AI 系统为什么需要 MLOps，它与传统 DevOps 到底有哪些不同

AI 系统进入生产环境以后，真正困难的部分往往不再是“把模型训练出来”，而是怎样让这个模型长期稳定、可追踪、可回滚，并且能够随着数据和业务变化持续更新。传统软件可以在代码通过测试之后打包、部署、监控，发现 Bug 再修改代码；机器学习系统却多了一层非常特殊的变量：模型的行为不仅由代码决定，还受到训练数据、特征工程、标签质量、超参数、模型版本以及线上数据分布影响。也正因为如此，传统 DevOps 的工程方法进入机器学习领域之后，需要进一步扩展为 MLOps。

DevOps，也就是 Development and Operations，核心思想是把软件开发、测试、部署和运维连接起来，通过版本控制、持续集成、持续交付、自动化测试和基础设施自动化，让软件能够更快、更稳定地进入生产环境。传统 Web 服务通常可以把代码视为系统行为的主要来源。只要代码版本、依赖环境和配置能够被准确记录，同一个版本的软件通常就可以重新构建和部署。

机器学习系统却不是这样。

假设一个推荐模型今天使用 model-v17，明天使用 model-v18。如果只保存两个模型文件，很多关键问题仍然无法回答：这个模型到底使用了哪一批训练数据？数据当时经过什么清洗？特征工程代码是哪一个版本？使用了什么 Python、CUDA 和深度学习框架？训练使用了哪些超参数？训练过程中使用了什么硬件？最终验证集指标是多少？

因此，MLOps 首先需要解决的是“可复现性”。

在传统软件开发中，Git 通常可以记录主要代码变化。但机器学习项目除了代码之外，还存在规模可能达到数GB、数TB甚至PB级别的数据集。数据本身不适合简单地全部放进 Git，因此实际系统往往需要数据版本管理、对象存储、数据目录以及模型注册机制共同工作。DVC 等工具可以参与数据和模型文件版本管理，但它只是整个体系中的一个组件，并不是 MLOps 的必选标准。

更重要的是，数据版本和代码版本必须能够建立关联。

例如一个模型上线后出现性能下降，工程团队需要知道它究竟是模型结构发生变化，还是训练数据发生变化。如果只记录“模型从 v17 更新到了 v18”，却没有保存训练数据版本和特征处理代码，那么出现问题以后很容易陷入一种非常尴尬的状态：模型文件还在，但当时究竟怎样训练出来的已经无法完整复现。

这也是机器学习系统与普通软件最大的工程区别之一。软件的输入主要由运行时请求决定，而机器学习模型已经把历史数据中的统计规律“写入”模型参数。训练数据发生变化，就可能改变模型行为。

因此，MLOps 的 CI/CD 也不应该只是“代码提交后自动部署”。

更准确地说，机器学习领域经常使用 CI、CT、CD 三个概念。CI 是 Continuous Integration，持续集成；CD 可以表示 Continuous Delivery 或 Continuous Deployment；CT 则经常被用于表示 Continuous Training，也就是持续训练。

持续训练并不意味着“每天自动训练一次模型”。真正成熟的系统应该根据业务条件决定什么时候重新训练。例如训练数据规模达到某个程度、数据分布发生明显变化、模型线上指标持续下降，或者业务规则发生变化时，才可能触发重新训练。

这里就出现了传统 DevOps 不太需要面对的一类问题：数据漂移。

假设一个金融风控模型最初使用过去两年的交易数据训练。上线之后，用户行为、经济环境或者欺诈模式发生变化，线上数据的分布逐渐偏离训练数据。即使程序代码一行都没有修改，模型的预测质量也可能下降。

从传统 DevOps 的角度来看，这个服务可能完全正常：服务器在线、CPU正常、内存正常、HTTP返回200、容器没有崩溃。

但从 MLOps 的角度来看，系统可能已经出现严重问题。

所以 MLOps 的监控不能只监控 CPU、内存、磁盘、网络、HTTP 5xx 和请求延迟，还需要观察机器学习模型自身的指标。例如分类模型可能关注 Precision、Recall、F1、ROC-AUC；回归模型可能关注 MAE、RMSE 等；推荐系统可能关注 CTR、转化率或者其他业务指标。

不过，这里又比单纯监控模型准确率复杂，因为线上系统通常并不知道每一条预测结果的真实标签。

例如信用风险模型今天预测了100万笔交易，但真实结果可能需要几周甚至几个月以后才能知道。如果等到所有标签都回来以后才发现模型已经退化，监控系统就已经晚了一步。

因此生产环境还需要监控输入数据本身，包括特征分布、缺失率、异常值比例、类别变化以及训练数据和线上数据之间的分布差异。常见概念包括 Data Drift 和 Concept Drift，但二者并不是完全相同的问题。前者主要关注输入数据分布发生变化，后者则涉及输入与目标变量之间关系的变化。

模型服务的资源管理也是 MLOps 与传统 DevOps 差异明显的地方。

