一、引言

LLM 的 Training 與 Inference 存在很多共性，但也有極大的不同，LLM Inference 涉及的變量會更加復雜，需要采用的方案也會存在明顯區(qū)別，比如：：

• 不同的模型：通常不會使用單一模型解決所有問題，可能有不同規(guī)模、類型的模型，不同垂直場景的模型等。
• 異構(gòu)硬件環(huán)境：在 Inference 場景可選擇的 GPU 設備遠多于 Training 場景，比如可以使用 A100、H100、B200，也可以采用 H20、L40S、A30、T4，甚至可以選擇 RTX 5090、4080、3070 等。
• 復雜的數(shù)據(jù)分布：不同場景、Request、時段的流量分布、序列分布（輸入、輸出 Token 數(shù)）都會存在較大不同。
• 不同的 SLO 要求：Online、Offline 場景等會對時延、吞吐有不一樣的要求。
• 多變的框架、系統(tǒng)：業(yè)內(nèi)也存在非常多推理框架和系統(tǒng)，比如 vLLM、TRT-LLM、SGLang、LMDeploy 等。

為了獲得最優(yōu)的 Inference 性能，需要綜合考慮各方面的因素，在相應的約束條件下進行綜合的優(yōu)化。???2 萬字總結(jié)：全面梳理大模型預訓練相關技術(shù)??中已經(jīng)詳細總結(jié)了大模型預訓練相關技術(shù)，本文中進一步總結(jié)大模型 Inference 相關技術(shù)。

相關工作可以參考筆者之前的文章：

• ??2 萬字總結(jié)：全面梳理大模型預訓練相關技術(shù)??
• ??分而治之：全面解析分布式分離 Inference 系統(tǒng)??
• ??萬字綜述 10+ 種 LLM 投機采樣推理加速方案??
• ??LLM 推理框架之上：10 種常見 LLM 推理系統(tǒng)總結(jié)??
• ??揭秘 LLM 推理：全面解析 LLM 推理性能的關鍵因素??
• ??綜述：DeepSeek Infra/V1/MoE/V2/V3/R1 & 開源關鍵技術(shù)??
• ??GPU 關鍵指標匯總：算力、顯存、通信??
• ??LLM 推理的 Attention 計算和 KV Cache 優(yōu)化：PagedAttention、vAttention 等??
• ??字節(jié) MegaScale-Infer：分離式專家并行 MoE 服務系統(tǒng)??
• ??美團 Flash Communication：LLM 推理的 AllReduce 通信優(yōu)化??
• ??TRT-LLM MultiShot：LLM 分布式推理 3x AllReduce 加速??

二、基本概念

2.1 模型結(jié)構(gòu)

當前 LLM 基本都是 Decoder-Only 的 Transformer 模型，只不過會進行一些修改。比如對 Attention 的修改衍生出來 Softmax Attention 系列和 Linear Attention 系列。而對 FFN 的修改衍生出了 Dense 模型和 MoE 模型。如下圖 Fig.2 所示為標準的 Decoder-Only LLM 模型結(jié)構(gòu)：

• Multi-Head Attention（MHA）。
• Dense FFN。

2.2 LLM Inference 過程

Decoder-Only LLM 的 Inference 過程可以分為兩個階段：

• Prefill 階段：根據(jù)輸入 Tokens（Recite, the, first, law, of, robotics） 生成第一個輸出 Token（A），通過一次 Forward 即可完成，在 Forward 中，輸入 Tokens 間可以并行執(zhí)行，執(zhí)行效率很高。
• Decoding 階段：從生成第一個 Token（A） 之后開始，采用自回歸方式一次生成一個 Token，直到生成一個特殊的 Stop Token（或者滿足某個條件，比如超過特定長度） 才會結(jié)束。假設輸出總共有 N 個 Token，則 Decoding 階段需要執(zhí)行 N-1 次 Forward（robot, may, not, injure, a, human,  being），這 N-1 次 Forward 只能串行執(zhí)行，效率很低。另外，在生成過程中，需要關注的 Token 越來越多（每個 Token 的生成都需要 Attention 之前的 Token），計算量也會適當增大。

2.3 MHA & KV Cache

Attention 是 Transformer 模型中非常關鍵的一環(huán)，以標準的 Multi-Head Attention（MHA）為例，其主要計算集中在

• 左圖中灰色的 Linear（Weight 相關）。
• 右圖中的 Scaled Dot-Product Attention（Weight 無關）。

在標準的 Transformer Decoder 中，如上右圖的 Mask 是一個下三角矩陣，也是因為這個下三角矩陣實現(xiàn)了自回歸特性，每個 Token 只能看到當前位置及之前的 Token。

如下圖所示，其中的 QKT 可以理解為一個相關性矩陣，4 個 Token 對應 4 個 Step，其中：

• Step 2 依賴 Step 1 的結(jié)果，相關性矩陣的第 1 行不用重復計算。
• Step 3 依賴 Step 1 和 Step 2 的結(jié)果，相關性矩陣的第 1 行和第 2 行不用重復計算。
• Step 4 依賴 Step 1、Step 2 和 Step 3 的結(jié)果，相關性矩陣的第 1 行、第 2 行和第 3 行不用重復計算。

在 Decoding 階段，Token 逐個生成，上述計算過程中每次都會依賴之前的結(jié)果，此時最簡單的思路就是緩存之前計算過的中間結(jié)果（KV Cache）。在計算當前 Token 時直接從 KV Cache 中讀取而不用重新計算，如下圖所示，上面是沒有 KV Cache的情況，下面是有 KV Cache 的情況：

2.4 算術(shù)強度

2.4.1 Roofline 模型

在 AI 模型（或高性能計算）中，通常使用算術(shù)強度（Arithmetic Intensity）反映一個任務是計算密集型（Compute Bound） 還是內(nèi)存帶寬密集型（Memory Bound），可以用下式表示：

Arithmetic Intensity = 浮點運算次數(shù) / 訪問內(nèi)存的數(shù)據(jù)量

如下圖所示，每個硬件都有對應的內(nèi)存帶寬（比如 GPU 顯存帶寬）和算力大?。ū热?FP16 算力），據(jù)此可以繪制出針對該硬件的 Roofline，其中虛線對應算力和顯存帶寬的比例：

• 虛線左側(cè)：訪存多，計算少的場景為 Memory Bound。
• 虛線右側(cè)：計算多，訪存少的場景為 Compute Bound。

如下圖所示為常見 GPU 設備對應的 Roofline 轉(zhuǎn)折點：

以最常見的矩陣乘法為例，C(m, n) = A(m, k) * B(k, n)，假設數(shù)據(jù)類型 FP16，則：

• 訪存：bytes = 2*(m*n + n*k + m*k)，讀取 A/B，寫回 C。
• 計算：ops = m * n * (k + k) = 2*m*n*k，乘和加。

則 Arithmetic Intensity = m*n*k/(m*n + n*k + m*k)：

• m=1024，n=1024，k=1：Arithmetic Intensity = 1。
• m=1024，n=1024，k=8：Arithmetic Intensity = 7.9。
• m=1024，n=1024，k=512：Arithmetic Intensity = 256。
• m=1024，n=1024，k=1024：Arithmetic Intensity = 341。
• m=∞，n=∞：Arithmetic Intensity = k。

需要注意的是：如果使用 FP8 計算，則上述的算術(shù)強度以及 Roofline 轉(zhuǎn)折點都需要乘以 2。

2.4.2 標準 Transformer 模型分析

Decoding 階段 Token 逐個處理，使用 KV Cache 之后，上面介紹的 MHA 里的矩陣乘矩陣操作全部降級為矩陣乘向量，算術(shù)強度為 1（FP16），明顯 Memory Bound。

除此之外，Transformer 模型中的另一個關鍵組件 FFN 中也是以矩陣乘法為主，但是 Token 之間不會交叉融合，任何一個 Token 都可以獨立計算。在 Decoding 階段不用 Cache 之前的結(jié)果，但同樣會出現(xiàn)矩陣乘矩陣操作降級為矩陣乘向量，算術(shù)強度為 1（FP16），明顯 Memory Bound。

對于 Prefill 階段或者 Batching 場景，多個 Token 同時處理，可以明顯緩解 Memory Bound 的問題。整體來說，基本可以得出如下圖所示的結(jié)論（圖片來自：[2408.12757] NanoFlow: Towards Optimal Large Language Model Serving Throughput）：

• Prefill 階段（通常序列長度可以達到幾百甚至幾千），所有矩陣計算都是 Compute Bound。
• Decoding 階段：

• Batch Size 比較小時，Weight 相關的矩陣乘法都是 Memory Bound，而 Weight 無關的 Attention 計算的算術(shù)強度和采用的 Attention 方案及序列長度有關。
• Batch Size 比較大時，Weight 相關的矩陣乘法都是 Compute Bound，而 Weight 無關的 Attention 計算的算術(shù)強度和采用的 Attention 方案及序列長度有關。

2.4.3 MHA vs GQA vs MQA vs MLA vs MFA

