大语言模型（LLMs）架构的规模和复杂度，使得将它们投入生产环境变得极其困难。生产化不仅仅是部署模型，还包括对模型进行监控、评估和性能优化。
挑战层出不穷。根据具体应用，可能涉及如何处理数据、如何存储和动态调整提示词、如何监控用户交互，以及最紧迫的——如何防止模型传播错误信息或记忆训练数据（从而泄露个人隐私）。这正是为何LLMs的日常生产管理需要一个全新的框架。
这个框架被称为LLMOps，是一种针对LLM应用的生产运维框架。虽然其名称和原则受到了MLOps和DevOps的启发，但LLMOps的内涵更加细致和复杂。LLMOps框架帮助企业降低技术债务、确保合规、应对LLMs的动态与实验特性，并通过避免常见陷阱，最大限度地减少运营风险和声誉风险。
本章首先介绍什么是LLMOps，以及它与MLOps的区别和联系。随后，我们将介绍LLMOps工程师的职责及其在现有机器学习团队中的定位。接下来，会讲述如何衡量团队的LLMOps准备度、评估组织的成熟度，并确定衡量成功的关键绩效指标（KPI）。章节后半部分将概述LLM应用生产化过程中面临的若干特定挑战。
什么是运维框架？
运维框架为管理组织内部复杂工作流和流水线提供了结构化的方法。这些框架整合工具与实践，实现自动化和流程简化，保障项目生命周期内的一致性与质量。
最早的运维框架可以追溯到军事战略和工业革命时代。两个最著名的框架均于1986年诞生：丰田的精益生产体系（Lean Production System），让丰田领先大多数同行；以及摩托罗拉的六西格玛（Six Sigma），一种基于数据的流程改进和缺陷减少方法。
2008年，科技行业开始广泛采用现今流行的软件运维框架——DevOps（开发与运维结合）。2018年，针对非生成式机器学习模型的运维框架MLOps开始兴起；此后安全运维（SecOps）、数据安全运维（DataSecOps）等多种框架相继出现。
随着2023年LLMs的广泛应用，一种新的运维框架开始在构建LLM应用的企业中流行开来——LLMOps。LLMOps仍处于初期阶段，但随着生成式模型逐渐成为软件产品的核心组成部分，其受欢迎程度势必大幅提升。
图2-1展示了运维框架多年来的缓慢兴起。随着2023年初LLMs的广泛采用，LLMOps开始快速发展。截止目前，越来越多企业认识到基于LLM的产品能带来价值和利润，推动了LLMOps的上升趋势。事实上，2025年可能成为LLMOps框架的黄金年份。
部署LLMs可以简单到通过API集成聊天机器人到网站，也可以复杂到从零开始构建自己的LLM和前端系统。但要让它们持续高效运行（即生产化），保持稳定、可扩展、安全和健壮，则是巨大的挑战。本书，正如LLMOps所关注的，正是聚焦于这个问题：部署到生产环境后的LLM将面临什么？
从MLOps到LLMOps：为什么我们需要一个新的框架？
MLOps和LLMOps之间存在一定的重叠——毕竟它们都涉及机器学习模型的运营生命周期管理，也有管理ML工作流的共同原则。但两者的核心关注点和目标不同。MLOps主要处理非生成式模型（包括语言和计算机视觉），而LLMOps聚焦于生成式语言模型，因此面对极其庞大的复杂性。这种复杂性不仅来自模型的规模和架构，还来自数据工程、领域适应、评估和监控等特有流程。LLMs在预测透明度、延迟以及内存和计算资源需求上的差异尤为明显。
也许最大的不同是终端用户的使用方式转变。非生成式模型作为预测工具，多用于被动消费场景，如仪表盘、推荐和分析；而LLM应用作为“软件3.0”，面向消费者，支持主动交互。这使得许多源自“软件1.0”（DevOps）的挑战重新浮现。实际上，LLMOps与DevOps相比，更有相似之处而非MLOps。
构建生成式AI应用需要匹配模型规模与复杂度的工具、框架和预期，远超现有MLOps方案的范围。为帮助理解不同Ops框架的区别，我们做一个思考实验：
想象MLOps像是从零开始建造一座小房子；DevOps则像开发一个大型购物中心；而LLMOps则更像是在建造迪拜的哈利法塔。这三者都用相同的建筑材料：木头、钢铁、混凝土、砖块、锤子等。基本流程也相似：先打地基，铺管线，最后搭墙。但你不会让普通建筑工人去建造哈利法塔，对吧？
大部分面向自然语言的MLOps基于构建较小的判别模型，用于情感分析、主题建模、摘要等任务。对于这些任务，首先假设理想特征，将数据建模为这些特征的函数，然后针对具体任务优化模型。
而LLMs则是生成式、领域无关和任务无关的。这意味着同一个模型既可用于摘要，也可用于回答问题，无需专门微调。
LLMs最适用的场景是你不知道要优化哪些特征（或者特征过于抽象），或者需要在单条流水线中建模多模态数据。不同于较小的判别模型，LLMs不依赖预定义特征或任务专用架构。如第一章所述，它们通过海量文本数据训练，学习语言中的模式和结构。训练过程涉及损失函数，衡量模型生成输出与各种任务预期输出的匹配度。例如训练时，模型生成一段文本序列，损失函数计算生成序列与目标序列的差异。
此外，举例来说，参数量为1750亿的GPT-4模型的超参数空间，可能比拥有1.1亿参数的判别式BERT模型大约多1500倍。这使得对LLMs进行微调和迭代训练的成本极高，而这类训练是MLOps中常见的。
下表2-1概述了MLOps和LLMOps模型生命周期的关键差异：
| 生命周期步骤 | 背景 | MLOps | LLMOps |
|---|---|---|---|
| 数据采集 | 难易度 | 始终简单直接 | 有时复杂，数据组成问题极具挑战 |
| 数据预处理 | 难易度 | 轻松修补缺失值和异常值 | 复杂，需去重、毒性过滤、多样性管理、数量控制 |
| 模型学习 | 模型规模 | 判别模型如分类器通常最多约2亿参数，计算资源需求较低 | LLMs参数规模达千亿甚至万亿，规模大，资源消耗巨大 |
| 超参数调优 | 精度 | 超参数空间有限，易搜索，适合预测任务 | 超参数空间庞大，搜索实时延迟高，适合生成与演化任务，准确率为计算瓶颈 |
| 训练时长 | 训练规模与周期 | 资源需求少，训练较快，易部署于云笔记本或单节点容器 | 需处理海量数据，分布式大规模集群训练，需动态资源扩展，训练周期长达数天至数周 |
| 领域适应 | 成本 | 完全微调必要且可承受 | 完全微调昂贵且少见，常用提示词工程、RAG、知识图谱、参数高效微调 |
| 评估 | 难易度 | 容易，判别模型有定义良好的概率空间 | 极难，生成式，概率空间无界，难以检测 |
| 鲁棒性 | 静态 vs 动态 | 生产环境中模型行为保持不变 | 基于交互模型行为动态变化，需持续监控调整 |
| 安全 | 安全性 | 安全 | 高度安全或高度脆弱，需数据安全运维框架（DataSecOps） |
LLMOps的四大目标
LLMOps基于专门针对大语言模型的设计模式原则，确保你的LLM应用实现以下四个关键目标：安全性、可扩展性、鲁棒性和可靠性。我们来逐一看看这些目标：
安全性
最大限度地降低在生产环境部署LLM应用所带来的合规风险、声誉风险和运营风险。
可扩展性
构建、存储和维护能够跨数据泛化且能按需高效扩展的LLM应用，同时优化延迟、吞吐量和成本。
鲁棒性
在面对数据漂移、模型漂移、第三方更新及其他挑战时，保持LLM应用的高性能。
可靠性
实施严格的推理监控、错误处理和冗余机制，防止停机和故障发生。
LLMOps团队通过自动化重复流程，更快地在大规模环境中优化应用，避免“LLM出错”的尴尬时刻。LLMOps框架的另一个关键方面是促进多学科团队间的一致性、透明度与协作，这些团队通常包括数据工程师、数据科学家、研究科学家、软件工程师以及业务运营团队。
由于LLMOps是一个全新的领域，截至2025年，成熟的工具和资源仍然很少。各组织的LLMOps团队因此基于原型开源库和工具包，内部开发适合自身的工具和流程。
LLMOps团队与角色
目前，构建LLM应用的公司主要分为两类：一类是以LLM应用为核心的新兴初创企业，另一类是已有机器学习模型的公司，这些公司正组建自己的生成式AI（GenAI）团队。
在后一类公司中，具备LLMOps技能的运维专业人员极为稀缺，大多数企业选择从内部招募机器学习工程师候选人，并对其进行LLMOps技能提升，而非外部招聘。主要原因在于对应用场景和岗位职责的普遍不清晰。因此，目前的常见做法是在内部从不同部门挑选8至10人组成团队，成员可能包括产品经理、全栈工程师、系统架构师、数据工程师、数据科学家、机器学习工程师、平台工程师、网络安全专家以及开发者倡导者等。许多企业希望找对业务有深刻理解的人，在确定投入前先评估多个潜在用例和项目的可行性。
而新兴初创公司则不得不从零开始组建团队。这些团队的构成差异较大，取决于其是专注于LLMOps基础设施建设（如LLMOps SaaS公司），还是专注于具体LLM应用场景，如文案写作、教育或流程优化。图2-2展示了一个非常基础的LLMOps团队模型，但实际上团队规模和结构多样，业务与技术成熟度也各不相同。（本章后续将介绍如何评估公司LLMOps的成熟度。）
大多数公司无法承担构建和训练专用LLM用于自身应用的高昂成本，因此大多选择使用基础模型。这时，AI工程师便发挥作用：利用LLMOps工具快速搭建概念验证（PoC）。大多数AI工程师具备软件工程背景，能够快速开发全栈应用，但未必深入理解机器学习/LLM模型的内部机制或优化方法。
一旦概念验证完成，模型的构建、部署和优化工作将由LLM工程师、机器学习科学家（根据组织不同，称谓可互换）及负责可靠性的LLMOps工程师承担。
若团队选择通过API集成部署LLM应用，初始部署较为简单。LLMOps工程师与AI工程师协作，共同提升模型的扩展性和性能。理想状态是每位AI工程师配备一名LLMOps工程师，前者专注模型微调以满足业务需求，后者负责部署和优化。对于开源模型，部署管理通常由LLMOps工程师承担。
随着技术从非生成式模型转向生成式模型，特征工程（手工设计特征并调参优化）的重要性降低。生成式模型，特别是LLMs，不再依赖特征工程。当前核心需求通常是提示词工程和构建RAG流水线，这些技能属于AI工程师领域。
另一大变化是数据工程流水线以及监控评估流水线变得更加复杂。评估LLMs不仅仅是简单的量化评分。行业内存在诸如BLEU（机器翻译评估指标）、ROUGE（摘要评估指标）等基准，但它们与实际应用性能的相关性有限。模型得分更高，并不保证用户满意度提升。标准化评分适合对比LLMs，但最终用户关心的是LLM应用是否解决了他们的问题。
此外，由于LLMs多部署于面向消费者的应用，感知延迟和吞吐量成为市场竞争的关键因素。模型本身不是唯一决定因素，部署、评估和监控流水线同样是性能评估的核心。
相关岗位角色介绍：
数据工程师
负责设计、构建和维护数据系统与流水线，实现数据的高效采集、存储、转换及访问。保障数据的可用性、可靠性和良好组织，支持数据科学家和其他工程师进行模型开发和评估。数据获取与迁移是基础技能，职业发展中构建数据架构愈发重要。
针对LLM的数据工程需要专业知识，如如何分块数据、选用何种分词模型等。最佳实践是将每名数据工程师与具备LLM背景的机器学习科学家及LLMOps工程师配对，共同自动化和优化LLM系统的规模化运维。
AI工程师
核心技能为全栈开发（React、Node.js、Django）及熟悉常见LLMOps工具和框架（如LangChain和Llama Index）以部署应用。需具备端到端AI应用开发基础，包括提示词工程和RAG系统。新建团队的企业通常招募既懂云服务部署管理，又熟悉外部API和向量数据库的AI工程师。
机器学习科学家
日常工作包括使用PyTorch、TensorFlow、JAX等框架研究、设计和优化LLMs。需深入理解NLP算法与任务，如分词、命名实体识别（NER）、情感分析和机器翻译。应掌握模型架构、训练及微调流程。
LLMOps工程师
职责是确保LLM应用的可靠性、鲁棒性、安全性与可扩展性。日常工作包括构建和维护LLM的运营流水线，承担项目负责人角色。
接下来，我们将详细介绍LLMOps工程师的角色。
LLMOps工程师角色
该角色要求具备丰富的经验，能够在生产环境中完成大语言模型（LLM）的部署、监控、微调、训练、扩展和优化；同时熟悉基础设施和平台工程、数据工程以及系统可靠性管理。
构建LLM团队的公司通常寻求具备理解LLM独特挑战、能够在自建与购买之间权衡利弊的LLMOps工程师，特别是能够在成本效益和系统性能之间做出合理权衡的专业人才。
要成为该职位的优秀候选人，你需要掌握一套独特的专业技能组合，对LLM生命周期全流程有深入的技术理解——从数据管理到模型部署和监控。同时，你还需具备解决问题的能力、良好的团队合作精神、有效的沟通技巧，并注重细节。
为更直观地说明这一角色的实际工作内容，我们来看看一位虚构的LLMOps工程师的典型工作日。
一位LLMOps工程师的一天
虽然不同公司对该岗位的具体职责有所差异，但核心任务通常涵盖基础设施管理、团队协作、性能优化和合规保障。以下是一个典型的LLMOps工程师的工作日安排，供你参考：
上午7:30–8:30：早晨签到
查看监控仪表盘，检查部署的LLM是否有过夜警报或性能异常；处理紧急问题或将其上报给相关团队。
主持团队的日常站会，讨论进行中的项目、阻碍和当天的优先事项。
上午8:30–10:00：基础设施管理与优化
模块化代码以提升复用性，分别创建GPU资源管理、存储管理和网络管理模块。
实现批处理机制，批量处理多条推理请求，降低单次请求开销。
采用内核融合、量化和动态批处理等延迟优化技术，提高模型性能。
上午10:00–11:30：协作与项目规划会议
与数据科学家、机器学习工程师和红队工程师开会，讨论使用需求、时间节点、监控错误和扩展难题。
上午11:30–12:30：API开发与模型部署
设计推理端点和缓存策略，确保不同模型的生产环境兼容性和高效响应。
12:30–13:30：午休时间
下午13:30–15:00：监控与故障排查
处理出现的问题。例如，若用户请求推理API时延迟过长，工程师会检查硬件利用率、网络延迟和访问日志，定位瓶颈。随后实施解决方案，比如使用Pod自动扩缩容或缓存高频请求。
下午15:00–16:30：研究与持续学习
尝试新工具、库或框架，评估是否可集成至现有技术栈以提升效率和性能。
下午16:30–17:30：日终总结、回顾及值班准备
复盘当天任务，更新任务单中的已完成内容和下一步计划。
为值班做好准备，确保监控系统配置完备，随时待命响应可能的事件。
参加跨职能团队的最终会议或同步，确保对即将到来的优先事项达成一致。
处理剩余任务，确保所有系统稳定运行后下班。
常规工作时间结束后，如你处于值班状态，需保持在线，随时应对任何关键故障。
外部招聘LLMOps工程师
填补LLMOps工程师岗位有两种方式：一是外部招聘，二是内部培养，通过培训现有的机器学习工程师提升为LLMOps工程师。本节先介绍外部招聘，再讨论内部培养。
如果你正在为此岗位招聘，候选人应具备或熟悉以下技能：
- 模型在PyTorch、JAX等库间的转换
- 理解机器学习指标，如准确率、精确率、召回率和PR-AUC
- 理解数据漂移和概念漂移
- 运行和基准测试模型，评估计算图表示对神经引擎、GPU和CPU性能的影响
- 在AWS、GCP、Azure等云环境中部署和扩展机器学习模型
- 使用LLM推理延迟优化技术，包括内核融合、量化和动态批处理
- 利用Terraform等工具构建数据工程、部署和基础设施即代码（IaC）的运维流水线，管理向量数据库和大规模训练数据的ETL流程
- 理解红队策略、接口和指南
- 使用Docker进行容器化，利用Kubernetes进行编排，确保部署的可扩展性和一致性
- 与LLM工程师、数据科学家及ML/NLP工程师团队协作和管理项目
当然，每家公司有各自的面试流程。有的会安排多轮面试，有的则会将多个环节合并为一次现场面试。本节介绍的是一套相对标准的四轮面试流程，如图2-3所示。
逐轮面试详细介绍：
第一轮：初步筛选
初步筛选的目标是确认应聘者具备该岗位所需的基本技能和经验。这可以通过简历评估表来完成。你需要问一些宏观问题：他们是否有在生产环境中部署LLM的经验？是否提到过具体的LLM流水线管理框架和工具？这些工具是否与你们公司使用的相同？如果不同，他们是否有能力学习并适应你们的技术栈？能否展示或讲述过往项目经验？
第二轮：技术能力评估
该轮面试旨在评估候选人在核心技术领域的能力，如LLM部署、数据工程和基础设施管理。可能的问题包括：
- 请描述你微调预训练大语言模型的步骤。你如何确保模型针对具体应用场景得到优化？
- 介绍你曾参与过的LLM部署过程。遇到了哪些挑战？如何解决？
- 你会如何搭建LLM的CI/CD流水线以支持训练、微调和部署？
- 如何设计和管理大规模机器学习项目中的数据流水线？使用哪些工具？如何保证数据质量？
- 你如何监控并排查生产环境中的延迟问题？
- 如何管理训练或微调LLM时使用的数据集版本和追踪？
- 你如何确保云基础设施的高可用性和成本效益？
第三轮：系统设计面试
本轮重点评估候选人设计可扩展、可靠且易维护的LLM部署与管理系统的能力。示例问题：
- 请讲述一次你需要在自建与购买ML基础设施组件之间做出决策的经历。你考虑了哪些因素？
- 如何设计一个支持大规模LLM推理服务的API？讨论负载均衡、容错和延迟优化的考虑点。
- 你会如何利用基础设施即代码（IaC）工具管理LLM部署的云基础设施？你将采取哪些策略来优化资源使用和成本？扩展过程中可能遇到哪些问题？
- 描述你在推理服务中实现动态批处理的方法。量化和混合精度训练等技术如何影响LLM的性能和效率？
- 训练LLM时如何管理CUDA内存？你有哪些策略防止内存溢出？
- 你如何在优化前后进行模型性能基准测试？关注哪些指标，使用什么工具？
- 优化后性能下降时，你如何诊断并解决？
最后一轮：行为面试
经过前三轮筛选，最后只剩下最合适的候选人。此轮重点评估其个性特质：是否自我驱动？能否团队协作？是否能坦然应对挑战并促进合作？示例问题：
- 你如何保持对LLM和机器学习运维最新进展的关注？
- 你如何将数据科学家的反馈融入部署流程？
- 你会如何与红队工程师协作，解决LLM部署中的潜在安全漏洞？
- 你有值班轮换的经验吗？如何处理非工作时间的紧急事件？
此外，还需确认候选人与贵组织文化契合，尤其是在创新、持续学习和协作方面。可问：
- 你喜欢哪些技术博客或播客？
- 你如何跟进该领域的新进展？
内部招聘：将MLOps工程师培养为LLMOps工程师
MLOps工程师与LLMOps工程师在规模、复杂度及技术挑战方面存在显著差距，因此对现有员工进行技能提升，需要集中精力帮助他们建立相关认知。
不过，MLOps的基础技能——如模型部署、自动化和云管理——为成长打下了坚实基础。通过专注学习和实践经验，MLOps工程师可以有效转型进入LLMOps领域。内部招聘的最大优势是候选人已与组织文化和价值观高度契合，并对组织的关键绩效指标（KPI）有深入理解。
为了出色完成工作，新晋LLMOps工程师需要资源和培训，深化对大规模模型架构、Transformer架构、注意力机制、基础设施管理以及LLM特定优化技术的理解。他们还需掌握LLMs与非生成式机器学习模型的差异。建议将他们与LLM工程师配对，协作实验和评估不同模型。
该岗位不仅仅是构建使用LLM的应用。LLMOps工程师还需管理成本、云资源与用户体验之间的平衡，并处理海量非结构化数据。因此，应安排他们与数据工程师合作，共同构建数据处理流水线，让他们熟悉可用数据源、数据库中的数据结构、不同数据库的信息检索方式、公司对延迟的期望，以及数据过滤方法。鼓励他们引入多节点配置和分布式系统，聚焦成本优化和错误管理。指导他们对不同LLM模型进行基准测试，并调试性能优化。最后，让他们展示日志实践和为保持大规模可靠性与性能所设置的保护措施。
多数MLOps工程师已有模型版本控制、数据版本控制、回滚管理和GitHub Actions等技能，因此培养他们是打造强大LLMOps团队的有效策略。
接下来，我们来看如何确保LLMOps工程师的目标与组织目标保持一致。
大语言模型（LLMs）与您的组织
本章开头提到，LLMOps框架的四大关键目标是安全性、可扩展性、鲁棒性和可靠性。对于LLMOps团队来说，下一个重要问题是如何衡量应用是否达到了这些目标。怎样才能知道你取得了成功？公司的期望必须明确界定，并始终保持定量和定性上的可衡量性。
衡量团队目标达成情况的指标主要有三类：SLO（服务级别目标）、SLA（服务级别协议）和KPI（关键绩效指标）。这些术语在站点可靠性工程师中已被广泛使用，如今LLMOps团队也迅速采用它们：
服务级别目标（SLOs）
SLO是组织内部设定的具体、可衡量的服务质量目标，用来衡量服务水平。例如，云托管公司可能设定SLO，确保服务器每月正常运行时间不低于99.9%。
服务级别协议（SLAs）
SLA是服务提供商与客户之间的正式合同，明确服务提供商承诺的服务水平，通常包含具体的性能目标及未达标时的补救措施。例如，如果互联网服务商的年正常运行时间低于99.9%，则SLA可能规定客户将在下一账单周期获得10%的折扣。
关键绩效指标（KPIs）
KPI衡量具体业务活动的整体成功和表现，反映组织实现战略目标的程度。例如，一个应用的重要KPI可能是流失率，即一定时间内停止使用该应用的客户比例。
2024年8月，Gartner发布研究预测，到2025年，30%的现有生成式AI项目将失败。（实际上，Gartner在2018年也发布过类似预测，称85%的机器学习项目将在生产环境中失败，时间点为2022年。）2024年研究中列出的关键失败点令人关注，因为它们都是LLM开发与部署的运营层面问题，包括数据质量不足、缺乏强有力的评估框架，以及大规模生产环境扩展的高成本。
更明显的问题之一是管理层与工程团队之间期望不匹配。过去十年里，数据科学家最大的技能差距之一就是如何将机器学习模型指标转化为组织和产品的成功指标。换言之，当你衡量诸如模型安全性、可扩展性、鲁棒性和可靠性这些抽象目标时，如何将其意义传达给业务层面？这正是SLO、SLA和KPI发挥作用的地方。
使用SLO-SLA-KPI框架，LLMOps团队能够自动化、简化并管理多个利益相关方的期望。SLO明确向所有相关方展示了目标服务水平。SLA确保责任落实，让所有参与者清楚自己的角色和商定的服务水平，有助于跟踪绩效并及时纠正偏差。KPI则提供实时数据可见性，帮助及早发现潜在问题，促进明智决策。
LLMOps的四大目标
让我们更深入地了解LLMOps的目标，看看这些指标如何具体体现。
可靠性（Reliability）
众所周知，LLMs极其复杂，拥有数十亿参数。其行为可能难以预测，有时因规模庞大和训练数据复杂，表现出意外的响应或错误。此外，如果训练数据存在偏见、过时或不具代表性，模型在相关领域的表现就可能不可靠。
LLMs有时难以准确理解用户查询的上下文、细微差别和意图，导致回答错误、不相关或误导信息。更重要的是，LLMs通常不会实时更新。随着语言演变，若不通过定期再训练将新信息纳入训练数据，模型会变得过时，从而降低可靠性。
所有这些问题归结为可靠性。基于LLM的应用可靠性可通过系统可用性、错误率和客户满意度来衡量。下表（表2-2）展示了这些指标在SLO、SLA和KPI中的示例。
| SLO | SLA | KPI | |
|---|---|---|---|
| 可用性 | 每月保证99.9%正常运行时间 | 滚动30天内确保系统请求正常响应率不低于99.95% | 与系统可用性相关的客户满意度评分（CSAT） |
| 错误率 | 所有API请求错误率低于0.1% | 用户交互错误率低于1% | 错误率趋势监控及主要错误根因分析 |
| 客户满意度 | CSAT评分不低于90% | 净推荐值（NPS）保持在8以上 | 交互后调查或反馈表，CSAT评分 |
可扩展性（Scalability）
LLMs通常占用大量内存，常超出单机容量。如何将模型分布在多GPU或多节点上，同时保持性能，是技术难点。高效处理海量数据至关重要。
另一个挑战是扩展数据管道，确保以所需速度向模型输送数据，避免瓶颈。这对聊天机器人或交互式服务尤为关键，低延迟要求极高。扩展过程中，资源争用和网络开销增加，平衡性能与成本始终是重点。
LLMOps的可扩展性可通过延迟、吞吐量、响应时间、资源扩展、容量规划和恢复时间目标（RTO）等指标衡量，见下表（表2-3）。
| SLO | SLA | KPI | |
|---|---|---|---|
| 延迟 | 95%的请求响应时间低于200毫秒 | API平均响应时间低于100毫秒 | 用户交互平均响应时间 |
| 吞吐量 | 高峰时段处理请求至少1000次每秒 | 支持至少100万并发连接且无性能下降 | 负载测试中的峰值吞吐能力 |
| 响应时间 | 95%的用户网页加载时间低于3秒 | 99%的用户登录流程完成时间低于500毫秒 | 与响应时间相关的用户体验指标 |
| 资源扩展 | 5分钟内自动扩展资源，应对50%流量增长 | 增加服务器后吞吐量线性增长，且无延迟影响 | 扩展测试结果及成本效益分析 |
| 容量规划 | 高峰期CPU利用率低于80% | 确保数据库连接数量足以应对预估峰值的两倍 | 资源利用率趋势及预测准确度 |
| 恢复时间目标 | 关键系统故障恢复时间不超过30分钟 | 系统能在15分钟内从数据库故障恢复并恢复服务 | 历史恢复时间数据及改进措施 |
鲁棒性（Robustness）
随着时间推移，模型训练数据的统计特性可能变化，导致模型性能漂移。这对处理实时或快速变化数据的模型尤为致命，表现为输出过时或不相关。
持续训练和微调是维持鲁棒性的必要手段，但需大量计算资源和谨慎管理，避免引入新偏差或错误。鲁棒性可通过数据新鲜度、模型评估和一致性等指标衡量，见下表（表2-4）。
| SLO | SLA | KPI | |
|---|---|---|---|
| 数据新鲜度 | 确保仪表盘数据每5分钟刷新一次 | 保证数据实时更新 | 数据刷新延迟及实时数据准确性 |
| 模型评估 | 6个月内性能退化率不超过5% | 定期更新和审核模型评估指标 | 评估指标的准确性、相关性和更新频率 |
| 一致性 | 保证所有区域读写数据强一致性 | 保持最终一致性，最大传播延迟1秒 | 一致性模型遵循度及复制延迟 |
安全性
维护LLM应用的安全性极具挑战性：这些复杂模型处理敏感数据，同时面临不断演变的安全威胁。LLMs特别容易受到对抗攻击、数据投毒及其他形式的利用，这些都可能危及模型的完整性和安全性。
在多访问或多租户环境中，管理和控制对LLM及其数据的访问非常复杂，但这是防止未经授权访问和滥用的关键。下表（表2-5）展示了一些衡量安全性的方式。
| SLO | SLA | KPI | |
|---|---|---|---|
| 数据隐私 | 确保所有传输和静态数据均加密 | 确保无数据泄露发生 | 加密合规状态 |
| 模型完整性 | 24小时内检测并处理任何模型篡改 | 保证及时发现和响应未授权修改 | 发现的未授权修改次数 |
| 访问控制 | 用户认证成功率达到99.9% | 确保健全的用户认证和授权机制 | 未授权访问尝试的频率 |
| 红队测试 | 确保检测到99.9%的对抗攻击尝试 | 确保定期进行安全评估和更新 | 安全评估频率及发现的关键漏洞数量 |
当所有团队——无论是开发、运维还是管理——都理解并认同商定的服务级别和性能指标时，他们能够更有效地协同工作，共同实现目标。这种一致性促进了统一的项目管理和绩效改进方法，也有助于基于数据做出资源分配、流程调整和战略变更的决策。最重要的是，这有助于建立信任，确保每个人对期望和结果保持共识。
总体而言，实施SLO-SLA-KPI框架不仅提升透明度和促进协作，还作为评估和提升LLMOps成熟度的基础要素，这也是本章最后部分的主题。
LLMOps成熟度模型
LLMOps成熟度是衡量一个组织的LLM运维实践与行业最佳实践和标准契合度的一种方式。评估LLMOps成熟度有助于组织识别自身优势、改进空间，以及扩展和增强LLM系统鲁棒性的机会。
几年前，微软发布了一套机器学习运维成熟度模型，详细列出了衡量MLOps生产环境和流程成熟度的逐步要求和阶段。我们在此提出的LLMOps成熟度模型，灵感来自微软的MLOps模型，旨在为LLMOps团队提供类似的评估方法。尽管这并非一份全面审计，我们希望看到更多不同版本的实践。
LLMOps的三个成熟度等级如下：
等级0
未实施任何LLMOps实践。组织缺乏正式的结构和流程来管理和部署LLM系统，导致效率低下。
等级1
组织采用了MLOps实践，但没有针对LLM的特定调整。在流程和规范方面比等级0有所提升，但仍缺乏全面的LLM运维所需的复杂度。
等级2
达到等级2表示LLMOps较为成熟，具备完善的文档、强健的监控和合规措施，并整合了先进的编排和人工审查策略。通常通过评估团队内是否对决策策略、模型性能指标等有良好文档来判定。
下表（表2-6）展示了LLMOps成熟度在文档和策略方面的评估指标：
| 等级0：无LLMOps | 等级1：MLOps，无LLMOps | 等级2：全面LLMOps | |
|---|---|---|---|
| LLM项目的业务目标和KPI是否有文档并保持更新？ | 无文档 | 有文档但常过时 | 完整文档，定期更新；KPI涵盖模型性能、运营效率和成本效益 |
| 是否有LLM模型风险评估指标的文档？ | 无正式风险评估 | 对模型准确性和数据安全有基础评估 | 包含偏差、公平性、数据漂移、性能退化及缓解措施的全面风险评估 |
| 是否有项目团队成员及职责的文档且定期更新？ | 无文档 | 记录高层角色，较新角色职责不明确 | 详细团队结构、职责和联系方式，定期审查和更新 |
| LLM选择及成本对比是否有文档？ | 无文档或成本分析 | 有基础文档，成本对比有限 | 详细文档，含选择理由、性能基准及与其他模型的成本比较 |
| 模型供应商API文档是否完善？ | 无API文档 | 模型自研 | 全面API文档，包括请求/响应示例、数据类型、错误码和版本信息 |
| 软件架构是否有完整且持续更新的文档？ | 无文档 | 有高层架构概览但可能过时 | 详细架构图，包括数据流、系统组件和集成点，定期更新 |
文档化这些因素对于选择和部署新模型非常有帮助。例如，考虑到部署LLM应用的高昂成本，成本基准分析文档能帮助公司决定采用哪个模型并估算项目时间表。
部署后，公司还需评估团队对模型性能指标的文档完善程度，确保团队成员理解预期目标并全面监控生产环境下的模型表现。
表2-7展示了与模型性能和评估相关的三种LLMOps成熟度级别：
| 等级0：无LLMOps | 等级1：MLOps，无LLMOps | 等级2：全面LLMOps | |
|---|---|---|---|
| LLM系统是否识别自身知识边界并知晓何时越界？ | 无识别机制 | 基础边界检测 | 高级保护措施，利用置信度评分和阈值等机制文档上下文相关警告 |
| 是否自动存储LLM输入输出？ | 无自动存储 | 基础存储 | 自动存储所有输入输出并建立索引，方便检索和分析 |
| 是否定期进行A/B测试？ | 无A/B测试 | 偶尔有限覆盖的A/B测试 | 定期且全面的A/B测试和分析，使用Optimizely或自定义框架 |
| 是否记录所有API请求和响应，监控响应时间和系统健康？ | 无日志与监控 | 基础日志与响应时间监控 | 完整日志及详细请求/响应分析，使用ELK等工具实时监控健康状态 |
| 是否监控LLM的毒性和偏见？ | 无异常检测和偏见监控 | 基础异常检测和人工审查 | 使用统计方法和定期偏见审核的高级自动化毒性和偏见检测，低置信度预测自动报警 |
| 是否确保LLM运营符合GDPR、HIPAA等法规？ | 无相关流程 | 有确保合规的流程 | 保障LLM运营遵守GDPR、HIPAA及相关数据保护和版权法规 |
| LLM应用是否使用匿名化保护用户身份，同时保持数据可用？ | 无匿名化 | 基础匿名化措施 | 高级自动化匿名化方法，包括数据掩码和聚合 |
| 是否定期进行LLM基础设施和代码的安全评审？ | 无定期评审 | 定期安全评审和审计 | 定期全面安全评审，包括第三方评估和漏洞扫描 |
下面详细介绍各等级：
等级0：无LLMOps
机器学习工作通常零散且实验性，缺乏系统的部署和监控框架。模型常在孤立环境中开发，导致不可靠且低效。雪佛兰聊天机器人事件即为典型例子：由于缺乏监控和保护机制，该应用被社区用来做代数作业，且误导性地推销雪佛兰和特斯拉汽车。
等级1：MLOps，无LLMOps
组织可能建立了较完善的模型训练、测试和部署流水线，并具备自动监控和再训练机制。但该体系面向小型模型设计，尚未充分适应LLM的特定挑战。
等级2：全面LLMOps
成熟度最高的状态，组织已全面采用LLMOps实践，基础设施支持大规模LLM部署、微调、实时推理、自动扩缩容和资源管理。成熟的LLMOps团队配备故障切换和回滚机制，能迅速应对部署后模型性能下降。组织能提供更可靠的响应，实现良好投资回报，降低运营风险。
总结
本章我们讨论了构建LLM应用的组织团队结构，介绍了各类岗位角色以及如何打造高效团队。最后，我们探讨了将LLM性能指标与业务KPI相结合的框架。下一章将聚焦于LLM如何改变数据工程格局，并展示如何为LLM构建高性能数据流水线。
参考文献
- Azure Machine Learning. “Machine Learning Operations Maturity Model”, Learn Azure, 访问时间：2025年5月21日。
- Friedman, Itamar. “Software 3.0—The Era of Intelligent Software Development”, Medium, 2022年5月3日。
- Lin, Chin-Yew. “ROUGE: A Package for Automatic Evaluation of Summaries”, Text Summarization Branches Out, （计算语言学协会，2024年）。
- Kadambi, Sreedher. “Shingo Principles: Bridging Lean and Toyota Production System Success”. Skil Global, 2021年5月28日。
- Mcintyre, Branden. “Chevy Chatbot Misfire: A Case Study in LLM Guardrails and Best Practices”, Medium, 2023年12月22日。
- Papineni, Kishore 等. “BLEU: A Method for Automatic Evaluation of Machine Translation”, ACL ’02: Proceedings of the 40th Annual Meeting of the Association for Computational Linguistics, 编辑：Pierre Isabelle, Eugene Charniak, Dekang Lin （计算语言学协会，2002年）。
延伸阅读
- Shingo, Shigeo. 《零缺陷质量控制：源头检验与防错系统》, Routledge, 2021年。
- Tennant, Geoff. 《六西格玛：制造与服务业中的统计过程控制与全面质量管理》, Routledge, 2001年。
