NVIDIA and Nscale Demonstrate DSX MaxLPS Dynamic Power Management to Expand AI Data Center Capacity

NVIDIA and Nscale Demonstrate DSX MaxLPS Dynamic Power Management to Expand AI Data Center Capacity A joint evaluation by NVIDIA and Nscale demonstrates that NVIDIA DSX MaxLPS dynamic power sharing allows data centers to deploy up to 40% more GPUs within an existing approved power budget by reallocating stranded power headroom. DSX MaxLPS uses policy-governed control loops across topology, telemetry, policy, allocation, and enforcement to dynamically balance GPU power limits without increasing total power supply. In testing on NVIDIA GB300 NVL72 systems running Kimi K2.5 workloads at Nscale's Iceland facility, managed GPUs grew 37.1% from 140 to 192 under an identical 264.4 kW budget. Aggregate throughput and throughput per provisioned watt increased by 49.2%, rising from 1,084,503 tokens/s (4.10 tokens/s/W) to 1,618,443 tokens/s (6.12 tokens/s/W). Median and P75 latencies stayed within 5% of the baseline, while P99 time to first token rose 17% from 15.7 seconds, highlighting the need to evaluate tail latency alongside throughput. Operators are advised to use a staged validation process covering boundary mapping, baseline measurement, conservative policy introduction, incremental scaling, and production limit approval. Addressing Stranded Power in Static AI Provisioning AI data centers face constraints across utility service, substations, distribution equipment, racks, and nodes. Conventional static power planning reserves peak power simultaneously for every node, yet AI workloads alternate through varying phases of compute, communication, synchronization, prefill, and decode. This discrepancy between reserved peak thresholds and actual consumption leaves unallocated power stranded. DSX MaxLPS uses Dynamic Power Software to monitor real-time consumption and dynamically distribute headroom among participating hardware within set operator policies. Test Methodology and Empirical Performance Results The evaluation took place at Nscale's renewable-powered Verne campus in Keflavík, Iceland, utilizing NVIDIA GB300 NVL72 systems, Blackwell Ultra GPUs, Kimi K2.5 in FP4, Dynamo, and TensorRT LLM with 8K input and 1K output sequence lengths. Compared against a static baseline of 140 GPUs running two high-throughput instances and one low-latency instance across four racks, the DSX MaxLPS setup deployed 192 GPUs by adding a third high-throughput instance under the same 264.4 kW power budget. Aggregate throughput rose by 49.2% to 1,618,443 tokens/s, while power-budget utilization increased from 62.9% to 75.2%, leaving per-instance throughput unaffected. Operational Trade-offs and Validation Requirements Dynamic power sharing exposes engineering trade-offs rather than removing them. Headroom is determined by workload mix, yielding the best results when workloads have complementary power profiles rather than simultaneous peaks. While median and P75 latencies remained within 5% of baseline figures, P99 time to first token rose 17% above the 15.7-second baseline, underscoring that tail latency must be factored into service-level targets. Accurate control relies directly on telemetry integrity across GPUs, nodes, and racks. Site Planning and Staged Deployment Guidance To safely adopt DSX MaxLPS, data center operators should follow a five-step validation framework: define the managed boundary and limits, establish a representative baseline under static provisioning, deploy policies conservatively near baseline limits, incrementally add hardware while stress-testing failure scenarios, and set final production limits. Facilities must also plan cooling, electrical, space, and networking infrastructure to accommodate the expanded operating target. Future implementations on Vera Rubin NVL72 systems will also combine dynamic power allocation with 45°C liquid-cooling inlet operations.

