What Is an AI Factory Digital Twin? NVIDIA's Omniverse DSX Blueprint Versus a Manufacturing Twin

As GPU clusters for robot training have grown, the data center has turned from a server room into a large facility in which the grid connection, cooling plant and high-speed network have to be designed together. NVIDIA calls these facilities “AI factories” and offers the Omniverse DSX Blueprint as a digital-twin reference architecture: validate the facility virtually before construction, then use the same twin as an operating environment afterwards. This article uses NVIDIA’s announcement and documentation to set out what DSX contains, how data flows through the blueprint, and how it differs from the manufacturing digital twins covered elsewhere on this site.

DSX and the DSX Blueprint are not the same thing

Start with the names. The NVIDIA blog post of October 28, 2025 introduced Omniverse DSX at the GTC Washington, D.C. keynote as an open blueprint for designing and operating gigawatt-scale AI factories, validated at the new AI Factory Research Center at Digital Realty’s site in Manassas, Virginia.

As of the verification date, the NVIDIA DSX product page describes DSX as this set of components:

According to the same page, the Omniverse DSX Blueprint is an open framework within DSX Sim. It includes SimReady assets, hardware configurations, a web UI and sample scripts, is generally available on build.nvidia.com, and is compatible with the Vera Rubin DSX AI Factory reference design. The 2025 blog framed DSX around three pillars, Flex, Boost and Exchange, while the current product page lists MaxLPS rather than Boost. Official documentation did not confirm whether the two names refer to the same function, so it is safer to cite the document date alongside any component name.

How data flows inside the blueprint

The DSX Blueprint system architecture documentation describes the flow in this order:

1. SimReady asset pipeline: vendor CAD is turned into OpenUSD assets. Geometry is first validated for topology, normals and structural compliance, then simulation metadata such as power, thermal cooling and connection points is added.
2. PLM and CAD/BIM: validated assets are stored in a product lifecycle management system as the authoritative definition, and CAD/BIM tools assemble them and export OpenUSD assemblies.
3. Simulation and surrogate models: network, grid, thermal, site and electrical simulations run, and AI-accelerated surrogate models return fast approximate results through an API.
4. AIF-DT runtime: the Omniverse Kit rendering engine, an app-streaming API, a simulation data delegate, AI agents, a USD storage API and a data lake form a single runtime.
5. Operational data: telemetry lands in the data lake next to simulation results, and AI agents read it to produce optimization recommendations.

The 2025 blog also assigns roles to the companies involved. Jacobs handles building design and compute layout; Siemens, Schneider Electric, Trane Technologies and Vertiv supply SimReady OpenUSD assets for power, electrical and cooling equipment; Cadence provides a thermal and electrical simulation platform; PTC provides PLM; and Phaidra and Emerald AI train AI agents inside the twin to optimize power use.

How it differs from a manufacturing twin

Set against the manufacturing twin covered in factory digital twins with OpenUSD, the differences are clear:

What they share is the use of OpenUSD to combine assets from many vendors into one scene, and the fact that changing a design before construction costs far less than changing it afterwards. What differs is the unit of optimization. A manufacturing plant asks how many units it can make per hour; an AI factory asks how many GPUs it can run on the same power.

How the power budget drives the design

Power is the starting point of AI factory design. With an incoming power limit $P_{budget}$ and per-node power $P_{node}$, the number of nodes that fit is:

Lowering $P_{node}$ lets more nodes fit within the same power. The Lambda example on the NVIDIA DSX product page reports a five-rack test in which 19 HGX B200 nodes ran on the power budget of 16 baseline nodes. The node ratio, $19/16 \approx 1.19$, matches the 19% GPU-capacity increase the page states, and the same example reports 24% more token throughput and 23% better performance per watt.

Results like these vary by facility and workload. The twin’s job is to check $P_{node}$ and cooling headroom in simulation before construction and then recalibrate them against real measurements during operation.

A realistic evaluation order

For a facility team evaluating the DSX Blueprint, this order is practical:

1. Define the questions the twin must answer, for example how many racks fit within a given power limit and which cooling approach to use.
2. Bring up the reference design using the sample configuration from the overview documentation and list where your own site differs.
3. Ask equipment vendors whether they supply SimReady OpenUSD assets; if not, scope the CAD conversion and metadata work.
4. Choose a solver for each simulation type and decide which detailed analyses will validate the surrogate models’ estimates.
5. Design the path for operational telemetry into the data lake.

How robot training data is produced and multiplied once such a training facility exists continues in the Physical AI Data Factory Blueprint.