NVIDIA DSX 電力調度：24% token 增益是真的嗎？（2026）

2026 年 9 月 15 日，NVIDIA 的 Vishal Ganeriwala 在 NVIDIA Blog 發表 〈From Megawatts to Tokens: How NVIDIA Maximizes AI Factory Production〉，把 NVIDIA DSX 的電力調度推到 AI 算力的新戰場：當電網暫時不肯再給你一瓦電，能不能靠軟體多跑幾台 GPU？文中公布一組答案：Lambda 在約 129 kW 的配置功率範圍內，把 16 個全功率 HGX B200 節點換成 19 個受控節點，總 token 吞吐提高約 24%。數字很吸睛，但這組合作夥伴概念驗證所支持的是「把預留餘裕變成可用容量」，不是軟體憑空創造電力。

真正的瓶頸：NVIDIA DSX 要解決的不是 GPU，而是電

AI 資料中心通常依設備可能出現的最高功耗來配置變壓器、配電與保護容量；真實工作負載卻不會讓每顆 GPU 在每一秒都吃滿額定功率。兩者之間的差，就是長期被保留、卻未必同時使用的「電力餘裕」。過去營運商寧可留得太多，也不願讓一次同步尖峰觸發保護機制。

NVIDIA DSX 的想法，是把這段餘裕從靜態保險變成可量測、可分優先級、可回收的共享資源。它是總體平台，不是單一排程器：Slurm、Kubernetes／Run:ai 等排程器仍決定工作跑在哪裡，Mission Control 則整合管理、觀測與這些排程器。MaxLPS 是涵蓋場地設計、效能／瓦最佳化與動態功率配置的框架，其中 Dynamic Power Software（DPS）建模並約束電力拓撲，再透過 BMC／Redfish 調整受管節點的 GPU 功率；DSX Exchange 負責交換 IT／OT 訊號，DSX Flex 則依電網事件協調可延後工作與現場能源資源。

“by running 19 nodes within the same power budget as 16 nodes at full power, Lambda achieved 24% more cluster-wide token throughput”

中文：Lambda 在 16 個節點全功率運行的功率預算內改跑 19 個節點，叢集總 token 吞吐因此提高 24%。

NVIDIA Blog

這不是讓原來的 16 台突然快 24%，而是降低單台的功率上限，再把省出的空間交給另外 3 台。只要單台效能下降得比功率下降慢，整個叢集就可能做更多工作。

Lambda 的 24%：算術成立，測量邊界要說清楚

公開配置	節點數	功率政策	配置功率預算	總 Tokens/s
基準	16	無	128.0 kW	4.04M
MaxLPS	19	85%	129.2 kW	5.00M

依公開數字重算，5.00 ÷ 4.04 − 1 = 23.8%，四捨五入就是 24%。若再除以各自標示的配置功率，吞吐／kW 提高約 22.6%，也能四捨五入成 23%。所以兩個百分比沒有算錯。

但「相同功率」只是約略說法：128.0 與 129.2 kW 相差約 0.94%。兩者也正好對應 16×8×1 kW 與 19×8×0.85×1 kW 的 B200 GPU 配置上限總和；表格寫的是 power budget，不是包含 UPS、冷卻與 PUE 的設施級電表讀值。節點數增加 18.75%，換算每節點吞吐則約提高 4.2%。這更像是用功率整形換取部署密度，而不是每台伺服器免費得到 24% 加速。

概念驗證仍缺三塊關鍵拼圖

• token 口徑不完整：NVIDIA 的公開圖表只寫 Tokens/s，沒有交代是輸出 token，還是輸入與輸出的合計，因此不能直接解讀成每秒產生 500 萬個答案 token。
• 服務品質缺少同口徑比較：截至 2026 年 9 月 16 日，本文核對的 NVIDIA 9 月 15 日原文與 Lambda 案例頁，未提供 16 與 19 節點兩組可直接比較的測試時長、重複次數、誤差棒，以及完整 TTFT／p95／p99 延遲與錯誤率。40 QPS／節點也代表 offered load 從 640 QPS 增至 760 QPS，不能只看總吞吐。
• 引用鏈不是獨立重現：Lambda 與 NVIDIA 是合作夥伴，NVIDIA 也曾參與 Lambda 2025 年的 4.8 億美元融資，而案例由 NVIDIA 發布。MLCommons v6.0 公開摘要中的 Lambda_SIT GPT-OSS-120B 項目為單節點且 has_power:false，不是本文這組 19 節點、85% 政策、129 kW 配置。

