大语言模型运维（LLMOps）是针对构建、管理和扩展依赖大语言模型（LLM）的应用时所面临障碍的一套深思熟虑、结构完善的解决方案。从数据准备、模型微调，到寻找提升模型性能的方法，本文将概述大语言模型的生命周期及LLMOps的最佳实践。

LLMOps正逐渐成为DevOps领域的下一个重要主题。尽管在生产环境中运行大语言模型（LLM）所需的技能、工具和技术看似熟悉，但大语言模型的特殊需求仍需我们重新思考。

从数据准备、模型微调，到寻找提升模型性能的方法，下文将概述大语言模型的生命周期及LLMOps的最佳实践。

从DevOps到MLOps，再到LLMOps

首先，我们来定义LLMOps。LLMOps，即大语言模型运维（Large Language Model Operations），是一门新兴学科，专注于大语言模型的开发、部署和管理，将其作为应用背后技术栈的一部分。可以将其视为机器学习运维（MLOps）的一个专业分支——而MLOps本身又是传统DevOps实践与机器学习模型（包括LLM这类深度学习模型）特殊需求之间的桥梁。

那么，LLMOps应包含哪些内容呢？主要分为三个不同领域：

1. 模型开发与训练：对大多数人而言，这意味着获取一个基础模型并对其进行微调。微调是指以预训练模型为基础，使用特定用例或特定领域的数据进一步训练模型，以提升其在特定任务中的性能。最终得到的是一个专用大语言模型，无需从零开始训练。

2. 模型部署与集成：模型微调完成后，下一步是将这个专用LLM部署到生产环境中。从这一阶段开始，LLMOps会大量借鉴DevOps最佳实践，同时满足LLM特有的运维需求。例如，管理LLM所依赖的大量计算资源，确保文本数据的高效处理吞吐量。不过，LLMOps的独特之处可能在于，解耦的、事件驱动的架构比以往任何时候都更具相关性。

3. 模型监控与维护：当依赖LLM的应用投入生产后，LLMOps仍会继续借鉴DevOps的理念。在此阶段，我们可以利用模型监控数据来检测并应对模型漂移等问题，同时维护包括向量数据库、各类计算资源以及关键流数据管道在内的组件。

实际上，随着时间推移，你需要同时开展这三方面的工作。本文将重点关注第三个阶段：面向生产场景的LLMOps。但在此之前，我们需要先明确为何需要LLMOps。

为何需要LLMOps？

迄今为止，软件开发一直追求精确性。作为开发者，我们清楚代码的行为方式以及预期结果。然而，要理解LLM的运行逻辑却更加困难，因为它们本质上具有非确定性。在支持并行性、依赖外部数据以及存在类似随机性因素的情况下，我们知道Python中的一行代码每次运行都会产生相同的输出，但LLM的提示词（prompt）却未必如此。

不过，我们对大语言模型的一个明确认知是：将其集成到应用技术栈中，不仅仅是接入一项新的技术。相反，我们需要调整DevOps方法，以应对LLM带来的独特挑战，例如：

• 数据量庞大：由于依赖自然语言处理，LLM需要管理和处理海量文本数据。

• 计算资源消耗高：为LLM的训练和运行分配并优化所需的大量计算能力（尤其是在执行复杂任务或服务大量用户时）。

• 模型易发生漂移：随着时间推移，LLM输出的结果往往会发生变化。这些输出差异按严重程度可分为三类：首先是相对无害的侧重点变化；其次是性能的提升或下降（例如模型失去此前已具备的某项能力）；而最具问题的是“幻觉”现象——LLM会自信地将虚构或不当内容当作事实呈现。监控此类模型漂移是LLMOps的重要组成部分，就像确保关系型数据库的完整性是DevOps的一部分一样。

• 集成难度大：将LLM集成到现有技术栈中可能颇具挑战性，因为它们与传统API的响应方式不同，会带来独特的数据问题，且通常遵循不同的运行规则。

• 安全与隐私风险：提示词和响应都可能包含明文形式的敏感数据。

• 成本高昂：无论是使用OpenAI等外部LLM提供商的服务，还是部署内部大语言模型，成本都可能迅速攀升。

• 可扩展性与可靠性挑战：上述每一项挑战都会进一步增加确保基于LLM的应用应对需求变化的难度。

当新术语出现时，人们很容易将其斥为“流行词”，但LLMOps是针对构建、管理和扩展依赖大语言模型的应用所面临障碍的一套深思熟虑、结构完善的解决方案。

接下来，我们将深入探讨LLMOps的具体内容。

LLMOps技术栈

