Fireworks 在 The frontier isn’t a model. It’s a router. 开头摆了三个数字：最好的单模型 GPT-6 Astra 在 DeepSWE 的智能体编码任务上通过 74.1%，每任务花 6.52 美元；同样这十八个模型，如果每个任务都挑最合适的那个来做，通过率是 97.6%，每任务 1.88 美元。
高 23 个百分点，花费不到三分之一。
这个数字来自后见之明——先把十八个模型在每一个任务上都跑一遍，再回头给每个任务点名赢家。它测量的是已经躺在模型池里的能力，只不过这份能力被分散在平时没人会放在一起用的模型之间。
把这十八个模型用起来，是路由器的工作。它必须在活干完之前决定谁来干，而「之前」才是难点。回头看，指着一个任务说出哪个模型会做得更好很容易；路由器得在看到结果之前选，选错的代价远大于省下的那几美元。
先说清楚：Fireworks 自己卖 FireRouter。这篇文章的数据是他们的，下面我会在能核对的地方和公开数据对照。
这组数字是怎么算出来的
先看方法，因为方法决定了这个 97.6% 该被读成什么。
基准是 DeepSWE v1.1，一个智能体编码基准，工作单位是一次工程任务：智能体要读懂 issue、翻仓库、用工具、改代码、跑起来，最后让任务通过。
策略被刻意简化：任务开始时挑一个模型，整个任务都用它，中途不切换。 然后用实测通过率给每个任务点名赢家，平局按成本低者胜。这就是 oracle router，和他们在 Kimi K3、Fable 分析里用的是同一套方法。
三个细节决定了这个数字的上限偏高：
| 偏差来源 | 具体做法 | 影响 |
|---|---|---|
| 选择集与评分集相同 | oracle 在它挑赢家的同一批 113 个任务上计分 | 相当于在测试集上挑最优，向上偏 |
| 取最大值 | 每个模型-任务对跑 4 次 rollout，取最好的一次 | 18 个噪声估计取 max，向上偏 |
| 成本口径经过缩放 | 公开 trials 文件里的 cost_usd 与榜单显示值不一致，DeepSeek 家族差了好几倍，于是按模型把每任务成本缩放到均值与榜单一致 | 成本是重建值，不是原始计费值 |
前两条 Fireworks 自己在文里写明了，第三条写在文末的注释里。愿意写出来是加分项，但读者要清楚：97.6% 是「这批任务上的能力天花板」，不是「你能拿到的通过率」。
他们还顺手挡掉了一个更漂亮的数字：全程用 pass@1，也就是单次尝试通过的概率，而不是「四次里成功过一次就算过」。后者会让上限好看得多，同时意义小得多。
能力在池子里，只是分散
同一批数据里，固定用一个模型的最好成绩是这样的：
| 模型 | 通过率 | 每任务成本 |
|---|---|---|
| GPT-6 Astra | 74.1% | $6.52 |
| Claude Opus 5 | 73.8% | $11.84 |
| GPT-5.6 Sol | 72.6% | $6.46 |
| Claude Fable 5 | 69.9% | $13.41 |
然后是按任务挑：
| 策略 | 通过率 | 每任务成本 |
|---|---|---|
| 最好的单模型（GPT-6 Astra） | 74.1% | $6.52 |
| oracle 路由（全部 18 个模型） | 97.6% | $1.88 |
| oracle 路由（仅开放权重子集） | 90.3% | $1.45 |
开放权重子集指的是 DeepSeek V4 Flash 与 Pro、GLM-5.3 与 GLM-5.3 Flash、Kimi K3、Qwen3.8 Max。这个子集单独拿出来，比这里任何一个闭源模型高 16 个百分点，花的钱不到 Astra 的四分之一。
于是 Fireworks 提出了一个我认为值得记住的框架转换：当不同模型真的互补时，在它们之间做选择是沿着能力曲线往上走，而不只是沿着成本曲线往左走。 大多数团队引入路由的动机是省钱——把简单的活派给便宜模型，贵的留给难的。如果能力确实互补，那省钱的副产品是更高的通过率，而不是拿通过率换钱。
贵模型很少是唯一解
这部分是全文最实的内容。在 97.6% 那个点上，oracle 把 113 个任务中的 94 个派给了成本低于 3 美元的模型。
现场最贵的那三个模型（每任务都在 11.50 美元以上）加起来，只在三个任务上是唯一的最佳选择。而在 113 个任务中的 79 个上，至少有一个贵模型能打平最高分，只是输在价格。
这组数字指向一个容易被忽视的事实：一个强通用模型可以在一大片分布上都很优秀，同时在大多数单个任务上并不唯一必要。固定用一个模型的策略，是在每个任务上都为「广度」付钱。
一个系统可以问一个更窄的问题：这个任务真正需要的是什么能力？
一份外部对照：公开榜上还有别的行
我对着 DeepSWE v1.1 官方榜单核对了那四个单模型数字，全部对得上（Astra 74%、Opus 5 74%、Sol 73%、Fable 5 70%）。但榜单上还有几行没被 Fireworks 提到：
| 模型 | 通过率 | 每任务成本 |
|---|---|---|
| Gemini 3.8 Flash | 74% ±1% | $2.36 |
| GPT-5.6 Luna | 67% ±4% | $0.61 |
| GLM-5.3 Flash | 63% ±4% | $0.24 |
Gemini 3.8 Flash 的通过率和 Astra 持平，成本是它的 36%。这条行如果成立，Fireworks 那句「最好的模型大约 70%，每任务花 6.46 到 13.41 美元」就只是他们那 18 个模型池内部的事实，不是市场事实。
需要说清楚的是，Fireworks 没有说明这些行是否在自己的池子里——他们只点名了 4 个闭源模型和 6 个开放权重模型，另外 8 个没有列出来。所以这里不是指控，而是一个读者必须自己补上的检查：当一篇厂商文章说「最强的单模型要 6.52 美元」时，先去公开榜上看有没有更便宜的同分模型。 如果有，那么「你必须路由」的论证就更依赖路由带来的增量，而不是单模型基线有多贵。
要几个模型才够
覆盖率阶梯给出了一个很实用的答案：
- 最佳的两模型组合比最佳单模型高 13.1 个百分点。
- 最佳的三模型组合达到 91.2%。
- 从三个扩到全部十八个，再加 6.4 个百分点。
也就是说，超过一半的收益来自头两三个模型，最后十五个模型贡献剩下的 6.4 个点。Fireworks 的结论是：有用的对象不是几百个几乎可互换的模型目录，而是一个覆盖互补的组合——价值在能力覆盖，不在模型数量。
这不是他们自说自话。LLMRouterBench这篇论文（ACL 2026 Findings）用了 21 个数据集、超过 40 万个实例、33 个模型做统一评测，结论包括：模型互补性确实存在（这是路由的前提），但更大的集成相对收益递减，仔细挑选模型比堆数量重要。两边在这一点上是一致的。
难的是开工前就选对
oracle 之所以讨人喜欢，是因为它永远不会选错。生产环境里的路由器会。
Fireworks 引用了 LLMRouterBench 的两个发现，我认为它们是这篇文章里最该被单独拿出来的部分：
- 多种路由方法在统一评测下表现相近，包括商业路由器在内，若干近期方法无法稳定超过一个简单基线。
- 离 oracle 还差很远，主要原因是持续的 model recall 失败——即使池子里存在具备合适能力的模型，路由器也得先意识到该去够它。
第二条是整个路由叙事的技术核心。路由的失败很少是「选了一个不该选的」，更多是「压根没想到那个对的不在候选里」。
所以 Fireworks 说了一句反直觉但很诚实的话：坚持用一个你熟悉的模型不是保守，是理性的——一个稳定的误差分布，胜过一个会不可预测地挑错专家的路由器。路由系统要跨过的门槛，是让模型专长变得可预测到这种程度：换模型能提升系统，而不会让它的行为变得不可信。
这句话其实把整篇文章的标题往下拉了一格。「前沿是路由器」是方向，不是现状。
FireRouter 说了什么，没说什么
FireRouter 的定位是任务级路由，横跨开源和闭源模型，而且是缓存感知的——切换模型不会悄悄丢掉你已经付过钱的上下文。这一点值得单独拎出来，因为多模型路由的隐性成本常常不写在基准里：上下文重放、prompt 缓存失效、多轮会话的状态迁移，这些都会把省下的 token 钱吃回去一部分。
生产数据是：在他们自己四周的编码流量里，走 FireRouter 的会话花了 7.42 美元，而单独用 Opus 5 是 15.81 美元，2,334 个会话下降 53%。
这里有个缺口必须指出：这是一个纯粹的成本数字。 他们没有报告这些会话的通过率或任务完成率，而前文所有的能力论证都建立在通过率上。用便宜模型把成本砍掉一半，同时任务成功率下降，是完全可能的——而且这正好是文章前半部分警告过的失败模式。
这不是说数字有问题，而是说：成本结论和路由质量结论是两件事，这份生产数据只支持前者。 你自己做验证时，两个都要测，而且要先测质量。
文章最后那个框架反而是全文最有价值的部分。它说，AI 工作的有用单位早就不是一次模型调用了：一个编码智能体是「模型装在 harness 里」，harness 提供上下文、工具、执行、测试、状态和反馈。
一旦多个模型有了互补的长处，选择策略就变成和上下文、工具、测试并列的系统组件。挑选和组合这些组件，就是 AI 工程的工作。
落到你自己的系统上
如果把这篇厂商文章压成可执行的东西，我会留下这几条：
- 先测互补性，再谈路由。 在你的任务分布上，模型之间的胜负是否分散？如果同一个模型在几乎所有任务上都赢，那路由没有空间可挖。DeepSWE 上这件事成立，不代表在你的负载上成立。
- 从两三个模型开始。 头两个模型吃掉 13.1 个点，三个到 91.2%。用十八个模型的第一版路由，你得到的是十八倍的失败模式。
- 用 pass@1，不要用「试几次总有一次过」。 后者会在你自己的评测里复制 oracle 的向上偏差，让你高估池子的真实能力，也会让你低估生产环境和它之间的差距。
- 把 model recall 当作一号风险。 你的路由器最可能的失败不是选错，是没想到。给路由加可观测性：记录每次选择了谁、当时还有什么候选、事后看哪个才对。
- 把缓存和上下文重放算进成本。 一个没有缓存感知的路由器，省下的单价可能被重放吃掉。这是 FireRouter 唯一一个我认为定义得清楚的技术特性。
- 成本和质量分开验收。 先确认路由后的通过率不低于基线，再谈省了多少钱。
最后回到标题。Fireworks 说前沿不是模型而是路由器，我同意一半：方向是对的，池子里的能力确实远超任何一个模型暴露出来的部分；但 97.6% 是回看出来的天花板，而当前的路由方法连稳定超过简单基线都还没做到。前沿既不是模型也不是路由器，是让模型之间的差异变得可预测的那部分工程。
Aide Hub 会继续整理这类模型评测口径与工程取舍的拆解，覆盖 AI 助手、开发工具与软件工程实践。
参考
- The frontier isn’t a model. It’s a router.（原文，Fireworks AI）
- DeepSWE v1.1 官方榜单与说明（DataCurve）
- LLMRouterBench: A Massive Benchmark and Unified Framework for LLM Routing（Findings of ACL 2026）
- LLMRouterBench 代码与数据
- Fireworks AI 关于该分析的公告帖