5.4 模型训练的 CI/CD 集成：从流水线到持续交付
文档摘要
5.4 模型训练的 CI/CD 集成：从流水线到持续交付 软件有 CI/CD——代码一提交，自动构建、测试、部署。ML 系统也需要 CI/CD，但管理对象从「代码」扩展到「代码 + 数据 + 模型」，触发条件也多了「数据更新」与「定时再训练」。这就是 MLOps 2 级的核心标志：训练成为持续交付的工程产物。 5.4.1 GitOps for ML：把 ML 也纳入 Git 化治理 GitOps 是云原生的运维哲学：「Git 是系统的唯一真相源」。任何系统状态变更都通过 Git 提交触发，CI/CD 自动驱动实际状态向 Git 声明收敛。这套哲学迁移到 ML 场景，就是 GitOps for ML： 代码在 Git：训练脚本、Pipeline 定义、配置。
5.4 模型训练的 CI/CD 集成：从流水线到持续交付
软件有 CI/CD——代码一提交，自动构建、测试、部署。ML 系统也需要 CI/CD，但管理对象从「代码」扩展到「代码 + 数据 + 模型」，触发条件也多了「数据更新」与「定时再训练」。这就是 MLOps 2 级的核心标志：训练成为持续交付的工程产物。
5.4.1 GitOps for ML：把 ML 也纳入 Git 化治理
GitOps 是云原生的运维哲学：「Git 是系统的唯一真相源」。任何系统状态变更都通过 Git 提交触发，CI/CD 自动驱动实际状态向 Git 声明收敛。这套哲学迁移到 ML 场景，就是 GitOps for ML：
- 代码在 Git：训练脚本、Pipeline 定义、配置。
- 数据版本在 Git：数据的版本指针（不是数据本身，是 DVC/LakeFS 引用）。
- 模型版本在 Git：部署声明的模型版本（如
production: rec-xgb@v3.2）。 - Pipeline 触发在 Git：Git 提交自动触发训练 Pipeline。
GitOps for ML 的核心价值：
- 审计：任何线上模型都能追溯到具体的 Git commit。
- 回滚：Git revert 即可回滚线上模型。
- 协作：模型变更走 PR review，而非某个人手工操作。
- 一致性：Dev/Staging/Prod 的模型版本声明都在 Git，一目了然。
5.4.2 数据版本化：DVC 与 LakeFS
GitOps for ML 的一个挑战是：Git 不擅长管大数据。模型文件已让 Git 吃力（5.4.0 节），TB 级训练数据更不可能塞进 Git。解决方案是数据版本管理工具——它们用 Git 管理数据的「指针」，而把数据本身放在对象存储里。
DVC（Data Version Control）
DVC 是最流行的开源数据版本工具。它的核心理念：用 Git 管版本，用对象存储存数据。
- 在 Git 仓库里，DVC 用一个
.dvc文件记录数据的元信息（哈希、大小、位置）。 - 实际数据存在对象存储（S3/OSS/GCS）。
dvc push把数据上传到对象存储，dvc pull按需拉取。- Git commit 一个
.dvc文件，就等于「数据版本固化」。
dataset.dvc 内容示意： md5: a1b2c3d4... path: dataset/ size: 1234567890
LakeFS
LakeFS 把数据版本管理做到「对象存储原生」。它在 S3/OSS 之上提供类似 Git 的分支、提交、合并能力，让数据仓库可以像代码仓库一样分支管理。
| 工具 | 模型 | 特点 | 适合 |
|---|---|---|---|
| DVC | Git + 对象存储指针 | 轻量、Git 原生 | 中小数据、与 Git 深度集成 |
| LakeFS | 对象存储原生分支 | 大数据、强一致性、Git-like API | 数据湖、TB-PB 级 |
| Delta Lake / Iceberg | 表格式 + 时间旅行 | 数据仓库内建版本 | 数仓场景 |
| Pachyderm | K8s 原生数据版本 | 与 K8s 流水线集成 | K8s 优先团队 |
💡 选型经验：小数据 + 强 Git 集成 → DVC；大数据湖 → LakeFS；已有数仓 → Delta/Iceberg；K8s 全栈 → Pachyderm。三者核心区别在于「版本化粒度与存储位置」，但目标一致——让数据像代码一样可版本、可分支、可回滚。
5.4.3 训练 Pipeline 的触发机制
CI/CD 的核心是「触发」。ML Pipeline 的触发比软件 CI/CD 多几类：
| 触发类型 | 时机 | 用途 |
|---|---|---|
| 代码触发 | 训练脚本/Pipeline 定义变更 | 模型逻辑变化 |
| 数据触发 | 数据版本更新 | 数据变化（最常用于 CT） |
| 定时触发 | 每天/每周 | 定期再训练 |
| 指标触发 | 监控发现漂移 | 自动再训练（CT 的最高形态） |
| 手工触发 | 人工点击 | 实验调试 |
持续训练（Continuous Training, CT）
持续训练是 MLOps 2 级的标志：当线上模型效果下降（数据漂移）时，系统自动触发再训练。它的回路是：
线上模型 → 监控预测分布 → 检测到漂移 → 触发再训练 Pipeline → 用最新数据重训 → 评估 → 通过门禁则晋升 Production
这种「自动闭环」让模型永远保持新鲜，无需人工干预。CT 的实现需要：
- 监控能识别漂移（第 8 章 8.1）。
- Pipeline 能被事件触发（而非手工）。
- 门禁能自动评估（指标达标自动晋升）。
- 数据版本能自动更新（最新数据可用）。
⚠️ CT 的风险：全自动 CT 可能产生意外后果——比如漂移检测误报导致频繁重训浪费算力，或新数据有偏差导致模型变差。生产中 CT 通常配合「人工审批门禁」（晋升 Production 需人工签字），完全自动的 CT 用于低风险场景。
5.4.4 CI/CD 的工具链
ML CI/CD 的工具链通常是「编排引擎 + GitOps + 模型注册」的组合：
| 角色 | 工具 | 职责 |
|---|---|---|
| CI 触发 | GitHub Actions、GitLab CI、Tekton | 检测 Git 提交，触发 Pipeline |
| Pipeline 编排 | KFP、Argo Workflows | 执行训练 DAG |
| GitOps 部署 | Argo CD、Flux | 监听 Git 变更，驱动推理服务部署 |
| 模型注册 | MLflow Model Registry | 模型版本与阶段管理 |
| 数据版本 | DVC、LakeFS | 数据版本管理 |
一个典型的端到端 CI/CD 链路：
1. 开发者提交代码 → Git 2. GitHub Actions 触发 → 调用 KFP Pipeline 3. KFP Pipeline 执行 → 训练 → 评估 → 注册模型到 MLflow（Staging） 4. MLflow Webhook 通知 → Argo CD 检测到 Staging 模型 5. Argo CD 在 Staging 环境部署 → 灰度 A/B 测试 6. 灰度达标 → 自动晋升 Production（更新 Git 中的 production 指针） 7. Argo CD 检测 Git 变更 → 在 Production 部署新模型 8. 监控 → 检测漂移 → 触发再训练（回到第 2 步）
5.4.5 模型晋升门禁
CI/CD 的核心是「门禁（Gate）」——任何模型晋升都要满足预设条件，避免坏模型污染线上。回顾第 4 章 4.4 节的阶段晋升门禁，在 CI/CD 中这些门禁是自动化的：
Dev → Staging 门禁（自动化）
- 离线指标达标（如 AUC > 基线 + 0.01）。
- 单元测试通过。
- Model Card 完整。
- 性能基准测试通过（延迟 < 阈值）。
Staging → Production 门禁（半自动化）
- Staging A/B 测试业务指标不劣化。
- 安全/偏差审计通过。
- 业务方审批（人工）。
- 灰度放量无异常。
Production 持续监控门禁
- 线上指标不下降。
- 无漂移告警。
- 用户投诉无异常。
门禁不通过的模型，要么回滚到上版本，要么回退到 Staging/Dev 继续调优。这种「门禁驱动」的晋升，让线上模型的质量有机制性保障。
5.4.6 CI/CD 的金丝雀与蓝绿部署
CI/CD 配合不同的部署策略，控制上线风险（与第 4 章 4.4 节呼应）：
金丝雀部署（Canary）
新模型先接收 1% 流量，逐步放大（5% → 20% → 100%）。任何阶段发现异常立即回滚。这是 ML 模型上线的最常用策略。
蓝绿部署（Blue-Green）
维护两套环境（蓝 = 旧版本，绿 = 新版本），切换流量从蓝到绿。验证稳定后销毁蓝。资源消耗大但切换瞬间完成。
影子部署（Shadow）
新模型并行跑但不影响用户，仅用于生产流量下的验证。最安全但最费算力。
| 策略 | 风险 | 资源 | 速度 | 用途 |
|---|---|---|---|---|
| 全量替换 | 高 | 低 | 快 | 紧急更新 |
| 金丝雀 | 低 | 中 | 中 | 常规首选 |
| 蓝绿 | 中 | 高 | 快 | 重要模型 |
| 影子 | 极低 | 极高 | 慢 | 风险验证 |
💡 判读：ML 模型的上线风险天然高于传统软件——传统软件 bug 通常立刻可见（崩溃、报错），而 ML 模型的问题可能「静默」（指标缓慢下降、隐性偏差）。因此金丝雀几乎是 ML 上线的标配，配合业务指标监控，能在问题扩散前捕获。
5.4.7 CI/CD 的工程实践
落地 ML CI/CD 的几个工程实践：
- 门禁代码化：所有门禁规则（指标阈值、性能基准）写在 Git 配置里，而非散落脚本。
- Pipeline 幂等：相同输入应产出相同结果，便于回滚与重跑。
- 环境隔离：Dev/Staging/Prod 用独立的模型注册中心阶段与 Git 分支，避免污染。
- 失败可见：Pipeline 失败要自动通知（Slack/邮件），并附失败原因与日志链接。
- 回滚演练：定期演练回滚流程，确保真正出事时能快速回滚。
- 数据快照：每次训练用到的数据快照要保存，便于事后追溯与重训。
- Feature Flag：用 Feature Flag 控制新模型的开关，比直接部署更灵活。
| 实践 | 价值 |
|---|---|
| 门禁代码化 | 规则可审计可版本 |
| Pipeline 幂等 | 可重跑可回滚 |
| 环境隔离 | 防 Dev 污染 Prod |
| 失败可见 | 快速响应 |
| 回滚演练 | 真出事能扛 |
| 数据快照 | 追溯重训 |
| Feature Flag | 灵活开关 |
5.4.8 LLM 时代的 CI/CD 新挑战
LLM 给 CI/CD 带来几个新挑战：
- 训练成本极高：一次完整 LLM 训练动辄百万美元，不可能每次提交都全量训练。LLM CI/CD 常用「增量微调」（LoRA）替代全量训练。
- 评估更难自动化：LLM 输出是开放式文本，AUC 这类指标不适用。要引入 LLM-as-Judge、人工评估、多维评分。
- Prompt 也是代码：Prompt 模板要纳入 Git 管理，Prompt 变更触发评估 Pipeline。
- 基座模型版本管理：基于哪个 base model（如 Llama-3-70B）微调，要严格版本化。
- RAG 知识库的 CI/CD：RAG 应用的「知识库」更新也要纳入 CI/CD，触发索引重建与评估。
LLM 时代的 CI/CD 更像「Prompt + LoRA + 知识库」三件套的协同管理，而非传统 ML 的「全量训练」。这种轻量化、增量化趋势，让 LLM 的迭代速度比传统 ML 快得多——但评估的复杂性也大幅上升。
5.4.9 第 5 章小结与第 6 章预告
到这里，第 5 章完成了「生产流水线层」的核心内容：
- 分布式训练范式（5.1）：DP/TP/PP + ZeRO + 3D 并行。
- K8s 训练编排（5.2）：Training Operator 与 Ray Train 两套方案。
- 流水线 DAG 编排（5.3）：Kubeflow Pipelines 把训练组织成可重跑的流水线。
- CI/CD 集成（5.4）：GitOps for ML + 数据版本化 + 自动化门禁，达成 MLOps 2 级。
这四块合起来，回答了「模型怎么工程化地训出来」的完整问题。第 6 章将进入下一层——「高效交付层」，讲清训练好的模型如何通过 KServe、vLLM、PagedAttention 等技术高效地服务化。
本节小结
- GitOps for ML 把代码、数据版本、模型版本统一纳入 Git 治理，让线上模型可追溯、可回滚、可协作。
- 数据版本化（DVC、LakeFS、Delta）解决「Git 不擅长管大数据」的问题，用 Git 管指针、对象存储存数据。
- ML Pipeline 的触发比软件 CI/CD 多：代码触发、数据触发、定时触发、指标触发（CT）、手工触发。
- 持续训练（CT）是 MLOps 2 级标志：监控检测漂移 → 自动再训练 → 自动评估晋升，让模型保持新鲜。
- CI/CD 工具链：GitHub Actions（触发）+ KFP（Pipeline）+ Argo CD（GitOps 部署）+ MLflow（注册）+ DVC（数据）。
- 模型晋升门禁：Dev→Staging 自动化指标门禁、Staging→Prod 半自动化业务门禁、Prod 持续监控门禁。
- 部署策略：金丝雀（常规首选）、蓝绿（重要模型）、影子（风险验证），金丝雀几乎是 ML 标配。
- 工程实践：门禁代码化、Pipeline 幂等、环境隔离、失败可见、回滚演练、数据快照、Feature Flag。
- LLM CI/CD 新挑战：增量微调（LoRA）、LLM-as-Judge 评估、Prompt 版本管理、RAG 知识库 CI/CD。
第 5 章完结。下一章《第 6 章 高性能推理服务（一）：服务化架构与 vLLM PagedAttention》将进入高效交付层。