MLOps 与 LLMOps：当模型是 LLM 时，会发生哪些变化

MLOps 是用于可靠地开发、部署、版本管理和运维机器学习系统的工程学科；LLMOps 将这一学科扩展到围绕大语言模型构建的应用，在这类应用中，生产行为不仅取决于模型产物，还取决于提示词、上下文、检索、提供商/模型版本、工具调用、安全控制和评估流水线。LLMOps 并不取代 MLOps。它将运维单元从“一个模型加服务流水线”转变为“一个不断演进的 LLM 应用，其行为由多个独立变化的组件共同涌现”。

MLOps 的真正含义

MLOps 将软件工程和运维纪律应用于机器学习系统。生产挑战不仅仅是训练模型：数据收集、数据验证、实验、可复现性、模型评估、部署、基础设施和监控都必须协同工作。

Google 的 MLOps 架构指南围绕持续集成、持续交付和持续训练来构建这一学科。CI 不仅验证代码，还验证数据、模式和模型；CD 部署 ML 流水线和预测服务；CT 可以在数据或实现变化时重新训练并重新部署模型。

AWS 指南从另一个角度补充了相同的运维关注点：模型血缘、模型/版本可追溯性、漂移监控和生产质量监控是部署后保持 ML 系统可靠性的核心部分。

当模型是 LLM 时会发生什么变化

大语言模型改变了生产问题，因为应用通常并不拥有完整的模型训练生命周期。团队可能调用托管模型 API、在本地运行开源模型、在提供商之间切换，或为不同任务使用多个模型。

因此，模型只是更大的行为系统中一个带版本的依赖项。提示词、检索结果、上下文顺序、工具、模型快照、温度/推理设置、安全过滤器和运行时编排都可能改变输出。

这带来了一个更广泛的运维问题：是模型、上下文、数据、提示词、工具和运行时的哪种组合产生了这种行为？LLMOps 的存在就是为了让这个问题可回答，并让答案足够可复现，以支持工程工作。

最简单的例子

假设一个应用回答内部政策问题。

在经典 ML 框架中，你可能会对一个训练好的分类器进行版本管理、部署它并监控预测质量。在 LLM 应用中，答案可能取决于托管模型快照、系统提示词、嵌入模型、向量索引、检索过滤器、重排序器以及最终选定的上下文。

即使应用端点和用户问题保持不变，更改其中任何一个组件都可能改变最终答案。

典型的 LLMOps 发布路径

1

1. 更改一个组件

提示词、模型、提供商、检索设置、工具模式或应用代码发生变化。

2

2. 运行确定性测试

验证模式、权限、工具契约、检索过滤器和应用行为。

3

3. 运行行为评估

根据验收标准比较代表性输出、检索质量以及智能体/工具轨迹。

4

4. 比较成本和延迟

测量令牌使用量、模型调用次数、检索/工具开销和响应延迟。

5

5. 部署受控版本

发布具体的应用配置，并记录模型/提供商版本。

6

6. 追踪生产行为

捕获相关的模型、检索、工具和运行时跨度。

7

7. 评估生产追踪

对真实执行进行采样，以评估质量、依据性、安全性和任务成功率。

8

8. 回滚或迭代

利用回归证据和运营信号来决定下一次发布。

简单示例止步之处

一些 LLM 系统仍然训练或微调自己的模型，因此训练流水线、模型注册表和数据血缘等传统 MLOps 实践仍然直接相关。

其他系统仅使用外部基础模型 API，从不运行持续训练。它们的主要运营工作是应用评估、模型/提供商变更管理、提示词/上下文版本控制、检索质量和可观测性。

因此，不存在单一的通用“LLMOps 流水线”。确切的生命周期取决于你是训练、微调、自托管、检索外部知识、运行智能体，还是依赖托管模型 API。

MLOps 与 LLMOps

哪些保持不变，哪些扩展

	MLOps	LLMOps
主要运营单元
模型所有权
典型变更
评估
生产监控
持续训练
版本化产物
回滚目标

LLMOps 扩展 MLOps 而非取代它

核心运营原则并未消失：源代码控制、CI/CD、可复现性、血缘、部署控制、监控、回滚和可衡量的验收标准仍然至关重要。

扩展之处在于，更多定义行为的产物现在位于模型权重之外。托管的基础模型可以通过快照升级改变行为，而应用输出可以通过提示词或检索更改而无需任何模型重新训练即可改变。

这就是为什么有用的层次结构通常是 DevOps → MLOps → LLMOps/GenAIOps，作为日益专业化的运营关注点，而不是三种相互排斥的实践。

LLMOps 中必须版本化哪些内容？

