Fireworks DeepSWE v1.1测试:路由模型组合超越单一大模型
Fireworks 在 DeepSWE v1.1 上做了 113 个任务 × 18 个模型 × 每组 4 次 rollout 的全量交叉测试,共 2034 个…
Agent开发必看,实测证明多模型路由能大幅降本增效,直接参考其配置与性能数据优化你的工作流。
Fireworks 在 DeepSWE v1.1 上做了 113 个任务 × 18 个模型 × 每组 4 次 rollout 的全量交叉测试,共 2034 个 “模型-任务” 单元,然后构造一个 oracle 路由器来考察 “完美路由” 的上界 https://fireworks.ai/blog/the-frontier-isnt-a-model-its-a-router
| 关键数字(配置 | 通过率 | 每任务成本): |
|---|---|---|
| 最佳单模型(GPT-6 Astra) | 74.1% | $6.52 |
| Oracle 路由(18 个模型) | 97.6% | $1.88 |
| Oracle 路由(仅开源权重模型) | 90.3% | $1.45 |
完美路由比最强单模型高 23 个百分点,成本却不到三分之一;甚至只用开源模型做路由,就能反超全部闭源模型 16 个百分点。
由此展开三个发现: 1. 极少任务真的需要最贵的模型。 113 个任务中 94 个的最优选择是单价低于 $3 的模型;三个 $11.50 以上的顶级模型,只在 3 个任务上是“唯一最优”。固定用一个大模型,本质是在为每一项任务支付“通用能力”的保险费,而多数任务只需要其中一小部分能力。
2. 路由池不需要很大。 最佳双模型组合就比最佳单模型高 13.1 个百分点,三模型组合达 91.2%,从 3 个扩到 18 个只再涨 6.4 个百分点。这与 LLMRouterBench(33 模型、40 万+实例)的结论互相印证:价值来自能力互补的覆盖度,不是模型数量;未经精选的大池子增益有限。
3. 真正的难题是“预测哪个模型合适”。 这是最值得理解的一段。在严格的 pass@1 口径下,多个近期的路由研究(包括商业方案)都无法稳定击败简单基线,瓶颈在“模型召回”,池子里明明有合适的模型,路由器却识别不出来。作者甚至承认:坚持用一个熟悉的模型是理性策略,因为稳定的错误分布好过一个会不可预测地选错专家的路由器。路由要成立,前提是模型的专业化差异足够可预测。
产品落点:FireRouter · 路由≠省钱工具:如果模型真正互补,路由是沿能力曲线上移,而不只是沿成本曲线左移(省成本只是副产品)。 · 缓存感知:agentic 工作流中切换模型最大的隐性成本是丢弃已积累的上下文;FireRouter 说明切换不损失已付费的上下文。生产数据:4 周 2334 个内部编码会话,成本 $7.42 vs. 单用 Opus 5 的 $15.81,降 53%。
更进一步:量化金融体系
看懂新闻只是起点——沿量化金融路径,把它变成能交付的工程能力