How NVIDIA DSX MaxLPS Maximizes AI Factory Throughput and Efficiency

AI factories operate within a hierarchy of electrical limits: from utility supply, substations, and distribution equipment to racks, nodes, and GPUs, each layer forms a constraint. Operators must stay compliant within every managed boundary while meeting the application's throughput and latency targets.

Static power planning typically reserves enough power for each node so that all of them can reach nominal peak at the same moment. This approach is simple and direct, but AI workloads rarely stay pinned at maximum: training workloads move among compute, communication, synchronization, and checkpointing, while inference workloads alternate among prefill, decode, memory-intensive tasks, network activity, and idle time; even instances of the same model show different power curves as request shape and concurrency change.

This fluctuation leaves a gap between "reserved peak" and "actual consumption." Under static per-node reservation, unused capacity in one reservation cannot be transferred to another node, so the facility as a whole may remain below its ceiling while additional GPU capacity sits offline. NVIDIA's DSX MaxLPS, introduced in a developer blog, targets exactly this gap: it monitors actual power draw and dynamically redistributes available power among participating resources while preserving the operator's aggregate budget and policy boundaries.

As NVIDIA describes it, DSX MaxLPS combines chip, system, thermal, and software technologies with the goal of maximizing AI factory output within land, power, and shell (LPS) constraints, with its control layer provided by Dynamic Power Software. The control process contains five technical elements: first, topology and resource groups, where the operator maps the participating infrastructure and organizes nodes into a managed group with an aggregate power budget; second, telemetry, where the system collects GPU, node, rack, and group-level power data at intervals sufficient to detect available headroom and emerging power events; third, policy, where the operator defines node caps, group caps, allocation priorities, reservation requirements, and responses to maintenance or emergency events; fourth, allocation and control, where when some resources consume below their allocation, the software adjusts the power caps of participating GPUs so that other resources can use that capacity; and fifth, validation and enforcement, where the system compares measured power against the approved group budget and adjusts allocations as consumption approaches the ceiling.

There is a boundary here that must be drawn explicitly: NVIDIA stresses this is coordinated allocation, not adding site power. The control loop merely lets the same managed power budget produce more useful work. In other words, what it changes is the way power is allocated inside the budget, not the size of the budget itself.

The evaluation was conducted jointly by NVIDIA and Nscale: Nscale deployed the MaxLPS software and collected telemetry at its data center in the Verne campus in Keflavík, Iceland, while NVIDIA ran the workload. That data center is powered entirely by renewable energy.

The evaluation environment was a specific configuration: NVIDIA Blackwell Ultra GPUs, Kimi K2.5 at FP4 precision, NVIDIA Dynamo, and NVIDIA TensorRT LLM, with an input sequence length of 8K and an output sequence length of 1K. The workload mix included both high-throughput and low-latency inference instances, thereby creating different power and service profiles within the same managed group.

The two configurations sit under the same 264.4 kW configured power budget. The static baseline used 35 four-GPU nodes, 140 GPUs in total, running two 52-GPU high-throughput instances and one 36-GPU low-latency instance; the DSX MaxLPS configuration used 48 four-GPU nodes, 192 GPUs in total, adding a third 52-GPU high-throughput instance while retaining the same 36-GPU low-latency instance.

There is also a controlled condition that is easy to overlook: under both configurations the jobs ran across four racks, and each distributed workload was confined to a single rack to control cross-rack performance variation. NVIDIA also notes that in test environments where cross-rack performance equivalence has been verified, this confinement is not required.

The number of hosted GPUs rose from 140 to 192, an increase of 37.1%. Aggregate throughput rose from the baseline's 1,084,503 tokens/s to 1,618,443 tokens/s, a gain of 49.2%. Throughput per configured watt rose from 4.10 to 6.12 tokens/s/W, also a 49.2% gain.

It is worth noting where the increment came from. The per-instance output of the high-throughput instance went from 59,153 tokens/s to 59,220 tokens/s, only +0.1%; the per-instance output of the low-latency instance held unchanged at 2,265 tokens/s. In other words, the rise in aggregate throughput did not come from any single instance running faster, but from running one additional 52-GPU high-throughput instance within the same budget.

The change on the power side is equally clear: average GPU power rose from 97.0 kW to 131.8 kW (+35.9%), total measured power rose from 166.2 kW to 198.9 kW (+19.7%), and power budget utilization rose from 62.9% to 75.2%, an increase of 12.3 percentage points. Under the baseline configuration, budget utilization was only a little over sixty percent, which is a direct manifestation of static reservation stranding available power.

The gains are not unconditional. The evaluation shows that median and P75 latency stayed within 5% of baseline, but P99 time to first token increased 17%. NVIDIA therefore notes that tail latency needs to be evaluated alongside the capacity gains.

This means that if a service's class objectives are defined by tail latency rather than the median, then the 49.2% throughput gain cannot be directly converted into deliverable service capacity. The evaluation itself did not quantify the impact of this 17% P99 increase on actual production service levels, which remains an unanswered question.

The metrics measured by the evaluation team included normalized aggregate throughput and per-instance throughput, time to first token, end-to-end latency, interactivity, and GPU, CPU, and rack power telemetry. NVIDIA's explanation is that comparing these metrics together prevents throughput gains from masking regressions in latency, stability, or power compliance.

The path to deployment NVIDIA gives is a five-stage validation process: define the management boundary; establish a representative baseline; introduce policy conservatively; scale up gradually and test at each stage; and set the production operating ceiling only after all objectives are met. The purpose of this process is to turn "dynamic allocation" from a demonstration into a reproducible operational method.

But the confirmed measured results must be kept separate from the vendor's claimed potential. NVIDIA says DSX MaxLPS can let customers deploy up to 40% more GPUs within the same approved power budget, whereas the GPU increase in this measured test was 37.1%; the two are not equivalent.

The more critical qualification is this: all data come from the joint evaluation by NVIDIA and Nscale, and NVIDIA is the provider of DSX MaxLPS, so the results are vendor self-reported and lack independent third-party reproduction or verification. The conclusions also do not apply to cases where the power budget changes, because both configurations ran within the same 264.4 kW budget. In addition, it remains unclear whether the throughput-latency tradeoff is consistent under different models, sequence lengths, or workload mixes; the effectiveness and time required for the five-stage validation process in real production environments have not been given; and the solution's behavior under non-renewable energy supply or different electrical hierarchy constraints has not been evaluated.