PyroDash：让小模型学会在 token 级别把难题交给大模型

一个公司想把数学问答服务上线到真实产品里，会很快碰到一个尴尬的选择。

如果所有请求都交给大模型，答案通常更可靠，但每一道题都要付一次昂贵的输入和输出 token 账单。尤其是多步推理题，输出很长，贵的不是“看一眼问题”，而是大模型一步一步生成后续推理。论文用 GLM-5.2-FP8 做大模型基线，在五个数学基准上的总估算成本是 49.36 美元。

如果所有请求都交给小模型，成本低很多，但能力缺口也很明显。论文里的 Qwen3.5-4B 基线平均准确率只有 28.36%。经过前两阶段 SFT 后能到 46.25%，但离大模型的 57.68% 还有距离。

直觉上，我们会想到“路由”：简单题给小模型，难题给大模型。问题是，很多题的难点不是写在题面上的。一个题看起来只是小学应用题，真正的坑可能在最后一步“严格大于”而不是“等于”；一个竞赛题的题面很短，难点可能出现在化简到一半之后。请求刚到系统时就决定整题给谁，有时太早了。

PyroDash 这篇论文的核心想法，就是把这个决定推迟到生成过程里。先让小模型开始做；如果它走到某一步发现自己需要更强的模型，就生成一个特殊控制 token：<offload>。协作引擎看到这个 token 后，不再让小模型继续，而是把原问题和小模型已经写出的局部推理一起打包，交给冻结的大模型一次性续写到答案。

先理解一个更细的路由问题

我们平时说“小模型加大模型协作”，很容易想成一个客服分诊台：请求来了，先判断难不难，难的转高级专家，不难的本地解决。这叫请求级路由。RouteLLM 这类方法就是这个方向：在解码前，把整个 query 分给小模型或大模型。

但自回归推理不是一次性完成的。模型生成答案，是一个 token 接一个 token。每生成一小段，它对问题的理解都会变一点：可能已经把自然语言题目转成方程，可能发现了约束冲突，可能刚好走到一个需要枚举或代数化简的节点。

这时，“难不难”不再只是题面的属性，而是当前推理轨迹的属性。

举个论文附录里的例子：AIME 题给出三个对数方程，要求求一个表达式的绝对值。小模型先做了关键的变量替换：令 a=log₂x, b=log₂y, c=log₂z，把原题变成三元线性方程组，并明确目标是 |4a+3b+2c|。到这里，它生成 <offload>。大模型接手后，只需要沿着这个已整理好的代数系统求解，得到答案 33。

这个过程不像“把整题丢给大模型”。小模型不是失败后求救，而是先完成了可用的前缀工作。大模型也不是从头读题，而是接着一个被压缩、被结构化的中间状态继续。

论文把这个设计叫 token-level SLM-LLM collaborative inference。更具体地说，PyroDash 选择的是 SLM-initiated、single-handoff 的版本：由小模型自己在 token 流里发起，最多交棒一次，交给冻结大模型后不再切回来。

这个限制很重要。反复切换听起来灵活，但工程上会引入更多 API 调用、上下文打包、延迟和成本。PyroDash 的目标不是做一个复杂调度系统，而是问一个更窄的问题：能不能让小模型学会在自己的生成轨迹里找一个值得交棒的边界？

<offload> 不是按钮，而是能力边界

表面上看，PyroDash 只是在词表里加了一个特殊 token。可如果我们只把它当成“开关”，就会误解这篇论文。

一个有用的 <offload>，必须同时满足三件事。

第一，它不能太早。如果小模型一开头就交棒，系统退化成大模型优先，成本省不下来。论文里 λ=0.05 的高准确率版本已经很接近这种状态：LLM token ratio 是 95.34%，平均每题 0.975 次大模型调用，成本 39.29 美元。它确实达到了 64.04% 平均准确率，比大模型单独跑的 57.68% 还高，但它主要是在追求质量，不是在极限省钱。

