AI 平台中的 CI/CD 应该管理什么，代码、模型、数据和配置如何分别处理

传统软件项目中的CI/CD主要围绕源代码展开，而AI平台的情况更加复杂。一个可以正常运行的机器学习系统，除了代码之外，还依赖训练数据、模型文件、运行环境、配置参数以及具体的部署版本。代码发生变化可能需要重新训练模型，数据发生变化可能导致模型重新评估，模型更新又可能要求重新部署推理服务。真正成熟的AI平台，并不是把所有东西都塞进CI/CD，而是明确区分不同资产的生命周期，再通过自动化流水线把它们连接起来。

代码仍然是CI/CD最熟悉的对象。Git等版本控制系统负责保存训练代码、数据处理代码、推理服务代码、基础设施配置以及测试代码。CI系统则可以在提交代码后执行单元测试、静态分析、依赖检查、安全扫描和构建任务。对于AI系统，训练代码和推理代码最好明确区分，因为二者的运行环境和资源需求通常不同。训练程序可能依赖GPU、分布式训练框架和大量数据，而推理服务更加关注启动时间、延迟、并发能力和资源利用率。

代码构建的目标不是简单地“把源代码打包起来”，而是产生能够被准确识别的构建产物。容器镜像通常可以作为推理服务的部署载体，其中记录具体的代码版本、依赖版本和运行时环境。生产部署时，与其使用不断变化的latest标签，不如记录不可变的容器镜像digest。这样出现问题时，才能明确知道线上运行的究竟是哪一个构建版本。

模型则需要单独的生命周期管理。训练得到的模型文件可能是几十MB，也可能达到GB甚至更大，因此模型并不一定应该直接放进Git仓库。实际系统通常会把模型文件作为模型制品存放在对象存储或专门的Artifact Store中，再通过模型注册中心记录模型名称、版本、训练数据版本、代码提交、评估指标、创建时间以及当前生命周期状态。

模型注册中心与模型文件存储是两个不同概念。注册中心负责管理模型的身份和元数据，真正的大型模型文件可以存放在对象存储中。类似Model Zoo这样的模型集合更适合用于提供或共享预训练模型，并不能简单等同于企业内部的模型注册中心。企业自己的生产模型，需要能够追踪训练过程、版本、评估结果和部署状态。

模型版本也不能孤立管理。一个生产模型至少应该能够回答几个基本问题：这个模型由哪一版代码训练？使用的是哪一版数据？训练时采用了什么参数？使用了什么运行环境？最终部署到了哪个服务？如果这些信息无法对应起来，那么模型出现性能下降或者线上故障以后，工程团队很难准确定位变化来自代码、数据、模型还是配置。

模型部署与模型训练也应该分开。训练阶段可能需要GPU集群、分布式计算和长时间运行的作业，而推理阶段通常需要持续运行的服务、自动扩缩容和低延迟响应。一个模型训练完成后，可以经过验证、评估和审批，再进入生产部署流程。生产服务使用哪个模型版本，应该成为明确的部署配置，而不是让服务启动时随意下载一个“最新模型”。

数据管理比普通软件项目更加复杂，因为数据通常规模巨大，而且会不断变化。AI平台需要记录数据来源、采集时间、清洗过程、特征处理、数据版本以及质量检查结果。数据版本控制的重点并不是一定要把每一份原始数据复制进Git，而是让系统能够准确知道某一次训练究竟使用了哪一批数据。

对于规模较大的数据集，可以采用对象存储、数据湖、数据仓库或者专门的数据版本管理方案保存实际数据，再通过版本标识、快照、manifest或者数据血缘信息记录训练输入。这样既能够避免代码仓库被大型数据文件占满，也能够让训练结果具有可追溯性。

数据质量检查同样可以进入CI/CD体系，但需要理解它与代码测试的区别。代码测试主要回答“程序是否按照预期工作”，数据质量检查则需要回答“输入数据是否满足模型和业务要求”。例如可以检查字段缺失、数据类型、重复记录、异常范围以及关键字段分布变化。对于机器学习系统，还可以进一步检查训练数据与生产数据之间是否出现明显分布变化。

