孟令公-大模型推理性能優化與實踐.pdf

《孟令公-大模型推理性能優化與實踐.pdf》由會員分享，可在線閱讀，更多相關《孟令公-大模型推理性能優化與實踐.pdf（45頁珍藏版）》請在三個皮匠報告上搜索。

1、孟令公 得物機器學習高級專家主要負責得物算法平臺的相關研發工作。在得物從0到1打造通用大模型訓練和推理平臺。曾就職于騰訊、阿里等多家互聯網大廠。2022年加入得物，專注于大模型相關技術，包括推理加速與各應用場景落地，曾在得物技術公眾號發表過多篇高質量大模型相關文章，比如：利用多Lora節省大模型部署成本，KubeAI大模型推理加速實踐，得物大模型平臺接入最佳實踐。演講主題：大模型推理性能提升實踐大模型推理性能優化與實踐得物技術 孟令公大模型推理引擎設計KV Cache高效顯存管理Prefill與Decode階段的優化利用多Lora節省成本其它優化手段大模型推理引擎設計應用程序用戶硬件支持：GP

2、U CPU NPU推理引擎核心模塊模型支持調度器PrefillDecodeKV Cache管理Llama系列Qianwen系列Other大模型推理引擎設計 業務方在訓練并部署大模型后，需要專用的大模型推理引擎來加速推理過程。當用戶發送請求時，Req 會首先傳遞給應用程序；當應用程序會調用大模型的推理引擎來觸發推理邏輯。大模型推理引擎的核心目標是提升推理速度和吞吐量，并兼容各種大模型和硬件。推理引擎的核心模塊主要包括調度器、Prefill、Decode 和 KV Cache 管理，這四個部分是性能優化的關鍵。當然，它還包括 Token、DeToken、采樣、模型支持、硬件支持(CUDA)等其他邏

3、輯。KVCache高效顯存管理-自回歸推理過程LLM輸入：輸出：人工智能是一項快速LLM發展快速LLM的發展LLM技術的退出條件：達到模型預定義的最大長度。遇到終止token。KVCache高效顯存管理-Attention計算Input:XQ=Wq*XK=Wk*XV=Wv*X每次計算，只需要當前的Q，但是需要之前歷史所有的K與V，因此需要為每個請求維護一個歷史K與V的緩存，叫做KVCache。KVCache高效顯存管理-KVCache與顯存碎片REQ硬件支持：GPU CPU XPU推理引擎Layer1Layer2Layer3前向傳播人工智能是一項快速發展的技術RESP需要為每個請求維護一個KV

4、Cache的緩存。隨著吐出Token的增加，KVCache會持續增大。KVCache高效顯存管理-KVCache與顯存碎片 KVCache在系統中占比多少？KVCache的頻繁申請與釋放會帶來什么問題？顯存碎片！就像內存管理一樣，頻繁的申請與釋放不規則的內存，時間長了都會產生大量碎片。圖片來自論文：Efficient Memory Management for Large Language Model Serving with PagedAttentionKVCache高效顯存管理-VLLM Paged Attention視頻來自文章：vLLM:Easy,Fast,and Cheap LLM

5、Serving with PagedAttentionKVCache高效顯存管理-VLLM Paged Attention VLLM 的 PagedAttention 是受操作系統虛擬內存和分頁啟發的注意力算法。它將注意力鍵和值（KV緩存）分成固定大小的頁，非連續存儲于內存中，從而高效管理內存，減少碎片，提高 系統的吞吐量。此外，它支持多序列共享內存，例如在并行采樣時共享提示詞的 KV 緩存，進一步降低內存開銷并提升性能。KVCache高效顯存管理-VLLM Paged Attention圖片來自文章：vLLM:Easy,Fast,and Cheap LLM Serving with Page

6、dAttention由于采用了Paged AttentionvLLM 的吞吐量比 HF 高 8.5 倍至 15 倍。KVCache高效顯存管理-SGLang Radix Attention圖片來自文章：SGLang:Efficient Execution of Structured Language Model Programs藍色框表示可共享的提示部分，綠色框表示不可共享的部分，黃色框標記不可共享的模型輸出?？晒蚕淼脑匕ㄉ贅颖緦W習示例、自一致性中的問題、多輪對話中的聊天記錄，以及思維樹中的搜索歷史。共享部分的KV Cache能否復用？KVCache高效顯存管理-SGLang Radix

