What Should You Include in an RFQ to Get Like-for-Like Quotes for Managed B200, B300, and NVL72 Capacity?

The first field in a Blackwell RFQ should describe the workload and the metric that proves the capacity works, before any GPU model appears: the model, its precision, the job type, and a number such as step time or p95 latency that every bidder has to size against. After that come hardware counts in stated units, network and storage in stated units, managed scope and support, and a response sheet every bidder fills in the same way. A provider is worth shortlisting for like-for-like quotes when it can answer each of those fields as a separate line. On GMI Cloud GPU infrastructure, every GPU is dedicated and single-tenant and priced per GPU-hour, a unit the rest of the form can be converted into.

At GMI, the Blackwell rows of such an RFQ cover B200 worker nodes for managed clusters, B300 as a hardware option for Prime Inference, and GB200 NVL72 and GB300 NVL72 racks, all in pre-order today, while H100 and H200 are available now.

Start with the workload and the number that proves it

Bidders size capacity from whatever the RFQ gives them, so give them a workload and a target rather than a GPU count. Put these fields at the top of the form, each with the unit you expect back:

Then write the acceptance metric as a test a bidder could run on the allocation it proposes. A training version might read: sustain [N] tokens per second on [model] at BF16, global batch [B], 8K sequence length, across the full allocation for two hours. An inference version: complete [R] requests per second for one hour at 2,000 input and 500 output tokens and [C] concurrent requests, with p95 time to first token under [T] ms and p95 end-to-end under [E] ms. Ask every bidder to name the system and GPU count it would use to pass that test. Each quote becomes a sizing claim tied to your workload, and claims built on different hardware can still be compared.

Hardware fields: count, billing unit, and topology

Blackwell capacity is sold in units that don't share a denominator. NVIDIA's HGX B200 and HGX B300 platforms carry eight GPUs per baseboard. NVIDIA describes the GB200 Grace Blackwell Superchip as two Blackwell GPUs paired with one Grace CPU, and a GB200 NVL72 rack as 36 Grace CPUs and 72 Blackwell GPUs in one NVLink domain. Quotes per node-hour, per superchip-hour, and per rack-hour can all be correct and still describe three different GPU counts. Each hardware row should ask for:

• Exact system name. HGX B200, HGX B300, GB200 NVL72, or GB300 NVL72, never a GPU name alone.
• GPUs requested and minimum billable GPUs. Two numbers, since a seller that bills by the rack bills 72 even when you ask for 64.
• GPUs per billing unit. The one field that makes every later conversion safe.
• NVLink domain size. Eight GPUs on an HGX node, 72 on an NVL72 rack.
• Memory per GPU, in GB. It sets how many GPUs a model plus its KV cache or optimizer state needs.
• Host CPU and system memory per node. Architecture (x86 or Arm64 Grace), CPU-to-GPU link (PCIe or NVLink-C2C), cores, and RAM in GB, because Arm64 hosts change which container images run unmodified.
• Local NVMe per node. Capacity in TB, drive layout or RAID level, and sustained read and write in GB/s, since checkpoint staging depends on throughput as much as on size.

Two mis-fills recur here. "One NVL72" with no word on partial racks gets answers in different shapes. A blank memory field makes a B300 bid and a B200 bid look like one product at two prices, even though the two GPUs carry different amounts of HBM and hold different model sizes per GPU.

Network, storage, and support fields in shared units

• Scale-out fabric. Bandwidth in Gb/s per GPU, the technology (InfiniBand or RDMA over Ethernet), whether the fabric is rail-optimized, and the oversubscription ratio between racks. Gb/s and GB/s differ by a factor of eight, so spell out "gigabits" on the form.
• Shared storage. Usable capacity in decimal TB, the type (parallel file system, NFS, or object), and aggregate read and write throughput in GB/s. Derive the write figure from checkpoints. Assume a 2 TB checkpoint that must land in five minutes, and the file system needs about 6.7 GB/s of sustained write across the cluster.
• Data movement. Expected egress in TB per month and the number of public IPs, so every bidder prices the same traffic.
• Managed scope. Kubernetes control plane, node images and drivers, scheduler, monitoring, and hardware replacement, each answered as included, separate line, or not offered.
• Support. First-response time in hours for each severity level, the time to swap a failed node back into service, coverage hours (24_7 or business hours in a named time zone), and whether a named engineer is assigned. "Support included" without a severity table can't be scored.

