Configuration engineering: requirements become a specified unit

Scope

What this stage actually decides

In a conventional build, configuration and design are the same activity, and they run for months because almost nothing is fixed. In a factory-built model the architecture is already fixed — enclosure, cooling topology, power distribution, rack geometry — so configuration is the short step of choosing among options the platform already supports. That is the whole trade: less freedom, far less schedule. This page is the stage-02 detail behind the six-stage deployment overview.

The stage has one deliverable and one failure mode. The deliverable is the configuration freeze. The failure mode is freezing a specification nobody traced end to end — an accelerator chosen without checking the density it implies, a density chosen without checking the cooling it forces, a cooling selection chosen without checking what the site can reject heat into.

Workload profile sets everything else

The first question is not which GPU. It is what the machine is for, and how hard it runs. A sustained training profile pins accelerators near their power ceiling for long stretches, so the thermal design is sized against a near-continuous load. An inference profile is spikier and more sensitive to latency and data residency, which often decides the site before it decides the hardware. A mixed profile must be sized against its worst sustained case — averaging is how thermal designs end up undersized.

Two assumptions belong in writing at this point: the sustained duty the cooling is sized against, and the horizon over which the unit must absorb a hardware generation or two. Both are what a later disagreement will be about.

Accelerator family and rack density

Choosing an accelerator family is no longer only a compute decision. Vendors now ship rack-scale packages with their own cooling and interconnect assumptions built in: NVIDIA's GB200 NVL72 is delivered as a liquid-cooled rack acting as a single NVLink domain, because an air-cooled build of that density is not on offer.^[2] The interconnect topology travels with the choice too: NVLink Switch gives all-to-all GPU communication across the rack,^[3] which is a different design question from the fabric between racks. Configuration has to accept both, or pick a different family.

Rack density then falls out of that choice, and it belongs in the freeze as a sustained figure across the refresh horizon rather than a day-one nameplate. Uptime Institute's 2025 global data center survey tracks the same shift across the operator base: fleet densities are climbing past what conventional air cooling handles comfortably.^[1] The high-density GPU infrastructure page covers what that density does to the rest of the design.

Cooling selection follows density, not preference

Once density is fixed, the cooling selection is mostly determined. What remains open is the coolant class, the facility water supply temperature the installed hardware accepts, and the heat-rejection method at the boundary. ASHRAE's thermal guidelines name liquid-cooling facility water classes by their maximum supply temperature, and the choice is economic as much as thermal: the warmer the class the hardware tolerates, the more of the year heat can be rejected without compressors.^[4]Open Compute's cold-plate requirements set the wetted-material and interface expectations that keep a multi-vendor loop stable across refreshes.^[5]

The rejection method is the genuinely site-specific part, sized against climatic design conditions for the actual location — design dry bulb, extreme dew point, coincident wet bulb — not a national average.^[9] A dry cooler consumes no water but needs a warmer loop or more surface area; evaporative rejection buys lower approach temperatures and pays in water. The loop itself is covered on the direct-to-chip liquid cooling page.