AI 日报 · 2026年06月29日

新浪开源模型VibeThinker-3B旨在展示推理能力可良好压缩，但事实性知识则不能

Jonathan Kemper 查看Jonathan Kemper的LinkedIn档案

Jun 28, 2026

Nano Banana Pro 由 THE DECODER 提供提示

要点

微博的新模型VibeThinker-3B仅有30亿参数，但在数学和编程基准测试中可媲美体积大至其333倍的顶级模型。

这一性能源于对阿里巴巴基础模型进行的多阶段后训练。然而，在需要广泛事实性知识的任务上，该小模型则远远落后。

研究人员得出结论：结构化的逻辑推理依赖于少量模式且可良好压缩，而广泛的世界知识仍需大型模型。

一个仅有30亿参数的中文语言模型，有时在数学和编程任务上可媲美体积大其百倍的模型。其背后的研究人员提出了一项关于AI能力结构如何组织的假设。

微博母公司新浪发布了一款小型语言模型，在困难数学和编程任务上可与当今顶级模型竞争。根据一份技术报告，VibeThinker-3B在诸如AIME26等竞争性基准测试中表现与DeepSeek V3.2和Kimi K2.5相当。这两款模型的参数量是它的200到333倍。

新浪将这款模型定位为一次实验，旨在探究模型要达到顶级竞争力究竟需要多少算力。其前代产品VibeThinker-1.5B于2025年11月发布。新版本更进一步，追问一个小模型能否达到真正的顶级性能，而不仅仅是“就其规模而言表现不错”。

在六项数学和编程基准测试中，该3B模型（橙色）的性能落在包括Gemini 3 Pro、GLM-5和Claude Opus 4.5在内的五款当前顶级模型的性能范围内。| 图片来源：新浪微博

逻辑可向下缩放，事实性知识则不能

这些结果讲述了两个不同的故事。在具有明确可验证解决方案的结构化任务上，如数学奥林匹克竞赛或编程挑战，VibeThinker-3B可与GLM-5或Gemini 3 Pro等模型媲美。在LiveCodeBench上，它击败了所有其他参数量低于200亿的模型。

事实性知识则是另一回事。在知识密集型基准测试 GPQA-Diamond 上，该模型远远落后于它那些体量更大的竞争对手。

VibeThinker-3B 在 IMO-AnswerBench 上几乎比肩 DeepSeek V3.2、GLM-5 和 Kimi K2.5，尽管其规模小了几百倍。| 图片来源：新浪微博

为了排除数据污染，该团队让模型在训练结束后参加了 2026 年 4 月下旬至 5 月下旬举办的 LeetCode 竞赛。VibeThinker-3B 在第一次尝试中就解决了 128 道题中的 123 道。这使得它领先于 GPT-5.2、Qwen3-Max、Kimi K2.5 和 Claude Opus 4.6。仅落后于 GPT-5.3-Codex、Gemini 3.1 Pro 和 Gemini 3 Flash，但差距不大。

后训练承担了主要工作。

VibeThinker-3B 基于阿里巴巴的 Qwen2.5-Coder-3B 构建。新浪的贡献在于后训练，即在大数据集上进行通用预训练之后的一切步骤。根据报告，正是后训练让一个 3B 模型逼近了顶尖水平。

后训练分阶段进行。首先，模型通过监督微调学习广泛的任务，涵盖数学、编程和通用对话。然后，模型针对困难的多步推理问题进行定制化调整。

随后是强化学习，依次应用于数学、编程和 STEM 领域。然后通过自蒸馏将每个阶段学到的技能整合到单个模型中。最后一步确保模型更好地遵循指令。

正是后训练实现了性能飞跃。两阶段监督微调、针对数学、代码和 STEM 的多阶段推理强化学习，再加上最终为了提示词遵循而进行的指令阶段。| 图片来源：新浪微博

在微调过程中，团队有意构建了多种多样的解题路径。随后强化学习强化那些有效的路径。其观点是，性能来自训练方法、数据质量和可靠的验证信号，而非来自更多的参数。

这对 AI 能力运作方式意味着什么？

基于这些结果，作者提出了他们所谓的“参数压缩-覆盖假说”。不同的 AI 能力具有不同的结构，需要不同数量的参数。

逻辑推理，比如像逐步解一道数学题，依赖于少数几种反复出现的模式：搜索、检查条件、纠正错误、组合中间结果。这类能力可以压缩进一个紧凑的核心中。世界知识则运作方式不同。回答横跨多个主题的开放性问题需要广泛的覆盖面，这意味着需要大量参数来存储大量事实。

研究人员表示，这重新定义了小模型的用途。它们不仅是专为低成本推理打造的廉价轻量版本，更是一条与传统规模扩展逻辑并行的独立研究路径。在任务可验证且有明确解构模式的情况下，参数量不再是瓶颈。

VibeThinker-3B 已在 Hugging Face 和 GitHub 上公开提供。

小模型在狭窄任务上追赶远比它们大的系统，正成为一种模式。今年 4 月，阿里巴巴的 Qwen3.6-27B 在所有编程基准测试中的表现都超越了其规模大 15 倍的前代产品。据其开发者称，来自阿布扎比的 Falcon H1R 7B 达到了规模为其两到七倍模型的性能水平。早期关于小模型逻辑缺陷的研究表明，它们在多步推理上通常会碰壁。而 VibeThinker 在可验证任务上的结果恰恰挑战了这一假设。

AI 新闻，不炒作——由人工精选

订阅《THE DECODER》，获取无广告阅读体验、每周 AI 简报、每年六期的独家“AI 雷达”前沿报告、完整存档访问权限以及评论区使用权限。

来源：Arxiv

确定性提示词复杂度路由——将每个提示词发送到本地或云端模型，离线运行，无需调用任何模型进行决策。

快速入门·基准测试·对比说明·解释·更新日志

无需调用模型来决定路由 确定性且完全离线

基于自身数据进行校准 自带密钥，自主托管

Wayfinder 会分析提示词的结构（长度、标题、列表、代码）和措辞（证明、数学、硬约束），然后告诉你应该将其发送到本地小模型还是云端大模型。它在微秒内做出决策，离线运行，从不调用其他模型来做出判断：无需 API 密钥、无需网络、无需调用模型来决策。你会得到一个分数和一个推荐建议，至于如何使用，完全由你决定。

简单的提示词留在本地，困难的提示词交给昂贵模型，这样你就不再为“总结一下”和“修个错别字”这类任务支付顶级价格了。

对比说明

大多数路由系统通过调用模型来决策：训练好的分类器、大语言模型评判或托管 API。这恰恰在旨在节省成本的步骤上增加了延迟、成本和随机性。而 Wayfinder 则通过读取结构和措辞来决策，因此判断结果免费且每次一致。

路由系统 决策方式 是否调用模型？ 自主托管 可校准

Wayfinder 确定性结构评分 否 是 是

RouteLLM 训练好的分类器（偏好数据） 是 是 需重新训练

NotDiamond / Martian 基于学习，托管服务 是 否 通过平台

OpenRouter (Auto) 托管自动路由 是 否 —

Bifrost / LiteLLM 供应商网关（非复杂度路由） 否 是 不适用

最后两行（OpenRouter、Bifrost、LiteLLM）中的网关回答的是另一个问题：根据价格、可用性和故障转移，哪个供应商来服务于一个调用。而 Wayfinder 回答的是提示词应该属于哪个层级：根据难度，离线决定是便宜还是昂贵。这两者可以组合使用。先运行 Wayfinder 做出“便宜还是昂贵”的判断，再通过底层的网关到达供应商。

Wayfinder 追求的不是顶尖的准确率数字。它提供的是一个你可以离线运行、无需调用模型、并能根据自身流量进行调优的路由决策。默认情况下，它只对提示词结构进行评分。它也能读取词汇线索（如证明、数学、约束条件），但这些功能默认是关闭的：一项针对独立编写的提示词进行的双盲测试显示，词汇提升并不具备泛化能力（它只能捕捉约 20% 的未见过的困难提示词，并且输给了一个简单的词数基线），因此这些功能是选用的。只有当你针对自身流量的词汇进行了校准后，才建议提高它们的权重。一个纯粹基于语义困难的提示词（例如一段微妙的代码片段，或者一个看似无害的问“第 100 个质数是什么？”）并没有结构上的信号，此时语义路由器会表现更好。在盲测中真正靠得住的部分才是你应该依赖的：一个确定性的、亚毫秒级的、无需调用模型的离线路由决策。基准测试（make benchmark）会显示它在哪些场景胜出、哪些场景失利，对标的是真实的基线和一个完美的“预言机”。你可以用它指向 RouterBench 或 RouterArena 来获取分级评分。

刚接触这个项目，或者在权衡利弊？常见问题解答给出了直白的回答——包括它在哪些场景表现不佳（在 RouterBench 的短而难的条目上表现不比随机选择好），以及为什么你仍然应该运行它。

试试演示（无需密钥）

两种方式让你亲眼看到路由决策——无需 API 密钥、无需模型、不上网。

在终端里——一个以决策驱动的聊天，运行在 Wayfinder 调色板中。终端聊天已包含在默认安装中，所以你无需额外添加任何东西——或者通过 uvx 无需安装直接运行：

uvx wayfinder-router chat --dry-run # zero install, zero keys

# or: pip install wayfinder-router && wayfinder-router chat

每一次对话轮次都会显示路由去向（● 本地 / ◆ 云端）、结构评分及原因（/why），以及与始终使用云端相比的累积节省。/init 无需离开聊天即可设置模型，/route · /local · /cloud 强制指定一个轮次，对话会跨会话持久保存（/threads）。

在浏览器中——网页版聊天界面，带有实时调节的阈值滑块：

pip install "wayfinder-router[gateway]"

wayfinder-router webchat --dry-run

# opens http://127.0.0.1:8088/demo