GQA、MQA、MLA 和 MFA 等方案都是對 MHA 的改造，可以從精度影響、計算量、KV Cache 量以及算術(shù)強度幾方面衡量其適用性。（PS：相應原理在之前的大模型訓練技術(shù)綜述中已經(jīng)介紹，這里不再贅述）

如下圖所示可以看出，Attention 中影響算術(shù)強度的核心因素是 Attention 里 K 和 V 被多少個 Q 共享，以及 K 和 V 是否共享（假設 FP16 格式，并且序列長度 >= 幾百）：

• MHA：Q 和 K/V 對應關系為 1:1，算術(shù)強度為 1。
• GQA：Q 和 K/V 對應關系為 gq:1，算術(shù)強度為 gq。（每個 Group 里有 gq 個 Q）
• MQA：Q 和 K/V 對應關系為 hq:1，算術(shù)強度為 hq。（有 hq 個 Query Head，hq>=gq）
• MFA：等效于 MQA，算術(shù)強度為 hq。
• MFA-KR：K 和 V 共享，只用讀一次，算術(shù)強度為 2*hq。
• MLA：K 和 V 共享，只用讀一次，算術(shù)強度為 2*hq。

需要注意的是：如果使用 FP8 計算，則上述的算術(shù)強度都需要乘以 2。

2.5 LLM Inference 評估指標

LLM Inference 服務通常有兩種調(diào)用模式，一種是傳統(tǒng)的請求方式，一次請求獲得所有的生成 Token，這種方式的好處是請求鏈路比較簡單，但端到端的時間往往比較長，可能需要數(shù)秒，這也導致用戶體驗很不好；另一種是像 ChatGPT 一樣的 Streaming 方式，不是一次返回所有 Token，而是一邊生成一邊返回，只要生成速度大于人的閱讀速度就能獲得很好的用戶體驗。

針對上述的兩種方式，引申出不同的評估指標，如下圖所示：

• 對于非 Streaming 模式，通常需要評估其整個 Request 的時延（Latency），請求粒度的 QPS（Throughput）；
• 針對 Streaming 模式，通常需要評估第一個 Token 生成的時延（Time To First Token，TTFT）和后續(xù)每個 Token 的時延（Time Per Output Token，TPOT，有些也叫 Time Between Token， TBT）。

對于整個推理服務或推理系統(tǒng)而言，通常還會關注其整體的 SLO（Service Level Object）。

三、KV Cache 優(yōu)化

3.1 KV Cache 管理

3.1.1 PagedAttention

傳統(tǒng)的 LLM 系統(tǒng)會為每個 Request 預先分配顯存，如下圖 Figure 3 所示，假設模型支持的最大序列長度為 2048，則最多會為每個 Request 預先分配 2048 個 Token 的顯存空間。如果實際執(zhí)行中的輸入和輸出包含 10 個 Token，則將有 2038 個 Token 空間的浪費（內(nèi)存碎片），隨著服務支持的 Batch Size 增加，這一問題會愈加明顯：

為了解決上述問題，[2309.06180] Efficient Memory Management for Large Language Model Serving with PagedAttention 中參考操作系統(tǒng)中內(nèi)存碎片和 Sharing 的解決方案：帶分頁的虛擬內(nèi)存，提出 PagedAttention，并進一半衍生出 vLLM 推理框架。

如下圖 Figure 6 所示，PagedAttention 將 Request 的 KV Cache 劃分為多個 Block，每個 Block 可以包含固定數(shù)量的 Token 的 Key 和 Value，在 Logical KV Blocks 中 Block 是連續(xù)的，但是在 Physical KV Blocks 中 Block 是不連續(xù)的（對應預先分配的大塊物理內(nèi)存）。因此，可以像操作系統(tǒng)的虛擬內(nèi)存一樣，以更靈活的方式管理 KV Cache，當然，也就需要 Block Table 來管理這種映射關系。這樣的好處是可以將整個 Request 對應的 KV Cache 劃分為相同大小的 Block，Block 可以遠小于模型支持的序列長度，以此來緩解內(nèi)存碎片化。

3.1.2 vTensor & vAttention

PagedAttention 的方式會引入額外的管理開銷，也可能導致無法充分發(fā)揮 GPU 的算力，因此 vTensor（[2407.15309] vTensor: Flexible Virtual Tensor Management for Efficient LLM Serving）和 vAttention（[2405.04437] vAttention: Dynamic Memory Management for Serving LLMs without PagedAttention）中提出了使用 GPU Low-level 的 VMM API 來減少 KV Cache 內(nèi)存碎片，降低 Attention Kernel 開發(fā)成本。

如下圖 Figure 1 所示為 vTensor 與原始的 KV Cache 機制以及 Paged KV Cache 的區(qū)別，和 vAttention 類似，有 3 個好處：

• 可以實現(xiàn)內(nèi)存管理與 CUDA Kernel 的解構(gòu)，更加通用，Kernel 實現(xiàn)更加簡單。
• 可以實現(xiàn)內(nèi)存的動態(tài)擴展，減少浪費。
• Attention Kernel 可以使用更強算力的 Tensor Core（虛擬地址連續(xù)），而原始的 PagedAttention 可能受限只能使用 CUDA Core。

3.1.3 分布式 KV Cache

考慮到單 GPU 或者單實例的 GPU 顯存是有限的，而不同 GPU 也可能因為處理的序列不同而出現(xiàn)存儲的不均衡；此外，不同實例間可能需要 KV Cache 的共享和傳輸，衍生出了分布式 KV Cache 的需求。

阿里在 [2401.02669] Infinite-LLM: Efficient LLM Service for Long Context with DistAttention and Distributed KVCache 中首先提出了 DistKV-LLM，可以動態(tài)管理分布式的 KV Cache，通過協(xié)調(diào)整個數(shù)據(jù)中心中所有可以訪問的 GPU 顯存和 CPU 內(nèi)存，確保其可以適應各種上下文長度的場景，提供高性能的 LLM 服務。

如下圖所示為 DistKV-LLM 的概覽，當 LLM 服務實例由于 KV Cache 增加而遇到內(nèi)存不足時，DistKV-LLM 會主動識別并借用其他容量過剩的設備中的可用內(nèi)存空間，這種自動化機制通過兩個主要組件（rManger 和 gManager）的協(xié)作操作來實現(xiàn)：

• gManager 充當中心化管理器，維護所有實例的全局內(nèi)存信息，如下圖左圖所示。每個實例定期向 gManager 發(fā)送心跳信號，發(fā)送有關其剩余可用內(nèi)存空間的更新信息。gManager 利用這些信息構(gòu)建了一個詳細的表，稱作 Global Debt Ledger。
• rManger 提供統(tǒng)一的 API 接口，用于本地和遠程內(nèi)存操作，如下圖右上所示。這些操作包括：

• 為新生成的 KV Cache 分配 Physical rBlock，并在不再需要時釋放。
• 在收到 local 或 remote 的內(nèi)存分配請求時，rManager 會查詢 rBlock 表，以確定第一個可用的 Physical rBlock 空間。
• 在沒有足夠的空間時，rManager 會啟動從其他實例空間借用過程，如下圖右下所示。此時，如果分配請求來自 remote 實例，則 rManager 會返回錯誤響應，表示 remote 分配不可用，避免陷入死循環(huán)。
• 可以為分配給 remote 實例的 rBlock 數(shù)量設置上限，避免搶占 local 分配的空間。當然，該配置需要通過實驗確定，并配置為超參。

Moonshot AI 在 Github（GitHub - kvcache-ai/Mooncake: Mooncake is the serving platform for Kimi, a leading LLM service provided by Moonshot AI.）開源了 Transfer Engine 的具體實現(xiàn)，也在 Mooncake: Trading More Storage for Less Computation 中有簡單的介紹。

Transfer Engine 是 MoonCake 項目的核心組件，支持高速數(shù)據(jù)傳輸，特別是在分離架構(gòu)中專注于 KV Cache 數(shù)據(jù)的復用、管理和傳輸，以提高可復用性和效率。旨在解決分布式系統(tǒng)中數(shù)據(jù)移動的瓶頸，提升系統(tǒng)整體性能。Transfer Engine 能處理多種介質(zhì)，包括 Local DRAM、Local GPU VRAM、Remote DRAM、Remote GPU VRAM 和 Remote NVMe 等，滿足復雜分布式環(huán)境的需求。

NVIDIA 也開源了相應實現(xiàn)：GitHub - ai-dynamo/nixl: NVIDIA Inference Xfer Library (NIXL) 。NIXL 是專為分布式 AI Inference 場景設計的高性能 P2P 通信庫，用于多節(jié)點/GPU Inference 框架中的數(shù)據(jù)傳輸。 

類似方案還有開源的 LMCache（GitHub - LMCache/LMCache: Supercharge Your LLM with the Fastest KV Cache Layer），也在開源社區(qū)受到廣泛關注。除此之外，各種公有云平臺也都在推出類似的產(chǎn)品，比如 火山引擎發(fā)布了彈性極速緩存 EIC（Elastic Instant Cache），具體可以參考：??推理加速新范式：火山引擎高性能分布式 KVCache （EIC）核心技術(shù)解讀??。

3.2 KV Cache 壓縮 & 共享

3.2.1 KV Cache 量化

