从 MLOps 到 LMOps 的关键技术嬗变

本文整理自 2023 年 9 月 3 日 QCon 全球软件开发大会 2023 · 北京站 —— 从 MLOps 到 LMOps 分论坛的同名主题演讲。

本次分享的内容结构如下：

• 从 MLOps 到 LMOps；

• MLOps 概述、挑战与解决方案；

• LMOps 实施挑战与关键技术（大模型推理性能优化、Prompt 构建和自动优化、上下文长度扩展）；

• 未来展望。

1 从 MLOps 到 LMOps

众所周知，目前我们实现人工智能的主要技术手段是机器学习技术，特别是其中基于深层神经网络的深度学习技术。机器学习的本质是通过具有学习能力的算法、对数据进行建模的技术。

深度学习借助大规模的算力，解决了机器学习中特征表示的人工干预的瓶颈，在效果上取得了巨大突破。因此，机器学习成为目前人工智能的主流技术。

深度学习和生成式大模型之间的关系，如下图右侧所示，在 2012 年至 2016 年左右，像卷积神经网络、对抗生成网络、ResNet 等经典的深度学习模型，已经在计算视觉、语音识别、自然语言处理等领域取得了显著的效果提升。这些经典深度学习模型既有判别式、也有生成式，它们往往会在 ImageNet、COCO 等有标注的数据集上进行预训练，形成带有预训练权重、可以进一步进行 Fine-tuning 的预训练模型。

在 2017 年 Transformer 结构在自然语言处理领域首先被成功应用，在这之后以 Transformer 为基础组件的生成式大模型逐步成为视觉、自然语言处理、跨模态理解和生成领域的主流技术。

这类技术通常以 Transformer 和注意力机制作为组件，并且它可以并行地进行自监督学习，参数规模在十亿以上。其中，将生成式大模型技术应用在语言建模上的方式，被称为「大语言模型」。在经过进一步的调优之后，形成了像 ChatGPT、文心一言等被大家熟知的对话式、生成式大语言模型应用。

DevOps 是贯穿传统软件生命周期的方法论和最佳的技术实践，它包括软件的需求提出、代码开发、测试、上线运维和推广运营等多个环节。其中的关键技术包括需求管理、版本控制、持续集成、组件化、容器化、微服务、持续交付、自动化运维等。目前 DevOps 的平台和工具已经成为大多数软件开发企业驾驭软件研发运营最有效的方法。

MLOps 是机器学习时代的 DevOps，其主要作用就是连接模型构建团队和业务，建立起标准化的模型开发、训练、部署、上线、监控的最佳实践，从而提高质量，简化管理流程。在大规模生产环境中自动部署机器学习和深度学习模型，让模型与业务需求、规则要求更好地保持一致。

下面，将为大家简单概述 MLOps 与 DevOps ，以及两者的共同点与区别，后面也会为大家详细讲解 MLOps 与 DevOps 相关概念、挑战与解决方案。

MLOps 与 DevOps 的共同点：

• 简化步骤流程：MLOps 与 DevOps 通过建立清晰、连续的步骤，简化软件开发 / 模型开发过程。MLOps 以缩短 ML 开发中的周转时间为主。

• 降低沟通成本：MLOps 与 DevOps 通过建立标准化的流程步骤，来降低沟通的成本。MLOps 相当于是系统管理员、数据科学团队和整个组织中其他部门之间对如何开发和维护生产模型达成共识。

MLOps 与 DevOps 的区别：

• MLOps 有更加复杂的版本控制：对于机器学习，代码并不是唯一不断变化的输入，数据、参数、元数据、日志以及最后的模型都需要做好版本管理。

• 持续监控和持续训练：DevOps 和 MLOps 中的监控之间的区别在于，软件不会降级，而机器学习模型会降级。数据将随着业务环境的变化和调整而继续变化和调整，从而导致模型退化。

和经典深度学习模型相比，大模型在人工智能技术与应用层面也发生了巨大的变化，比如在以下 4 个层面：

• 数据：首先在数据上大模型的预训练通常需要 TB 至 PB 级别的数据，这个数据规模和对应的数据加工技术，是和经典深度学习模型很不一样的。同时，现在的大模型还越来越多的以多模态、指令、对话数据作为训练或调优输入，在数据内容上和之前也有不同。