模型快照成为发布依赖项

对于托管的 LLM，团队可能无法控制模型训练，但仍然控制应用程序调用哪个模型或快照。

OpenAI 当前的 API 指南明确警告，提示行为可能在不同模型快照之间发生变化，并建议在一致性重要的生产应用程序中固定到特定快照，然后在升级时运行评估。

运营后果很直接：模型升级应被视为应用程序发布，而不是不可见的基础设施维护。

提供商生命周期成为运营的一部分

LLM 应用通常依赖于提供商的速率限制、弃用时间表、API 语义、上下文限制、数据处理规则和定价。

即使你的应用程序代码保持不变，提供商也可能弃用某个模型。例如，OpenAI 当前的弃用时间表包括针对旧模型快照和平台界面的 2026 年退役日期。

因此，LLMOps 除了需要模型质量监控外，还需要提供商生命周期跟踪、迁移测试和回退决策。

提示词的行为类似于生产代码

提示词是可执行的行为配置。微小的更改可能会改变输出质量、工具选择和策略解释。

OpenAI 当前的指南建议将生产提示词存储在应用程序代码中，通过拉取请求审查提示词更改，使用类型化输入，并通过测试和评估检查覆盖更改。

这使得提示词版本管理不再像编辑营销文案，而更像更改一个输出具有概率性且依赖于模型的函数。

上下文工程成为一项运营关注点

生产模型很少只接收静态提示词。它可能接收对话历史、检索到的文档、工具输出、记忆、当前应用程序状态和策略指令。

因此，LLMOps 必须观察上下文组装：选择了哪些证据、当前是哪个状态版本、是否发生了截断，以及重要指令是否在压缩后保留下来。

模型回归和上下文回归在最终答案上可能看起来完全相同。追踪实际的上下文路径才能让团队区分它们。

RAG 创建了自己的运营生命周期

RAG 系统在模型推理之外引入了第二条生产流水线：摄取、提取、分块、元数据、嵌入、索引、检索、重排序和上下文选择。

即使模型和提示词没有变化，知识语料库也可能每天发生变化。因此，过时的索引或损坏的元数据过滤器可能会在没有任何模型漂移的情况下降低答案质量。

针对 RAG 的 LLMOps 应独立于生成质量，分别跟踪语料库/索引版本、嵌入模型、分块策略、检索配置、源新鲜度和检索指标。

评估用发布证据取代“在我看来不错”

生成式输出通常是开放式的，因此精确匹配测试对许多任务来说是不够的。LLMOps 增加了评估数据集和评分器，可以衡量任务成功、正确性、安全性、有据性、风格或特定领域的验收标准。

MLflow 当前的 GenAI 评估栈支持版本化评估数据集、提示/模型比较、自定义评分器以及对完整追踪的评估。

最强的实践是评估驱动开发：在变更之前或同时定义代表性案例和验收标准，然后用相同的证据比较各个版本。

LLM 作为评判者有用但并非绝对真理

LLM 评判者可以扩展对那些难以编码为确定性断言的品质的评估，例如相关性、语气或事实依据。

然而，评判者是另一个具有自身偏见、版本和提示的模型。因此，在后果重要的地方，评判者配置应进行版本管理，并针对人类或确定性参考案例进行校准。

生产评估可以混合使用确定性检查、基于参考的指标、模型评判者和人工审查，而不是要求单一指标代表所有质量维度。

追踪变得比端点日志更重要

传统的 API 日志可以告诉你一个请求耗时两秒并返回了 HTTP 200。它们无法告诉你选择了哪些检索到的块、代理调用了哪个工具，或者哪个模型跨度消耗了最多的 token。

MLflow 当前的 GenAI 追踪捕获提示、检索、工具调用和应用跨度，其生产评估流程可以对中间轨迹信息进行评分，而不仅仅是最终文本。

这是一个重大的 LLMOps 转变：可观测性遵循应用的行为图，而不仅仅是服务端点。

代理将 LLMOps 扩展到运行时操作

代理应用在产生结果之前可以执行多次模型调用、工具调用和状态转换。

因此，操作代理除了需要常规的模型延迟和 token 指标外，还需要步数、工具调用追踪、权限拒绝、重试、循环检测、人工批准和验证的最终状态。

正确的最终答案可能掩盖了糟糕的轨迹，因此代理评估必须检查路径以及结果。

Token、模型调用和上下文成为成本变量

经典 ML 推理成本通常由服务基础设施或每次预测的计算主导。LLM 应用可以增加提供商 token 定价、重复的代理调用、嵌入调用、重排序和工具/运行时开销。

