NVIDIA DSX for power engineers: what the AI factory playbook asks of the grid

The program in one table

Unlike the Open Compute specs, DSX is one vendor's playbook rather than a consortium agreement. But it is the vendor whose racks set the load, and since the Vera Rubin reference design launched in March 2026 it has grown a set of components that each touch the electrical system:

The reference one-line

The public facilities reference design overview describes the electrical path in more detail than most developers share at a first utility meeting:

• Service substation taking transmission above 100 kV (the glossary assumes 230 kV), stepping to a 34.5 kV backbone through 2,500 A, 40 kA switchgear in AIS or GIS. Two buses in that switchgear separate the network core from GPU compute, because they carry different availability objectives.
• Four main switchgears in N+1, medium-voltage switchboards fed in a loop with one end normally closed and the other normally open, 34.5/0.48 kV transformers at the buildings, and a separate 4.16 kV bus for chillers.
• Central standby generators in N+2 at 34.5 kV, and the BESS on the same 34.5 kV bus as a buffer between the AI load and the grid.
• UPS only for the core network and indoor mechanical equipment. Primary GPU compute is not UPS-backed, and neither is the GPU-side cooling plant.

The sizing example is a 250 MW-class design: 240 MW of compute IT and mechanical load, 22.8 MW of core load, 1,536 GPU racks, and 110,592 GPUs, with cabinet TDPs from 198 kW up to 330 kW for Vera Rubin NVL72. For a worked partner version, Siemens has published a 136 MW facility (100 MW IT) fed from a 34.5 kV utility connection.

The no-UPS-on-compute decision is the one to dwell on. With no double-conversion UPS between the GPUs and the grid, what the utility sees during a fault is set by the rack power supplies and the 34.5 kV BESS—nothing else. That makes the BESS qualification below, and the PSU firmware discussed in the OCP ride-through spec, the whole ride-through story.

Twelve tests for a battery

The BESS qualification tests are the most substantive power-system document in DSX, and they read like they were written by someone who has debugged an inverter plant on a weak grid. The qualification boundary is the BESS AC terminals, power conversion system included; battery chemistry and sizing are out of scope, and NVIDIA is clear that passing does not replace site-level engineering.

Condensed from NVIDIA's published test list. Several values—ramp magnitudes, current limits, ride-through curves—are vendor-declared or deferred to IEEE 2800 and the governing utility, not fixed by NVIDIA.

What stands out:

• The weak-grid test is the gate. Test 5 runs the EMT model at SCR 2.0 across X/R from 2 to 10, and failure there disqualifies the product no matter how it behaves at SCR 20. That is a stricter stance than many interconnection studies take.
• A load-side battery is held to a generator-side standard. Ride-through is judged against IEEE 2800—the inverter-based resource standard—or the utility envelope, whichever governs.
• No black boxes. Test 12 requires a runnable EMT model, full dq impedance scans, Nyquist or passivity evidence at SCR 2 and 20, and the actual controller parameters: droop, virtual impedance, inertia, PLL. Encrypted models are acceptable only if they run and let you change the grid and load around them. If you have ever been handed an unrunnable vendor model a month before energization, this list is worth stealing for your own storage specifications.
• One battery, several jobs, and an energy budget. Tests 6 and 11 force the vendor to show demand response cannot drain the reserve held for ride-through and AI buffering, over 24 hours, with a declared state machine. NVIDIA spells out that a bigger battery is not a substitute for control logic.
• Islanding and black start are in scope. Tests 8–10 assume the site may run as a microgrid with gas generation following a grid-forming battery. That matches the “bridge power” model NVIDIA and Emerald AI are promoting with AES, Constellation, Invenergy, NextEra, and Vistra: bring the factory up on onsite generation and storage before the full interconnection is ready.

Who handles which timescale

AI training loads swing in lockstep across thousands of GPUs. DSX answers that with a stack of mechanisms, and the clearest way to read it is by timescale. The layering below is our synthesis of the NVIDIA documents, not a table NVIDIA publishes:

MaxLPS: less headroom between contract and demand

Traditional data center provisioning allocates every rack for its credible peak, so real demand sits well below the contracted capacity. MaxLPS is built to reclaim that stranded headroom: size local distribution for each rack's maximum (the overview uses 227 kW per Vera Rubin rack as its allocation basis), then let software reallocate power so more racks fit in the same envelope. NVIDIA projects up to 40% more GPUs for Vera Rubin NVL72 in suitable deployments; a Lambda trial running 19 nodes at an 85% power policy, instead of 16 at full power, produced 24% more token throughput on the same facility budget.

For a planner, the consequence is straightforward. A MaxLPS site is designed to run close to its power budget, so the diversity margin you may be used to assuming for data centers is exactly what is being engineered away. NVIDIA presents the upside to utilities just as plainly: a site that can flex reliably is easier to approve, which “can mean more approved megawatts, or power sooner.”

DSX Flex: what a utility signal looks like

DSX Flex turns a grid or program requirement into a Load Target Set: a time-bound power limit on one or more feeds, published by a grid-services provider over MQTT as a signed CloudEvents message. The factory decides how to meet it and streams back its operating state. A few details matter if you are designing a program around it:

• No native ramp rate yet. In schema 1.7.0 a ramp is approximated by publishing staged targets; a native field is planned for Q1 2027, and breach alerts for Q4 2026.
• Status is not settlement. NVIDIA says outright that the power-state stream is “not a complete utility-compliance record”—site metering and program evidence decide compliance.
• No utility protocol is named. There is no OpenADR or IEEE 2030.5 mapping; a grid-services provider such as Emerald AI sits in between.
• Onsite resources are outside the contract. Generators and BESS behind a microgrid controller change the grid draw, but Flex does not define a control interface for them.

The field evidence is early but real. In Phoenix, a 256-GPU cluster held a 25% power reduction for three hours during peak grid events with software alone. In Santa Clara, NVIDIA's Eos system answers Silicon Valley Power's Flexible Load Interconnect Program in under a minute—one August event took it from 4 MW to 3 MW—across more than 200 signals. The first dedicated DSX Flex deployment is planned for a 96 MW Vera Rubin factory in Manassas, Virginia. That is the same region where, as covered in our OCP post, data center load has dropped off the grid during faults three times in two years.

Questions for a DSX-based interconnection

• Is the BESS DSX Ready-qualified, and will you share the Test 5 and Test 12 package—the runnable EMT model and impedance scans—for the interconnection study?
• With no UPS on compute, what are the PSU ride-through settings and firmware revision, and how do they coordinate with the BESS ride-through mode?
• What SOC reserve is held for ride-through, and which state machine wins when DR and a fault coincide?
• What ramp-up cap and ramp-down rate are configured for job start and stop, and who can change them after commissioning?
• Will the site run MaxLPS? If so, model demand near the contract value, not at a historical load factor.
• Is there onsite generation for bridge power, and what is the islanding and resynchronization sequence at the point of interconnection?