量化是緩解 KV Cache 存儲壓力，降低訪存 IO 最有效的方式，其實現(xiàn)簡單，并且與其他方案正交，是最經(jīng)常使用的手段。相比 FP16 的 KV Cache，量化為 INT8/FP8 可以將存儲和 IO 減半；量化為 INT4/FP4，更進一步可以將其降低到 1/4。

需要說明的是，KV Cache 量化可以和模型權(quán)重量化、低 Bit 計算解耦或者相互配合，比如可以只使用 INT8 量化 KV Cache，實際的模型權(quán)重，F(xiàn)orward 計算還都維持在 FP16/BF16。

3.2.2 Prefix Cache

除了在一個 Request 內(nèi)使用 KV Cache 來避免重復計算之外，不同的 Request 之間如果有相同的 Prefix，也可以使用對應的 KV Cache 來加速，這也是為什么在公有云的大模型 API 中，除了根據(jù)輸入 Token、輸出 Token 分別計費外，還會針對命中 Cache 的 Token 提供更低的價格。

在 [2312.07104] SGLang: Efficient Execution of Structured Language Model Programs 中，SGlang 團隊基于 Prefix Cache 實現(xiàn)了高效的 RadixAttention 以及 Cache 感知調(diào)度，以便充分發(fā)揮 Prefix Cache 的作用。

隨著當前 AI Agent 的發(fā)展，Prompt Engineer 和 Context Engineer 的場景越來越多，通過 Prefix Cache 來降低成本也變得愈加重要。為了提升 Prefix Cache 命中率，也有一些技巧（AI代理的上下文工程：構(gòu)建Manus的經(jīng)驗教訓），比如：盡可能不修改 Prompt，盡量不擴充或刪減工具。

3.2.3 KV Cache 稀疏化

在一個序列中，每個 Token 的信息熵是不一樣的，因此也就可以通常移除低熵 Token 來降低 KV Cache 的訪存壓力。KV Cache 稀疏化通常會與長序列場景的 Attention 稀疏化結(jié)合使用，在降低 KV Cache 壓力的同時大幅降低 Attention 的計算開銷。

然而，由于 LLM 的自回歸特性，很難預測 Token 在未來的生成過程中是否重要，因此往往不建議直接刪除 Token。

3.2.4 KV Cache 合并與共享

KV Cache 合并、共享是另一種有效節(jié)約 KV Cache 存儲的方案，如下圖所示，[2405.12981] Reducing Transformer Key-Value Cache Size with Cross-Layer Attention 中提出了多層共享 KV Cache 的方案。比如 CLA2 可以實現(xiàn)每 2 層共享的方式，Layer 1 中可以使用 Layer 0 的 KV Cache，實現(xiàn) 2x 的 KV Cache 節(jié)約；而 CLA3 對應每 3 層共享的方式，可以將 KV Cache 存儲降低到 1/3。

在常見的開源大模型中，目前主要看到騰訊的 Hunyuan-Large （[2411.02265] Hunyuan-Large: An Open-Source MoE Model with 52 Billion Activated Parameters by Tencent）采用了該方案。其采用的 CLA2，因此 KV Cache 可以在 GQA 的基礎上進一步減半：

3.3 Attention 優(yōu)化

前面已經(jīng)從算術(shù)強度分析了各種 Attention 的特性，其實這些方案的另一個重要因素是 KV Cache 大小。如下圖 Table 1 所示（來自 MFA Paper：[2412.19255] Multi-matrix Factorization Attention）：

• MQA 通常能獲得最小的 KV Cache，但是效果較差，現(xiàn)在很少使用。
• GQA 可以將 KV Cache 降低到 1/gq，通常能達到 1/4 或 1/8，并且對效果的影響較小，因此被廣泛采用。
• MLA 的 KV Cache 需求大于 MQA，但明顯優(yōu)于 MHA 和 GQA，同時效果更好。
• MFA 和 MLA 相當。

MFA 中也對各種方式的效果進行評估，如下圖所示，看著 MFA 會比 MHA 的效果更好，并且 MHA 會好于 MLA（此外，MFA Paper 中 Low-Rank 的 Rank 和 Head Dim 相同，而在 Step-3 的技術(shù)報告中兩者不同）。不過在 DeepSeek 的 Paper 中，MLA 會優(yōu)于 MHA。

四、模型壓縮

4.1 量化

4.1.1 量化方案

量化是模型壓縮中最常用的技術(shù)，不同的量化方案會采用不同的精度、Tensor 類型等，比如有常見的 KV Cache Only 量化，Weight Only 量化，以及幾種方案的結(jié)合，具體如下圖所示：

4.1.2 量化精度

不同的量化方案在不同模型上的量化損失也會有所不同，但是大體上來說，壓縮后的 Bit 數(shù)越低，損失越大。如下圖 Table 1 所示為 [2404.14047] How Good Are Low-bit Quantized LLaMA3 Models? An Empirical Study 中對 LLaMA3-8B 模型的量化評估（都使用 INT 類型，未使用 FP8/FP6/FP4），可以看出：

• W8A16 的量化損失都比較小，幾乎無損。
• W4A16 和 W8A8 的損失相比 W8A16 會大一些，大部分情況都可以接受。但也和量化方法有關，比如，GPTQ 和 QuIP 的 W4A16 相比 AWQ 的損失會更大一些。
• 更低 Bit 的量化損失會比較大，比如 W3A16 和 W2A16 的精度會明顯下降。
• 需要說明的是：下圖中 SpinQuant 的結(jié)果比較奇怪，W4A8 和 W4A4 的效果竟然比基線還高，而在 SpinQuant 的 Paper（[2405.16406] SpinQuant: LLM quantization with learned rotations）中并不會比 FP16 的高。

NVIDIA 的 GPU 從 Hopper 架構(gòu)開始可以支持 FP8 計算，使用 FP8 后其精度相比 SmoothQuant 的 INT8 以及其他的 W4A16 損失更小，更具有使用價值（數(shù)據(jù)來自 ??https://github.com/NVIDIA/TensorRT-LLM/blob/v1.0.0rc4/docs/source/blogs/quantization-in-TRT-LLM.md??）：

NVIDIA GPU 從 Blackwell 架構(gòu)開始可以原生支持 FP4，并且其 FP4 算力是 FP8 算力的 2x-3x；此外，對于更大規(guī)模的模型，使用更低 bit 量化計算的損失會更小一些。如下圖所示，NVIDIA 在 nvidia/DeepSeek-R1-0528-FP4 · Hugging Face 提供了 DeepSeek-R1 的 FP4 量化模型，其相比 FP8 的損失非常?。?/p>

百度在自研的 FastDeploy 推理框架中也進一步支持了 W2A16 的量化方式（??FastDeploy 2.0：大模型高效部署套件，文心4.5原生，釋放最優(yōu)推理性能！??），其在 ERNIE-4.5-300B-A47B 模型上的量化結(jié)果如下圖所示。其量化損失比較大（尤其對比的還是 INT4），但也不失為一種選擇：

4.1.3 吞吐提升

如下圖所示，在 [2404.14294] A Survey on Efficient Inference for Large Language Models 中作者評估了 TensorRT-LLM 和 LMDeploy 推理框架在不同場景的 W4A16 推理性能，使用的 GPU 為 NVIDIA A100，圖中的數(shù)據(jù)分別為 Prefill/Decoding/End2End 的加速比，可以看出，基本都可以實現(xiàn) 2x 左右加速，當序列比較長或者 Batch Size 比較大時會略低一些。

如下圖所示，使用 FP8 相比 FP16 可以加速 1.4-1.5 倍，這是比較早的數(shù)據(jù)，進一步優(yōu)化后可以到 1.7-1.9 倍：

如下表所示為 TensorRT-LLM 中作者對不同量化方案的總結(jié)，可以看出，如果 GPU 支持 FP8，則使用 FP8 是最理想的選擇，如果允許少量精度損失，則可以進一步使用 INT4-FP8 AWQ 的方案：

4.2 模型稀疏化

NVIDIA 在 Ampere 架構(gòu)的 Tensor Core 中加入了稀疏矩陣乘法支持，理論最多可以提升2x性能，實際上可能只有 1.5x，而且對稀疏化的方式有要求。如下圖所示，每 4 個 Weight 中需要有 2 個是 0 值，也就是可以剪掉的值：

基本上稀疏化都會帶來一定的精度損失，如下圖 Table 2 所示，論文 [2310.15929] E-Sparse: Boosting the Large Language Model Inference through Entropy-based N:M Sparsity 中作者評估了 2:4 稀疏化對模型精度的影響。可以看出（PS：論文圖片中的部分數(shù)字有誤，比如 13B 模型上 Magnitude 平均精度達到 57.71，實際平均只有 49.36）：

• 每種稀疏化方法都有一定的精度損失，即使最優(yōu)的方案損失也比較大。
• 不同規(guī)模的模型上精度損失差異比較大，小模型損失比較大。
• 13B 模型稀疏化后的精度還不如原始的 7B 模型，那么 13B 模型的稀疏化基本沒有太大的意義。

而其收益主要體現(xiàn)在速度的提升和顯存的節(jié)約，如下圖 Table 5 所示，其矩陣乘法可以加速 20%-30%，而端到端時延只能加速 16% 左右：

