NVIDIA DSX MaxLPS is a set of chip, thermal, system and software technologies from NVIDIA intended to get more AI throughput out of a data center whose power supply is fixed. It is part of the NVIDIA DSX platform for designing and operating what NVIDIA calls AI factories. According to NVIDIA, the name stands for "Maximum Land Power Shell," meaning the site-level limits that bound an AI factory: the land, the utility power, and the physical shell that houses power, cooling, networking and compute.[2] The core idea is power oversubscription: install more GPUs than a static, worst-case power budget would allow, then use software to keep the aggregate draw under the site's limit by adjusting GPU power caps in real time. NVIDIA announced DSX MaxLPS at GTC Taipei on May 31, 2026, saying it would let operators "run up to 40% more GPUs at their most energy-efficient operating point with minimal impact on workload performance."[1]

The software control layer is NVIDIA Dynamic Power Software (DPS), a Kubernetes-based power management service that sets per-GPU power limits through each server's baseboard management controller (BMC) over the Redfish protocol.[4][8] DPS 0.9.0, released September 11, 2026, was what NVIDIA calls the first release of MaxLPS policy-driven dynamic power management, although MaxLPS pilot deployments had already run on DPS 0.8.x.[16] As of October 2026 NVIDIA offers DPS as a Developer Preview and says it should not be used in production except as part of an authorized collaboration.[5] Published results so far come from NVIDIA and its cloud partners, including a Lambda test on HGX B200 servers and an Nscale evaluation on GB300 NVL72 systems in Iceland.[19][3]

Attribute	Detail
Developer	NVIDIA[1]
Part of	NVIDIA DSX platform[1]
Announced	May 31, 2026, GTC Taipei press release[1]
Name	"Maximum Land Power Shell"[2]
Main components	Dynamic power allocation (Dynamic Power Software), performance-per-watt techniques (workload power profiles, APPM), 45 degrees Celsius liquid-cooling and site design[2]
Software control layer	NVIDIA Dynamic Power Software (DPS), Developer Preview[5]
First DPS release with MaxLPS	DPS 0.9.0, September 11, 2026[16]
Latest documented DPS version	0.10 (documentation last updated October 16, 2026)[5][17]
Hardware control path	Per-GPU power limits written to server BMCs over Redfish[4][8]
Pilot hardware	GB200 NVL72 or GB300 NVL72 racks; Vera Rubin NVL72 support added in DPS 0.9.0[7][16]
Headline vendor claim	Up to 40% more GPUs within the same power budget[1][3]

Background: power provisioning and oversubscription

A data center's electrical system is usually sized for the worst case. If every server is budgeted at its nameplate power and all of them could hit that figure at the same instant, the facility can host only as many servers as fit under that sum. In practice, aggregate draw almost never reaches the theoretical peak, so part of the paid-for capacity sits unused. Using that headroom by installing more equipment than the nameplate sum allows, and capping power when demand spikes, is known as power oversubscription.

The idea is older than MaxLPS. In a 2007 paper at the International Symposium on Computer Architecture (ISCA), Google researchers Xiaobo Fan, Wolf-Dietrich Weber and Luiz Andre Barroso studied the power use of groups of up to 15,000 servers over about six months. They found a gap of 7 to 16% between achieved and theoretical aggregate peak power at the cluster level, growing to almost 40% for whole data centers, and argued that this headroom could host additional equipment within the same power budget with minimal risk.[29] Facebook's Dynamo system, described at ISCA 2016, monitored the entire power hierarchy and made coordinated control decisions across Facebook's data centers; the authors reported that it prevented 18 potential power outages in six months and had enabled an 8% increase in the power capacity utilization of one data center.[30] Google's Thunderbolt power-capping system, presented at OSDI 2020, throttled batch work to protect latency-sensitive tasks and enabled oversubscription gains of 9 to 25% in production clusters.[31]

