Where to Find GPU Capacity in 2026: Hyperscalers, Neoclouds and Regional Clouds

Key Points:

• The largest providers say they are short. Google said in April 2026 that it is "compute constrained in the near-term". CoreWeave's CFO said the company is largely sold out of 2026 capacity, and Nebius reported selling out three quarters in a row.
• GPU supply sits in four tiers. Hyperscalers, GPU-first neoclouds, regional clouds and marketplaces each sell GPUs on different terms. Most teams only ever check the first tier.
• Managed Kubernetes is the common layer. Most serious GPU providers now offer it, so the same container and the same deployment can run on any of them.
• Off-the-shelf services connect the clouds. AWS Interconnect multicloud, Megaport, Equinix Fabric, VPNs, Tailscale and Cilium Cluster Mesh cover everything from a quick test to a production data path.
• A second cloud mostly costs operations time. Each provider brings a new cluster setup, new IAM, a new pipeline and a new on-call surface. Running every cluster from one platform turns adding capacity into a deploy.

A team that runs inference on one cloud usually discovers the GPU shortage the same way. A deploy needs one more node, the node never comes up, and the support ticket comes back with "try another region". The other region is out too.

Our GCP capacity article covered what the hyperscalers say about it. This one picks up the next question: if your cloud has no GPUs for you this week, who does, and what does it take to use them?

Is there a GPU shortage in 2026?

Yes, for data center GPUs, and the providers say so on their earnings calls.

• Google Cloud. "We are compute constrained in the near-term", and cloud revenue "would have been higher if we were able to meet that demand" (Sundar Pichai, Q1 2026 earnings, TechCrunch).
• CoreWeave. Largely sold out of 2026 capacity and already allocating 2027 (Technologymatch).
• Nebius. Sold out of available capacity in Q3 2025 and in each of the next two quarters, with four or more customers competing for each GPU it brings online (same source).

"Sold out" has a specific meaning here. Large providers sell most new capacity through multi-year contracts before the data center is even built. On-demand and short reservations get whatever is left once those contracts are served. Smaller providers have fewer GPUs in total, but they often keep more of them for on-demand rental, so the GPUs you need this week may well sit at a provider you don't use yet.

If you landed here because a gaming card is out of stock, this post won't help. Everything below is about renting data center GPUs.

Where is GPU capacity available in 2026?

GPU supply sits in four tiers. Price, contract terms and the amount of platform around the GPU change a lot from one tier to the next.

Tier 1: hyperscalers

AWS, Google Cloud, Microsoft Azure and Oracle Cloud Infrastructure have the widest service catalogs, your existing enterprise agreements and the broadest compliance coverage. They also have the tightest on-demand capacity for recent GPUs. Each sells a reservation product that trades flexibility for a guarantee: EC2 Capacity Blocks for ML, GCP reservations and Dynamic Workload Scheduler, and Azure capacity reservations.

Use them when the GPU workload has to sit next to data and services you already run there.

Tier 2: neoclouds

A neocloud is a cloud provider built around GPUs, with a much narrower catalog than a hyperscaler. The main names are CoreWeave, Nebius, Lambda, Crusoe, Together AI, Voltage Park, Nscale and Fluidstack.

They often get new NVIDIA generations before or alongside the hyperscalers, publish simpler GPU pricing, and run InfiniBand networking for multi-node training. CoreWeave and Nebius are public companies. In October 2026, Gartner predicted that "cost pressure and a lack of a differentiating business model will force over 80% of neocloud providers to cease independent operations" by 2030. If you rent from a neocloud, run on standard Kubernetes and containers so that leaving stays cheap if your provider is bought or shuts down.

Tier 3: regional and developer clouds

OVHcloud, Scaleway, DigitalOcean, Vultr, Akamai and Hetzner run smaller GPU fleets with shorter queues. They are often the fastest way to get a handful of GPUs for inference, and the European ones matter if you need EU data residency. Our European GPU cloud comparison goes through them one by one.

Tier 4: marketplaces and brokers

RunPod, Vast.ai and NVIDIA DGX Cloud Lepton aggregate capacity from many suppliers. DGX Cloud Lepton is NVIDIA's own marketplace, with CoreWeave, Crusoe, Lambda, Nebius, Nscale and others behind it. Marketplaces work well for experiments, batch jobs and burst inference. They are harder to fit into a production setup that needs private networking, audit logs and compliance controls.

Which GPU clouds offer managed Kubernetes?

If a provider gives you a conformant Kubernetes cluster with GPU nodes, your containers, Helm charts and deployment tooling carry over unchanged. If it only rents raw machines, you are building and running the cluster yourself.

