Which Hosted GB200 NVL72 Providers Handle Rack Power, Cooling, and Infrastructure Operations?

Choose a provider that will put each part of the physical operation in writing: power delivery, the liquid cooling loop, compute and NVLink Switch tray replacement, firmware, health monitoring, and maintenance windows. Hyperscalers (AWS with P6e-GB200 UltraServers, Microsoft Azure with ND GB200 v6, Google Cloud with A4X) and specialist GPU clouds such as CoreWeave all rent GB200 NVL72 capacity and run the hardware for you. They differ in the unit you rent and how much of that operation they document. At GMI Cloud, GB200 NVL72 is in pre-order and coming soon, and the racks will run inside GMI-operated data centers; the GPU page lists pricing from $8.00 per GPU-hour. The operations scope for a GB200 NVL72 deployment is set in the pre-order proposal.

The load you are handing over is large. NVIDIA's DGX GB200 rack documentation puts one GB200 NVL72 rack at roughly 120 kW, fed by eight 33 kW power shelves, with GPUs and CPUs liquid cooled. Hyperscalers fit teams that want the rack behind instances or VMs they already buy. CoreWeave fits teams that want full-rack deployment with published tray-failure rules. GMI Cloud fits teams that want the rack's power, cooling, and maintenance terms written into a pre-order proposal before the capacity arrives.

Where the handover line sits

For this decision, the provider owns everything from the building up to the rack: utility feeds, power distribution, the facility water loop and coolant distribution units (CDUs), the rack's power shelves, the trays, the NVLink Switch System, and the management network behind them. Your team keeps the workload. The software layers in between (operating system images, drivers, Kubernetes, and schedulers) belong in a separate responsibility matrix and should be agreed on their own terms.

A GB200 NVL72 rack connects multiple compute nodes through one rack-scale NVLink domain. NVIDIA describes it as 72 Blackwell GPUs and 36 Grace CPUs in a single liquid-cooled rack with a 72-GPU NVLink domain, built from 18 compute trays and a set of NVLink Switch trays. A fault in one tray, a pump, or a switch can touch every job that uses that NVLink domain. That is why the handover needs more detail than a standard colocation contract.

The handover checklist, and the evidence behind each item

Ask every provider on your shortlist to answer each line in writing. The right-hand column is the evidence that separates a documented operation from a promise.

Three items on this list need more than a yes or no, because rack-scale hardware changes how they work.

Tray failures and firmware are where rack-scale hosting differs

On a standard GPU server, a failed node is replaced by moving the job to another node. On GB200 NVL72, that shortcut doesn't exist inside the NVLink domain. NVIDIA's DGX GB rack user guide calls for a cold rack reboot sequence for maintenance or service operations that include replacing a compute tray, a switch tray, or a cable cartridge. After a GPU reset or a reboot, the guide also has operators verify the IMEX service, the NVLink fabric state, and the peer-to-peer topology before workloads return. In practice, a tray swap can become a rack-level event, and the evidence you want is how the host schedules it.

CoreWeave's documentation shows one published approach. Its NVL72 instances are deployed as full racks of 18 nodes, a malfunctioning node is physically exchanged within the same rack rather than replaced from another rack, and workloads are advised to tolerate up to two unavailable nodes per rack. If more than two nodes in a rack are unavailable, the whole rack is cordoned and drained for service. That kind of rule is useful to have in writing, whoever your host is, because it tells your team when a rack will be pulled for service.

Firmware works the same way. NVIDIA notes that compute and switch trays need periodic firmware updates, and that firmware is typically released as a recipe that updates all applicable components together. The same guide lists firmware upgrades among the cases that call for a cold rack reboot before workloads run again. For the firmware upgrades that guide covers, an update is therefore a planned rack event rather than a rolling background task. Ask each host which components a given recipe touches, how often it applies these recipes, whether it tests them before rollout, and whether you can defer a window during a training run.