• 训练：现在的千亿参数级别的大模型，往往需要千卡甚至万卡进行分布式训练，这其中的调度、容错、通信技术和之前大不相同，大模型在调优过程中也出现了很多低资源开销、高效率的技术。

• 评估：经典深度学习模型往往基于人工标注的测试数据集，来计算客观指标，并评估模型效果。因为大模型生成的海量内容暂无标准的答案，所以我们无法全部依赖人工去评判内容的质量。因此，大模型的效果和性能需要建立与以往不同的评估基准和评估方法。

• 推理：通过提示工程去调教大模型的输出，无论在自然语言处理还是视觉生成领域，之前经典的深度学习模型都不具备这些能力。

大模型在技术和应用模式上带来了巨大的变化，也对企业提出了新的挑战，比如如何对 AI 能力进行运用和管理、如何实现大模型规模化落地。这些对于数据工程、模型调优、模型交付、服务运营、支撑能力等环节，都提出了新的要求。

LMOps 可以帮助企业解决大模型带来的上述新挑战。

LMOps 是大模型开发、运营一体化的方案，让企业快速自建与管理大模型。通过整合各种能力与模型运营全过程的标准化要求，帮助企业实现从数据到服务的完整流程，让大模型快速、高效地部署在生产环境中，提高大模型应用落地的效率和质量。

人工智能发展让 MLOps 和 LMOps 平台和工具呈现在我们眼前。接下来，我将为大家详细拆解 MLOps、LMOps 面临的挑战以及对应的解决方案。

2 MLOps 概述、挑战与解决方案

数据及模型缺乏统一的管理：底层基础设施不统一、且分散在不同的算法研发小组中。比如，在汽车工业早期实践中，一辆汽车的制作过程只由一位工人手工参与，缺乏协作而导致浪费大量的造车时间与人工精力。

这也让机器学习模型研发面临第二个问题，模型整体开发部署与迭代的周期较长。

模型的监控体系不够完善：模型在实验室环境下，是不会出现效果变化的，但现实业务数据则不同，随着数据分布和数据结构的变化，模型的实际应用效果则可能出现衰减，这就需要一个持续监控能力。

角色协同：因为人工智能整个应用系统的开发过程中, 会涉及到的业务团队, 运维团队和算法工程师团队之间的协同相关环节的打通，而往往就在这个环节中，我们会遇到一个难以逾越的障碍，这个真应了托尔斯泰的名言，通畅的企业是相似的，不通畅的企业各自有各自的不通畅方式。什么人有何种权限，能访问多少资源，彼此会不会冲突和影响，也需要一个统一协调和管理的平台或机制。

在 MLOps 的具体实践中，如果计划构建一个 MLOps 实践，需要贯穿机器学习生命周期的全流程，包括数据处理、模型构建、模型训练、模型部署、预测服务落地和后续监控优化。每个环节都有一系列的难题待续解决和管理。

所以，构建 MLOps 实践需要相应的工具，将各个流程之间进行自动化和打通，并建立起基于流水线的协同机制。

为此，百度智能云推出 AI 中台构建 MLOps 实践，让机器学习系统所有步骤自动化运行、实时监控。

百度 AI 中台是依托百度大脑十余年 AI 技术与能力的积累，目前，已经为金融、能源、互联网、教育、运营商、制造、政府等行业提供了智能中台解决方案，帮助企业构建统一的 AI 基础设施，实现 AI 资产的共建共享、敏捷的智能应用开发。

百度 AI 中台的功能架构全景图如下图所示：

• 样本中心：主要对接数据中台、获取数据，并对数据进行特征处理或数据标注。

• AI 开发平台：当数据完成特征处理、标注后，数据会进入 AI 开发平台来进行进一步的开发工作。AI 开发平台主要面向算法工程师，帮助算法工程师开发平台其他功能，快速进行模型开发和训练。

• 模型中心：完成训练的模型会进入模型中心统一管理。

• AI 服务运行平台：最终模型中心处理好的模型部署包，发往 AI 服务运行平台上线部署，最后由软件工程师整合到客户应用中。