Researchers have since applied the same reasoning to GPU clusters for large language models. In POLCA (2023), Pratyush Patel and colleagues characterized LLM power patterns, concluded that inference clusters leave substantial headroom for oversubscription, and reported in simulation that 30% more servers could be deployed in the same GPU cluster for inference with minimal performance loss. They also noted that the limited GPU telemetry and controls available in virtualized environments make a reliable oversubscription mechanism hard to build.[32]

NVIDIA's own case for MaxLPS follows the same logic. In an illustrative 100 MW AI factory, NVIDIA's technical blog allocates 20 MW to facility overhead, 10 MW to rack losses, and 10 MW to operational inefficiency during failures, restarts and checkpointing, leaving about 60 MW for the AI load. It then argues that static rack provisioning strands part of even that 60 MW, because power reserved for one rack's peak cannot be lent to a neighboring rack that could use it.[2] Training and inference both cycle through phases (compute bursts, memory-bound work, synchronization, checkpointing, prefill, decode and idle gaps) that draw different amounts of power.[2][3]

Name and scope

NVIDIA presents MaxLPS as an extension of two existing GPU power settings. Its documentation describes MaxP as the highest GPU power setting, used to design rack- and row-level power and cooling, and MaxQ as the setting with the best application performance per watt. Both are static and GPU-level. MaxLPS is described as dynamic and factory-wide: it is based on effective average utilized power with stranded power recovered, and NVIDIA says it is used to determine data center sizing and GPU count.[4]

The August 2026 technical blog groups MaxLPS into three parts:[2]

Pillar	What NVIDIA says it does
Dynamic power allocation	Continuously monitors GPU and rack power and allocates unused headroom to other GPUs in the same managed group, using Dynamic Power Software
Advanced performance-per-watt techniques	Workload power profiles and the Application Performance and Power Manager (APPM) tune GPU behavior for inference, training, memory-bound and compute-bound work
45 degrees Celsius thermal efficiency and site design	Warm-water liquid cooling cuts cooling overhead and improves power usage effectiveness, leaving more of the envelope for compute

The DSX documentation adds that MaxLPS works without the other DSX grid and facility components. DSX Flex (grid response) and DSX Exchange (an IT and facility event bus) are not prerequisites, although NVIDIA recommends planning all three together for a new site.[4]

History

Date	Event
May 31, 2026	NVIDIA announces the DSX platform at GTC Taipei, listing DSX MaxLPS among "new open source software" and naming CoreWeave, Crusoe, Firmus, IREN, Lambda, Nebius, Nscale and Yotta Data Services as cloud partners deploying DSX components including MaxLPS[1]
August 24, 2026	NVIDIA Technical Blog publishes "Maximizing AI Factory Performance per Watt with NVIDIA DSX MaxLPS"[2]; the same day Lancium announces an NVIDIA partnership under which it plans to use DSX MaxLPS and DSX Flex on its campuses[24]
August 2026	NVIDIA discusses MaxLPS during its Hot Chips 2026 presentation on the Rubin GPU[23]
September 11, 2026	DPS 0.9.0 released, the first release with MaxLPS policy-driven dynamic power management[16]
September 15, 2026	At the AI Infra Summit, Lambda releases what NVIDIA calls the first validation of DSX MaxLPS on Blackwell servers[19][21]
September 27, 2026	NVIDIA publishes the joint NVIDIA and Nscale evaluation on GB300 NVL72[3]
October 12, 2026	Ian Buck discusses MaxLPS in NVIDIA's opening keynote at the Open Compute Project Global Summit in San Jose[25][28]
By October 16, 2026	Documentation for DPS 0.10, described by NVIDIA as a release candidate, is published; the release adds DSX Exchange and DSX Flex integration, DPS agent authentication and Nautobot import[5][17]

How it works: Dynamic Power Software

