随机挑也赢过六款商业路由器：循环里的算力该花在哪一步 (2026)

同样的花费下，让一个路由器在两个挑好的模型之间随机挑一个——六款卖钱的商业路由器，没有一款打得过它，最差的那款低了 10.5 分。而另一头，最贵的一成 token 吃掉了 64%–80% 的算力。这一期四篇论文说的是同一件事：一次循环里的算力，该花在哪一步。1

这一期取自 10 月 5 日周一挂出的那批新投稿，cs.AI 新投稿 124 篇、整页 402 条条目；前面几期一直在用的 10 月 2 日那批，这一期换掉了。2

本期听什么

现成的商业路由器，大多不如随机挑。 6 款商业路由器、14 种设置、8 个任务类别、17 个基准：没有一款打得过「在两个挑好的模型之间随机挑一个」，OpenRouter 的 high 档低 4.0±2.0 分，Orca 的 adaptive 档低 10.5±2.8 分。1
跑偏有四种，而且标准目标函数在奖励它们。 难度盲视（路由选择与题目难度的相关系数不超过 +0.20）、长度反转（评测集里答案长度与难度 γ=+0.52，五个路由器设置里却把长答案发给更便宜的模型）、语义匹配（按来源路由，vLLM SR 的调整互信息 0.79、Orca 约 −0.01）、名册次优。1
每个 token 需要的算力差得很远，而且能量。 15 个模型组评审团逐 token 复现：0.5B 的小模型能复现 92%–95% 的 token，而最贵的 10% token 占估计算力的 64%–80%；按这张图路由，MATH-500 上预计延迟 7.59→5.12 秒。3
重复的步骤可以编译成程序，但要把失败算进账。 回本 2–16 次、每次使用的节省份额 0.936–0.999，编译后的程序在 180 次匹配输入上成功 178 次（Agent 是 157 次）；可编译阶段 20 个格子只有 11 个通过，失败尝试中位烧掉 170 万 token。4
验证是预算里的一项，按信息增益花。 联合决定「谁执行」和「哪些中间结果花钱验证」，四个推理基准上成本与延迟都降到至少三分之一。5
四篇合起来给了一条顺序。 先量自己这套每一步花在哪儿，再决定哪些步骤固定成程序，剩下的用小范围路由或干脆选一个模型，最后把验证当成预算项分配。

六款路由器，没有一款赢过随机

Dynamic LLM Routers are Often Misguided 的作者是 Sam Wang、Julia White、Sahibzada Allahyar、Dhruv Atreja、Urchade Zaratiana 和 Kelton Zhang，8 页 15 图，投的是 NAACL。路由器省钱的逻辑很简单：把每个查询发给「便宜但答得对」的模型，比一律发给贵模型省。作者要验的是这个逻辑在商业产品上成不成立。1

他们收了六款商业路由器、14 种设置：OpenRouter 的多档 auto、微软 Azure 的 balanced 与 quality、vLLM SR，以及三家专做路由的 Not Diamond（cost / quality）、Nadir（2-tier / 3-tier）和 Orca（adaptive）。基准横跨 8 个任务类别——写代码、指令跟随、知识、数学、问答、办公、工具调用和 Humanity's Last Exam——共 17 个基准、2,508 条训练样本、800 道评测题。1

比的对象是一个随机路由器：在两个挑好的模型之间按概率随机挑。同样花费下，没有一款商业路由器打得过它。OpenRouter 的 high 档低 4.0±2.0 分，Orca 的 adaptive 档低 10.5±2.8 分；作者说有的差距超过 10 分。1

差在哪儿，他们归成四种形态。难度盲视：路由选择与查询难度的相关极弱，Goodman–Kruskal γ 不超过 +0.20；按 20% 的难度分带看，升级 40–60 或 60–80 百分位是帕累托有效的，升级 80–100 百分位（也就是最难的题）反而不是。长度反转：评测集里答案长度与难度正相关（γ=+0.52），但在五个路由器设置里，预期答案长度与所选模型的平均成本显著负相关——越长反而发给越便宜的模型；把最短的 0–20 百分位查询升级，能拿到 59.5% 的准确率、每千次查询 $1.03，只比升级最难那 20% 低 1.6 个百分点，花费只有后者的 1.5%。语义匹配：多数路由器其实是按问题来自哪个来源路由的，一个来源的题几乎全发给同一个模型（vLLM SR 的调整互信息 0.79，Orca 约 −0.01）。名册次优：多数名册里有帮不上忙的模型，Nadir 的名册干脆漏掉了前沿模型，只有 Haiku 4.5 和 Sonnet 5，两个都不在帕累托前沿上。1

作者再往前推了一步：前三种不是意外，而是标准目标函数奖出来的。在「实际花掉的钱」上算成本—准确率的帕累托效率，会奖励把中等偏难的题升级、把最难的题放过，也会奖励按长度和来源路由。他们给了一个避开四种毛病的两模型路由器做验证，结果对随机路由的增益很有限（三种成本档分别是 −0.2±0.2、−0.7±0.7、−0.7±1.0 分）。论文自己的结论是：名册要是挑得好，本来就没多少可路由的。1

一个 token 到底要多少算力

What Does a Token Cost? 的作者是 Zhixu Du、Weijia Han、Hai Helen Li 和 Yiran Chen。现在的模型对每个 token 花同样的算力，不管这个 token 好不好写；投机解码、模型路由这些方法都建立在「大量算力是浪费的」这个假设上，但单个 token 实际需要多少，之前没有被量过。3

他们的量法是用一个「智能体混合」当尺子：从 Qwen、OLMo 和 R1 蒸馏三个家族里取 15 个容量递增的模型，每个成员都在给定正确前缀的情况下，逐 token 复现同一段参考序列；能把某个 token 复现出来的最小模型，其推理开销被定义成这个 token 的足够算力。这是个上界，不是精确需求，但它把一个原本没指标的东西变成了可测的量。3