7、Attention圖片來自V章：SGLang:Efficient Execution of Structured Language Model Programs1.初始狀態：基數樹最初為空。2.第一場聊天開始：用戶發送“你好！”，助手回復“你好！”，系統提示、用戶消息和助手回復被合并為基數樹中的一條邊，連接到新節點。3.第一場聊天繼續：同一會話中收到新消息，服務器在基數樹中找到已有前綴并重用其KV緩存，新消息作為新節點附加到樹上。4.第二場聊天開始：另一個用戶開始新的聊天會話，服務器分割現有節點，使兩個會話共享公共前綴和KV緩存。5.第二場聊天繼續并進行淘汰：第二場聊天繼續，因內存限制，第一場

8、聊天中最少近期使用的節點被淘汰釋放空間，新消息在共享節點后添加到樹上。6.處理少樣本學習查詢：服務器收到不與現有節點共享前綴的少樣本學習請求，根節點被分割以容納新序列，請求作為單獨分支插入樹中。7.處理一批少樣本學習查詢：收到一批共享相同少樣本示例的查詢，分割第六步的節點以在這些查詢間實現KV緩存共享，最大化重用并減少冗余計算。8.第一場聊天繼續并進行淘汰：第一場聊天繼續，基于最近最少使用（LRU）策略，淘汰第二場聊天的節點以高效管理內存。9.自一致性采樣并進行淘汰：服務器收到生成多個答案的請求，為自一致性目的，按照LRU策略淘汰較不重要的節點以為新請求分配內存。KVCache高效顯存管理-S

9、GLang Radix Attention圖片來自V章：Achieving Faster Open-Source Llama3 Serving with SGLang Runtime(vs.TensorRT-LLM,vLLM)大模型推理的關鍵階段Prefill與DecodePrefill輸入：輸出：人工智能是一項快速Decode發展快速Decode的發展Decode技術的退出條件：達到模型預定義的最大長度。遇到終止token。大模型推理的Prefill階段與Decode階段REQ硬件支持：GPU CPU XPU推理引擎Prefill階段對輸入Prompt進行批量計算Decode階自回歸逐個生成

10、新的詞或短語前向傳播人工智能是一項快速發展的技術RESP如何讓大模型的Prefill階段與Decode階段更加高效，GPU使用率更高，是推理引擎優化的重要目標。問題：輸入的Promt長度與最終生成的token長度，哪個影響大模型的推理耗時？Prefill階段-chunked prefillREQ推理引擎前向傳播人工智能是一項快速發展的技術人工智能是一項快速發展的技術RESP簡單來說，chunked prefill 是指系統將請求（Req）的輸入提示（Prompt，即 prefill）按照固定的長度（例如 512 個 token）拆分成若干小的塊（chunk），然后依次對這些拆分后的塊進行前向傳

11、播。相反，未經過 chunked prefill 拆分的請求，會將整個請求的提示一次性全部提交給引擎進行前向傳播。Prefill階段-chunked prefill圖片來自 Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve vLLM Fourth Meetup(Public)Prefill階段-chunked prefill圖片來自 Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve vLLM Fourth Mee

12、tup(Public)大模型推理的Decode階段REQ硬件支持：GPU CPU XPU推理引擎Prefill階段對輸入Prompt進行批量計算Decode階自回歸逐個生成新的詞或短語前向傳播人工智能是一項快速發展的技術RESP如何讓大模型的Prefill階段與Decode階段更加高效，GPU使用率更高，是推理引擎優化的重要目標。Decode階段-Continuous batching decodeREQ硬件支持：GPU CPU XPU推理引擎Prefill階段Decode階前向傳播人工智能是一項快速發展的技術RESPBatching參考上圖，由于 decode 階段一次只能生成一個 toke

13、n。如果在 decode 階段提交給 GPU 的請求批次（Batching）只有一個，就會導致 GPU 利用率不足。因此，在經過 Prefill 階段后的請求（Reqs）中，需要確保有足夠數量的 Reqs 通過批處理（Batching）進入 decode 階段，以實現批量解碼，從而提高 GPU 的使用效率。Decode階段-Continuous batching decode例子來自https:/ Decoding例子來自https:/blog.vllm.ai/2024/10/17/spec-decode.html草稿模型生成：草稿模型提出下一個詞元序列：I,like,cooking,and,