當然，顯存的節(jié)約還是比較可觀的，可以節(jié)約 43% 左右的顯存空間：

4.3 蒸餾

知識蒸餾是通過較大模型（Teacher）向較小模型（Student）傳遞知識的一種方式，其核心思想是借助 Teacher 模型讓 Student 模型獲得優(yōu)于從頭訓練的性能表現(xiàn)，或者明顯更低的訓練成本，因此在傳統(tǒng)的 CV/NLP 任務中得到廣泛應用。

Meta 在 LLaMA 3.2（Llama 3.2: Revolutionizing edge AI and vision with open, customizable models）中引入了知識蒸餾技術(shù)。具體來說，針對 LLaMA 3.2 中的 1B 和 3B 模型，Meta 在其預訓練階段整合了 LLaMA 3.1 8B 和 70B 的 Logits，并將這些模型的輸出作為 Token 級預測目標。

DeepSeek R1（[2501.12948] DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning）中也使用了類似知識蒸餾技術(shù)，如下圖所示，將 DeepSeek V3 和 DeepSeek R1 生成的數(shù)據(jù)用于 Qwen 和 LLaMA 系列模型的蒸餾：

阿里在 Qwen3 輕量級模型（[2505.09388] Qwen3 Technical Report）的 Post-training 階段中也引入了模型蒸餾方案，如下圖所示：

4.4 Token 稀疏化

4.4.1 概覽

對于常見的 Softmax Attention LLM 而言，Attention 計算與序列長度呈二次方關系，導致長序列場景 Attention 計算占比成為主要瓶頸。一種方式是采用 Linear Attention 方案，另一種是 Sparse Attention。相較于 Linear Attention，很多 Sparse Attention 不依賴預訓練的改造，代價更低，因此在社區(qū)中受到廣泛關注。

Sparse Attention 的主要動機是：Attention Score 是高度稀疏化的，只關注權(quán)重比較高的 Score 可以大幅降低計算復雜度并維持相當?shù)木取Ｓ捎?LLM Inference 中 Attention 計算主要與 KV Cache 相關，因此 Sparse Attention 也可以簡單理解為 Token 的稀疏化。其通?？梢詮?3 個方面來衡量：

• 是否節(jié)約 KV Cache 存儲空間。
• 是否能提升性能。需要說明的是，降低計算量并不意味著一定能提升吞吐。
• 是否影響精度。訓練后稀疏化幾乎必然會影響精度，主要還是對精度影響的大小。

4.4.1 Token 選擇

Token 選擇是 Token 稀疏化的前提，也是最重要的部分。通?？梢詮娜缦聢D Table 2 的幾個方面來衡量：

• 靜態(tài)選擇 vs 動態(tài)選擇：

• 靜態(tài)選擇意味著所有 Query 都選擇固定的 Pattern，比如常見的 Sliding Window Attention（[2310.06825] Mistral 7B），SnapKV（[2404.14469] SnapKV: LLM Knows What You are Looking for Before Generation） 等。
• 動態(tài)選擇意味著不同的 Query 會根據(jù) Query 內(nèi)容動態(tài)選擇哪些 Token 參與計算，比如經(jīng)典的 H2O（[2306.14048] H$_2$O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models）。

• 關鍵 Token：Sliding Window Attention 會讓每個 Token 都能關注到附近的一些 Token，而 Streaming-LLM（[2309.17453] Efficient Streaming Language Models with Attention Sinks）進一步發(fā)現(xiàn)序列初始的幾個 Token 也很重要，很多工作中也會保留。
• 稀疏粒度：可以按照 Token 粒度稀疏，也可以按照 Block 粒度稀疏。Token 粒度稀疏能最大化稀疏率，但不利于 GPU 的高效訪存和計算，因此一些高性能計算都會采用 Block 粒度稀疏化。
• Token 驅(qū)逐：對于動態(tài)稀疏 Pattern 場景，由于 LLM 自回歸特性，無法預知當前不重要的 Token 在未來是否重要，因此不可逆的 Token 驅(qū)逐很可能會影響效果。而重計算的開銷太大，不驅(qū)逐又達不到降低 KV Cache 存儲開銷的目的。

如下圖 Table 4 所示，[2412.10319] SCBench: A KV Cache-Centric Analysis of Long-Context Methods 中作者提出了 SCBENCH，并對常見稀疏化方案在長序列場景下的性能進行了分析，可以看出，這些方案多多少少都會有一些精度的損失，其中紅框為基線：

4.4.2 MoBA vs NSA

在 Token 稀疏化領域，今年比較火的有兩個工作（PS：都是針對長序列場景），一個是 Moonshot AI 的 [2502.13189] MoBA: Mixture of Block Attention for Long-Context LLMs，另外一個是 DeepSeek 的 Hardware-Aligned and Natively Trainable Sparse Attention。它們在某些方面都促進了一些共識：

• 長序列場景（Long Prefill 或 Long Decoding），Attention 是高度稀疏化的，也是高度動態(tài)化的。
• 固定 Pattern 的稀疏化方式往往很難保持精度，可學習 Sparse Pattern 是通用化且高精度的有效方案。
• Token 粒度的稀疏化很難充分發(fā)揮 GPU 算力，Block 粒度稀疏化是精度和性能（稀疏度、計算量）的良好平衡，基于此的高效 Block Sparse Attention 也成為標配。
• 當前常見的 LLM 通常會采用 GQA，也要充分結(jié)合 GQA 的特性來設計稀疏化方案，不然可能會影響整體的稀疏化程度。
• 在進行 Block 選擇時并不需要使用 Block 內(nèi)所有的 KV Cache，選擇一個代表性的“聚類中心”即可，比如取 Avg 或者 Max。
• 不要隨意永久性丟棄 Token，由于 LLM 的自回歸特性，很難推測在后續(xù)的生成中是不是一定不需要某個 Token。這也就是為什么在 NSA 和 MOBA 中并不會節(jié)約 KV Cache 的存儲空間。

如下圖 Figure 1 所示為 Moonshot AI MoBA 的主要原理：

如下圖 Figure 2 所示是 DeepSeek NSA 的主要原理：

其實在 MoBA 和 NSA 之前，微軟也提出過類似的工作 SeerAttention（[2410.13276] SeerAttention: Learning Intrinsic Sparse Attention in Your LLMs），其主張通過學習而非預定義方式來實現(xiàn) Attention 稀疏性。具體來說，通過引入一個可學習的門控機制，自適應地選擇 Attention 中的重要 Block，并將其他 Block 忽略。這種 Block 稀疏性有效地平衡了準確性和 Inference 速度。

五、優(yōu)化手段

5.1 基礎優(yōu)化

5.1.1 Continuous Batching

如前所述，LLM Inference 的 Decoding 階段逐個生成 Token，導致存在明顯的 Memory Bound，一種有效的手段是通過 Batching 策略來提升算術(shù)強度，進而提升算力利用率。

不過在 LLM 場景中，傳統(tǒng)的 Static Batching 或 Dynamic Batching 不再合適，雖然也可以一定程度緩解 Memory Bound，但會存在比較明顯的 Bubble，依然無法充分利用硬件算力。為了解決這個問題，Orca: A Distributed Serving System for Transformer-Based Generative Models | USENIX 中提出 Continuous Batching，在后續(xù)的工作中得到廣泛采用。3 種 Batching 的區(qū)別如下圖 Fig.9 所示：

• Static Batching：通常是固定的 Batch Size 大小，或者等間隔內(nèi)所有 Request + Padding。
• Dynamic Batching：動態(tài)的 Batch Size 大小，但是一個 Batch 內(nèi)的 Request 會一起處理完。LLM 中序列長度差異很大，會存在很多 Bubble。
• Continuous Batching：允許新的 Request 加入當前的 Batch 中，取代已經(jīng)結(jié)束的 Request 繼續(xù)執(zhí)行。

需要說明的是，如之前所示，無論是那種 Batching 方式，都無法緩解 Decoding 階段 Attention 處的 Memory Bound 問題（針對 MHA、GQA），只能緩解 Weight 相關的矩陣計算的 Memory Bound 問題。

5.1.2 Chunked Prefill

Continuous Batching 雖然可以降低 Bubble，但是依然會在高度動態(tài)化的序列長度下出現(xiàn)一定的 Bubble，在多 GPU 環(huán)境中尤其明顯。此外，超長 Prefill 也可能導致短 Request 的響應時間變長，影響整體的 SLO。

為了解決上述問題，[2308.16369] SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills 中提出 Chunked Prefill。如下圖 Figure 1 所示，Chunked Prefill 將 Prefill 分割成多個 Chunk 逐個處理，這樣 Request 可以更早的開始調(diào)度，Decoding Step 也可以插入到 Prefill 的 Bubble 中，充分降低 Bubble 率。

需要說明的是，這種方式也就需要更復雜的調(diào)度邏輯，進行更精細的控制。

5.2 投機采樣

5.2.1 概述