NVIDIA describes Dynamic Power Software as a data center power management system that "monitors power consumption, enforces power policies, and integrates with BMCs and cluster management systems."[5] It manages power only. NVIDIA's MaxLPS concept page states that DPS "does not schedule workloads or add facility capacity": the existing workload scheduler (for example Slurm or Kubernetes) keeps placing jobs, and DPS controls how much GPU power the managed nodes may use.[6]

Architecture

DPS is built as a cloud-native set of microservices deployed on Kubernetes with Helm charts. Its main parts are the DPS server, which exposes a gRPC API (with an HTTP/REST gateway) and handles topology, policy and resource-group management; the dpsctl command-line client; a web UI; and a PostgreSQL database for persistent state. Hardware is controlled through BMCs using Redfish over HTTPS, with BMC credentials stored in Kubernetes secrets.[8] A BMC simulator that models NVIDIA DGX systems is included for development, and the SDK simulator can emulate 144 DGX GB300 nodes without data center hardware.[8][5]

A site runs one DPS Core deployment (server, UI, Power Steering, PostgreSQL and SeaweedFS object storage) and one DPS Agent per Compute Data Hall. Each agent collects telemetry from the devices in its hall and applies the power limits DPS sets through their BMCs. DPS sizing guidance is expressed in DSX scalable units (SUs); NVIDIA defines one SU as 14 Vera Rubin NVL72 racks.[9] The DSX MaxLPS overview says DPS runs its control loop "every few seconds" and that millisecond-scale spikes are handled by hardware and electrical protection, not by DPS.[4]

Topology, resource groups and policies

Operators first describe the power distribution network as a topology: power domains, floor and rack power distribution units (PDUs), and compute nodes, each with operating limits. DPS validates every power change against this topology.[6] Fixed loads that DPS does not manage, such as NVSwitch trays, are declared as static load so they still count against rack and domain budgets.[7]

Compute nodes are then placed in a resource group, which carries a policy bundle and optional power-management settings.[11] DPS ships three built-in bundles:[10]

Bundle	Intended behavior (per NVIDIA)
MaxP	Full operating ceiling, proportional dynamic power management with power shifting, Power Reservation Steering off
MaxQ	Model-specific efficiency targets, proportional dynamic power management with power shifting, Power Reservation Steering off
MaxLPS	Model-specific sustained-power targets, proportional dynamic power management with power shifting, Power Reservation Steering on

New DPS 0.9.0 deployments use MaxLPS as the default policy bundle.[16] In the pilot runbook the MaxLPS bundle sets, for a DGX GB300 node, a 4,108 W aggregate GPU target against a 5,600 W GPU ceiling, and for a DGX GB200 node, a 3,648 W target against a 4,800 W ceiling; these are totals for all GPUs in one system, not per-GPU values.[7]

Shared GPU budget and Power Steering

Three resource-group features work together in the MaxLPS configuration: dynamic power management (DPM), which enforces per-node power policy; Power Reservation Steering (PRS), which moves headroom between GPUs based on live telemetry; and Shared GPU mode, which enforces the group's GPU budget as a sum rather than as separate per-node caps. NVIDIA's runbook says all three are required and that Shared GPU is "what makes operating more racks within one envelope possible."[7] Under Shared GPU, one node can take more GPU power while another takes less, as long as the group stays inside its budget; per-GPU hardware minimum and maximum limits still apply and are enforced by the device or BMC.[11]

The current PRS implementation is the DPS Power Steering Controller, which runs as a Config Service and a Controller Service. On each scheduled cycle the controller loads the domain configuration, collects power telemetry and workload allocations, predicts demand, identifies under-allocated and idle devices, and uses a "waterfall allocator" to satisfy each device's minimum before spreading the remaining budget across demand. DPS then validates each proposed limit against policy, topology and hardware constraints before applying it. A GPU with no current power reading keeps its last confirmed limit rather than being treated as idle. The controller interval can be set no lower than 5 seconds, and a headroom setting that adjusts the GPU pool DPS sends to each steering domain defaults to -15 percent.[12]

Excursion handling

