September 25, 2026
Shortlist the providers that will answer one written request for quote (RFQ) line by line: a per-GPU-hour rate at a GPU count you set, managed scope itemized service by service, storage and networking priced on their own lines, and the term, delivery date, and support spelled out. However low it looks, a single node-hour or rack figure with no itemized scope can't be compared fairly until the provider fills in the GPU count, billing unit, term, and what the rate includes.
For managed HGX B200 and B300 clusters, send the RFQ to Together AI and Nebius, which both publicly list HGX B300 alongside managed Kubernetes, and to AWS for P6-B200 and P6-B300, where the managed layer has to be confirmed separately. For NVL72, include CoreWeave, Together AI, and Nebius, which quotes NVL72 on request. Put GMI Cloud on the list as well: GMI prices GPUs per GPU-hour, with networking and storage provisioned separately based on the workload, and all NVIDIA Blackwell hardware on GMI Cloud is currently in pre-order. Our managed clusters list H200 and B200 node types today. GB200 NVL72 and GB300 NVL72 are pre-order GPU platforms, and whether an NVL72 reservation includes a managed layer, and how far it goes, is set in the pre-order quote rather than in the current cluster catalog. B300 is a hardware option on Prime Inference, our dedicated inference service, and like the rest of our Blackwell lineup it is in pre-order. The comparison only holds once every quote uses the same unit, GPU count, and scope.
Managed Blackwell quotes usually differ in five ways before price even comes into it:
The RFQ below forces every provider to answer those five points in the same format.
Send the same text to every provider and ask for answers in the same order. A blank field is recorded as "not quoted," not as zero.
RFQ: managed Blackwell capacity
1. Systems and counts
- HGX B200: 72 GPUs (9 nodes) and 144 GPUs (18 nodes)
- HGX B300: 72 GPUs (9 nodes) and 144 GPUs (18 nodes)
- NVL72 (GB200 or GB300): 1 rack (72 GPUs) and 2 racks (144 GPUs)
2. Price
- Rate per GPU-hour for each system and count
- The unit you actually bill in (GPU, node, instance, rack) and GPUs per unit
- Minimum allocation and whether partial racks are sold
3. Managed scope (included / separate fee / not offered, per line)
- Kubernetes control plane and version upgrades
- GPU drivers, CUDA, and NCCL images
- Scheduler (Kubernetes, Slurm, or both)
- Monitoring and alerting
- Hardware failure detection and replacement
- NVL72 only: rack-scale NVLink fabric management, IMEX, Arm64 node images
4. Storage and networking, priced separately
- Shared file system, object storage, local NVMe
- Egress, ingress, public IPs, high-speed interconnect
5. Term and commitment
- Term lengths offered, prepaid vs. monthly, discount per term
- Price for added nodes or racks during the term
6. Delivery
- Delivery date or window, and what happens if it slips
- Current status of each system (available now or pre-order)
7. Support
- Response times, named contacts, and whether support is in the rate
8. Region or data center for each system
The GPU counts are chosen on purpose. Seventy-two GPUs is exactly nine 8-GPU nodes and exactly one NVL72 rack, so a provider can quote the same GPU count across all three systems. Quoting two sizes also shows whether the per-GPU rate steps down with scale. Some providers list minimum cluster sizes above 144 GPUs: Together AI's GPU Clusters page, for example, lists HGX B200 clusters from 256 GPUs and GB200 NVL72 clusters from 512 GPUs. Ask those providers to quote at their minimum size as well, and record that minimum in the "minimum billable GPU count" column.
Convert every price to one unit before comparing:
Rate per GPU-hour = price per billing unit per hour ÷ GPUs in that unit
A node-hour price for HGX B200 or B300 divides by eight, since NVIDIA's HGX platform is a single baseboard with eight Blackwell or Blackwell Ultra GPUs. A rack price divides by 72. Providers that split NVL72 into smaller instances need one more step: CoreWeave's documentation describes its GB200 instances as four GPUs per node and requires NVL72 instances to be deployed as full racks of 18 nodes, so a per-node figure divides by four and the minimum purchase is still 72 GPUs.
Then check the count behind the rate. Lambda's 1-Click Clusters page, for example, publishes per-GPU-hour rates for HGX B200 that step down at 16, 64, and 256 or more GPUs. A per-GPU rate is only comparable with another rate quoted at the same GPU count and term.
Minimum allocation changes the real bill. A team that needs 64 GPUs pays for eight HGX nodes, but on a provider that sells NVL72 only as full racks, the NVL72 option costs 72 GPUs' worth of hours. Put the minimum billable GPU count next to each rate and multiply by that, not by the count you need.
"Managed" means different things across providers. A per-GPU-hour rate only compares cleanly once you know what each quote covers. Record each line as included, separate fee, or not offered:
| Managed layer | What to ask for in the quote | Why it moves the comparison |
|---|---|---|
| Kubernetes control plane | Included, and who schedules version upgrades | Some providers charge nothing for it, others bundle it into the GPU rate |
| Node images, drivers, CUDA, NCCL | Who builds and patches them | This is ongoing engineering work if it lands on your team |
| Scheduler | Kubernetes only, Slurm, or both | Adding Slurm yourself is extra work to price in |
| Monitoring | GPU, node, and fabric metrics you can see | Missing visibility means building your own |
| Hardware replacement | Detection, replacement, and target time | A failed node on a rack system can hold up a whole job |
| NVL72 fabric | Rack-scale NVLink fabric management, IMEX, Arm64 node images | HGX nodes have NVLink too, but only inside each 8-GPU node; the rack-wide NVLink domain, IMEX across compute trays, and Grace Arm64 hosts add scope an HGX quote doesn't carry |
A lower GPU-hour rate that excludes two of these lines may cost more once the missing work is staffed. Price that work in engineer-hours per month and add it to the quote that leaves it with you.
Storage and networking belong on their own lines because providers treat them so differently. Nebius, for example, lists egress and ingress traffic as free and its Managed Service for Kubernetes at no charge, while object storage is billed by volume. Ask every provider for capacity pricing on the same storage size and type, plus expected egress, so the totals rest on the same assumptions.
Term needs the same care. A prepaid six-month rate and a monthly one-year rate aren't the same product, even at the same GPU-hour price. Compare them at the same term, or show both terms for every provider.
The delivery date is part of the quote. A lower rate on capacity arriving months later isn't equivalent to capacity available sooner, so record the date or window and the current status of each system next to the price. Support gets the same treatment: which response times and contacts come with the rate, and which cost extra.
Once the rates share a unit, GPU count, scope, and term, add everything for each option: GPU hours at the minimum billable count, the managed-layer fee if separate, storage, networking, support, and the engineering hours for any scope left with your team. Divide by the unit of work your team already tracks, such as training steps, completed fine-tuning runs, or served requests. Use throughput your team has measured for the same model rather than a provider's marketing figure.
Some differences survive every conversion. Note them next to the numbers instead of hiding them in the math:
Managed GPU Cluster provides fully managed, Kubernetes-based multi-node GPU clusters for distributed training and large-scale inference, with centralized cluster lifecycle management. It's in early access. Managed clusters list H200 and B200 node types, with B200 in pre-order like the rest of our Blackwell lineup. GMI provisions and operates these clusters inside GMI-operated data centers, with deployment across the US, APAC, and EU.
For the Blackwell rows of the RFQ:
The pricing structure fits the RFQ. GPU pricing is per GPU-hour and covers compute, while networking and storage are provisioned separately based on your workload. Committed usage plans are discounted compared with on-demand pricing. When you request a managed cluster in the console, the form offers pay-as-you-go billing, charged by the minute with no upfront cost, and clusters are billed either pay as you go or prepaid. You also choose the data center, Kubernetes version, worker node type, node count, and OS image. The summary panel then shows the estimated monthly cost as list price, discount, and estimated total. The Managed GPU Clusters documentation walks through the form. Requests aren't processed automatically: after submitting, contact support to activate the cluster. Additional nodes on an existing cluster go through Node Requests.
These providers sell Blackwell capacity with a managed layer, each with a different pricing unit, which is why they belong on the same RFQ:
Can we compare a partial NVL72 allocation with 8-GPU nodes? Only if the provider sells partial racks and states which NVLink domain the partial allocation sits in. Some providers sell full racks only, so ask for the minimum allocation in the RFQ before comparing.
Can GMI Cloud quote B300 for training? B300 is a hardware option on Prime Inference for dedicated inference, and like the rest of our Blackwell lineup it is in pre-order. For B300 training capacity, include providers that list HGX B300 in the RFQ. Use GMI's B200 pre-order quote for the managed-cluster rows, and for NVL72, ask whether the managed layer is included in the pre-order quote.
To answer the RFQ for B200 and NVL72 pre-order capacity, and whether the managed layer is included, plus the billing unit, term, and delivery window, talk to our team. Bring the GPU counts and storage assumptions you're sending to other providers, so every quote starts from the same numbers.
Colin Mo
GMI Cloud helps you architect, deploy, optimize, and scale your AI strategies
