在之前的技術博客中,我們介紹了低延遲和高吞吐場景的優(yōu)化方法。對于生產(chǎn)部署,用戶還關心在滿足特定延遲約束的情況下,每個 GPU 的吞吐表現(xiàn)。本文將圍繞“吞吐量-延遲”性能場景,介紹 TensorRT-LLM 分離式服務的設計理念、使用方法,以及性能研究結果。
初衷
LLM 推理通常分為上下文 (prefill) 和生成 (decode) 兩個階段。在上下文階段,模型會根據(jù)提示詞計算鍵值 (KV) 緩存,而在生成階段,則利用這些緩存值逐步生成每一個 Token。這兩個階段在計算特性上存在顯著差異。
LLM 推理請求的服務方式有兩種:
聚合式 LLM 服務(在本文中有時也稱為 IFB):上下文和生成階段通常在同一個 GPU 上運行。
分離式 LLM 服務:上下文和生成階段通常在不同 GPU 上運行。
圖 1. 聚合式 LLM 服務執(zhí)行時間線
(該圖片來源于 NVIDIA 團隊論文:Beyond the Buzz:
A Pragmatic Take on Inference Disaggregation,若您有任何疑問或需要使用該圖片,請聯(lián)系該文作者)
在聚合式 LLM 服務中,上下文和生成階段共享相同的 GPU 資源和并行策略。這種資源耦合會干擾上下文階段的 Token 生成速度,并且增加 Token 間延遲 (TPOT),從而影響用戶交互體驗,正如圖 1:聚合式 LLM 服務的執(zhí)行時間線所示。聚合式 LLM 服務還強制兩個階段使用相同的 GPU 類型和并行配置,盡管它們的計算需求并不相同。在這種耦合約束下,優(yōu)化某一項指標(如首 Token 生成時間 TTFT)往往會以犧牲另一項指標 (如 TPOT) 為代價。
圖 2. 分離式 LLM 服務執(zhí)行時間線
(該圖片來源于 NVIDIA 團隊論文:Beyond the Buzz:
A Pragmatic Take on Inference Disaggregation,若您有任何疑問或需要使用該圖片,請聯(lián)系該文作者)
分離式服務通過解耦上下文階段與生成階段有效解決了上述問題。兩個階段可分別運行在不同的 GPU 池上,并采用各自優(yōu)化的并行策略,從而避免了資源干擾。如圖 2 所示,這種分離式的運行方式消除了上下文和生成階段之間性能沖突,使得 TTFT 和 TPOT 能夠分別進行針對性優(yōu)化。盡管在兩個階段之間傳輸 KV 緩存塊會帶來一定開銷,但在輸入序列較長、輸出長度適中的工作負載下,這種架構的優(yōu)勢依然十分顯著——尤其是在此類場景中,IFB 干擾最為嚴重。
關于更多分離式服務的原理和設計細節(jié),請參考這篇論文:
https://arxiv.org/pdf/2506.05508
使用 TensorRT-LLM 執(zhí)行分離服務
使用 TensorRT-LLM 進行 LLM 分離式推理共有三種不同方法,每種方法在架構設計和運行特性上各具優(yōu)勢,適用于不同的部署場景。
trtllm-serve
trtllm-serve是一個命令行工具,用于部署與 OpenAI 兼容的 TensorRT-LLM 服務。
使用 TensorRT-LLM 進行 LLM 分離式推理的第一種方法是通過trtllm-serve為每個上下文和生成實例分別啟動獨立的 OpenAI 服務。同時,trtllm-serve還會啟動一個稱為“分離服務器”的調(diào)度器,用于接收客戶端請求,并通過 OpenAI REST API 將請求分發(fā)至對應的上下文或生成服務器。圖 3 展示了該方法的工作流程。當上下文實例完成提示詞的 KV 緩存生成后,會將結果返回給分離式服務器,其中包含提示詞 Token、首個生成Token以及與上下文相關的元數(shù)據(jù)(稱為ctx_params)。這些參數(shù)隨后被生成實例用于與上下文實例建立連接,并檢索與請求相關的 KV 緩存塊。
圖 3. 使用 trtllm-serve 進行分離式服務
在以下示例中,上下文階段的服務分別運行在端口 8001 和 8002 上,生成階段的服務則分別在端口 8003 和 8004 上。分離式服務器監(jiān)聽端口 8000,用于接收客戶端請求,并在上下文與生成階段之間進行調(diào)度。
# 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 緩存的路由。此外,該架構已支持動態(tài)擴縮容,能夠靈活應對不同規(guī)模的推理負載。
了解更多信息,請參見示例:
https://github.com/NVIDIA/TensorRT-LLM/tree/main/examples/disaggregated#trt-llm-disaggregated-serving
Dynamo
第二種方法是使用Dynamo—— 一個專為 LLM 工作負載設計的數(shù)據(jù)中心級推理服務器。Dynamo 提供了許多高級功能,包括預處理與后處理線程的解耦,特別適用于高并發(fā)場景。其工作流程如圖 4 所示。
圖 4. 使用 Dynamo 進行分離服務
在 Dynamo 的工作流程中,首先由預處理和后處理工作線程處理請求,隨后它們會查詢智能路由器,以確定將請求路由到哪個最優(yōu)的生成器。根據(jù) KV 緩存塊的可用性,生成器可能跳過上下文階段,或?qū)⒄埱筠D發(fā)至上下文工作線程。一旦上下文階段完成提示詞的處理,KV 緩存塊即可通過上圖所示的 ctx_params 元數(shù)據(jù)發(fā)送至生成階段,用于后續(xù)的 Token 生成。
Dynamo 還內(nèi)置了對 Kubernetes 部署、監(jiān)測和指標采集的支持。我們正在積極推進動態(tài)實例擴展,進一步提高其在生產(chǎn)環(huán)境中的適用性與彈性。
更多有關如何將 Dynamo 與 TensorRT-LLM 集成的信息,請參見此文檔:
https://docs.nvidia.com/dynamo/latest/examples/trtllm.html
Triton 推理服務
第三種方法是使用 Triton 推理服務器,通過 Triton 的 ensemble 模型實現(xiàn)分離式推理。該模型由預處理器、調(diào)度器(基于 Python BLS 后端)和后處理器組成。如圖 5 所示,調(diào)度器負責將客戶端請求路由至上下文和生成實例,管理提示 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 緩存?zhèn)鬏?/strong>
多后端支持
如圖 6 所示,在 TensorRT-LLM 中,KV 緩存交換模塊、KV 緩存管理器及底層通信庫采用模塊化解耦設計。KV 緩存交換模塊負責高效傳輸緩存、及時釋放緩存空間,并在交換過程中按需轉換緩存布局。目前,TensorRT-LLM 支持主流通信協(xié)議,包括 MPI、UCX 和 NIXL,其底層通信協(xié)議采用 RDMA / NVLink。我們推薦使用 UCX 和 NIXL 后端,因為它們支持動態(tài)擴縮容功能,使用戶能夠根據(jù)流量需求調(diào)整負載,或在上下文和生成角色之間進行動態(tài)切換。
圖 6. KV 緩存交換架構
并行優(yōu)化
為了提高分離式服務的整體性能,TensorRT-LLM 將 KV 緩存?zhèn)鬏斉c請求計算過程重疊。如圖 7 所示,當一個請求正在發(fā)送或接收其 KV 緩存塊時,其他請求可以繼續(xù)進行計算。此外,如果上下文或生成階段使用了多個 GPU,不同 GPU 之間的 KV 緩存?zhèn)鬏斠部梢圆⑿羞M行。
圖 7. KV 緩存交換時序圖
緩存布局轉換
為了最大限度地降低 KV 緩存?zhèn)鬏斞舆t,TensorRT-LLM 采用在設備顯存間直接傳輸緩存的方式。KV 緩存?zhèn)鬏斨С衷谏舷挛暮蜕呻A段采用不同的并行策略,此時需謹慎地映射兩個階段間的對 KV 緩存塊布局。圖 8 通過一個示例進行了說明:上下文階段采用 TP2 并行策略,而生成階段采用 PP2 并行策略。在這種異構并行配置下,緩存塊的正確布局映射至關重要。
圖 8. KV 緩存布局轉換
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 分離服務的性能曲線,需全面覆蓋并行化策略的組合,比如 TP(張量并行)、EP(專家并行)、DP(數(shù)據(jù)并行)、PP(流水線并行),以及其他優(yōu)化方法,如投機采樣(例如 MTP)。這些組合必須分別在上下文階段和生成階段進行評估。隨著上下文 (CTX) 和生成 (GEN) 服務器數(shù)量的增加,可能的配置數(shù)量呈指數(shù)級增長,評估復雜度也隨之提升。
為了確定最佳配置,我們將測量過程分為兩步:
速率匹配
測量上下文服務器的請求吞吐量(以請求數(shù) / 秒 / GPU 為單位),針對滿足 TTFT 約束的不同 TP / EP / DP / PP 映射,選擇最優(yōu)配置。
針對不同的 TP / EP / DP / PP 映射、并發(fā)級別,以及投機采樣開關的情況,測量生成服務器的總吞吐量(以Token/ 秒為單位)和延遲(以Token/ 秒 /用戶為單位)。
確定上下文服務器與生成服務器的比例,使得在給定工作負載的輸入序列長度 (ISL) 和輸出序列長度 (OSL) 下,上下文服務器的總吞吐量與生成服務器的總吞吐量相匹配。
使用以下公式計算每個 GPU 的吞吐量:
一旦計算出上下文與生成服務器的最佳比例,即可構建“速率匹配”帕累托曲線 (Pareto curve),以便在不同延遲(Token / 秒 / 用戶)下識別最佳配置。
端到端性能測量
在考慮可用 GPU 總數(shù)量的實際限制的前提下,對最具優(yōu)勢的配置進行trtllm-serve分離式部署的基準測試。
DeepSeek R1
我們在 ISL 和 OSL 不同的數(shù)據(jù)集上對 DeepSeek R1 進行了性能測試。以下所有實驗均在 NVIDIA GPU 上進行。
ISL 4400 - OSL 1200(機器翻譯數(shù)據(jù)集)
圖 9. 關閉 MTP 時的 DeepSeek R1“速率匹配”帕累托曲線
圖 9 是 DeepSeek R1 在關閉 MTP 時的速率匹配帕累托曲線。該曲線考慮了 ADP 和 ATP 配置,每個實例使用 4、8、16 或 32 個 GPU。分離式實現(xiàn)的加速比為1.4 至 1.8 倍,尤其在低并發(fā)水平下效果更為顯著。
圖 10. 啟用 MTP 時的 DeepSeek R1 帕累托曲線
我們在性能曲線中選取一些數(shù)據(jù)點標注了上下文 / 生成實例的數(shù)量和并行策略。例如,CTX=1xTEP-4|GEN=2xDEP-8表示由 1 個 TEP4 上下文實例和 2 個 DEP8 生成實例組成一個完整的 LLM 處理實例。
如圖 10 所示,啟用 MTP 后,分離式服務相較于聚合式服務的加速比進一步提升,平均比關閉 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 服務實例。
圖 12. DeepSeek R1 8-GPU 帕累托曲線
圖 11 和圖 12 分別是在每個生成實例使用 4 個 GPU (GEN4) 和 8 個GPU (GEN8) 的情況下,在 DeepSeek R1 上運行 ISL8192-OSL256 數(shù)據(jù)集的性能曲線。我們同時繪制了分離式服務的“速率匹配”結果(基于上下文與生成階段之間的理想速率匹配)和端到端結果(用戶可在生產(chǎn)部署環(huán)境中直接復現(xiàn)該結果)。
結果顯示,在此 ISL / OSL 設置下,分離服務的性能明顯優(yōu)于合并服務——在 GEN4 配置下加速比最高可達1.73 倍,GEN8 配置下最高可達2 倍。
通過將分離式服務的端到端結果與“速率匹配”曲線進行比較,我們觀察到性能差距在 0%–25% 之間。這種差異是符合預期的,因為 SOL 性能依賴于理想化假設,例如 ctx:gen 比例極小、KV 緩存?zhèn)鬏敳划a(chǎn)生開銷等。
ISL 4096 - OSL 1024(機器翻譯數(shù)據(jù)集)
圖 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 倍。隨著并發(fā)度的提高,啟用 MTP 能夠帶來更大的性能收益。
Qwen 3
ISL 8192 - OSL 1024(機器翻譯數(shù)據(jù)集)
圖 15. Qwen 3 帕累托曲線
我們還對 Qwen 3 進行了性能評估。數(shù)據(jù)顯示,分離服務實現(xiàn)的加速比在 1.7 至 6.11 倍之間。
性能復現(xiàn)
我們提供了一組腳本用于復現(xiàn)本論文中展示的性能數(shù)據(jù)。請參見此文檔中的使用說明:
https://github.com/NVIDIA/TensorRT-LLM/tree/main/examples/disaggregated/slurm
工作展望
我們已經(jīng)通過使用 TensorRT-LLM 進行 LLM 分離式推理獲得了性能優(yōu)勢,我們還將會進一步提高性能和易用性,所需的工作包括:
提供詳細的步驟和腳本,以自動化生成用于比較聚合式與分離服務的吞吐量-延遲性能曲線。
繼續(xù)提升大規(guī)模部署場景下的性能(如大規(guī)模 EP)。
支持根據(jù)流量負載動態(tài)調(diào)整上下文和生成實例。
支持按層計算傳輸KV 緩存。
致謝
在 TensorRT-LLM 中增加分離式服務支持是一個典型的跨團隊協(xié)作項目,需要在內(nèi)核級優(yōu)化、運行時增強以及系統(tǒng)化性能分析與調(diào)優(yōu)等方面緊密配合。我們?yōu)檫@支敬業(yè)樂群的工程師團隊感到驕傲,正是他們深厚的專業(yè)知識大幅提升了 TensorRT-LLM 的整體性能。除本文作者外,我們誠摯感謝 Iman Tabrizian、張順康、段政和網(wǎng)絡團隊等同事為項目所作的代碼貢獻。通過此次協(xié)作,團隊在進一步提升大語言模型推理的 GPU 利用率方面積累了寶貴經(jīng)驗。我們希望本文能夠為開發(fā)者社區(qū)提供有益參考,助力大家在關鍵 LLM 推理應用中更充分地釋放 NVIDIA GPU 的潛力。
關于作者
Patrice Castonguay
NVIDIA TensorRT-LLM 的首席軟件工程師,擁有計算流體力學 (CFD) 背景。他長期領導開發(fā)面向稀疏線性代數(shù)、語音識別、語音合成及大型語言模型的 GPU 加速庫。并擁有斯坦福大學航空航天學博士學位。
陳曉明
NVIDIATensorRT-LLM 性能團隊的首席架構師和高級經(jīng)理,對深度學習模型的算法軟硬件協(xié)同設計感興趣,最近在做大語言模型推理的性能建模、分析和優(yōu)化。
石曉偉
NVIDIA 軟件工程師,目前主要參與 TensorRT-LLM 框架開發(fā)及性能優(yōu)化。
朱闖
NVIDIA 軟件工程師,目前主要從事 TensorRT-LLM 大語言模型的推理優(yōu)化。
喬顯杰
NVIDIA Compute Arch 部門高級架構師, 主要負責 LLM 推理的性能評估和優(yōu)化。加入 NVIDIA 之前,他曾從事推薦系統(tǒng)的 GPU 加速研發(fā)工作。
Jatin Gangani
NVIDIA 深度學習計算團隊的高級計算架構師,專注于提升數(shù)據(jù)中心中 AI 推理的軟硬件性能。他近期的工作重點是優(yōu)化 TensorRT-LLM 軟件的性能表現(xiàn)。擁有北卡羅來納州立大學計算機工程碩士學位。
-
NVIDIA
+關注
關注
14文章
5430瀏覽量
108206 -
gpu
+關注
關注
28文章
5035瀏覽量
133682 -
模型
+關注
關注
1文章
3609瀏覽量
51410 -
LLM
+關注
關注
1文章
337瀏覽量
1130
原文標題:TensorRT-LLM 中的分離式服務
文章出處:【微信號:NVIDIA-Enterprise,微信公眾號:NVIDIA英偉達企業(yè)解決方案】歡迎添加關注!文章轉載請注明出處。
發(fā)布評論請先 登錄
DeepSeek R1 MTP在TensorRT-LLM中的實現(xiàn)與優(yōu)化

使用NVIDIA Triton和TensorRT-LLM部署TTS應用的最佳實踐

如何在魔搭社區(qū)使用TensorRT-LLM加速優(yōu)化Qwen3系列模型推理部署
分離式液位傳感器代替浮球傳感器的優(yōu)勢
分離式熱管換熱器的綜合利用
可直接訪問的分離式內(nèi)存DirectCXL應用案例

現(xiàn)已公開發(fā)布!歡迎使用 NVIDIA TensorRT-LLM 優(yōu)化大語言模型推理

魔搭社區(qū)借助NVIDIA TensorRT-LLM提升LLM推理效率
TensorRT-LLM低精度推理優(yōu)化

NVIDIA TensorRT-LLM Roadmap現(xiàn)已在GitHub上公開發(fā)布

解鎖NVIDIA TensorRT-LLM的卓越性能
在NVIDIA TensorRT-LLM中啟用ReDrafter的一些變化

TensorRT-LLM的大規(guī)模專家并行架構設計

評論