NVIDIA推出DSX MaxLPS动态电力分配技术，在固定供电预算下提升AI算力密度与吞吐量 传统AI数据中心基于峰值功耗进行静态容量预留，导致大量电力闲置。NVIDIA联合Nscale通过DSX MaxLPS技术，利用动态电力管理软件在既定电力预算内协调分配电力，在冰岛机房的GB300 NVL72系统上实现了GPU部署量增加37.1%、总吞吐量提升49.2%的测试表现。 静态配置因按极端峰值预留功率导致资源闲置，而AI训练与推理负载功耗随计算、通信和输入输出阶段动态波动。 DSX MaxLPS结合拓扑映射、遥测、策略、动态分配和执行验证五大要素，在不增加总电网供电的前提下提高利用率。 实测在264.4 kW固定电力预算下，受管GPU从140台增至192台，整体吞吐量提升49.2%，每瓦吞吐量从4.10增至6.12 tokens/s/W。 尽管中位数和P75延迟维持在基线5%以内，但P99首字时间增加了17%，表明动态调配需权衡尾部延迟与遥测可靠性。 静态供电规划导致可用电力闲置 AI工厂在电网、变电站、配电设备、机架到GPU各层级均有严格电气限制。静态电力规划通常为每个节点预留全额峰值功率，但AI训练与推理的实际功耗会随阶段（如预填充、解码、通信、闲置）剧烈变动。这种保守策略导致单节点闲置电量无法转移，整体机房在未达上限时便无法继续接入更多GPU。 DSX MaxLPS控制闭环机制 DSX MaxLPS依托Dynamic Power Software构建控制层，包含五个核心环节：划分拓扑与资源组、采集细粒度遥测数据、设定组级与节点级策略规则、动态分配其他节点未用电力调整GPU功耗上限，以及校验执行防止超过总体预算。该闭环在固定的电力预算红线内释放了更多有效算力。 基于GB300 NVL72与Kimi大模型的评估结果 NVIDIA与Nscale在冰岛数据中心开展实测，使用GB300 NVL72系统运行FP4精度的Kimi K2.5推理负载。在保持264.4 kW电力预算不变的情况下，DSX MaxLPS将GPU规模从140台扩展到192台（+37.1%），总吞吐量从约108.5万tokens/s提升至161.8万tokens/s（+49.2%），总功耗利用率从62.9%升至75.2%，各实例单体吞吐量基本保持不变。 工程权衡考量与多阶段验证流程 动态调配放大了尾部性能与遥测风险：测试中P99首字时间增长了17%，且可用裕量高度依赖异构工作负载的互补性，同时依赖精准的遥测数据以防误判。因此，运营团队需通过分步流程上线该方案，涵盖界定管理边界、建立代表性静态基准、保守引入策略、分批增加算力容量并压测故障场景，最终确立生产运营限制。