更重要的是，截至 2026 年 9 月 16 日，DPS 0.9 文件仍明確標為 Developer Preview，官方並寫明除經授權合作外不應用於生產環境。NVIDIA 的機制說明也明確寫道，它「does not schedule workloads or add facility capacity」：它不取代 Slurm、Kubernetes／Run:ai，也不會增加大樓的變壓器、斷路器、冷卻或機櫃容量。

4 MW 降到 3 MW：究竟算不算 DSX Flex？

NVIDIA 原文另描述 Santa Clara 的一場 8 月事件：Emerald AI Conductor 讓低優先工作退讓，把該 AI factory 受控範圍的負載從 4 MW 降到 3 MW，高優先推論則繼續運作；一般收到 Silicon Valley Power 訊號後，控制器可在一分鐘內回應。NVIDIA 還稱，該工廠此後收到逾 200 個需求訊號且每次都成功回應；但這仍是 NVIDIA／Emerald 自報。截至 2026 年 9 月 16 日，本文核對的 NVIDIA 9 月 15 日原文與前述官方案例頁，未逐次列出削減幅度、持續時間與 SLA。這顯示 AI 負載有機會從電網的「固定大戶」變成可調節負載，也留下了可稽核性問題。

這裡有兩組不能略過的衝突。第一，4 MW 降至 3 MW 本身是 25%；NVIDIA 同頁摘要表另列 40% 並歸於 SVP automated response，卻沒有說明是否為另一事件。另一份 Emerald 案例頁則把 40% 與逾 200 次模擬事件明確歸於倫敦 96-GPU 試驗。第二，Silicon Valley Power 於 2026 年 4 月 21 日的試點公告稱系統與 DSX Flex 緊密整合、由它提供支援；NVIDIA 9 月 15 日原文卻說 Santa Clara「不是 DSX Flex installation」。上述官方頁面沒有調和這些版本；SVP 的公告早於 8 月事件，因此該頁本身也不可能提供後來事件的時間序列、電表邊界或推論 SLA 前後數據。

所以最準確的說法是：Santa Clara 支持「彈性 AI 負載」的方向；但截至 2026 年 9 月 16 日，本文核對的上述官方頁面對 DSX Flex 產品歸屬說法不一，也未提供可逐事件核對的完整結果。另有一項不同配置的 Nature Energy 研究，在 Phoenix 的 256-GPU 叢集連續三小時降低 25% 功率並維持 QoS；它支持機制可行，並不重現 Santa Clara 或 Lambda 的精確倍率。這篇研究由 Emerald AI 主導，作者也包括 NVIDIA、Oracle、SRP／EPRI 等參與者；論文揭露部分作者持有相關公司的股票或期權，Emerald 作者另有相關專利申請。Emerald 同時是 NVentures portfolio company。這些關係不代表結果錯誤，但它是經同儕審查的一手 field demo，不是與商業利益切開的獨立重現。

別把「67 倍 Rubin」和「24% DSX」相乘

SemiAnalysis 的 Rubin 評測仍是 InferenceX official preview；在 DeepSeek V4 Pro 0813 1.6T AgentX、約 170 P90 TPS、TRT-LLM NVFP4 Dense 與大型 hyperscaler owning-cost 假設下，它依自建成本模型算出 Rubin NVL72 相對 GB300 Dynamo TRT-LLM 約 67 倍 throughput／TCO。這不是帳單或採購成本的獨立實測。該端點之所以爆炸，是舊平台在那個服務門檻附近幾乎失去可承載的併發量；換成較常見的 60–100 TPS，SemiAnalysis 自己給的區間只有 1.4–3 倍。GB300 改用 SGLang 又能達到與 Rubin 接近的最高 interactivity，顯示 serving engine 本身也是 headline 倍率的一部分。

