MaxLPS Power Management#

MaxLPS asks whether a fixed facility power budget can deliver higher aggregate inference throughput by operating more GPUs inside that budget than static, per-rack sizing would allow. DPS continuously reconciles aggregate draw against the agreed operating envelope.

Inference workloads rarely sustain peak GPU power draw. MaxLPS uses that headroom to operate more compute while keeping aggregate draw within the facility envelope. A common planning rule of thumb is up to 40% more compute than static power sizing would allow. Validate that assumption with your own workload measurements and power-compliance requirements.

Compared with an unmanaged baseline, a successful managed run increases aggregate token throughput or your primary tokens-per-second KPI, maintains an acceptable latency impact, and complies with the operating envelope throughout the steady-state window.

Before you enable DPS power control, complete the BMC Readiness and Health Guide for every managed node.

How DPS Enables MaxLPS#

DPS combines a power boundary, a managed compute group, and live power control. It does not schedule workloads or add facility capacity. Your workload scheduler continues to place work, while DPS controls the GPU power available to the compute nodes that you place in the pilot resource group.

  1. Topology sets the facility boundary. The pilot topology models the four racks beneath a PowerDomain. Its OperatingLimit is the same facility power envelope used for the three-rack baseline. DPS validates power changes against this topology boundary. Refer to Topologies.

  2. A resource group identifies the managed compute. An active resource group contains the pilot’s compute nodes and applies their effective power policies. Dynamic power management enforces those policies. Shared GPU pools the policy-derived GPU budget across the group, rather than treating each node as an independent static cap. Refer to Resource Groups.

  3. The default MaxLPS bundle defines the allowed range. The pilot selects the MaxLPS bundle when it creates the resource group. The bundle supplies model-scoped power limits that DPS uses for dynamic power management and Power Steering. Do not replace it with a pilot-specific bundle. Refer to Power Policies.

  4. Power Steering adjusts the split of that budget. The controller uses live telemetry and workload allocation data to propose per-GPU limits. DPS validates each proposal against effective policy, topology constraints, the shared-GPU budget, and hardware limits before applying it. Refer to DPS Power Steering Controller.

The result is dynamic allocation within a fixed budget: GPUs with demand can receive more of the resource group’s available power while other GPUs receive less. Neither Power Steering nor a resource group can exceed the topology envelope or the policy and hardware limits that DPS enforces.

Scheduler-Independent Configuration#

Workload schedulers, such as Slurm and Kubernetes, own workload placement. Provisioning systems own fleet membership and hardware lifecycle. DPS can integrate with those systems through the nvidia.dcpower.v1 resource group API and matching dpsctl resource-group commands. Refer to Managing Resource Groups for that integrated lifecycle.

The MaxLPS pilot runbook uses a scheduler-independent configuration. You manage the resource group outside the workload scheduler and provisioning system, while inference continues through your existing tooling. This configuration uses:

  • A topology that models the four racks and the operating power domain.

  • A resource group containing every compute node, with these capabilities:

    • Dynamic power management, which enforces per-node power policy.

    • Power Steering, which redistributes headroom based on live telemetry. Refer to DPS Power Steering Controller.

    • Shared GPU, which enforces the GPU budget as a group sum rather than separate per-node limits. Refer to Shared GPU Budget.

All three capabilities are required for the pilot configuration. If one is missing, the managed comparison is not reproducible.