在 NVIDIA GTC 2025 上，我們宣布推出 NVIDIA Dynamo ，這是一種高吞吐量、低延遲的開源推理服務框架，用于在大規模分布式環境中部署生成式 AI 和推理模型。
Dynamo 的最新 v0.2 版本包括：
- 用于預填充和解碼 GPU 自動縮放的規劃器。
- 適用于大規模 Dynamo 部署的 Kubernetes 自動化。
- 支持 AWS Elastic Fabric Adaptor (EFA) ，用于在 AWS 上進行節點間數據傳輸。
在本文中，我們將介紹這些功能，以及它們如何幫助您從 GPU 投資中獲得更多收益。
適用于解服務工作負載的 GPU 自動擴展
21 世紀初，云計算迅速采用的關鍵驅動因素之一是 autoscaling，即根據實時需求自動調整計算能力的能力。通過消除提前為峰值負載配置基礎設施的需求，autoscaling 可實現成本效益和運營靈活性。雖然這一概念已得到充分確認，但將其有效應用于 LLM 推理工作負載仍然是一項重大挑戰。
傳統的自動縮放依賴于簡單的指標，例如每秒查詢次數 (QPS) 。然而，在現代 LLM 服務環境中，并非所有推理請求都是相同的 (尤其是那些使用解服務等技術的環境) ，僅 QPS 就無法預測系統負載。與使用短 ISL 的多個請求相比，具有長輸入序列長度 (ISL) 的單個請求會消耗更多資源。
此外，長 ISL 對預填充 GPU 造成壓力，而長輸出序列長度 (OSL) 對 GPU 進行壓力解碼。在解設置中，工作負載分布可能會隨時發生急劇變化，導致基于原始指標 (如 QPS) 的自動擴展策略失效。這種復雜性使得很難平衡預填充和解碼 GPU 之間的負載。
我們需要一個專門構建的規劃引擎，它能夠理解 LLM 特定的推理模式和分解的服務架構。它不僅要決定何時擴展，還要決定要擴展的 GPU 類型和方向。它還應支持本地實驗，使開發者能夠在原型設計和大規模生產部署期間考慮需求波動，以便與 Kubernetes 自動擴展環境一起運行。
在 v0.2 版本的 Dynamo 中，我們推出了 NVIDIA Dynamo Planner? 推理感知型自動縮放器，用于分解服務。使用 Dynamo Serve CLI (命令行接口) 的開發者現在可以在部署的同時運行 GPU 規劃器，使其能夠監控工作負載模式，并動態管理預填充和解碼階段的計算資源。
Dynamo Planner 的工作原理
- 監控所有解碼 GPU 的平均 KV 塊利用率。
- 跟蹤全局 prefill 隊列中的待處理 prefill 請求量。
- 將這些值與 heuristic 閾值進行比較，開發者可以在部署設置期間手動定義這些閾值。
- 自動重新平衡資源 – 在預填充和解碼階段之間切換 GPU，或從共享池調配新 GPU。
下一個版本的 Dynamo 將能夠與 NVIDIA Dynamo Deploy CLI 一起運行 GPU Planner，從而在大規模 Kubernetes 部署中實現 autoscaling。
只需一條命令，即可將 LLM 從本地開發擴展到生產環境
AI 推理團隊面臨的一項關鍵挑戰是，將 LLM 從本地開發環境過渡到可擴展的生產就緒型 Kubernetes 部署，操作十分復雜。雖然本地環境非常適合進行實驗和原型設計，但很少能反映數據中心級生產系統的現實情況。
過去，使用 Kubernetes 將應用程序從本地過渡到生產需要執行一系列手動步驟：容器化應用程序及其支持組件，手動制作 Kubernetes YAML 配置文件，配置 Kubernetes 資源，以及管理向 Kubernetes 兼容注冊表發布的容器鏡像。此過程通常非常耗時、容易出錯，并且嚴重依賴開發者專業知識，從而延遲新 LLM-enabled 應用程序的上市時間。
隨著 LLM 規模和復雜性的不斷變化，在生產環境中部署 LLM 的要求也顯著增加。現代推理服務器現在需要其他組件，例如：
- LLM 感知型請求路由，可在推理節點之間優化請求分布。
- KV 緩存卸載可高效處理大規模推理內存需求。
- 動態 GPU 分配可確保高效且經濟高效地使用計算資源。
這些組件緊密集成，這使得在 Kubernetes 中手動容器化成為生產部署期間的額外挑戰。
為應對這些挑戰，v0.2 版本配備了 NVIDIA Dynamo Kubernetes Operator ，可自動執行 Kubernetes 部署。Operator 包含圖像構建和圖形管理功能，旨在完全自動化處理生產部署的復雜性。這使得 AI 推理團隊能夠從桌面 GPU 或本地 GPU 節點上的 Dynamo 原型轉向使用單個 CLI 命令跨數千個 GPU 進行可擴展的數據中心級部署。
這種自動化消除了手動創建 Docker 文件和配置 YAML 的需求，并在 GPU 優化的 Kubernetes 集群中動態調配和擴展推理工作負載。它還與領先的 Kubernetes 原生 MLOps 云工具無縫集成，從而更輕松地將 Kubernetes 集群部署到所有主要的云服務提供商。
通過抽象化手動開發和配置流程，Dynamo 使 AI 團隊能夠專注于模型創新和交付，而不是基礎架構設置。它可顯著縮短生產時間，并提供在分布式環境中部署現代數據中心級 LLM 所需的可靠性、靈活性和可擴展性。
優化 NVIDIA 驅動的 Amazon EC2 實例上的 KV 緩存傳輸
KV 緩存是 LLM 推理成本的主要來源。雖然 KV 緩存通常對最終用戶隱藏，但在后臺進行管理，可以顯著節省成本。分解服務和 KV 緩存卸載等技術已經出現，可以優化 KV 緩存的生成和存儲。
然而，這些方法依賴于跨 GPU 節點的低延遲數據傳輸（通常通過 InfiniBand 或 Ethernet 等網絡協議互聯），并且可能涉及將數據移動到外部存儲（例如文件系統或對象存儲）。將各種網絡和存儲庫集成到推理服務框架中非常耗時，而且通常會導致 KV 緩存移動效率低下，從而增加延遲并推高推理成本。
為應對這些挑戰，Dynamo 包含開源 NVIDIA Inference Transfer Library (NIXL) 。NIXL 是一種高性能、低延遲的點對點通信庫，專為在異構環境中移動數據而構建。它為跨內存和存儲層的快速異步傳輸提供了一致的 API，降低了處理不同硬件和協議的復雜性。它支持與 GDS (GPUDirect Storage) 、UCX (Unified Communication X) 、Amazon S3 (Simple Storage Service) 等集成，并可跨 NVIDIA NVLink-C2C、NVIDIA NVLink Switch、InfiniBand、RoCE 和 Ethernet 等互連產品使用。
借助 NIXL，開發者不再需要手動處理協議選擇或集成邏輯。相反，他們可以通過 NIXL 的前端 API 使用簡單的 get、push 和 delete 命令，而庫可以智能地選擇最佳后端并處理所有底層 bookkeeping，從而大大簡化開發并提高性能。
最新版本的 Dynamo 擴展了 NIXL 的支持，增加了 AWS Adapter (EFA) 。EFA 是用于 EC2 實例的節點間通信網絡接口。借助 V0.2 Dynamo 版本，在 AWS 云上部署 LLM 的 AI 服務提供商現在可以在多節點設置中利用 Dynamo 的分布式和分解服務功能，這些功能在 NVIDIA 驅動的 EC2 實例上運行，例如由 NVIDIA Hopper 驅動的 P5 系列和由 NVIDIA Blackwell 驅動的 P6 系列。
參加我們的下一次用戶見面會
我們正在以開放的方式構建 NVIDIA Dynamo，并已在 GitHub 上 發布了 我們的路線圖。我們很高興能繼續討論，并聆聽您如何使用 NVIDIA Dynamo 進行構建。
加入我們于 6 月 5 日在 San Francisco 舉行的首次線下 用戶見面會 ，我們將深入探討 v0.2 版本和 Dynamo 路線圖。我們期待在那里見到您。
?
