MLOps 与 LLMOps 运维指南：模型建成后如何持续稳定运行

MLOps 是什么，为什么需要它

所有工业机器学习项目的目标都是构建 ML 产品并迅速投入生产环境。然而，MLOps 概述研究（paper）指出，由于难以自动化和运维，许多项目未能取得预期成果。该研究结合文献调研、工具调研和专家访谈，梳理了 MLOps 所需的原则、组件、角色和架构，并给出了定义。

Google Cloud 文档（w1）指出，真正的难点不在于构建模型，而在于构建集成的 ML 系统并让它在生产环境中持续运行。在实际系统中，ML 代码只占一小部分，配置、数据收集、数据验证、资源管理、服务基础设施、监控等周边要素范围广且复杂。CD4ML 一文（w4）也引用 2015 年 Google 论文《Hidden Technical Debt in Machine Learning Systems》指出了同样的问题。ml-ops.org（w2）将 MLOps 的目的概括为避免机器学习应用中不断累积的“技术债务”。

它与一般软件有何不同？CD4ML 一文（w4）解释说，ML 应用会在代码、模型和数据三个维度上发生变化。Google Cloud 文档（w1）认为，即使代码没有问题，只要输入数据的特性不断变化，模型性能也可能下降。因此需要跟踪数据的汇总统计和模型的在线性能，一旦偏离预期就发出告警或回退到之前的版本（回滚）。总之，MLOps 是将 DevOps 原则引入 ML 系统、把开发（Dev）和运维（Ops）统一起来的工程文化与实践（w1）。

组件：由什么构成

先来看模型投入生产之前的流程。Google Cloud 文档（w1）按以下顺序说明：数据提取、数据分析、数据准备（清洗、划分训练/验证/测试集、特征工程）、模型训练、模型评估、模型验证（确认是否优于基线）、模型服务、模型监控。服务方式有三种：以带 REST API 的微服务提供在线预测，将模型部署到边缘或移动设备，或者作为批量预测系统的一部分运行。

要将这一流程自动化，就需要工具。ml-ops.org（w2）列出的组件如下：源代码管理（代码、数据、模型的版本管理），测试与构建服务，部署服务，存放已训练模型的模型注册表，在训练和服务中以相同方式处理输入的特征存储，记录模型名称、参数、训练/测试数据和指标结果的 ML 元数据存储，以及自动串联各实验步骤的流水线编排器。

CD4ML 一文（w4）也给出了类似的清单：易于发现和访问的数据、可复现的模型训练、模型服务、测试与质量、实验跟踪、模型部署、持续部署编排、模型监控与可观测性。ml-ops.org（w2）还总结了为什么需要版本管理：当用新数据或新训练方法重新训练时、当性能随时间下降时、当遭受攻击需要修复时、当需要快速回退到之前版本时、当需要应对监管机构或公司审计时，都必须能够访问所有生产模型版本。

自动化成熟度：从手动到完全自动

Google Cloud 文档（w1）和 ml-ops.org（w2）认为，这些步骤的自动化程度决定了 ML 流程的成熟度。越成熟，用新数据或新实现重新训练模型的速度就越快。ml-ops.org（w2）将其分为三个阶段。第一是手动流程，用 Jupyter Notebook 等工具由人工完成从数据准备到训练、测试的全部工作。第二是 ML 流水线自动化，新数据到来时自动开始重新训练，并加入数据和模型验证步骤。第三是 CI/CD 流水线自动化，自动构建、测试和部署数据、模型及训练流水线组件。

Microsoft 的 Azure 文档（w3）将其进一步细分为五个级别。级别 0“无 MLOps”：构建、部署、训练和测试全部手动，模型性能没有集中跟踪。级别 1“有 DevOps 但无 MLOps”：应用代码的构建和测试已自动化，但结果难以跟踪和复现。级别 2“训练自动化”：训练实现自动化，训练性能跟踪集中到一处，模型管理开始成形；部署仍是手动的，但很容易。级别 3“模型部署自动化”：部署自动进行，可以从已部署模型追溯到原始数据，A/B 测试纳入部署流程。级别 4“完全自动化运维”：漂移（数据或性能逐渐偏移的现象）或性能下降信号会自动触发重新训练。

