The Rack as Integration Unit

For thirty years the rack was the least interesting object in the data center: a 19-inch steel cabinet, 42 rack-units tall, that you bolted to the floor and slid servers into. It had no opinion about power, cooling, or networking — those arrived from elsewhere and the rack merely held the boxes that consumed them. The AI generation ended that. A GB200 NVL72 is not 72 GPUs in a rack; it is a rack that happens to contain 72 GPUs — a single 1.36-tonne object with one liquid loop, one 1,400 A busbar, one NVLink spine, and one part number, built and validated as a unit at the factory and craned onto the slab as a unit. The rack stopped being a container and became the integration unit: the smallest thing you can meaningfully buy, ship, power, cool, cable, and accept.

This chapter is the canonical home for the rack as an object — its anatomy, its form factors, and the way every other physical subsystem now lands on it — and it is deliberately a hub that points outward. The power chain inside the rack is engineered in Part 4; the liquid loop in Part 5; the civil mass and anchoring in Chapter 6.7; the fabrics in Part 8; the operational telemetry in Part 14. What lives here is the integration discipline: the decision of which rack standard to build a facility around, and the consequence that every interior subsystem — busbar pitch, manifold geometry, cable management, BBU shelf, DCIM model — is dimensioned to that frame and inherits its constraints for a decade. The frame is among the most durable decisions in the facility. It outlives three GPU generations. Cut it to the wrong width and you strand the floor, the busbar, the manifold, and the cabling at once.

The integration unit is the level at which a thing is designed, procured, tested, and warranted as one. For decades that level was the server: you bought a 2U box, the vendor warranted it, and the rack was just where it lived. The scale-up domain pushed the unit up a level. When 72 GPUs must behave as one coherent accelerator over a copper NVLink spine that tolerates only sub-metre reach, the 72 GPUs, the nine NVSwitch trays, the spine, the busbar, and the manifold cannot be assembled by independent vendors and hoped to fit — they must be co-designed against a single mechanical, electrical, and thermal contract. That contract is the rack. The consequence is that the rack is now the smallest object that is independently meaningful: you cannot buy a third of an NVL72 and you cannot service one GPU without respecting the loop and the spine that bind the whole.

This reframing is what makes the rack the natural home for an integration chapter that points outward. The rack is where the four facility spines — power, cooling, network, and data — physically converge, terminate, and must coexist in roughly 600 mm of depth and one rack-width. Each spine has a canonical chapter of its own; none of them can be designed without knowing the geometry of the frame they land in. The civil scope — how a 1.5–3 t object distributes load into the slab and resists seismic events — is its own discipline and lives in Chapter 6.7; this chapter owns everything from the frame inward to the point where each spine becomes canonical elsewhere.

Three frame lineages dominate in 2026, and the differences are not cosmetic — they propagate into every spine. The legacy line is 19" EIA-310: the universal enterprise rack, ~600 mm external width, IT-usable width fixed at 17.72" (450 mm) between mounting rails, measured in 1.75" rack-units (U). It is the default for air-cooled and modest-density inference, and it is what most existing colocation halls are striped for. The OCP line is 21" Open Rack V3: a wider IT-usable aperture (~537 mm) measured in OpenU (OU, 48 mm — taller than a U), a 48 V DC blade busbar running the full height of the rear, and side-pocket volume for power shelves and BBUs. ORV3 was designed for hyperscale serviceability and is the baseline that the ±400 VDC Diablo 400 and 800 VDC sidecar designs extend. The newest line is Open Rack Wide (ORW) — Meta's 2025 contribution, effectively a double-wide ORV3 — built specifically to give rack-scale accelerators like AMD's 72-GPU Helios the lateral room for trays, manifolds, and a scale-up fabric that a single-wide frame cannot hold.