第二，它不能太晚。如果小模型已经沿着错误方向写了很多，后面大模型接到的是一个带偏的局部推理。即使大模型更强，也可能被前缀拖住，或者要花额外 token 纠正。

第三，它最好出现在一个“可续写”的位置。小模型前缀应该把题目整理到某个有信息增益的状态：算出年净收入、列出方程、选出物理公式、识别组合约束。这样大模型接手时，拿到的不是混乱草稿，而是一段可以继续使用的 reasoning trace。

PyroDash 的协作引擎本身并不聪明。论文反复强调，Collaborate Engine 只是执行协议：接收 query，把 offloading prompt P_s 和问题发给小模型；小模型流式生成；如果检测到 <offload>，就截断小模型输出，去掉控制 token，把前面的局部轨迹和原问题一起打包；然后用 completion prompt P_l 调用冻结大模型续写；最后拼接小模型前缀和大模型后缀。

真正要学的是小模型内部的策略。论文的形式化目标也很直接：最大化答案正确率，同时惩罚相对大模型单独推理的归一化成本。奖励可以粗略理解成：

正确性 - λ × 相对成本

这里的 λ 是整篇论文的调音旋钮。它越小，系统越愿意为准确率付大模型账单；它越大，系统越保守，只有在收益明显时才交棒。

为什么需要三阶段训练

现在的问题变成：小模型原本的词表里没有 <offload>，也没有“我该在这里交给大模型”的行为习惯。直接用强化学习硬怼，很可能不稳定；只做监督微调，又只能模仿人工插入的交棒位置，未必对应真实成本收益。

PyroDash 用三阶段把这个动作慢慢变成策略。

第一阶段先让模型“认识”这个新 token。论文不是完全随机初始化 <offload> 的 embedding，而是用一组自然断点 token 的 embedding 均值初始化，比如句号、换行、EOS，再加标准差 0.1 的高斯噪声。这个细节很工程，但有道理：交棒往往应该发生在一句推理或一个步骤的边界，而不是任意半个表达式中间。

第二阶段做 offloading-oriented SFT。论文构造了 EasyHard-24k 数据集，共 24,061 个例子。判断 easy/hard 的方式不是用静态标签，而是看当前小模型能不能答对：答对的是 easy，答错但可以重构正确推理的是 hard。这样，难度是相对于这个小模型的能力定义的。

然后数据被扩展成两种 prompt 条件。Corpus A 没有协作 prompt，因此目标里不应该出现 <offload>，用来保留普通独立推理能力。Corpus B 加上 P_s，easy 例子仍然不交棒，hard 例子在 chain-of-thought 里动态插入一到四个候选 <offload>，让模型先学会“协作模式下可以在推理中请求帮助”。

但这些插入位置只是冷启动。论文明确说，Stage 2 的 synthetic locations 不被假定为最终最优能力边界。真正的边界要在第三阶段通过完整协作 rollout 来学。

第三阶段用 GRPO 做成本感知对齐。每个训练问题采样 G=8 条小模型轨迹；如果某条轨迹出现 <offload>，训练环境就按真实推理协议调用冻结大模型完成后半段。最后根据答案是否正确，以及这条协作轨迹相对大模型单独跑的成本，计算总奖励。GRPO 在同一个问题的 8 条 rollout 内做相对比较，不需要额外 critic。

这里有一个关键边界：梯度只更新小模型生成的 token，包括它是否生成 <offload>；冻结大模型的输出不会反向传播回大模型。大模型只通过最终正确率和成本影响小模型策略。这让 PyroDash 更接近现实 API 场景：你可以调用一个强模型，但不能改它的权重，也不一定能拿到它的 logits。

数字最有戏剧性的地方：不是“省一点”，而是出现了两个操作点

