AWS:序列级知识蒸馏将购物智能体压缩至 4B 参数,保留推理链是成败关键
智能体应用的成本结构与单次问答不同。一个购物助手完成一次推荐,可能经历搜索、读取结果、缩小范围、验证约束、提交答案等多步循环,每一步都是对前沿模型的一次独立计费调用。在用户规模下,这种按 token 计费的循环使项目无法上线。AWS 博客给出的解法是序列级知识蒸馏(SeqKD):让前沿教师模型生成完整的多步轨迹,用基准测试的评分器筛选出真正解决问题的轨迹,再用这些轨迹对小模型做监督微调。教师只需要输出文本,不需要权重、logits 或强化学习基础设施,因此闭源 API 模型也能充当教师。
这篇博客最有实践价值的发现是一个消融实验:同样的 426 道训练题、同样的筛选流程,唯一区别是训练目标中是否保留教师的推理文字。去掉推理、只留工具调用,平均绝对成功率从 0.541 降到 0.415,差了约 13 个百分点。作者的解释是:推理不是装饰性旁白,而是连接观察与下一步行动的因果链。智能体在每一步需要决定搜索什么、如何过滤、何时终止,这些决策由推理驱动。学生如果只学到工具调用序列而没学到背后的推理,就只完成了部分迁移——保留推理才是把学生带到接近教师水平的关键。
但 SeqKD 有明确的能力天花板。博客指出,决定蒸馏能否成功的不是学生与教师之间的参数差距,而是任务本身是否在学生能力范围内。教师 GLM-5.3 约有 400 亿活跃参数,学生 Qwen3.5-4B 只有 40 亿,十倍差距,但购物任务对 4B 模型来说足够简单,所以学生几乎完全恢复了教师的质量。反过来,如果任务超出学生的原始能力,蒸馏只会让它产出格式正确但答案错误的长推理链,轨迹变长而准确率不动。作者建议的应对方式是:看到这种症状就停止加数据,要么换更大的学生,要么降低任务难度。此外,SeqKD 在多步循环的最难尾部会停滞,因为学生看不到自己犯错后进入的状态;要突破这个瓶颈需要 on-policy 方法,SeqKD 本身只是第一阶段。
从成本结构看,蒸馏的意义不仅是模型变小。前沿 API 按 token 计费,每次循环每一步都要付费,成本随流量线性增长。蒸馏后的 4B 学生部署在自托管端点上,按实例小时计费,流量增加不额外收费直到需要扩容。作者没有给出具体每任务成本数字,因为那取决于你的请求模式、序列长度和并发量,需要自行测量。同时,IFEval 显示学生的通用指令遵循能力下降了约 6 到 8 个百分点,这是专用化的预期代价——如果降幅远大于此,说明蒸馏把模型收窄得太厉害了。