2 篇博文 含有标签「distillation」

一个团队将一个 200B 的教师模型压缩成一个 7B 的学生模型，因为评估套件——包含五万个覆盖产品发布时所有功能的样本——显示学生模型仅落后教师模型不到两个点，且推理成本降低了一个数量级。迁移上线了。成本曲线下降。客户满意度曲线持平。三周后，客服开始看到一类团队无法在评估中复现的故障。

学生模型不再识别教师模型曾默默处理的边缘案例输入格式。它不再能从教师模型曾可靠消除歧义的特定模糊指令中恢复。它不再产生那种罕见但关键的“与其猜测不如询问澄清问题”的行为——因为评估集以这些提示词是“坏数据”为由，清除了其中的模糊提示词。

评估结果显示蒸馏是忠实的。评估对于“忠实性”的定义是错误的。

一个基于前沿模型的聊天功能，单次对话成本大约是 30 美分。而同功能的蒸馏版本，单次对话成本大约只有 0.3 美分。这并不是同一个产品的两种实现方式，而是两个截然不同的产品。它们有着不同的免费层级经济模型、不同的获客成本、不同的市场定位以及不同的竞争护城河。如果一个团队只是将蒸馏版本当作“更便宜的同款功能”发布，那就白费了这一招。

大多数工程组织仍将蒸馏视为研究团队的优化任务，认为是在功能“完成”后，为了挤出推理成本而对已经按前沿模型规格设计好的东西进行的后期处理。这种理解在数量级上就是错误的。Teacher 模型（教师模型）的选择、Student 模型（学生模型）的选择、用于评测 Student 的评估套件，以及 Student 最终部署的产品界面，本质上都是产品决策。它们决定了你同意放弃哪些能力、你为哪种流量形态进行设计，以及你正在开启哪种价格底线。如果把这些交给研究团队去针对 MMLU 进行优化，你最终发布的模型虽然在榜单上表现优异，但对产品本身毫无意义。