LLMOps

LLMOps（大型语言模型运维）是一套用于构建、发布和运行基于大型语言模型（LLM）的生产应用的实践和工具。它涵盖提示和模型选择的版本管理、发布前后的生成文本评估、多步骤请求在检索和工具调用过程中的追踪、延迟和词元成本控制，以及防范幻觉和提示注入等故障。LLMOps 是面向这些应用的机器学习运维（MLOps）分支；随着各公司在 2023 年将聊天机器人原型转为产品，这个术语开始广泛使用。大多数团队会通过提示工程、检索增强生成（RAG）或微调，改造托管或开放权重的基础模型，而不是从头训练模型；因此，大部分运维工作也从训练流水线转移到模型周边的各项工作。

LLMOps 与 MLOps 的区别#

发布单元不只是权重集合。一次变更可能涉及提示模板、模型名称和版本、采样设置、检索索引以及工具定义；每个部分都需要进行版本管理，因为任一部分都可能改变模型行为。提示管理工具会存储带版本号的模板，应用程序在运行时获取模板，因此无需发布代码就能上线或回滚提示修改。托管模型也可能在应用程序运行期间发生变化，因此，如果提供商支持，团队会固定使用带日期的模型快照，并在切换前重新运行测试。数据工作也会发生变化：RAG 应用会对文档、分块设置和搜索索引背后的嵌入模型进行版本管理；切换嵌入模型意味着必须为整个语料库重新生成嵌入。微调变体通常以小型 LoRA适配器的形式存储，由一台服务器加载到共享基础模型之上。

评估更难，因为生成文本很少只有一个正确答案。团队会维护一个包含代表性输入及参考答案或评分准则的黄金数据集，并通过精确检查、人工审查或 LLM-as-a-judge 进行评分；在 LLM-as-a-judge 中，一个能力较强的模型负责评判回答。在 2023 年的论文 Judging LLM-as-a-Judge中，Lianmin Zheng 及其同事发现，GPT-4 与人类偏好的一致率超过 80%，与人类彼此之间的一致率相当。每个候选版本都会运行同一套测试，而生产流量会不断补充测试案例：

成本和延迟按请求进行管理。托管模型按词元计费，因此团队会通过提示缓存、语义缓存和模型路由来降低开支，将简单请求发送给较小的模型。另一种相关模式是先调用廉价模型，再调用昂贵模型：Ultralytics Platform Agents中的 YOLO → VLM Monitor 模板会先运行 YOLO26，只有在 YOLO 检测到人的图像上才调用视觉语言模型，语言模型的使用费用则计入工作区自己的提供商密钥。安全工作也同步进行：AI 防护措施会在每个请求上过滤输入和输出，红队测试则会在每次发布前探测越狱攻击。

追踪、网关与服务#

LLM 应用的可观测性以追踪记录为基础。每个请求都会形成一个跨度树，包含提示、每次模型调用、从向量数据库进行的每次检索，以及AI 智能体发出的每次工具调用，并附带词元数、延迟和成本。OpenTelemetry 的生成式 AI 语义约定会统一模型和词元使用情况的属性名称；LangSmith、Langfuse、Arize Phoenix 和 MLflow Tracing 等工具则会存储和搜索追踪记录。追踪记录也会用于在线评估：系统使用与离线测试套件相同的评审模型和评分准则来评估抽样的生产环境回答，并将每位用户的点赞或点踩关联到生成该回答的追踪记录。

AI 网关位于应用程序和模型提供商之间，集中保存 API 密钥并执行速率限制、故障回退和支出预算控制。托管开放权重模型的团队会在 vLLM 和 SGLang 等推理服务器上运行模型；这些服务器使用连续批处理和分页式 KV 缓存内存，在每个 GPU 上处理大量并发请求。