一个普通 Web API 可能主要消耗 CPU 和内存，而大型机器学习模型可能需要 GPU。不同模型的显存需求、批处理能力、推理延迟和吞吐量差异非常大。一个模型可能适合单请求实时推理，另一个模型则可能更适合批量推理。

因此，部署模型不能只考虑“容器是否启动成功”。

还需要考虑模型加载时间、显存占用、GPU利用率、请求队列长度、批处理大小、并发请求数以及 P50、P95、P99 延迟。特别是 GPU 服务，如果模型占用大量显存，但实际 GPU 利用率很低，单纯增加 GPU 数量可能只是增加成本，并没有提高吞吐量。

Kubernetes 可以提供容器编排和自动扩缩容能力，但 Kubernetes 本身并不等于 MLOps。它可以帮助部署模型服务，却不能自动解决训练数据版本、模型质量、数据漂移和模型回滚等问题。

同样，MLflow 也不能单独等同于完整的 MLOps 平台。MLflow 可以承担实验跟踪、模型注册等重要工作，但实际生产系统还需要数据存储、训练平台、CI/CD、容器环境、模型服务、监控系统和权限管理等多个组件。

因此，一个典型的 MLOps 流程可能是：

数据进入数据平台
↓
数据质量检查
↓
特征处理
↓
训练任务
↓
实验记录与指标比较
↓
模型验证
↓
模型注册
↓
部署到测试环境
↓
自动化验证
↓
生产部署
↓
线上推理
↓
模型、数据和业务指标监控
↓
满足条件后重新训练

其中任何一个环节都可能成为生产事故的来源。

例如模型训练完成之后，离线验证集的 F1 提升了5%，看起来非常漂亮，但上线之后业务转化率却下降。原因可能并不是模型算法本身，而是训练数据与线上数据存在分布差异，或者特征工程在训练环境和生产环境中的实现并不完全一致。

这就是所谓的 Training-Serving Skew，也就是训练和线上推理之间的数据处理不一致。

如果训练阶段把某个字段进行了标准化，而生产推理阶段使用了另一套标准化逻辑，那么模型即使完全没有改变，线上结果也可能出现明显变化。对于复杂 AI 系统，这种问题甚至比传统软件中的普通 Bug 更难发现，因为程序本身可能完全正常运行。

因此，MLOps 需要特别强调数据和特征处理的一致性。

在团队协作方面，传统 DevOps 通常围绕开发人员、测试人员和运维人员展开，而 MLOps 往往需要数据科学家、机器学习工程师、数据工程师、平台工程师和运维团队共同参与。不同角色关心的问题并不一样。

数据科学家关心模型指标和实验结果；数据工程师关心数据质量和数据流水线；机器学习工程师关心训练、模型服务和推理性能；平台工程师关心 GPU、容器、集群和资源调度；业务团队则更关心模型最终是否改善收入、风险控制、推荐点击率或者其他业务指标。

MLOps 的价值就在于把这些不同层面的工作连接起来。

不过，MLOps 并不是要取代 DevOps。更准确地说，它是在 DevOps 工程体系之上增加机器学习系统所需要的数据、模型和实验管理能力。

可以把两者的核心对象简单理解为：

传统 DevOps
代码
配置
构建
测试
部署
基础设施
服务监控

MLOps
代码
数据
特征
训练环境
实验
模型
模型服务
数据监控
模型监控
业务指标

这也是为什么一个成熟的 AI 系统通常不能仅仅依靠“训练一个模型 + 部署一个 API”来完成。

真正进入生产环境之后，模型会面对新的数据、新的用户、新的业务规则和新的硬件环境。昨天效果不错的模型，今天可能仍然能够正常运行，但并不代表它今天仍然适合业务。

所以，MLOps 真正解决的不是“如何把 AI 模型部署出去”，而是如何让模型从实验室走向生产环境以后，仍然能够被追踪、验证、监控、更新和回滚。

对于小规模项目，完整建立一套复杂的 MLOps 平台可能反而增加维护成本。一个模型、几个工程师、每天几千次推理的内部工具，没有必要一开始就部署一整套庞大的机器学习平台。Git、对象存储、容器、基础监控和简单的模型版本记录可能已经足够。

但当模型数量增加、训练数据持续变化、GPU成本开始明显上升，或者模型直接影响订单、广告、风控、推荐等核心业务时，MLOps 的价值就会迅速提高。因为到了这个阶段，真正昂贵的已经不只是计算资源，而是一个模型出现问题以后，团队能不能准确知道发生了什么、能不能恢复到上一版本，以及能不能证明当前生产模型究竟是用什么数据和代码训练出来的。

最终可以把 MLOps 理解为机器学习系统的工程化生命周期管理。DevOps 解决的是软件怎样稳定地构建、测试、发布和运行，而 MLOps 在此基础上继续回答数据怎样管理、模型怎样复现、训练怎样自动化、线上性能怎样监控以及什么时候应该重新训练。机器学习最大的特殊性，是代码不变并不代表系统行为不变；只要数据、环境和现实世界发生变化，模型就可能发生变化。因此，真正成熟的 AI 系统，必须把代码、数据、模型和生产指标放在同一条可追踪的工程链路中。