webchat 是基于 serve（网关及其 /demo 页面；参数包括 --no-open、--port、--host 0.0.0.0、--dry-run）的轻量级启动器；serve 是无头命令。两个界面都会显示每条消息的路由去向（本地还是云端）、复杂度评分及其原因（功能分解），以及与始终使用云端相比节省的成本。无需配置时，两者仅作决策展示（web 端通过 --dry-run 参数，终端则显示预览），因此你可以零配置地进行试探。要获取真实回复，请运行 wayfinder-router init 来搭建 [gateway.models] 框架（然后运行 wayfinder-router doctor 确认你的密钥解析成功）——详见快速入门指南。

支持任何兼容 OpenAI 的 API

Wayfinder 将每次调用转发至 OpenAI 风格的 /chat/completions 端点——因此只要你的提供商支持该协议（绝大多数都支持），它就能直接工作。一个层级由 base_url、模型名称以及请求时从环境变量读取的密钥组成；无需 SDK，也不需要针对每个提供商的专用代码。你可以将免费的本地模型与托管的云端模型配对，或者运行两个云端层级。

… 此外还支持 Groq、Together、OpenRouter、Fireworks、DeepSeek 以及本地服务器（vLLM、LM Studio、llama.cpp）——以及任何接受 Bearer 密钥的 OpenAI 兼容端点。

快速入门

将 Wayfinder 置于你的模型前端。你的应用继续使用 OpenAI API 进行通信；你只需更改一个 base_url。

搭建配置——运行 init 会写入一个启动版的 wayfinder-router.toml 文件（默认配置为本地无密钥 Ollama 到 Anthropic 云端）以及一个 .env.example 文件，然后检查你的密钥：

pip install "wayfinder-router[gateway]"

wayfinder-router init # starter config (hybrid preset)

wayfinder-router init --preset openai # two OpenAI tiers (gpt-4o-mini → gpt-4o)

wayfinder-router init --preset gemini # two Gemini tiers (gemini-2.5-flash → gemini-2.5-pro)

wayfinder-router init --interactive # pick providers/models step by step

或者手动在 wayfinder-router.toml 中描述你的两个模型：

[routing]

threshold = 0.5 # below -> local, at/above -> cloud

[gateway.models.local]

base_url = "http://localhost:11434/v1"

model = "llama3.2"

[gateway.models.cloud]

base_url = "https://api.openai.com/v1"

model = "gpt-4o"

api_key_env = "OPENAI_API_KEY" # read from this env var, never stored

# api_key_cmd = "op read op://Private/OpenAI/credential" # optional: fill it from a vault

Wayfinder 从不存储密钥：模型通过 api_key_env 指定环境变量名称，密钥在请求时从你的环境中读取。无需任何“安装”步骤——只需导出该变量即可。不想在 shell 中直接粘贴原始密钥？可添加可选的 api_key_cmd 参数，Wayfinder 会在启动时通过你的密钥库填充该变量——例如 op read …（1Password）、security …（macOS 钥匙串）、secret-tool …（Linux）、pass/gopass、vault kv get …、aws secretsmanager get-secret-value …、bw、doppler、gcloud secrets …，或任何能输出密钥的命令。密钥仅保存在内存中，仍然不会写入磁盘。wayfinder-router doctor 可检测你已安装的上述工具，并给出精确的命令行建议。

设置好你的密钥，然后运行网关。`doctor` 会在启动前重新检查配置以及每个模型的密钥是否有效（✓ 已设置 / ✗ 未设置）。

export ANTHROPIC_API_KEY=sk-... # or OPENAI_API_KEY, per your config

wayfinder-router doctor # ✓/✗ per model — is each key set?

wayfinder-router serve --port 8088

将现有的客户端指向该网关即可，无需改动代码。

client = openai.OpenAI(base_url="http://localhost:8088/v1", api_key="unused")

client.chat.completions.create(model="auto", messages=[{"role": "user", "content": "..."}])

简单的提示词走本地，困难的提示词走云端，每次响应都会携带 `x-wayfinder-router-model` 和 `x-wayfinder-router-score`，方便你查看请求路由到了哪里。想强制某个请求使用某一层级？设置 `model="local"` 或 `"cloud"`（或 `prefer-local` / `prefer-hosted`），通过 `X-Wayfinder-Threshold` 标头为单次调用调整分界，也可以用 `/local` 或 `/cloud` 开始聊天消息（详见“控制单次请求”）。

验证运行是否正常：

curl -s localhost:8088/healthz

# {"status":"ok","models":["cloud","local"]}

curl -s -D - -o /dev/null http://localhost:8088/v1/chat/completions \

-H "Content-Type: application/json" \

-d '{"model":"auto","messages":[{"role":"user","content":"hi"}]}' \

| grep -i x-wayfinder-router

# x-wayfinder-router-model: local

# x-wayfinder-router-score: 0.00

还没有后端？`wayfinder-router serve --dry-run` 会返回路由决策结果，而不是调用上游，这样你无需接入真实模型，只需 30 秒就能感受路由效果。

安装

命令 获取内容

`pip install wayfinder-router` 评分器、CLI、Python API 以及终端聊天（`chat`）；评分器/库导入保持轻量依赖

`pip install "wayfinder-router[gateway]"` 额外添加与 OpenAI 兼容的路由网关，这是常见的服务场景

`pip install "wayfinder-router[ui]"` 额外添加本地校准/解释/配置界面

`pip install "wayfinder-router[all]"` 在默认安装基础上额外包含网关和界面

工作原理

Wayfinder 位于你已使用的任何 OpenAI 兼容客户端之后。你只需将客户端的 `base_url` 指向该网关一次，此后它就不可见。同一个客户端无论请求路由到本地还是托管，都能正常处理。

your client (chat app, IDE, agent, or code)

|

v

Wayfinder gateway scores, picks a model

|

|-- low --> local (Ollama, vLLM)

|-- high --> hosted (OpenAI, any /v1)

|

v

response returns via the same client,

with x-wayfinder-router-* headers

由此衍生出以下几点：

你面前的界面由你决定。可以是聊天 GUI（Open WebUI、LibreChat），带自定义端点的 IDE 助手（Cursor、Continue），智能体框架，或者你自己基于 OpenAI SDK 编写的代码。今天想要一个聊天窗口？把 Open WebUI 放在前面，指向网关即可。

本地和托管都是后端，而非应用。本地模型只是一个服务器（Ollama、LM Studio、vLLM、llama.cpp），使用 OpenAI 的 `/v1` 协议；托管模型也是同样的形态。用户永远不需要切换界面，通常也不知道是哪个模型回答了问题。

分数是计算得出的，而非第二意见。让模型判断一个提示词的难度会很慢、不确定性高，并且为了决定是否调用模型而先调用一次模型本身也会产生成本。Wayfinder 则直接扫描提示词——根据其结构（长度、标题、步骤、链接、代码、表格）以及措辞中的难度线索（推理术语、数学符号、约束条件）——生成一个 0.0 到 1.0 之间的值，并与你的阈值进行比较。相同的提示词、相同的阈值、相同的答案。这是一个难度代理指标，而非最终裁决，因此阈值由你自己调优。

密钥在请求时从环境变量中读取，不会写入配置文件或评分路径中。

通过命令行界面对提示词进行评分

echo "Summarise this paragraph in one sentence." | wayfinder-router route -

Recommended Model: local

Complexity Score: 0.00 (mode: tiered)

Tiers:

>= 0.00 local <-

>= 0.50 cloud

Contributing Features:

Word Count: 6

...

添加 `--json` 参数用于机器消费者（智能体读取该信息并将其路由到自己的模型）：

{

"schema_version": "3",

"score": 0.66,

"recommendation": "cloud",

"mode": "tiered",

"features": { "word_count": 545, "heading_count": 12, "reasoning_term_count": 3, "...": 0 },

"tiers": [{ "min_score": 0.0, "model": "local" }, { "min_score": 0.5, "model": "cloud" }]

}

配置路由

Wayfinder 会读取自己的 `wayfinder-router.toml` 配置文件，该文件通过从运行目录向上寻找的方式定位。共有三种模式，按优先级顺序排列（分类器 > 层级 > 阈值）；标量分数权重适用于其中任何一种模式。

二进制模式（默认）是一个单一分界点：

[routing]

threshold = 0.6

weights = { word_count = 4.0, list_item_count = 2.5 }

`--threshold N` 可在单次运行中覆盖阈值；`WAYFINDER_ROUTER_THRESHOLD` 环境变量可覆盖该值。

若要启用词汇线索，提高它们的权重并在拐点处切分——这是在实际前沿流量上相对于纯结构默认值所取得的唯一保持性改进（skill −0.038 → +0.057，在 RouterBench 上节省 61% 成本）。详见 `docs/lexical-routing.md` 和可直接编辑的 `examples/wayfinder-router.lexical.toml`；请根据自身流量重新校准阈值（仅用约 20 条提示词进行引导只是冒烟测试——参见 `benchmarks/calibration-eval.md`）。

分层路由将分数区间按顺序分配给任意数量的模型：

[[routing.tiers]]

min_score = 0.0

model = "llama-3b"

[[routing.tiers]]

min_score = 0.3

model = "llama-70b"

[[routing.tiers]]

min_score = 0.6

model = "claude-cloud"

分类器是一个拟合的多项逻辑回归模型，基于每个模型线性分数的 argmax 进行决策。通常通过 `calibrate` 生成，而非手动编写。

每个 `[gateway.models.<name>]` 块将路由名称映射到上游 `base_url`、模型以及可选的 `api_key_env`（环境变量名称，绝不是密钥本身）。网关是唯一接触密钥或网络的组件；评分器、配置和校准器保持纯离线状态。

基于你的数据进行校准

cut 是一个代理值，因此需要根据您自身的流量进行调整。wayfinder-router calibrate 命令会读取带标签的 JSONL 数据集（{"text": ..., "label": ...}），并输出一个配置片段。该命令离线运行，不会调用任何模型；标签就是您的真实标注数据。