這和 DSX 是兩件事。Rubin 數字比較硬體世代、推論引擎與特定 SLA；DSX 數字比較固定功率範圍內能啟用多少節點。兩者不能相乘，也不能把 67 倍歸功於電力調度。SemiAnalysis 公開致謝 NVIDIA 協助 Rubin 軟體 bring-up 與驗證，早期測試點也由 NVIDIA 量測後交由 SemiAnalysis 審核；截至 2026 年 9 月 16 日，本文核對的 InferenceX Rubin row 未附 power_audit 與 run_url，對應的公開 log／trace availability 也為空。它應被視為 vendor-assisted、third-party-reviewed 的特定邊界結果，而非一般化的獨立量測平均升級幅度。

這也呼應 AI 推論的 HBM 記憶體瓶頸：模型在 prefill、decode、長上下文與不同批次下，功率—效能曲線完全不同。只有在吞吐下降速度小於功率下降速度時，MaxLPS 才能靠多開節點賺回總吞吐。

把「容量」拆成三層：NVIDIA DSX 解鎖的是哪一種？

1. 名目電力容量沒有增加：公用電力、變壓器與斷路器的上限原封不動。
2. 可部署／同時啟用的 GPU 數量可能增加：若機房已有機櫃、網路、冷卻與資本，動態功率上限能讓營運商在同一電力邊界內多啟用硬體。
3. 每焦耳有用工作可能增加：若控制器找到功率—效能曲線的甜蜜點，總 tokens／kWh 能上升；代價可能是單卡降速、低優先工作延後，以及額外伺服器成本。

這就是我同意 NVIDIA 的地方：在站點總包絡與峰值同時性規劃上，不必假設所有 GPU 永遠同步達峰，電力可以成為可觀測、可排隊、可分級的資源；但本地配電與 rack-side cooling 仍須依 MaxP sizing，實體保護不能由統計多工取代。Microsoft Research 的 ASPLOS 2024 研究也發現，推論叢集比同步訓練更常留下可統計多工的功率餘裕。

我保留的地方，是把「最高可多放 40% GPU」說成普遍結果。NVIDIA 的 Rubin 1 MW 情境仍標示為 illustrative，硬體測試也仍在進行。DPS 0.9 預設功率分配週期為 5 秒，官方也明言其模型不能建立 50 毫秒尖峰的實測合規；訓練同步尖峰、低優先工作不足、BMC 或遙測故障，都可能迫使系統保留更多安全邊際。即使電力夠，機櫃、交換器、液冷與三台額外伺服器也不會免費出現。

接下來真正值得追的五個訊號

• Lambda 是否公開精確的 token 定義、完整延遲分布、功率時間序列與重複試驗。
• 支撐 MaxLPS 動態功率配置的 DPS 是否從 Developer Preview 進入正式生產支援，並以公開實測驗證故障時的安全退化行為。
• 是否有非 NVIDIA、Lambda 或 Emerald 團隊重現相近的吞吐／功率改善。
• 訓練、混合 prefill／decode 與不同模型下，收益是否仍能覆蓋額外硬體及網路成本。
• 電力公司是否發布實際需求回應事件的電表資料、持續時間與 SLA 影響，而不只是一個峰值百分比。

結論：這不是魔法，而是把預留餘裕變成功率配置問題

NVIDIA DSX 最重要的訊號，不是 24%、40% 或 67 倍中的任何一個大數字，而是 AI 基礎建設的競爭單位正在從「單顆 GPU 有多快」移向「每一瓦、每一秒、每一級服務承諾能產出多少有用工作」。Lambda 的結果是一組算術可核、但證據鏈仍由 NVIDIA 與其投資／合作方組成的概念驗證，目前只支持特定 B200 推論配置；它還不是普遍定律，也不是獨立審核過的設施級節能成績。