在之前的技術博客中，我們介紹了低延遲和高吞吐場景的優化方法。對于生產部署，用戶還關心在滿足特定延遲約束的情況下，每個 GPU 的吞吐表現。本文將圍繞“吞吐量-延遲”性能場景，介紹 TensorRT-LLM 分離式服務的設計理念、使用方法，以及性能研究結果。

初衷

LLM 推理通常分為上下文 (prefill) 和生成 (decode) 兩個階段。在上下文階段，模型會根據提示詞計算鍵值 (KV) 緩存，而在生成階段，則利用這些緩存值逐步生成每一個 Token。這兩個階段在計算特性上存在顯著差異。

LLM 推理請求的服務方式有兩種：

聚合式 LLM 服務（在本文中有時也稱為 IFB）：上下文和生成階段通常在同一個 GPU 上運行。

分離式 LLM 服務：上下文和生成階段通常在不同 GPU 上運行。

圖 1. 聚合式 LLM 服務執行時間線

（該圖片來源于 NVIDIA 團隊論文：Beyond the Buzz:

A Pragmatic Take on Inference Disaggregation，若您有任何疑問或需要使用該圖片，請聯系該文作者）

在聚合式 LLM 服務中，上下文和生成階段共享相同的 GPU 資源和并行策略。這種資源耦合會干擾上下文階段的 Token 生成速度，并且增加 Token 間延遲 (TPOT)，從而影響用戶交互體驗，正如圖 1：聚合式 LLM 服務的執行時間線所示。聚合式 LLM 服務還強制兩個階段使用相同的 GPU 類型和并行配置，盡管它們的計算需求并不相同。在這種耦合約束下，優化某一項指標（如首 Token 生成時間 TTFT）往往會以犧牲另一項指標 (如 TPOT) 為代價。

圖 2. 分離式 LLM 服務執行時間線

（該圖片來源于 NVIDIA 團隊論文：Beyond the Buzz:

A Pragmatic Take on Inference Disaggregation，若您有任何疑問或需要使用該圖片，請聯系該文作者）

分離式服務通過解耦上下文階段與生成階段有效解決了上述問題。兩個階段可分別運行在不同的 GPU 池上，并采用各自優化的并行策略，從而避免了資源干擾。如圖 2 所示，這種分離式的運行方式消除了上下文和生成階段之間性能沖突，使得 TTFT 和 TPOT 能夠分別進行針對性優化。盡管在兩個階段之間傳輸 KV 緩存塊會帶來一定開銷，但在輸入序列較長、輸出長度適中的工作負載下，這種架構的優勢依然十分顯著——尤其是在此類場景中，IFB 干擾最為嚴重。

關于更多分離式服務的原理和設計細節，請參考這篇論文：

https://arxiv.org/pdf/2506.05508

使用 TensorRT-LLM 執行分離服務

使用 TensorRT-LLM 進行 LLM 分離式推理共有三種不同方法，每種方法在架構設計和運行特性上各具優勢，適用于不同的部署場景。

trtllm-serve

trtllm-serve是一個命令行工具，用于部署與 OpenAI 兼容的 TensorRT-LLM 服務。

使用 TensorRT-LLM 進行 LLM 分離式推理的第一種方法是通過trtllm-serve為每個上下文和生成實例分別啟動獨立的 OpenAI 服務。同時，trtllm-serve還會啟動一個稱為“分離服務器”的調度器，用于接收客戶端請求，并通過 OpenAI REST API 將請求分發至對應的上下文或生成服務器。圖 3 展示了該方法的工作流程。當上下文實例完成提示詞的 KV 緩存生成后，會將結果返回給分離式服務器，其中包含提示詞 Token、首個生成Token以及與上下文相關的元數據（稱為ctx_params）。這些參數隨后被生成實例用于與上下文實例建立連接，并檢索與請求相關的 KV 緩存塊。

圖 3. 使用 trtllm-serve 進行分離式服務

