大模型更新后旧学生模型要不要重做蒸馏，先算清这三笔账

教师模型换了版本，旧学生模型要不要重新蒸馏，不能靠版本号决定。企业先要回答三个问题。新教师在自己的业务任务上是否真的更好，旧学生是否仍能稳定完成原来的工作，重做数据和训练需要付出多少完整成本。三项答案都没有拿到之前，直接重训通常只是把不确定性换成一笔确定的支出。

我查阅了 Google 的模型迁移说明、NVIDIA NeMo 的蒸馏文档和模型更新回归研究。公开资料的共同建议是先评测，再决定是否调整提示、重新调优或迁移。蒸馏训练中教师提供学习信号，学生接受更新，教师与学生的版本、数据和评测结果应该能够追溯。下面给出一套工程上可执行的核算方法，金额、阈值和停止条件均属于企业内部建议口径。

第一笔账是新教师到底带来什么改善

新版本在公开榜单上提高，并不等于企业流程得到改善。先拿上线前保留的回归集做对照，旧教师、新教师和当前学生处理同一批任务。样本要覆盖固定格式、长输入、工具调用和历史严重错误。

记录业务验收通过率、结构错误、严重错误、人工修改量、延迟和完整任务成本。新教师若只让回答更长，却增加解析失败，升级没有带来正收益。若只在罕见任务上改善，可以先把这些任务路由给新教师，不必立即重做全部蒸馏。

回归集还要与近期样本分开。旧集用于检查原有能力有没有退化，新集用于观察最近业务。两者混成一份，版本变化和任务变化会互相遮住。

第二笔账是旧学生还能不能继续工作

学生不必全面追上教师。固定、低风险、容易验收的任务，只要仍然稳定，就有继续保留的理由。企业可以按任务类别复算学生直出率、教师升级、严重错误和完整耗时。平均分没有下降，某个高风险任务的错误也不能被忽略。

模型更新可能改变提示理解、输出格式、拒答边界或工具调用。旧学生本身没有更新，也要重新跑与新教师相关的接口和业务回归。教师只是复杂任务的兜底时，学生是否重训应依据自己的输出，而不是教师版本的新旧。

如果旧学生已经频繁回退，先查回退原因。服务超时、解析器不兼容和新业务输入应从能力问题里分开。只有失败稳定落在学生无法掌握的任务边界，重做蒸馏才有明确目标。

第三笔账是训练的完整成本

重做蒸馏的费用不只是一批教师调用。还包括样本筛选、敏感信息处理、答案抽检、训练资源、离线评测、灰度、回滚和人工时间。建议把这些项目列在同一张内部预算表里，和继续使用旧学生、直接调用新教师的方案比较。

模型调用是否产生费用，应以调用记录与结算记录核对。失败请求、重试和流式中断不能用一个通用规则推断。人工时间可按企业内部标准估算，不需要伪装成行业统一会计方法。

完整任务成本比单次价格更适合做决定。学生先失败一次再调用教师，可能比新教师直接完成更慢，也多一段调用。新学生提高直出率以后，才可能抵消训练和部署成本。

先跑一轮不训练的迁移实验

第一步冻结当前学生、提示、路由和评测集，建立可回滚的基线。第二步只替换教师版本，跑代码回归和离线质量评测。第三步把近期真实任务按类别分桶，查看变化集中在哪里。第四步只对一个高频能力缺口生成少量候选数据，和旧数据做小实验。

每次只改一个主要变量。新教师、新提示和新学生同时变化，实验结果无法归因。Google 的迁移说明也将代码回归、模型表现测试和负载测试分开安排，企业可以按风险选择执行范围。

147AI在测试接入中能承担哪一层

如果团队需要同时测试多个教师和学生，可以评估统一 API 接入层。147AI公开信息显示支持多模型调用、多个 API Key，以及调用量、消耗和日志查看。企业可以按实验或环境拆分 Key，核对不同模型的使用情况。具体模型、价格和接口方式以当前页面为准。

接入层不会自动知道任务是否通过业务验收，也不能替代企业的权限、敏感数据和回滚管理。严格服务等级和特殊合规场景要单独核对合同与数据处理边界。

模型更新后，先把三笔账算清，再决定旧学生保留、局部重训还是全面迁移。训练不是版本升级的默认动作，证据才是。

工程上还应保留一份迁移决策单。它记录当前教师和学生的版本，受影响的任务类别，评测样本来源，已经发现的退化，拟采取的动作和回滚负责人。决策单不需要写成很长的报告，关键是几周后有人能复现当时的判断。

如果新教师只改变了输出表达，先改提示和解析器。如果新增任务没有可靠验收，先补业务标准。如果旧学生在一块固定工作上依然稳定，就让它继续服务。把不同问题分开以后，蒸馏训练才会针对真正的能力缺口。

参考资料

• Google 模型迁移说明
• NVIDIA NeMo 蒸馏文档
• 模型更新回归研究
• 147AI 公开状态信息