投機采樣或投機解碼（Speculative Decoding）是另一種常見的 LLM Inference 優(yōu)化手段，其核心是利用 Memory Bound 場景下的冗余算力來實現(xiàn)降低 Decoding Step 的目的。基本所有的投機采樣方式都包含兩個關鍵步驟：

• 通過某種方式生成一系列候選 Token 序列（可以是序列、樹、多頭樹等）。
• 通過一次 Forward 來并行驗證這些候選序列，只要平均每個 Step 驗證的 Token 數(shù) > 1，就可以降低總的 Decoding Step 數(shù)。

5.2.2. 多頭的方式

如下圖 Figure 3 所示，其思路很簡單，除了直接預測下一個 Token 外，還會使用額外的頭預測下下一個，下下下一個 Token，只是準確率可能會低一些而已。這樣就可以在 Decoding Step 的同時額外生成一個候選序列，下次 Decoding Step 來驗證即可：

多頭方式非常常見，用的也很多，比較典型的工作包括：

• Medusa：[2401.10774] Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads
• Eagle 系列：[2503.01840] EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test
• DeepSeek MTP：[2412.19437] DeepSeek-V3 Technical Report

5.2.3. 小模型生成

除了多頭之外，另一種常見的方式是使用小模型生成候選序列，然后使用更大的模型來驗證。比如使用 LLaMA 3B 作為草稿模型來生成候選序列，然后使用 LLaMA 70B 作為目標模型來驗證。這種方式通常會要求兩個模型是同系列的（同分布），使用相同的 Tokenizer、相同的數(shù)據(jù)預訓練，以便能獲得較高的接受率。

這種方式的好處是兩個模型可以獨立訓練，甚至可以獨立部署；當然，也可以通過蒸餾方式獲得草稿模型。

5.2.4. 利用歷史記錄或知識庫

對于確定的上下文（Prompt），后續(xù)的生成中很可能會包含其中的一些短語序列，或者說會包含某些以前的錯誤生成序列中的短語。比如說，“。。。He is a very very famous computer scientist.”，在 “。。。He is a” 處，如果額外生成一些序列，比如 “。。。He is a computer scientist.”，那么在 “。。。He is a very very” 的后續(xù)生成時是有可能利用上 “computer scientist” 這個子序列的。

現(xiàn)在也有很多任務通過 RAG 的方式來增強 LLM 的生成能力，生成結(jié)果中很有可能包含 RAG 檢索出來的子序列，可以增加猜中的子序列的概率。

也有方案通過外部知識庫來生成候選序列，與 RAG 類似，只不過檢索到的語料不是添加到 Prompt 中，而是用于構(gòu)建草稿 Token 樹。

5.2.5. 相關 Tradeoff

在投機采樣中，為了降低 Decoding 的 Step 數(shù)（也就是增加每個 Step 接收的 Token 的數(shù)），通常會采用草稿樹的方式，對應的 Attention 實現(xiàn)也就變成 Tree Attention。對應的 Attention Mask 如下圖所示：

然而，草稿樹的方式并不總是能降低整體的 Inference 時間/吞吐，也需要充分考慮 Token 接受率。如下所示為 Token 接受率的定義，接受率越低，浪費的算力越大，也就越難推廣到較大 Batch Size：

接受率 = 通過的 Token / 驗證的 Token

綜上：

• 在 Batch Size 比較小時，比如 1，2，4 時，由于 Decoding 的算術(shù)強度非常低，可以考慮使用草稿樹，以增加接受的 Token 數(shù)目；
• 當 Batch Size 比較大，比如 32，64 時，算術(shù)強度比較大，空閑算力相對較小，可以采用草稿序列，以增加 Token 接受率。

需要說明的是：如果 Batch Size 可以足夠大，Attention 計算也分配到合適的硬件上，所有算力都充分發(fā)揮，則投機采樣反而是負優(yōu)化，因為接受率不可能是 100%，總是增加開銷的。

5.3 并行 & 通信優(yōu)化

5.3.1 概述

如下圖所示，在 LLM Inference 過程中，通常會采用 TP（Tensor Parallelism） 和 PP（Pipeline Parallelism） 方式；對于 MoE 模型，還會使用 EP（Expert Parallelism） 方式。由于 PP 并不會降低 Latency，因此在 Online 場景中使用較少，主要是使用 TP 和 EP。

除了上述并行方式之外，[2407.00079] Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving 中針對長序列場景，將 TeraPipe（[2102.07988] TeraPipe: Token-Level Pipeline Parallelism for Training Large-Scale Language Models） 引入到 Inference 中，提出 CPP（Chunked Pipeline Parallelism），具體過程如下圖所示：

不同的并行方式會引入不同的通信方式，常見有兩種：一種是 TP 引入的 AllReduce 操作，另一種是 EP 引入的 All2All 操作；當然，還會涉及 PP 或分離式系統(tǒng)中的 P2P 等操作，這里主要聚焦在 AllReduce 和 All2All。

在優(yōu)化前需要明確通信的帶寬情況以及實際的通信占比。比如說，如果 TP 和 EP 限制在有 NVLink + NVSwitch 的節(jié)點內(nèi)，那么 AllReduce 和 All2All 的通信占比會遠小于使用 PCIe 或網(wǎng)絡通信的情況。

5.3.2 AllReduce 優(yōu)化

AllReduce 優(yōu)化中比較經(jīng)典的是 NVIDIA 的 3x Faster AllReduce with NVSwitch and TensorRT-LLM MultiShot | NVIDIA Technical Blog，其利用 NVSwitch 的 MultiCast 能力對 AllReduce 進行優(yōu)化，可以有效降低 AllReduce 操作的時延（降低時延和增加吞吐是非常不一樣的場景，NCCL 中的 AllReduce 更關注吞吐，而 LLM Inference 中的 AllReduce 更希望降低時延）。

TensorRT-LLM 中的 MultiShot 實際上是將 AllReduce 分成 ReduceScatter + AllGather，并且都進行獨立的優(yōu)化。可以將總的通信量從 Ring 方式的 4*(K-1)*T 降低為 2*T，通信步數(shù)也從 2*(K-1) 降低為 2，并且與設備數(shù)無關。

如下圖所示為 NVIDIA 進行的相關測試，LLM Inference 中 AllReduce 的通信量（機內(nèi)）往往不大，在通信的 Message 為 4KB - 1MB 時，使用優(yōu)化后的 MultiShot 方案可以將 AllReduce 的通信時延降低到 1/3 左右。

美團在 [2412.04964] Flash Communication: Reducing Tensor Parallelization Bottleneck for Fast Large Language Model Inference 中也對 AllReduce 進行了優(yōu)化，核心思路是將量化引入到通信中，通信前先對數(shù)據(jù)進行量化，通信后再反量化，通過降低通信量來降低通信時延。除此之外，也自定義了相應的 CUDA 算子。如下圖 Table 3 所示，其 INT8 量化的損失比較小，基本都可以接受。

華為也在 FlashComm大模型推理中的AllReduce通信優(yōu)化技術(shù) 中對 AllReduce 進行了優(yōu)化，其同樣是從量化、減少通信/計算量的角度分別優(yōu)化，在作者的實驗中可以獲得不錯的收益：

5.3.2 All2All 優(yōu)化

All2All 比較經(jīng)典的優(yōu)化是 DeepSeek 開源的 DeepEP（GitHub - deepseek-ai/DeepEP: DeepEP: an efficient expert-parallel communication library）。在之前的文章中已經(jīng)介紹，這里不再贅述。

5.3.3 細粒度 Overlap

在常見 LLM Inference 場景中，通常同一時間只有一個 Batch 數(shù)據(jù)在處理，會出現(xiàn)通信（AllReduce 和 All2All）無法 Overlap 的情況，即使采用了上述的通信優(yōu)化手段，依然無法完全避免其開銷。

有兩種常見的方案，一種是支持多個 Micro-Batch 同時處理，實現(xiàn)計算和通信的 Overlap，不過這種方式需要考慮總的 Batch Size 是否夠大，不然可能反而降低算術(shù)強度，從而影響性能；還有一種方式是使用細粒度 Overlap，也就是將相鄰的計算和通信拆分成更小的粒度，以便能實現(xiàn)細粒度的 Overlap。

細粒度 Overlap 的方案很多，比如字節(jié)的 Flux、Tilelink 以及 Triton-Distributed，在之前的工作中已經(jīng)具體介紹，這里不再贅述。如下圖 Figure 6 所示，比字節(jié) Flux 稍晚提出的 NanoFlow 也實現(xiàn)了類似的 Overlap 工作，通過細粒度的調(diào)度（控制 SM 數(shù)量），實現(xiàn)不同算子的 Overlap：

5.4 MoE 優(yōu)化

5.4.1 概述

最近一年多，MoE 模型逐漸成為大模型的主流，最新開源的 LLM 基本都是 MoE 結(jié)構(gòu)，并且都趨向于細粒度 MoE，比如 DeepSeek-V3/R1、Qwen-3、ERNIE-4.5、Kimi K2、GLM-4.5 等。MoE 模型相比 Dense 模型也會帶來更多的挑戰(zhàn)，比如需要更大的 Batch Size 來發(fā)揮算力、負載不均衡、需要 EP 并且會引入 All2All 通信等。