首先，我们需要明确将使用哪些工具。LLMOps工具大致可分为五大类：

• 数据管理

• 模型管理

• 模型部署

• 提示词工程与优化

• 监控与日志记录

下面我们逐一介绍。

1. 数据管理

在处理依赖LLM的架构时，最大的差异之一就体现在数据管理上。此类架构中的大部分数据是非结构化文本，且数据量可能极其庞大。常见的文本数据包括：

• 训练与微调数据源（具体取决于你是从零开始训练模型，还是对现有模型进行增强）；

• 检查点（checkpoints）——LLM在训练/微调不同阶段的状态快照；

• 提示词及其对应的响应；

• 检索增强生成（RAG）文本——需从外部来源检索，然后提供给LLM，为用户提示词补充上下文；

• 用于模型持续微调的文本来源。

从数据摄入、系统内流转，到存储和查询，数据管理主要分为三个部分：

（1）数据存储与检索

核心工具是向量数据库——它通过存储和搜索文本数据项之间的语义关系，对LLM起到补充作用。目前有多种可选方案，包括Weaviate、Qdrant、Pinecone等专用向量数据库。如果倾向于使用现有工具，pgvector（Postgres的扩展插件）可添加向量搜索功能；Redis、Couchbase、MongoDB等数据库也均提供向量搜索选项。

除向量数据库外，还需要块存储或对象存储来存储检查点等大型数据块；传统数据库工具也有其用武之地，例如存储和检索元数据、管理提示词，以及处理用于分析模型性能的数据。

（2）数据处理

从初始收集到质量控制，数据管理本身是一个多阶段过程，文本数据和非文本数据需要不同的工具和处理思路。这些阶段包括：

• 收集与聚合：若使用现有LLM，需从应用特定领域的数据源中获取数据；

• 分词（Tokenization）：将文本分解为单词或短语等较小单元，这是后续预处理阶段的基础。spaCy、自然语言工具包（NLTK）等工具可用于完成文本分割、标点符号或特殊字符处理等任务；

• 清洗与预处理：对于文本数据，NLTK等工具可去除文本中的冗余信息，以提高处理效率。例如，词干提取（stemming）等标准化技术可将单词简化为词根形式（如将“running”“runs”“ran”统一处理为“run”）。pandas可对表格数据执行类似处理，librosa则适用于音频数据；

• 标注（Annotation & Labeling）：为数据添加额外上下文（如社交媒体帖子的情感倾向、图像内容描述等）；

• 嵌入（Embedding）或向量化：将单词和短语之间的关系转换为数值表示。例如，“dog（狗）”和“cat（猫）”在向量空间中距离较近，而“donkey（驴）”与前两者的距离则更远。此阶段还可赋予单词上下文含义，例如区分“bark”在“狗叫”和“树皮”两个场景中的不同含义。OpenAI的Embedding API、Hugging Face的Embeddings等工具提供了不同的实现方案；

• 质量控制：Great Expectations等工具可根据你设定的标准验证数据；AI Fairness 360等工具包则可检测并帮助缓解数据中的偏差。

（3）数据分发

要在应用架构中高效、实时地传输所有文本数据，需要可靠的实时传输工具。可考虑使用Apache Kafka、亚马逊Kinesis，或Quix流应用平台。

2. 模型管理

大语言模型自身的生命周期管理（从开发、部署到更新）对于维持基于LLM的应用的实用性至关重要。其核心组件包括：

• 模型托管：若使用开源或其他自托管模型，需对LLM本身进行托管；

• 模型测试：Giskard等工具提供了模型自动化测试框架，可检测偏差、幻觉、有害响应、提示词注入漏洞等安全问题，以及质量控制问题；

• 版本控制与模型跟踪：可使用Neptune等集成模型注册表的一站式工具，也可选择lakeFS、DVC（数据版本控制）、Git（结合Git LFS处理大文件）等独立工具，对模型及其数据集进行版本控制；

• 模型训练与微调：TensorFlow、PyTorch等原本为传统机器学习模型设计的工具，可用于根据应用的特定需求微调大语言模型。

3. 模型部署

将大语言模型部署到生产环境时，所使用的工具大多与典型DevOps环境中的工具相同，也可根据偏好选择一些专用工具。

Kubeflow、Netflix的Metaflow、Databricks的MLflow、Skypilot等框架负责管理从测试到生产的全生命周期，包括启动云资源和容器资源、将工作负载部署到这些资源，以及根据需求波动管理资源。