If measured power at a device exceeds its limit, DPS runs an excursion mitigation loop. It finds the highest-level devices in excursion, calculates the deficit, and sets a reduction target of twice the deficit by default. It then lowers power on resource groups in order of priority (lower-priority groups first), waits 10 seconds by default for fresh telemetry, and checks again, repeating until the excursion clears or an iteration limit is reached. Power is given back after a successful mitigation on a best-effort basis. DPS raises a PowerExcursion warning per device and an ExcursionMitigationFailed critical alert if it runs out of options.[13]

Provisioned and observed power

NVIDIA's documentation frames MaxLPS around the difference between provisioned power (the sum of power limits in force) and observed power (measured draw). Under static sizing, provisioned power must stay below physical capacity because nothing stops all systems from reaching their limits together. With DPS enforcing limits dynamically, NVIDIA argues that observed power is what must stay under capacity, so a MaxLPS deployment can look "over-provisioned" on paper while operating correctly.[14]

Performance-per-watt techniques and thermal design

Beyond rack-level power steering, MaxLPS includes workload power profiles (WPPS), NVIDIA's pretuned GPU power profiles for operating modes such as inference, training, memory-bound and compute-bound work. The Application Performance and Power Manager applies the chosen configuration to participating GPUs, and NVIDIA says NVIDIA Dynamo can further tune inference serving.[2] DPS exposes WPPS through resource-group settings; the profiles are not supported on GPU architectures before Blackwell.[15]

The thermal pillar relies on Vera Rubin NVL72 racks being designed for 45 degrees Celsius liquid-cooling inlet temperatures. Warmer coolant lets a facility rely more often on free cooling with dry coolers rather than mechanical chillers, which NVIDIA says lowers cooling power and annual power usage effectiveness. If the electrical distribution and controls are sized for it, power budgeted for cooling during the hottest hours can go to compute for much of the year.[2] Tom's Hardware reported NVIDIA saying chillers had consumed as much as 40% of site power in past installations.[23]

NVIDIA also treats MaxLPS as a planning method. Its guidance is to size the site's power distribution, cooling, network and rack positions for the full MaxLPS GPU count from the start, even if a training-heavy day-one workload means fewer racks are installed at first, so that more racks can be added later as the workload mix shifts toward lower-power inference.[2]

For Vera Rubin NVL72, NVIDIA projects that MaxLPS combined with data center power planning could fit 40,000 Rubin GPUs, up to 40% more capacity, in a 100 MW AI factory.[2] Tom's Hardware, covering NVIDIA's Hot Chips presentation, judged the associated performance figures to be estimates rather than measurements.[23] The DSX documentation labels its own illustrative Vera Rubin scenario (1.35 times the token throughput of MaxP) as one in which "Vera Rubin testing remains in progress."[4]

NVIDIA projection for a 100 MW AI factory with MaxLPS and power planning[2]	Value
Rubin GPUs	40,000
NVFP4 inference	2 zettaflops
NVFP4 training	1.4 zettaflops
HBM4 memory capacity	11 petabytes
HBM4 memory bandwidth	800 petabytes per second

Reported results

Every result listed below was published by NVIDIA or by a partner working with NVIDIA.

Test	Hardware and workload	Reported result
NVIDIA internal[2]	GB200 NVL72 with Kimi K2.5	Provisioned rack power cut from 125 kW to 90 kW, 39% more racks in the same envelope, about 1.5x performance per watt
NVIDIA internal[2]	Rack with DeepSeek-R1 (see note below)	Provisioned rack power cut from 136 kW to 101 kW, 35% more racks, 1.3 to 1.4x performance per watt
Lambda[19][20]	Five-rack, 19-node HGX B200 cluster, MLPerf inference and training workloads	19 nodes at an 85% power policy in the budget of 16 full-power nodes; cluster token throughput up 24% (about 4.04 million to 5 million tokens per second); performance per watt up 23%
Lambda, mixed workloads[20]	10 inference and 10 training nodes at an 80% policy	Training cluster throughput up 17%, inference cluster throughput up 20%
Nscale[3]	GB300 NVL72, Kimi K2.5 in FP4, 140 GPUs vs 192 GPUs	Aggregate throughput up 49.2% in the same 264.4 kW budget