AI 中台整个流程在模型风险管理的监控体系下，可以做到全流程可检查、可追溯，降低企业应用AI 能力的风险。而在整个流程中的数据，也可以形成对应的 AI 资产，进行企业内跨组织，跨部门的分享，打破部门藩篱，避免重复建设。

大模型平台是 AI 中台的组成部分，面向生成式 AI 的基础设施。百度 AI 中台既对外直接提供模型能力，又支持企业自主高效构建。

当前，百度 AI 中台已经覆盖 MLOps 方法论的核心环节，并已获得信通院相关标准旗舰级认证。百度 AI 中台也是国内唯一一家能获得此级别认证的产品或方案。

下面，将为大家简单介绍 MLOps 核心的技术。

• 自动化数据标注：模型真正运行起来，人工标注占据了大量的时间、人力劳动成本。MLOps 通过自动化方式进行数据标注，去除噪声数据，保证模型训练数据的质量，节省人工数据标注的时间、成本。

• 实验管理 + 版本控制：自动收集实验参数，配合 Git 等版本控制系统来管理代码、数据、模型文件等。当模型需要进行效果追踪和对比时，可以通过前期自动收集的实验参数进行回溯，不断优化模型效果。

• AutoML + AutoDL：使用 AutoML 等技术来自动搜索算法和调参，快速找到最佳模型并加速实验周期。

• 可解释性：通过可解释性技术来分析模型行为，响应大模型监管、安全的需求，提高模型透明度。

• 漂移监控：当模型上线以后，数据发生变化导致模型效果下降，所以需要不断监控、优化模型。漂移监控可以收集模型训练和推理的日志，设置关键指标，监控模型性能，并可实现自动重训。

• 模型适配：持续扩展模型适配的硬件范围，促成广泛环境下的自动部署。

• 模型压缩：使用剪枝、量化等技术来压缩模型大小，减少显存占用，提升运行速度，降低部署成本。

• API-Centric：平台主要操作行为可代码化，连同实验版本信息，可自动执行。

3 LMOps 实施挑战与关键技术

如下图所示，虽然 LMOps 问世不久，但整个上下游的各类公司已经共同构建了繁荣的生态。近期大模型引发的投资热里，有三分之一的资金投在了 LMOps 相关工具或平台上。

虽然企业较多，也出现了一些新面孔，不过依然可划分数据、训练、评估、推理、部署和安全这 6 个主要环节。今天时间有限，我挑了几个有大模型特色的技术点来和大家分享。

目前，针对大模型推理性能优化、Prompt 工程、上下文长度扩展等三个具有大模型特色的技术点，已经整合至百度智能云千帆大模型平台。

千帆大模型平台以智能云算力基础设施以及 AI 中台成熟能力为基础，重新定义了大模型时代的 AI 应用构建范式。其广泛兼容市场上的几十个主流大模型，覆盖 LMOps 生命周期，并可实现自动化。

应用开发者无需掌握模型细节，通过简单的页面交互即可进行大模型微调、评估、压缩、部署、提示功能等功能。同时还支持插件机制，应用方可以通过插件来扩展自身大模型场景。

3.1 大模型推理性能优化

QAT 是量化感知训练（Quantization-aware-training）的缩写，它是一种在模型训练过程中引入伪量化（Fake-quantization）来模拟量化过程中带来的误差的方法，目的是让模型能够适应量化后的数值表示，从而减少量化后模型的精度损失。

QAT 的优势是：

• 可以在训练时就考虑量化误差，使模型更加鲁棒，避免后处理量化带来的较大精度损失。

• 可以使用更高精度的梯度更新权重，避免量化噪声对优化过程的干扰。

• 可以使用更灵活的量化策略，如对不同层使用不同的量化位宽、对不同通道使用不同的缩放因子等。

QAT 的劣势和局限性是：

• 需要修改模型训练代码，增加伪量化操作和观察器，可能会影响模型结构和性能。

• 需要重新训练模型，增加训练时间和成本。

• 需要选择合适的量化配置和超参数，如量化位宽、观察器类型、校准数据集等，这些可能会影响量化效果。

百度智能云针对大模型提供四种训练后量化方案，分别是针对权重、激活层以及 k/v cache 进行量化，从而实现了不同压缩效果，供开发者使用。

