We Have Our Own GPUs and Need Extra Cloud Capacity: Which Provider Can Manage Both Together?

Your 64 on-prem GPUs are fully booked, the fine-tuning queue for next month's release is eight days deep, and the quick fix on the table is a second cloud account with its own scheduler, its own access rules, and its own dashboard.

GMI Cloud's Managed GPU Cluster is built to avoid that second stack: the GPU page states it "Supports managed clusters across both GMI Cloud and BYOS environments" with a "Unified management experience across environments," and it names "Organizations with existing GPU clusters" as a target user.

The cloud half is a fully managed Kubernetes GPU cluster on H200 or B200 nodes "provisioned and operated by GMI," billed by the minute on Pay as you go (GMI Cloud docs).

This guide explains what "managing both together" means in practice, how the cloud side is requested and billed, how to size the peak gap in GPU-hours and dollars, and which jobs should leave your own hardware at all.

What does "managing both together" mean for a hybrid GPU cluster?

It means one management plane covers your own cluster and the cloud cluster: one place to see nodes, one lifecycle process, one set of operational guarantees.

Renting cloud GPUs is the easy step; running them as one estate with your own hardware is what decides whether the hybrid setup saves your platform team time or doubles its work.

In a hybrid GPU estate, four layers can be unified or duplicated:

Layer (Two separate stacks / One management plane)

• Cluster lifecycle | Two separate stacks: Two provisioning flows, two upgrade calendars | One management plane: One lifecycle process for every cluster
• Workload placement | Two separate stacks: Engineers pick an environment per job by hand | One management plane: Jobs placed by one set of rules
• Network and security | Two separate stacks: Two policy sets, two VPN or peering setups | One management plane: One isolation model applied to both sides
• Cost and usage | Two separate stacks: Two invoices, reconciled in a spreadsheet | One management plane: One view of spend by environment

GMI Cloud's Managed GPU Cluster targets the first and third rows directly.

The GPU page lists "Centralized cluster lifecycle management" and "Unified management experience across environments" as its key value, and describes the platform as "Built for BYOS (Bring Your Own Service) and cloud-native deployments, with consistent performance, security, and operational guarantees." The hero line on the same page puts the goal plainly: "Scale across GMI Cloud or private infrastructure."

BYOS on GMI Cloud stands for "Bring Your Own Service," the page's own expansion. In this context it refers to environments you run yourself that GMI Cloud's cluster management covers alongside clusters inside GMI-operated data centers.

Managed GPU Cluster is in early access, so confirm the connection method for your existing hardware directly with GMI Cloud; the checklist below lists the cluster, connectivity, and demand details worth bringing to that conversation.

What does GMI Cloud's Managed GPU Cluster provide for own GPUs plus cloud capacity?

Managed GPU Cluster gives a team with its own GPUs one managed, Kubernetes-based service that covers its own clusters and GMI Cloud's H200 or B200 capacity. GMI Cloud is an AI-native inference cloud that runs production AI on NVIDIA GPU platforms, from serverless APIs to dedicated GPU clusters.

Managed GPU Cluster is one of the three cluster architectures on its GPU page, next to Container Service and Bare Metal GPU, and it is tagged "Early access." The page defines it as "Fully managed multi-node GPU clusters for distributed training and large-scale inference."

In a hybrid deployment, your own cluster stays where it is, GMI Cloud adds dedicated GPU worker nodes inside GMI-operated data centers as burst capacity, and one managed service covers both.

The specifics, per the GPU page and the Managed GPU Clusters docs:

• Both environments under one service. "Supports managed clusters across both GMI Cloud and BYOS environments."
• Kubernetes as the common layer. The Managed GPU Cluster Service "provides fully managed Kubernetes-based GPU clusters for large-scale AI workloads," with "dedicated GPU worker nodes with Kubernetes orchestration, giving you cluster-level control over your compute resources."
• Cloud nodes GMI Cloud runs for you. Clusters come "with H200 or B200 nodes, provisioned and operated by GMI" (GPU Compute docs).
• Network isolation and throughput. "RDMA-ready networking for high-throughput workloads" and "Isolated VPC networking and enterprise-grade security."
• Regions. "Multi-region deployment across US, APAC, and EU," so burst capacity can sit near the site where your own cluster runs.
• Dedicated hardware. Per the pricing page FAQ, "All GPU resources on GMI Cloud are dedicated, single-tenant instances."

