Fireworks 实测：完美路由通过率 97.6%，成本不到最佳单模型 1/3

Fireworks 在 DeepSWE v1.1 上做了 113 个任务 × 18 个模型 × 每组 4 次 rollout 的全量交叉测试，共 2034 个 “模型-任务” 单元，然后构造一个 or...

Fireworks 在 DeepSWE v1.1 上做了 113 个任务 × 18 个模型 × 每组 4 次 rollout 的全量交叉测试，共 2034 个 “模型-任务” 单元，然后构造一个 oracle 路由器来考察 “完美路由” 的上界 fireworks.ai/blog/the-front… 关键数字（配置 | 通过率 | 每任务成本）： 最佳单模型（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%。 Fireworks @FireworksAI_HQ We ran 18 models across 113 real coding tasks on DeepSWE, then went back and asked a simple question: what if every task had routed to the model that handled it best? Answer: 97.6% solve rate at $1.88 per task, versus the best model at 74.1% at $6.52. The next frontier is a router. Full analysis: fireworks.ai/blog/the-front… 🔗 View Quoted Tweet 💬 0 🔄 0 ❤️ 0 👀 397 ⚡