做蒸馏的人大多默认一个前提:训练数据越多越好。9 月 3 日上传 arXiv 的论文 Rethinking On-Policy Distillation II: One Training Example 把这个前提推到极限——on-policy 蒸馏只用一条训练样本,学生模型照样持续涨分。数字摆出来之后,「攒数据」这件事的边际价值需要重新掂量。
一条 query 能走到多远
先补背景:on-policy 蒸馏(OPD)的组合方式,是学生模型自己生成 rollout,再由教师在 token 级别提供密集监督。论文自述,已有工作主要在研究它的算法行为,训练数据扮演什么角色一直不清楚。Thinking-Space 团队(README 联系方式为清华邮箱)的做法是把数据压到最小极限:只用一条 query 训练。
结果有三层。第一,单样本 OPD 在数百步内持续改进,并在不同任务域和模型家族上都找回了全量数据 OPD 增益的大头。第二,团队定义了「状态覆盖率」——全量 OPD 训练中到访过的状态里,当前 query 集的 rollout 能触达的比例——单条 query 就达到 71.5%,而且大头在前 100 步内完成。第三,继续加语义多样的 query,状态覆盖率和验证准确率一起上升,16 条时覆盖率达到 98.9%,追平约 17k query 的全量训练。
数据过量,算法饥饿
更关键的对照是吸收速率:不管用一条 query 还是全部 17k,学生对齐教师的速度都以相似节奏放缓;甚至固定住同一批状态,学生也要数百步才能消化。论文给出一句话结论:OPD 是「数据过量、算法饥饿」(data-overfed but algorithm-starved)——rollout 很快铺开广泛的监督信号,学生吸收监督却越来越慢。
两个延伸发现。其一,状态覆盖结论可以推广到多教师 MOPD:每个域 16 条语义多样的 query 即可追平全量多教师训练。其二,压力测试里,内容近乎空的模板、域外 WildChat query 都能逼近真实 query 的基线——任务内容和它诱导的状态覆盖,是可以分离的。仓库里甚至留了 template 模式,让学生自己写训练输入。
开源与复现门槛
代码开源于 GitHub(Thinking-Space/One-Shot-OPD,Apache 2.0),基于 veRL 扩展实现,论文参考数字来自单台 8 卡 H100/A100 80GB 节点。评测覆盖四个域:数学(MATH-500、AMC 2023、AIME 2025,avg@16)、代码(LiveCodeBench v6,avg@3)、指令跟随(Multi-IF 八语言)、工具调用(BFCL v3,avg@8)。这是系列第二篇,前作今年 4 月上传,团队希望这些发现把后续工作引向 OPD 的步效率问题。
所以呢
对做后训练的团队,启示不是「以后蒸馏只用一条样本」,而是投入结构的再分配:数据工程的边际收益比想象中低,怎么让学生更快吸收监督(步效率)才是下一阶段的竞争点。和月初普渡大学那篇「固定负优势就能追平教师」的发现放在一起看,「OPD 到底在学什么」正在被集中重审。论文与代码:arXiv:2609.04172,github.com/Thinking-Space/One-Shot-OPD。