The response sheet every bidder returns

Attach a response sheet with one row per RFQ field and fixed columns, and accept nothing else as the technical answer. Prices go on a separate tab keyed to the same field numbers, so the technical comparison is finished before anyone looks at a rate. The rows below are illustrative values, not a quote:

Field                       Requested    Quoted     Unit            Status          Deviation / assumption
1.8 GPUs to pass the test   -            64         GPUs            -               HGX B200, 8 nodes, passes test
2.3 GPUs per billing unit   -            8          GPUs per node   -               -
3.1 Scale-out bandwidth     400          400        Gb/s per GPU    included        RDMA over Ethernet
3.2 Shared storage          500          500        TB usable       separate line   parallel file system
4.2 Node image patching     provider     customer   -               not offered     customer builds images

The first row is where a bidder commits its sizing to your acceptance test, and every other row describes the allocation behind that number. A few rules keep the sheet honest:

• Status takes one of four values: included, separate line, not offered, or not quoted. A blank cell counts as not quoted, never as zero.
• Any difference from the requested value goes in the deviation column with its reason, not in a cover letter.
• An alternative system gets its own sheet, so a B200 alternate never overwrites the B300 row it replaces.
• Every sheet carries a validity date for the configuration and for the pricing tab.

Delivery dates, minimum commitments, and capacity guarantees go on a tab of their own, since weighing them takes a timeline comparison rather than a column.

When two answers still don't line up

Work through mismatched answers in a fixed order:

1. Run one written clarification round. Answer bidder questions in writing and send every answer to all bidders, with the asker's name removed.
2. Convert units only with the bidder's own numbers. If GPUs per billing unit is missing, ask for it. A conversion you infer yourself can open a price gap that isn't really there.
3. Price scope gaps yourself, in the open. When one bid leaves node images or the scheduler to your team, add an internal line in engineer-hours per month and label it as your estimate.
4. Score alternates on the total cost of passing your test. Multiply billed GPUs by billed hours by that system's rate, then add the network, storage, and support lines in the same scope. A bid offering more B200 GPUs in place of fewer B300 GPUs can land above or below the original on that total, whatever its per-GPU rate.
5. Keep availability apart from price. An available-now row and a pre-order row stay in separate columns.
6. Pin conditional answers. "Depends on term" gets one follow-up asking for the answer at the term the RFQ specified.

GMI's answers for cluster and inference lots

For cluster lots, Managed GPU Cluster (early access) provides fully managed, Kubernetes-based clusters with H200 or B200 worker nodes, provisioned and operated by GMI. The request form described in the Managed GPU Clusters documentation captures billing method, data center, Kubernetes version, worker node specification, node quantity, and OS image, which map directly onto the hardware and managed-scope fields.

For inference lots, Prime Inference runs your model on reserved single-tenant GPUs with runtimes our engineers tune per model, and B300 is one of its hardware options. Its quotes are tailored to the model and traffic profile, the same details your workload block already spells out.

FAQ

Can one RFQ cover both training and inference capacity?

It works best as two lots in one document. Training lots are sized on step time or tokens per second across the allocation, and inference lots on requests per second at a p95 latency, so a single acceptance test can't serve both. Separate lots also let you award each one to a different provider.

Should the RFQ include our budget?

Holding it back in the first round keeps bidders sizing to the workload instead of to a number. Once the technical sheets are scored, sharing a budget range with the shortlist opens the commercial levers, such as a longer commitment term or a different payment schedule, along with alternative systems that still meet your throughput and latency targets.

Send us the workload section first

Send the workload fields and acceptance metric to our team and ask for the answer in your response-sheet format. Include the lots, GPU counts, and storage and egress assumptions you're giving every other bidder, so our configuration and line items sit in the same columns as theirs.