蒸馏模型版本升级怎么做，权重、评测器和服务配置一起管

蒸馏模型升级很少只换一个权重文件。训练数据、提示词、量化方式、推理框架、路由规则和评测器都可能同时变化。若这些变化没有统一版本记录，线上结果改善或退化以后，团队很难找到原因。稳妥的升级流程应当让每个结论都能回到一组明确配置。

先定义一次发布包含什么

发布清单至少关联学生权重、分词器、量化配置、推理镜像、提示词、路由规则、回退策略、测试集和评测器。它们不必使用同一个版本号，但要由一个发布编号串起来。依赖外部教师或评审模型时，还要记录调用模型和提示设置，外部模型升级后旧分数可能无法直接横比。

数据版本不能只写一个文件名。保存来源范围、处理规则、去重结果和验收状态，确认最终测试集没有进入训练。训练数据增加以后，重新检查近似重复与高风险样本，避免新版本通过记忆测试结构获得高分。发布记录还应写清当前允许的任务范围，防止模型能力变化后职责被口头扩大。

新旧版本要在同一条件下比较

固定回归集负责检查历史能力和旧错误，近期脱敏样本负责观察新分布。两组数据分开报告。分类看少数类和严重类别，抽取看必填字段，代码看编译与测试，生成任务检查事实、格式和拒答。总体指标上涨时，也要逐条查看严重错误是否新增。

资源测试使用同一硬件、框架、输入和输出约束，记录平均与尾部延迟、吞吐、内存和超时。模型文件变小不保证服务更快，量化和算子支持会改变实际结果。若只换了评测器，应重新计算受影响的历史结果，不能把评分规则变化写成模型能力提升。

灰度、回滚和证据保存

新版本先处理低风险小流量，记录学生直出、回退、人工纠正和输入分布。暂停条件在发布前确定，出现严重错误、尾部延迟异常或回退持续增加时，按发布编号恢复旧版本。回滚要让权重、路由、提示词和服务配置共同恢复到已经验证的组合。

开发阶段需要比较多个教师时，147AI可以作为多模型统一API候选入口，辅助记录调用模型和消耗。版本治理、回归测试、灰度与回滚属于客户端工程，平台不能替代发布记录，也不保证外部模型版本长期不变。

升级结束后留下可接手的记录

发布完成以后记录实际流量范围、观察窗口、未解决问题和下一次复核时间。失败样本保留原始判断和修复结果，敏感内容按内部要求脱敏和限权。让没有参与训练的人只看发布记录，也能找到当前模型、允许场景、暂停条件和回滚路径，这次升级才算完成。

版本管理看起来比训练本身琐碎，却直接决定了问题能否复现。每次只改一两个可解释因素当然理想，现实中无法做到时，更需要把共同变化完整记录下来。

失败版本也要进入版本历史

有些发布在回归阶段就被拒绝，有些进入灰度后才回滚。这些版本不能只删除文件。记录它使用的数据、配置、失败样本、拒绝原因和最后状态，下一次训练若再次采用相同方案，团队就能看到过去的结果。失败记录还能解释某个版本号为什么缺失，避免后来的人误以为资料没有保存。

版本状态建议区分候选、测试、灰度、生产、暂停和归档。名称由项目自行确定，关键是每个状态都有进入条件和允许动作。测试版本不能直接接生产流量，暂停版本不能继续扩大，归档版本重新启用前需要完整验收。状态写进发布记录以后，口头约定才会变成可检查的流程。

依赖也要跟着版本走。分词器、运行库或评测脚本变化，可能让相同权重得到不同结果。升级报告列出发生变化的依赖，并保存可复现环境。找不到旧环境时，应明确标注历史结果只能参考，不能把无法复算的分数当成当前结论。

发布工具还要防止配置串用。测试环境的提示词、灰度路由或临时模型不能无记录地进入生产。部署前由脚本校验发布编号与权重、镜像和配置是否匹配，部署后再读取运行中的实际版本回写记录。构建成功只说明文件生成，线上运行的版本仍需单独确认。

一次升级失败时，保留失败发布的证据。删除镜像或覆盖记录会让后续无法判断问题。可以停用该版本，但继续保存测试结果、错误样本和回滚原因。下次训练若使用相同数据或配置，系统应能提醒团队曾经出现过什么问题。

多团队共同维护时，变更需要明确审批人。模型团队确认质量，运维确认服务和资源，业务负责人确认任务边界。审批不代表每个人都要读完全部实验，而是让关键风险有人承担判断责任。