Every unused watt is capacity left on the table. AI factories are typically provisioned for the unlikely moment when every GPU reaches peak power, creating a protective buffer that can leave valuable infrastructure underused during normal operation. NVIDIA DSX MaxLPS uses policy-governed power sharing to allocate power across participating resources dynamically, enabling customers to deploy up to 40% more GPUs within the same approved power budget. This technical walkthrough examines a joint NVIDIA and Nscale evaluation of this approach with Kimi K2.5 workloads running on NVIDIA GB300 NVL72 systems at Nscale’s data center at the Verne campus in Keflavík, Iceland, powered entirely by renewable energy. It covers the measured trade-offs between power and performance, explains the controls used to maintain electrical limits, and presents a repeatable validation method operators can use before deploying at scale. How static provisioning leaves usable power stranded An AI factory operates within a hierarchy of electrical limits. Utility service, substations, power-distribution equipment, racks, nodes, and GPUs all impose constraints. Operators must keep each managed boundary within its approved limit while meeting application throughput and latency objectives. Static power planning typically reserves enough power for every node to reach its specified peak at the same time. This conservative approach is straightforward, but AI workloads rarely draw constant power. Training workloads move through compute, communication, synchronization, and checkpointing. Inference workloads alternate among prefill, decode, memory-bound work, network activity, and idle intervals. Even instances of the same model can draw different power as request shapes and concurrencies change. This variability creates a gap between reserved peak power and actual consumption. With static per-node reservations, unused capacity inside one reservation cannot be applied to another node. The aggregate facility can remain below its limit while additional GPU capacity stays offline. DSX MaxLPS monitors actual power consumption and dynamically reallocates available power across participating resources while preserving the operator’s aggregate budget and policy boundaries. Figure 1. Static MaxP can leave reserved power unused; static MaxQ can constrain performance; DSX MaxLPS dynamically reallocates power within operator-defined limits Inside the DSX MaxLPS control loop DSX MaxLPS combines chip, system, thermal, and software technologies to maximize AI factory output within land, power, and shell (LPS) constraints. Dynamic Power Software provides the control layer for policy-governed power allocation. The control process has five technical elements: Topology and resource groups. Operators map the participating infrastructure and organize nodes into a managed group with an aggregate power budget. Telemetry. The system collects GPU, node, rack, and group power telemetry at intervals sufficient to detect available headroom and emerging power events. Policy. Operator-defined rules establish node limits, group limits, allocation priorities, reserve requirements, and responses to maintenance or emergency events. Allocation and control. When some resources draw less than their allocation, the software adjusts participating GPU power limits so other resources can use the available capacity. Validation and enforcement. The system compares measured power against the approved group budget and adjusts allocations when consumption approaches a limit. This is coordinated allocation, not an increase in the site’s power supply. The control loop enables more productive work beneath the same managed power budget. How the method was evaluated For the evaluation, Nscale deployed the MaxLPS software in its data center and collected telemetry while NVIDIA ran the workloads. The evaluation measured control behavior and workload trade-offs. The evaluation used NVIDIA Blackwell Ultra GPUs, Kimi K2.5 in FP4, NVIDIA Dynamo, NVIDIA TensorRT LLM, an 8K input sequence length, and a 1K output sequence length. The workload mix combined high-throughput and low-latency inference instances, creating distinct power and service profiles within the managed group. The static baseline used 35 four-GPU nodes, or 140 GPUs. It ran two high-throughput instances using 52 GPUs each and one low-latency instance using 36 GPUs. The DSX MaxLPS configuration used 48 four-GPU nodes, or 192 GPUs. It added a third 52-GPU high-throughput instance while retaining the same 36-GPU low-latency instance. Jobs ran across four racks, with each distributed workload confined to a single rack in both configurations. This controlled for cross-rack performance differences. Confining distributed workloads to a single rack is not required when the test environment has been validated for equivalent performance across racks. The team measured normalized aggregate and per-instance throughput, time to first token, end-to-end latency, interactivity, GPU, CPU, and rack power telemetry. Comparing these metrics prevents a throughput gain from hiding latency, stability, or power-compliance regressions. Figure 2. The baseline combined two 52-GPU high-throughput instances with one 36-GPU low-latency instance. DSX MaxLPS added a third 52-GPU high-throughput instance, increasing the fleet from 140 to 192 GPUs What the measurements show Table 1 compares capacity, throughput, and power use for the static baseline and DSX MaxLPS configurations. Metric Static baseline DSX MaxLPS Change Managed GPUs 140 192 +37.1% Aggregate throughput 1,084,503 tokens/s 1,618,443 tokens/s +49.2% High-throughput output per instance 59,153 tokens/s 59,220 tokens/s +0.1% Low-latency output per instance 2,265 tokens/s 2,265 tokens/s 0% Mean GPU power 97.0 kW 131.8 kW +35.9% Total measured power 166.2 kW 198.9 kW +19.7% Power-budget utilization 62.9% 75.2% +12.3 percentage points Throughput per provisioned watt 4.10 tokens/s/W 6.12 tokens/s/W +49.2% Table 1. Static baseline and DSX MaxLPS performance and power results Both configurations used the same 264.4 kW provisioned power budget . Throughput per provisioned watt divides normalized aggregate throughput by this fixed denominator. The baseline delivered 4.10 tokens/s/W, and DSX MaxLPS delivered 6.12 tokens/s/W, a 49.2% increase. Because the provisioned-power denominator remained unchanged, this percentage matches the aggregate-throughput increase. The per-instance results remained effectively unchanged at the displayed precision. This shows that the larger managed fleet increased aggregate throughput without materially reducing the throughput of the existing high-throughput or low-latency instances. For latency, P75 is the 75th-percentile result , meaning 75% of requests completed at or below that latency. P99 is the 99th-percentile result , representing tail behavior: 99% of requests completed at or below that latency, while the slowest 1% took longer. Median and P75 latency remained within 5% of baseline. P99 time to first token increased 17% from the 15.7-second baseline, showing the importance of evaluating tail latency alongside capacity and throughput. Figure 3. DSX MaxLPS increased normalized aggregate throughput by 49.2%, from 1.085 million to 1.618 million tokens per second. With the same 264.4 kW provisioned power budget, throughput per provisioned watt increased from 4.10 to 6.12 tokens per second per watt Trade-offs exposed by the evaluation Dynamic power allocation makes engineering trade-offs observable and controllable at the fleet level; it does not eliminate them. Workload mix shapes available headroom DSX MaxLPS uses previously unused headroom, so added capacity still increases average power utilization. The available headroom also depends on the workload mix: complementary power profiles create more opportunity than workloads that peak simultaneously. Operators should therefore test representative production workloads against the aggregate power limit. Typical AI factories run heterogeneous workloads with different power profiles. The study therefore used a workload mix designed to reflect that variability. Tail latency reveals service trade-offs Stable median latency can mask changes in tail latency. In this evaluation, median and P75 latency remained within 5% of baseline, but P99 time to first token increased by 17%. Production acceptance criteria should be defined as part of the study. Telemetry supports reliable control Dynamic allocation depends on reliable telemetry. Missing, delayed, or incorrectly mapped measurements can undermine fleet-level decisions. For this evaluation, site-level telemetry was used to verify rack-level power measurements. Before deployment, operators should confirm that added throughput does not compromise service quality or compliance with power limits. Together, these trade-offs define what operators should validate before deployment. How operators can validate DSX MaxLPS Use a staged validation process with explicit boundaries and acceptance criteria. Define the managed boundary. Map utility, distribution, rack, node, and GPU topology. Set the resource-group budget, reserve requirements, and escalation behavior. Confirm which measurement represents the enforceable limit. Establish a representative baseline. Run the representative AI factory workload mix under static provisioning, using the intended deployment and placement rules. Measure performance and power long enough to capture workload variation and confirm repeatability. Introduce policies conservatively. Begin with limits close to the validated baseline. Confirm telemetry, topology, control response, and budget compliance before adding nodes. Add capacity and test each stage. Increase the managed population incrementally, comparing aggregate and per-instance performance at each step. Before proceeding, verify service behavior under peak demand, operating transitions, telemetry failure, and reduced power availability. Set production operating limits. Approve a configuration only when it meets throughput and latency objectives, stays within the managed budget, preserves the required reserve, and behaves predictably during faults and transitions. This evaluation shows how DSX MaxLPS can reclaim stranded capacity in a power-constrained AI factory. The same policy-governed approach can increase useful compute across diverse environments. Operators can tune the optimal operating point for each deployment based on hardware, workload mix, software, cooling, network topology, and service objectives. Plan the site for the validated operating target Dynamic allocation is an operational capability, but the site must be able to host the capacity it enables. Electrical distribution, cooling, network fabric, floor space, and rack positions should be sized for the validated lifecycle target even if fewer racks are populated on day one. For future NVIDIA Vera Rubin NVL72 AI factories, DSX MaxLPS also combines dynamic power management with performance-per-watt techniques and infrastructure designed for 45°C liquid-cooling inlet operation. Any Vera Rubin capacity projection should remain separate from this measured GB300 NVL72 evaluation. DSX MaxLPS gives operators a framework for turning workload variability into managed capacity. The engineering work is to define the boundary, measure representative behavior, tune policy against service objectives, and prove compliance under both normal and adverse conditions. Review NVIDIA DSX MaxLPS and NVIDIA Dynamic Power Software documentation , then use this validation sequence to establish production operating limits for your own AI factory.