per-channel 就是 weight 的每个 channel 使用单独的量化参数，这种方法比 per-tensor 的量化方法更细致，量化参数的自由度也更好，所以可以得到精度无损的效果。

per-group 是指对权重参数进行分组，再将每个组进行 int8/Int4 的量化。分组可以采用不同的策略，比如每 128 个权重参数分为一个组，然后它的每个组就可以有各自不同的最大最小值范围和精度，整体会精度更高。

针对大模型量化，可以在量化前增加一定的 smooth 过程，平滑权重分布，解决大模型权重分布不够均匀的问题。

引入超参数 s 可以很好地平衡量化过程中激活函数量化和权重量化之间难易度的差异，使得整个量化过程更加平滑，同时也提高了量化方案的泛化性。通过这两点改进，可以有效减轻大模型量化带来的精度损失，使量化后的模型精度更接近原始全精度模型，从而实现高效的大模型部署。

该方案通用性好，对于千亿级别的大模型能节省一半显存或卡数，且精度无损，同时速度也能提升 1.5 倍。

在前述方案中，权重和激活都是由 int8 保存的，但是大模型中另外一个消耗显存的运行时参数 k/v cache 依然是 FP16 保存的。

为此我们新增了 k/v cache int8 量化。可以在保证速度的情况下，显存进一步压缩 15%，节约运行时显存，实现真正意义上的全流程 int8 量化。

模型稀疏是一种模型压缩的技术，它的目的是减少模型中的参数数量，从而降低模型的存储空间和计算复杂度。模型稀疏的原理是利用某种策略（如权重剪枝、特征选择、矩阵分解等）将模型中的一些参数置为零或删除，让模型变得稀疏。在模型稀疏下，只有少数参数是非零的。

静态压缩是在训练结束后对模型进行压缩，动态压缩是在模型训练过程中就进行压缩。相比静态压缩，动态压缩使用更多，原因如下：

• 动态压缩可以持续优化。当训练过程中识别出不重要的参数，可以直接进行压缩。动态压缩可以随着训练的过程，持续进行压缩优化。

• 灵活调整。动态压缩可以根据资源情况动态调整压缩率，适应不同的部署需求。

• 动态压缩可以更好地保留重要信息。动态压缩可以在训练过程中识别参数重要性，保留对模型更为重要的信息。

百度智能云的大模型方案主要是基于业界最新的探索进行的方案实现。SparseGPT 是其中一个被应用的方案。

SparseGPT 算法是奥地利科学技术研究所 ( ISTA ) 的两名研究人员 Elias Frantar 和 Dan Alistarh 开创的，首次针对 100 至 1000 亿参数的模型规模，可以进行精确的单次剪枝方法。

SparseGPT 重建算法的可视化。给定一个固定的剪枝掩码 M，使用 Hessian 逆序列（HUj）并更新这些行中位于列「右侧」的剩余权重，逐步修剪权重矩阵 W 的每一列中的权重处理。具体来说，修剪后权重（深蓝?）「右侧」的权重将被更新以补偿修剪错误，而未修剪的权重不会生成更新（浅蓝?）。

该方法处理后的大模型，性能最大可提升 60%。此外，SparseGPT 是对量化方法的补充，二者可以结合应用。

另外一种被应用的方案是 WandA。

传统的剪枝思路是非常直接的，即对网络里的权重，如果其绝对值小于一定阈值，就会认为该权重所起到的作用不大，直接清空成 0。

新的 WandA 方案则是提出需要同时考虑权重和激活，因此处理时，先要将权重和激活进行一个乘法运算，然后将其中小于阈值的参数归零。

该方案在精度上并不比 SparseGPT 优越，但效率非常高，耗时上有数十倍的提升。

通过上述这些方法，自今年 4 月以来，千帆大模型平台上的部分模型推理性能已经提升了 10 倍以上。

3.2 Prompt 构建和自动优化

大模型因为参数量巨大，所以有着强大的语言生成能力。但是它的输出也极端依赖于输入的质量。如果输入不当，很可能得到错误的回答。

所以如何给大模型提供合适的输入，成为一个值得研究的问题。找到最佳输入方式的工作，现在被称为提示工程。

