1.3 从 MLOps 到 LLMOps：云原生承载的演进路径

文档摘要

1.3 从 MLOps 到 LLMOps：云原生承载的演进路径 MLOps 解决的是「怎么把模型工程化地跑起来」，LLMOps 解决的是「怎么把一个会吞噬算力的大模型经济地跑起来」——同一个工程化命题，但在大模型时代被推到了全新的难度。 1.3.1 MLOps：把 DevOps 思想引入机器学习 MLOps（Machine Learning Operations，机器学习运维）是 DevOps 思想在机器学习领域的延伸。它的目标是让 ML 模型的开发、部署、运维像传统软件一样自动化、可复现、可监控、可持续。理解 MLOps 的关键是认识到它比传统 DevOps 多出来的复杂度。

1.3 从 MLOps 到 LLMOps：云原生承载的演进路径

MLOps 解决的是「怎么把模型工程化地跑起来」，LLMOps 解决的是「怎么把一个会吞噬算力的大模型经济地跑起来」——同一个工程化命题，但在大模型时代被推到了全新的难度。

1.3.1 MLOps：把 DevOps 思想引入机器学习

MLOps（Machine Learning Operations，机器学习运维） 是 DevOps 思想在机器学习领域的延伸。它的目标是让 ML 模型的开发、部署、运维像传统软件一样自动化、可复现、可监控、可持续。

理解 MLOps 的关键是认识到它比传统 DevOps 多出来的复杂度。传统软件只需要管「代码」，而 ML 系统要同时管「代码 + 数据 + 模型」三件套，这就是 Google 著名的 ML 代码 vs ML 系统对比图所揭示的——ML 系统中真正的 ML 代码只占很小一部分，外围环绕着配置、数据收集、特征工程、 serving、监控等一大圈基础设施。

维度	DevOps	MLOps
版本管理对象	代码	代码 + 数据 + 模型
部署产物	二进制	模型权重 + 推理容器
质量指标	功能、性能	还要管模型精度、漂移
上线后行为	代码不变则行为不变	数据变了模型效果就变（数据漂移）
回滚单位	代码版本	模型版本 + 数据版本

💡 判读：MLOps 比 DevOps 多出来的复杂度，本质上是因为 ML 系统的行为不仅由代码决定，还由数据决定。这要求 MLOps 必须把数据作为一等公民纳入版本管理与监控。

1.3.2 MLOps 成熟度模型：三级跃迁

Google 在 MLOps 白皮书中提出了著名的三级成熟度模型，刻画团队 ML 工程化的演进路径。这三级是评估任何 AI 团队现状的标准尺子：

第 0 级（手工流程）：数据科学家在 notebook 里手工完成数据分析、训练、验证，手工导出模型，交给工程团队部署。这是 1.1 节描述的困境原型，全程无自动化、无复现性。
第 1 级（训练流水线自动化）：训练被封装成可重复执行的流水线（Pipeline），由触发器（数据更新、定时任务）自动跑。模型实验可追踪、可复现。但部署仍是手工或半自动。
第 2 级（CI/CD 流水线自动化）：训练与部署都进入 CI/CD 闭环，代码、数据、配置变更自动触发训练，评估达标的模型自动晋升上线。这是 MLOps 的最终形态。

大多数团队的真实状态是「0.5 级」或「1.2 级」——介于两级之间。MLOps 的演进不是一蹴而就的，而是逐级提升自动化范围。

1.3.3 LLMOps：大模型时代的新挑战

当大语言模型（LLM）登场后，MLOps 的复杂度再次跃升，催生了 LLMOps（Large Language Model Operations，大模型运维） 这个新分支。LLMOps 不是 MLOps 的简单延续，而是面对一组全新的工程化挑战：

挑战维度	传统 MLOps	LLMOps
模型体积	MB 级	GB 甚至 TB 级
训练成本	单卡数小时	千卡数周，百万美元级
微调方式	全参训练	LoRA/QLoRA 等参数高效微调
推理模式	一次性预测	自回归逐 token 生成
上下文管理	无	KV Cache、长上下文
评估维度	准确率/F1	人工/LLM-as-Judge、多维度
Prompt	无	Prompt 工程与版本治理
智能体	无	Agent 编排、工具调用

下面把其中最关键的几个新挑战展开。

挑战一：推理成本与延迟的极致博弈

传统 ML 模型推理通常是毫秒级、几乎免费。LLM 推理则是「自回归逐 token 生成」，一个长回复要算几十次前向传播，单次请求成本可能是传统模型的几千倍。

这迫使 LLMOps 把「推理效率」提到前所未有的高度——vLLM 的 PagedAttention、量化、投机解码、PD 分离（详见第 6-7 章）都是为了把推理成本打下来。传统 MLOps 很少为推理效率单独立章，而 LLMOps 必须把推理优化作为核心议题。

挑战二：Prompt 治理与版本管理

传统 ML 的「输入」是结构化特征，相对稳定。LLM 应用的「输入」除了用户 query，还包括精心设计的 System Prompt、Few-shot 示例、工具描述。这些 Prompt 的一个字改动都可能导致行为剧变。

LLMOps 需要 Prompt 版本管理——把 Prompt 当作代码一样纳入 Git、做 A/B 测试、回归评估。这是传统 MLOps 完全没有的维度。

挑战三：评估的开放性难题

传统 ML 评估有明确的测试集与指标（准确率、AUC）。LLM 评估则面临「开放性」难题：同一个回答的好坏取决于上下文、风格、安全性等多重维度，难以用单一指标衡量。

LLMOps 引入了 LLM-as-Judge（用大模型当评委）、人工标注平台、多维评分卡 等新评估范式。这要求把评估流程也工程化、自动化。