5.4.2 算術(shù)強度

對于 Dense 模型而言，其 FFN 模塊的算術(shù)強度與 Batch Size 呈正比，假設硬件 Roofline 轉(zhuǎn)折點為 256，則往往需要 256+ 的 Batch Size 才能比較好的發(fā)揮出硬件算力。對于 MoE 模型而言，假設 64 個專家，每個 Token 激活 4 個，則需要 4000+ 的 Batch Size 才能獲得同樣算術(shù)強度（負載均衡的情況下），對服務并發(fā)的要求高了很多。

總的來說，MoE 的算術(shù)強度除了受 Batch Size 影響外，還受專家激活度（激活專家 / 路由總專家，有些也稱作稀疏度）的影響；最后，還會受到負載均衡的影響。

5.4.3 負載均衡

即使在訓練階段添加了 MoE 負載均衡損失，依然無法保證嚴格的均衡，除此之外，即使全局均衡，也無法保證局部的均衡。因此，在 Inference 階段還是要處理 MoE 負載均衡的問題。

DeepSeek 在EPLB 代碼庫（GitHub - deepseek-ai/EPLB: Expert Parallelism Load Balancer）中開源了專家并行負載均衡器（Expert Parallelism Load Balancer）。其包含兩種負載均衡：

• 分層負載均衡（Hierarchical Load Balancing）：當節(jié)點數(shù)能整除專家組數(shù)量時，采用分層負載來利用組限制專家路由（group-limited expert routing）。比較適合 Inference Prefill 階段，此時 EP 的大小比較小。

• 首先將專家均勻分配到節(jié)點上，確保不同節(jié)點負載均衡；
• 然后，在每個節(jié)點內(nèi)復制專家實例；
• 最后，將復制的專家實例分配到各個 GPU 上，以確保不同 GPU 間的負載均衡。

• 全局負載均衡（Global Load Balancing）：其他情況下，采用全局負載均衡，該策略無視專家組的劃分，將專家復制至全局范圍，并將這些復制的專家分配到各個 GPU 上。此策略適用于 Inference Decoding 階段，此時 EP 規(guī)模較大。

在 DeepSeek V3 的技術(shù)報告等論文中，也提出了根據(jù)歷史負載來動態(tài)調(diào)整專家的方案，其從全局視角看相比靜態(tài)方式能獲得更優(yōu)的吞吐，但也會增加系統(tǒng)的調(diào)度和通信負擔。

5.4.3 專家剪枝

我們前面提到，算術(shù)強度與 Batch Size 以及專家激活度呈正比，當無法增加 Batch Size 時也可以通過增加專家激活度（激活專家 / 路由專家）來增加算術(shù)強度。在忽略效果影響的前提下，增加激活專家確實可以提升算術(shù)強度，但并不會提升吞吐，因此只能通過降低路由專家來提升算術(shù)強度。

在 [2411.08982] Lynx: Enabling Efficient MoE Inference through Dynamic Batch-Aware Expert Selection 中，作者提出通過專家剪枝的方式來提升算術(shù)強度，進而提升吞吐的方式。如下圖 Figure 10 所示，不是永久的刪除某些專家，而是在每個 Batch 中讓被選中的專家盡量少，由于每個 Token 的激活專家數(shù)不變，也就增加了被選中專家的算術(shù)強度。

需要說明的時：這種方式不是數(shù)學等價的，因此可能影響精度。

5.4.4 量化挑戰(zhàn)

相比 Dense 模型的 FFN，MoE 的量化存在幾個挑戰(zhàn)：

• MoE 中不同專家的離群值各有差異；
• 路由專家的選擇對量化引起的邏輯值擾動高度敏感（PS：這是從浮點型到整型的常見問題，比如像素中的索引，TopK 的索引等）。
• 在量化階段，極少被激活的專家可能由于數(shù)據(jù)覆蓋不足導致量化參數(shù)估計失準，進而產(chǎn)生較大量化誤差。

為了解決這些問題，[2505.21411] Pangu Pro MoE: Mixture of Grouped Experts for Efficient Sparsity 中采用了專家感知訓練后量化方法，來抑制 MoE 專家中的激活異常值。如下所示；

• 構(gòu)建一個統(tǒng)一的通道級平滑向量；
• 將專家權(quán)重和 Router logits 這兩個方向的最大縮放需求聚合在一起；
• 在保持與前置歸一化層的參數(shù)融合下的數(shù)學等價性的同時，重新分布異常值的幅度。

5.4.5 專家 Offload

此外，也有一系列工作探索了專家 Offload 的方案，將不常用專家 Offload 到 CPU 內(nèi)存中，以節(jié)約 GPU 顯存空間。結(jié)合 Prefetch 機制，可以盡量 Overlap 動態(tài)加載的額外開銷。如下圖 Figure 5 所示，這種方式通常會需要一種方式提前預測可能會激活的專家（比如額外的 Gate，或其他預測器），以便能實現(xiàn) Prefetch。

考慮到采用 EP 等方案后可以明顯緩解 GPU 顯存空間不足的問題，這種方式在實際的生產(chǎn)系統(tǒng)中使用不多，這里不再贅述。

六、推理系統(tǒng)

6.1 Multi-LoRA

在多租戶的 Inference 系統(tǒng)/集群中，經(jīng)常會存在多個用戶使用同樣基座模型（比如 Qwen 32B）微調(diào)的場景，如果每個用戶的流量都比較小，則會導致 Decoding 階段存在明顯的 Memory Bound 問題。針對這種場景，Multi-LoRA 是一種不錯的解決方案，有兩個比較經(jīng)典的工作：

• Punica：[2310.18547] Punica: Multi-Tenant LoRA Serving
• S-LoRA：[2311.03285] S-LoRA: Serving Thousands of Concurrent LoRA Adapters

以 S-LoRA 為例，作者發(fā)現(xiàn)，在傳統(tǒng)的方案下，如果有多個 LoRA Adapter，就需要合并成多個模型副本，喪失了不同 Request 間 Batching 的機會（例如 query1 需要調(diào)用 lora1，query2 需要調(diào)用 lora2，query3 需要調(diào)用 lora3。如果單獨合并，query1，query2，query3 需要分別調(diào)用獨立的模型 model1，model2 和 model3。然而，如果不合并，三個 query 在基座模型上的計算就可以 Batching 處理）。最終可以支持上千個 LoRA 模型，獲得 4 倍以上吞吐提升。

如下圖 Figure 1 所示，基座模型可以通過 Batching 計算，然后使用自定義的 CUDA Kernel 為所有的 LoRA Adapter 執(zhí)行額外的 xAB 計算：

Multi-LoRA 方案對于 Dense 模型比較友好，對于 MoE 模型會變得更加復雜。

• 對于 Dense 模型，Weight 相關部分變成一個 GEMM + 一個 Grouped GEMM 操作；
• 對于 MoE 模型而言，會變成多個（GEMM + Grouped GEMM）操作。

假設有 64 個路由專家，每個 Token 激活 4 個專家，Batch 中要激活 8 個 LoRA，則：

• 最優(yōu)情況：8 個 LoRA 激活的都是相同的專家，對應 4 個 GEMM（Backbone） + 4 個 Grouped GEMM（每個是 8 個小的 LoRA）。
• 最壞情況：8 個 LoRA 激活各不相同的專家，對應 32 個 GEMM（Backbone） + 32 個 GEMM（LoRA）。

當然，上述計算都可以合并為一個大的 Grouped GEMM，但效率會非常低，尤其是如果 LoRA 的 Rank 不同時會變得更加復雜。

6.2 分離式推理系統(tǒng)

6.2.1 概述

當前主流 GPU 服務器節(jié)點資源高度一體化，單純以節(jié)點為單位分配任務，容易造成資源利用不足，難以兼顧高吞吐與低延遲。因此，需要對集群資源（CPU/DRAM/SSD/GPU）進行更細粒度的解耦與重組。分離技術(shù)應運而生，包括模態(tài)分離、PD（Prefill & Decoding） 分離以及 Attention/MoE 分離：

• 模態(tài)分離：涉及將不同模態(tài)分開處理，例如在 Vision-Language 模型中，Vision Encoder 可以獨立優(yōu)化。
• PD 分離：將 LLM 的 Prefill 和 Decoding 階段分開，允許在不同硬件上運行，從而提高吞吐量，降低成本。
• Attention & MoE 分離：在 Decoding 階段，通過將 Attention 計算和 FFN（MoE）模塊分開，優(yōu)化 MoE 模型的資源利用率。

6.2.2 模態(tài)分離

廣義的多模態(tài)模型包括各種模態(tài)，比如語言（Language）、視覺（Vision）、音頻（Audio）甚至深度（Depth）信息。這里以狹義的 Language + Vision 模型為例，也是目前最常見的。

論文 ModServe（[2502.00937] ModServe: Scalable and Resource-Efficient Large Multimodal Model Serving）中，作者們兩種常見的 LMM 架構(gòu)（Decoder-only 和 Cross-attention）在真實生產(chǎn)負載下作了詳盡的系統(tǒng)層面分析和實驗，獲得若干深刻的洞察，揭示了 Inference 瓶頸、各階段資源特征以及生產(chǎn)環(huán)境中 LMM 請求的流量模式：