14、traveling。目標模型的并行驗證：將提出的詞元一次性送入目標模型進行驗證。錯誤檢測和糾正：目標模型發現第三個詞元“cooking”不正確，應該是“playing”。輸出生成：系統輸出糾正后的詞元，直到錯誤發生的位置：I,like,playing。Decode階段-Speculative Decoding例子來自 docs.vllm.ai調度策略優化REQ推理引擎等待隊列前向傳播自回歸生成新的TokenRESP服務收到REQ后，會首先把REQ加入到等待隊列中。由調度器按預定的策略從等待隊列中選取多個Req，組合批量請求(Batch)，進行前向傳播。調度器批量請求調度策略優化調度策略決定了調

15、度器如何從等待隊列中選擇和組合請求。以下是幾種常見的調度策略：先到先服務（FCFS,First-Come-First-Served）：按照請求到達的順序依次處理，不進行優先級排序。優點：實現簡單，公平性高。缺點：可能導致資源利用率不高，長請求阻塞短請求。最長前綴匹配（LPM,Longest Prefix Match）：優先處理具有最長匹配前綴的請求，通常用于優化緩存命中率。優點：RadixAttention中，提高緩存命中率，減少計算重復。缺點：實現復雜，可能不適用于所有場景。隨機調度（Random）：隨機選擇請求進行處理，避免特定請求長期等待。優點：簡單實現，避免請求饑餓。缺點：不保證公平性

16、和資源利用率最優化。目前我們默認使用最長前綴匹配調度策略+Radix Attention 緩存管理策略，可以取得最大的吞吐量CPU與GPU分離圖片來自https:/blog.vllm.ai由于 Python 的全局解釋器鎖（GIL）限制，在同一進程中，CPU 密集型任務（如網絡請求處理和數據格式化）會與 GPU 密集型任務（如模型推理）競爭 CPU 資源。通過將 API 服務器和推理引擎分離到不同的進程，可以消除 GIL 帶來的限制，使得 CPU 和 GPU 任務各自高效運行，避免資源爭奪，從而提升系統性能。利用多Lora節省大模型部署成本W 表示大模型的一個原始參數矩陣。Lora的思路是將矩

17、陣 W 拆分為兩個低秩矩陣 A 和 B。在訓練過程中，僅對 A 和 B 的參數進行訓練，這與訓練整個 W 的參數相比，能顯著減少所需的訓練參數數量，從而降低訓練成本。利用多Lora節省大模型部署成本大模型Lora微調Lora參數文件對于每個業務場景，我們首先通過微調訓練生成一個Lora參數文件，然后將Lora參數文件與基礎大模型合并，最后進行大模型的部署。這是一個經典的流程。數據基礎大模型合并參數部署大模型利用多Lora節省大模型部署成本場景1然而，如果業務場景眾多且每個場景的流量較小，就需要部署多套大模型。場景2場景3大模型1大模型2大模型3真的需要為每個場景都獨立部署一個大模型嗎？利用多L

18、ora節省大模型部署成本場景1每個業務場景都基于自己的業務數據訓練一個Lora文件。在部署時，我們只需選擇一個基礎大模型，并在顯存中同時加載多個Lora文件。這樣，便可以使用一塊顯卡同時滿足多個業務場景的需求。場景2場景3Lora1Lora2Lora3基礎大模型Req指定Lora Path利用多Lora節省大模型部署成本可見，多Lora對推理的吞吐與速度的影響幾乎可以忽略。部署模式QPS平均耗時Token吞吐7B大模型211s125 token/s7B大模型/多Lora1.810s120 token/s其他優化手段REQ推理引擎引擎層RESP前面我們通過對引擎層的KV Cache高效管理，Pr

19、efill與Dcode階段的調度策略，chunked prefill，并行Decode，多Lora等方式進行了調研與優化提速方案驗證。還可以針對模型層進行與底層庫進行優化，其中模型層可以支持相關的量化模型，底層庫可以使用更快的庫。模型層：fp16 int8等量化版本大模型基礎庫：Pytorch CUDA其他優化手段模型量化支持 AWQ量化支持，通過將模型權重量化為低比特位（如INT8），AWQ（Accurate Weight Quantization）在不顯著降低精度的情況下減少模型體積和計算量，加速推理。GPTQ量化支持，GPTQ（Generalized Post-training Quantization）是一種無需重新訓練即可對大型模型進行低比特量化的方法，保持原有性能的同時提升運行效率。其他優化手段底層推理庫優化 Torch compile，PyTorch 2.0的功能，它通過算子融合，生成高效的 Triton 內核，從而優化模型的執行效率。Cuda graph，NVIDIA提供的技術，預先記錄并復用GPU計算任務的執行流程，降低內核啟動和調度的開銷，提升GPU性能。謝謝