近期，OpenAI 的 gpt-oss、月之暗面的 Kimi K2 等多個新的前沿開源模型相繼問世，標志著大語言模型 (LLM) 創新浪潮的加速。近日發布的 Dynamo 0.4 提供了一系列新功能，旨在規?；⒌统杀镜夭渴鸫祟惸Ｐ?，其核心功能包括性能優化、可觀察性和基于服務等級目標 (SLO) 的自動擴展。

Dynamo 0.4 的主要亮點包括：

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

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

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

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

內置可觀察性指標，支持實時性能監測

通過實時請求重定向和早期故障檢測提升系統韌性

通過下文了解更多關于這些更新的信息。

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

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

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

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

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

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

我們十分高興能夠發布這些腳本，使社區能夠復現這些結果并充分發揮 PD 分離服務架構的成本效益。參見以下 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

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

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

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

使用 Dynamo 和 SGLang 部署 DeepSeek-R1 技術博客 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 分離服務的推理團隊了解的主要挑戰之一，是如何估算預期吞吐量收益，并確定適合其特定部署的正確配置。具體而言，用戶反饋難以決定分配 prefill 和 decode 階段的 GPU 數量，以及在滿足目標 SLO 前提下，如何選擇模型并行策略。

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

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

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

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

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

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

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

與傳統的響應式擴展系統不同，新的基于 SLO 的 Planner 采用前瞻性策略：

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

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

使用 ARIMA 或 Prophet 等先進的時間序列模型預測未來流量模式。

計算在預測需求下滿足 SLA 目標所需的最小 PD 工作節點數量。

持續評估流量模式并動態調整 PD 工作節點以持續滿足目標 SLA。

Planner 的與眾不同之處在于能夠預測輸入 / 輸出序列長度變化的影響，并在出現瓶頸前，主動擴展資源規模。

基于 SLO 的 Planner 使推理團隊能夠：

把控用戶體驗和基礎設施成本

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

無需手動調優即可優化 GPU 使用率

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

如何追蹤實時推理可觀察性指標

可觀察性在大規模分布式推理環境中至關重要，使工程團隊能夠監測系統健康狀況、診斷性能瓶頸并滿足嚴格的 SLO，根據 SLO 的要求不斷實時優化延遲、吞吐量和 GPU 利用率。

圖 3. 顯示 Dynamo 采集的關鍵性能指標的 Grafana操作面板

在新發布的 Dynamo 0.4 中，事件、控制和數據平面的 Dynamo 工作節點和組件會輸出關鍵的可觀察性指標，包括：

每秒平均請求數和請求持續時間

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

平均輸入和輸出序列長度

GPU 利用率和功耗

這些指標通過開源的 Prometheus 工具采集，無需進行定制開發即可輕松集成到 Grafana 等開源監測和可觀察性工具中。

本版本還包含一個 API，供工程團隊和解決方案架構師定義和輸出適配其服務環境的自定義指標，進一步提高了靈活性和可擴展性。

Dynamo 0.4 中的可觀察性基礎為后續版本奠定了基礎，未來將引入更具細粒度、針對特定用例的指標，包括與 PD 分離相關的指標。

Dynamo 0.4 如何提升系統彈性和早期故障檢測能力

大規模部署前沿推理 MoE 模型需要支持數百 GPU 的多節點環境。在此類部署中，任何軟硬件組件的故障（無論持續時間多短）都會中斷整個系統的運行，并導致用戶請求延遲或失敗，進而影響業務運營，損害用戶體驗。

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

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

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

如何參與 Dynamo 開發者社區互動

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