The second axis is depth, and it has grown faster than width. Enterprise racks lived comfortably at ~1,070–1,200 mm. AI racks have pushed past ~1,200 mm and are heading deeper because the rear of the rack is now contested territory: liquid manifolds, ~150–200 quick-disconnects, blind-mate power connectors, and dense cabling all compete for the same plane. NVIDIA's NVL72 MGX rack and its 44RU/48RU manifold variants exist precisely to package that rear congestion. Depth growth is not free — it consumes white-space floor area per rack, lengthens cable and hose runs, and complicates rear-aisle service clearance. The third axis is weight, which is a civil problem (Chapter 6.7) but originates in the frame: a populated, wet NVL72 is ~1.36 t and next-generation racks trend toward 2–3 t, which is why the frame, the slab, and the anchoring must be co-specified.

The rightmost column is the cost of getting the fork wrong. A 19" hall cannot host an ORW rack without re-striping aisles and re-pouring containment; an ORV3 power shelf will not feed a 19" rack; an MGX rack's rear plane is so fully consumed by its manifold and NVLink spine that there is no room to retrofit a different cooling or cabling scheme. The frame is the first irreversible interior decision, and the three lineages do not interoperate at the subsystem level even where their external footprint looks similar.

The power spine is where the frame standard bites first. In the legacy 19" world, power arrives as AC whips to in-rack PDUs — fine to ~20–40 kW, hopeless above it. The OCP world replaced whips with a vertical blade busbar running the full height of the rear: ORV3 operates at 47.5–50.5 V, delivers ~660 A and ~33 kW per power shelf, and a GB200-class rack stacks six to eight shelves. Blind-mate connectors let a tray drop into the busbar without a single bolted cable — a serviceability win that only exists because the busbar geometry is part of the frame standard. The NVL72 MGX busbar is rated to ~1,400 A to feed ~132 kW continuous. This entire power chain — busbar ampacity, shelf ratings, PSU efficiency, the AC-to-DC topology — is engineered canonically in Chapter 4.6 (LV distribution, busway, PDUs) and Chapter 4.7 (the ±400/800 VDC and disaggregated-sidecar revolution). What lives here is the geometry: the busbar occupies a fixed plane of the rear, and it competes with the manifold and the cabling for that plane.

The density ramp is what forces the frame to anticipate a power architecture it does not yet run. At 54 V, a 1 MW rack implies ~18,500 A and ~200 kg of copper busbar per rack — a physical impossibility to scale, which is the entire reason the industry is moving to ±400/800 VDC, where 800 V carries ~157% more power in the same copper than 415 V. A frame cut today for a 48 V blade busbar may have to host an 800 VDC busbar fed from a sidecar power rack in two generations. The BBU shelf — rack-level battery ride-through that triggers in milliseconds to absorb the synchronized GPU load step — also lives in the frame's side pockets and is made canonical in Chapter 4.5. The integration question the rack owns: does the frame reserve the volume and the busbar plane for the next voltage class, or does it lock you to 48 V?

The cooling spine is the most congested object in the rear of the rack and the one most coupled to the frame. A direct-to-chip liquid-cooled rack carries a vertical manifold pair (supply and return) feeding cold plates on every GPU and switch, connected through ~150–200 quick-disconnects (QDs) per rack — each a potential leak point, each a place where a tray must blind-mate into the loop without an operator coupling a hose by hand. The NVL72 moves ~80 L/min of coolant at an inlet below ~25 °C with a delta-T held under ~10 °C across the cold plates; deviate and the GPUs throttle up to 50%. The dripless, blind-mate UQD/UQDB couplings that make this serviceable are an OCP-standardized interface, which is precisely why the manifold and QD geometry must conform to the frame standard — a manifold designed for an MGX rear plane will not fit an ORW one. The full thermal contract (CDU sizing, flow, delta-T, coolant chemistry, the technology-cooling vs facility-water loop split) is canonical in Chapter 5.4; the density wall that makes liquid mandatory is Chapter 5.1.

