GPU rack design: U budget, switch placement, cabling, and the layouts that survive the first year

A rack design is a contract you sign with your future self. Get it right and you can hot-swap a node, retrace a fiber, and pull a leaf switch at 2 AM with one hand. Get it wrong and every operation is a 90-minute scavenger hunt with a flashlight, an unlabeled bundle, and an angry customer on Slack. This page is the rack-level layout discipline — what fits, where switches go, how to route cables, what to label, and what to photograph.

For the underlying constraints see power and cooling. For the cable BOM and physical network specifics see physical network.

U budget — what actually fits in a 42U or 48U rack

The default rack height in most colos is 42U or 48U (modern AI halls increasingly use 48U or even 52U). On paper that's a lot of slots. In practice, GPU servers eat U at a rate enterprise people aren't used to:

Two example budgets show how full this gets.

Example 1: Air-cooled DGX H100 rack (42U, ~30 kW)

+---- 42U rack ----+
| 42  cable mgmt   |  1U
| 41  ToR IB leaf  |  1U  -- 64-port QSFP NDR
| 40  ToR Eth leaf |  1U  -- 32x 100G + 4x 400G uplink
| 39  OOB switch   |  1U  -- 1G mgmt
| 38  cable mgmt   |  1U
| 37 +-------------+
| 36 |  DGX H100   |  8U
| 35 |   #1        |
| 34 |             |
| 33 |             |
| 32 |             |
| 31 |             |
| 30 |             |
| 29 +-------------+
| 28 +-------------+
| ...|  DGX H100   |  8U
| 21 +-------------+
| 20 +-------------+
| ...|  DGX H100   |  8U
| 13 +-------------+
| 12 +-------------+
| ...|  DGX H100   |  8U
|  5 +-------------+
|  4  blanking     |
|  3  blanking     |
|  2  blanking     |
|  1  blanking     |
+------------------+

4 DGX H100 = 32U
3 switches  =  3U
3 cable mgmt=  3U
4 blanking  =  4U
Total       = 42U exact

You're full at 4 nodes per rack. Could you fit a 5th DGX? Yes — drop a switch and use a mid-rack leaf, or go to a 48U cabinet. But your real ceiling is power: 4 × 6.5 kW sustained = 26 kW + ~3 kW switches + overhead ≈ 30 kW. A 5th node pushes you toward 36 kW which an air room can handle but only with containment + RDHX.

Example 2: GB200 NVL72 reference rack (48U-ish, 120 kW liquid)

NVIDIA publishes a reference layout that uses essentially every U in the rack:

+---- ~48U NVL72 rack ----+
| top  cable manifold      |  ~1-2U
| 47   compute tray #18    |  1U
| ...  compute trays       |  9 trays
| 39   compute tray #10    |  1U
| 38   NVSwitch tray #5    |  1U
| 37   NVSwitch tray #4    |  1U
| 36   NVSwitch tray #3    |  1U  -- center NVLink spine
| 35   NVSwitch tray #2    |  1U
| 34   NVSwitch tray #1    |  1U
| 33   NVSwitch tray #6    |  1U
| 32   NVSwitch tray #7    |  1U
| 31   NVSwitch tray #8    |  1U
| 30   NVSwitch tray #9    |  1U
| 29   compute tray #9     |  1U
| ...  compute trays       |  9 trays
| 21   compute tray #1     |  1U
| 20   busbar tap / mgmt   |  ~2U
| 19   power shelf #4      |  3U
| 16   power shelf #3      |  3U
| 13   power shelf #2      |  3U
| 10   power shelf #1      |  3U
|  9   coolant manifold    |  base
+--------------------------+

18 compute trays =  18U
9 NVSwitch trays =   9U
4 power shelves  =  12U
manifold + mgmt  =   3-5U
Total            =  ~42-44U + manifold structure

The compute trays are stacked symmetrically around a center band of NVSwitch trays — that's the cable-distance optimization for the NVLink copper backplane. Power shelves at the bottom feed a 48 V busbar. The coolant manifold (large copper or stainless tubing) runs the rack height inside the rear, fed from a CDU.

There is no spare U in this rack. There is no room for a discrete leaf switch — leaf switches live in adjacent racks or in a separate networking aisle. There is no traditional rack PDU strip; the busbar replaces it.

Switch placement: top-of-rack vs middle-of-rack vs end-of-row

The choice has cabling, cooling, and operational implications.

Top-of-rack (ToR) — the default