论文在五个数学推理基准上评估：GSM8K、Minerva、Olympiad-Bench、AIME-2025、AIME-2024。Minerva、GSM8K、Olympiad 用 greedy pass@1；两个 AIME 用 avg@32 来降低采样波动。平均分是不加权平均，避免大数据集支配结果。

先看端点。

Qwen3.5-4B 小模型平均准确率 28.36%，成本 2.26 美元。GLM-5.2-FP8 大模型平均准确率 57.68%，成本 49.36 美元。SFT 后小模型到 46.25%，成本 1.32 美元。也就是说，SFT 带来明显能力提升，但还没有达到大模型水平。

再看传统路由基线。RouteLLM 在大约 75% GLM 使用率下，平均准确率 52.74%，成本 44.62 美元；GlimpRouter 平均准确率 54.20%，成本 31.61 美元，平均每题 1.20 次大模型调用。这两个数给了我们一个参照：路由确实比纯小模型强，但很容易仍然大量依赖大模型。

PyroDash 的有趣之处，是它不是只给一个结果，而是给了一条由 λ 控制的 trade-off 曲线。

当 λ=0.05，它几乎不吝啬使用大模型：LLM token ratio 95.34%，平均调用 0.975 次，成本 39.29 美元。但换来的是 64.04% 平均准确率，比 GLM-only 的 57.68% 高 6.36 个百分点，同时成本比 GLM-only 低 20.4%。具体到基准，它在 Minerva、Olympiad、AIME25、AIME24 上都是表中最高；GSM8K 则是 GLM-only 的 96.44% 略高于 PyroDash 的 96.13%。

这说明“先小模型推理一段再交给大模型”不只是省钱技巧，也可能提高质量。一个合理解释是：小模型前缀有时把问题先规整到更适合续写的状态，大模型接手时不是从原始题面开始。但这个解释要谨慎，论文没有逐个分析所有触发位置的理性，只在 case study 中展示了若干例子。

当 λ=0.6，故事变成另一个方向。平均准确率是 54.55%，比 GLM-only 低 3.13 个百分点，但 LLM token ratio 只有 1.90%，平均每题大模型调用 0.012 次，总成本从 49.36 美元降到 1.78 美元，相当于 96.4% 的成本下降。它的准确率仍略高于 RouteLLM 的 52.74%，也略高于 GlimpRouter 的 54.20%，但成本远低于两者。

最值得注意的是 λ 从 0.05 到 0.1 的突变。论文的 ablation 表显示，LLM token ratio 从 95.34% 掉到 8.19%，平均调用从 0.975 掉到 0.058，成本从 39.29 美元掉到 4.71 美元；平均准确率从 64.04% 降到 55.29%。继续把 λ 增到 0.2、0.3、0.6，准确率基本在 54.20% 到 55.29% 之间，成本继续下降到 2.55、2.16、1.78 美元。

这条曲线的含义不是“λ 越大越好”。它说明 PyroDash 学到的不是一个固定路由器，而是一族可部署策略：如果你的产品愿意多花钱追求最高准确率，选低 λ；如果你要控制大规模服务成本，选高 λ；如果你想在准确率和成本之间取折中，λ=0.1 给出 55.29% 准确率和 4.71 美元成本。

成本节省来自哪里

论文没有只报一个“省钱百分比”，还把 token 用量拆开了。

价格假设是：Qwen3.5-4B 输入 0.05 美元/百万 token，输出 0.08 美元/百万 token；GLM-5.2-FP8 输入 0.90 美元/百万 token，输出 2.86 美元/百万 token。这个价格模型很关键，因为大模型输出 token 最贵，而数学推理恰恰会生成大量输出。

在 λ=0.6 下，GLM-only 的 LLM 输出 token 是 17.08M，总成本 49.36 美元。PyroDash 把 LLM 输出 token 降到 0.23M，同时产生 12.07M 小模型输出 token，总成本 1.78 美元。换句话说，省钱的主因不是某个神奇压缩，而是把绝大部分长解码从昂贵大模型转移到了便宜小模型；大模型只在少数需要时被调用。