正如前文所提及的，基于LLM的应用本质上具有对话属性，因此非常适合采用解耦的、事件驱动的架构。无需依赖微服务之间可能不稳定的同步API调用，而是通过Kafka或类似的流代理（stream broker）来管理LLMOps架构中各组件之间的数据流。借助Quix，你可以将应用作为容器部署，并使用Kafka主题（topics）编排各组件之间的数据流。

4. 提示词工程与优化

与传统软件工程不同，LLM用不精确的人类语言替代了精确的代码——这既是艺术，也是科学。当学生使用ChatAPI等服务寻求作业帮助时，查询的精确性并非关键；但当将大语言模型集成到应用后端时，用词选择、句子结构及其他细微差别都会影响响应的可预测性和效率。

目前已有多种提示词技术，每种技术都试图将特定方法规范化。例如，思维链提示（Chain-of-Thought Prompting）将问题分解为多个提示词，引导模型逐步推理；而零样本提示（Zero-Shot Prompting）和少样本提示（Few-Shot Prompting）则更接近我们向ChatGPT提出日常问题的方式。

由于获取可预测的提示词响应可能涉及复杂流程，“提示词工程”这一新兴学科应运而生，同时也出现了支持提示词创建、测试和管理的工具。这些工具主要分为以下几类：

• 提示词开发与测试：与其他场景类似，Jupyter Notebooks、Google Colab等工具提供了沙箱环境，可用于测试单个提示词，支持迭代式测试和优化查询。此外，也有专用提示词工程工具，例如PromptLayer、Knit可提供提示词测试、运行和协作的环境；LangBear等测试工具则支持对提示词进行A/B测试；

• 提示词分析：理解提示词的语言构成，有助于识别情感倾向、语法结构和上下文含义的不同表达方式对结果的影响。NLTK在此阶段仍有用武之地，可用于检查提示词的歧义性、一致性和效率；Hugging Face提供的模型可分析提示词的情感，帮助理解提示词细微变化带来的影响；

• 提示词版本控制：与普通代码类似，提示词会随时间不断修改。因此，我们可以借鉴模型管理的思路，使用熟悉的版本控制工具跟踪提示词的演变过程；

• 提示词链与编排：正如在传统软件工程中会将问题分解为更小的模块一样，将复杂问题拆分为针对特定方面的提示词，能让LLM的表现更高效。LangChain等工具可编排提示词流程，简化小型提示词的链接，同时管理来自向量数据库的上下文数据。

5. 监控与日志记录

与常规DevOps类似，模型监控和日志记录能帮助我们了解依赖LLM的系统的运行状态，并做出相应调整。

ROUGE（基于召回率的摘要评估指标）、BLEU（双语评估替补指标）等标准化指标框架，通过将LLM的输出与参考摘要对比，评估其特定方面的性能。更广泛地说，跟踪准确率和精确率有助于了解模型的可靠性。

此阶段可能使用的工具包括：

• 性能监控工具：Grafana等常用工具提供了用于接收LLM监控数据的插件，可帮助跟踪响应时间、准确率、吞吐量等指标；Weights and Biases等专用工具则通过可复现的实验帮助评估模型性能；

• 日志记录工具：无论是选择LLM Report、Helicone等专用LLM日志工具，还是ELK Stack等通用日志系统，LLMOps中的日志数据与其他场景并无太大差异。核心目标是通过日志洞察性能、可靠性和使用模式，识别可改进的领域。

以上虽未涵盖所有工具，但已能让你了解规划LLMOps架构时需要考虑的主要领域。

LLMOps最佳实践

了解可用工具是重要的一步，但要将LLM集成到应用架构中，还需考虑大语言模型的端到端生命周期——正如前文所述，这包括从数据准备、模型训练，到部署、监控和持续更新的全过程。

许多企业能够逐步采用DevOps实践，但向LLMOps的转型可能有所不同。因为LLMOps是一项“全有或全无”的工作：运行基于LLM的应用需要采用新的技术和工具，这使得这种转型不像DevOps那样可以循序渐进，灵活性更低。

在将LLMOps集成到工作流程之前，建议考虑以下LLMOps最佳实践：

1. 避免网络拥塞；

2. 做好大量静态数据的存储准备；

3. 在计算资源的弹性与成本之间找到平衡；

4. 加强数据安全与隐私保护。

下面我们将深入探讨这些最佳实践，了解它们如何帮助你制定成功的LLMOps策略。

1. 避免网络拥塞

过去二十年，软件工程似乎在高效的二进制协议（如Protobuf）和人类可读格式（如JSON）之间反复摇摆。而LLM则大幅倾向于人类可读文本，这可能带来问题——基于LLM的应用所需处理的网络流量，将远大于传统架构中REST API之间JSON数据的交互量。