The integration decisions the rack owns are mechanical and operational. Leak detection — rope sensors at the manifold, drip trays, and per-tray flow monitoring — is a rack-level instrumentation layer, and its telemetry feeds the DCIM model. The emerging negative-pressure (sub-atmospheric) design is a rack-architecture choice with a real consequence: running the loop below ambient pressure means a breach pulls air in rather than pushing coolant out, so a leak becomes a detectable nuisance instead of a fleet-killing flood. That safety property is bought with more complex pumping and tighter CDU control, and it is a decision made at the rack/CDU boundary before the loop is plumbed. With ~150–200 coupling points per rack and thousands of racks, the probabilistic leak math is unforgiving — negative pressure is the lever that converts a catastrophic failure mode into a maintenance event.

The network spine resolves a decision made canonical elsewhere but physically settled here, at the rack. Inside a scale-up domain, the choice is copper vs optics. NVIDIA's NVL72 keeps the entire 72-GPU NVLink scale-up fabric on copper — ~5,184 in-rack twin-axial cables forming a passive backplane spine — because at a worst-case in-rack span of ~0.83 m, copper is viable and saves on the order of ~20 kW/rack versus driving those links with optical transceivers. That power saving is enormous at fleet scale: optics for the scale-up fabric would add transceiver power, transceiver failures, and transceiver cost to every link. The catch is reach: passive copper at 800G/1.6T runs only ~1–2 m, which is exactly why the scale-up domain is confined to a rack (or, for NVL576/Kyber, to a rack cluster that crosses the copper wall and is forced onto optics). The copper-vs-optics economics and the NVLink fabric itself are canonical in Chapter 8.2; the physical-layer interconnect taxonomy in Chapter 8.9.

The scale-out (back-end) and front-end fabrics are a different physical animal: structured fiber, pre-terminated MPO trunks running from the rack to a row or end-of-row manifold, polarity-disciplined and loss-budgeted. The integration decision the rack owns is the boundary: where does the copper spine end and the fiber plant begin, and how does the rear plane accommodate both without the dense copper backplane fouling the fiber breakout. Pre-terminated trunk cabling is the primary install-velocity lever — it is what lets a rack land and link in hours instead of days — and that velocity story is owned in Chapter 7.15. The rack-level consequence: a frame that does not reserve cable-management volume for both a copper spine and a fiber breakout forces a field re-work that no amount of factory integration can recover.

The fourth spine is data, and the rack is where it becomes physical. A modern DCIM stack is no longer a spreadsheet of asset tags — it is a 3D digital twin of the rack and the hall, with every device mapped to a U/OU position, every port mapped to its peer, and a physical-layer telemetry feed (power per phase, coolant flow and temperature, leak-sensor state, busbar current, per-tray draw) streaming from the rack into the model. The integration discipline the rack owns is making the physical object legible: asset and port mapping accurate enough that a remote-hands technician can be directed to the exact tray and the exact QD, and a twin faithful enough that capacity, thermal, and cabling decisions can be simulated before steel moves. For a hall with thousands of liquid-cooled racks and hundreds of thousands of QDs, the twin is not a luxury — it is the only way to reason about where the next leak, the next thermal margin breach, or the next stranded U of capacity will appear.

The line between this chapter and operations is clean: the physical-layer twin — geometry, asset/port mapping, the sensor wiring — is a rack-integration deliverable and belongs here. The operational DCIM — alerting, predictive maintenance, agentic ops, the run-time observability that consumes this telemetry — is canonical in Chapter 14.2, and the failure-rate data that the telemetry exposes is Chapter 14.3. The rack's job is to be instrumented and mapped at integration time; operations' job is to act on what that instrumentation reports. A rack that ships without an accurate twin and a wired telemetry plane is a rack the fleet cannot see — and an invisible rack at 130 kW with 200 coupling points is a liability, not an asset.

The rack is integrated, not assembled: the four spines are co-designed against one frame rather than independently specified and hoped to fit. The frame is the first decision and the most durable, and it must be chosen against the workload and the density ramp, not against the existing hall. The rear plane is the contest a single integrator must arbitrate; the wet-vs-dry shipping fork trades commissioning speed against freight risk and field serviceability; and the digital twin must be wired and mapped at integration time so the fleet can see a 130 kW object with 200 coupling points. Get the frame right and every downstream subsystem lands cleanly; get it wrong and you strand the floor, the power, the cooling, and the cabling together.