從 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 平臺依然有集約化建設和規模化運營帶來的成本優勢。