NVIDIA's own sources describe the DeepSeek-R1 rack inconsistently. The August blog text says Vera Rubin NVL72 was tested with DeepSeek-R1, while the accompanying figure caption names GB200 NVL72 and GB300 NVL72 systems.[2] Tom's Hardware reported the 136 kW to 101 kW result as a GB300 system, with typical GPU power falling from 1,400 W to 1,000 W.[23]

Lambda

Lambda, a GPU cloud provider, ran DPS on HGX B200 servers and tested power targets of 80% and 85% of maximum draw, which cut per-node consumption enough to bring extra nodes online.[20] Dave Ward, Lambda's president of cloud services, said: "With our proof of concept, we believe we've moved beyond the limitation of fixed power budgets."[19] NVIDIA's case study says Lambda's feedback helped refine MaxLPS power-observability dashboards and contributed to configurable power-shaping controls that NVIDIA says will be available within MaxLPS.[20] The Register, reporting from the AI Infra Summit, described MaxLPS as "an evolution of an old idea."[22]

Nscale

The Nscale evaluation took place at Nscale's data center on the Verne campus in Keflavik, Iceland. Nscale deployed the software and collected telemetry while NVIDIA ran the workloads, which used Blackwell Ultra GPUs, Kimi K2.5 in FP4, NVIDIA Dynamo and TensorRT-LLM with 8K input and 1K output sequence lengths. The static baseline used 35 four-GPU nodes running two 52-GPU high-throughput instances and one 36-GPU low-latency instance; the MaxLPS configuration used 48 nodes and added a third high-throughput instance.[3]

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 points
Throughput per provisioned watt	4.10 tokens/s/W	6.12 tokens/s/W	+49.2%

Source: NVIDIA Technical Blog, September 27, 2026.[3]

Median and 75th-percentile latency stayed within 5% of the baseline, but 99th-percentile time to first token rose 17% from a 15.7-second baseline. NVIDIA's write-up says this shows the need to evaluate tail latency alongside capacity gains, and that the measured GB300 results should be kept separate from any Vera Rubin projection.[3]

The MaxLPS power pilot

NVIDIA publishes a runbook for customers to test MaxLPS on their own hardware. The pilot asks whether four managed racks can deliver more aggregate inference throughput than a three-rack baseline inside the same facility power envelope.[7]

Pilot element	Specification in the runbook[7]
Hardware	Four GB200 NVL72 or GB300 NVL72 racks, 18 compute nodes each (72 nodes)
Power envelope	The three-rack envelope, applied across all four racks: 375 kW for GB200 NVL72, 405 kW for GB300 NVL72
Unmanaged load	NVSwitch trays declared as static load: 7,416 W per GB300 NVL72 rack, 11,160 W per GB200 NVL72 rack
Baseline run	3 racks (54 nodes), DPS out of the control path
Managed run	4 racks (72 nodes), MaxLPS bundle with DPM, Power Steering and Shared GPU enabled
Workload	At least two representative inference jobs, one low-power and one high-power; training jobs and synthetic stress tools are excluded
Comparison window	At least one hour of running, with a contiguous steady-state window of at least 30 minutes

Before the managed run, every BMC must pass a health check covering Redfish reachability, firmware, power-limit write and read-back, and telemetry sampling. NVIDIA's readiness targets are median BMC latency below 0.5 seconds, 95th percentile below 0.7 seconds and 99th percentile below 0.8 seconds, and it recommends no more than four BMC client connections per GB200 or GB300 system, two of them used by DPS.[7] GB200 and GB300 systems need BMC firmware 25.0.0 or later.[33]