挑战四：Agent 与工具调用的编排

大模型不仅能「回答问题」，还能「调用工具、规划任务、执行多步推理」，这就是 Agent（智能体）。Agent 应用涉及多轮 LLM 调用、工具执行、状态管理、错误恢复，工程复杂度远高于单轮问答。

LLMOps 需要为 Agent 提供专门的编排框架（如 LangGraph、AutoGen 模式）、调用追踪、错误处理与可观测性。

1.3.4 MLOps 与 LLMOps 在云原生栈中的落点

无论是 MLOps 还是 LLMOps，它们最终都跑在云原生基础设施上。下表把两者的关键组件映射到云原生栈：

能力	MLOps 组件	LLMOps 组件	云原生承载
特征/数据管理	Feast、Tecton	LakeFS、DVC + 语料库	对象存储 + K8s CRD
训练编排	Kubeflow Pipelines、Training Operator	+ DeepSpeed、Ray Train	K8s Operator + Pipeline
实验跟踪	MLflow、W&B	MLflow、W&B + Prompt 层	K8s 任务 + 元数据存储
模型注册	MLflow Model Registry	+ Hugging Face Hub 镜像	模型仓库 + 镜像仓库
推理服务	KServe、Seldon	vLLM、TGI、Triton	K8s Deployment + InferenceService
监控可观测	Prometheus + 模型漂移监控	+ Token 吞吐/延迟/Prompt 追踪	Prometheus + Grafana

⚠️ 注意：MLOps 与 LLMOps 的边界并非泾渭分明。许多组件是共享的（如 MLflow 既能管传统模型也能管 LLM 的微调产物），区别更多在于「重点不同」：MLOps 重特征与漂移，LLMOps 重推理效率与 Prompt。

1.3.5 一张图理解演进：从单机到大模型平台

把传统 ML → MLOps → LLMOps 的演进画成一张时间轴，可以看到工程化复杂度的持续攀升：


<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 880 360" font-family="sans-serif" font-size="13">
  <!-- 标题 -->
  <text x="440" y="26" text-anchor="middle" font-size="15" font-weight="bold">从单机到云原生：AI 工程化的演进时间轴</text>

  <!-- 时间轴 -->
  <line x1="60" y1="200" x2="820" y2="200" stroke="#475569" stroke-width="2"/>

  <!-- 阶段节点 -->
  <g>
    <circle cx="120" cy="200" r="8" fill="#dc2626"/>
    <text x="120" y="230" text-anchor="middle" font-weight="bold">2015 前</text>
    <text x="120" y="250" text-anchor="middle">单机 Notebook</text>
    <text x="120" y="170" text-anchor="middle" font-size="11" fill="#64748b">环境地狱</text>

    <circle cx="300" cy="200" r="8" fill="#ca8a04"/>
    <text x="300" y="230" text-anchor="middle" font-weight="bold">2018</text>
    <text x="300" y="250" text-anchor="middle">容器化 ML</text>
    <text x="300" y="170" text-anchor="middle" font-size="11" fill="#64748b">环境封装</text>

    <circle cx="480" cy="200" r="8" fill="#16a34a"/>
    <text x="480" y="230" text-anchor="middle" font-weight="bold">2020</text>
    <text x="480" y="250" text-anchor="middle">MLOps 兴起</text>
    <text x="480" y="170" text-anchor="middle" font-size="11" fill="#64748b">流水线自动化</text>

    <circle cx="660" cy="200" r="8" fill="#2563eb"/>
    <text x="660" y="230" text-anchor="middle" font-weight="bold">2023</text>
    <text x="660" y="250" text-anchor="middle">LLM 时代</text>
    <text x="660" y="170" text-anchor="middle" font-size="11" fill="#64748b">vLLM/推理优化</text>

    <circle cx="800" cy="200" r="8" fill="#7c3aed"/>
    <text x="800" y="230" text-anchor="middle" font-weight="bold">2024+</text>
    <text x="800" y="250" text-anchor="middle">LLMOps</text>
    <text x="800" y="170" text-anchor="middle" font-size="11" fill="#64748b">Agent/Prompt 治理</text>
  </g>

  <!-- 复杂度曲线 -->
  <path d="M 120 320 Q 300 315 480 295 T 800 270" fill="none" stroke="#7c3aed" stroke-width="2" stroke-dasharray="5,3"/>
  <text x="440" y="340" text-anchor="middle" font-size="12" fill="#7c3aed" font-style="italic">— — 工程化复杂度持续攀升</text>
</svg>

可以看到，每一步演进都不是「推翻重来」，而是「在云原生底座上叠加新能力」：容器化解决了环境、MLOps 解决了流水线、LLMOps 解决了推理效率与 Prompt。这也是为什么本书要按四层架构组织——每一层都是前一层的延伸，而非替代。

本节小结

MLOps = DevOps + 数据/模型三件套，比传统 DevOps 多了「数据版本、模型版本、漂移监控」三个维度。
MLOps 三级成熟度（手工 → 训练流水线 → CI/CD）是评估团队现状的标准尺子，多数团队处于 1 级左右。
LLMOps 是 MLOps 在大模型时代的延伸，核心新挑战包括推理成本、Prompt 治理、开放性评估、Agent 编排。
MLOps 与 LLMOps 共享同一套云原生底座，区别在于「重点不同」：前者重特征与漂移，后者重推理与 Prompt。
从单机到 LLMOps 的演进是层层叠加，本书四层架构正对应这条演进路径。

下一节《1.4 CNCF AI 生态全景与本书地图》将绘制完整的开源项目谱系图，并把本书各章在生态中定位清楚。