多后端支持

如圖 6 所示，在 TensorRT-LLM 中，KV 緩存交換模塊、KV 緩存管理器及底層通信庫采用模塊化解耦設(shè)計。KV 緩存交換模塊負(fù)責(zé)高效傳輸緩存、及時釋放緩存空間，并在交換過程中按需轉(zhuǎn)換緩存布局。目前，TensorRT-LLM 支持主流通信協(xié)議，包括 MPI、UCX 和 NIXL，其底層通信協(xié)議采用 RDMA / NVLink。我們推薦使用 UCX 和 NIXL 后端，因為它們支持動態(tài)擴(kuò)縮容功能，使用戶能夠根據(jù)流量需求調(diào)整負(fù)載，或在上下文和生成角色之間進(jìn)行動態(tài)切換。

圖 6. KV 緩存交換架構(gòu)

并行優(yōu)化

為了提高分離式服務(wù)的整體性能，TensorRT-LLM 將 KV 緩存?zhèn)鬏斉c請求計算過程重疊。如圖 7 所示，當(dāng)一個請求正在發(fā)送或接收其 KV 緩存塊時，其他請求可以繼續(xù)進(jìn)行計算。此外，如果上下文或生成階段使用了多個 GPU，不同 GPU 之間的 KV 緩存?zhèn)鬏斠部梢圆⑿羞M(jìn)行。

圖 7. KV 緩存交換時序圖

緩存布局轉(zhuǎn)換

為了最大限度地降低 KV 緩存?zhèn)鬏斞舆t，TensorRT-LLM 采用在設(shè)備顯存間直接傳輸緩存的方式。KV 緩存?zhèn)鬏斨С衷谏舷挛暮蜕呻A段采用不同的并行策略，此時需謹(jǐn)慎地映射兩個階段間的對 KV 緩存塊布局。圖 8 通過一個示例進(jìn)行了說明：上下文階段采用 TP2 并行策略，而生成階段采用 PP2 并行策略。在這種異構(gòu)并行配置下，緩存塊的正確布局映射至關(guān)重要。

圖 8. KV 緩存布局轉(zhuǎn)換

KV 緩存?zhèn)鬏斔璧膬?yōu)化策略會因具體部署環(huán)境而異，例如單節(jié)點多 GPU、多節(jié)點多 GPU 或 不同 GPU 種類。為此，TensorRT-LLM 提供了一組環(huán)境變量，供用戶根據(jù)實際運行環(huán)境靈活選擇和配置，以實現(xiàn)最佳性能。詳情請參見此文檔：

https://github.com/NVIDIA/TensorRT-LLM/blob/main/docs/source/advanced/disaggregated-service.md

性能分析

測量方案

如果要生成 LLM 分離服務(wù)的性能曲線，需全面覆蓋并行化策略的組合，比如 TP（張量并行）、EP（專家并行）、DP（數(shù)據(jù)并行）、PP（流水線并行），以及其他優(yōu)化方法，如投機(jī)采樣（例如 MTP）。這些組合必須分別在上下文階段和生成階段進(jìn)行評估。隨著上下文 (CTX) 和生成 (GEN) 服務(wù)器數(shù)量的增加，可能的配置數(shù)量呈指數(shù)級增長，評估復(fù)雜度也隨之提升。

為了確定最佳配置，我們將測量過程分為兩步：

速率匹配

測量上下文服務(wù)器的請求吞吐量（以請求數(shù) / 秒 / GPU 為單位），針對滿足 TTFT 約束的不同 TP / EP / DP / PP 映射，選擇最優(yōu)配置。

針對不同的 TP / EP / DP / PP 映射、并發(fā)級別，以及投機(jī)采樣開關(guān)的情況，測量生成服務(wù)器的總吞吐量（以Token/ 秒為單位）和延遲（以Token/ 秒 /用戶為單位）。

確定上下文服務(wù)器與生成服務(wù)器的比例，使得在給定工作負(fù)載的輸入序列長度 (ISL) 和輸出序列長度 (OSL) 下，上下文服務(wù)器的總吞吐量與生成服務(wù)器的總吞吐量相匹配。

使用以下公式計算每個 GPU 的吞吐量：

