CI/CD for ML：当你的模型训练需要跑72小时，持续集成还靠谱吗？

那个跑了3天然后失败的CI Job

2026年4月，我们在GitHub Actions上配了一个ML CI流水线。流程很简单：代码push → 触发训练 → 评估模型 → 如果AUC提升则自动部署。

第一次运行，第72小时，由于OOM失败了。不是因为代码Bug，而是因为训练数据比上次大了20%。GitHub Actions的免费额度直接烧光。这是"传统CI/CD思维"在ML场景下的经典翻车。

金句：传统CI/CD是"代码编译+测试"，ML CI/CD是"模型训练+评估"——前者几分钟，后者几小时到几天。

ML CI/CD的三个范式

范式一：流水线式（Pipeline CI/CD）。 适用于训练时间 < 1小时的小模型。CI直接执行训练+评估+部署。用自托管GPU Runner，不要用GitHub托管Runner。

范式二：触发式（Trigger-based CI/CD）。 适用于训练时间 > 1小时的大模型。CI只做代码检查和单元测试，训练由Kubeflow Pipelines或Airflow DAG触发。

范式三：事件驱动式（Event-driven CI/CD）。 适用于"数据更新 → 触发训练"的场景。当新数据到达S3时，自动触发训练Pipeline。使用AWS Lambda + Step Functions或Argo Events。

2026年ML CI/CD工具链推荐

代码CI：GitHub Actions / GitLab CI。Pipeline编排：Kubeflow Pipelines / Argo Workflows。模型注册：MLflow Model Registry。部署：ArgoCD / KServe。监控：Prometheus + Grafana。

ML CI/CD的独特挑战

挑战1：训练时间不可预测。 解决方案：用自托管Runner + 长时间超时 + checkpoint恢复。

挑战2：GPU资源昂贵。 解决方案：用Kubernetes GPU节点池 + 自动扩缩容，训练时拉起节点，训练后释放。

挑战3：CD的"评估门控"。 模型部署不是简单的"代码合并即部署"，而是"模型评估通过才部署"。在Pipeline中设置评估门控——只有新模型在所有评估指标上优于当前生产模型，才自动推进到部署阶段。

结论：ML CI/CD不是"把传统CI/CD套在ML上"，而是"为ML重新设计CI/CD"。 当你的模型训练需要跑72小时，你需要的是一个能管理72小时流水线的系统，而不是一个假设"一切在5分钟内完成"的系统。