wayfinder-router calibrate data.jsonl --mode threshold # sweep the binary cut

wayfinder-router calibrate data.jsonl --mode tiers # ordinal multi-model

wayfinder-router calibrate data.jsonl --mode classifier --out wayfinder-router.toml

该配置片段可直接放入 wayfinder-router.toml 文件中；准确率和选定的断点值会打印到标准错误输出上。分类器通过确定性的 L2 正则化牛顿法/IRLS 算法拟合，采用纯 Python 实现，只需数次迭代即可收敛。

若想从成本角度而非单纯准确率角度来选择 cut，可使用成本感知目标函数。--objective knee 可自动选择成本感知拐点（它最大化质量恢复 × 成本节省——无需猜测目标，并且不会像纯准确率那样在标签偏差场景下陷入“始终路由到昂贵模型”的困境）；--objective cost-quality --target-savings X 则可指定一个具体的节省下限。添加 --weights 参数可对自定义特征权重（例如词汇主动切换）进行评分并输出，从而生成一份完整、可直接部署的配置（参见 docs/lexical-routing.md）：

wayfinder-router calibrate data.jsonl --mode threshold --objective knee \

--costs local=0.2,cloud=1.0 \

--weights reasoning_term_count=5,math_symbol_count=3,constraint_term_count=1.5

成本仅作为元数据存在——它会影响校准后的 cut 值，并会暴露在 /metrics 端点上，但永远不会进入每次请求的决策过程，后者始终保持确定性和零成本。

控制单次请求

部署配置设定了默认边界，但客户端可以在单个请求上通过普通 OpenAI 传输方式覆盖该决策。覆盖仅改变请求的发送目的地；提示词评分依然会执行，且不会增加任何模型调用。

model 字段是一条路由指令。auto（或任何常规模型 ID）表示让 Wayfinder 决定；配置好的端点名称（local、cloud）会将请求固定到该端点；prefer-local / prefer-hosted 则分别将请求固定到路由器的低端/高端（prefer-cloud 仍可作为 prefer-hosted 的别名使用）。

X-Wayfinder-Threshold 头部可针对该请求重新划定 cut 值，取值为 0.0-1.0 之间的数字，会复用您已有的权重（仅适用于二元路由器）。

消息内指令（需主动启用：`[gateway] slash_directives = true`）让普通聊天框也能控制路由——以 `/local`、`/cloud`、`/prefer-hosted` 或 `/auto` 开头输入消息，即可锁定该轮对话的路由（指令在模型看到之前已被剥离）。只有已知指令才会生效；其他以 `/` 开头的内容将作为普通文本处理（WF-ADR-0036）。

# Pin one call to cloud regardless of score:

client.chat.completions.create(model="cloud", messages=[...])

# Or move the cut for one call (keep model="auto"):

client.chat.completions.create(

model="auto", messages=[...], extra_headers={"X-Wayfinder-Threshold": "0.8"}

)

每次响应都会在 `-model` 和 `-score` 请求头旁边添加 `x-wayfinder-router-mode`（取值：scored / pinned / threshold-override），这样你就能看到是哪个通道决定了路由。

从聊天 UI 驱动路由（无需分支）

由于模型字段本身就是路由指令，任何兼容 OpenAI 的聊天 UI 无需修改代码即可驱动路由：应用原有的模型下拉菜单会自动变成按对话设置的路由选择器（auto / prefer-local / prefer-hosted / 固定端点）。网关会在 `GET /v1/models` 中列出这些选项，因此 UI 可以自动发现它们。

LibreChat——将 `examples/librechat.yaml` 和 `examples/docker-compose.override.yml` 复制到你的代码目录中，运行 `docker compose up`，然后选择 "Wayfinder" 端点。

Open WebUI——添加一个指向该网关的 OpenAI 连接；它会自动发现路由选项。

具体配置请参见 `examples/` 目录下的两个示例。标准聊天 UI 无法实现的是实时按对话调整阈值的滑块；这正是 wayfinder-chat 分支所增加的功能，而这条无分支路径则是先用来验证该功能。

查看请求的去向

Wayfinder 的控制功能分布在您已经运行的各个工具中，因此很容易忽略它正在工作。以下四个界面可以展示或控制路由：

界面 显示内容 位置

模型下拉菜单 路由选择器（auto / prefer-local / prefer-hosted / 固定端点） 您的客户端，来自 `GET /v1/models`

响应头 每个请求的去向及原因（`-model` / `-score` / `-mode` / `-request-id`） 每次响应

调试体字段 响应体内的决策信息，需主动启用 请求头 `X-Wayfinder-Debug: true`

仪表盘 最近的决策、按模型统计的次数、分数——仅限元数据，绝不包含提示词文本 `GET /router`（JSON 格式位于 `/router/recent`）

该仪表盘与旁路的 wayfinder-router UI 控制台是分开的，后者用于调优，不面向生产流量。

从反馈中学习

不要猜测分界点，而是从你自己对本地输出与托管输出的判断中学习。循环是：收集判断、校准、自动路由。

通过 A/B 引导来启动。对于每个示例提示词，wayfinder-router onboard 运行两个分支，并询问哪一个足够好；答案就是一个标签：

wayfinder-router onboard prompts.jsonl --arms local,cloud --calibrate > wayfinder-router.toml

比较结果输出到 stderr；--calibrate 将生成的配置打印到 stdout。每次判断都会将一条 {"text", "label"} 行追加到反馈日志中，该日志本身就是校准数据集，因此日志直接转化为配置。

要跳过手动分级，让 wayfinder-router 自动判断标签。它运行两个层级，并向自动判断器询问“较便宜的层级是否足够好？”——同样的充分性问题，无需人工介入：

wayfinder-router judge prompts.jsonl --arms local,cloud --gold gold.jsonl > wayfinder-router.toml

内置判断器是一个确定性文本比较器，当无法判断时会弃权而不是猜测。因为一个错误标签会在静默中降低实时路由的质量，判断器只有在通过信任门限时才会输出配置——与您人工标记的 --gold 集的一致性（Cohen's κ ≥ 0.6）、在折外数据集上相比多数基线的提升，以及两个分支都有代表。如果门限检查失败，它会打印混淆矩阵并拒绝（标签仍会被记录）。传递 --save-comparisons out.jsonl 以同时保留原始响应（默认关闭——它存储大量数据）。

一旦你开始自动路由，通过记录哪个模型实际上足够好来保持诚实：

curl localhost:8088/v1/feedback -d '{"text": "...", "label": "cloud"}'

然后按计划重新拟合——通过 cron、k8s CronJob 或点击 UI。重新校准只重写 [routing] 部分，保留您的 [gateway] 端点，运行中的网关会热重载结果而无需重启：

wayfinder-router recalibrate # log -> calibrate -> write config

wayfinder-router recalibrate --min-labels 50 # no-op until you have enough signal

判断过程会运行模型，因此它位于网关层（使用您的密钥）；评分核心保持不变，日志不携带任何秘密。

部署与集成

CLI、引导和 UI 用于操作员和启动阶段。在生产环境中，提示词通过网关（透明模式）或库（进程内模式）流动，因此路由发生在提示词所在的位置。

以服务、sidecar 或独立模式运行网关：

docker build -t wayfinder-router . && docker run -p 8088:8088 -v "$PWD/data:/data" wayfinder-router

# or: docker compose up gateway (see docker-compose.example.yml)

将你现有的客户端指向它，无需修改应用程序。任何兼容 OpenAI API 的客户端都可以接受 `base_url`，包括 Agent 框架（LangChain、LlamaIndex）、支持自定义端点的 IDE 助手（Cursor、Continue），以及像 LiteLLM 这样的网关：

client = openai.OpenAI(base_url="http://localhost:8088/v1", api_key="unused")

请参阅集成方案，获取可直接复制粘贴的配置：聊天界面（Open WebUI、LibreChat、Jan）、编辑器（Continue、Cline、Zed、JetBrains）、Agent 框架（LangChain、LlamaIndex、CrewAI、AutoGen、OpenAI Agents SDK、Vercel AI SDK）以及 CLI（aider、Copilot CLI）——另外还有标准的 `OPENAI_BASE_URL` / `OPENAI_API_KEY` 对。

Claude Code 使用的是 Anthropic 的 Messages API 而非 OpenAI 的 API，因此网关暴露了一个 POST `/v1/messages` 适配器（WF-DESIGN-0011），负责 Anthropic ⇄ OpenAI 的双向转换——包括流式和工具调用。将其指向网关根地址，Claude Code 就能像其他客户端一样通过 Wayfinder 路由：

export ANTHROPIC_BASE_URL="http://localhost:8088" # client appends /v1/messages

export ANTHROPIC_API_KEY="unused" # the gateway uses each upstream's own key

claude

从用户所在的任何位置收集反馈。你的应用、IDE 或聊天界面会显示一个点赞或点踩按钮，并提交判断结果；下次重新校准时会从中学习：

fetch("http://localhost:8088/v1/feedback", {

method: "POST",

body: JSON.stringify({ text: prompt, label: wasGoodEnough ? "local" : "cloud" }),

});

网关以异步方式转发并支持流式：当请求中包含 `stream: true` 时，返回结果为 Server-Sent-Events，因此聊天客户端可以在 token 到达时实时呈现。上游超时或连接失败时，会返回一个符合 OpenAI 格式的错误响应，而非裸的 500 状态码；每个响应都带有请求 ID 用于追踪，路由决策和重载失败信息都会被记录。可供调节的参数如下：

设置项 作用

`WAYFINDER_ROUTER_TIMEOUT` / `serve --timeout` 上游超时时间（秒，默认 60）

`WAYFINDER_ROUTER_FEEDBACK_TOKEN` 设置后，`/v1/feedback` 需要 `Authorization: Bearer <token>`

`serve --dry-run` 返回路由决策，但不调用任何上游

`GET /healthz` 当配置的 `api_key_env` 未设置时，报告降级状态并列出缺失的键

