NVIDIA DSX Flex Overview

View as Markdown

What Is NVIDIA DSX Flex?

Participation in a utility or energy program can require an AI factory to operate within a power limit for a defined period. Meeting that requirement can involve workloads, facility equipment, and onsite energy systems that are managed through separate controls.

NVIDIA DSX Flex provides a common model for coordinating the power requirement across grid-facing and AI factory systems. It covers the requested limit and timing, the factory’s reported operating state, and exceptions without transferring control of the factory response.

The published integration surface for this model is the versioned DSX Flex Power Management Schema. It defines how a grid-facing provider expresses the requirement and how factory-side systems report their operating state or signal an exception.

NVIDIA DSX Exchange carries these Flex messages between participants. The grid-facing provider states the requested limit, while factory-side systems determine how to meet it using the workload, power, facility, and infrastructure controls available in the deployment.

Who Is NVIDIA DSX Flex For?

Grid-facing providers use Flex to express utility or energy-program requirements as load targets and observe the factory’s reported power state and outcomes. The schema identifies this participant role as the Grid ISV (independent software vendor).

NVIDIA Cloud Partners (NCPs) and other AI factory solution providers are responsible for coordinating the response within the factory. Their systems determine how to operate within the target, report the resulting state, and signal exceptions. For NCPs, this supports meeting power commitments while keeping available power directed to token-producing workloads.

A site response may also involve energy-management systems, microgrid controls, battery energy storage systems (BESS), onsite energy, and facility metering. These systems and their providers can shape the flexibility available to the AI factory and how the result is measured, even when their interfaces are outside the current Flex schema.

How NVIDIA DSX Flex Fits into DSX

A factory’s response to a power target involves systems with different responsibilities. The following representative system map places DSX Flex, Exchange, and MaxLPS alongside the energy, facility, and workload systems that shape the site’s power response. The participants and control paths vary by deployment.

AI factory system map showing a Grid ISV, onsite energy systems, facility systems, workload orchestration, and power management. DSX Exchange carries separate Flex and BMS schema paths to factory-side systems, including DPS in MaxLPS. GPU racks and Intelligent Power Smoothing (IPS) appear in the power-management area. A key distinguishes MQTT, gRPC, HTTPS pull, and power-control links.

Scroll horizontally to inspect the complete system diagram.

DSX Flex, Exchange, and MaxLPS

The DSX software families serve distinct roles in this system:

  • NVIDIA DSX Flex defines shared power intent, timing, scope, reported state, and exception semantics used across the grid-facing boundary.
  • NVIDIA DSX Exchange provides the communication and integration layer that carries Flex events and other operational information across the AI factory.
  • NVIDIA DSX MaxLPS combines site and facilities design, NVIDIA Dynamic Power Software (DPS), and performance-per-watt techniques. DPS manages power for configured GPU and rack groups on the factory side.

These families are presented together to show how their responsibilities connect, not as one required product stack. An NCP can combine NVIDIA and partner components, provided the deployment supplies the communication and factory-side power-management capabilities needed for the response.

Exchange carries Flex events and facility information through distinct schemas, including the building management system (BMS) schema.

Onsite Energy and Storage

Flex targets can apply to a site-defined power scope, while the power drawn from the grid also reflects facility loads and any onsite generation or storage.

Onsite generators, renewables, and BESS are grouped with a microgrid controller because local controls can coordinate these sources and storage. They can change how much power the site draws from the grid. The current Flex contract does not define their control interface.

Facility Systems

The facility area covers power distribution, cooling, meters, and the systems that operate them. A mechanical, electrical, and plumbing (MEP) ISV represents partner software that can use IT and BMS signals to optimize power or cooling. For the facility information path, refer to the BMS Integration Companion Guide.

Workloads and Compute Power Management

On the compute side, orchestration determines which workloads run on IT infrastructure. DPS manages power allocated to GPU and rack groups against the target. On supported Vera Rubin racks, Intelligent Power Smoothing (IPS) reduces fast changes in rack input power. Workload decisions, managed limits, and rack smoothing affect the grid-facing power profile at different time scales.

The next section traces the Flex events that express the target and report the factory’s response.

How Flex Coordinates a Power Response

  1. Publish the target — Grid Utility/ISO. A Grid ISV represents an external power requirement as a time-bound Load Target Set.
  2. Carry the target — Communication and schema layer. The DSX Flex Schema defines the event, and NVIDIA DSX Exchange delivers it to subscribed factory-side systems.
  3. Determine the response — Power optimization and enforcement. Factory-side power management evaluates the target against the loads and controls it manages, then applies local policy. MaxLPS, including DPS, provides one NVIDIA option for this part of the response.
  4. Report operating state — DSX Flex Schema. Factory-side systems publish power-state snapshots through Exchange to report progress and target compliance. This is an ongoing asynchronous stream, not a direct response to a command.

Each participant remains responsible for its local controls. The operating-state stream allows subscribed systems to observe the factory response and adjust their own decisions as conditions change.

Flex also defines how factory-side systems report exceptions after a target becomes active. A Power Breach Alert reports that the factory cannot maintain the target and carries updates across the exception lifecycle. When infrastructure enforcement is used, a separate Power Breach Enforcement event reports the action taken and its outcome.

These events give participants a consistent view of the target, reported operating state, and exceptions that Flex covers.

Continue to the Flex architecture to see how the participant roles use Exchange to carry these events and how the schema represents target, state, and exception lifecycles.