4.4 模型注册中心与版本治理
文档摘要
4.4 模型注册中心与版本治理 代码用 Git 管版本，模型用什么？答案是「模型注册中心」——它把模型从「文件系统里的一堆 .bin」变成「可版本、可追溯、可晋升、可回滚」的资产，是 MLOps 把模型作为一等公民治理的核心组件。 4.4.1 为什么 Git 不够：模型版本管理的特殊性 一个常见误区是「模型文件放 Git 不就行了」。但模型文件有几个特性让 Git 不堪重负： 体积大：单个模型几十 MB 到几 GB，大模型可达几十 GB 甚至 TB 级，Git LFS 也吃力。 二进制：Git 的 diff/merge 对二进制无效，无法做内容级版本管理。 多维版本：模型版本不只是「代码版本」，还要绑定数据版本、超参、评估指标。
4.4 模型注册中心与版本治理
代码用 Git 管版本，模型用什么？答案是「模型注册中心」——它把模型从「文件系统里的一堆 .bin」变成「可版本、可追溯、可晋升、可回滚」的资产，是 MLOps 把模型作为一等公民治理的核心组件。
4.4.1 为什么 Git 不够：模型版本管理的特殊性
一个常见误区是「模型文件放 Git 不就行了」。但模型文件有几个特性让 Git 不堪重负：
- 体积大：单个模型几十 MB 到几 GB，大模型可达几十 GB 甚至 TB 级，Git LFS 也吃力。
- 二进制：Git 的 diff/merge 对二进制无效，无法做内容级版本管理。
- 多维版本：模型版本不只是「代码版本」，还要绑定数据版本、超参、评估指标。
- 多环境：同一个模型要区分 Dev/Staging/Production 环境，Git 分支模型不直观。
- 审批流：模型上线需要业务评审、灰度门禁，Git 的 PR 流程对模型不够用。
所以业界演化出了模型注册中心（Model Registry） 这一专门组件，它把模型当作「带元数据、有生命周期的资产」来管理。
4.4.2 模型注册中心的核心抽象
主流模型注册中心（MLflow Model Registry、W&B Artifacts、Vertex AI Model Registry）都围绕几个核心抽象构建：
Registered Model（已注册模型）
一个逻辑模型实体，如 rec-xgboost、llama3-finetune-zh。它是版本的容器。
Model Version（模型版本）
Registered Model 下的具体版本，如 v1、v2、v3。每个版本绑定：
- 模型文件（权重、配置）。
- 来源（哪个实验、哪个 Pipeline run）。
- 元数据（超参、指标、Git commit、数据版本）。
Model Stage / Tag（阶段与标签）
版本在生命周期中的「阶段」，常见四阶段：
- None / Archived：归档，不再使用。
- Development：开发中，未评估。
- Staging：已通过评估，待生产灰度。
- Production：生产环境。
这种阶段流转模型让模型的「生命周期」可视化、可治理——任何时候都知道「线上跑的是哪个版本、它从哪里来、什么时候上的线」。
4.4.3 模型注册中心 vs Git：互补而非替代
模型注册中心不替代 Git，而是与 Git 互补：
| 维度 | Git | 模型注册中心 |
|---|---|---|
| 管理对象 | 训练代码、配置 | 模型权重、产物 |
| 版本粒度 | 行级 diff | 整体版本快照 |
| 元数据 | commit message | 多维（数据/超参/指标） |
| 阶段流转 | 分支/标签 | Staging/Production |
| 审批流 | Pull Request | 晋升审批 + 灰度门禁 |
| 体积支持 | KB-MB 级 | GB-TB 级 |
理想的协作模式是：
- 代码在 Git：训练脚本、配置、Pipeline 定义走 Git 的 PR 流程。
- 模型在注册中心：训练产出的模型文件进注册中心，绑定 Git commit + 数据版本 + 指标。
- 晋升走门禁：从 Staging 到 Production 的晋升，走模型注册中心的审批 + 灰度门禁，而非 Git PR。
4.4.4 模型卡 Model Card：模型的「说明书」
Model Card（模型卡） 是 Google 提出的一种模型文档标准，类似食品的「营养成分表」。一份完整的 Model Card 应包含：
- 模型概况：用途、架构、输入输出。
- 训练数据：数据来源、规模、标注方式、潜在偏差。
- 评估方法：指标定义、测试集、基线对比。
- 评估结果：分人群/分场景的指标 disaggregated。
- 伦理与限制：适用边界、已知偏差、风险警示。
- 维护信息：负责人、更新计划、联系方式。
| Model Card 章节 | 关键内容 |
|---|---|
| 模型概况 | 用途、架构、I/O |
| 训练数据 | 来源、规模、偏差 |
| 评估方法 | 指标、测试集、基线 |
| 评估结果 | 分人群指标 |
| 伦理限制 | 边界、风险 |
| 维护信息 | owner、更新计划 |
Model Card 在 LLM 时代尤为重要。Hugging Face 等模型平台把 Model Card 作为「模型发布标准」，没有完整 Model Card 的模型不被推荐使用。一份优秀的 Model Card 让用户清楚「这个模型能做什么、不能做什么、有哪些风险」，是负责任 AI 的基础实践。
4.4.5 阶段晋升与门禁
从 Development → Staging → Production 的每一步晋升，都应有门禁（Gate） 把关，而不是人工手动操作：
Dev → Staging 门禁
- 离线评估达标（指标超基线）。
- 单元测试通过（预处理、推理代码）。
- Model Card 完整填写。
- 至少一位 Reviewer 审批。
Staging → Production 门禁
- Staging 环境灰度 A/B 测试达标（线上指标不劣化）。
- 性能压测达标（延迟、吞吐满足 SLO）。
- 安全审计通过（无后门、无偏差风险）。
- 业务方签字。
💡 判读：阶段门禁是 MLOps 2 级成熟度的标志。一个团队如果模型上线靠「人记忆哪个版本好」，那是 0-1 级；如果靠「注册中心 + 自动门禁」，那才是 2 级。门禁不仅是质量保障，更是「让模型上线决策可追溯、可审计」的治理机制。
4.4.6 回滚：从异常中快速恢复
即使门禁严格，线上模型仍可能出问题（效果衰退、偏差、用户投诉）。这时回滚（Rollback） 是救命的能力。
模型注册中心让回滚变得简单：
- 线上跑的是 Production 阶段的当前版本。
- 注册中心保留了历史版本（上一次 Production、更早的版本）。
- 回滚 = 把 Production 标签指向上一个版本（一条命令/一次配置变更）。
- 推理服务（如 KServe）监听 Production 变化，自动切换部署的模型。
回滚的几种触发方式：
| 触发方式 | 说明 | 响应速度 |
|---|---|---|
| 手工回滚 | 运维发现异常，手工切换 | 慢（分钟级） |
| 自动指标回滚 | 监控发现线上指标劣化，自动回滚 | 快（分钟级） |
| 金丝雀回滚 | 灰度期间发现问题自动回滚灰度 | 极快（秒级） |
| 蓝绿回滚 | 蓝绿部署切换 | 快（秒级） |
⚠️ 现实代价：回滚的前提是「上一次 Production 还在注册中心」。许多团队为了节省存储清理得太积极，等需要回滚时发现旧版本已经被删了。建议至少保留最近 N 个 Production 版本（如 5 个），关键模型保留更多。
4.4.7 A/B 测试与影子部署
阶段晋升之外，模型注册中心还支持多种上线策略：
A/B 测试
把流量按比例分给多个模型版本（如 90% v3.2 + 10% v3.3），对比业务指标。这要求推理服务能按流量比例路由，并把请求标记来源版本以便统计。
影子部署（Shadow Deployment）
新版本不接收真实流量，而是「镜像」一份线上请求并发给它，对比新旧版本的输出，但不影响用户。用于在生产流量下验证新模型，而不冒风险。
金丝雀部署（Canary Deployment）
新版本先接收一小部分流量（如 1%），监控无异常后逐步放大（5% → 20% → 100%）。任何阶段发现异常立即回滚。
| 策略 | 流量分配 | 用途 |
|---|---|---|
| 全量替换 | 100% 新 | 确定性更新 |
| A/B 测试 | 多版本并行 | 业务指标对比 |
| 影子部署 | 0%（镜像） | 生产流量验证 |
| 金丝雀 | 渐进放大 | 风险控制 |
这些策略的实现需要推理服务支持「多版本路由」（详见第 6 章 KServe）。模型注册中心提供版本，推理服务负责路由，二者协作完成上线治理。
4.4.8 主流模型注册中心对比
| 项目 | 类型 | 特点 | 适用 |
|---|---|---|---|
| MLflow Model Registry | 开源 | 与 MLflow Tracking 一体、开源标准 | 通用自建团队 |
| W&B Artifacts | 商业 | 与 W&B Tracking 一体、UI 强 | W&B 用户 |
| Vertex AI Model Registry | 商业云 | GCP 原生 | GCP 用户 |
| SageMaker Model Registry | 商业云 | AWS 原生 | AWS 用户 |
| Hugging Face Hub | 开源 SaaS | LLM 时代事实标准、Git-LFS 支持 | LLM 模型共享 |
Hugging Face Hub 的特殊性：它在 LLM 时代演化为「模型注册中心 + 模型分发 + 协作平台」的混合体。许多团队把内部模型注册中心与 HF Hub 镜像结合——内部用 MLflow 治理，对外发布到 HF Hub。这是 LLM 时代模型管理的新形态。
4.4.9 模型治理的合规与审计
在企业级（尤其金融、医疗）场景，模型治理还涉及合规与审计：
- 模型审计日志：谁、何时、为什么把哪个版本晋升到 Production，全部留痕。
- 模型清单（Model Inventory）：企业内所有生产模型的清单，含用途、负责人、风险等级。
- 模型风险评级：按业务影响给模型分级，高风险模型需更严的门禁。
- 法规合规：如欧盟 AI Act 对高风险 AI 系统的文档与审计要求。
这些治理要求是 LLM 时代日益突出的议题——随着大模型被广泛部署，监管机构对「模型从哪来、谁负责、风险多大」的关注度持续提升，模型注册中心作为「模型资产的权威记录」，是合规审计的基础。
4.4.10 第 4 章小结与第 5 章预告
到这里，第 4 章完成了 MLOps 流水线层的全景：
- MLOps 全景闭环（4.1）：七大组件、成熟度模型。
- 特征存储（4.2）：根治 training-serving skew、Point-in-Time 正确性。
- 实验跟踪（4.3）：可追溯、可复现、可比对。
- 模型注册（4.4）：版本治理、阶段晋升、回滚。
这四块合起来，构成了「模型作为工程产物」的完整治理体系。第 5 章将聚焦其中的「训练」环节，讲分布式训练与 Kubeflow Pipelines 的 DAG 编排，把本章的特征、实验、注册串联成自动化的训练流水线。
本节小结
- 模型文件体积大、二进制、多维版本，Git 不堪重负，需要专门的模型注册中心。
- 模型注册中心核心抽象：Registered Model（逻辑实体）、Model Version（具体版本）、Stage（生命周期阶段：Dev/Staging/Production/Archived）。
- 模型注册中心与 Git 互补：代码在 Git、模型在注册中心、晋升走门禁。
- Model Card 是模型的「说明书」，包含概况、数据、评估、伦理、维护，是负责任 AI 的基础。
- 阶段晋升要配门禁：Dev→Staging 评估达标、Staging→Production 灰度达标，让上线决策可追溯。
- 回滚能力是救命稻草：注册中心保留历史版本，配合推理服务的版本切换实现秒级回滚。
- 上线策略：A/B 测试、影子部署、金丝雀部署，需推理服务支持多版本路由。
- 主流方案：MLflow（开源通用）、W&B（商业体验）、Hugging Face Hub（LLM 时代事实标准）。
- 企业级治理：审计日志、模型清单、风险评级、法规合规，是 LLM 时代日益突出的议题。
第 4 章完结。下一章《第 5 章 分布式训练与 Kubeflow Pipelines》将讲清大模型怎么分布式训练、训练流水线怎么编排。