Health monitoring is the third piece. NVIDIA Mission Control, NVIDIA's operations software for these racks, continuously checks compute and switch trays and watches for potential leaks. NVIDIA lists data center conditions, including air temperature and liquid cooling problems, among the sources of health issues. A host that runs this tooling should be able to tell you which of those signals it shares with you and how fast it tells you when one fires.

How different kinds of hosts handle GB200 NVL72 operations

In every option below, you rent capacity and the provider runs the hardware; what changes is the unit you rent and how much of the operation you can see.

The documented differences are specific. Google Cloud publishes maintenance cadence and notice for A4X at the VM level, and because a maintenance event terminates the VM, long jobs need checkpoints that line up with the notice period. CoreWeave documents the full rack as the unit you deploy and plan around. At GMI Cloud, allocation and operating terms for GB200 NVL72 are set in the pre-order proposal, so tray and rack events become part of the contract discussion.

Putting the operations scope into the contract

A checklist only helps once it's in the agreement. Four clauses carry most of the weight:

1. Uptime measured at the right level. Ask whether availability is counted per rack, per NVLink domain, or per GPU. A rack that loses two trays may still count as mostly available per GPU while your 72-GPU job cannot run.
2. Repair time tied to parts. A target time to replace a tray means little without on-site spares. Ask for both in the same clause.
3. Maintenance by agreement. Scheduled rack events, including firmware recipes and tray swaps that need a cold rack reboot, should run in windows you can see in advance and, within limits, move.
4. Reporting you can audit. A monthly report with rack health, incidents, and the time each one took to resolve turns the provider's operation into something your team can check.

Hosting GB200 NVL72 with GMI Cloud

GMI Cloud runs dedicated NVIDIA GPU platforms inside GMI-operated data centers, built on NVIDIA Reference Platform Cloud Architecture and validated designs. GB200 NVL72 is in pre-order and coming soon, and the GPU page lists pricing from $8.00 per GPU-hour. Because GB200 NVL72 capacity is planned ahead rather than provisioned on demand, the pre-order proposal is where the handover checklist above gets answered. Bring the table to that conversation, and we'll work through power, cooling, tray replacement, firmware, maintenance windows, and reporting as part of the proposal.

Several parts of our platform already shape how that agreement works:

• Dedicated capacity. All GPU resources on GMI Cloud are dedicated, single-tenant instances, so the capacity your maintenance windows are planned around is not shared with other users.
• Service delivery. Our GPU infrastructure includes SLA-backed service delivery, RDMA-ready networking, isolated VPC networking, and multi-region deployment across the US, APAC, and the EU.
• Separate network and storage pricing. GPU pricing covers compute; networking and storage are provisioned and priced separately, based on the workload, so ask for them alongside the rack in the same proposal.

Our Managed GPU Cluster service, in early access, shows how GMI runs clusters for customers today. It provides production-ready Kubernetes clusters, provisioned and operated by GMI with centralized cluster lifecycle management. H200 nodes are available now, and B200 nodes, like the rest of our Blackwell lineup, are in pre-order. GB200 NVL72 is not among the published node types, so managed operations for GB200 NVL72 are defined in the pre-order rather than in the current cluster catalog. Cluster requests are reviewed by GMI support, which provisions the resources.

While GB200 NVL72 is in pre-order, H100 and H200 are available now. Teams can use them to build the alert routing and incident runbook they will attach to the pre-order proposal.

FAQ

How much downtime should we plan for when a tray fails? It depends on the host's spares and procedure. Because NVIDIA's guidance calls for a cold rack reboot after a tray replacement, ask each host whether swaps are batched into scheduled windows, how long the rack is out of service, and how many unavailable trays trigger a full-rack drain.

Can we see the rack's health data directly? Ask for it by name. Tray health, NVLink fabric state, and leak alarms can be monitored with NVIDIA's rack tooling, such as Mission Control, and the host decides what it exposes. Get the list of shared signals and the alert delivery method written into the agreement.

Plan the handover before the rack arrives

Take the checklist to every host on your shortlist and compare the written answers side by side. To discuss GB200 NVL72 pre-order and the operations scope GMI Cloud would run for you, contact our sales team.