Switches sit at the top 1-2U of the rack. Each node connects upward with relatively short cables. Easy to identify (top of the rack, eye level when you stand in front).

Pros:

• Short server-to-leaf cables (1-3 m), so DAC works for in-rack links.
• Failure domain is one rack. If the ToR dies, only this rack's nodes lose connectivity.
• Inline with operator mental model — "rack X = leaf X."

Cons:

• Hot air rises. Switches at the top see the highest hot-aisle temp. Most modern leaf switches are rated A2 and survive, but you're operating closer to the limit.
• Doubles the leaf count vs an end-of-row design (one leaf per rack instead of one leaf per multiple racks).
• For 8-rail GPU nodes, ToR means one rail's leaf is in this rack and the other rails' leaves are in different racks — defeating the rail-aligned cable simplification.

Middle-of-rack (MoR)

Less common for GPU; more common in mixed-density rooms. Switch sits at U18-U22 with nodes above and below.

Pros:

• Average cable length to nodes is shorter than ToR for tall racks.
• Switch is in cooler air than the very top.

Cons:

• Cable management around the switch is awkward — you have cables going up from below and down from above into the same panel.
• Less common, less standardized — operators have to learn the layout.

End-of-row (EoR) / rail-aligned spine pattern

Leaves live in dedicated networking racks at the end of each row. All compute racks have just nodes; all networking lives separately. The pattern matches rail-aligned IB design where leaf-N collects rail-N from every node in the row.

Pros:

• Cleaner thermal: switches in their own rack with their own cooling profile.
• One leaf per rail, not one leaf per rack — fewer switches at the leaf layer for the same node count.
• Matches the IB rail-aligned topology naturally — see IB architecture.
• Easier to swap a leaf without disturbing compute racks.

Cons:

• Cables get longer (5-30 m), so you need AOCs or transceivers + fiber for many links instead of cheap DAC.
• Cable BOM grows; cabling labor grows.
• Failure domain is "the entire row" if a leaf fails — but rail-aligned design means only one rail is affected, not all rails, so jobs can continue at degraded bandwidth.

For AI training fabrics, rail-aligned EoR is the discipline that scales. ToR is fine up to ~64 nodes; past that you want EoR for the network and ToR only for the management/storage Ethernet.

PDU placement