`GET /router` 只读面板，显示最近的决策记录，设置 `X-Wayfinder-Debug: true` 可在响应正文中输出一条决策

`GET /v1/savings?period=today|7d|30d|all` 实际成本与始终使用前沿模型的成本对比，以及两者之间的节省额，按路由展示（WF-DESIGN-0007）

`WAYFINDER_ROUTER_SAVINGS_FILE` 节省账本的持久化路径（默认：`<config-dir>/wayfinder-savings.json`）

`[gateway] retries / breaker_threshold / breaker_cooldown` 可靠性：针对传输层/429/5xx 错误进行有限重试，以及每个目标独立的断路器机制（WF-ADR-0031）

[网关] 故障转移 = 同层级|降级|升级 资源耗尽时，默认停留在当前层级，或回退到更便宜的层级（绝不增加成本），或升级到更贵的层级（需主动选择）；通过每次请求的 X-Wayfinder-Failover 头控制

[gateway.models.<名称>] fallbacks = [...] / context_window（备选模型列表 / 上下文窗口） 同层级下失败时尝试的备选端点；跳过窗口不足以容纳提示词的目标。响应中包含 x-wayfinder-router-served-by 头

[gateway.budget] limit（限额）/ window = day|month|all（周期 = 日|月|全部）/ on_breach = degrade|block（超限行为 = 降级|拦截） 消费上限：一旦达到限额成本，默认降级到最便宜的层级（绝不增加成本），或使用 HTTP 402 进行拦截。通过 x-wayfinder-router-budget 头暴露；需要配置真实的 cost_per_1k 价格（WF-ADR-0032）

[gateway.cache] enabled（启用）/ ttl（缓存时间）/ max_entries（最大条目数）/ max_bytes（最大字节数） 精确匹配响应缓存：对完全相同的确定性请求重播已存储的回答——即时且免费重复。默认关闭；仅内存缓存；增大 max_bytes（默认 64 MiB）可缓存更多。命中缓存免费，并通过 x-wayfinder-router-cache: hit|miss 头暴露；禁用缓存时会清空所有缓存（WF-ADR-0033）

[gateway.rate_limit] rpm（每分钟请求数）/ tpm（每分钟上游 token 数）/ window（时间窗口） 在固定时间窗口（默认 60 秒）内限制每分钟请求数和/或每分钟上游 token 数；超限时返回 429 状态码及 Retry-After 头。这是全局网关的最外层防护栏（在评分前检查）。成功响应携带 X-RateLimit-Limit/-Remaining/-Reset 头，以便客户端自我节流；通过 x-wayfinder-router-rate-limit 和 wayfinder_router_rate_limited_total 指标暴露（WF-ADR-0034）