这些级别不只是技术问题。根据 Microsoft 文档（w3），在级别 0，数据科学家、数据工程师和软件工程师各自为战，交付物往往只是一个手动移交的模型文件。从级别 2 开始，数据科学家和数据工程师合作，把实验代码改写成可重复运行的脚本。该文档指出，一个组织同时呈现多个级别的特征是很常见的，建议把这些级别看作连续的光谱，而不是割裂的台阶。

CI·CD·CT：机器学习中有所不同的持续集成

DevOps 的两大支柱是持续集成（CI）和持续部署（CD）。Google Cloud 文档（w1）解释说，在 ML 中这两者的含义有所扩展。CI 不仅要测试和验证代码与组件，还要测试和验证数据、数据模式和模型。CD 不是发布单个软件包，而是部署训练流水线这一系统，再由该流水线自动部署预测服务。此外还加入了 CT（Continuous Training，持续训练），即自动重新训练模型并提供服务，这是 ML 系统独有的特性。ml-ops.org（w2）还补充了 CM（Continuous Monitoring，持续监控），意思是将生产数据和模型性能指标与业务指标关联起来持续观察。

测试也会增多。Google Cloud 文档（w1）指出，除了常规的单元测试和集成测试，还需要数据验证、已训练模型的质量评估和模型验证。关于触发重新训练的条件，ml-ops.org（w2）列出了预定计划、消息、监控事件，以及数据、训练代码和应用代码的变更。

CD4ML 一文（w4）将这一原则概括为“以小而安全的增量、可复现地、随时处于可部署状态”。如果软件始终处于可部署状态，那么何时部署就不再是技术问题，而是业务决策。该文的目标是把开发周期从几周或几个月缩短到几天或几小时，并建立从生产中模型行为学习、进而改进模型的反馈闭环。

LLMOps 中的不同之处

Microsoft 文档（w5）将 GenAIOps（也称 LLMOps）定义为在生产环境中管理大语言模型（LLM）的实践与策略。Databricks（w6）将 LLMOps 视为针对 LLM 对 MLOps 的扩展，并说明 MLOps 的大部分运维要求仍然适用。Microsoft 的 MLOps 成熟度文档（w3）也指出，GenAIOps 并不取代 MLOps 成熟度级别，而是对其加以补充，增加了提示生命周期、检索增强（RAG）、输出安全、token 成本等能力。

Databricks（w6）详细总结了有哪些变化。第一，与其从零训练模型，更常见的是从基础模型出发，用新数据进行微调。第二，GPU 等专用硬件在训练和部署中都变得必不可少，而推理成本使模型压缩和蒸馏（知识蒸馏）技术变得重要；超参数调优也不仅用于提高准确率，还用于降低成本。第三，打磨提示模板的提示工程成为核心工作，它也用于降低幻觉、提示注入、敏感信息泄露和越狱的风险。第四，借助 LangChain 或 LlamaIndex 等工具串联多次 LLM 调用、并连接向量数据库或网络搜索来构建流水线，比构建新的 LLM 更成为开发的重心。

评估和观测方式也会变化。传统 ML 使用准确率、AUC、F1 等计算明确的指标，而 LLM 评估需要 BLEU、ROUGE 等不同的指标（w6）。LLM 任务往往没有唯一的标准答案，因此最终用户的反馈对评估很重要。把这些反馈接入流水线，既能简化评估，也能获得后续微调所需的数据（w6）。Microsoft 文档（w5）建议使用有据性（groundedness）、相关性、相似度等评估指标以及内容安全。Databricks（w6）建议在监控流水线中对模型漂移和恶意用户行为都设置告警。

Microsoft 文档（w5）将 GenAIOps 成熟度分为初始（initial）、已定义（defined）、已管理（managed）、已优化（optimized）四个阶段。在初始阶段，熟悉多种 LLM API，并开始结构化提示设计和基本评估指标。在已定义阶段，推进到 CI/CD 集成、高级评估指标和内容安全。在已管理阶段，加强主动监控、微调、版本管理和回滚。