Two vertical PDU strips, one on each side of the rack, mounted in the side pockets (zero-U, doesn't eat U-budget). Each strip has its own inlet whip from a different upstream feed.

top of rack (looking in from rear)

+--+--------------------------+--+
|A |  switches                |B |
|P |--------------------------|P |
|D |  node 1 PSU 1 -> A       |D |
|U |          PSU 2 -> B      |U |
|  |          PSU 3 -> A      |  |
|A |          PSU 4 -> B      |B |
|  |          PSU 5 -> A      |  |
|s |          PSU 6 -> B      |s |
|i |--------------------------|i |
|d |  node 2 PSU 1 -> A ...   |d |
|e |  ...                     |e |
+--+--------------------------+--+

Discipline points that bite operators in year two if you skip them:

• Always alternate A/B on PSUs. A node with all PSUs on A loses everything when A trips. Alternating means A failure runs on N+1 of B-side PSUs, B failure runs on N+1 of A-side. Half the PSUs each side, half the cords each side.
• Use C13/C19 cords with correctly sized plug retention. GPU nodes vibrate enough under load that cheap cords back out over weeks. Pick locking cords (IEC 60320 V-lock) or use a cord retainer.
• Color-code A vs B. Blue = A side, red = B side, or vice versa — pick a convention and stick to it across the whole site. Operators visually scanning a rack at 3 AM can spot a mis-cabled node from the aisle.
• Label every outlet at both ends with a tag: outlet number on one end, node + PSU number on the other. When PSU 4 of node 7 fails, you want the cord-pull to be obvious.

For a GB200 NVL72 rack, the busbar replaces vertical PDU strips. The discipline shifts: instead of cord routing, you verify shelf-to-bar blind-mate engagement during install (no tools, but visual inspection that all four shelves are seated), and you label each shelf with its branch breaker.

Cable management

This is where racks fail an operator's first attempt. The principles are tedious; the value compounds for years.

Two physical paths, kept separate

InfiniBand (or RoCE) high-speed fabric, and out-of-band / management Ethernet, should travel on separate cable paths. Storage Ethernet is a third path. Power is a fourth. Routing them all in the same tray turns the back of the rack into a snake pit.

A typical layout:

                        cable trays (overhead)
   ----------------------------------------------------
   |  IB / RDMA fabric tray (rail 0-7 cables)         |
   |                                                  |
   |  Ethernet fabric tray (storage, OOB)             |
   |                                                  |
   |  Power feeds (A and B whips)                     |
   ----------------------------------------------------
              |              |             |
              v              v             v
       rack - rear (vertical channels behind PDUs)
       IB cables on left side, Ethernet on right,
       power down the corners

Trays should be physically separated by 6+ inches with a barrier where they cross power paths, to limit any nuisance EMI on copper.

Color-code by rail and by side

For an 8-rail GPU node, every cable is one of 8 IB rails plus management plus storage. Use 8 distinct cable jacket colors (or 8 boot colors if jackets are all black) for the 8 rails. The colors should be the same across the entire fabric — rail 0 is always orange, rail 1 always green, etc.

When you walk into a rack and see 8 cables emerging from the back of a node, you should be able to tell at a glance that:

• Each cable is a different color (= each rail is connected once).
• The colors match the leaf rack's cable bundle (= rails are aligned to leaves).
• Nothing is teal where it should be orange (= rails not crossed).

If you can't see that, your install is going to ship rail-mismatched, NCCL will run at 1/8 of expected, and you'll spend a week tracing.

Label both ends

Every cable has a label at each end with:

[ source-node:port ] -> [ dest-switch:port ]
e.g. n0712:HCA0  ->  leaf-rail0-rk04:34

The label format should be machine-parseable, written with a thermal-print labeler, and wrapped on a flag (so you can read it without unplugging the cable). Pen-on-tape labels fade in 18 months in a hot aisle. Sharpie on heat-shrink also fades. Thermal-print plus a clear over-laminate is the standard.

Label discipline is what makes rebuild from photographs possible. If you trace a cable in three years and its label is gone, you can either pull it (40 minutes per cable, x thousand cables) or guess.

Slack and bend radius

Every cable should have:

• Service loop near the node end: enough slack that the node can be racked out 6-8 inches without unplugging.
• Bend radius respected: optical cables typically 25-50 mm minimum bend; AOCs often 50 mm. Tight bends increase BER over time.
• Vertical drop strain-relieved: cables hanging vertically without support stretch the connector strain points over years.

Photograph before, during, after

Before commissioning, take photographs of:

• The front of the rack with all switches and nodes seated.
• The back of the rack with all cabling routed and labeled.
• Each cable bundle entry into the cable tray.
• Each leaf switch port mat (showing port labels with cables seated).

Store these in your CMDB / runbook system, indexed by rack ID. When something changes in a year, the photographs are how you know what changed. They're also the document you give a new operator on day one.

Reference layouts

DGX SuperPOD H100 Scalable Unit (32 nodes)

NVIDIA's published H100 SU is 32 DGX nodes, 8 leaf IB switches, 4 spine IB switches, organized across 8-12 racks depending on density. The published cable count for one SU is in the hundreds (8 rails × 32 nodes = 256 server-to-leaf cables alone, plus leaf-to-spine).

A typical compute-rack layout for this SU:

• 4 DGX H100 per rack × 8 racks = 32 nodes.
• Storage and management in adjacent rack(s).
• Networking aisle with EoR leaf and spine racks separately.

Power per compute rack: ~30 kW sustained. Cooling: in-row CRAH + cold-aisle containment. Air-cooled is fine at this density.

GB200 NVL72 — full rack as the unit

Each NVL72 rack is its own pod. The 72 GPUs inside one rack share an NVLink5 domain via the in-rack NVSwitch trays, with copper cabling. The IB fabric exits the rack to leaf switches in adjacent racks (typically EoR networking).

Layout per row:

• N compute racks, each a complete NVL72 (120 kW liquid).
• 1-2 networking racks at row end, holding leaves + management.
• 1 cooling/power rack interleaved (CDU, busbar power shelf bank).

A row of 8 NVL72 = 576 GPUs in roughly 10 racks of floor space. Power per row: ~1 MW. Cooling: full DLC, primary chilled water at warm-water temperature, dry coolers or hybrid evaporative for heat rejection.

BMS and per-rack telemetry

A BMS-instrumented rack should report at least:

Sample these into your TSDB at 30-60 second intervals. Build dashboards by rack ID and by row. The first time a rack drifts thermally you'll be glad you did.

Cable-tray sizing and segregation

Tray fill ratio is one of those numbers that determines whether your build looks clean or looks like a hairball.

Fill capacity rules of thumb

Tray cross-sectional area:  width * height (after deducting structural)
Cable bundle area:          pi * (cable_OD/2)^2 * count, plus packing factor (~0.75)

For a 600 mm wide x 100 mm deep tray (common):
  Usable area  ~ 600 * 80 = 48000 mm^2
  Cable OD     ~ 8 mm for AOC, 10 mm for thicker DAC, 5 mm for OOB Ethernet
  Per cable    ~ pi*(5)^2 / 0.75 = 105 mm^2 for AOC (with packing)
  Capacity     ~ 48000 / 105 = 457 cables theoretical
  Practical    ~ 200-300 cables (for tracing, replacement, growth)

The "practical" number is half the theoretical because:

• You need to be able to fish individual cables in and out.
• Growth: 30-50% headroom for adding cables later.
• Bend loss at tray turns wastes effective volume.

A 1-SU cluster of 32 nodes with 16 cables/node = 512 IB cables on the high-speed tray. At 200 cables / 600 mm tray, you need 3 trays per row, or one wider tray (1200 mm).

The four-tray rule

For high-density GPU rooms, use four physically separated trays:

1. High-speed fabric (IB or RoCE) — 8-rail bundle per node + leaf-to-spine.
2. Storage Ethernet — 200/400G storage links.
3. Management / OOB — 1G/10G Ethernet, copper or fiber.
4. Power — A and B feeds (themselves separated by ~6+ inches).

Why four and not two: when (in year three) you have to add a cable on the storage side, you don't want to be fishing through 500 IB cables to get there. Same for OOB during a debugging session.

Tray crossings and grounding

Where trays cross power feeds, install a metal barrier or use armored cable. EMI from a 200 A power whip is not theoretical; it shows up as occasional bit errors on the closest copper Ethernet line over months.

Trays must be properly grounded — bonded to the building ground at multiple points along their length. An ungrounded tray sees voltage potentials build up under thunderstorm conditions and can damage optics on plug-events.

Hot-aisle / cold-aisle aisle-end caps

Containment is a roof and end-cap doors that physically separate the cold-aisle and hot-aisle airstreams. Variations:

• Cold-aisle containment: doors and roof on the cold aisle, hot exhaust is into the open room.
• Hot-aisle containment: doors and roof on the hot aisle, the room is the cold side.
• Chimney rack: each rack has its own chimney to the return-air ceiling plenum.

For mixed environments, hot-aisle containment is more flexible — the room stays comfortable for operators and cold air can be supplied flexibly. For uniform GPU rooms, cold-aisle containment is cleaner because supply air paths are concentrated.

End-cap doors must:

• Self-close (cannot be propped open during normal operations).
• Have transparent panels for visibility.
• Survive 24/7 cycling — crap hardware fails in months.

A common operator mistake: propping the end-cap door open during cable work. The hot air leaks out, the cold air leaks in, the inlet temperatures drift, the CRAH responds, and now the entire row's setpoint is off. Close the door. Always close the door.

Operator ergonomics: the 3 AM test

A rack design is a contract with your future self at 3 AM with a flashlight and a customer Slack bridge open.

Things to verify before signing off on a layout:

• Stand at the front of the rack. Can you read every node's power button label without bending? Can you read the switch port labels?
• Stand at the back of the rack. Can you trace any single cable from node to switch, visually, without unbundling?
• Open the rear door. Can you reach every PSU, every cable connector? Or are some hidden behind cable bundles?
• Pull a node halfway out (rack rails). Do the cables reach? Or do you have to disconnect to slide?
• Power-cycle a single PDU. What loses power? Is the impact what you expected?
• Photograph every face. If you came back 18 months later with no documentation, could the photos guide a rebuild?

Running these tests at install — before the customer is on the cluster — catches dozens of small issues that compound. After the customer is on, fixing them costs 10× more.

Auditing a rack you didn't build

Sometimes you inherit a rack designed by someone else. The audit checklist:

Power audit

• Every node has both A-side and B-side cords landing on different PDUs.
• Both PDUs have separate upstream feeds (verify breaker panel mapping).
• Phase balance across PDUs is within 15%.
• No outlet is loaded above 80% of its rating.
• PSUs report healthy via BMC.
• Cord retention (locking plugs or retainers) is in place.

Cooling audit

• Cold-aisle inlet temp at top, middle, bottom of rack — all within 3 K.
• Hot-aisle exhaust within expected envelope.
• No bypass airflow (check blanking panels in every empty U).
• No recirculation (check containment door state, end caps).
• For DLC: visually verify all quick-disconnects are seated, no drips, no condensation.
• Filter pressure drop in spec.

Network audit

• Every cable has a label at both ends, readable.
• Cables match the topology document (rail X to leaf X, etc.).
• Color coding consistent with site policy.
• Bundle entry into trays is strain-relieved.
• No cable bent below minimum radius.
• Service loops at node ends present.
• Optical power readings within spec for fiber links.
• Link state (rate, errors) clean for every port.

Documentation audit

• Rack elevation (current) on file.
• Photographs of front and rear within the last 6 months.
• Cable database with both endpoints for every cable.
• Power database with PSU-to-PDU mapping.
• Maintenance log entries up to date.

If any item fails, log it, prioritize the safety-critical ones (power, cooling), and schedule the rest. An undocumented rack is a future incident waiting to happen.

Inventory: what to keep on the rack and on the floor

Keep on the rack (in a designated cubby or zip-loc on the rear door):

• Spare blanking panels (4-6).
• Spare velcro and zip ties.
• Permanent marker, pen.
• Printed rack elevation diagram (update on every change).

Keep on the floor (per row or per rack-section):

• 1-2 spare AOC cables of each common length.
• 2-3 spare DAC cables of common lengths.
• 1-2 spare optic transceivers of every model in use.
• 1 spare PSU per node model.
• A clean rolling tool cart with the standard install kit.

Keep in your DCIM / CMDB:

• Rack-level power inventory (PSU count, PDU model, breaker mapping).
• Rack-level cable inventory (cable count, length, type).
• Rack-level node inventory (model, serial, firmware version).

When something fails at 3 AM, the difference between a 30-minute fix and a 4-hour fix is whether the spare is on the floor and the documentation is current.

Common rack mistakes and how to avoid them

1. Leaving a 4U gap at the top of the rack with no blanking panels. Bypass airflow ruins cold-aisle pressure and your inlet temps drift. Fix: install blanking panels in every empty U.
2. Mixing rail colors. Two cables that look almost the same color but represent different rails. Operators mis-trace, NCCL runs at half speed. Fix: pick distinct colors for the 8 rails, document the palette, audit before commissioning.
3. Running both A and B power cords through the same cable tray, both into the same PDU. Defeats dual-corded design. Fix: separate trays for A and B; physical inspection at install.
4. Switch at the top of an air rack with no rear airflow. Switch overheats, port errors increase, no one connects it to the rack thermals. Fix: ensure the switch's intake is actually in cold air (front-to-back fans, switch facing the right way).
5. No cable-tracking system. When a cable fails in year two, you have no document of what should be on that port. Fix: every cable in a CMDB with both endpoints, plus the photographs.
6. Cable tray too small. You add 20% more nodes and there's nowhere to route the new cables. Fix: size trays for 1.5-2× initial cable count.
7. No service loops. Every node maintenance is a cable disconnect. Fix: 0.5-1 m service loop on the node end of every cable.
8. Labeling that fades. 18 months later you're staring at a blurred label trying to identify port. Fix: thermal-print labels with over-laminate.

Rack-level design choices that show up in incidents

Several layout decisions look harmless at design time but generate a steady flow of operational incidents. Naming them so you avoid them.

Switch in-rack vs end-of-row, when it matters

Putting an IB leaf switch in every compute rack (ToR) gives you:

• Short cables, mostly DAC.
• Localized failure (one rack loses connectivity if the leaf dies).
• Doubled switch count for the same node count.

Putting leaves in a dedicated networking rack at end-of-row (EoR) gives you:

• Longer cables (AOC or transceivers + fiber), higher BOM.
• Failure of one leaf affects one rail across multiple racks (smaller blast radius for any single rail; bigger blast radius for a single rack).
• Cleaner thermal: switches aren't sharing hot air with compute.

For rail-aligned IB at scale, EoR wins. The cabling cost is real but the operational simplicity (and matching topology) pays it back.

Mixed-density rows

If you put a 30 kW air-cooled H100 rack next to a 120 kW liquid GB200 rack, the two have very different airflow needs. The H100 wants strong cold-aisle pressure; the GB200 takes most of its heat to liquid and emits less hot air per rack. The CRAH can struggle to balance.

Better: dedicate rows to one density class. Air-cooled H100 in one row, GB200 NVL72 in another, B200 4U-liquid in a third. Each row gets sized cooling, sized power, sized cabling.

Cable trays at the wrong height

Overhead cable trays at ~3 m height look clean but make every cable change a ladder operation. Trays at ~2.4 m are reachable from a step stool. The 60 cm difference matters — a year of installs at the higher height adds up to days of extra labor.

Insufficient blanking

Blanking panels in every empty U is the cheapest cooling improvement available. Sites that skip blanking see hot air recirculation through gaps, inlet temperature drift of 3-5 K, CRAH set-point creep down, PUE worsening. Cost: ~$10/U for snap-in plastic blanking. Easy fix.

No cable storage on the rack

Spare cables in the data hall are good. Spare cables on a shelf 100 m away are useless when you need one. A small cubby in the rack with 2-3 spare AOCs of common lengths and a spare optic-pair is what bridges 90% of incidents.

Templating: rack designs you can copy

A real site standardizes on 3-5 rack templates and uses them everywhere.

Template A: H100 air-cooled compute rack (42U, 30 kW)

U42: cable mgmt
U41: ToR IB leaf (1U)
U40: ToR Eth leaf (1U)
U39: OOB switch (1U)
U38: cable mgmt
U37-30: DGX H100 #1 (8U)
U29-22: DGX H100 #2 (8U)
U21-14: DGX H100 #3 (8U)
U13-6:  DGX H100 #4 (8U)
U5-1:   blanking
PDU:    2x vertical 60A 415V three-phase, A and B
Cooling:room air, cold-aisle containment
Power:  ~28 kW sustained, 41 kW peak
Cables: ~64 IB, 8 storage, 4 mgmt = ~76 per rack

Template B: GB200 NVL72 compute rack (~48U-equivalent, 120 kW)

Top:      cable manifold (vertical, runs full rack height)
U upper:  9 compute trays
U mid:    9 NVSwitch trays (centered)
U lower:  9 compute trays
Below:    4x 33kW power shelves
Base:     coolant manifold inlet/outlet
PDU:      busbar, 48V DC, fed by power shelves at 480V 3-phase
Cooling:  liquid (DLC primary, ~85% to liquid, residual air)
Power:    ~120 kW continuous
Cables:   ~16 IB out per rack (rail-aligned to row leaf), ~4 mgmt

Template C: Networking rack (42U, ~15 kW)

U42-39: cable mgmt + patch panels
U38-35: 4x spine IB switches (1U each)
U34-31: 4x leaf IB switches (1U each, for adjacent compute rows)
U30:    OOB management switch
U29:    DCN core switch (Ethernet)
U28-25: storage / monitoring servers (4x 1U)
U24-1:  patch panel field, structured cabling
PDU:    2x vertical 30A 415V, A and B (lower power requirement)
Power:  ~12 kW sustained
Cables: ~256 IB cables terminate or pass through here

Template D: Storage rack (42U, ~25 kW)

U42-39: switching (storage Ethernet leaf, OOB)
U38-3:  storage nodes (NVMe-oF servers, 1U or 2U each)
U2-1:   blanking
PDU:    2x vertical 60A 415V, A and B
Power:  ~22 kW sustained
Cables: ~64 storage Ethernet, 4 mgmt

Standardizing means every operator knows what to expect when they walk to a rack. Tracking down a "weird" build that doesn't match any template is what eats hours.

See also

• Power — what determines per-rack power budget
• Cooling — what determines per-rack thermal budget
• Physical network — cable types, BOM math, transceivers
• InfiniBand architecture — rail-aligned topology this rack design supports
• InfiniBand implementation — install + commissioning sequence
• PCIe topology — node-internal layout that drives rack cabling order
• Health check runbook — daily checks include port state and cable health

Sources

• NVIDIA DGX SuperPOD H100 Reference Architecture (white space + infrastructure design guides): 32-node Scalable Unit, 8 leaf + 4 spine, in-row CRAH + containment, "rack power exceeds 40 kW."
• NVIDIA DGX H100 chassis spec: 8U, 482 mm wide, 897 mm deep, ~130 kg, 6× 3.3 kW PSU.
• NVIDIA GB200 NVL72 published layout: 18 compute trays + 9 NVSwitch trays + 4 power shelves, full liquid, 480 V three-phase.
• Open Compute Project Open Rack v3: 44OU vertical busbar, 33 kW power shelves, blind-mate compute trays.
• ASHRAE TC 9.9 (5th ed.): thermal envelopes A1-A4 and the 18-27 °C recommended range used in cold-aisle design.