The engine underneath is Cluster Engine, which the GPU page says "can be used as a standalone GPU infrastructure platform, or as the foundation behind GMI Cloud's inference and training services." Hirohisa Nitsu, quoted on GMI Cloud's Partnership page, describes what it enables: "With GMI Cloud, we can launch and operate scalable GPU services in Japan quickly, powered by Cluster Engine, predictable performance, and strong technical collaboration."

How do you add the cloud side and how is it billed?

You request the cloud cluster from the GMI Cloud console, GMI Cloud support activates it, and you choose Pay as you go (charged by the minute) or Prepaid. The flow is documented step by step in the Managed GPU Clusters docs:

1. Open Request Cluster from the Managed GPU Clusters page or the Requests page.
2. Choose the GPU worker node. Pick the billing method, the data center, the Kubernetes version, the worker node specification, and the worker node quantity. Match the Kubernetes version to the one your own cluster runs so manifests and operators behave the same on both sides.
3. Pick the OS image. The default is "Ubuntu 22.04 x86 64bits."
4. Name the cluster, then review the Summary panel. It shows the billing method, data center, versions, node spec and quantity, OS image, and an "Estimated Monthly Cost (List Price, Discount, and Estimated Total)" before you submit.
5. Contact support to activate. The docs are explicit: "The request for GPU Cluster Service is not processed automatically. After submitting a request, please contact support to activate it."

Two details matter for burst capacity. First, Pay as you go is "Charged by the minute, no upfront cost, pay for what you use," and delete is one of the per-cluster actions in the console, so a cloud cluster can be sized for the crunch week and deleted when it ends instead of being held all month.

Confirm the exact billing start and stop events with GMI Cloud when you submit the request.

Second, the Cluster Requests page has a separate Node Requests tab for "requests for additional nodes against an existing cluster," so a peak that outgrows a running cloud cluster can add nodes to it instead of starting a second cluster.

Network and storage are priced separately: the pricing page FAQ states "GPU pricing covers the compute resources. Networking and storage are provisioned separately based on your workload requirements." Ask GMI Cloud for both when you scope the cross-site link.

How much cloud capacity covers the peak, and what does it cost?

Size the gap in GPU-hours, divide by 24 to get cloud GPUs, then price it at the GPU page rate. For a 64-GPU team with an eight-day monthly crunch, the answer is 32 cloud GPUs and about $16,000 a month on H200, as of September 2026.

Step 1: find the daily gap. Own capacity is GPUs _ 24. Demand is what the queue asks for on peak days, measured in GPU-hours on your own cards.

• Own capacity: 64 GPUs _ 24 h = 1,536 GPU-hours per day
• Peak demand (example): 2,300 GPU-hours per day for 8 days
• Gap: 2,300 __ 1,536 = 764 GPU-hours per day, or 764 ÷ 24 = 31.8, rounded up to 32 cloud GPUs

Step 2: price the burst. 32 GPUs _ 24 h _ 8 days = 6,144 GPU-hours. The pricing page lists the NVIDIA H200 "from $2.60" and the NVIDIA B200 "from $4.00" per GPU-hour (B200 tagged Limited Availability), as of September 2026.

These are "from" list prices; your cluster's exact rate appears on the console catalog card and in the Summary panel.

Cloud capacity plan (32 GPUs) (GPU-hours per month / H200 at from $2.60 / B200 at from $4.00)

• Burst only during the 8-day peak | GPU-hours per month: 6,144 | H200 at from $2.60: $15,974 | B200 at from $4.00: $24,576
• Always-on for the full month (730 h) | GPU-hours per month: 23,360 | H200 at from $2.60: $60,736 | B200 at from $4.00: $93,440

The burst plan's GPU cost is 26.3% of keeping the same 32 GPUs running all month, because it covers 192 hours per GPU instead of 730. Per-minute Pay as you go billing and the console's delete action are what make a crunch-week-only cluster practical.

The table assumes one cloud GPU-hour does the same work as one hour on your own cards, which is the conservative case when the cloud side is newer hardware.