提示工程需要研究不同类型的提示格式，找到对特定任务最有效的表述方式。同时还需要考虑输入的长度、语句结构等因素，使 Prompt 既包含足够的信息，又不会过于冗长。

一个好的 Prompt 能明确交代任务要求，并让模型聚焦于关键信息，从而生成出优质的输出。

让普通用户自己构建复杂的 Prompt 往往不太实际，因为设计出一个高质量的 Prompt 需要专业知识和大量时间。如果直接让用户提供自然语言的问题或请求，系统帮助用户自动转换为合适的 Prompt，会对用户更加友好。理想情况下，用户只需要用简单的语句表达需求，不需要操心底层的 Prompt 格式。

为实现这一目标，一种方法是建立 Prompt 模板库，根据用户查询的意图匹配已有的高效模板，然后插入查询的关键信息，自动生成 Prompt。另一种方法是训练一个模型，可以直接把自然语言转化为充分表达其意图的 Prompt 语句。此外，还可以在用户查询后，用反馈机制多次迭代优化 Prompt，直到生成满意的回复。

常见的提示工程有一些经典办法:

• 直接提出问题，这是效果最难保障的一种方式。直接提出问题的方式，回答的效果取决于大模型训练是否充分，以及是否进行过良好的指令微调，压力主要集中在大模型侧。

• 小样本提示。用户先给大模型举一些例子，然后让大模型回答同类型的问题，这种方式的效果普遍较好。

• CoT 提示过程是一种最近开发的提示方法，它鼓励大语言模型解释其推理过程。思维链的主要思想是通过向大语言模型展示一些包含逻辑推理过程的样例, 并要求大模型在回答时同样显示推理过程。这种推理的解释往往会引导出更准确的结果。

• 生成知识提示，让大模型发挥自身潜在知识丰富的优势，通过自我完善背景信息，从而获得准确的答案。

刚才讲过人工的提示工程有两个问题，第一个问题是探索耗时巨大，普通用户不会费心思构建适合的 Prompt。第二个问题是不同的模板适应的任务有限，不通用。

在工程落地上讲，当前有两种办法可以使 Prompt 工程进一步自动化。

第一个是专用模型，即应用系统接收 Prompt 后，先发往一个分类模型, 让它判断这个 Prompt 是否可优化。如果需要，则发往一个专门使用大量指令训练出来的一个新模型，这个模型对原始 Prompt 进行润色和补充，然后再发往 LLM，从而获得更好的答案。这种方案简单直接，但整体推理开销变大了一些。

另一种方案是让大模型先生成结果，然后自己对结果进行分析，同时提供优化建议， 继续让大模型利用优化建议生成多个相关 Prompt，大模型对这些新生成的 Prompt 继续评估和建议，从而生成最佳 Prompt。该方案自动化程度更高，但也有两个局限，一是依赖核心大模型自身的能力，二是推理开销会更大。可以作为离线任务，对 Prompt 模板库进行自动补充。

3.3 上下文长度扩展

很多大模型的输入只有 2K 至 3K token，对大模型应用造成局限。所以每次大模型，例如 GPT-4、Claude 对 Context 进行扩展后，市场都给予热烈反馈。

这个四海皆同的痛点，导致学界和工程界提出了一系列的技术方案，例如外挂方案， 直接外推，内插方案等，来快速拓展大模型的输入输出长度。由于方案数量过多，本篇文章将为大家精选两个简单的方案进行详细描述。

为了解决大模型上下文长度不足的问题，我们可以采取一种直接的方法，即将原始输入或背景资料进行切分，并将其存入向量数据库。

然后根据用户 Prompt 到向量数据库中进行匹配，以向量数据库中匹配到的片段，作为 Prompt 背景知识，让大模型生成回答。

比如对一本书的内容进行提问，就可以用这种办法。

向量数据库可以提供快速的查询和检索操作，使得处理过程更加高效，也是为什么近期向量数据库突然火爆的原因。对于摘要任务也可以先切片，然后分段进行总结，将总结合并，或改变循环顺序。顺序摘要，层层总结。

然而，这种方法也存在一些局限性。例如，切分可能导致信息的丢失和重复，从而影响模型的准确性。