因此，成本必须归因到任务或追踪，而不仅仅是单个端点。一个工作流如果进行了八次隐藏的模型调用，可能在功能上是正确的，但在运营上不可接受。

延迟的表现也是如此：模型延迟、检索、重排序和外部工具共同构成了端到端的用户延迟。

缓存变得语义化，而不仅仅是技术性

LLM系统可以缓存提示、嵌入、检索结果或完整响应，但缓存键必须反映可能改变结果的语义。

一个忽略模型版本、租户、权限或源数据新鲜度的响应缓存，可能返回技术上有效但语义上无效的答案。

因此，LLMOps将缓存失效视为模型/上下文/数据版本管理的一部分，而不仅仅是基础设施优化。

安全与权限成为发布标准

生成式系统可以产生无界文本，智能体可以触发外部操作。因此，安全测试比许多经典预测性ML系统更接近常规CI/CD。

在存在这些风险的地方，权限检查、提示注入测试、租户隔离测试和副作用审批应成为可复现的回归测试。

模型可以建议操作，但运行时仍然必须强制执行授权。LLMOps负责提供证据，证明这些控制在模型、提示或工具变更后仍然有效。

LLMOps中的CI是什么样的

LLMOps中的CD是什么样的

生产发布可能根本不部署新的模型工件。它可能只是发布新的提示、检索配置、工具集或提供商映射。

因此，发布包应标识完整的定义行为的配置，而不仅仅是应用容器镜像。

功能标志、分阶段推出、影子评估、金丝雀流量和回滚非常有用，因为LLM行为可能以静态契约测试无法检测的方式发生回归。

持续训练变为可选；持续评估成为核心

传统MLOps通常强调在新数据或漂移证明需要重新训练时进行持续训练。

许多LLM应用从不训练基础模型。它们对应的持续循环是持续评估：收集失败案例和具有代表性的生产案例，将其加入评估数据集，测试候选的提示词/模型/检索变更，并且仅在证据表明有改进时才重新部署。

微调可以重新引入训练生命周期，但它应当置于同一个更广泛的评估与发布流程之中。

生产环境中应监控哪些内容？

生产追踪可以成为评估数据

现代LLMOps中最有用的模式之一，是将抽样的生产追踪转化为评估记录。

MLflow目前支持检索生产追踪，并且不仅对输出评分，还可以对中间跨度（如检索或工具调用轨迹）进行评分。

这闭合了可观测性与开发之间的循环：真实失败可以成为下一次发布中的回归案例，而不是消失在日志中。

可复现性变为有条件的，而非精确的

经典机器学习的可复现性通常旨在从版本化的代码、数据、环境和训练参数中重建模型。

托管式LLM应用无法始终逐令牌复现完全相同的输出，因为生成是概率性的，并且提供商可能控制基础设施。

因此，LLMOps追求的是行为可复现性：记录足够的模型/提供商/版本、提示词、上下文输入、检索状态和运行时配置，以便在预期容差范围内复现条件并验证行为。

血缘从模型血缘扩展为应用血缘

AWS的MLOps指南将模型血缘视为诊断和可复现性所需的代码、数据、模型和基础设施制品的历史记录。

对于LLM应用，血缘还应连接提示词、评估数据集、检索/索引版本、工具模式、智能体/运行时配置以及提供商/模型快照。

目标问题变为：究竟是哪个确切的应用配置产生了这条追踪？

多提供商和模型路由产生运营策略

一旦应用可以使用多个提供商或本地模型，路由就成为一种运营策略，而不再只是一个简单的模型字符串。

路由可能取决于能力、延迟、成本、隐私、上下文长度、可用性、工具支持或本地性。回退机制可以在保持正常运行时间的同时，改变答案质量或数据处理假设。

因此，LLMOps 应记录实际选择了哪条路由，并独立评估各条路由，而不是将每个兼容端点视为行为上可互换的。

原始实现证据

Aaasaasa AI Client：提供商、模型和运行时是独立的运维对象

Aaasaasa AI Client 将代理/客户端、提供商、模型、运行时位置和权限分开。其 AI Hub 支持 Ollama、LM Studio/OpenAI 兼容端点以及其他提供商协议，而不是将“模型”视为一个全局设置。

该实现包括动态本地模型发现、流式传输、思考输出以及显式的 Ollama 预热/加载和卸载控制。这是运维证据，表明本地 LLM 服务引入了超出 API 模型名称的资源生命周期问题。

提供商状态通过提供商适配器查询，连接类型区分本地、云 API、账户支持、远程代理和 Web 客户端路径。这些是 LLM 感知平台必须呈现的具体运维维度。

