第 19 章 模型版本与发布工程
第 19 章 模型版本与发布工程
学习目标
- 掌握模型注册表、模型仓库、制品管理的设计；
- 理解 CI/CD/CT：持续集成、持续交付、持续训练；
- 理解开发/测试/预发/生产的环境隔离；
- 掌握配置管理、密钥管理、权限控制；
- 掌握回滚、审计、合规的发布底线。
19.1 模型是「制品」：注册表与仓库
第 5 章讲过模型版本管理原则，这里落地成工程。模型与代码一样是制品（Artifact），要有仓库、有版本、有元数据、有审批流：
%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart LR
A[训练产物
权重+tokenizer+配置] --> B[模型注册表
版本+元数据+审批]
B --> C[制品仓库
对象存储/模型文件]
C --> D[部署环境
拉取指定版本]
B -.模型卡/数据卡.-> E[治理层]模型注册表（Model Registry） 是「模型的 git」：每个版本记录来源（训练 run、数据版本、代码 commit）、指标（评测分数）、审批状态（待审/已批/已废弃）。MLflow Model Registry、HuggingFace Hub、Seldon 都提供。
版本语义（第 5 章）：结构-压缩-版本 三段式，如 qwen2.5-7b-w4a16-v20260919。版本号是部署、回滚、审计的最小锚点——没有版本号的模型服务，出事时无法定位。
19.2 CI/CD/CT：持续集成、交付、训练
传统 CI/CD 管代码，ML 的 CI/CD/CT 要管「代码 + 数据 + 模型」：
| 环节 | 传统 | ML/LLM 版 |
|---|---|---|
| CI（持续集成） | 代码测试 | + 数据校验、模型格式校验、评测集回归 |
| CD（持续交付） | 构建发布 | + 模型打包、注册、部署到预发 |
| CT（持续训练） | 无 | 新数据自动触发重训/微调，评估后发布 |
%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart LR
A[数据变更] --> B[CT 触发微调]
B --> C[评测门禁
业务集]
C -->|通过| D[模型注册]
D --> E[CD 部署预发]
E --> F[金丝雀发布
第 16 章]
F -->|达标| G[全量]
C -->|不通过| H[拒绝发布
回滚数据/代码]评估门禁（第 9 章）是 CI/CD 的关卡：自动化评测（离线基准 + 业务集 + 回归集）不通过，模型不进发布线。这解决了「模型上线是拍脑袋」的问题——发布是流水线产物，不是个人决定。
CT 的触发源：数据漂移检测（第 22 章）、业务反馈回流、周期性重训计划、上游新基座（如新开源模型发布）。
19.3 环境隔离：开发、测试、预发、生产
模型发布要有和代码一样的环境链：
| 环境 | 用途 | 数据/模型 | 特点 |
|---|---|---|---|
| 开发 | 实验、Notebook | 小样本、开发模型 | 自由 |
| 测试 | 自动化评测、集成 | 评测集 | 门禁 |
| 预发（Staging） | 金丝雀、影子流量 | 生产副本 | 模拟生产 |
| 生产 | 全量服务 | 正式版 | 最严 |
LLM 环境的特殊性：预发环境要能「加载与生产相同的模型版本 + 相同的 Prompt 版本」，否则预发测不出问题；生产环境还要有「模型版本 + Prompt 版本」的组合回滚能力（第 16 章）。
19.4 配置管理、密钥管理、权限控制
- 配置管理：模型服务配置（模型版本、量化、batch、SLA）与环境分离（ConfigMap/Helm values），Promot 模板也是配置（第 5、17 章）——Prompt 变更走配置发布而非改代码；
- 密钥管理：API Key、数据库口令、对象存储凭证不能进镜像/仓库——用 K8s Secret / 云 KMS / Vault，注入到运行时；
- 权限控制：谁能在哪个环境发布哪个模型版本——审批流（第 19.1 的注册表审批）+ 环境权限隔离。
「配置漂移」是发布事故的头号来源：生产环境加载的模型版本、Prompt、量化参数与预发不一致——发布清单要「版本可追溯、环境可对齐」。
19.5 回滚、审计、合规
19.5.1 回滚
模型回滚比代码回滚复杂：不只是换权重，要同时回滚 Prompt、缓存、路由策略：
| 回滚项 | 说明 |
|---|---|
| 模型版本 | 权重换回上一版 |
| Prompt 版本 | 对话模板/系统提示换回 |
| 缓存 | 语义缓存/前缀缓存要带版本失效（第 16 章） |
| 路由 | 路由规则（第 15 章）按版本对齐 |
回滚触发：在线指标恶化（第 9、21 章）、安全事件、成本异常。回滚速度 = 平台底线：蓝绿/金丝雀架构（第 16 章）让回滚在分钟级完成。
19.5.2 审计与合规
发布留痕是合规底线（第 23 章展开 GDPR/AI Act）：
- 审计日志：谁、何时、把哪个模型版本、部署到哪个环境、用了什么配置；
- 模型卡/数据卡归档：每个发布版本的模型卡与数据卡（第 5 章）随版本留存；
- 可复现：版本 → 训练 run → 数据版本 → 代码 commit 的全链路可追溯（第 6 章血缘）；
- 合规：数据出域审批、模型输出的内容安全审查记录。
本章要点回顾
- 模型是制品：注册表（版本+元数据+审批）+ 仓库（文件）；版本号是部署/回滚/审计的最小锚点。
- CI/CD/CT 管「代码+数据+模型」；评估门禁是发布关卡，CT 让新数据自动进发布线。
- 环境链开发/测试/预发/生产；LLM 环境要模型版本与 Prompt 版本双对齐。
- Prompt 是配置（走配置发布）；密钥用 KMS/Vault；配置漂移是事故头号来源。
- 回滚 = 权重 + Prompt + 缓存 + 路由一起回；蓝绿/金丝雀让回滚分钟级。
- 审计 = 发布留痕 + 模型卡归档 + 血缘可追溯；合规在发布线内做。
习题
- 设计一个模型注册表的版本字段：至少要包含哪些元数据才能支撑「事故定位」？
- 画出你的 LLM 应用的 CI/CD/CT 流水线：触发条件、各阶段、门禁、回滚路径。
- 为什么 Prompt 变更要走配置发布而不是改代码？两种方式的差异与风险。
- 一次回滚事件中「语义缓存命中旧版本」会造成什么后果？如何设计缓存版本策略？
- 合规视角：一个金融客户要求「模型输出全留痕」，在设计发布工程时要加哪些能力？
延伸阅读
- MLflow Model Registry 文档
- HuggingFace Hub（模型仓库）文档
- GitHub Actions / GitLab CI 的 ML 流水线最佳实践
- Sculley et al., Hidden Technical Debt in Machine Learning Systems, 2015（ML 工程债，第 5 章也引过）
- 各云厂商 MLOps 白皮书（模型注册、CI/CD）
下一章预告
第 20 章分布式部署：多副本与多区域、混合云与边缘协同、分布式推理（张量/流水/专家并行）、服务网格与流量治理、联邦推理与分层推理、CAP 与成本权衡。