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 个百分点，这是专用化的预期代价——如果降幅远大于此，说明蒸馏把模型收窄得太厉害了。