關鍵技術詳解｜騰訊一念 LLM 分布式推理優化實踐

作者 | 袁鐿

編輯｜李忠良

策劃｜AICon 全球人工智能開發與應用大會

從 vLLM、SGLang，到 TensorRT-LLM、MindIE，再到新興的“一念”，不同團隊在算子優化、顯存管理與調度策略上不斷博弈，性能指標在短短半年間就提升了數倍。為什么會出現這樣激烈的競爭？現有的開源框架是否已足夠成熟？推理系統究竟卡在哪些“瓶頸”？

InfoQ 榮幸邀請到了 袁鐿 騰訊 /PCG 機器學習平臺技術負責人在 AICon 全球人工智能開發與應用大會·深圳站上分享了《一念 LLM 分布式推理優化實踐》，從 KV cache 全鏈路管理、算子封裝與自研，到多維并行（PP/DP/EP）、MoE 負載均衡與 MLA、以及 PD 分離與多階段流水線調度，給出了一套工程化解法。

12 月 19～20 日的 AICon 北京站 將錨定行業前沿，聚焦大模型訓練與推理、AI Agent、研發新范式與組織革新，邀您共同深入探討：如何構建起可信賴、可規模化、可商業化的 Agentic 操作系統，讓 AI 真正成為企業降本增效、突破增長天花板的核心引擎。

詳細日程見：

https://aicon.infoq.cn/202512/beijing/schedule

以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。

“一念 LLM”是一款面向大語言模型的推理框架，與 vLLM、SGLang、TensorRT-LLM 等同屬一類。那么，在已有眾多開源框架的前提下，為什么還需要開發“一念 LLM”？

要回答這個問題，先看大語言模型推理框架的基本工作流：當系統接收到大量并發請求，請求首先進入并行調度模塊，隨后進入顯存管理。顯存管理包括為 KV cache 分配顯存；當顯存不足時，需要決定是從外部 KV Cache 調入，還是將部分請求 offload 到內存，或更遠的存儲介質。

顯存就緒后，系統會對請求進行批處理，并針對不同模型進行算子調度，生成 KV cache。隨后算子開始執行，完成后進入采樣階段。在生成過程中，會設置諸如 temperature 等參數，系統隨之生成一系列 Token。生成結束后，可能還需進一步處理，例如將 Token 轉換為結構化輸出（如 JSON），或對齊業務約定的模式；又或者在生成某個 Token 后，基于對下一個 Token 的概率分布，執行投機解碼以加速推理。

整體流程中，不同模塊大體對應并行調度、顯存與隊列管理，以及算子調度，這些也是各框架之間的主要差異所在。至于算子層面，若深入代碼會發現各框架相互借鑒較多：由于 Transformer 架構和模型結構相對穩定，優化路徑趨于一致；一旦某個算子實現效果更優，往往會被迅速吸收并推廣。

從貢獻角度來看，硬件廠商通常在算子研發上具備天然優勢，因為其對自家硬件的理解最為深入，能夠充分利用硬件特性進行設計。典型代表是 TensorRT-LLM 與 MindIE。

對于非硬件廠商而言，研發的重點更多集中在調度與顯存管理，例如 vLLM 最初從 paged attention 入手，SGLang 以 prefix caching 作為起點，而“一念”等框架也在此方向進行探索。同時，學術界也持續在這些機制上開展研究與創新。

另一個在算子方面貢獻顯著的群體是模型廠商，他們貢獻了大量算子。隨著 DeepSeek 的興起，過去半年間推理框架領域的競爭異常激烈。為什么會如此激烈？假設在 H20 16 張卡的條件下，可以部署完整版本的 DeepSeek 模型，如果所有算子的 MFU 僅為 60%，理論吞吐量應可達到 30K。

然而，實際情況是在今年 2 月份時，vLLM 和 SGLang 的性能僅為 2K。經過半年的激烈競爭與優化，目前 vLLM 和 SGLang 的性能已提升至原來的兩到三倍。與此同時，TensorRT-LLM 橫空出世，最新測試數據達到 11.2 K。

一念的最新數據則為 14.6K。但整體來看，與理論預估的 30K 相比，仍存在巨大的差距。這也意味著，在基礎設施層面仍有廣闊的優化空間，相關工作需要持續深入推進。

“一念 LLM”的設計思路與實踐

那么，為什么要做一念框架這件事？我們的判斷基于兩個核心因素。

首先，推理環節在業務邏輯中的比重將會越來越大。一個模型即可完成整個業務流程時，推理就會成為后臺系統中最龐大的服務。這一趨勢直接帶來對業務快速響應和系統穩定高效的更高要求。