A pilot passes only if it shows zero new power-compliance events, aggregate output tokens per second strictly greater than the baseline, an error rate within 0.1 percentage points of the baseline, and observed power at or below the binding constraint for essentially all steady-state samples.[7] For later tuning the runbook describes an optional OverProvisioningPercentage field on the topology's power domain, where the provisioning limit equals the operating limit times (1 + percentage/100), and advises staying within roughly 10% of the true electrical or contractual limit when first pushing outward.[7]

Statements by NVIDIA executives

Ian Buck, NVIDIA's vice president of hyperscale and high-performance computing, promoted MaxLPS at the 2026 OCP Global Summit.[25][26] In the Key Context interview he put the GPU increase from MaxLPS at Nscale and Lambda at 33% and the resulting revenue gain at 50%.[26] According to a transcript of his keynote published by Fireside Alpha, he called MaxLPS one of the DSX components he was "most proud of" and said that by deploying it Nscale had put "37 more GPUs" into its Iceland data center and grown "their revenue, their token throughput, by 50%."[27] NVIDIA's published Nscale figures are a 37.1% increase in GPU count (140 to 192 GPUs) and a 49.2% increase in aggregate throughput.[3]

In an interview with Tae Kim, published in his Key Context newsletter on October 15, 2026 and conducted at the summit, Buck described MaxLPS as software that "taps directly into the power monitor BMCs at every GPU, every compute tray, and every rack" and said it also "taps into the scheduler to route work to where there's power." He said NVIDIA had open-sourced the software and that "pretty much every NCP is now adopting a MaxLPS strategy." He added: "I don't think it's been fully recognized by your audience that the opportunity for incremental demand in existing data centers today, without retiring any GPUs, is another 30% to 40% of GPUs. Whether that's been modeled in, I doubt it." Kim's bracketed note in the transcript reads "He means investors!"[26] In a post on X the same day, Kim wrote that Buck was "calling out Wall Street for failing to model the upside of MaxLPS."[34]

Buck's description of scheduler integration goes beyond the scheduler-independent configuration in NVIDIA's pilot runbook, in which DPS does not place work. DPS does offer an API through which workload schedulers can manage resource groups.[6][7]

Licensing and availability

NVIDIA's May 2026 press release lists DSX MaxLPS among "new open source software" added to DSX.[1] The DPS 0.10 documentation, however, presents DPS as a Developer Preview whose use is governed by Developer Preview guidelines, and its license page is an NVIDIA Software License Agreement; client and server packages are distributed through NVIDIA NGC.[5][18][7] The press release also states that many DSX products and features "will be offered on a when-and-if-available basis."[1]

Limitations

NVIDIA's documentation and partner reports list several caveats:

Gains depend on workload mix. Complementary power profiles (for example bursty training next to steadier inference) leave more headroom than workloads that peak at the same time.[3][20]
Tail latency can rise. The Nscale test saw a 17% increase in 99th-percentile time to first token.[3]
The method depends on telemetry. Missing, delayed or mis-mapped readings can undermine fleet-level decisions, and NVIDIA used site-level telemetry to verify rack readings in the Nscale test.[3]
DPS reacts on a scale of seconds; very fast transients rely on hardware and electrical protection.[4]
NVIDIA describes its "up to 40%" figure as a planning rule of thumb and tells operators to validate it with their own workload measurements and compliance requirements.[6]

References

