近期，OpenAI 的 gpt-oss、月之暗面的 Kimi K2 等多個新的前沿開源模型相繼問世，標(biāo)志著大語言模型 (LLM) 創(chuàng)新浪潮的加速。近日發(fā)布的 Dynamo 0.4 提供了一系列新功能，旨在規(guī)?；?、低成本地部署此類模型，其核心功能包括性能優(yōu)化、可觀察性和基于服務(wù)等級目標(biāo) (SLO) 的自動擴(kuò)展。

Dynamo 0.4 的主要亮點(diǎn)包括：

在 NVIDIA Blackwell 上通過 PD 分離將性能提升 4 倍

提供針對 NVIDIA 高性能計算平臺的大規(guī)模專家并行部署指南

新的 prefill-decode (PD) 配置工具，簡化 PD 分離架構(gòu)設(shè)置

支持基于 SLO 的 PD 自動擴(kuò)展，并集成 Kubernetes

內(nèi)置可觀察性指標(biāo)，支持實(shí)時性能監(jiān)測

通過實(shí)時請求重定向和早期故障檢測提升系統(tǒng)韌性

通過下文了解更多關(guān)于這些更新的信息。

Dynamo 0.4 如何通過PD 分離將推理性能提高至 4 倍

Dynamo 0.4 大幅提升了 NVIDIA Blackwell 上的 PD 分離服務(wù)性能。在 NVIDIA Blackwell 架構(gòu) GPU 上使用 Dynamo 和 TensorRT-LLM 運(yùn)行新的 OpenAI gpt-oss-120b 模型，能夠在不降低吞吐量的情況下，將長輸入序列（常見于智能體工作流、代碼生成和摘要任務(wù)）場景下的交互速度（Token / 秒 / 用戶）至高提速 4 倍。

此外，在 NVIDIA 高性能計算平臺上基于 TensorRT-LLM 和 Dynamo 運(yùn)行 DeepSeek-R1 671B 模型，能夠在不增加推理成本的情況下，將吞吐量（Token / 秒 / GPU）提升 2.5 倍。

圖 1. PD 分離服務(wù)解決了 prefill 與 decode 之間的資源競爭問題，能夠在不增加 GPU 預(yù)算的情況下顯著提升性能。

（注：圖中結(jié)果僅供技術(shù)探討和參考，并且不代表最大吞吐量或最小延遲性能。復(fù)制此鏈接至瀏覽器查看最新推理性能：https://developer.nvidia.com/deep-learning-performance-training-inference/ai-inference）

圖中的性能提升來源于使用 Dynamo 進(jìn)行的 PD 分離服務(wù)，該架構(gòu)將模型推理的 prefill 和 decode 階段分離到獨(dú)立的 GPU 上。通過分離這兩個階段，Dynamo 能夠根據(jù)每個階段的具體需求靈活分配 GPU 資源和模型并行策略，從而大幅提高整體效率。

我們十分高興能夠發(fā)布這些腳本，使社區(qū)能夠復(fù)現(xiàn)這些結(jié)果并充分發(fā)揮 PD 分離服務(wù)架構(gòu)的成本效益。參見以下 GitHub 鏈接：

使用 Dynamo 和 TensorRT-LLM 部署 OpenAI gpt-oss-120b：

https://github.com/ai-dynamo/dynamo/blob/main/components/backends/trtllm/gpt-oss.md

使用 Dynamo 和 TensorRT-LLM 部署 DeepSeek-R1 671B：

https://github.com/ai-dynamo/dynamo/tree/main/components/backends/trtllm/performance_sweeps

為了幫助研究者、工程師和企業(yè)探索 PD 分離服務(wù)架構(gòu)下的 MoE 模型部署優(yōu)勢，我們還提供了詳盡的部署指南，分步指導(dǎo)用戶在多節(jié)點(diǎn)環(huán)境中使用 Dynamo 部署 DeepSeek-R1 (結(jié)合 SGLang) 和 Llama4 Maverick (結(jié)合 TensorRT-LLM)。參見以下 GitHub 鏈接：

使用 Dynamo 和 SGLang 部署 DeepSeek-R1 技術(shù)博客 1：

https://github.com/ai-dynamo/dynamo/blob/main/components/backends/sglang/docs/dsr1-wideep-gb200.md

使用 Dynamo 和 SGLang 部署 DeepSeek-R1 技術(shù)博客 2：