该仓库还保留了一个重要边界：本地运行时并不自动等于本地推理。提供商/模型/运行时位置是影响隐私、延迟、成本和可用性的版本化或可配置事项。

Source of Truth Research Engine：LLM 应用状态超出模型本身

Source of Truth Research Engine 围绕本地模型辅助研究，结合了词法搜索、可选嵌入、来源快照、SHA-256 身份、声明、溯源和矛盾跟踪。

这是有用的 LLMOps 证据，因为仅更改模型并不能定义研究系统。检索、来源获取、证据分类和持久溯源是独立的运维产物。

该实现有意将语义相似性视为发现而非证据，说明为什么 LLMOps 可观测性应区分检索行为与声明有效性。

常见 LLMOps 故障模式

常见误解

实用的LLMOps设计流程

运营完整的产生行为的系统

1

1. 定义行为单元

列出所有能实质性改变输出的组件：模型、提示词、检索、工具、上下文和策略。

2

2. 建立应用谱系

对代码、模型/提供商、提示词、评估数据集、检索配置和工具契约进行版本控制。

3

3. 构建有代表性的评估数据集

使用来自设计和生产的预期成功/失败案例。

4

4. 分离确定性测试和行为测试

将模式/安全断言与语义输出评估区分开。

5

5. 追踪端到端执行

对模型、检索、重排序、工具和代理/运行时跨度进行埋点。

6

6. 定义发布门禁

设置质量、安全、延迟和成本阈值。

7

7. 固定或明确记录模型版本

将模型/提供商变更视为发布事件。

8

8. 渐进式部署

在后果需要时使用功能标志、金丝雀发布或分阶段推出。

9

9. 评估生产追踪

衡量真实任务行为并识别反复出现的故障。

10

10. 将故障反馈到评估数据集

将事件和纠正转化为永久的回归覆盖。

11

11. 监控提供商和数据生命周期

跟踪弃用、索引新鲜度、源变更和运行时可用性。

12

12. 干净地退役过时版本

在迁移和证据保留决策后，移除旧的提示词/模型/索引/凭证。

LLMOps架构检查清单

边缘情况和限制

一个简单的应用，调用一个固定的托管模型，没有检索或工具，可能只需要轻量级的LLMOps：版本化的提示词代码、评估、模型固定、基本追踪和提供商监控。

一个自托管的微调模型可能需要几乎完整的经典MLOps堆栈，加上LLM特定的应用评估，使得MLOps和LLMOps之间的界限有意模糊。

一个代理平台可能只有最少的模型训练操作，但需要大量的运行时操作，因为故障发生在工具选择、状态和编排中。

一个重度依赖RAG的系统，其操作可能主要由文档摄取和检索质量主导，而不是模型服务。

术语将继续演变。持久的架构问题不是哪个“Ops”标签胜出，而是哪些工件产生行为，因此必须被版本化、评估、观察和治理。

什么会改变这个答案？

如果基础模型提供商标准化了完全稳定的模型行为和长期版本支持，提供商/快照管理可能在操作上变得不那么重要。

如果应用越来越多地拥有微调或训练，经典的MLOps关注点将再次变得更加核心。

操作原则将保持不变：每个能实质性改变生产行为的组件都属于谱系、测试、可观测性和变更控制。

相关规范知识

LLMOps位于AI治理和企业AI架构之下：治理定义哪些变更需要证据和批准，而LLMOps提供操作机制来版本化、评估、部署和观察这些变更。

上下文工程和RAG是许多LLM应用内部的操作子领域，因为上下文和检索可以独立于模型改变行为。

代理式AI将LLMOps进一步扩展到轨迹、权限和工具运行时操作。

常见问题

MLOps 与 LLMOps 常见问题

MLOps 和 LLMOps 有什么区别？

MLOps 在数据、训练、部署和监控方面运营机器学习系统。LLMOps 将这些实践扩展到 LLM 应用，其中提示、上下文、检索、提供商、工具和评估也会实质性地影响行为。

LLMOps 会取代 MLOps 吗？

不会。LLMOps 复用 MLOps 的学科，如 CI/CD、血缘、评估、部署和监控，并增加 LLM 特有的运营关注点。

LLM 应用需要持续训练吗？

不一定。许多应用使用外部基础模型，转而依赖对提示、模型、检索和应用行为的持续评估。微调或自训练系统仍可能需要训练流水线。

为什么评估在 LLMOps 中如此重要？

生成式输出是开放式的，模型行为可能因提示、快照和上下文而变化。评估提供可重复的证据，证明发布仍满足定义的质量和安全标准。

