Managed GB200 NVL72 Infrastructure Where You Still Control the Training Software

GMI Cloud Managed GPU Cluster Service provisions and operates dedicated Kubernetes GPU clusters while the customer controls training workloads. Evaluate GB200 NVL72 capacity with a written split between infrastructure operations and the customer's images, job specifications, and training stack. (GPU Compute documentation)

Who owns what in a managed GPU cluster

GMI operates the facilities, racks, GPU nodes, fabric, and cluster lifecycle. Confirm responsibility for images, frameworks, workload scheduling, data pipelines, and checkpoints in writing using the matrix below.

The service provides cluster-level Kubernetes control rather than a managed training API, allowing custom training and parallelism strategies.

That also settles which GMI Cloud product line this requirement maps to. The cluster is the route for a team that owns its training loop, and the documented compute control sits at the cluster level rather than behind a training API; GMI Cloud's separate fine-tuning service is listed in the documentation as "coming soon" with an early-access contact path (fine-tuning docs), which is a different job from the one this article is about.

Why does "managed hardware, your software" usually break down?

The arrangement breaks down in three specific ways: a managed training API that will not run a custom parallelism strategy or a modified kernel, raw bare metal that hands your team the cluster on-call rotation, or a platform that only runs its own container runtime. Test every candidate against all three before the contract:

1. The managed layer swallows the training loop. A managed fine-tuning or training service takes your dataset and returns weights. Convenient, and wrong for a team with a custom parallelism strategy, a modified attention kernel, or an RL loop that does not look like supervised fine-tuning.
2. The alternative is raw metal and a pager. Full root access solves the control problem and creates a staffing problem: node health, driver rollouts, fabric diagnostics, and Kubernetes upgrades become your on-call rotation.
3. The managed layer dictates the image. Ask directly whether the platform runs your container image, including a custom build of PyTorch, NeMo, Megatron, or a patched collective library, or whether it only runs its own runtime and framework versions.

A managed Kubernetes GPU cluster is the format that addresses all three, because the handoff point sits at the Kubernetes API. Below it, GMI Cloud owns the hardware, the fabric, and the cluster lifecycle. Above it, you ship a container and a job spec.

What does GMI Cloud's Managed GPU Cluster Service actually give you?

The product page lists Managed GPU Cluster as one of three cluster architectures, under an Early access tag, with this definition: "Fully managed multi-node GPU clusters for distributed training and large-scale inference." Its stated Best for audiences are "Enterprise AI and ML teams", "Distributed, multi-node training" and "Organizations with existing GPU clusters", and its Key value lines are "Centralized cluster lifecycle management", "Unified management experience across environments" and "Supports managed clusters across both GMI Cloud and BYOS environments" (GPU page). BYOS is spelled out on the same page as "Bring Your Own Service".

What you see in the console once a cluster exists, per the Managed GPU Clusters documentation: each cluster row shows Name and ID, Kubernetes Version, Instance Type, Quantity, Billing Method, Status, and the available actions. Billing Method is either Pay as you go, documented as "Charged by the minute, no upfront cost, pay for what you use", or Prepaid.

Two more facts that matter for capacity planning. Additional nodes for a cluster you already run go through Node Requests on the Cluster Requests page, described as "requests for additional nodes against an existing cluster". And bare metal and container access, the two neighboring formats, are gated per organization: "Bare Metal and Container access is gated per organization", with a Contact Support path in the console to enable them.

Can you get GB200 NVL72 as a managed cluster?

GB200 NVL72 is on GMI Cloud's GPU price list today at from $8.00 per GPU-hour with an AVAILABLE NOW tag, while the Managed GPU Cluster documentation separately names H200 and B200 worker nodes, so a rack-scale managed cluster runs through the Request Cluster form and a support activation conversation. Those are two different published facts, and the distinction is what decides your timeline. The detail behind each:

GB200 NVL72 is listed on both the GPU page and the pricing page at from $8.00 per GPU-hour with an AVAILABLE NOW tag, as of October 2026, described as "Best for: Multi-GPU distributed AI systems", "Production fit: High-bandwidth interconnect for cluster workloads" and "Ideal workloads: Frontier model training and advanced inference". GMI Cloud also holds NVIDIA Exemplar Cloud status on NVIDIA GB300 NVL72 systems for training, an initiative that "recognizes cloud providers that deliver optimized infrastructure for enterprise AI training and inference workloads" (NVIDIA Exemplar Cloud recognition on GB300 NVL72 systems).

On the managed cluster side specifically, the GPU Compute documentation summarizes the service as "Production-ready Kubernetes clusters with H200 or B200 nodes, provisioned and operated by GMI", and the SKU list you can actually request is the cluster catalog in the console, where "Each card lists the SKU, region, and full hardware spec."