Step 3: decide H200 or B200 with one ratio. B200 lists at 1.54 times the H200 price ($4.00 ÷ $2.60). B200 is the cheaper burst only if it finishes the same job in less than 65% of the H200 time; at exactly 65% the two cost the same.

B200 speed vs H200 on your job (B200 GPU-hours for the same 6,144 H200 GPU-hours of work / B200 burst cost / Cheaper choice)

• 1.0x | B200 GPU-hours for the same 6,144 H200 GPU-hours of work: 6,144 | B200 burst cost: $24,576 | Cheaper choice: H200 ($15,974)
• 1.54x | B200 GPU-hours for the same 6,144 H200 GPU-hours of work: 3,990 | B200 burst cost: $15,958 | Cheaper choice: About even
• 2.0x | B200 GPU-hours for the same 6,144 H200 GPU-hours of work: 3,072 | B200 burst cost: $12,288 | Cheaper choice: B200

The speed ratios above are illustrative inputs. A one-node step-time test on each GPU gives your real multiplier before you commit the whole burst.

If the same cloud nodes turn out to be needed on most days of the month, compare Prepaid against Pay as you go in the Summary panel's List Price, Discount, and Estimated Total lines, and ask GMI Cloud sales about committed pricing, which the pricing page describes as "Commitment-Based Savings."

Which jobs should burst to the cloud and which should stay on your own GPUs?

Burst the jobs that are self-contained and light on data movement. Keep the jobs that pull large, frequently changing datasets on the hardware next to that data. Apply these placement rules to each queue:

1. Run each job entirely on one side. A single distributed training job split across your data center and a cloud region puts cross-site latency inside every collective that spans both sites. Place whole jobs, and use GMI Cloud's "RDMA-ready networking" within the cloud cluster for multi-node runs that land there.
2. Burst when staging data takes under 10% of the job's runtime. This is a planning rule, and the arithmetic is simple: 20 TB over a 10 Gbps link takes at least 4.4 hours at line rate, before protocol overhead (20 _ 10¹² bytes _ 8 ÷ 10¹__ bits per second = 16,000 seconds), which fits a 48-hour fine-tune at 9.3%. The same 20 TB over 1 Gbps takes 44.4 hours, and that job stays home.
3. Move the queue's most portable work first. Fine-tuning runs, evaluation sweeps, and batch inference with fixed inputs are the usual first movers because their inputs are copied once and their outputs are small. Long pre-training runs tied to a live data pipeline stay on your own cluster.

When the answer is "the cloud cluster will run every day," the setup has become a second baseline cluster rather than a burst. That is still a Managed GPU Cluster, just on a committed plan.

Trend Micro shows where a growing cloud share can lead: it "uses GMI Cloud GPU clusters as a more cost-effective infrastructure foundation for AI-heavy workloads previously run on Oracle Cloud," with "H100 and H200 GPU capacity in use" (GPU page).

Trend Micro's case is a consolidation onto GMI Cloud from another cloud rather than a hybrid split.

How do other hybrid GPU options compare?

GMI Cloud's Managed GPU Cluster is the option that delivers the unified management plane and the cloud GPU capacity together, from a provider that provisions and operates the GPU nodes itself.

The alternatives buyers compare it with are control-plane software that runs over GPUs you source yourself, or a managed Kubernetes service whose cloud nodes come from one hyperscaler.

Option (What it unifies / Where the cloud GPUs come from)

• GMI Cloud Managed GPU Cluster | What it unifies: "Supports managed clusters across both GMI Cloud and BYOS environments," Kubernetes-based | Where the cloud GPUs come from: H200 or B200 nodes provisioned and operated by GMI, billed by the minute
• AWS EKS Hybrid Nodes | What it unifies: Your on-prem machines join an EKS cluster whose control plane AWS manages (AWS docs) | Where the cloud GPUs come from: AWS Regions, Local Zones, or Outposts in the same EKS cluster
• NVIDIA Run:ai | What it unifies: Orchestration software that "unifies resources from cloud, on-premises, and hybrid environments" (NVIDIA) | Where the cloud GPUs come from: Whatever clusters you deploy it on
• SkyPilot | What it unifies: Open-source system "to run, manage, and scale AI workloads on any AI infrastructure," across Kubernetes, Slurm, and 20+ clouds (SkyPilot docs) | Where the cloud GPUs come from: Your own accounts with each cloud

Two notes for readers comparing these.