These offers change quickly. Check the current GPU types and regions with each provider before you commit.

How do you connect GPU capacity in another cloud to your existing stack?

List what has to cross the boundary between the two clouds. For most inference workloads, that comes down to three things:

• Requests and responses. The model server can sit behind an HTTPS endpoint with authentication, and your application calls it like any other API.
• Model weights. They load at startup and on every scale-up. This is usually the largest transfer, and it is the one that drives egress cost.
• Private data. If prompts or features come from a database in your main cloud, that path needs a private network.

Pick the connection from that list.

Private links between clouds

• AWS Interconnect multicloud became generally available in April 2026 as a private link between AWS and Google Cloud, with five region pairs in the US and Europe and 1 to 100 Gbps of bandwidth. AWS said Azure support would follow in the second half of 2026.
• Megaport and Equinix Fabric sell virtual cross-connects, and they are the usual way to reach a neocloud privately. CoreWeave's Direct Connect accepts existing Equinix or Megaport connections.
• Provider interconnects such as Nebius Cloud Interconnect give you a dedicated port that you can land in a colocation facility, an on-premises network or another cloud.

Use these when sensitive data flows between clouds all the time, or when you need predictable bandwidth and latency.

Site-to-site VPN

Every hyperscaler and most regional clouds support IPsec VPN gateways. A VPN takes about an hour to set up and costs little, which makes it enough for control traffic and moderate data volumes. Throughput per tunnel is limited, so don't stream large datasets through one.

Overlay networks

Tailscale's Kubernetes operator exposes services across clusters over WireGuard, with access rules managed in one place. NetBird has a similar Kubernetes operator and can be self-hosted. An overlay is the quickest way to connect a tier 3 or tier 4 provider that has no private interconnect product.

Kubernetes cluster mesh

• Cilium Cluster Mesh joins clusters running Cilium into one network, with shared service discovery and network policies.
• Submariner builds encrypted layer 3 tunnels between clusters.
• Skupper connects services at the application layer and works across NAT and firewalls without network changes.
• Istio multi-cluster extends a service mesh across clusters if you already run Istio.

A Red Hat Research comparison found Submariner strongest on latency, Istio on throughput, and Skupper easiest to configure.

Model weights and egress

Hyperscaler egress fees apply every time a GPU node in another cloud pulls weights from S3 or Google Cloud Storage. There are two common fixes. You can store weights in a zero-egress object store that every cloud can reach, such as Tigris or Cloudflare R2. Or you can mirror weights into object storage inside the GPU provider and refresh the copy when a new model version ships.

What does it take to run GPU workloads on a second provider?

GPUs and a network link are the easy part. Each new provider also brings:

1. A cluster to create, upgrade and secure.
2. GPU drivers, the NVIDIA device plugin and node autoscaling to configure.
3. Another identity and access model.
4. Another deployment pipeline, or a fork of the existing one.
5. Separate logs, metrics and cost reports.
6. One more system for whoever is on call to learn.

A team with a platform group can absorb that in a few weeks per provider. A team without one usually never gets the second cloud running, even when the capacity is there.

How does Qovery help you add GPU capacity from another cloud?

Qovery is an Agentic DevOps platform. It runs Kubernetes clusters in your own cloud accounts and deploys your applications to them from one place.

• One control plane for every cluster. Qovery creates and manages clusters on AWS, Google Cloud, Azure and Scaleway, and can attach Kubernetes clusters you already run elsewhere.
• GPUs per service. You set the GPU count on the service that needs it, and Qovery provisions GPU nodes for it on whichever cluster the service runs.
• Clone to where the capacity is. Clone an environment to a cluster on another cloud and deploy it with the same pipeline, variables and settings.
• Bring your own network. Qovery has no built-in cross-cloud networking. You connect the clusters with the services listed above, and Qovery deploys on top.
• Your accounts, your contracts. Clusters run in your own cloud accounts, so the reservations, credits and committed spend you negotiate with each provider still apply.

For the tools that schedule GPU jobs across clouds (SkyPilot, Ray, Kueue and others), see our multi-cloud GPU orchestration comparison.

Checklist before you add a GPU provider

• Which GPU type do you need, how many, and for how long? On-demand, reserved or spot?
• Does the provider offer managed Kubernetes with that GPU type in the region you need?
• What crosses the boundary: requests only, model weights, or private data?
• Which connection fits that traffic: public HTTPS, VPN, overlay or private interconnect?
• Where will the model weights live, and what does each pull cost in egress?
• Does the provider meet your data residency and compliance requirements?
• What happens to the workload if the provider is acquired or shuts down?
• Who deploys, monitors and is on call for the new cluster?