一旦計算出上下文與生成服務(wù)器的最佳比例，即可構(gòu)建“速率匹配”帕累托曲線 (Pareto curve)，以便在不同延遲（Token / 秒 / 用戶）下識別最佳配置。

端到端性能測量

在考慮可用 GPU 總數(shù)量的實際限制的前提下，對最具優(yōu)勢的配置進(jìn)行trtllm-serve分離式部署的基準(zhǔn)測試。

DeepSeek R1

我們在 ISL 和 OSL 不同的數(shù)據(jù)集上對 DeepSeek R1 進(jìn)行了性能測試。以下所有實驗均在 NVIDIA GPU 上進(jìn)行。

ISL 4400 - OSL 1200（機(jī)器翻譯數(shù)據(jù)集）

圖 9. 關(guān)閉 MTP 時的 DeepSeek R1“速率匹配”帕累托曲線

圖 9 是 DeepSeek R1 在關(guān)閉 MTP 時的速率匹配帕累托曲線。該曲線考慮了 ADP 和 ATP 配置，每個實例使用 4、8、16 或 32 個 GPU。分離式實現(xiàn)的加速比為1.4 至 1.8 倍，尤其在低并發(fā)水平下效果更為顯著。

圖 10. 啟用 MTP 時的 DeepSeek R1 帕累托曲線

我們在性能曲線中選取一些數(shù)據(jù)點標(biāo)注了上下文 / 生成實例的數(shù)量和并行策略。例如，CTX=1xTEP-4|GEN=2xDEP-8表示由 1 個 TEP4 上下文實例和 2 個 DEP8 生成實例組成一個完整的 LLM 處理實例。

如圖 10 所示，啟用 MTP 后，分離式服務(wù)相較于聚合式服務(wù)的加速比進(jìn)一步提升，平均比關(guān)閉 MTP 時高出 20% 至 30%。

ISL 8192 - OSL 256（合成數(shù)據(jù)集）

圖 11. DeepSeek R1 4-GPU 帕累托曲線。ctx/gen=4.5 表示上下文與生成階段的 SOL 速率匹配，該配置僅用于 SOL 性能收集。c4dep4_g1dep4 表示 4 個 DEP4 上下文實例加上 1 個 DEP4 生成實例組成一個完整的 LLM 服務(wù)實例。

圖 12. DeepSeek R1 8-GPU 帕累托曲線

圖 11 和圖 12 分別是在每個生成實例使用 4 個 GPU (GEN4) 和 8 個GPU (GEN8) 的情況下，在 DeepSeek R1 上運行 ISL8192-OSL256 數(shù)據(jù)集的性能曲線。我們同時繪制了分離式服務(wù)的“速率匹配”結(jié)果（基于上下文與生成階段之間的理想速率匹配）和端到端結(jié)果（用戶可在生產(chǎn)部署環(huán)境中直接復(fù)現(xiàn)該結(jié)果）。

結(jié)果顯示，在此 ISL / OSL 設(shè)置下，分離服務(wù)的性能明顯優(yōu)于合并服務(wù)——在 GEN4 配置下加速比最高可達(dá)1.73 倍，GEN8 配置下最高可達(dá)2 倍。

通過將分離式服務(wù)的端到端結(jié)果與“速率匹配”曲線進(jìn)行比較，我們觀察到性能差距在 0%–25% 之間。這種差異是符合預(yù)期的，因為 SOL 性能依賴于理想化假設(shè)，例如 ctx:gen 比例極小、KV 緩存?zhèn)鬏敳划a(chǎn)生開銷等。

ISL 4096 - OSL 1024（機(jī)器翻譯數(shù)據(jù)集）

圖 13. DeepSeek R1 端到端帕累托曲線，MTP = 1、2、3。在此圖中，ctx1dep4-gen2dep4-mtp3 表示 1 個 DEP4 上下文實例加 2 個 DEP4 生成實例，且 MTP = 3。

圖 14. 關(guān)閉 MTP 時的 DeepSeek R1 端到端帕累托曲線

圖 13 和 14 分別為合并服務(wù)和分離服務(wù)在開關(guān) MTP 時的端到端帕累托曲線。

