一句话总结
大模型好但贵，小模型省但弱，自然的想法便是让二者协作解决实际问题，节省成本的同时实现更好的效果。本文回顾相关研究历程，并推荐了一个字符级路由的工程优化开源项目
一、动机
最强的模型答得好，但贵且慢；便宜的小模型又快又省，碰到难题就露怯。而真实流量里大多数问题小模型就能答对，只有少数真正难的才值得交给大模型
所以让大小模型分工几乎是天然需求，难点只有一个：由谁、在什么粒度上判断「这一次该不该请大模型」
二、级联、路由与自检
2.1 多模型级联
- 传统模型级联
「先便宜、没把握再升级」的骨架很早就出现了。2001 年的 Viola-Jones 人脸检测框架把一串分类器从便宜到昂贵排成级联，绝大多数明显不是人脸的窗口在前几级就被筛掉，只有可疑窗口才送进更贵的分类器
BranchyNet 把同一思想搬进单个神经网络：允许在模型中间层直接输出结果，有把握的样本提前离开，不必跑完整个网络
Rapid Object Detection using a Boosted Cascade of Simple Features（CVPR 2001）
BranchyNet: Fast Inference via Early Exiting from Deep Neural Networks（ICPR 2016）
- 大模型级联
FrugalGPT 把多个 LLM 接口按价格排成一条链，便宜的先答，由打分器判断答案是否可靠。可靠就停，否则升级到下一级。配合其他成本节省策略，FrugalGPT 在追平 GPT-4 效果时成本最多降低 98%
但级联的硬伤在于难题成本：越难的问题越要把前面每个便宜模型都白跑一遍，花冤枉钱也拉长延迟
FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance（TMLR 2024）
2.2 路由派单
为了解决难模型的开销问题，路由策略不再排队，而是在拿到问题之初就判断难度。Hybrid LLM 训练一个轻量路由器，根据预测的问题难度和期望质量把请求委派出去，实现了大模型调用减少 40% 且回答质量不降
RouteLLM 用人类偏好数据训练路由器，在未参与训练的模型组合上也有较好泛化，成本降低 2 倍以上且质量不明显下降
Hybrid LLM: Cost-Efficient and Quality-Aware Query Routing（ICLR 2024）
RouteLLM: Learning to Route LLMs from Preference Data（ICLR 2025）
2.3 看了答案再决定
很多场景下，光看问题来猜难度并不可靠。AutoMix 先让小模型作答，再用少样本提示让它自我核验答案，核验结果交给一个基于 POMDP 的路由器决定是否升级，在性能相当时计算成本降低 50% 以上
AutoMix: Automatically Mixing Language Models（NeurIPS 2024）
2.4 局限
上述方法都只对整条请求做一次判断，但长推理里往往只有几个转折点才是真正困难的。如果整个问题判成难，可能在多数常规推理步骤上并不划算；判成简单又很可能在关键难点上被小模型写坏
三、逐字路由
3.1 Co-LLM
逐字路由（token 级路由）在生成每个字时都决策一下由谁来写。Co-LLM 把「这个字由谁生成」建模为隐变量，训练模型判断什么时候自己写、什么时候调用助手模型
Learning to Decode Collaboratively with Multiple Language Models（ACL 2024）
这看起来与投机解码（speculative decoding）很像，但后者是为了加速推理，输出结果与大模型单独解码基本一致；逐字路由让小模型真正写下大部分字，大模型只接手关键位置，输出可以不同，换的是成本与质量的平衡
3.2 关键点判定
如何判断哪些 token 该上报给强力外援？有以下几种典型方案：
- 不确定性启发式：直接看小模型对当前字有多没把握（熵、最高概率、前两名的差距），超过阈值就交给大模型。依据是统计结论：让答案由对转错的字附近熵明显偏高。问题在于「没把握」和「有后果」往往并不等价（如 R-Stitch）
- 监督学习路由器：离线合成推理链上每个位置「该不该交出去」的标注，训练轻量分类器，输入小模型的隐状态、logits 等，推理时逐字打分。难点在于如何准确合成监督数据的同时控制标注成本（如 CITER、R2R）
- 强化学习路由器：把路由器当作策略，整条回答生成完后按「答案对不对、花了多少大模型调用或延迟」给奖励，让它自己摸索哪里值得花钱。难点在于奖励稀疏、训练不稳定、采样昂贵（如 R-Stitch+）
- 端到端隐变量：在小模型最后一层加一个线性头输出「让位」概率，微调训练让判断能力内化进模型自身。好处是不需要精确的路由标签，代价是训练后会与搭档模型深度绑定，泛化性欠缺（如 Co-LLM）
CITER: Collaborative Inference for Efficient Large Language Model Decoding with Token-Level Routing
R-Stitch: Dynamic Trajectory Stitching for Efficient Reasoning
R2R: Efficiently Navigating Divergent Reasoning Paths with Small-Large Model Token Routing（NeurIPS 2025）
四、TokenRouter 工程优化
4.1 系统开销
vLLM、SGLang 这类服务框架有一个默认假设：一条请求从头到尾只由一个模型处理。逐字路由每隔几个字就换一次模型，这个假设直接失效
每当请求从大模型那里拿回一个字，重新进到小模型时，框架不认识它了，只看见一条以已生成内容为前缀的新请求，需要重新做前缀匹配、分配 KV cache、挂 radix 树。在多模型协作架构中拆解小模型的单步耗时可见，小模型本身的推理开销只占 4.20%，工程损耗占了大头，并且回答越长越严重
TokenRouter: Efficient Serving System for Token-Level LLM Routing
github: thu-nics/TokenRouter
TokenRouter 的解法是给请求加一个挂起状态，标记被路由走的请求，调度器会跳过它但原样保留其 KV cache 与全部服务状态；大模型的字回来后，直接把新字追加到末尾、切回运行，就像它从没离开过
4.2 调度算法
一般情况下，大小模型的响应速度差距很大，前面的讨论解决了状态切换的开销问题，但在真实的多并发服务场景下，如何规划模型之间的协作方式也需要良好设计，尽可能避免设备空转的现象
如上图 a 所示，步骤级同步是最常见的协作方式，它沿用了单模型的循环做法：把一批请求组装成 batch，每一轮必须等到所有请求做完才继续。一旦出现了大模型调用，所有请求都得停下来等待；子图 b 展示的是模型粒度同步：轮流调用大小模型并尽量提高并发程度，但如图所示这一做法可能反而更慢
一个自然的想法是，让两个模型各自独立循环，一收到请求就立刻开算，被路由走的请求也暂时离开小模型的 batch，剩下的照常往前走（如上图 c 所示）。按理说这种 “不等待” 的设置应该是最高效的，但实际上并非如此：
就像坐电梯一样，轿厢内的人数并非是升降速度的主要瓶颈，LLM 推理耗时的主要开销在于显存中的权重搬运，一个 batch 内多几条请求的影响也不大。逐字路由换模型频繁、每步耗时方差大，让大模型等一小会儿，攒够 N 个请求再发车往往能实现更高吞吐。至于 N 的取值到底如何设置，TokenRouter 通过离散时间马尔可夫链建模来求解
除此之外 TokenRouter 还实现了 kernel 指令录制、进程通信优化、kv cache 联合分配等操作来优化逐字路由带来的新瓶颈，开发者只需要实现三个函数：route（调哪个模型）、send（打包要转交的状态）、receive（如何接收），批处理与异步调度全由系统负责，最终实现了 2～64× 的解码吞吐量，显著提升了 token 级路由的服务效率
五、智能体场景
5.1 步骤级路由
智能体完成任务时需要执行多个步骤（规划、调工具、读结果、改代码），任务难度会随每次工具返回而改变。相比于把工具调用拆得七零八落的逐字切换，步骤粒度上做路由是更自然的做法，但也多了两条约束：
- 回滚代价：写错了几个字，大模型可以很轻易地圆回来。但智能体发出的请求、执行的命令面临更大的反悔代价（改变了系统状态、产出了大量上下文等），所以实践中应该尽量在动作执行之前就做好判断，或者在交付之前做额外补救
- 黑盒约束：智能体常用商用 API，没有 logits、隐状态、熵等内部信息，只能依靠外部可见内容做路由判断
5.2 判断求助时机
对于接入商用 API 的 Agent 系统，在拿不到 logits 时判断「这一步该不该求助」的方法大致有以下几种：
- 规则触发：根据业务经验手写规则，比如在：连续 5 步无进展、预测动作在环境里非法、关键决策（如提交最终答案）、出现异常时咨询大模型（如 SwiftSage）。这一方案简单有效，Anthropic 的顾问策略也是这样设计（提示执行模型在确定方案前、错误反复出现时和宣布完成前求助），坏处是条件写死，严重依赖业务经验
- 训练风险估计器：给每一步候选动作估一个失败概率，超过阈值就升级，如 R2V-Agent、StepGate 等，本质上就是上述「监督学习路由器」的步骤级翻版
- 智能体决策：允许 Agent 自行决策要不要求助，在成本约束下训练模型，优化整条轨迹的成功率，如 ARIA
- 子任务委派：以子任务拆解的形式解决问题，并识别评估子任务是否需要调大模型。如 RSI-Router，它离线分析大模型的历史轨迹，归纳子任务类型并决定分配给哪个模型、配什么技能提示
SwiftSage: A Generative Agent with Fast and Slow Thinking for Complex Interactive Tasks（NeurIPS 2023）
R2V Agent: Teaching SLMs When to Ask for Help
Do I Need the Cloud? Uncertainty-Aware Step-Level Handoff for Small Language Model Agents（StepGate，2026 SLMs for Agentic Systems 研讨会）
RSI-Router: Evolving Subtask-Level LLM Routing and Skills for Cost-Efficient Agents
5.3 求助方式
之前讨论的是如何决策求助的时机与粒度，而求助的方式也有两种做法：
- 接管：强模型亲自执行这一步，产出的动作直接作用于环境（如 SwiftSage）
- 指导：强模型不碰工具，只给执行模型一段建议，执行权仍在便宜模型手里（如 ARIA、SWE-Protégé 和 Anthropic 官方的顾问策略）
既然都叫强模型出手了，为什么指导模式还考虑不让对方接管？这样做的好处在于：隔离了决策建议与执行环境。就像企业高管不必操心所有的工作细节一样，强模型只读上下文、写几句话，不用跑完一整步的工具循环，执行轨迹也保持连贯。代价是多出一个接管模式下不存在的隐患：建议送到了，执行模型未必照做，多项研究都报告了这一情况，一般占 badcase 的 40～60%。解决方案主要有两种：
- 改协议：强制执行者先确认收到建议（ACK）、把建议包装成执行者自己的 history（前者可能导致模型口头答应但就是不做）
- 改模型：直接在带专家建议的轨迹上 SFT 训练小模型，奖励里专门惩罚原地打转和「问了专家却不照做」
Precise but Uncoupled: Reviewer Precision Does Not Guarantee Critique Uptake in Multi-Agent Math Reasoning
SWE-Protégé: Learning to Selectively Collaborate With an Expert Unlocks Small Language Models as Software Engineering Agents
Thinking Outside the Box: Can Language Models Rely on External Guidance Selectively?