在以下示例中，上下文階段的服務分別運行在端口 8001 和 8002 上，生成階段的服務則分別在端口 8003 和 8004 上。分離式服務器監聽端口 8000，用于接收客戶端請求，并在上下文與生成階段之間進行調度。

# Launching context servers
trtllm-serve TinyLlama/TinyLlama-1.1B-Chat-v1.0--host localhost --port8001--kv_cache_free_gpu_memory_fraction0.15&> output_ctx0 &
trtllm-serve TinyLlama/TinyLlama-1.1B-Chat-v1.0--host localhost --port8002--kv_cache_free_gpu_memory_fraction0.15&> output_ctx1 &


# Launching generation servers
trtllm-serve TinyLlama/TinyLlama-1.1B-Chat-v1.0--host localhost --port8003--kv_cache_free_gpu_memory_fraction0.15&> output_gen0 &
trtllm-serve TinyLlama/TinyLlama-1.1B-Chat-v1.0--host localhost --port8004--kv_cache_free_gpu_memory_fraction0.15&> output_gen1 &


# Launching disaggregated server
trtllm-serve disaggregated -c disagg_config.yaml

# disagg_config.yaml
hostname: localhost
port: 8000
context_servers:
 num_instances: 2
 router:
  type: round_robin
 urls:
  -"localhost:8001"
  -"localhost:8002"
generation_servers:
 num_instances: 2
 urls:
  -"localhost:8003"
  -"localhost:8004"

分離式服務支持多種負載均衡策略，包括輪詢 (round-robin) 及基于 KV 緩存的路由。此外，該架構已支持動態擴縮容，能夠靈活應對不同規模的推理負載。

了解更多信息，請參見示例：

https://github.com/NVIDIA/TensorRT-LLM/tree/main/examples/disaggregated#trt-llm-disaggregated-serving

Dynamo

第二種方法是使用Dynamo—— 一個專為 LLM 工作負載設計的數據中心級推理服務器。Dynamo 提供了許多高級功能，包括預處理與后處理線程的解耦，特別適用于高并發場景。其工作流程如圖 4 所示。

圖 4. 使用 Dynamo 進行分離服務

在 Dynamo 的工作流程中，首先由預處理和后處理工作線程處理請求，隨后它們會查詢智能路由器，以確定將請求路由到哪個最優的生成器。根據 KV 緩存塊的可用性，生成器可能跳過上下文階段，或將請求轉發至上下文工作線程。一旦上下文階段完成提示詞的處理，KV 緩存塊即可通過上圖所示的 ctx_params 元數據發送至生成階段，用于后續的 Token 生成。

Dynamo 還內置了對 Kubernetes 部署、監測和指標采集的支持。我們正在積極推進動態實例擴展，進一步提高其在生產環境中的適用性與彈性。

更多有關如何將 Dynamo 與 TensorRT-LLM 集成的信息，請參見此文檔：

https://docs.nvidia.com/dynamo/latest/examples/trtllm.html

Triton 推理服務

第三種方法是使用 Triton 推理服務器，通過 Triton 的 ensemble 模型實現分離式推理。該模型由預處理器、調度器（基于 Python BLS 后端）和后處理器組成。如圖 5 所示，調度器負責將客戶端請求路由至上下文和生成實例，管理提示 Token 的流轉，并處理生成 Token 的返回結果。該方法依賴于 Triton 的 TensorRT-LLM 后端及其 Executor API，目前僅支持 TensorRT 后端。如需了解更多信息，請參閱此文檔：

https://github.com/NVIDIA/TensorRT-LLM/tree/main/triton_backend/all_models/disaggregated_serving#running-disaggregated-serving-with-triton-tensorrt-llm-backend

圖 5. 使用 Triton 進行分離服務

KV 緩存傳輸

多后端支持

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

圖 6. KV 緩存交換架構

并行優化