在 MTP = 1、2、3 的帕累托曲線上，可以觀察到，在 50 Token / 秒 / 用戶（20 毫秒延遲）時，分離服務(wù)的性能提升達(dá)1.7 倍。隨著并發(fā)度的提高，啟用 MTP 能夠帶來更大的性能收益。

Qwen 3

ISL 8192 - OSL 1024（機(jī)器翻譯數(shù)據(jù)集）

圖 15. Qwen 3 帕累托曲線

我們還對 Qwen 3 進(jìn)行了性能評估。數(shù)據(jù)顯示，分離服務(wù)實現(xiàn)的加速比在 1.7 至 6.11 倍之間。

性能復(fù)現(xiàn)

我們提供了一組腳本用于復(fù)現(xiàn)本論文中展示的性能數(shù)據(jù)。請參見此文檔中的使用說明：

https://github.com/NVIDIA/TensorRT-LLM/tree/main/examples/disaggregated/slurm

工作展望

我們已經(jīng)通過使用 TensorRT-LLM 進(jìn)行 LLM 分離式推理獲得了性能優(yōu)勢，我們還將會進(jìn)一步提高性能和易用性，所需的工作包括：

提供詳細(xì)的步驟和腳本，以自動化生成用于比較聚合式與分離服務(wù)的吞吐量-延遲性能曲線。

繼續(xù)提升大規(guī)模部署場景下的性能（如大規(guī)模 EP）。

支持根據(jù)流量負(fù)載動態(tài)調(diào)整上下文和生成實例。

支持按層計算傳輸KV 緩存。

致謝

在 TensorRT-LLM 中增加分離式服務(wù)支持是一個典型的跨團(tuán)隊協(xié)作項目，需要在內(nèi)核級優(yōu)化、運行時增強(qiáng)以及系統(tǒng)化性能分析與調(diào)優(yōu)等方面緊密配合。我們?yōu)檫@支敬業(yè)樂群的工程師團(tuán)隊感到驕傲，正是他們深厚的專業(yè)知識大幅提升了 TensorRT-LLM 的整體性能。除本文作者外，我們誠摯感謝 Iman Tabrizian、張順康、段政和網(wǎng)絡(luò)團(tuán)隊等同事為項目所作的代碼貢獻(xiàn)。通過此次協(xié)作，團(tuán)隊在進(jìn)一步提升大語言模型推理的 GPU 利用率方面積累了寶貴經(jīng)驗。我們希望本文能夠為開發(fā)者社區(qū)提供有益參考，助力大家在關(guān)鍵 LLM 推理應(yīng)用中更充分地釋放 NVIDIA GPU 的潛力。

關(guān)于作者

Patrice Castonguay

NVIDIA TensorRT-LLM 的首席軟件工程師，擁有計算流體力學(xué) (CFD) 背景。他長期領(lǐng)導(dǎo)開發(fā)面向稀疏線性代數(shù)、語音識別、語音合成及大型語言模型的 GPU 加速庫。并擁有斯坦福大學(xué)航空航天學(xué)博士學(xué)位。

陳曉明

NVIDIATensorRT-LLM 性能團(tuán)隊的首席架構(gòu)師和高級經(jīng)理，對深度學(xué)習(xí)模型的算法軟硬件協(xié)同設(shè)計感興趣，最近在做大語言模型推理的性能建模、分析和優(yōu)化。

石曉偉

NVIDIA 軟件工程師，目前主要參與 TensorRT-LLM 框架開發(fā)及性能優(yōu)化。

朱闖

NVIDIA 軟件工程師，目前主要從事 TensorRT-LLM 大語言模型的推理優(yōu)化。

喬顯杰

NVIDIA Compute Arch 部門高級架構(gòu)師, 主要負(fù)責(zé) LLM 推理的性能評估和優(yōu)化。加入 NVIDIA 之前，他曾從事推薦系統(tǒng)的 GPU 加速研發(fā)工作。

Jatin Gangani

NVIDIA 深度學(xué)習(xí)計算團(tuán)隊的高級計算架構(gòu)師，專注于提升數(shù)據(jù)中心中 AI 推理的軟硬件性能。他近期的工作重點是優(yōu)化 TensorRT-LLM 軟件的性能表現(xiàn)。擁有北卡羅來納州立大學(xué)計算機(jī)工程碩士學(xué)位。