数据漂移也不能简单理解为模型已经失效。Data Drift描述的是输入数据分布发生变化，而Concept Drift则涉及输入与目标变量之间关系发生变化。模型是否需要重新训练，最终还需要结合业务指标、模型性能和数据变化程度判断。CI/CD可以负责触发评估或训练流程，但不应该机械地规定“数据一变化就重新训练”。

配置管理则需要解决另一个问题：同一套代码、模型和服务，在不同环境中可能采用不同参数。数据库连接、对象存储地址、模型路径、CPU和GPU资源、超时时间、批处理大小、日志级别以及服务副本数量，都可能属于配置。

小型项目完全可以通过Git管理声明式配置文件，而大型平台也可以使用配置中心、Secrets管理系统和基础设施即代码工具。配置中心不是AI平台的必需品，真正重要的是配置应该具有版本、权限、审计和回滚能力。密码、API密钥和其他敏感信息则不应该直接写进Git配置文件，而应该使用专门的Secrets管理机制。

配置变更也不一定都需要灰度发布。对于影响线上流量的推理参数，例如模型版本、副本数量、资源限制和关键服务参数，灰度或逐步发布能够降低风险；而对于某些开发环境参数，直接部署可能就足够。发布策略应该根据变更的风险和服务特征决定。

AI平台中的CI/CD因此更像一个协调层，而不是一个“万能仓库”。代码仓库保存源代码和部分声明式配置，模型注册中心记录模型版本和生命周期，模型制品存储保存实际模型文件，数据系统保存数据及其版本信息，Secrets和配置系统管理运行参数，容器镜像仓库保存应用运行环境。CI/CD负责验证这些资产、构建制品、执行测试、触发训练或评估，并把经过验证的版本部署到目标环境。

例如一次模型更新可以形成这样一套关系：训练代码提交产生代码版本，训练流水线读取指定的数据版本，训练完成后生成模型制品，模型注册中心记录模型版本和训练元数据，CI/CD构建对应的推理服务镜像，部署系统再同时引用明确的镜像digest和模型版本。这样出现问题时，可以快速定位到底是推理代码、模型文件、训练数据还是运行配置发生了变化。

这种设计也解释了为什么“模型更新就重新构建整个容器镜像”并不是唯一方案。如果推理代码和运行环境没有变化，而只是模型权重更新，那么完全可以保持容器镜像不变，只替换经过验证的模型制品。相反，如果模型格式需要新的推理引擎，或者代码需要支持新的输入输出结构，那么就应该同时产生新的应用构建版本。

服务网格和API网关可以在这个体系中发挥作用，但它们解决的是服务之间的通信、路由、安全和流量管理问题，并不是代码、模型、数据和配置的版本管理工具。把服务网格作为AI资产依赖管理的核心，会混淆基础设施层与资产生命周期管理层的职责。

真正成熟的AI平台，需要建立的是可追溯关系，而不是把所有东西强行统一。一次生产推理请求应该能够追溯到具体的应用代码版本、容器镜像digest、模型版本和必要的配置版本；一次训练任务则应该能够追溯到训练代码、数据版本、特征处理逻辑、超参数和运行环境。只有这些关系能够被记录，CI/CD才真正具备持续交付AI系统的能力。

因此，AI平台中的CI/CD并不应该简单复制传统DevOps的流程，也不应该试图直接“管理所有数据”。更合理的方式是让不同资产各司其职，再通过自动化流水线建立明确的版本关系和发布流程。代码负责软件逻辑，数据负责训练输入，模型负责学习结果，配置负责运行参数，而CI/CD负责验证、构建、编排和交付。这样才能让AI系统从一次能够运行的实验，逐渐变成一个可以持续维护、回滚、审计和稳定发布的生产系统。