• 洞察一：各階段性能異質(zhì)，Vision Encoder 成為 TTFT 瓶頸。
• 洞察二：Vision 與文本處理可以并行，解耦有巨大加速潛力。
• 洞察三：架構(gòu)不同（Decoder-Only 和 Cross-Attention），LLM 后端的 Prefill 延遲差異巨大。
• 洞察四：Batching 策略、并行度對每一階段的影響大不相同。
• 洞察五：單體架構(gòu)限制了分階段獨立伸縮，導致大幅資源浪費。
• 洞察六：路由與排隊策略必須模態(tài)感知，否則極易形成 HoL 阻塞和尾部延遲。
• 洞察七：動態(tài)負載需按 Token 級吞吐速率而非簡單 QPS 衡量與擴縮容。

基于這些洞察，作者提出對應的 ModServe 架構(gòu)，如下圖 Figure 13 所示：

• 將 LMM Inference 模塊化解耦，Vision 和 Text 相關計算在不同實例資源上獨立調(diào)度和優(yōu)化。
• 支持自適應自動伸縮、模型切分與 Batching 策略，動態(tài)匹配真實時變流量，降低成本并精準滿足延遲 SLO。
• 設計模態(tài)感知調(diào)度與路由，有效應對圖像流量突發(fā)、請求異構(gòu)性，降低尾部延遲。

6.2.3 PD 分離

考慮到 Prefill 階段的 Compute Bound 特性與 Decoding 階段的 Memory Bound 特性（大部分情況）有明顯區(qū)別，也有很多工作嘗試將 Prefill 和 Decoding 分離，稱為 PD 分離。

比較早的工作是微軟和華盛頓大學提出的 Splitwise（[2311.18677] Splitwise: Efficient generative LLM inference using phase splitting），其為 LLM Inference 不同階段選擇不同類型 GPU。Prefill 階段選擇高算力 GPU，而 Decoding 階段使用算力不是特別強而訪存帶寬比較大的 GPU。同時使用高速的 IB 網(wǎng)絡實現(xiàn)兩個階段 KV Cache 的共享。

如下圖 Figure 10 所示為 Splitwise 的架構(gòu)概覽。Splitwise 會維護兩個獨立節(jié)點池：Prompt Pool 和 Token Pool，用于 Prefill 和 Decoding 的處理。第三個混合池（Mixed Pool）根據(jù)工作負載的情況來擴展 Prompt Pool 和 Token Pool。

然而，實際在 Moonshot AI 團隊與清華大學共同提出 MoonCake（[2407.00079] Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving）后，PD 分離方案才在社區(qū)內(nèi)引起廣泛關注和討論。MoonCake 系統(tǒng)以 KV Cache 為中心，采用分離式架構(gòu)，專為支撐多樣化、海量、具有高時延需求的 Inference 流量而設計，并且在生產(chǎn)環(huán)境大規(guī)模部署。

如下圖 Figure 1 所示為其主要架構(gòu)和流程：

• Conductor（全局調(diào)度器）：根據(jù) KV Cache 分布與預估請求負載，智能選擇 Prefill 節(jié)點與 Decoding 節(jié)點。
• KV Cache 復用：輸入經(jīng)過 Token 分塊，優(yōu)先復用已有 KV Cache 塊，需遠程拉取時平衡吞吐與時延。
• Prefill 分塊流水處理（CPP）：對長輸入流按 Chunk 分發(fā)多節(jié)點串行處理，計算與 KV Cache 傳輸可并行化，顯著降低延遲。
• KV Cache 傳輸與存儲（分布式 KV Cache）：KV Cache Pool 子模塊通過 RDMA 在 CPU 內(nèi)存/GPU 顯存/SSD 間實現(xiàn) KV Cache 高效傳遞與副本冗余，支持冷熱數(shù)據(jù)分級與 Cache 淘汰。
• Decoding 與 Batching 處理：Prefill 結(jié)束后，KV Cache 轉(zhuǎn)到預選 Decoding 節(jié)點，加入 Continuous Batching，高效生成后續(xù) Token。

24 年底，DeepSeek V3（[2412.19437] DeepSeek-V3 Technical Report）發(fā)布，其中的 PD 分離部署及 EP 優(yōu)化進一步引起大家對分離式部署方案的討論。

6.2.4 Attention/MoE 分離

一些工作在 PD 分離的基礎上進一步提出了 Attention 和 MoE（FFN） 的分離，主要基于以下洞察：

• MoE 模型的 Decoding 階段需要更大的 Batch Size 才能擺脫 Memory Bound 的限制；
• 更大的 Batch Size 也意味著需要更多的空間存儲 KV Cache，可能限制無法 Batching 足夠大的 Batch Size；
• Decoding 階段 Attention 部分的算術(shù)強度并不會隨著 Batch Size 的增加而大幅增加，與 Weight 相關矩陣計算表現(xiàn)出很大差異。

其中，字節(jié)跳動最早提出 Attention 和 MoE 分離系統(tǒng) MegaScale-Infer（[2504.02263] MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism）。該系統(tǒng)在 LLM 的 Decoding 階段，對各模型層中的 Attention 模塊與 Expert 模塊解耦，實現(xiàn)獨立擴展、定制化并行策略及異構(gòu)部署。

如下圖 Figure 3 所示為 MegaScale-Infer 的架構(gòu)，依然會采用常見的 PD 分離方案，也就是 Prefill 和 Decoding 有單獨的集群。不過其重點是 Decoding 階段，進一步對 Decoding 集群進行切分，包含 Attention 節(jié)點和 Expert 節(jié)點：

• Attention 節(jié)點：

• 每個節(jié)點包含全部 Attention 參數(shù)，采用 TP（Tensor Parallelism）。

• Expert 節(jié)點：
• 每個節(jié)點多個 GPU 存儲一個 Expert，采用 TP。
• 所有專家節(jié)點一起組成一個 EP（Exert Parallelism）組。
• TP：節(jié)點內(nèi) TP 可以充分利用高帶寬的 NVLink 通信。

采用分離式架構(gòu)后，Attention 和 Expert 是相互獨立的節(jié)點，并且數(shù)量可能不同。假設 M 個 Attention 節(jié)點，N 個 Exert 節(jié)點，則 Dispatch（A2E） 變成 M2N 操作，而 Combine（E2A）變成 N2M 操作。為此，作者也開發(fā)了高效的 M2N 通信庫。

為了解決資源浪費問題，作者引入了 Ping-Pong 流水線并行方案，與分布式訓練中的流水線并行思路類似。如下圖 Figure 4 所示，類似 Interleaved 1F1B，不過只有兩個設備，共 2*L 個 Stage（L 表示層數(shù)，每層都是 2 個 Stage）；此外，Stage 間的通信方式也稍有不同。

除了直接將 Attention 分離外，如下圖 Figure 7 和 Figure 8 所示，[2503.20552] Injecting Adrenaline into LLM Serving: Boosting Resource Utilization and Throughput via Attention Disaggregation將 Decoding 階段中 Memory Bound 的 Attention 計算部分 Offload 到 Prefill GPU 上執(zhí)行，從而：

• 提升 Prefill GPU 的內(nèi)存利用率；
• 提升 Decoding GPU 的 Batch size 和計算利用率；
• 整體提升吞吐量。

除了字節(jié)跳動的 MegaScale-Infer 之外，一些其他工作也探討了 Attention 和 MoE 分離的方案，比如：

• [2405.01814] Efficient Heterogeneous Large Language Model Decoding with Model-Attention Disaggregation。
• [2507.19427] Step-3 is Large yet Affordable: Model-system Co-design for Cost-effective Decoding

6.3 調(diào)度

LLM Inference 系統(tǒng)通常需要較大的并發(fā)才能充分發(fā)揮系統(tǒng)的算力、存儲、帶寬等資源。而 LLM Request 輸入和輸出具有高度動態(tài)性和不可預測性，同時又需要在系統(tǒng)中頻繁的存儲、傳輸 KV Cache，這都給實現(xiàn)高效的 LLM Inference 帶來極大挑戰(zhàn)。

為了最大化吞吐、最小化時延，需要充分優(yōu)化其中的調(diào)度機制，常見有如下幾種方式：

• FCFS（First-Come First-Serve，先到先服務）：隊列中等待時間較長的 Request 會被賦予更高優(yōu)先級，但該策略可能導致隊頭阻塞（head-of-line）問題，即早期長時運行 Request 會阻塞后續(xù)本可快速完成的短時 Request 執(zhí)行。
• SJF（Shortest-Job First，最短作業(yè)優(yōu)先）：通過優(yōu)先處理預估 Decoding Step 最少的 Request，在實現(xiàn)最低平均時延的同時避免上述問題，但其依賴精確的 Decoding Step 預測，有比較大的挑戰(zhàn)。此外，可能導致長任務饑餓，即預估高 Decoding Step 的 Request 因持續(xù)被新到達的低 Decoding Step Request 擠占而無法執(zhí)行。當然，可以引入最大等待時長等方式緩解。
• MLQ（Multi-Level Queuing，多級隊列）：通過逐步降級長時運行 Request 的優(yōu)先級（而非固定優(yōu)先級）來實現(xiàn)。
• KV Cache 感知調(diào)度：考慮 KV Cache 的高計算成本，可以優(yōu)先調(diào)度最大化 KV Cache 命中率的 Request，從而避免 KV Cache 重計算或 Offload 的額外開銷。