在一些特殊的长上下文场景，例如阅读理解，我们可以采用完全外挂的基于 Naive Bayes 的 NBCE 解决输入 query + 原文后长度超限的问题。其原理是：将原文切分成若干个小片段，并对每个片段采用 query 提问，并计算哪个生成结果与 query 最相关。其假设是问题只和原文的部分有关，并且切分的小片段之间对问题的回答没有相互依赖。但这种方法场景局限性很强，且效果一般。

所以，NBCE 应运而生。NBCE（Naive Bayes-based Context Extension）即朴素贝叶斯上下文扩展。NBCE 的主要适用场景是：假设要预测的答案可以分为若干个片段，每个片段只依赖于一个Context。它基于朴素贝叶斯思想来扩展 LLM 的 Context 处理长度，有着即插即用、模型无关、无须微调、线性效率、实现简单等优点。

那有没有更加通用的应对长上下文的方案呢？

目前业界用的比较多的是位置插值的方法。我们知道最原始的 Transformer 中，为了让同一个 token 的 Embedding，也就是输入 x，在不同位置上有区别，采用了对输入的 Embedding 向量进行绝对位置编码的方式，也就是在 Embedding 向量的每一个维度分量上加上一个基于绝对位置的三角函数增量值。

但这种方法直接扩展上下文长度的上限，会导致生成效果急剧下降。因此，有学者提出了对于经过权重矩阵 Q 相乘后的 query 向量和矩阵 K 相乘后的 key 向量分别乘以基于位置的三角函数的增量，也就是 RoPE 编码，它相当于把相同的 q 和 k 向量在不同的位置进行了不同角度的调整。

在这个编码的基础上进一步调整向量每一个维度的距离进制，就形成了位置插值的上下文长度扩展方法。这种方法的通用性较好，且仅需要少量长文本数据进行调优即可。当然，长上下文增强的技术还在不断发展，目前已经出现了不需要调优且较为通用的其他方法。

4 未来展望

过去的半年我们经历了一场百模大战，在开源社区隔三差五就有新的大模型出现，相关的技术也越来越标准化、同质化。特别是 LLaMA 系列, 让我们学了不少「驼」系英语单词，比如 llama 是美洲驼，alpaca 是羊驼，vicuna 是小羊驼。为什么有那么多以驼命名的大语言模型呢？

因为大语言模型 Large Language Model 的缩写是 LLM，当年 Meta 公司觉得两个 L 在一起不太好念，所以就选了一个相近的词语 llama，它的意思是美洲驼。而后来基于这个开源大模型调优的很多开源模型就都给自己取了驼系名称。

同时，我们可以看到在这一轮硅谷的大模型的创业公司中，不包括 OpenAI，有将近 1/3 的资金投入了 MLOps 和 LMOps 的工具和平台方向。

越来越多的高质量开源模型将充斥市场，国外是有 LLaMA 系列，国内也有一系列自主开源模型，这个状态还会延续一段时间。但由于模型本身同质，例如 Dolly 12B 等参数量较低，效果一般的模型会彻底沉寂。同时闭源模型会主攻多模态或更加智能的方向。

行业大模型也会是一个短期繁荣的景象。未来新一代超强模型会覆盖行业大模型的能力，从而抑制其发展势头。标志性事件就是 GPT-4 在金融领域的能力超过了专门训练的 BloombergGPT。一种解释是，大模型在数万亿的训练语料加持下，已经获得了全行业知识，只是缺乏合适的激发手段。当然这个是我们的一个基础判断，但行业尤其是企业，内部的知识库还是有其价值的，值得深入积累。

最后就是 LMOps 平台依然重要。因为企业关注成本，即便企业不再尝试自主开发大模型，但使用和运营 LMOps 平台依然有集约化建设和规模化运营带来的成本优势。

以上是今天分享的全部内容。

点击阅读原文，了解更多产品信息

——END——

推荐阅读

百度APP iOS端包体积50M优化实践(七)编译器优化

百度搜索内容HTAP表格存储系统

大模型时代，“人人可AI”的百度开发者平台长什么样？

数十万QPS，百度热点大事件搜索的稳定性保障实践

百度搜索万亿规模特征计算系统实践