差异有多大：0.5B 的模型就能复现 92%–95% 的参考 token；而在三个家族的评审团里，最贵的那 10% token 占估计算力的 64%–80%。他们还做了两个演示：在全部 500 道 MATH-500 上，用这张图做模型路由，预计延迟从 7.59 秒降到 5.12 秒，准确率还略好于最好的置信度路由基线；用同一张图做草稿，草稿 token 少 32.6%，预计延迟低约 20%。论文的落点是：分配上还有余量，值得做一个利用「足够算力」结构的控制器。3

什么时候值得把步骤编译成程序

When to Compile a Computer-Use Agent? 的作者是 Yulong Ming、Jie Xu、Zihan Wu 和 Xiaohua Jia，27 页 3 图。让 Agent 反复执行的界面过程，可以编译成一个程序，之后直接跑程序省 token。难点有两个：编译成本不确定，因为尝试可能需要修复、而且可能一直失败；未来复用也未知，因为任务可能不再来、界面一漂移程序就失效。4

他们的系统叫 PACE，一半是测量协议，一半是在线决策算法。协议记录成功与失败编译各花多少，在匹配的任务输入上比较 Agent 与程序的执行成本，估出每次使用的节省和回本次数；上线的条件是编译后用生成程序在源任务上跑通 3/3 才部署。在线算法把预计的未来节省与含失败尝试的编译成本相比，并且开销要压在由观测到的任务到达累计出来的预算线以内——在论文的成本假设下，每个到达之后的总成本不超过「全部任务都用 Agent 跑」的 1+ε 倍。4

数字很具体。成功的编译，排除收集轨迹的源运行，回本需要 2–16 次使用；每次使用的节省份额在 0.936–0.999 之间，几乎等于全免。6 个已验证的 Android 程序 × 30 个绑定 = 180 次匹配输入：Agent 成功 157 次，程序成功 178 次，程序反而更稳。4

但编译本身经常失败：有编译阶段记录的 20 个格子里只有 11 个通过验证。失败的尝试中位成本 170 万 token，成功的只要 25.9 万，差 6.57 倍。用记录的到达顺序做模拟，ε=0.25 时平均省 token：比 ReAct 省 17.3%、比 AutoRPA 省 24.9%、比 ToolPro 省 17.3%；4,800 次 grid 运行加 120 次日志运行都落在实现的那条 1.25 上界内。要注意的是，这条保证只约束成本，不保证任务成功率。4

验证该花在哪一个中间结果上

JOVE 的作者是 Haoran Zhang、Dongjun Kim、Seohyeon Cha、Kevin S Chan、Ananthram Swami、Gustavo De Veciana 和 Haris Vikalo。做法是把一个复杂查询拆成有向无环的任务图，分给不同的模型并行执行，既能降延迟，也让小模型能参与解复杂题。麻烦在于：哪个模型适合哪个子任务，事先不知道；而且光执行一次也看不出输出对不对。5

JOVE 同时决定两件事：每个节点交给哪个执行器，以及哪些中间输出值得花钱送验证。验证异步执行，不拖慢当前这次回答，但费用计入长期预算——所以本质上是在「现在花钱」和「以后学得更准」之间做取舍。验证回来的二元标签用来更新每个模型在每个子任务上的质量估计，长期预算由影子价格管着，每次查询解一个混合整数线性规划。5

最值得抄的一点是验证怎么挑：他们给每次验证算一个信息增益（按 D-optimal 准则），把预算放在最能降低未来分配不确定性的「节点—模型」对上；也就是说，oracle 已知质量时最优选择是根本不验证，质量未知时才需要选择性验证，而不是全量验证。结果上，四个推理基准的准确率与标准推理基线相当，平均成本与平均延迟都降低到至少三分之一；相对最强基线，成本低 3.7–16.3 倍、延迟低 8.3–17.0 倍。理论上他们证明了质量学习的 regret 是次线性的，前提是验证要足够频繁以便学习、又不能挤掉执行。5

边界

四篇都是作者自报的结果，没有第三方复现。1 3 4 5
路由器那篇的 8 个任务类别、17 个基准和那个「两个挑好的模型」都是作者挑的；换一批任务或换一对模型，结论可能变。1
「足够算力」是上界，不是真实需求，而且它取决于评审团里放了哪些模型。3
编译那篇的任务只来自 4 个 AndroidWorld、2 个 OSWorld LibreOffice 和 1 个 WebArena Reddit 任务；模拟里的到达顺序借的是业务流程日志，不是实时的界面任务；缺少的成本用估计值补。4
JOVE 没有点名那四个推理基准，执行器模型、任务图规模、成本与延迟的口径也都没有完全披露。5

落到顺序上是这样：先量自己这套里每一步花在哪儿，再决定哪些步骤固定成程序，剩下的用小范围路由或者干脆选一个模型，最后把验证当成预算里的一项去分配。四篇都没回答的是：省下来的算力，你打算拿去干什么。

回到开头那句：随机在两个挑好的模型之间挑一个，就赢过六款卖钱的路由器。你以为装上去的是一个优化，其实很可能只是一个判断不了难度的开关。

References

1
Dynamic LLM Routers are Often Misguided（arXiv:2610.02762）
arxiv.org
2
arXiv cs.AI 新投稿列表（2026-10-05）
arxiv.org
3
What Does a Token Cost?（arXiv:2610.02491）
arxiv.org
4
When to Compile a Computer-Use Agent?（arXiv:2610.02932）
arxiv.org
5
JOVE: Joint Execution and Verification for Resource-Aware LLM Task Graphs（arXiv:2610.03296）
arxiv.org