除了 Request 調(diào)度優(yōu)先級的問題，負載均衡也是需要重點考慮的因素，不僅涉及計算的負載均衡，還涉及 KV Cache 存儲以及 IO 傳輸。通過貪心算法將 Request 分配給當前負載最低的節(jié)點能獲得不錯的性能，但是結(jié)合 KV Cache 感知和分離式 Inference 系統(tǒng)后會變得更加有挑戰(zhàn)。為此，很多工作用會采用周期性分析和重排方式來盡可能的保持均衡。比如 DeepSeek V3 中提到會周期性進行專家的負載均衡，[2501.06709] Mell: Memory-Efficient Large Language Model Serving via Multi-GPU KV Cache Management 中會周期性的進行 KV Cache 的負載均衡。

6.4 模型路由

對于一個大規(guī)模 LLM Inference 系統(tǒng)而言，其支持的 Request 可能非常復雜，比如可能包含不同的類型，針對這種情況，模型路由也可以作為降低成本的有效手段。其核心在于通過路由機制從候選模型池中為給定 Request 推薦最優(yōu)模型。目前常見有兩種路由的范式：

• 按意圖路由：與傳統(tǒng)意圖識別思路類似。其思路是雖然小模型可能整體實力不如大模型，但是在某些垂類可能與大模型相當，比如代碼、數(shù)學等，此時如果判斷是代碼相關 Query 就可以直接路由到專業(yè)的代碼小模型。
• 按難易路由：其核心思路是說小模型雖然處理復雜問題能力不行，但是處理簡單問題時與大模型相當，那么簡單問題用小模型足以。比如 LeetCode 的 Easy 題目讓小模型處理，Hard 題目交給大模型。

這里面比較典型的是 SambaNova CoE（[2405.07518] SambaNova SN40L: Scaling the AI Memory Wall with Dataflow and Composition of Experts）、Hybrid LLM（[2404.14618] Hybrid LLM: Cost-Efficient and Quality-Aware Query Routing）和 RouteLLM（[2406.18665] RouteLLM: Learning to Route LLMs with Preference Data）。

如下圖所示，NVIDIA 也開源過基于 NIM 搭建類似系統(tǒng)的示例（GitHub - NVIDIA-AI-Blueprints/llm-router: Route LLM requests to the best model for the task at hand.）：

在這類系統(tǒng)中，Router 設計至關重要，也要充分考慮模型刪減、新增時的泛化能力。為了促進類似 Router 的發(fā)展，[2503.10657] RouterEval: A Comprehensive Benchmark for Routing LLMs to Explore Model-level Scaling Up in LLMs 中提出了 RouterEval 基準，整合了涵蓋常識 Reasoning、語義理解等 12 個主流評測維度的逾 200,000,000 條性能記錄，數(shù)據(jù)源自 8,500 余個異構(gòu) LLM 的評估結(jié)果?；诖耍髡咭矊ΤＲ姷?Router 進行了評估，表明當前的 Router 還有很大改進空間。

七、參考鏈接

1. Inference 綜述：[2404.14294] A Survey on Efficient Inference for Large Language Models
2. MoE Inference 綜述：[2412.14219] A Survey on Inference Optimization Techniques for Mixture of Experts Models
3. Inference 引擎綜述：[2505.01658] A Survey on Inference Engines for Large Language Models: Perspectives on Optimization and Efficiency
4. Inference 系統(tǒng)綜述：[2506.21901] A Survey of LLM Inference Systems
5. Attention 機制綜述：[2507.19595] Efficient Attention Mechanisms for Large Language Models: A Survey
6. Nanoflow：[2408.12757] NanoFlow: Towards Optimal Large Language Model Serving Throughput
7. PagedAttention：[2309.06180] Efficient Memory Management for Large Language Model Serving with PagedAttention
8. vTensor：[2407.15309] vTensor: Flexible Virtual Tensor Management for Efficient LLM Serving
9. vAttention：[2405.04437] vAttention: Dynamic Memory Management for Serving LLMs without PagedAttention
10. Dist-KV：[2401.02669] Infinite-LLM: Efficient LLM Service for Long Context with DistAttention and Distributed KVCache
11. MoonCake：Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM Chatbot
12. SGlang：[2312.07104] SGLang: Efficient Execution of Structured Language Model Programs
13. Manus：AI代理的上下文工程：構(gòu)建Manus的經(jīng)驗教訓
14. CLA：[2405.12981] Reducing Transformer Key-Value Cache Size with Cross-Layer Attention
15. Hunyuan-Large：[2411.02265] Hunyuan-Large: An Open-Source MoE Model with 52 Billion Activated Parameters by Tencent
16. LLaMA-3 Quantization：[2404.14047] An empirical study of LLaMA3 quantization: from LLMs to MLLMs
17. SpinQuant：[2405.16406] SpinQuant: LLM quantization with learned rotations
18. E-Sparse：[2310.15929] E-Sparse: Boosting the Large Language Model Inference through Entropy-based N:M Sparsity
19. LLaMA-3.2：Llama 3.2: Revolutionizing edge AI and vision with open, customizable models
20. DeepSeek V3：[2412.19437] DeepSeek-V3 Technical Report
21. DeepSeek-R1：[2501.12948] DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning
22. Qwen3：[2505.09388] Qwen3 Technical Report
23. Mistral 7B：[2310.06825] Mistral 7B
24. SnapKV：[2404.14469] SnapKV: LLM Knows What You are Looking for Before Generation
25. H2O：[2306.14048] H$_2$O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models
26. StreamingLLM：[2309.17453] Efficient Streaming Language Models with Attention Sinks
27. SCBench：[2412.10319] SCBench: A KV Cache-Centric Analysis of Long-Context Methods
28. MOBA：[2502.13189] MoBA: Mixture of Block Attention for Long-Context LLMs
29. NSA：Hardware-Aligned and Natively Trainable Sparse Attention
30. SeerAttention：[2410.13276] SeerAttention: Learning Intrinsic Sparse Attention in Your LLMs
31. Continuous Batching：Orca: A Distributed Serving System for Transformer-Based Generative Models | USENIX
32. Chunked Prefill：[2308.16369] SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills
33. Medusa：[2401.10774] Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads
34. Eagle-3：[2503.01840] EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test
35. TeraPipe：[2102.07988] TeraPipe: Token-Level Pipeline Parallelism for Training Large-Scale Language Models
36. Multishot-AllReduce：3x Faster AllReduce with NVSwitch and TensorRT-LLM MultiShot | NVIDIA Technical Blog
37. FlashCommunication：[2412.04964] Flash Communication: Reducing Tensor Parallelization Bottleneck for Fast Large Language Model Inference
38. DeepSeek DeepEP：GitHub - deepseek-ai/DeepEP: DeepEP: an efficient expert-parallel communication library
39. DeepSeek EPLB：GitHub - deepseek-ai/EPLB: Expert Parallelism Load Balancer
40. Lynx：[2411.08982] Lynx: Enabling Efficient MoE Inference through Dynamic Batch-Aware Expert Selection
41. Huawei Pangu Pro：[2505.21411] Pangu Pro MoE: Mixture of Grouped Experts for Efficient Sparsity
42. StepFun MFA：[2412.19255] Multi-matrix Factorization Attention
43. Punica：[2310.18547] Punica: Multi-Tenant LoRA Serving
44. S-LoRA：[2311.03285] S-LoRA: Serving Thousands of Concurrent LoRA Adapters
45. ModServe：[2502.00937] ModServe: Scalable and Resource-Efficient Large Multimodal Model Serving
46. Splitwise：[2311.18677] Splitwise: Efficient generative LLM inference using phase splitting
47. MagaScale-Infer：[2504.02263] MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism
48. Adrenaline：[2503.20552] Injecting Adrenaline into LLM Serving: Boosting Resource Utilization and Throughput via Attention Disaggregation
49. Model-Attention Disaggregation：[2405.01814] Efficient Heterogeneous Large Language Model Decoding with Model-Attention Disaggregation
50. StepFun Step-3：[2507.19427] Step-3 is Large yet Affordable: Model-system Co-design for Cost-effective Decoding
51. Mell：[2501.06709] Mell: Memory-Efficient Large Language Model Serving via Multi-GPU KV Cache Management
52. SambaNova CoE：[2405.07518] SambaNova SN40L: Scaling the AI Memory Wall with Dataflow and Composition of Experts
53. Hybrid LLM：[2404.14618] Hybrid LLM: Cost-Efficient and Quality-Aware Query Routing
54. RouteLLM：[2406.18665] RouteLLM: Learning to Route LLMs with Preference Data
55. RouterEval：[2503.10657] RouterEval: A Comprehensive Benchmark for Routing LLMs to Explore Model-level Scaling Up in LLMs?

本文轉(zhuǎn)載自??????AI閑談????????，作者：AI閑談