[gateway.keys.<ID>] hash（哈希）/ tags（标签）/ models（模型，可嵌套 budget / rate_limit） 虚拟 API 密钥：一旦设置任何密钥，/v1/* 端点要求有效的 Authorization: Bearer 令牌（否则返回 401）。使用 wayfinder-router keys new 命令生成；仅存储 SHA-256 哈希值。每次花费和节省的金额都会按密钥归因（通过 /v1/savings 的 by_key 参数和 wayfinder_router_key_requests_total 指标）；密钥可携带自己的预算/速率限制（以最严格的为准）以及模型白名单（将模型限制到最近允许的层级）（WF-ADR-0035）

解释与调优

要了解某个提示词为何被路由到特定位置，可以请求逐特征分解：每个特征的值、其归一化水平、其权重以及其在评分中所占的份额。

wayfinder-router route prompt.md --explain

对于交互式调优，有一个本地 Web UI：

解释 —— 粘贴一条提示词；查看分数、等级阶梯和贡献柱状图，然后拖动阈值滑块，实时观察路由变化。

校准 —— 粘贴带标签的数据集，运行一种模式，查看准确率、扫描曲线以及生成配置片段。

配置 —— 编辑 wayfinder-router.toml，支持实时验证并保存。

上手 —— 在浏览器中对本地模型和托管模型进行 A/B 测试，为每个模型打分，并根据日志校准（需要 [gateway] 来处理模型调用）。

pip install "wayfinder-router[ui]"

wayfinder-router ui --port 8099 # then open http://localhost:8099

该 UI 是对相同纯函数的薄封装；它从不调用模型，也不在其中暴露任何机密。

Python API

from wayfinder_router import score_complexity, RoutingConfig, explain_score

result = score_complexity(prompt_text, config=RoutingConfig.binary(threshold=0.7))

print(result.recommendation, result.score, result.features)

for fc in explain_score(result.features, RoutingConfig().weights):

print(fc.name, fc.contribution)

起源

Wayfinder 最初是一个更大需求工具内部的路由实验，后来被拆分出来，因为路由是运行时关注点，而非知识关注点：提示词路由器不应该让你安装一个你并不需要的引擎。最终成果是一个小巧、专注的工具，其评分核心保持零依赖——你可以仅使用标准库导入 wayfinder_router 并对提示词进行评分（WF-ADR-0001, WF-ADR-0029）。

仓库布局

wayfinder-router/

wayfinder_router/ the package: scorer, tiers + classifier, config loader/writer,

offline calibration (Newton/IRLS), explain, the feedback log and

onboarding harness, recalibration, CLI, and the optional gateway

and local UI (the impure layers, behind their extras)

tests/ scorer, config, calibration, explain, feedback, onboard,

recalibrate, CLI, gateway, and UI coverage

decisions/ design notes behind the tool's own choices

docs/ the FAQ and the lexical-routing guide

Dockerfile, docker-compose.example.yml deploy the gateway as a service

测试

pip install -e .[dev] # or: pip install pytest

make test

关于

简单的 CLI 工具，用于在本地和托管 LLM 模型之间进行确定性查询路由

资源

自述文件

许可证

Apache-2.0 许可证

动态

自定义属性

星标

202 星标

关注者

1 人关注

复刻

11 个复刻

举报仓库

发布版本 9

Wayfinder Router 2026.6.9 - 将网关作为控制平面 最新版

2026 年 6 月 28 日

+ 8 个发布版本

包

贡献者

语言

Python 93.1%

HTML 6.7%

其他 0.2%

在一项为期500天的创业生存测试中，只有三款AI模型的最终资本高于初始资金。

马克西米利安·施赖纳 查看马克西米利安·施赖纳的领英资料

Jun 28, 2026

Nano Banana Pro 由 THE DECODER 提供提示词

普林斯顿大学的研究人员构建了 CEO-Bench，这是一个测试AI智能体在500个模拟日内运营一家虚构软件公司的基准。目前大多数模型都会破产，而一个无需AI的简单基于规则的启发式方法几乎击败了所有模型。

AI智能体在狭隘任务上表现越来越出色：修复漏洞、在对话中遵循服务策略、或完成基于网页的工作流程。普林斯顿大学的研究指出，这些任务结构简单：智能体获得明确目标，短期行动，并能迅速收到反馈。许多重要的现实任务则完全不同。它们涉及在不确定性下的长链决策，需要设定优先级、分配有限资源、解读嘈杂信号并适应不断变化的条件。

为了专门测试这些技能，研究人员开发了 CEO-Bench。该基准模拟了一个现实中此类长期任务的例子：在500个模拟日内运营一家创业公司。

研究人员援引了一个著名例子：1997年，苹果公司距破产仅剩90天。史蒂夫·乔布斯画了一个简单的2x2网格——消费者与专业级、桌面与便携——并决定苹果只在这四个象限内制造产品。随后诞生了 iMac、iPod 和 iPhone。

作者认为，这种战略引导智能与当前AI智能体所做的本质不同。智能体在单项任务上进步很快。但引导整个组织实现长期目标？那完全是另一个问题。CEO-Bench 是首次尝试衡量这种“引导智能”。

一家虚构软件公司的AI首席执行官

在 CEO-Bench 中，智能体运营一家名为 NovaMind 的虚构订阅制软件公司。初始状态为零客户、银行存款100万美元。最终业绩以剩余现金衡量。如果余额哪怕一次降到零以下，公司即宣告破产，模拟结束。

该智能体通过一个包含 34 个工具的 Python API 和一个包含 19 张表的数据库来控制这家公司。它不只是下发单个命令，而是自己编写代码、用 SQL 查询数据库，并根据结果构建自定义工作流。研究人员表示，这使得它面临着与人类 CEO 同样的挑战。

在这持续 500 天的创业模拟中，智能体将数据库查询、管理工具交互以及社交媒体帖子，与市场周期和结果指标（如工单解决数、订阅增长量、取消率和可用现金）联系起来。| 图片来源：Chen, Narasimhan, Liu

需要决策的事项很多：定价与套餐层级、各渠道广告支出、产品质量与研发、基础设施容量与客户支持，还有与企业客户的多轮谈判。除此之外，还有一个模拟社交网络，智能体可以在其中阅读投诉、竞争对手新闻和经济趋势，并自行发帖。

滞后反馈与隐藏变量使得这项测试难度很大

让这项任务变得困难的是时间与不确定性。决策会在真实的商业时间线上展开：收入只在计费日到账，研发项目耗时数天到数周，而错误常常要到后来才会通过客户流失或声誉受损显现出来。成本则立即产生。智能体必须花钱，但回报可能数周后才出现。

公司的大部分状态是隐藏的。智能体无法直接看到客户满意度、支付意愿或最低质量期望。它必须从嘈杂的信号（如取消率、支持工单或社交网络上的反应）中拼凑出这些信息。模拟系统包含 26 个客户细分群体和单个客户，每个都有自己的预算、价格敏感度和期望。

世界也在不断变化。竞争对手会周期性提高客户质量期望，偏好随时间推移而变化，模拟的商业周期也会影响需求和支付意愿，因此智能体必须持续调整。

研究人员特意选择了固定的、透明的规则，而不是用大语言模型作为裁判。他们希望避免他们在 Vending-Bench（一个带有模拟自动售货机的测试）中看到的一个弱点：在那里，AI 模拟的供应商可能会因智能体做出不切实际的口头承诺而奖励它。

大多数模型破产

在十四个受测模型中，大多数未能完成任务。几乎所有模型都能生成有效的命令和数据库查询，但没有任何一个能长期保持连贯的策略。许多模型在模拟结束前就破产了。

只有三个模型的最佳运行结果超过了起始资本一百万美元：Claude Fable 5 获得 4715 万美元，Claude Opus 4.8 获得 2780 万美元，GPT-5.5 获得 2130 万美元。Claude Fable 5 是唯一一个在不止一次运行中超过起始资本的模型。

不过，有一个注意事项。一次 Fable 5 的运行因模型拒绝继续而中止，另外两次运行中，部分请求回退到了 Opus 4.8。GPT-5.5 在三次运行中有两次破产。

在 500 天的模拟中，Claude 模型手头现金达到最高 4715 万美元，其次是 GPT-5.5。多个智能体在运行结束前破产。| 图片：Chen, Narasimhan, Liu

最具说服力的比较对象是一个简单的基于规则的启发式方法，它完全不调用大语言模型。该方法设定固定的价格、配额和等级，将广告和定向开发集中于一小部分客户细分市场，并根据近期使用情况调整产能。这一启发式方法达到了 1576 万美元，超过了除 Fable 5、Opus 4.8 和 GPT-5.5 之外的所有模型。

研究人员还粗略估算了可达到的最终现金上限约为 22 亿美元。即使最好的智能体也远未达到。作者表示，该测试远未达到极限。

探索胜于谨慎

分析决策轨迹可发现明显的行为差异。GPT-5.5和Claude Opus 4.8会随着条件变化不断尝试新策略，无论是加大客户获取力度、调整客户分层，还是重新分配支持与研发预算。相比之下，Claude Opus 4.7面对挫折时主要采取削减成本、保留现金的应对方式。这种被动策略能让模型存活到最后，却无法实现盈利。

有趣的是，Opus 4.8和GPT-5.5通过截然不同的路径达到了相似的最终结果：Opus 4.8在早期获取了更多客户，但在模拟中期客户数量降为零；而GPT-5.5始终保持着客户基础。两者都编写了令人惊讶的复杂代码。Opus 4.8构建了自己的内部模拟，对客户群组进行建模以预测未来现金流；GPT-5.5则深入挖掘数据库中的谈判历史，揭示隐藏的客户偏好。

研究人员衡量了与成功相关的四种能力：

发现隐藏信息，例如哪个广告渠道对特定客户群体效果最好；

预测未来，以四周现金流预测的误差来衡量；

快速适应变化，以模型察觉竞争对手行动的速度来衡量；

以及提前规划，部分通过智能体笔记中出现“如果-那么”场景的频率来衡量。

在这四个维度上，Opus 4.8和GPT-5.5的得分均高于其他模型的平均水平。

工具环境也很重要

另一项发现涉及智能体用于行动的软件环境。研究人员还测试了搭配Claude Code的Claude Opus 4.7以及搭配Codex的GPT-5.5，这两个都是流行的编码助手。在这两种情况下，智能体的行动频率显著降低且表现更差。研究人员怀疑，这些工具中针对软件开发优化的系统提示词是原因所在。

缩短时间跨度同样无法解决问题。当模拟压缩至50天时，只有GPT-5.5最终实现了盈利。研究人员总结道，大多数模型即使在面向短期目标时，协调决策的能力仍然薄弱。

作者承认其设置存在局限性。产品仅通过单一质量评分来呈现，因为他们认为没有可靠的方法来评估产品定性变化。合规、安全和筹款方面的内容被排除在外，以保证每次运行在经济上可行。但他们表示，CEO-Bench 揭示了当前模型的本地工具能力与将长期行为连接成连贯策略的能力之间的差距。

AI 新闻，拒绝炒作——由人类策展。

订阅 THE DECODER，享受无广告阅读、每周 AI 新闻通讯、每年六次独家“AI Radar”前沿报告、完整档案访问权限以及评论区的访问权限。

继续阅读以了解全貌。订阅以获取无炒作报道。

访问所有 THE DECODER 文章。

无干扰阅读——没有 Google 广告。

访问评论区和社区讨论。

每周 AI 新闻通讯。

每年六次：“AI Radar”——深入探讨关键 AI 话题。

KI Pro 在线活动最高可享 25% 折扣。

访问我们完整的十年档案。

从 The Decoder 获取最新 AI 新闻。

太魔幻了！就在最近，英国前首相府数据科学家 Liam Wilkinson，花一个周末搭了 76 个 MCP 工具，把 Claude、GPT、Gemini 等四个顶尖模型扔进了《文明 VI》。

结果，23 场对局打完，其中一个 AI 造了核弹炸了法国 —— 然后输了。

一群 AI，被丢进了「文明 VI」里

Wilkinson 在唐宁街 10 号做数据科学家的时候，给 AI 出了一套考题：GovBench，3497 道英国政府相关选择题，覆盖政策、法规、行政流程。

GPT-5 考了 99.26 分。

满分级选手。但治国不是知识竞赛。一个能背下所有政策文件的人，丢到唐宁街真能治国吗？选择题测不出来的东西太多了：多线程决策、资源分配、长期规划、在不完整信息下做判断。他需要一个不一样的考场。然后他想到了《文明 VI》。

一个周末搭出来的系统，通过游戏引擎自带的端口接入。AI 看不到画面。没有地图，没有音乐，没有动画。它的整个世界就是一行行文本和六边形坐标。

Claude 在游戏日记里写了这么一段：“我感知游戏的方式和人类玩家完全不同。没有画面，没有音乐，没有动画。我的界面就是管道分隔符和六边形坐标。”

别小看「一个周末」。76 个工具覆盖了完整的游戏循环：城市管理、单位移动、外交谈判、科技研究、政策选择，一个不漏。

此外，Wilkinson 还给 AI 配了一个日记系统当外部记忆。如若不然，AI 连自己上一回合干了什么都记不住。

三个测试场景逐级加码：

Ground Control 是标准开局的公平基线；

Snowflake 是六臂雪花地图，每个文明被困在独立半岛上，外交基本没戏，逼你走军事路线；

Cry Havoc 是残酷模式，AI 对手全部拉满。

决策空间更吓人。

《文明 VI》晚期每回合的可能行动数量级大约是 10 的 166 次方。

做个对比，围棋每步大约 10 的 360 次方，但围棋一步只落一子。《文明 VI》每回合要同时操作几十个单位、选建筑、定科技、做外交，是一道巨大的组合决策题。

一场 50 回合复仇，AI 核平图卢兹

23 场里最魔幻的一局，是葡萄牙。Claude 扮演若昂三世，一个贸易文明。开局稳得一批。它建起了每回合 200+ 金币的贸易帝国，海上航线四通八达。外交胜利进度 18/20，只差两分就赢了。

这时候，法国的文化胜利进度条开始飙升。Claude 慌了。先试外交。没用，法国不吃这套。再派间谍去搞破坏，杯水车薪。试贸易制裁？法国的文化产出根本不依赖贸易。和平手段穷尽。

于是，Claude 翻开了科技树最后一页：核裂变。

接下来的 50 回合，它把大量资源从贸易和外交抽出来，投入核武器研发。All in 曼哈顿计划。

第 305 回合，核弹就绪。目标锁定：图卢兹。法国的文化产出重镇。

发射。图卢兹被夷为平地。法国的文化胜利进度条，停了。

AI 赢了吗？没有。

造核弹这 50 回合，AI 把所有注意力都放在了文化威胁上。它没有注意到一件事 —— 法国在疯狂攒外交分。

第 318 回合，法国以外交胜利赢得比赛。20 分对 18 分。

讽刺的是，18 分是 AI 自己辛苦攒下的外交分数。它曾经离外交胜利只差两分。但它把资源全抽去造核弹了。

AI 盯着文化威胁打了 50 回合，然后输在了外交。它的视野里只有一个威胁。但棋盘上有很多个。

无独有偶，伦敦国王学院做过一个核危机模拟实验，把三个前沿模型丢进去当虚拟国家的决策者。结果：95% 的模拟中，AI 选择了使用战术核武器。

AI 不是「想」用核弹。它是真的不知道还能怎么办。

98% 时间装瞎，一半计划烂尾

除了爱好「核平」之外，Wilkinson 还从 23 场对局里挖出了的两个细节。

第一个数字：1-2%。

这是 AI 在整场游戏中，主动检查全局状态的行为占比。

AI 每回合要执行很多操作：造建筑、移动单位、研究科技、外交谈判。但在所有这些操作里，主动去看一眼排行榜、检查对手胜利进度、扫一圈全局局势的动作，只占 1-2%。

Wilkinson 给这个现象起了个名字：sensorium effect，感知盲区效应。AI 只能通过主动调用工具来感知世界。它不查的东西，对它来说不存在。

韩国那局是最好的例子。AI 玩韩国 —— 科技文明，天生科技加成。它在日记里全程自信：「我在碾压科技树。」

实际呢？它的科技产出每回合 44.7，在所有文明里排倒数第一。马其顿 89.3，波斯 64.9。

但它从来没查过排名。它的自信建立在一个从未验证过的假设上。第 178 回合，波斯突袭。首都沦陷。第 216 回合，AI 以两城残国投降。从头到尾，它都不知道自己是最弱的那个。

第二个数字：48-66%。

这是 AI 写下计划后，在 10 回合内实际执行的比例。

Claude Opus 4.6 最低，48.2%—— 还不到一半。写了计划，转头就忘。

GPT-5.4 好一点，63.2%。

Gemini 3.1 Pro 最高，65.8%。最好的模型也有三分之一的计划烂在了日记本里。

Wilkinson 管这叫 knowing-doing gap，知行差距。

你让它写一份治国纲领，它能写得比很多人类政客漂亮。你让它按自己的纲领治国，活不过两周。

Scaling Law 的盲区

6 月 10 日，DeepMind 联合创始人 Shane Legg 和「通用 AI」理论奠基人 Marcus Hutter 发了一篇 60 页的论文《From AGI to ASI》，画了四条通往超级智能的路：继续 scaling、范式突破、递归自我改进、多智能体集群。

四条路都建立在一个假设上：瓶颈在大脑。数据墙、算力墙、范式墙 —— 都是「怎么让 AI 更聪明」的问题。

但 CivBench 这 23 场对局指向一个完全不同的瓶颈。

99.26 分已经证明了智力不是瓶颈。但 23 场《文明 VI》打完，所有模型都撞上了同样两堵墙 —— 和「聪不聪明」无关的两堵墙。

第一堵：感知是架构问题，不是智力问题。

AI 只能通过主动调用工具来获取信息，不查就不存在。把模型参数翻十倍，它也不会自动变得更爱检查全局。1-2% 的感知盲区不会因为模型更大而消失。

第二堵：执行是工程问题，不是能力问题。

AI 写计划的水平远超执行计划的水平。48-66% 的执行率不是因为「想不到」，而是因为「做不到」。一个更聪明的大脑，装在一双不听使唤的手上，治不了国。

通向超级智能的路，也许不是一条单纯往上爬的智力曲线。在「更聪明」之前，有一个看起来更低级但也更致命的工程问题要先解决：怎么让 AI 真正睁开眼、伸出手。Scaling law 解决的是大脑。但 CivBench 暴露的问题，在大脑之外。

参考资料：

https://www.lwilko.com/blog/i-gave-an-ai-a-civilization

https://news.ycombinator.com/item?id=48623159

本文来自微信公众号：新智元（ID：AI_era），作者：ASI 启示录 ASI 启示录

第22期“人工制品”：Zyphra、Cohere和Poolside正拓展生态系统的广度

对开放生态系统及模型发布背后动机的评估

弗洛里安·布兰德与内森·兰伯特

2026年6月28日

∙ 付费内容

我们在开放模型发布中持续观察到的一个趋势是：生态系统正变得更加多元化，越来越多的组织发布了种类繁多的模型。一年前，开放“人工制品”以及更广泛的开放模型领域还被少数（中国）玩家主导。如今这一格局已经改变，我们越来越多地报道世界各地更加细分的公司。

虽然很难确切了解这些公司自身的动机，但我们可以大致观察到以下几类：

“纯”模型制造商：这些公司的公开目标是在前沿（或至少接近前沿）训练模型。这包括许多中国公司，如DeepSeek、智谱和MiniMax，也包括西方公司如Poolside、Arcee和Zyphra。此外，主权AI玩家也越来越多，例如Cohere、Sovereign、Mistral和Trillion Labs。最近的Mythos事件唤醒了一些政策制定者，这可能会使人们对主权模型训练的兴趣增加。

大型科技公司：对于大型科技公司（包括阿里巴巴的通义千问、谷歌的Gemma，以及在某种程度上英伟达）而言，动机更加多样。阿里巴巴通过发布模型来推销其闭源模型，而英伟达则受益于蓬勃发展的开放模型生态，因为这增加了对其GPU的兴趣和使用。这种既得利益不同于Llama时代的西方开放模型——当时开放发布的动机并不明确（最终也未能持续）。

产品公司：有些公司（如JetBrains、Zed、Krea和Photoroom）主要销售以AI为核心组件的产品。由于它们不希望被切断访问闭源模型的途径，或者希望提供独特的功能，它们可以训练高度专业化的小型模型来满足产品需求。因此，将这些模型权重开源并不会损害它们的利润底线。

这种制造者和模型的多样性符合我们的假设，即会有更多公司开发长尾模型，而追逐绝对开放前沿的公司数量将会减少。

尽管并非每个模型发布都能 neatly 归入这些类别之一，但更广泛的观点是，开放模型的开发并非由单一类型的参与者或动机驱动。这种多样性是开放生态系统的优势之一，并且可以从模型发布的技术报告中看出，这些报告复用了其他开放模型发布中的训练方法、架构选择和数据。

试图放缓或禁止这一生态系统的努力不仅是徒劳的（正如技术相关禁令的历史所显示的那样），而且是不安全且反自由的。此类限制会将 AI 开发和使用集中在少数人手中，最终危及局外人自由采用我们这一代最重要的技术之一的能力。

我们的推荐

NVIDIA-Nemotron-3-Ultra-550B-A55B-BF16 by nvidia：Nemotron 系列的大版本，使用 LatentMoE 使其比同类模型更快。与其他 Nemotron 模型一样，绝大多数数据都是开源的。而且，最重要的是：NVIDIA 承诺使用 OpenMDW 许可证，该许可证专门针对模型权重（及数据）而定，并放弃了其自定义许可证。虽然 MIT 和 Apache 与 OpenMDW 精神相同，但只有后者真正涵盖了模型权重，而前者是软件许可证，并不真正适用于模型权重。

command-a-plus-05-2026-bf16 by CohereLabs：Cohere（近来越来越频繁地出现在 Artifacts 中）发布了其旗舰模型 Command A+，采用 Apache 2.0 许可证。该系列之前的版本是在非商业许可证下发布的，因此这一变化非常受欢迎！Command A+ 以 218B-A25B MoE 的架构结合了多模态、多语言和智能体能力，使其可以在单个 B200 上使用（使用 4-bit 时）。

来自 zai-org 的 GLM-5.2：本期 Artifacts 中最重磅的消息是 GLM-5.2，我们在另一篇博客中也已报道过。这个模型持续让人印象深刻，确实可用于日常工作；与当前最优秀的闭源模型相比，并没有明显的倒退。有趣的是，自发布以来的原始下载量与其他模型发布的数据更趋一致，GLM-5.2 在发布后大致与 GLM-5 处于同一水平。

来自 Zyphra 的 ZAYA1-74B-preview：Zyphra 使用 AMD GPU 进行训练，因其技术报告中采用了有趣的架构选择，在研究社区中被视为某种内部消息来源。他们发布了一些新模型，其中 74B-A4B MoE 和 8B-A0.6B MoE（有技术报告）是其当前旗舰版本。

来自 poolside 的 Laguna-M.1：我们在上一期 Artifacts 中报道过的 Poolside，也在 Apache 2.0 许可下发布了他们的旗舰模型！他们还承诺未来将继续进行开放发布：

开放权重现在是我们的默认选项。我们将继续朝着前沿方向努力，并公开发布越来越强大的模型。

模型

通用目的

来自 moonshotai 的 Kimi-K2.7-Code：这是 Kimi 的一次更新，重点专注在模型 token 效率上。

来自 stepfun-ai 的 Step-3.7-Flash：这是 Step-Flash 的更新版本，尤其在数学方面非常强大。

来自 nvidia 的 Nemotron-Labs-Diffusion-14B：这是一个实验性模型，可以通过三种不同模式使用：自回归、扩散和自推测。每种模式适用于不同的使用场景。

本文为付费订阅专享

已经是付费订阅用户？

IT之家 6 月 27 日消息，阿里旗下千问输入法 macOS 版今日已上线官网，官方预告 iOS 版、Android 版、Windows 版将于近日发布。

官网显示，该产品号称“说完即成稿”，支持最快 300 字 / 分，AI 自动润色，说话秒变工整文字。支持 9 种方言，纯净无广告。

此前有消息称，千问团队将推出名为“千问输入法”的独立 App，与 PC 端的千问语音输入法有一定区别，AI 功能、键盘会更贴合手机端操作，填补千问在移动端 AI 输入法赛道的空白。

IT之家查询发现，这并不是千问第一次尝试进入输入法领域。千问官网显示，千问语音输入法是阿里千问今年 5 月上线的 AI 语音输入能力，当时并不是一个独立的输入法，而是千问 App 中的一个组件，支持对口语内容去语气词、纠错、格式化整理等，能够基于上下文智能回复，还可直接下达创作、问答、翻译等指令。

广告本地化现已成为 Runway API 中的一个 Recipe。

现在您只需一次 API 调用，即可翻译静态广告和图形资产。

[引用 @runwayml]：Runway 新增功能，您现在可以本地化广告。

输入一张图片，输出任意语言。只需输入一条广告，即可获得面向每个市场的版本。一切只需一键操作。

### 引用推文

> Runway：New in Runway, you can now localize ads. One image in, any language out. Input a single ad and get a version for every market. All with a single click.

新闻：SpaceX 刚刚为“SpaceXAI”注册了商标。

埃隆·马斯克表示 xAI 将不再作为独立公司存在，而是直接并入 SpaceX，成为 SpaceX 旗下的 AI 产品 SpaceXAI。

[引用 @xdNiBoR]：SpaceX 刚刚注册了 SPACEXAI 商标！

### 引用推文

> Robin：SpaceX just trademarked SPACEXAI!

刚刚！苹果VisionPro 眼镜负责大神跳槽OpenAI！AI 硬件大战，库克最担心的事儿发生了！

Apple 这几天也是亏麻了！

宣布涨价以来，市值直接蒸发2300 多e美金！

2026年6月26日，Mark Gurman在一天内发了两条关于苹果的重大新闻。

第一条更重磅。

Paul Meade，苹果Vision产品组的副总裁，下周离开苹果，加入OpenAI的硬件部门。

这个人的职责范围不只是Vision Pro头显。

他负责苹果所有智能眼镜的开发，包括计划明年发布的无屏幕AI智能眼镜，以及本十年末的增强现实眼镜路线图。

他还掌管苹果一系列其他AI可穿戴设备的研发。

他的团队叫VPG，Vision Products Group。是苹果空间计算和AI硬件战略的核心执行层。

他不是唯一一个。

苹果在过去一年经历了多起高管向竞争对手流失的事件。但这次不同。

Paul Meade去的不是Meta，不是Google，是OpenAI。

OpenAI正在组建自己的硬件团队。

他们已经在开发AI驱动的设备家族。根据郭明錤的分析，OpenAI甚至在计划一款智能手机，采用联发科天玑9600定制版芯片，由立讯精密代工。目标直指iPhone。

这意味着什么？

OpenAI不再满足于做软件。

他们要进入硬件。而他们挖走的人，恰好是苹果硬件战略中最前沿的那个板块的负责人。

苹果在Vision和智能眼镜上的投入，数十亿美元的研发、数年的工程积累，现在为竞争对手提供了核心人才。

第二条新闻关于MacBook。

苹果计划在首款触控OLED高端MacBook上使用现有的M5 Pro和M5 Max芯片。

不是新的M6系列。直接跳到M7 Pro和M7 Max，最早2027年底发布。

这个决策透露了一个信号。苹果不想等。触控OLED MacBook是用户等了好几年的产品，苹果选择用现有芯片加速上市，而不是为了一代新芯片推迟发布。

M6系列只会有基础版M6，没有Pro和Max。苹果把高端触控OLED的赌注押在了M7上。

2026年底到2027年初，你会看到第一款触控OLED MacBook Pro。

M5 Pro/Max驱动。保留键盘和触控板。屏幕支持触控操作。

2027年底，M7 Pro/Max版本跟进。那才是真正完整的下一代。

同一天。一边是苹果最重要的硬件高管跳槽到OpenAI。

一边是苹果用现有芯片赶工触控OLED MacBook。

两件事指向同一个趋势：AI硬件的竞争已经不是未来时了。

它正在发生，而且正在加速。

IT之家 6 月 27 日消息，今日，国家统计局工业司首席统计师于卫宁解读 2026 年 1—5 月份工业企业利润数据，IT之家整理主要内容如下：

工业企业利润保持较快增长。1—5 月份，工业生产较快增长叠加工业品价格涨幅扩大，推动全国规模以上工业企业营业收入同比增长 5.5%，较 1—4 月份加快 0.3 个百分点。规模以上工业企业营收稳定增长，带动全国规模以上工业企业利润同比增长 18.8%，较 1—4 月份加快 0.6 个百分点，规模以上工业企业利润自今年以来保持较快增长态势。从三大门类看，采矿业增长 33.5%，较 1—4 月份加快 7.5 个百分点；制造业增长 20.0%，电力、热力、燃气及水生产和供应业下降 2.7%。5 月份，全国规模以上工业企业利润同比增长 21.1%。

电子行业支撑作用明显。1—5 月份，规模以上装备制造业利润同比增长 14.1%，拉动全部规模以上工业企业利润增长 5.2 个百分点。从行业看，全球人工智能技术变革带来高端算力芯片和存储芯片需求爆发，推动电子行业利润高速增长，1—5 月份，电子行业利润增长 103.9%，对全部规模以上工业企业利润增长的贡献率达 43.1%，是规模以上工业企业利润较快增长的重要支撑。

原材料制造业利润快速增长。1—5 月份，规模以上原材料制造业利润同比增长 83.1%，拉动全部规模以上工业企业利润增长 10.2 个百分点。从行业看，受新能源、人工智能等新兴产业需求增加带动，铜、铝等产品价格维持在较高水平，推动有色行业利润增长 117.1%，拉动全部规模以上工业企业利润增长 5.3 个百分点；在石油产业链条相关产品价格上涨推动下，石油加工行业同比扭亏为盈，化工行业利润增长 71.6%。

高技术制造业利润保持两位数增长。1—5 月份，规模以上高技术制造业利润同比增长 44.7%，拉动全部规模以上工业企业利润增长 8.0 个百分点，引领作用持续凸显。从行业看，半导体产业链条行业发展向好，电子器件制造方面，光电子器件制造、半导体分立器件制造行业利润分别增长 53.8%、40.6%；电子元件及电子专用材料制造方面，电子专用材料制造、电子电路制造行业利润分别增长 665.4%、19.7%。医疗设备器材相关行业利润增长较快，口腔科用设备及器具制造、卫生材料及医药用品制造行业利润分别增长 26.4%、23.2%。

工业企业单位成本下降，盈利能力持续改善。1—5 月份，规模以上工业企业每百元营业收入中的成本为 84.95 元，同比下降 0.59 元，工业企业累计单位成本今年以来连续五个月下降。1—5 月份，规模以上工业企业营业收入利润率为 5.56%，同比提高 0.63 个百分点，营收利润率达 2024 年以来各月累计最高水平。

文章指出，总体看，1—5 月份规模以上工业企业利润继续保持较快增长态势。但也要看到，国内供强需弱矛盾依然突出，部分行业企业生产经营还比较困难。

最有可能用自动化取代你工作的那些公司，现在正资助一项 10 亿美元的计划来对你进行再培训。

托米斯拉夫·贝兹马利诺维奇

Jun 27, 2026

Nano Banana Pro 由 THE DECODER 提供提示

关键要点

美国前商务部长吉娜·雷蒙多创立了一个名为“Raise Us”的无党派组织，旨在帮助美国劳动者为人工智能驱动的经济做好准备。

目标：为再培训和继续教育项目筹集 10 亿美元。目前已确保筹集到其中一半的资金。

大型科技公司正在支持这一努力。亚马逊、Anthropic、微软和 OpenAI 都是支持者，这引发了关于其独立性的明显问题，因为这些公司正是从人工智能广泛普及中受益最大的企业。

美国前商务部长吉娜·雷蒙多和前印第安纳州州长埃里克·霍尔科姆共同发起了“Raise Us”，这是一个由二十多家大型企业和四位州长支持的两党非营利组织。

该组织旨在筹集 10 亿美元，以帮助美国劳动者为人工智能驱动的经济做好准备。雷蒙多将担任首席执行官。作为参照，谷歌、亚马逊、微软和 Meta 今年计划在人工智能上总共花费 7250 亿美元。

“美国在引领全球人工智能竞争方面有一套技术战略，但还没有一套人才战略——没有人才战略，我们就无法领先，”雷蒙多在启动会上表示。“如果我们建造出世界上最好的人工智能系统，却让数百万美国人掉队，那我们什么也没赢到；我们只是把自己的衰落自动化了。”

该组织计划为企业再培训和留任创造新的激励措施，与各州州长共同启动试点项目，并根据雇主不断变化的需求调整培训模式。衡量成功的标准是劳动者能否获得并保住稳定且收入可观的工作。

人工智能领域的竞争对手首次共同资助一项劳动力计划

Raise Us 引人注目之处在于谁在为其买单。根据公告，亚马逊、Anthropic、微软和 OpenAI 基金会都在支持这项计划。雷蒙多表示，这是领先的人工智能开发者首次共同资助一项独立的计划来支持劳动力转型。美国银行是主要赞助商，资助了一个面向先进制造业的学徒项目。

其他支持者包括 ADP、AMD、Autodesk、黑石、思科、Cognizant、德勤、礼来、通用汽车、IBM、万事达卡、ServiceNow、UPS 和 Workday。在公益方面则有：洛克菲勒基金会、Arnold Ventures、Pritzker Traubert 基金会和 Stephen A. Schwarzman 基金会。Raise Us 的目标是筹集10亿美元的多年期承诺捐款。据《纽约时报》报道，目前已锁定5亿美元。

这种资金结构自然会引发关于独立性的疑问。参与的许多公司要么直接从人工智能的快速普及中获利，要么正在积极推动这一进程。Raise Us 本应为人工智能可能导致的失业问题开发解决方案，但其资金主要来源于那些正是引发这一冲击的公司。

试点项目在四个州启动

Raise Us 首先在阿肯色州、康涅狄格州、马里兰州和犹他州建立合作伙伴关系。选择这些州有意体现了跨党派特色：州长包括 Sarah Huckabee Sanders（共和党，阿肯色州）和 Spencer Cox（共和党，犹他州），以及 Ned Lamont（民主党，康涅狄格州）和 Wes Moore（民主党，马里兰州）。

这些试点项目重点在于促进职业转型，帮助人们了解哪些岗位仍有需求、这些工作需要哪些技能，以及如何转入这些岗位。在阿肯色州，Raise Us 正在支持一个名为 Arkansas LAUNCH 的人工智能驱动的职业导航平台，该平台将学生和求职者与个性化学习路径以及与企业关联的职业轨道路径连接起来。

据《纽约时报》报道，在马里兰州，该州面向高中应届毕业生的 Service Year 项目将扩展到医疗保健等面临劳动力短缺的行业。该组织还计划在当地设立一个面向创新职业转型模式的竞争性资金池，并设立一个加速器项目，帮助失业人员自主创业。

据《纽约时报》报道，在其他州，Raise Us 希望为那些接受低薪工作而非完全退出劳动力队伍的劳动者提供"工资保险"。

该组织的工作围绕四大支柱展开

Raise Us 分为四个领域。“州级合作伙伴关系”旨在通过学徒制和短期证书等方式，使州教育与劳动力项目更紧密地对接雇主需求。公共资金将更多地取决于参与者是否实际找到工作，而不仅仅是入学人数。

“雇主联盟”汇集了使用人工智能的企业，共同开发再培训和留任的试点项目。据《纽约时报》报道，微软已经测试了一种模式：该公司培训跨部门的初级法律人员，并教授他们AI技能，以便他们能在技术变革时更容易地转向新岗位。“几乎我们所有的岗位都可以这样做，”微软副董事长布拉德·史密斯表示。

“教育与培训”旨在推广AI驱动的培训模式，将实践经验与证书相结合，并提供比传统大学更便宜的替代方案。“政策实验室”将开发和测试新的政策方法。该实验室明确不接受企业资金。

再培训仍然是难点

在美国，对失业人员进行再培训的效果参差不齐。据《纽约时报》报道，雷蒙多本人称过去的努力“成效甚微”。自1973年通过以来，国会一直在逐步削减其主要劳动力发展法案的资金。计划的改革也毫无进展。

Raise Us 是否会比以往的再培训项目取得更好的效果，仍有待观察。但这一倡议出台之际，美国正将大量资金投入AI基础设施和模型，却仍未对工人如何应对未来的结构性变革给出可靠答案。

还有一个更基本的问题：AI究竟会以多快的速度、多深程度地重塑劳动力市场。虽然AI可以加速特定任务，但关于更广泛生产力提升的研究尚无定论。目前还没有明确证据表明AI正以引发大规模失业的方式推动整体经济增长。

去伪存真的AI新闻——由人类精选

订阅《THE DECODER》即可享受无广告阅读、每周AI新闻简报、每年六期的独家“AI雷达”前沿报告、全部存档资料以及评论区的访问权限。

来源：洛克菲勒基金会《纽约时报》

IT之家 6 月 27 日消息，CNBC 昨日（6 月 26 日）发布博文，报道称在 AI 账单失控背景下，越来越多的美国企业转向 Tokenminimizing，追求使用更少的 Token 完成同等复杂度的任务。

该媒体从 Lindy 公司视角切入，并采访了多位分析师，洞察美国企业在 AI 支出方面的变化。

Lindy 是一支拥有约 25 人的公司，总部位于旧金山，此前主要调用 Anthropic 的 Claude 模型，该公司 CEO 弗洛 · 克里维洛（Flo Crivello）诉苦称每月 AI 账单严重超支，甚至超出了所有员工的工资支出。

他表示本月初已将 100% 流量切换到 DeepSeek，并称这项决定在未来几个月能给公司省下数百万美元。

克里维洛表示：“别小看 AI 账单，这关乎企业的生死存亡。你现在来瞧瞧我们的 AI 成本曲线，简直是断崖式下跌”。

克里维洛此前曾在 Uber 工作 5 年，他表示老东家目前也在严苛限制 AI 调用，本月为部分 AI 工具设定了分级支出上限，基础档为每月 1500 美元（IT之家注：现汇率约合 10211 元人民币）。

在失控领域方面，CNBC 采访了多名咨询公司以及企业管理员，指出 AI 支出最先失控的是辅助编程，开发者消耗大量的 Tokens，投入到新工具和新服务开发上。

而现在企业已严苛限制场景使用，企业开始转向按任务匹配模型的“模型路由”（model routing），不再把最贵的前沿模型用于所有场景。

面对失控的 AI 账单，咨询公司 Highspring 的 Jeff Henry 说，一些客户决定先暂停投入，等能证明投资回报率后再决定。

DeepSeek 发布了 DSpark，一个投机解码框架，并开源了检查点和训练代码。这是一项服务优化，而非新模型。检查点 DeepSeek-V4-Pro-DSpark 和 DeepSeek-V4-Flash-DSpark 复用了现有的 V4 权重，并附加了一个草稿模块。

DeepSeek 研究团队还开源了 DeepSpec，一个采用 MIT 许可证的代码库，用于训练和评估投机解码草稿模块。这项工作瞄准一个问题：在繁忙的生产服务中实现更快的大模型推理。

摘要

DSpark 将并行草稿主干与一个极小的顺序头配对，以减少后缀衰减。

一个置信度头和负载感知调度器在 GPU 空闲时验证更多 token，在繁忙时验证更少。

离线场景下，接受长度相比 Eagle3 提升 26–31%，相比 DFlash 提升 16–18%。

在 DeepSeek-V4 的生产环境中，每用户生成速度比 MTP-1 基线快 60–85%。

输出保持无损，检查点及 DeepSpec 训练代码均已开源。

什么是 DSpark？

投机解码将生成拆分为两个角色。一个小型的草稿模型提议一个 token 块。完整的目标模型随后在一次前向传播中验证该块。

拒绝采样接受最长的有效前缀，并附加一个额外的 token。由于该规则精确保持目标分布，因此不存在质量损失。DSpark 保留了这一保证。它改变了 token 的草稿方式以及验证的数量。

它优化的延迟公式

每个 token 的延迟遵循论文中的一个公式：L = (Tdraft + Tverify) / τ。这里 τ 是每轮接受的 token 数量。加速仅来自三个杠杆。

你可以更快地草稿，从而降低 Tdraft。你可以更好地草稿，从而提高 τ。或者你可以更智能地验证，减少浪费的 Tverify。DSpark 同时拉动全部三个杠杆。

工作原理：半自回归生成

先前的草稿模块强制进行权衡。像 Eagle3 这样的自回归草稿模块使每个 token 依赖于先前的 token。这提供了很强的接受率，但草稿成本随块大小增长。

像 DFlash 这样的并行草稿模块一次生成整个块。草稿成本低廉，但每个位置忽略其邻居。结果是“多模态冲突”和沿着后缀的快速接受衰减。

DSpark将草稿生成分为两个阶段。其设置中的DFlash是一个重型并行主干，为每个位置生成基础logits。然后，一个轻量级的顺序头部在采样每个token之前添加一个依赖于前缀的偏置。

默认的顺序头部是马尔可夫头部。它只查看紧邻的前一个token。低秩分解（秩为256）使其即使在词汇量大的情况下也保持低成本。

一旦位置一采样到 'of'，头部就会提升 'course' 并抑制 'problem'。一个可选的RNN头部会跟踪整个块的前缀。它带来的收益微乎其微，因此默认采用马尔可夫头部。

收益逐位置显现。DSpark继承了并行主干的高首token准确率。然后顺序头部使得接受率在块深处保持稳定。

训练冻结目标模型并复用其嵌入和输出头部。总变差损失是关键项。最小化该距离直接最大化草稿的接受率。

工作原理：置信度调度验证

更多的草稿token并不总是意味着更快的速度。在重负载下，验证将被拒绝的token会浪费批处理容量。DSpark添加了两个部分来解决这个问题。

一个置信度头部为每个草稿位置输出一个分数。该分数估计在给定已接受的前驱token的情况下，该token通过验证的概率。它由解析的每步接受率进行监督。

原始的神经网络置信度通常过于自信。因此研究团队应用了顺序温度缩放，这是一种事后校准步骤。它将期望校准误差从3–8%降低到大约1%。

然后，一个硬件感知的前缀调度器为每个请求设置验证长度。它使用在启动时测量一次的剖析吞吐曲线SPS(B)。当GPU空闲时，它验证更多的token。当GPU繁忙时，它验证更少的token。

调度器使用提前停止规则以保持无损。附录部分给出了一个反例，说明为什么朴素的全局搜索会泄露信息。

指标

离线测试涵盖数学、代码和日常聊天。目标包括Qwen3-4B、8B、14B和Gemma4-12B。DSpark在每一个领域上的接受长度均优于两个基线。

在 Eagle3 上，三种 Qwen3 尺寸版本的平均接受长度分别提升 30.9%、26.7% 和 30.0%。在 DFlash 上，提升幅度分别为 16.3%、18.4% 和 18.3%。仅两层 DSpark 即可超越五层 DFlash。

顺序头带来的额外成本极低。将草稿长度从 4 扩展到 16，每轮延迟仅增加 0.2%–1.3%。作为回报，接受长度提升最高达 30%。

生产环境结果来自 DeepSeek-V4-Flash 和 V4-Pro 在真实流量下的表现。基线为 MTP-1（之前的单 token 方案）。在相同吞吐量下，Flash 版每用户速度提升 60–85%，Pro 版提升 57–78%。已上线配置为 DSpark-5，即一个包含马尔可夫头的五 token 草稿块。

草稿模型草稿生成方式块计算成本后缀接受率验证长度

Eagle3自回归随块大小增长高且稳定固定

DFlash并行近似恒定快速衰减固定（完整块）

MTP-1单 token（MTP）低—静态 2 token

DSpark并行 + 顺序头近似恒定高且稳定动态、负载感知

用例及示例

结构化任务从更长的验证中获益最多。在代码生成中，接受率天然较高。调度器可以验证较长的前缀而几乎没有浪费，因此编码智能体能够更快地输出结果。

开放式对话的表现则不同。通过置信度阈值扫描，对话接受率从 45.7% 提升至 95.7%。置信度头会标记不确定的后缀 token，以便将其裁剪。

数学推理介于两者之间。在相同的扫描中，其接受率从 76.9% 提升至 92.5%。长流程的逐步推理轨迹受益于稳定的深层块接受率。

高并发服务是主要应用场景。在中等负载下，调度器每个请求大约验证 4–6 个 token。随着并发度上升，它会缩减该预算以保障吞吐量。

尝试使用

DeepSpec 运行分为三个阶段：数据准备、训练，然后评估。配置文件用于选择算法和目标模型。评估在九个数据集上对训练好的草稿检查点进行基准测试。

复制代码已复制请使用其他浏览器

# Install dependencies

python -m pip install -r requirements.txt

# Train a DSpark draft against a Qwen3-4B target.

# The algorithm and target are chosen by the config, e.g.

# config/dspark/dspark_qwen3_4b.py

bash scripts/train/train.sh

# Evaluate the trained draft across the 9 benchmark datasets.

# Set in the eval config:

# target_name_or_path = Qwen/Qwen3-4B

# draft_name_or_path = ~/checkpoints/deepspec/dspark_block8_qwen3_4b/step_latest

bash scripts/eval/eval.sh

默认配置假设单节点配备 8 块 GPU。减少 CUDA_VISIBLE_DEVICES 可适配更少 GPU。请注意，目标缓存可能很大，Qwen3-4B 设置下接近 38 TB。

对于生产检查点，草稿模块会附着在现有的 V4 权重上。Hugging Face 模型卡在 inference 文件夹中提供了一个最小推理示例。无需对目标模型进行重新训练。

下方的交互式演示展示了这一机制。选择一个起草器、一个领域以及一个 GPU 负载级别。观察草稿块、置信度分数以及调度器的验证预算如何实时变化。这些数字仅作示意，基于论文中报告的行为建模。