AWS charges EKS Hybrid Nodes "per hour for the vCPU resources of your hybrid nodes when they are attached to your Amazon EKS clusters," and requires "a reliable connection between your on-premises environment and AWS." Run:ai and SkyPilot are scheduling layers, so the GPU contract, the capacity, and the support relationship for the cloud side still have to come from a separate provider.

For a team whose actual goal is "more GPUs, one place to run them," GMI Cloud collapses those two purchases into one: the cluster management and the H200 or B200 capacity arrive together, with GMI Cloud engineers operating the cloud nodes.

What should you prepare before contacting GMI Cloud?

Bring an inventory of your own cluster and a demand profile for the peak. That is enough for GMI Cloud to scope the BYOS side and for you to fill in the Request Cluster form in one pass.

• Own cluster inventory: GPU model and count per node, interconnect, Kubernetes version (or scheduler if it is not Kubernetes yet), OS image, and the site's location.
• Connectivity: link type and bandwidth between your site and the target GMI Cloud region (US, APAC, or EU), plus the largest dataset a burst job would need to stage.
• Demand profile: peak GPU-hours per day, number of peak days per month, and which queues are portable under the three rules above.
• Node choice: a one-node step-time test on H200 and B200 to apply the 65% rule.
• Billing: Pay as you go for bursts, or Prepaid and committed pricing if the cloud share is becoming a baseline.
• Access and isolation: who needs cluster access on each side, and the VPC layout you expect for the cloud cluster.

FAQ

What is BYOS on GMI Cloud?

On GMI Cloud, BYOS stands for "Bring Your Own Service," as written on the GPU page, and refers to environments a customer runs itself rather than clusters inside GMI-operated data centers.

GMI Cloud's Managed GPU Cluster "Supports managed clusters across both GMI Cloud and BYOS environments," which is how a team with existing GPUs gets one management experience across its own hardware and GMI Cloud capacity.

The onboarding method for a specific BYOS environment is scoped with GMI Cloud during early access.

How do I request the cloud part of a hybrid cluster, and how is it billed?

Open Request Cluster in the GMI Cloud console, choose the billing method, data center, Kubernetes version, node type, node quantity, and OS image, then submit and contact GMI Cloud support to activate it. Pay as you go is charged by the minute with no upfront cost; Prepaid is the other billing method.

The Summary panel shows the estimated monthly cost, including list price and discount, before you submit.

Which GPUs can the cloud side of a GMI Cloud managed cluster use?

GMI Cloud's GPU Compute documentation describes managed Kubernetes clusters "with H200 or B200 nodes, provisioned and operated by GMI." As of September 2026 the pricing page lists the H200 from $2.60 per GPU-hour and the B200 from $4.00 per GPU-hour, with B200 marked Limited Availability.

The console catalog card shows the live rate for each node SKU and region.

Can we add more cloud nodes later without building a new cluster?

Yes. GMI Cloud's Cluster Requests page includes a Node Requests tab for "requests for additional nodes against an existing cluster." That lets a team grow a running cloud cluster when a peak outgrows it, instead of standing up a second one.

Is Managed GPU Cluster generally available?

GMI Cloud lists Managed GPU Cluster as "Early access" on its GPU page, alongside Container Service and Bare Metal GPU. Teams with existing GPU clusters are one of its named target users, so contacting GMI Cloud sales is the way in.

Next step: size your peak and request the cloud side

Run the three-step capacity math on your own queue data, then contact GMI Cloud sales with the inventory checklist above so we can scope your BYOS environment and the cloud node plan together.

Current H200 and B200 list prices are on the GMI Cloud pricing page.

For background on hybrid strategy, see GMI Cloud's earlier guides on when to combine on-prem GPUs with cloud GPUs and scaling AI training with hybrid GPU clusters.

For large training programs, Reflection AI trains frontier open models on GMI Cloud's "U.S.-based high-performance GPU clusters and 24/7 operations" (Customers page; partnership announcement), and GMI Cloud was recognized as an NVIDIA Exemplar Cloud on GB300 NVL72 systems for training.

If your question is reserving Blackwell for inference rather than training burst, read how to reserve B200 or B300 GPUs and tune inference; if it is a serverless bill that has grown too large, see moving from serverless inference to dedicated GPUs.