可通过以下四种策略避免网络拥塞：

• 序列化：前文提到的分词和嵌入操作，不仅能去除不必要的字符，还能将令牌（token）之间的上下文关系表示为数值。这种方式将相对冗长的文本转换为更高效的表示形式，从而简化数据的传输和存储；

• 压缩：Gzip、Brotli等方法已针对HTTP和HTML负载进行了优化，可有效压缩文本和序列化数据；

• 缓存：使用Redis等工具将常用结果存储在靠近使用端的位置，可减少网络拥塞，并减少对LLM（无论外部托管还是内部部署）的调用次数；

• 架构解耦：如前文所述，使用Quix、Apache Kafka或亚马逊Kinesis在应用组件之间建立流数据管道，可降低应用某一部分的拥塞影响其他部分的风险。

2. 做好大量静态数据的存储准备

在LLMOps架构中传输大量数据是一方面，更重要的是制定这些数据的存储方案。常规数据处理方式与LLM架构所需的数据处理方式之间的差异主要体现在三个方面：

• 数据冗长性：文本数据的体量与软件开发中通常处理的结构化数据截然不同。LLM的训练和推理需要海量文本数据，这对存储容量、传输速度和检索速度都提出了挑战；

• 延迟敏感性：LLM通常需实时或近实时运行，因此最小化文本数据的访问和处理延迟至关重要；

• 数据关联性：LLM依赖对文本中单词、短语和概念之间关系的理解，而非LLM场景中使用的数据库并不擅长处理这类关联关系。

那么，在实际操作中应如何应对这些差异呢？

• 采用分层数据存储策略：对于原始文本数据，没有“一刀切”的解决方案，需在延迟、可扩展性和成本之间进行权衡。这与传统架构中的选择类似：对于低延迟、高吞吐量的工作负载，可使用亚马逊EBS等基于固态硬盘（SSD）的块存储；对于规模比访问速度更重要的场景，可选择S3等对象存储；

• 使用向量数据库：LLM数据依赖文本元素之间的多维关联，这需要与传统应用架构不同的数据模型。因此，需将Chroma、Milvus等向量数据库作为LLMOps架构的核心。若所选工具支持，还需考虑采用自托管还是云部署模式：自托管可提升响应速度，但需承担额外的管理工作以确保其稳定运行和高可用性；云部署虽可能增加成本和延迟，但能简化日常维护。

3. 在计算资源的弹性与成本之间找到平衡

基于LLM的应用对处理能力要求极高，这使得我们对云资源高效利用的担忧愈发突出。不过，在这一领域，我们可以借鉴非LLM应用的有效实践，例如：

• 使用自动扩展工具；

• 尽可能使用缓存；

• 优化实例类型，避免为不需要的资源支付额外费用；

• 为可预测的工作负载使用预留实例。

4. 加强数据安全与隐私保护

将数据安全与隐私保护视为LLMOps的特有需求，似乎有些奇怪——毕竟，无论数据如何处理，它都是所有应用的关注点。但LLM能够生成类人文本的特性，会让人们对其产生超出其他技术的信任，这可能导致系统用户向LLM分享敏感数据或个人隐私。

为降低风险，建议采取以下措施：

• 对静态数据和传输中数据均进行加密；

• 在模型训练和增强之前，过滤输入数据，去除有害信息和敏感数据；

• 考虑使用Giskard等工具自动化模型测试，防范敏感信息泄露、提示词注入等风险；

• 实施身份与访问管理（IAM）系统，仅向必要人员授予访问权限；

• 遵守GDPR、CCPA等相关法规；

• 对系统进行审计，识别漏洞；

• 尽可能对数据进行匿名化或脱敏处理。

借助Quix构建实时LLM数据管道

几乎所有现代应用都依赖多个数据源的协同处理，最终为用户提供服务。但基于LLM的应用更进一步——它们依赖海量文本数据、需要高强度处理，且用户期望实时响应。

由于LLMOps应用对低延迟对话式交互的需求，事件驱动架构比基于REST API的架构更适合。Quix的事件流平台提供了一套完全托管的工具，支持你构建由Kafka驱动的事件驱动型LLM应用。你可以将模型直接部署到Quix Cloud，并使用你熟悉的Python库（结合Quix Streams开源Python库），在用户界面（UI）、模型、向量数据库及其他所需组件之间创建数据管道。

如需了解更多信息，可查看Quix文档或查看实际演示。

本文翻译自

https://quix.io/blog/llmops-running-large-language-models-in-production

，仅供参考学习