这里也能看出 token-level handoff 为什么比只看 LLM token ratio 更细。LLM token ratio 只统计解码输出，不包含 prefill。可实际成本里，交棒前的小模型前缀会变成大模型输入上下文，也要按 LLM prefill 价格计费。PyroDash 的 reward 用相对大模型单独推理的 normalized cost，就是为了让策略学到：太晚交棒会让大模型读很长前缀，太早交棒又会让大模型生成太多后续，两者都不免费。

这篇论文证明了什么，也没有证明什么

先说它证明了什么。

第一，在论文设定的数学推理任务和 Qwen3.5-4B / GLM-5.2-FP8 组合上，一个小模型内部化的 token-level handoff 策略，可以形成明显优于请求级或外部 step-level 路由基线的成本—准确率折中。尤其是 λ=0.6 的点：54.55% 平均准确率、1.90% LLM token ratio、0.012 次平均 LLM 调用、1.78 美元总成本，是很强的成本信号。

第二，Stage 3 的 GRPO 不只是锦上添花。SFT 冷启动平均 46.25%，而 λ=0.05 的完整 PyroDash 达到 64.04%；AIME-2024 从 SFT 的 28.23% 到 63.75%。这说明只教模型“哪里可能 offload”不够，必须让它在真实协作 rollout 中看到最终答案和成本。

第三，λ 确实能控制贵模型依赖。论文给出的 sweep 显示，从 0.05 到 0.6，LLM token ratio 可以从 95.34% 压到 1.90%，同时在 λ≥0.1 的区域维持 54% 到 55% 左右的平均准确率。

但它没有证明的东西也要说清楚。

第一，论文没有系统分析每一次 offload 是否真的发生在“合理能力边界”。限制章节明确承认：当前评估报告准确率和 LLM 使用量，但没有检查个体触发位置的 rationality。也就是说，我们知道策略总体有效，但还不知道它是不是像人类希望的那样“在刚好不会做时交棒”。

第二，成本是按列出的 token 价格估算，不是实际 provider bill。不同平台的批处理、缓存、并发、最小计费单位、延迟要求，都会改变真实经济性。

第三，任务域比较窄。论文只评估数学推理，训练数据和测试都围绕这类题；代码生成、工具调用、多模态、多轮对话里的 handoff 行为还没有验证。尤其是多轮场景，PyroDash 当前每个 query 最多一次从小到大的单向交棒，不讨论交给大模型后再回到小模型，或者下一轮如何继承状态。

第四，模型组合也只有一组主实验：Qwen3.5-4B 作为小模型，GLM-5.2-FP8 作为大模型。不同小模型的“知道自己不会”的能力可能差很多；不同大模型对局部推理前缀的鲁棒性也可能差很多。

真正值得带走的系统直觉

PyroDash 最有价值的地方，不是发明了一个特殊 token。特殊 token 很容易复制，难的是它背后的系统视角。

过去我们常把模型协作想成“选择哪个模型回答”。PyroDash 把问题改成“推理进行到哪里时，应该把控制权交给更强的模型”。这会让路由从输入分类，变成轨迹控制。

这个转向可能很重要。随着本地小模型越来越便宜，未来很多服务不会每个请求都从大模型开始。更合理的默认路径可能是：小模型先处理、先规整、先尝试；只有当轨迹暴露出能力边界，才调用昂贵模型。大模型不再是所有问题的默认入口，而是推理网络里的稀缺专家资源。

当然，PyroDash 还不是最终答案。它需要更细的触发位置诊断，需要真实账单验证，需要跨任务域和多模型组合复现。但它给了一个清晰的实验信号：小模型不只是可以便宜地生成 token，也可以被训练成一个会在自己生成过程中发出求助信号的策略体。

如果这个方向成立，未来推理系统的核心能力可能不只是“谁更聪明”，而是“谁知道什么时候该继续，什么时候该交棒”。