https://github.com/ai-dynamo/dynamo/blob/main/components/backends/sglang/docs/dsr1-wideep-h100.md

使用 Dynamo 和 TRT-LLM 部署 Llama4 Maverick：

https://github.com/ai-dynamo/dynamo/blob/main/components/backends/trtllm/llama4_plus_eagle.md

如何簡化消除 PD 分離最佳配置的大量猜測和試錯的工作

我們從采用 PD 分離服務(wù)的推理團(tuán)隊了解的主要挑戰(zhàn)之一，是如何估算預(yù)期吞吐量收益，并確定適合其特定部署的正確配置。具體而言，用戶反饋難以決定分配 prefill 和 decode 階段的 GPU 數(shù)量，以及在滿足目標(biāo) SLO 前提下，如何選擇模型并行策略。

為此，我們推出AIConfigurator，這是一個專為推薦最佳 PD 分離配置和模型并行策略設(shè)計的新工具，根據(jù)特定模型和 GPU 預(yù)算滿足 SLO 要求。

圖 2.AIConfigurator CLI 控制面板的截圖，它可視化了吞吐量與延遲間的權(quán)衡及 PD 分離的收益。在相似的延遲水平下，使用 PD 分離架構(gòu)將 Qwen3-32B 模型部署在 512 個 GPU 組成的集群中，可使吞吐量提高至 2.36 倍。

AIConfigurator 利用大量離線采集的模型各層（包括注意力機(jī)制、前饋神經(jīng)網(wǎng)絡(luò) (FFN)、通信和顯存）性能數(shù)據(jù)，并對各種調(diào)度技術(shù)（靜態(tài)批處理、動態(tài)批處理和 PD 分離服務(wù)）進(jìn)行建模，推薦 PD 配置，在給定 GPU 預(yù)算內(nèi)滿足用戶定義的 SLO，并最大化每個 GPU 的吞吐量，然后自動生成可無縫部署到 Dynamo 的后端配置。

AIConfigurator 支持命令行界面 (CLI) 和網(wǎng)頁界面，初期支持 NVIDIA Hopper 上的 TensorRT-LLM。未來版本將陸續(xù)支持更多推理框架和 NVIDIA 硬件。

如何在不對 GPU 過度或不足配置的情況下，持續(xù)滿足推理 SLO

在今年 5 月的 0.2 版本中，我們推出了首版規(guī)劃器 (Planner)，專為生成式 AI 推理和 PD 分離設(shè)計的 GPU 自動擴(kuò)展引擎。它能夠通過監(jiān)測 prefill 隊列和 decode 內(nèi)存使用情況，智能增減推理工作節(jié)點(diǎn)，最大化 GPU 利用率并最小化推理成本。

在 0.4 版本中，我們進(jìn)一步完善了 Planner，新增基于 SLO 的自動擴(kuò)展功能，使推理團(tuán)隊不僅能夠降低成本，還能穩(wěn)定地滿足嚴(yán)格的性能指標(biāo)，例如首 Token 延遲 (TTFT)、Token 間延遲 (ITL)。

與傳統(tǒng)的響應(yīng)式擴(kuò)展系統(tǒng)不同，新的基于 SLO 的 Planner 采用前瞻性策略：

使用部署前性能分析，理解不同模型并行和批處理配置下的部署表現(xiàn)。

基于 SLO 推薦最具成本效益的引擎配置。

使用 ARIMA 或 Prophet 等先進(jìn)的時間序列模型預(yù)測未來流量模式。

計算在預(yù)測需求下滿足 SLA 目標(biāo)所需的最小 PD 工作節(jié)點(diǎn)數(shù)量。

持續(xù)評估流量模式并動態(tài)調(diào)整 PD 工作節(jié)點(diǎn)以持續(xù)滿足目標(biāo) SLA。

Planner 的與眾不同之處在于能夠預(yù)測輸入 / 輸出序列長度變化的影響，并在出現(xiàn)瓶頸前，主動擴(kuò)展資源規(guī)模。

基于 SLO 的 Planner 使推理團(tuán)隊能夠：

把控用戶體驗(yàn)和基礎(chǔ)設(shè)施成本

在不過度或不足配制資源的前提下維持 SLA 性能

無需手動調(diào)優(yōu)即可優(yōu)化 GPU 使用率