對于一個開源框架而言，如果無法在研發路徑上保持較高的可控性，那么在定制能力與系統穩定性之間就會產生沖突，從而可能影響業務收益與整體的穩定性。

其次，在算子優化方面，硬件廠商和模型發布者往往會進行深度優化。因此，“一念”在設計時便以高效引入開源算子、支持多種硬件為基礎假設，并在此之上構建了基本結構。

在整體架構的最上層，我們采用的是手寫模型。事實上，大語言模型本質上都是手寫模型，只是常見的實現方式多基于 PyTorch，用 Python 編寫；而我們選擇使用 C++ 實現，并在此過程中進行顯存優化。

顯存優化的重要性不言而喻。以 Kv-cache 為例，其本身就會消耗大量顯存，而在追求更高吞吐量與更長序列長度的場景中，顯存問題尤為關鍵。同時，還需要通過高效的調度來進一步提升吞吐性能。

在算子層面由三部分組成：開源封裝、移植算子、自研算子。針對不同硬件進行適配，我們額外封裝了一層類 CUDA 的接口，以支持多種硬件平臺，包括 Nvidia GPU、華為昇騰芯片以及騰訊紫霄芯片。通過這一設計，可以實現對下層異構硬件的屏蔽，對上層提供統一使用體驗。

需要特別指出的是，由于我們對顯存實現了全流程的自主管理，在 R1 模型上，Kv-cache 的可用顯存比業界水平提升約 130%，而吞吐量提升約 30%。

推理優化的挑戰與突破

在進行大語言模型推理優化時，首先需要明確所面臨的問題與限制。隨著應用規模的擴大，Prefilling Tokens 的長度不斷增加，而真正導致效率低下的環節主要集中在 Decoding Tokens 階段。

如上圖，在 A100 上進行 Forwarding 計算時，隨著輸入 Token 數量的增加，GPU 的實時有效計算能力會逐漸逼近硬件上限。一旦達到上限，即便繼續增加 Token 數量，計算功率也無法進一步提升，只能通過延長計算時間來完成額外的任務。

另一個瓶頸在于 decoding 階段。其效率較低，因為在常規情況下每次僅能生成一個 Token，即便結合投機解碼，通常也只能生成兩到三個 Token。因此，提高 batch size 成為一個顯著的優化手段。

然而，增加 batch size 會帶來新的挑戰。由于序列長度不斷增長，較大的序列長度疊加更大的 batch size，將導致 Kv-cache 的需求急劇增加，從而直接受限于顯存容量。

因此，在有限顯存條件下，提升推理階段 Token 的并行處理能力。同時需要注意，一旦某一階段達到硬件極限，就不應繼續增加負載，否則只會導致整體耗時增加。

接下來，來看推理過程中的多個階段。在 MoE 部分，采用 256 個路由專家加 1 個共享專家的架構。如上 DeepSeek 的結構圖可以看到，在計算過程中，大量 Token 經過路由表時，會導致各個專家之間的負載分布不均。而共享專家的路徑則是全量 Token 直接通過，沒有經過路由，因此共享專家的負載會異常集中。

換言之，上半部分是稀疏計算但負載不均，下半部分則是高負載計算。典型的解決方案有兩點：一是通過增加并行 Token 數，使不均衡效應被攤薄；二是采用 EP 的方式，為共享專家設置多副本，將其分配到不同的卡或芯片上進行并行計算，從而獲得更多計算資源。

在 MLA 部分，其最大特點是對 Kv-cache 進行壓縮，從而減少單個副本內各卡的 Kv-cache 占用。但這也帶來新的問題：多卡之間的壓縮 CompressedKv 出現重復，造成顯存浪費。同時，額外的 Project 操作也進一步增加了開銷。對應的解決方案包括權重吸收，以及采用全 DP（Data Parallelism），即只保留一份副本，避免重復存儲。

目前的技術主要從計算、通信和顯存三個維度展開優化。最原始的方案是 全 TP（Tensor Parallelism），這種方式實現最為簡單，但其特點是：在 MoE 階段計算呈稀疏狀態，同時通信開銷較大；另一個關鍵問題是 Kv-cache 的冗余存儲。在全 TP 方案中 ，若使用 4 張卡，就會產生 4 份冗余副本。

針對這一問題，出現了第一批改進方案：通過減少冗余，將不同的 MoE 分配到盡量少的卡上。例如，將兩張卡之間的內容保持一致，計算邏輯相同，只是輸入數據不同（如 batch1 與 batch2）。

