模型注册与发布

训练产出的检查点不是终点——从 TB 级分片检查点到可用的服务模型，中间有一整条发布管道：格式转换、评测门禁、注册、版本管理、灰度发布。本章讲清楚模型发布的完整链路与版本管理的实践。

从检查点到可发布模型

分片训练检查点（见检查点）不能直接服务，要经过：

分片训练检查点（dcp/DS 格式）
  ↓ 合并/转换
标准权重格式（safetensors，FP16/BF16，单文件或分片）
  ↓ 评测门禁（见[评测基础设施](#)）
注册入库（版本、元数据、血缘）
  ↓
发布（灰度 → 全量，见[服务框架](/inference-serving/03-frameworks/serving-frameworks.md)）

每一步的目的：

步骤	目的
合并转换	训练分片 → 推理友好的标准格式（safetensors：安全、快、零 pickle）
评测门禁	质量不达标的模型不能发布（自动化的门禁）
注册	版本、血缘（哪个实验产出的）、元数据的唯一可信源
发布	灰度验证 → 全量，回滚预案

模型注册：唯一可信源

模型注册表（model registry）是模型资产的目录：

元数据	内容
版本	语义化版本（v1.2.3）或 hash，不可变
血缘	训练实验的链接（配置、数据版本、代码 commit，见实验管理）
评测报告	各基准的分数 + 评测时间（链接到评测基础设施）
权重信息	精度、分片、大小、tokenizer 版本
状态	实验 → 候选 → 生产 → 归档

三个设计原则：

一、不可变版本：发布的模型版本不可变（重训 = 新版本）——回滚与对比的基础。

二、血缘完整：每个生产模型能追溯到"哪个实验、什么配置、什么数据"——事故排查与合规的基础。

三、状态机管理：实验 → 候选 → 生产的晋升是显式流程（不是"拷个文件"）——门禁与审批的载体。

版本管理的实践

场景	实践
重训同配方	新版本号（v1.2 → v1.3），血缘链接同实验
热修复（量化/格式）	patch 版本（v1.2.1），血缘标注"基于 v1.2"
微调/下游	独立命名空间（base-v1.3 + task-x），记录基座版本
回滚	服务配置指回上一版本（秒级，权重已在存储里）

基座与下游的关系：下游微调模型要记录基座版本——基座出问题（bug、数据）时，能找出所有受影响的下游。

发布：灰度与回滚

模型发布的标准流程（与软件发布同构）：

阶段	动作	验证
灰度	5–10% 流量到新版本	在线指标（延迟、错误率）+ 抽样质量
放量	逐步 50% → 100%	持续监控
回滚预案	上一版本保持热备	回滚是秒级（配置切换）

推理侧的灰度有特殊性：模型质量的问题（幻觉率、风格）不是即时指标——抽样人工评估（灰度期对真实请求抽样对比新旧版本）是模型发布特有的验证手段。

与数据/tokenizer 的版本联动

模型不只是权重——tokenizer、系统提示、推理配置都是模型的一部分：

tokenizer 版本变了 = 新模型（词表不兼容）
推理配置（采样参数、系统提示）的版本也要管理（行为的一部分）
"模型 = 权重 + tokenizer + 配置"的完整打包是发布的单位

工程实践清单

注册表是唯一可信源（别用"共享盘上的目录"当注册表）
safetensors 发布（零 pickle，安全）；训练检查点用分片格式
每个生产模型有完整血缘（实验/数据/代码）
灰度 + 抽样质量评估；回滚秒级预案
tokenizer/配置与权重一起版本化

本章要点

发布管道：分片检查点 → safetensors 转换 → 评测门禁 → 注册 → 灰度发布。
注册表是唯一可信源：版本（不可变）、血缘（实验/数据/代码）、评测报告、状态机。
统计复现的结论依赖血缘；事故排查与合规的基础也是血缘。
灰度的特殊性：模型质量问题不是即时指标，抽样人工评估是模型发布特有的验证。
"模型 = 权重 + tokenizer + 配置"一起版本化；基座与下游的版本联动。
回滚是秒级（配置切换），靠"上一版本保持热备"支撑。