Planner 原生集成 Kubernetes，便于已經(jīng)采用容器化基礎(chǔ)設(shè)施的企業(yè)能夠輕松部署 Dynamo，并使用 Planner 擴(kuò)展其 AI 工作負(fù)載。此版本加入了對 vLLM 的支持，未來將持續(xù)支持更多推理框架。。

如何追蹤實(shí)時推理可觀察性指標(biāo)

可觀察性在大規(guī)模分布式推理環(huán)境中至關(guān)重要，使工程團(tuán)隊能夠監(jiān)測系統(tǒng)健康狀況、診斷性能瓶頸并滿足嚴(yán)格的 SLO，根據(jù) SLO 的要求不斷實(shí)時優(yōu)化延遲、吞吐量和 GPU 利用率。

圖 3. 顯示 Dynamo 采集的關(guān)鍵性能指標(biāo)的 Grafana操作面板

在新發(fā)布的 Dynamo 0.4 中，事件、控制和數(shù)據(jù)平面的 Dynamo 工作節(jié)點(diǎn)和組件會輸出關(guān)鍵的可觀察性指標(biāo)，包括：

每秒平均請求數(shù)和請求持續(xù)時間

平均的首 Token 延遲 (TTFT) 和 Token 間延遲 (ITL)

平均輸入和輸出序列長度

GPU 利用率和功耗

這些指標(biāo)通過開源的 Prometheus 工具采集，無需進(jìn)行定制開發(fā)即可輕松集成到 Grafana 等開源監(jiān)測和可觀察性工具中。

本版本還包含一個 API，供工程團(tuán)隊和解決方案架構(gòu)師定義和輸出適配其服務(wù)環(huán)境的自定義指標(biāo)，進(jìn)一步提高了靈活性和可擴(kuò)展性。

Dynamo 0.4 中的可觀察性基礎(chǔ)為后續(xù)版本奠定了基礎(chǔ)，未來將引入更具細(xì)粒度、針對特定用例的指標(biāo)，包括與 PD 分離相關(guān)的指標(biāo)。

Dynamo 0.4 如何提升系統(tǒng)彈性和早期故障檢測能力

大規(guī)模部署前沿推理 MoE 模型需要支持?jǐn)?shù)百 GPU 的多節(jié)點(diǎn)環(huán)境。在此類部署中，任何軟硬件組件的故障（無論持續(xù)時間多短）都會中斷整個系統(tǒng)的運(yùn)行，并導(dǎo)致用戶請求延遲或失敗，進(jìn)而影響業(yè)務(wù)運(yùn)營，損害用戶體驗(yàn)。

Dynamo 0.4 版本引入了實(shí)時請求重定向(inflight request re-routing)等容錯和彈性功能。在之前的版本中，發(fā)送到離線 GPU 的請求會失敗，并回退到推理棧上層或用戶端，這會觸發(fā)重試流程，即重復(fù)執(zhí)行預(yù)處理步驟（如 Token 化和嵌入），浪費(fèi)計算資源并增加延遲。經(jīng)過此次更新，Dynamo 會在請求執(zhí)行中動態(tài)重定向，保留中間計算結(jié)果并直接轉(zhuǎn)發(fā)至在線 GPU，從而消除冗余工作。

圖 4. 生成過程中未啟用（圖片上半部）和啟用（圖片下半部）實(shí)時請求重定向的系統(tǒng)工作流差異示意圖。

此外，此版本引入了更快的故障檢測機(jī)制。在之前的版本中，etcd（Dynamo 控制平面中的關(guān)鍵組件）負(fù)責(zé)檢測離線工作節(jié)點(diǎn)并向系統(tǒng)廣播其狀態(tài)。但這會引發(fā)幾秒鐘的延遲，在此期間請求仍可能被路由到離線工作節(jié)點(diǎn)。新版本在 Dynamo 智能路由器 (Smart Router) 中引入了早期故障檢測功能，使其能夠繞過 etcd 并響應(yīng)關(guān)鍵健康信號，縮短了故障檢測到恢復(fù)的時間窗口，顯著減少了失敗請求。

如何參與 Dynamo 開發(fā)者社區(qū)互動

歡迎您加入我們的 Discord 社區(qū) (https://discord.gg/ZXRE8epz)，來與其他開發(fā)者交流、分享反饋并獲得實(shí)時支持。如果您對我們的開發(fā)方向感興趣，請訪問官方 Dynamo GitHub 開源資源庫 (https://github.com/ai-dynamo/dynamo)。我們歡迎社區(qū)的貢獻(xiàn)、問題反饋和想法。