分阶段引入方法

把各输入资料共同建议的方向按初次起步的顺序整理如下。第一，从一个用例开始。ml-ops.org（w2）建议一次只处理一个 ML 用例，并指出在设计阶段应考察所需数据、确定模型的功能与非功能需求，预先设计架构、服务策略和测试套件。

第二，搭建版本管理和实验跟踪。不仅对代码，也对数据和模型做版本管理，并在元数据存储中记录哪些参数和数据得出了哪些指标（w2、w4）。按 Microsoft 成熟度（w3）来看，这是从级别 1 迈向级别 2 的准备。第三，将训练流水线自动化，加入数据验证和模型验证，然后把已训练的模型存入模型注册表（w1、w2）。第四，用 CI/CD 自动化流水线和模型部署，并接入 A/B 测试（w3 的级别 3）。第五，接入生产监控，让漂移或性能下降信号触发重新训练（w3 的级别 4）。

如果是 LLM 应用，可以遵循 Microsoft 文档（w5）的顺序：先熟悉 LLM API 和结构化提示设计，引入基本评估指标，然后逐步扩展到 CI/CD 集成、有据性等高级评估和内容安全。Microsoft 文档（w3）建议用成熟度模型评估当前状态、设定切实可行的成功标准，不要一开始就承担完整实现的复杂度，而应逐步提升能力。

检查清单与常见错误、局限

实际需要确认的项目如下：代码、数据和模型是否都做了版本管理？实验结果和训练性能是否集中记录？是否有数据验证、模型质量评估和模型验证测试？是否在确认新模型优于基线后再部署？能否快速回退到之前的服务版本？是否监控数据汇总统计和在线性能，并在偏离时收到告警？收到审计请求时，能否访问生产中使用过的模型和数据的所有版本（w1、w2、w3）？如果是 LLM 应用，还要加上：是否管理提示的版本和生命周期？是否用有据性等指标进行评估？是否关注 token 成本？是否对漂移和恶意使用设置了告警（w3、w5、w6）？

也有一些常见错误。CD4ML 一文（w4）把数据工程师、数据科学家和 ML 工程师在没有就预期达成一致的情况下，把各自负责的部分“隔墙扔给”下一个团队的组织结构列为首要问题。像 Microsoft 级别 0（w3）描述的那样，在实验结束后手工编写评分脚本且不做版本管理，也很常见。只看离线测试集性能就认为大功告成也很危险，因为数据一旦变化，生产中的性能就会下降（w1）。

还需要了解其局限。MLOps 概述研究（paper）指出，MLOps 仍是一个含糊的术语，对研究者和从业者而言含义并不明确。Google Cloud 文档（w1）主要针对预测型 AI 系统，Microsoft 成熟度文档（w3）也以预测型、表格型和传统 ML 为中心，因此难以直接照搬到 LLM 上。还要记住，工具变化很快。Microsoft 文档（w5）已公告其 Prompt flow 将于 2027 年 4 月 20 日停用。比起特定工具，先掌握原则更为稳妥。

延伸学习

初学者最好先读 Google Cloud 文档（w1）。它在一条主线上讲解了 DevOps 与 MLOps 的区别、ML 开发阶段、CI·CD·CT 以及成熟度级别。接着从 ml-ops.org 的原则文章（w2）中梳理组件表、持续 X（CI·CD·CT·CM）和版本管理的理由，就能掌握实务术语。

想获得实际实现的感觉，CD4ML 一文（w4）最合适。它以销量预测示例应用，端到端地串起数据、训练、服务、实验跟踪和监控。想诊断自己的组织处于什么位置，可以查看 Microsoft 的 MLOps 成熟度文档（w3）中按级别划分的人员、流程、技术表。学术定义和尚未解决的问题由 MLOps 概述研究（paper）进行了梳理。

LLM 方面，建议先在 Databricks 一文（w6）中了解它与 MLOps 有何不同，再在 Microsoft 的 GenAIOps 成熟度文档（w5）中确认每个阶段要增加哪些能力。