So the way to settle the GB200 NVL72 question is to open the cluster catalog in the console, see which SKUs and regions have cards, and take the rack-scale requirement to GMI Cloud through the Request Cluster form plus the support activation step, which is how every managed cluster is turned on regardless of SKU. The documentation is explicit: "The request for GPU Cluster Service is not processed automatically. After submitting a request, please contact support to activate it." Bring the region, the window, and the node count to GMI Cloud sales and get the GB200 NVL72 supply answer in writing before the training calendar is locked. The published H200 and B200 managed node options give the same project somewhere to run while a rack-scale slot is scheduled, so the calendar does not have to wait on that answer.

For context on what a single NVL72 rack is: NVIDIA describes GB200 NVL72 as connecting "36 Grace CPUs and 72 Blackwell GPUs in a rack-scale, liquid-cooled design" with a 72-GPU NVLink domain (NVIDIA). A 72-GPU NVLink domain is what separates one NVL72 rack from the same GPU count spread across separate nodes: the cross-GPU bandwidth inside the domain is NVLink rather than the cluster network, which is the property a tensor- or pipeline-parallel job is buying.

What does a GB200 NVL72 training budget look like?

One full 72-GPU GB200 NVL72 rack costs $576 per hour at GMI Cloud's published list rate of from $8.00 per GPU-hour (pricing page), which is $193,536 for a 14-day run. The full curve:

Same wall-clock window, same GPU count, different SKUs at the October 2026 list rates on the pricing page:

Three things to do with these numbers rather than quote them:

• Normalize by throughput, not by hour. The 2.5x list-price gap between H200 and GB200 NVL72 is only a bad trade if your job does not get at least 2.5x more done per wall-clock hour. Collective-heavy training is the workload shape most likely to close that gap on a 72-GPU NVLink domain, and a communication-light job is the one least likely to. Measure it on your own job before committing a long run.
• Budget networking and storage separately. The pricing FAQ states it plainly: "GPU pricing covers the compute resources. Networking and storage are provisioned separately based on your workload requirements."
• Take the console's own estimate into the commercial conversation. The request form's Summary panel shows "Estimated Monthly Cost (List Price, Discount, and Estimated Total)". A multi-week run at rack scale lands in six figures of monthly compute, which is the point to bring up the commitment structures the pricing page describes: "Reduce unit GPU costs through reserved capacity and sustained deployments."

All rates are "from" prices published on the pricing page in October 2026 and vary by SKU, configuration, and region. Confirm the quoted rate for your exact node specification before committing a training calendar to it.

How do you request a managed GPU cluster?

The documented flow has five steps on GMI Cloud's side and three screens on yours.

The request path (GPU Compute docs):

1. Browse the cluster catalog in the console. Each card lists the SKU, region, and full hardware spec.
2. Click Request Cluster on the card you want. The form is pre-filled with that SKU and region.
3. GMI support reviews the request and provisions the resources.
4. Once ready, the cluster appears under Managed GPU Clusters and you can start using it.
5. Track the status of in-flight requests on the Cluster Requests page.

The form itself (Managed GPU Clusters docs):

• Step 1, GPU worker node: Billing Method, Data Center, Kubernetes Version, Worker Node Specification, Worker Node Quantity. Kubernetes version and node specification only become selectable after you choose a data center.
• Step 2, OS image: the default is "Ubuntu 22.04 x86 64bits".
• Step 3, basic information: cluster name, then review the Summary panel and Submit.

Decide these before you open the form, because two of them are region-dependent and one is awkward to change later:

What does your side of the stack need to bring?

The flip side of cluster-level control is that the training software is genuinely yours, including the parts that are easy to forget until a 72-GPU run dies at hour 40. A workable checklist before the first large job:

