A rack can have enough empty rack units and still be the wrong home for an AI server. The useful purchase question is not simply “will it fit?” It is “can this cabinet deliver the required power, remove the heat, and meet our agreed performance target when something fails?” This sizing guide gives you a reusable worksheet, a 256-GPU design example, and a facilities acceptance matrix.
The hardware anchor is NVIDIA DGX B200, not a generic Blackwell server or a GB200 rack. NVIDIA specifies eight B200 GPUs, a 10U chassis, and 14.3 kW maximum system power for this product.[1] All cluster totals below are hypothetical planning calculations, not measured consumption, benchmarks, or a certified electrical design. Have the equipment vendor and qualified facilities engineers approve the final installation.
1. Start with the failure requirement, not rack density
Write down three separate promises before requesting a quotation:
- Normal operation: every admitted job can run within its agreed performance envelope.
- Degraded operation: after the specified failure, jobs either continue at a defined reduced performance level or drain safely.
- Maintenance: identify which components can be serviced without losing that promise.
Do not use “redundant” as a substitute for those statements. DGX B200 has six power supplies in a 5+1 arrangement, but NVIDIA also documents reduced performance when two supplies lose power.[1] The current user guide's cable-disconnection table reports a maximum GPU power of 1,000 W with one cable removed, 800 W with two or three removed, and system shutdown with four removed.[1] Those are documented power-state limits, not a prediction of application throughput.
A hypothetical three-cords-to-A and three-cords-to-B arrangement therefore cannot be sold as “one feed can disappear with no performance effect.” Losing a feed removes three supplies; the documented state is not the same as losing one supply.[1] Ask the vendor to approve the cord-to-feed mapping and specify the performance commitment in that state. Neither extra upstream capacity nor an attractive A/B diagram changes the server's internal behavior.
Decision asset: if full performance during feed loss is mandatory, make that a procurement gate. If degraded performance is acceptable, define its minimum service level and test it. If only safe shutdown is required, document the shutdown sequence and recovery time instead of paying for an unverified availability claim.
2. Keep the hardware identity and source revision attached
The following inputs belong to DGX B200. They must not be transferred to an HGX-based OEM chassis, DGX H200, a Grace Blackwell rack, or a newer product without checking its own documentation.
| Planning input | Published DGX B200 value | How to use it |
|---|---|---|
| GPUs per system | 8 | Convert a GPU target into whole systems.[1] |
| Server height | 10U | Count occupied rack units, not just cabinets.[1] |
| Maximum system power | 14.3 kW | Size the stated maximum envelope; do not call it typical draw.[1] |
| Maximum system weight | 142.4 kg | Include rails, PDUs, cabinet and other equipment separately.[1] |
| Power supplies | Six, rated 3.3 kW each | Do not substitute the sum of PSU ratings for server consumption.[1] |
| Published system airflow | 1,550 CFM | Take the operating conditions to the cooling designer.[1] |
There is a useful documentation trap here. NVIDIA's data-center best-practices presentation labels several specifications as estimated, identifies DGX B200 as air-cooled, and presents two-system and four-system rack patterns.[2] Its dense-rack airflow worksheet uses an estimated 150 CFM per kilowatt at sea level, producing 4,290 CFM for two systems and 8,580 CFM for four; it explicitly says actual requirements vary by site.[2] That is not identical to multiplying the user guide's system airflow entry by server count.[1]
Do not silently average the figures or select the smaller number to make a room pass. They are different planning inputs with different context. For this worksheet, use 14.3 kW as the common power anchor; keep both airflow references visible and obtain an approved site-specific cooling design. Use the current product guide for the ordered hardware revision, and record any vendor clarification in the handover pack. This article makes no claim that B200 is the newest platform or that a particular configuration is currently available for delivery.
3. A worked 256-GPU rack power sizing example
Hypothetical assumptions: 256 GPUs, eight per server, two or four servers per compute rack, and 1.0 kW of additional equipment in each compute rack. That extra kilowatt is an illustrative allowance for local equipment, not a measured switch specification. Shared storage, fabric-spine racks and facility losses remain outside the compute-rack subtotal. A 20% capacity allowance is applied to connected design load; it is not an electrical-code derating rule.
The reusable equations are:
server_count = ceil(target_GPUs / GPUs_per_server)
rack_count = ceil(server_count / servers_per_rack)
server_load_kW = server_count * server_max_kW
rack_design_load_kW = servers_per_rack * server_max_kW + auxiliary_kW
rack_planning_capacity_kW = rack_design_load_kW * (1 + allowance)
The Python worksheet accompanying this article was executed to produce these results. The results are arithmetic only; no hardware load test was performed.
| Metric | Two servers per rack | Four servers per rack |
|---|---|---|
| Servers / GPUs per full rack | 2 / 16 | 4 / 32 |
| Compute racks | 16 | 8 |
| Server load per full rack | 28.6 kW | 57.2 kW |
| Assumed auxiliary load per rack | 1.0 kW | 1.0 kW |
| Connected design load per rack | 29.6 kW | 58.2 kW |
| Per-rack planning capacity with 20% allowance | 35.52 kW | 69.84 kW |
| Server-only cluster load | 457.6 kW | 457.6 kW |
| Compute-rack connected subtotal | 473.6 kW | 465.6 kW |
| Compute-rack capacity subtotal with allowance | 568.32 kW | 558.72 kW |
The dense arrangement saves cabinets, not server watts. Its slightly lower subtotal arises solely from assuming the same fixed auxiliary allowance in fewer racks. Real switch counts and placement may invalidate that assumption. Replace the allowance with a port-level bill of materials before comparing quotations.
Twenty percent extra capacity also does not mean operating at 80% utilization: dividing the load by its 1.2-times capacity produces about 83.3%. If your policy is a strict 80% ceiling, divide by 0.8 instead. These two conventions should never share an unlabeled “headroom” cell in a spreadsheet.
4. Space, weight and cabling are separate constraints
Four 10U systems occupy 40U before other rack equipment is counted; four times the documented maximum system weight is 569.6 kg before the cabinet and accessories.[1] A successful rack-unit calculation therefore does not establish floor-loading, rolling-load, access-route, seismic-restraint, or service-clearance approval. Put those approvals on separate lines in the design review.
The NVIDIA presentation identifies four-system racks as an option for specialized sites designed for extreme-density air-cooled deployment, rather than treating density as a free upgrade.[2] That is the right purchasing mindset: ask which constraint becomes harder when the rack count is halved. It might be branch-circuit capacity, air delivery, cable management, or the ability to service a heavy chassis without disrupting adjacent equipment.
Keep fabric reach and rack placement in the same review. NVIDIA explicitly identifies InfiniBand cable-distance limits as a constraint on cabinet proximity in the DGX deployment pattern.[2] Do not approve a cooling-driven rack move and leave the network team to discover that the existing cable order no longer fits. Recalculate actual routed lengths, including vertical travel and the approved service slack, before releasing the optics and cable bill of materials.
For design continuity, pair this worksheet with the AI checkpoint storage sizing guide. Storage racks and their networking need their own power and cooling entries; they are not hidden inside the compute subtotal.
5. Why two power feeds do not automatically mean 2N
NVIDIA's best-practices presentation describes an N deployment pattern using two power circuits, each sized for half the rack's peak demand with required breaker deratings considered.[2] That wording matters: two circuits together providing required capacity is not the same promise as each independent path supporting the whole required load.
Use an explicit electrical worksheet rather than a picture of two PDUs:
| Worksheet field | Required entry before approval |
|---|---|
| Server cord map | PSU identifier to outlet, branch circuit, PDU and upstream path |
| Normal state | Load on every outlet, branch, phase and upstream element |
| Failure state | Remaining capacity and server power/performance state |
| Independence | Shared transformers, switchgear, controls and upstream dependencies |
| Maintenance state | Equipment isolated, operating constraints and rollback procedure |
| Approval | Vendor cord-map approval and responsible electrical engineer sign-off |
For an illustrative balanced three-phase estimate, use real power in watts divided by the product of the square root of three, line-to-line voltage and power factor. At an assumed 400 V and 0.95 power factor, the 29.6 kW rack corresponds to approximately 44.97 A aggregate line current if that full load is served by a single equivalent balanced three-phase path. The 58.2 kW rack corresponds to approximately 88.43 A under the same assumptions.
These are not breaker recommendations, outlet ratings, or instructions to connect a server to line-to-line voltage. The DGX B200 guide specifies 200–240 V AC inputs to its supplies.[1] The facility distribution must deliver compatible voltage at each server outlet. Real phase imbalance, circuit arrangement, local rules, derating and failure-state behavior require engineering review; the aggregate equation cannot approve them.
Purchase question: “Show the normal and failed-path load schedule and the server behavior for the exact cord map you propose.” An answer consisting only of total rack kilowatts is incomplete.
6. Air cooling versus liquid infrastructure: avoid a category error
This is an air-cooled DGX B200 example, as identified in the NVIDIA deployment presentation.[2] It is not a direct-to-chip liquid-cooled rack design. Do not buy a coolant distribution unit (CDU) merely because an AI planning template has a CDU field. First define which equipment transfers heat to liquid, where that heat transfer occurs, and what the manufacturer actually supports.
For the compute worksheet, treat the connected rack power as an approximate rack heat-load planning envelope. Keep unused capacity allowance separate from generated heat: reserving 35.52 kW does not mean a 29.6 kW load is emitting 35.52 kW. Obtain room-cooling approval for the selected maximum operating envelope and actual air paths, not a room-average temperature alone.
For a different, hypothetical liquid-cooled platform, the acceptance worksheet should split heat captured by liquid from residual room heat. Ask the supplier for the capture fraction and operating conditions, rather than assuming every watt enters the water loop. Request the approved coolant, water-quality limits, materials compatibility, filtration, supply-temperature range, flow and pressure requirements, allowable transients, leak response, and service procedure.
Those are procurement questions, not generic setpoints. A CDU's headline kilowatt rating is insufficient without its rated temperatures and flow conditions. Ask what capacity remains during maintenance, which pumps and controls share power, and what happens when the facility loop is unavailable. Do not substitute an internet water-flow formula for the vendor's hydraulic and thermal design.
7. Failure domains: count the jobs affected, not just devices
The four-server arrangement concentrates 32 hypothetical GPUs in one rack, versus 16 in the two-server arrangement. A rack-level event can therefore affect a different amount of scheduled capacity even though total cluster GPU count is unchanged. Whether a job survives depends on its software behavior and placement; this worksheet does not assume transparent recovery.
Build a dependency map for each rack: electrical paths, cooling zone, fabric leaf or rail, management network and storage reachability. Then ask the scheduler owner to show where a representative distributed job lands. Two servers in different cabinets may still share the same cooling zone or upstream distribution dependency. Physical separation alone is not evidence of independent failure domains.
Suggested design-review scenarios include one server PSU unavailable, an approved upstream power-path test, loss of a cooling unit, a network leaf unavailable, and loss of a management path. Agree which require continued full service, degraded operation, checkpoint-and-drain, or controlled shutdown. Do not induce several failures simultaneously merely to make a demonstration dramatic; each test needs a safe boundary and a way to attribute the result.
Network symptoms should be correlated with power and thermal telemetry. Before changing collective-communication settings, use the earlier NCCL slow AllReduce troubleshooting matrix to separate GPU, host, RDMA and fabric evidence. A reduced GPU power envelope and a fabric fault demand different corrective actions.
8. Deployment and acceptance checklist
The durable deliverable is a signed test matrix. The table below is a proposed plan, not an executed test report. Set numeric limits and observation windows with the responsible teams before deployment; do not invent pass thresholds after seeing the results.
| Test or review | Evidence to retain | Acceptance decision |
|---|---|---|
| Identity and support | Ordered chassis, firmware, software and source-document revisions | Match approved configuration |
| Physical installation | Weight, route, clearances, rack/rail and floor approvals | Facilities sign-off complete |
| Cord and phase audit | PSU-to-outlet map, phase loads, branch and upstream schedule | Correct mapping and approved capacity |
| Baseline workload | Workload version, input, power, inlet conditions, clocks and performance | Meet agreed healthy baseline |
| Sustained operation | Time-aligned electrical, thermal and application telemetry | No unexplained degradation or exceeded limits |
| Approved PSU scenario | BMC event, operating supplies, GPU power limits and job outcome | Match documented state and service commitment |
| Upstream-path scenario | Facilities-approved method, capacity measurements and application result | Meet explicitly agreed failure-state objective |
| Cooling alarm path | Safe alarm simulation and incident timestamps | Correct responders and actionable alert |
| Recovery | Restore steps, alarms cleared and baseline rerun | No unresolved condition or performance regression |
Only authorized facilities personnel should perform electrical isolation or cooling interventions under an approved method of procedure. For the initial integration phase, prefer safe alarm simulation and vendor-supported diagnostic checks over improvised live-fault experiments. Define stop conditions, communications and rollback before any intrusive work.
Keep the workload reproducible. Record the software image, workload parameters, placement, duration and telemetry interval. Capture normal and degraded states using the same workload where safe; otherwise explain the difference. A server that stays powered on has not automatically passed an application availability test.
9. What to buy, what to defer, and the practical takeaway
Choose the lower-density rack pattern when the approved power, cooling, access or failure-domain constraints favor it. Consider the denser pattern only when its complete support envelope is approved and the saved floor space justifies the concentration. If evaluating a liquid-cooled alternative, create a separate worksheet for that exact platform instead of modifying the B200 row by intuition.
Release the purchase order only when it includes the server configuration, approved rack and rails, power-distribution design, qualified cords, cooling design, network cable schedule, monitoring integration and acceptance scope. Separate installed capacity, normal consumption, failure-state capability and future expansion in the commercial comparison. They answer different questions and should have different evidence.
The immediate next step is simple: replace the example's GPU count, rack density and auxiliary allowance with your own approved inputs, then send the worksheet to both the infrastructure and facilities owners. Use the AI Infrastructure hub and Data Center hub for the connected compute, storage and fabric decisions.
Bottom line: a usable GPU rack is a verified power, heat-removal and service envelope—not a count of free rack units. The calculation identifies the questions; vendor documentation, qualified engineering and a witnessed acceptance test close them.
Post a Comment