在這種情況下，可以邏輯上等價于將 batch 擴大一倍，從而使后續 MoE 階段的 batch 規模加倍。該方案的優勢在于顯著增大了 MoE 階段的 Token 數量，同時降低了部分通信與 Kv-cache 的冗余。但也帶來了新的問題：權重和 buffer 有所增加。

在實際的小規模部署中，會遇到 DP 無法擴展過大的問題。原因在于，當 DP 規模增大時，雖然 Kv-cache 的冗余有所減少，但權重與 buffer 占用卻顯著增加。如果資源消耗超過可用顯存，就會無法正常運行。

進一步擴展的思路是增加 MLA 與 DP 的份數，并在跨機時引入 EP。EP 的優勢在于通信量減少，因為它只需傳輸對應專家所需的參數、路由信息及部分狀態數據。

然而，采用共享專家進行負載均衡會增加顯存開銷，形成“蹺蹺板”效應。常見的解決方式是擴大批處理規模，將更多專家分布到多張卡上，即使每張卡只增加一個專家或共享專家，也能獲得收益。

不過，僅依靠擴大 DP + 大 EP 的組合方案仍不足以解決問題，因此引入了PD 分離（Prefill 與 Decode 分離）的思路。其原因在于 Prefill 與 Decode 兩個階段混合執行時會相互影響性能。Prefill 階段通常一次性輸入數千個 Token，會將硬件完全占滿。例如，若系統吞吐能力為 1K，卻一次性輸入 4K Token，則耗時將增加至原來的 4 倍；此時若 Decode 與之混合執行，Decode 的延遲也會隨之放大。

此外，在 DeepSeek 中，由于引入了權重吸收機制，Prefill 與 Decode 混合執行還會帶來額外的權重和顯存開銷。更重要的是，二者的最優 batch size 本就不同：Prefill 階段每個請求的 Token 數量較大，因此只需較小的 batch size 就能充分利用集群；而 Decode 階段則需要更大的 batch size 才能達到集群利用率最大化。

但其缺點在于需要進行 Kv-cache 同步，同時需要較大的并行請求規模，才能充分發揮硬件性能。這類需求往往適合高性能大規模集群，因此成為硬件廠商和云廠商最關注的場景。如果確有 PD 分離的需求，并不建議自行實現。因為該方案涉及調度、集群管理、故障排查等復雜問題，對周邊系統提出極高要求，實施和維護成本巨大。因此更為可行的方式是依賴云廠商的成熟解決方案。

最后值得思考的是，為什么推理系統會逐漸走向“小型機化”？按理來說，互聯網服務應當依托海量、低成本、具備柔性伸縮能力的機器來支撐，而不是依賴高性能單機。

但現實情況是，由于推理請求普遍為同步執行，且伴隨大量數據交換，這種模式逐漸推動了“小型機化”的趨勢。以上述推理過程為例，61 層的 DeepSeek 模型在輸出一個 Token 時需要進行 122 次跨機通信。如果中間環節的性能不足，其結果可想而知。

基于這一問題，我們必須探索其他路徑來減少跨機通信。從并行技術的角度來看，流水線并行是一種較為傳統的方案。以兩機為例，該方法僅需進行兩次跨機通信：一次將數據傳遞過去，另一次再傳回來，并且是異步進行的。這在通信量上具有明顯優勢。

然而，由于 Kv-cache 以及自回歸邏輯等特性，使得當前推理框架在實現多 batch 推理時的復雜度和成本依然較高。

在“一念”的實踐中，目前在多階段流水線并行方面實現較為完善，整體性能處于領先水平。需要注意的是，在 Forward 階段，流水線要求資源得到充分填充，因此任務的劃分必須盡量均勻。

在此過程中，需要通過多 batch 的方式實現負載均衡，因為在推理過程中部分 batch 可能退出，同時新的 batch 會不斷進入。

例如，在 prefill 階段，可能很多的請求仍處于 decode 狀態，如果此時 prefill 與 decode 混合在同一批次中，再疊加更多的 decode 請求，就可能導致 decode 階段因 prefill 的操作而性能下降。

為此，必須在 batch 調度中引入多種負載均衡策略。這并不是一種全新的技術，而是流水線并行本應具備的特性。不同之處在于，我們首次在大規模語言模型推理這種有狀態服務中實現了這一點。完成優化后，系統吞吐量從 5K 提升至 9K。

關于如何進一步提升 MoE 的利用率，這里存在幾個關鍵問題。

