模型工程系列新篇。团队跑模型业务三个月后，通常会面对一个失控的局面：几十个模型版本散落在各个机器和对象存储里，prompt 改了不知道是哪个版本在线上，上次那个效果很好的配置找不回来了。这篇讲怎么把模型相关的产物——权重、配置、prompt、评测结果——纳入版本管理，变成可追溯的资产。
先定义「模型资产」的四个组成部分
- 权重：模型本体。版本间可能差几个 GB，不能塞 git——需要专门的存储与寻址
- 配置：推理参数（temperature、采样策略）、量化方案、部署拓扑
- Prompt/模板：系统提示、few-shot 样例、输出格式约束——业务侧迭代非常频繁的部分
- 评测记录：每个版本在哪些评测集上跑出什么分数——资产的价值证明
版本化的核心：把这四者绑定
单独管理每一类都不难（权重有 registry、代码有 git），难的是绑定：「线上跑的这个效果，到底是哪个权重的哪个配置加哪个 prompt」——这个问题的答案就是一个版本快照。定义版本 = 权重哈希 + 配置 commit + prompt commit + 评测报告 ID 的四元组，每次发布固化一条快照记录。
有了快照，回滚、复现、对比才有抓手：效果退化时 diff 相邻两个快照（配置变了？prompt 变了？权重变了？），三分钟定位变量——而不是翻聊天记录考古。
权重管理的实操
- 命名规范：模型名-基座版本-微调/量化标识-日期序号（如 trans-model-v3-ft-int8-1021），杜绝 final_final2.bin
- 注册表：中心化登记（哪怕就是一张数据库表）：哈希、大小、训练数据摘要、上游来源。没有登记的权重不允许部署——这是把「来路不明文件」挡在生产线外的硬闸
- 存储分层：热（当前线上+备胎）/温（最近 N 个版本）/冷（历史归档），与日志冷热分层的思路一致
Prompt 的版本化：容易被漏的一环
Prompt 是「藏在代码里的模型行为」。三个实践：
- prompt 从代码里抽出来，进独立版本库（或配置中心）——改 prompt 走评审流程，不是工程师顺手一改
- 线上生效的 prompt 带 commit ID 透出（响应头或日志），排查「今天回答风格怎么变了」时能直接对上版本
- prompt 变更跑评测回归（上一篇的评测流水线）——它对输出质量的影响不亚于换模型，享受同等待遇
评测记录：资产的价值锚
每个版本快照挂上评测报告：哪些用例集、什么分数、和上一版的对比。三个月后你面对「要不要回退到 9 月的版本」时，评测记录是唯一的决策依据。没有评测记录的版本库只是文件堆。
数据血缘：进阶但值得
训练数据的摘要（数据集版本、采样比例、清洗规则）进版本快照——当某天模型输出出现系统性偏差时，能追溯到「那次用了哪批数据」。这对微调频繁的团队是刚需，对纯 API 调用团队可以先跳过。
从哪里起步（一周计划）
- 第 1~2 天：清点存量——线上在跑什么、存储里躺着什么、哪些来路不明
- 第 3~4 天：建注册表 + 命名规范，把存量全部登记（来路不明的标记隔离）
- 第 5 天：把「版本快照」写进发布流程——上线必填快照四元组
- 之后：prompt 独立库 + 评测挂钩，按迭代节奏逐步补齐
模型资产的版本管理没有炫技的部分，全是纪律——但三个月后当监管问「你们线上模型的训练数据来源」或老板问「上次效果好的配置去哪了」时，有和没有这套体系，是五分钟答复和一周考古的区别。
（模型工程系列：迁移评估 → 竞技场 → 网关路由 → 扩缩容 → 评测流水线 → 多模型混部 → 本文：版本管理）