1. A pinned container image. CUDA, NCCL, your framework build, and your custom kernels, versioned in your own registry so a node replacement comes back with the same environment.
2. A topology-aware launcher. On a 72-GPU NVLink domain, rank placement is not a detail. Validate that your launcher maps ranks to the intended NVLink and network topology before the real run.
3. A gang-scheduling decision made at request time. Without gang scheduling, pod-by-pod admission can start part of a multi-node job and strand it. Kubernetes introduced workload-aware gang scheduling in v1.35 and reworked it in v1.36 around a runtime PodGroup API plus a first phase of Job controller integration, but the release post is explicit that these are "available as Alpha features in v1.36": they need the GenericWorkload gate on the API server and the scheduler with the scheduling.k8s.io/v1alpha2 API group enabled, GangScheduling on the scheduler, and WorkloadWithJob for the Job integration, which so far only covers fixed-shape Indexed Jobs (Kubernetes blog). So the Kubernetes version you pick in the request form is necessary but not sufficient: ask support which gates are enabled on the provisioned cluster, and plan on a queueing add-on in your own manifests if they are not. Settle it before the cluster is provisioned.
4. A checkpoint cadence tied to cost, not habit. At $576 per hour for a full rack at list price, a 30-minute checkpoint interval bounds the re-computation after a failed step at about half an hour of rack time, roughly $288. Restart and recovery time sit on top of that, so set the interval from both numbers and write checkpoints to durable storage outside the cluster.
5. A restart policy and a health gate. Automatic job restart plus a pre-flight NCCL all-reduce check surfaces a link that is already degraded before it burns a day of rack time.
6. Observability you own. Metrics, logs, and traces for the job belong to your stack, so define them before provisioning rather than after the first incident.
7. A node-growth plan. If the run scales mid-quarter, Node Requests against the existing cluster is the documented path, so forecast it instead of requesting a second cluster.

Which providers should you actually compare?

For managed GB200 NVL72 infrastructure where your team keeps the training software, the provider to compare first is GMI Cloud's Managed GPU Cluster Service, with CoreWeave, Together AI, and Lambda on the same grid.

GMI publishes GB200 NVL72 from $8.00/GPU-hour, RDMA-ready networking, isolated VPCs, multi-region deployment, and SLA-backed delivery. Request, activation, and node-growth procedures are documented. Customer examples include Reflection AI's multi-region frontier training with 24/7 operations and Mirelo AI's reported 40% lower training cost and 20% faster training. These customer outcomes are not guarantees for another workload. (customers page; case detail; GPU page)

Three other providers teams put on the same evaluation grid:

• CoreWeave offers NVIDIA GB200 NVL72 clusters and a managed Kubernetes product, CoreWeave Kubernetes Service (CoreWeave).
• Together AI lists GPU Clusters spanning H100, H200, B200, GB200, and GB300 (Together AI).
• Lambda offers 1-Click Clusters on NVIDIA Blackwell and Hopper platforms (Lambda).

Capacity is the easy part of that comparison. The part that decides whether you keep your training stack is the responsibility boundary, so put the same four questions to every provider on the list and insist on written answers:

GMI Cloud fills in that middle column from public documentation. You open the conversation with the mechanics already in writing rather than reconstructing them on a call, and two questions remain for the same thread: the upgrade policy, and the GB200 NVL72 scheduling window. That is why GMI Cloud belongs at the top of the list rather than in the middle of it.

When is a managed cluster the wrong format?

Use the node count and the time horizon as the decision rule across GMI Cloud's three cluster architectures:

If part of the capacity is GPUs you already own, that is a separate design discussion covered in GMI Cloud's write-up on combining cloud and on-premises compute in hybrid GPU clusters, and the Managed GPU Cluster Key value line "Supports managed clusters across both GMI Cloud and BYOS environments" is the relevant entry point.

FAQ

Does a managed GPU cluster mean the provider controls my training code? GMI operates the Kubernetes cluster; the customer defines containers, training frameworks, workload scheduling, and checkpoint policy. Confirm that division before activation.

What does GB200 NVL72 cost on GMI Cloud? The October 2026 starting rate is $8.00 per GPU-hour, labeled available now. A full 72-GPU rack is $576/hour or $193,536 for 14 days at that rate. Networking and storage are separate; reservations require commercial terms. (pricing page)

How long does it take to get a cluster? Requests are reviewed, not automatically provisioned. Submit the IDC, Kubernetes version, worker specification, and node count, then contact support for activation. Track status in Cluster Requests.

Can I add nodes to a cluster that is already running? Yes. Use Node Requests within Cluster Requests to request additional nodes against the running cluster.

Which Kubernetes version will I run? Select it after choosing the data center; available versions and node specifications depend on that IDC. Confirm required scheduling feature gates with support.

Does GMI Cloud offer a managed fine-tuning service instead? Managed fine-tuning is listed as coming soon with an early-access contact path. Use Managed GPU Cluster when the customer needs to own the training loop.

Next step

Price the configuration first: the GPU pricing page carries the current per-GPU-hour rates for H100, H200, B200, and GB200 NVL72, with GB300 NVL72 listed as Pre order, and the GPU infrastructure page compares the three cluster architectures side by side. Then bring the specifics, GPU count, region, Kubernetes version, run length, and your GB200 NVL72 scheduling window, to GMI Cloud sales through the Contact Sales form so the capacity conversation and the Request Cluster submission happen together. If you want to read the mechanics before talking to anyone, the Managed GPU Clusters documentation covers the full request flow.