為了提高分離式服務的整體性能，TensorRT-LLM 將 KV 緩存傳輸與請求計算過程重疊。如圖 7 所示，當一個請求正在發送或接收其 KV 緩存塊時，其他請求可以繼續進行計算。此外，如果上下文或生成階段使用了多個 GPU，不同 GPU 之間的 KV 緩存傳輸也可以并行進行。

圖 7. KV 緩存交換時序圖

緩存布局轉換

為了最大限度地降低 KV 緩存傳輸延遲，TensorRT-LLM 采用在設備顯存間直接傳輸緩存的方式。KV 緩存傳輸支持在上下文和生成階段采用不同的并行策略，此時需謹慎地映射兩個階段間的對 KV 緩存塊布局。圖 8 通過一個示例進行了說明：上下文階段采用 TP2 并行策略，而生成階段采用 PP2 并行策略。在這種異構并行配置下，緩存塊的正確布局映射至關重要。

圖 8. KV 緩存布局轉換

KV 緩存傳輸所需的優化策略會因具體部署環境而異，例如單節點多 GPU、多節點多 GPU 或 不同 GPU 種類。為此，TensorRT-LLM 提供了一組環境變量，供用戶根據實際運行環境靈活選擇和配置，以實現最佳性能。詳情請參見此文檔：

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

性能分析

測量方案

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

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

速率匹配

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

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

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

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

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

端到端性能測量

在考慮可用 GPU 總數量的實際限制的前提下，對最具優勢的配置進行trtllm-serve分離式部署的基準測試。

DeepSeek R1

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

ISL 4400 - OSL 1200（機器翻譯數據集）

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

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

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

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

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

ISL 8192 - OSL 256（合成數據集）

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

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

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

結果顯示，在此 ISL / OSL 設置下，分離服務的性能明顯優于合并服務——在 GEN4 配置下加速比最高可達1.73 倍，GEN8 配置下最高可達2 倍。

通過將分離式服務的端到端結果與“速率匹配”曲線進行比較，我們觀察到性能差距在 0%–25% 之間。這種差異是符合預期的，因為 SOL 性能依賴于理想化假設，例如 ctx:gen 比例極小、KV 緩存傳輸不產生開銷等。

ISL 4096 - OSL 1024（機器翻譯數據集）

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

圖 14. 關閉 MTP 時的 DeepSeek R1 端到端帕累托曲線

圖 13 和 14 分別為合并服務和分離服務在開關 MTP 時的端到端帕累托曲線。

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

Qwen 3

ISL 8192 - OSL 1024（機器翻譯數據集）

圖 15. Qwen 3 帕累托曲線

我們還對 Qwen 3 進行了性能評估。數據顯示，分離服務實現的加速比在 1.7 至 6.11 倍之間。

性能復現

我們提供了一組腳本用于復現本論文中展示的性能數據。請參見此文檔中的使用說明：

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

工作展望

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

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

繼續提升大規模部署場景下的性能（如大規模 EP）。

支持根據流量負載動態調整上下文和生成實例。

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

致謝

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

關于作者

Patrice Castonguay

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

陳曉明

NVIDIATensorRT-LLM 性能團隊的首席架構師和高級經理，對深度學習模型的算法軟硬件協同設計感興趣，最近在做大語言模型推理的性能建模、分析和優化。

石曉偉

NVIDIA 軟件工程師，目前主要參與 TensorRT-LLM 框架開發及性能優化。

朱闖

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

喬顯杰

NVIDIA Compute Arch 部門高級架構師, 主要負責 LLM 推理的性能評估和優化。加入 NVIDIA 之前，他曾從事推薦系統的 GPU 加速研發工作。

Jatin Gangani

NVIDIA 深度學習計算團隊的高級計算架構師，專注于提升數據中心中 AI 推理的軟硬件性能。他近期的工作重點是優化 TensorRT-LLM 軟件的性能表現。擁有北卡羅來納州立大學計算機工程碩士學位。