在 LLMOps 中应该对什么进行版本控制？

至少包括：应用代码、模型/提供商/版本、提示、评估数据集/评分器、检索配置/索引、工具模式、上下文规则以及相关的安全/权限配置。

提示版本控制就足够了吗？

不够。同一个提示在另一个模型、检索集、上下文顺序、工具面或提供商下可能表现不同。

什么是 GenAIOps？

GenAIOps 是运营生成式 AI 应用的另一个行业术语。一些供应商将其与 LLMOps 互换使用，或作为比 LLMOps 更广泛的标签。

如何监控 LLM 应用？

监控端到端追踪，包括模型调用、提示/上下文、检索、工具、延迟、令牌/成本、质量样本、安全性以及最终任务结果。

本地 LLM 可以使用 LLMOps 实践吗？

可以。本地模型增加了自身的运营关注点，如模型文件、硬件/VRAM、加载/卸载、运行时健康、量化和升级管理。

术语表

关键 MLOps 和 LLMOps 术语

MLOps

用于构建、部署、监控和维护机器学习系统及其数据/模型生命周期的工程实践。

LLMOps

针对生产应用的运营实践，其行为实质性地依赖于大型语言模型以及周围的提示、上下文、检索、工具和运行时。

GenAIOps

生成式 AI 应用的运营学科；通常用作 LLMOps 的更广泛或替代标签。

持续训练

随着数据或实现变化，对 ML 模型进行自动化或重复的再训练和 serving。

持续评估

针对版本化数据集和标准，对候选和生产 AI 行为进行重复评估。

模型快照

托管或打包模型的具体版本，其行为可以被测试和引用。

应用血缘

代码、模型/提供商、提示、数据/检索、工具、运行时和发布配置之间的可追溯关系。

追踪

一次应用执行的结构化记录，包含模型调用、检索和工具操作等跨度。

评估数据集

版本化的代表性输入、期望值以及可选的追踪/输出集合，用于衡量行为。

LLM 评判器

用作定性或语义标准评估器的语言模型；它本身就是一个版本化的评估依赖项。

行为回归

尽管接口和代码继续成功执行，应用输出或轨迹仍出现退化。

提供商路由

根据能力、成本、延迟、隐私或可用性在可用模型提供商/端点之间进行选择的策略。

结论

MLOps 和 LLMOps 共享相同的工程目标：使 AI 系统足够可复现、足够可测试、足够可观测，以便在生产中可靠运行。

区别在于系统的形态。经典 MLOps 通常以训练和 serving 模型工件为中心；LLMOps 必须运营一个行为栈，其中模型快照、提示、上下文、检索、工具、权限和提供商可以独立变化。

最简短有用的规则是：对一切可能实质性改变 LLM 应用行为的内容进行版本控制、评估和观测——而不仅仅是模型。

主要来源和当前文档

以下来源为 MLOps 基线和 LLM 及代理应用的当前运营模式提供依据。项目部分是原始实现证据，并且有意比关于完整 LLMOps 平台的声明更窄。

Google Cloud — MLOps：持续交付和自动化流水线

描述 ML 系统的 CI、CD、持续训练、模型注册表、元数据、serving 和监控的参考架构。

AWS Machine Learning Lens — 模型血缘

跨 ML 发布跟踪代码、数据、模型、环境和基础设施的当前指南。

AWS Machine Learning Lens — 模型可观测性和跟踪

生产模型监控、漂移、端点健康和血缘的当前指南。

Microsoft Azure — GenAIOps / LLMOps 生命周期

官方指南，描述 GenAIOps（有时称为 LLMOps）在初始化、实验、评估/改进和部署方面的内容。

MLflow — 代理和 LLM 应用

当前 GenAI 运营文档，涵盖 LLM 应用和代理的追踪、评估、提示和生产可观测性。

MLflow — 评估生产追踪

评估完整 LLM/代理追踪（包括检索和工具调用轨迹）的当前指南。

MLflow — 评估提示词

当前使用版本化提示词、数据集、评分器和追踪的提示词/模型评估工作流。

OpenAI API — 版本管理与模型快照

当前 API 指南建议固定模型版本并进行评估，因为提示行为可能在不同快照之间发生变化。

OpenAI — 提示词工程

当前指南建议将生产提示词视为应用程序代码，通过源代码控制进行版本管理，并用测试和评估检查覆盖变更。

OpenAI — 弃用

当前提供商生命周期证据表明，模型和平台界面的退役是一种运营依赖。

OpenAI — 将评估工作流迁移到 Promptfoo

当前 2026 年迁移指南说明，随着提供商工具的变化，评估资产应保持可移植性。