首先，在 DP（Data Parallelism）中，最直接的方式是僅保留一份 KvCache，從而避免在多卡之間的冗余存儲。但這樣會帶來新的挑戰：權重需要集中放置在單卡上，而非分散在 2 張、4 張或 8 張卡上，從而顯著增加單卡的顯存壓力。如果再遇到一個 64K 的請求，必須保證任意一個 DP 都能處理該請求，這對中間計算過程中 buffer 的要求更為嚴格。

其次，當多個 DP 將資源切分得過細時，如果同時出現大規模請求，例如在 8 個 DP、8 張卡的情況下，每個 DP 都接收到一個 64K 的請求，那么 MoE 階段的壓力將放大為 64K × 8，導致中間緩存成為瓶頸。因此，需要在 DP 之間引入負載均衡機制，確保無論如何調度，都不會使 MoE 的 buffer 被過載。

為應對這些問題，一方面必須進行更精細化的顯存管理，以承載更高的權重與 buffer 開銷。這也是我們選擇直接從顯卡層面進行顯存分配，而不是依賴 PyTorch 等框架自動管理的原因。

另一方面，還需要在 DP 之間進行調度與均衡。結合前述的 MT-Batch 與流水線并行，我們還可以在不同 batch 之間進行調度，從而確保每個 batch 內部的 DP 負載更加均衡。

通過這些優化，目前系統吞吐量已提升至 14.6K。然而，如果仔細對比會發現問題：從單 DP 擴展到 8 DP，理論上吞吐應接近 8 倍，但實際僅提升不足一倍。這表明我們的優化仍不充分。

相較之下，TensorRT-LLM 在開啟 DP 前后幾乎實現一倍的提升，說明其 DP 算子的性能明顯優于我們。這也是后續我們需要重點借鑒的地方。

總結與展望

我們并非不做 EP 和 PD 分離，而是選擇先實現 PP。這一順序主要取決于硬件條件。從下圖中可以看到 Token 并行數與最終硬件性能的關系。藍色曲線代表 H800，橙色曲線代表 H20，二者之間存在約十倍的性能差距。

這意味著在不同 Token 數下，算子的性能上限存在顯著差異。H20 很快便會達到天花板并進入平穩期，再增加只會帶來時延。

EP 和 PD 分離的首要收益在于可支持更大的 batch size。而 PP 帶來更優的顯存利用率和更低的通信開銷。

因此，我們先實現了 PP，目前正推進 EP 與 PD 分離。在 batch size 已接近上限的情況下，下一步的重點是進一步釋放顯存并優化通信。

我們當前的工作也聚焦在幾個關鍵問題上：

一是調度策略與業務場景的兼容。如果業務峰值是 10 倍量級，現有策略更偏向“保吞吐”，那么后續調度需要在保證吞吐的同時，把 TPOT、TTFT 等體驗指標也做上去（既降低首 Token 時延、又提升持續輸出效率），這對調度提出了更高要求；

二是柔性 KV cache 匹配。目前我們的 prefix cache 采用嚴格匹配：例如一個會話約 50 輪，對到第 51 輪時會發生窗口回滾（從第 2 輪到第 51 輪重新送入模型）。此時大部分上下文相同，但由于嚴格匹配，KV cache 往往無法命中。因此我們在推進“柔性 KV cache”，力圖在上下文高度相似的情況下也能復用緩存，減少重復計算。

三是模型層間進度是否必須同步。從研究與實踐看，答案是否定的：不同層的計算負載與時序分布并不一致，沒必要強行保持層層同速。適度引入層間解耦 / 異步有望提升整體效率。

四是batch 之間的流程編排。雖然兩個 batch 在邏輯上相互獨立，但若把它們視為計算圖，并不必然沖突；因此沒必要做硬件強隔離。通過在不沖突的算子間交叉 / 穿插執行，可進一步提升資源利用率與吞吐。此外，我們也在推進多模態支持與國產 GPU適配等相關工作。

謝謝大家！

AI 重塑組織的浪潮已至，Agentic 企業時代正式開啟！當 AI 不再是單純的輔助工具，而是深度融入業務核心、驅動組織形態與運作邏輯全面革新的核心力量。

把握行業變革關鍵節點，12 月 19 日 - 20 日，AICon 全球人工智能開發與應用大會（北京站） 即將重磅啟幕！本屆大會精準錨定行業前沿，聚焦大模型訓練與推理、AI Agent、研發新范式與組織革新，邀您共同深入探討：如何構建起可信賴、可規模化、可商業化的 Agentic 操作系統，讓 AI 真正成為企業降本增效、突破增長天花板的核心引擎。