NVIDIA Newsroom. "NVIDIA DSX Gives Infrastructure Builders the Playbook for AI Factories." May 31, 2026. https://nvidianews.nvidia.com/news/dsx-infrastructure-ai-factory
Sarah McKenney and Harry Petty. "Maximizing AI Factory Performance per Watt with NVIDIA DSX MaxLPS." NVIDIA Technical Blog, August 24, 2026. https://developer.nvidia.com/blog/maximizing-ai-factory-performance-per-watt-with-nvidia-dsx-maxlps/
Sarah McKenney and Harry Petty. "How NVIDIA DSX MaxLPS Maximizes AI Factory Throughput and Efficiency." NVIDIA Technical Blog, September 27, 2026. https://developer.nvidia.com/blog/how-nvidia-dsx-maxlps-maximizes-ai-factory-throughput-and-efficiency/
NVIDIA. "NVIDIA DSX MaxLPS Overview." NVIDIA DSX Documentation. https://docs.nvidia.com/dsx/maxlps/overview
NVIDIA. "NVIDIA Dynamic Power Software" (documentation home, version 0.10). Last updated October 16, 2026. https://docs.nvidia.com/datacenter/dps/versions/0.10/index.html
NVIDIA. "MaxLPS Power Management." NVIDIA Dynamic Power Software documentation, version 0.10. https://docs.nvidia.com/datacenter/dps/versions/0.10/guides/concepts/maxlps-power-management.html
NVIDIA. "Run the MaxLPS Power Pilot." NVIDIA Dynamic Power Software documentation, version 0.10. https://docs.nvidia.com/datacenter/dps/versions/0.10/guides/runbooks/maxlps-simple-mode-pilot.html
NVIDIA. "DPS Architecture." NVIDIA Dynamic Power Software documentation, version 0.10. https://docs.nvidia.com/datacenter/dps/versions/0.10/sdk/administrator/operations/architecture.html
NVIDIA. "System Requirements." NVIDIA Dynamic Power Software documentation, version 0.10. https://docs.nvidia.com/datacenter/dps/versions/0.10/guides/installation/system-requirements.html
NVIDIA. "Power Policies." NVIDIA Dynamic Power Software documentation, version 0.10. https://docs.nvidia.com/datacenter/dps/versions/0.10/guides/concepts/power-policies.html
NVIDIA. "Resource Groups." NVIDIA Dynamic Power Software documentation, version 0.10. https://docs.nvidia.com/datacenter/dps/versions/0.10/guides/concepts/resource-groups.html
NVIDIA. "DPS Power Steering Controller." NVIDIA Dynamic Power Software documentation, version 0.10. https://docs.nvidia.com/datacenter/dps/versions/0.10/guides/concepts/power-reservation-steering.html
NVIDIA. "Excursion Mitigation." NVIDIA Dynamic Power Software documentation, version 0.10. https://docs.nvidia.com/datacenter/dps/versions/0.10/guides/concepts/excursion-mitigation.html
NVIDIA. "Provisioned and Observed Power." NVIDIA Dynamic Power Software documentation, version 0.10. https://docs.nvidia.com/datacenter/dps/versions/0.10/guides/concepts/provisioned-vs-observed-power.html
NVIDIA. "Workload Power Profiles Settings." NVIDIA Dynamic Power Software documentation, version 0.10. https://docs.nvidia.com/datacenter/dps/versions/0.10/guides/concepts/workload-power-profiles.html
NVIDIA. "DPS 0.9.0 Release Notes." Release date September 11, 2026. https://docs.nvidia.com/datacenter/dps/versions/0.10/release-notes/0.9.x/index.html
NVIDIA. "DPS 0.10 Release Notes." https://docs.nvidia.com/datacenter/dps/versions/0.10/release-notes/0.10.x/index.html
NVIDIA. "NVIDIA Software License Agreement: NVIDIA Dynamic Power Software." https://docs.nvidia.com/datacenter/dps/versions/0.10/license/index.html
NVIDIA Blog. "From Megawatts to Tokens: How NVIDIA Maximizes AI Factory Production." September 15, 2026. https://blogs.nvidia.com/blog/from-megawatts-to-tokens-how-nvidia-maximizes-ai-factory-production
NVIDIA. "Lambda Boosts AI Factory Efficiency With DSX MaxLPS" (customer case study). https://www.nvidia.com/en-us/case-studies/lambda/
NVIDIA Blog. "AI Infra Summit: NVIDIA Vera Rubin and DSX Platform Advances Showcase Energy Efficiencies of Optimizing Tokens Per Watt for AI Factories." September 15, 2026. https://blogs.nvidia.com/blog/ai-infra-summit-vera-rubin-dsx-energy-efficiencies-tokens-per-watt-ai-factories/
Tobias Mann. "Nvidia goes green to keep grid capacity from zapping its revenues." The Register, September 16, 2026. https://www.theregister.com/systems/2026/09/16/nvidia-goes-green-to-keep-grid-capacity-from-zapping-its-revenues/5296984
Jeff Kampman. "Hot Chips 2026: Nvidia touts benefits of its DSX MaxLPS site power management approach." Tom's Hardware, August 26, 2026. https://www.tomshardware.com/tech-industry/data-centers/hot-chips-2026-nvidia-touts-benefits-of-its-dsx-maxlps-site-power-management-approach-tech-allows-for-more-compute-from-fixed-data-center-power-budgets
David Chernicoff and Matt Vincent. "NVIDIA Pushes DSX Deeper Into Data Center Infrastructure." Data Center Frontier, September 10, 2026. https://www.datacenterfrontier.com/hyperscale/article/55402883/nvidia-pushes-dsx-deeper-into-data-center-infrastructure
Matt Vincent. "OCP 2026: Agentic AI Pushes the Data Center from Chip to Grid." Data Center Frontier, October 13, 2026. https://www.datacenterfrontier.com/hyperscale/article/55411534/ocp-2026-agentic-ai-pushes-the-data-center-from-chip-to-grid
Tae Kim. "An Interview with Nvidia's Ian Buck on Why GPUs Keep Winning." Key Context, October 15, 2026. https://taekim.substack.com/p/an-interview-with-nvidias-ian-buck-975
Fireside Alpha. "[OCP'26] NVIDIA's Ian Buck: 'AI Factories at Scale: Advancing Open Infrastructure for Agentic AI'." October 14, 2026. https://firesidealpha.substack.com/p/ocp26-nvidias-ian-buck-ai-factories
Open Compute Project. "2026 OCP Global Summit." October 12-15, 2026, San Jose, California. https://www.opencompute.org/events/ocp-summit/2026-ocp-global-summit
Xiaobo Fan, Wolf-Dietrich Weber and Luiz Andre Barroso. "Power Provisioning for a Warehouse-sized Computer." Proceedings of the 34th International Symposium on Computer Architecture (ISCA), 2007. https://doi.org/10.1145/1250662.1250665
Qiang Wu, Qingyuan Deng, Lakshmi Ganesh, Chang-Hong Hsu, Yun Jin, Sanjeev Kumar, Bin Li, Justin Meza and Yee Jiun Song. "Dynamo: Facebook's Data Center-Wide Power Management System." 2016 ACM/IEEE 43rd International Symposium on Computer Architecture (ISCA), 2016. https://doi.org/10.1109/ISCA.2016.48
Shaohong Li, Xi Wang, Xiao Zhang, Vasileios Kontorinis, Sreekumar Kodakara, David Lo and Parthasarathy Ranganathan. "Thunderbolt: Throughput-Optimized, Quality-of-Service-Aware Power Capping at Scale." 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2020. https://www.usenix.org/conference/osdi20/presentation/li-shaohong
Pratyush Patel, Esha Choukse, Chaojie Zhang, Inigo Goiri, Brijesh Warrier, Nithish Mahalingam and Ricardo Bianchini. "POLCA: Power Oversubscription in LLM Cloud Providers." arXiv:2308.12908, August 2023. https://arxiv.org/abs/2308.12908
NVIDIA. "BMC Readiness and Health Guide." NVIDIA Dynamic Power Software documentation, version 0.10. https://docs.nvidia.com/datacenter/dps/versions/0.10/guides/runbooks/bmc-readiness-and-health.html
Tae Kim (@firstadopter). Post on X, October 15, 2026. https://x.com/firstadopter/status/2110765424191361151

Editing: NVIDIA DSX MaxLPS