GPU cloud providers differ by operating model
The phrase GPU cloud provider covers several business models. AI-focused neoclouds concentrate on accelerated compute and large clusters. Hyperscalers integrate GPUs with broad cloud portfolios. Flexible GPU-rental platforms emphasize rapid deployment, many accelerator choices and granular billing. Dedicated infrastructure providers may focus on reserved clusters or bare-metal delivery. These categories overlap, so the useful question is not which label applies perfectly, but which operating characteristics matter for the workload.
Provider type affects procurement as much as technology. A research team running intermittent experiments may value rapid on-demand access and small minimum commitments. A company training a frontier-scale model may care more about multi-node topology, capacity reservation, support and contractual certainty. An inference platform may prioritize predictable latency, geographic distribution and operational tooling. The same provider can therefore be attractive for one workload and unsuitable for another.
Current provider examples show why normalized comparison matters
AIDataCenterHQ is starting this directory with four specialist providers that expose materially different commercial structures. These are examples for structured comparison, not an overall ranking.
| Provider | Current public signals | Decision implication |
|---|---|---|
| CoreWeave | Its current pricing page lists HGX H100, H200 and B200 systems and distinguishes on-demand, spot and inference pricing for some configurations. | Compare the full multi-GPU system and price basis rather than treating the displayed node rate as a universal per-GPU market price. |
| Lambda | Lambda currently publishes instance and cluster pricing, including H100 and B200 cluster structures with GPU-count and duration conditions. | Commitment length and cluster size can materially alter the effective rate and procurement path. |
| AWS | P5 H100, P5e/P5en H200 and P6-B200 families combine multiple accelerator generations with region-specific availability and several purchasing models. | Preserve the EC2 instance, region and purchase model before comparing effective accelerator cost. |
| RunPod | RunPod lists many GPU models across 30+ regions and separates Pods, Serverless and cluster-oriented delivery. | A single provider can serve very different usage patterns, so product type must be part of the comparison record. |
| Crusoe | Crusoe publishes on-demand GPU-instance prices for selected accelerators and uses sales-led pricing for other newer configurations. | Public list price and negotiated reserved capacity should be treated as different commercial states. |
Primary-source anchors checked 24 September 2026: CoreWeave pricing, Lambda pricing, RunPod pricing, and Crusoe pricing., AWS EC2 accelerated instance specifications
A provider record should separate capability from commercial state
A reliable directory needs stable fields and fast-changing fields. Stable fields include provider type, supported deployment models and broad product architecture. Faster-changing fields include accelerator availability, regions, list prices, spot prices, reservation terms and capacity status. Mixing the two produces stale pages that look precise but are no longer decision-useful.
| Field | What to capture | Why it matters |
|---|---|---|
| Accelerator | Exact GPU model, memory and system form | H100 PCIe, H100 SXM, H200 and B200 are not interchangeable offers. |
| Node | GPU count, CPU, system RAM, local storage | Two prices for the same GPU name may represent very different nodes. |
| Network | Interconnect and multi-node fabric | Distributed training performance depends on communication as well as GPU throughput. |
| Geography | Region and data-location constraints | Latency, residency and actual capacity can determine whether a provider is usable. |
| Commercial state | On-demand, spot, reservation, cluster contract, sales quote | Commitment and interruption risk change effective economics. |
| Freshness | Source, extraction date, last verified | Prices and availability can move quickly. |
Normalize pricing before comparing providers
Provider pricing pages use different units. CoreWeave commonly presents multi-GPU system rates for HGX configurations. Lambda publishes both instance and cluster structures. RunPod exposes per-GPU-style hourly rates across several products, while Crusoe publishes per-GPU-hour rates for selected instances. Converting these numbers into a single table without preserving the original billing unit would create false precision.
A useful normalized record therefore stores the original unit first, then derives comparison metrics. At minimum, record currency, billing unit, GPU count, region, commitment assumption, tax treatment when stated, source timestamp and whether capacity is on-demand, interruptible or reserved. Only after that should the site calculate comparable per-GPU-hour or workload-level scenarios.
This is also why the existing GPU Cloud Pricing Comparator should remain the canonical pricing utility. The provider directory describes who offers what and under which conditions. The tool can then normalize observations without forcing the provider page itself to become a continuously changing price table.
Current pricing illustrates the danger of comparing unlike units
As of the verification date, CoreWeave's public page lists an eight-GPU HGX H100 on-demand configuration at a node-level hourly price, while RunPod publishes H100 options as individual GPU-oriented hourly rates. Lambda's cluster offers introduce GPU-count and contract-duration conditions. Crusoe publishes per-GPU-hour rates for selected H100 and H200 instances. Those observations are useful, but only after their units and commercial conditions are retained.
A separate market signal reinforces the freshness requirement: Reuters reported on 17 September 2026 that Nebius announced another increase in pay-as-you-go pricing for certain NVIDIA GPUs, effective 1 October. This is not evidence that every provider will raise prices, but it demonstrates that accelerator rental economics can change over weeks rather than years.
Market context: Reuters, 17 September 2026. Provider-specific numbers should always be rechecked against the provider's own current page before a procurement decision.
Build the shortlist from workload constraints outward
The first filter should be technical feasibility. Identify required accelerator family, VRAM, expected GPU count, inter-node communication, storage throughput and software environment. Remove offers that cannot satisfy those requirements. Next apply geography, security, data-location and availability constraints. Only then compare prices among genuinely substitutable offers.
The second filter is operating model. Short experiments and bursty inference may favor flexible access. Large training runs may justify reserved clusters and direct sales engagement. Sustained utilization may require a separate ROI analysis comparing cloud with owned or colocated infrastructure. Provider selection should therefore connect to AI-infrastructure business models, technology architecture, power constraints and data-center infrastructure rather than remain an isolated procurement exercise.
The third filter is commercial resilience. Record what happens when demand scales, when spot capacity disappears, when a region is unavailable, or when a workload must move. Portability, contract length, support and the cost of data movement can matter as much as the opening GPU rate. The aim is not to produce a universal winner. It is to identify which provider configuration best fits a defined scenario.
Limitations, methodology and freshness
This directory page does not claim to enumerate every GPU cloud provider, every region or every negotiated price. Public provider pages may omit enterprise discounts, reserved-capacity terms or real-time inventory. Availability can change without a pricing-page change. A published SKU should therefore not be interpreted as guaranteed immediate capacity.
AIDataCenterHQ treats provider price and availability data as fast-changing. Consequential provider records should retain source identity, source date or extraction date, last-verified date, billing unit, region, configuration and commitment assumptions. Where evidence is missing, the page should say so rather than infer an unavailable fact.
Provider and accelerator pages connected to this directory
The structured provider profiles now cover AWS, Google Cloud, Microsoft Azure, Nebius, CoreWeave, Lambda, RunPod, Crusoe and Vast.ai. The NVIDIA H100, H200 and B200 sourcing guides and direct provider comparisons are also live. Each child links back to this directory and the parent GPU Cloud hub.
Adjacent technology, IP and commercialization resources
For organizations evaluating AI compute suppliers, adjacent questions often include technology commercialization, cross-border IP protection, and corporate structuring. Relevant specialist resources include Patent Business Lawyer, GIP Research, GIPResearch.org, Tech Law Attorney, US Tech Law Attorney, Patent Business Attorney, International Patents, TechCorpLegal and Advocate Rahul Dev. These contextual links do not imply endorsement or provider relationships.
Frequently asked questions
What is a GPU cloud provider?
A GPU cloud provider supplies remote access to accelerator-based compute through instances, dedicated servers, clusters, serverless services or related managed infrastructure.
How should GPU cloud providers be compared?
Compare exact accelerator configuration, node resources, network, storage, region, availability, billing unit, commitment terms and workload-level cost.
Why can two H100 offers have very different prices?
The offers may use different H100 variants, node sizes, networking, regions, product types, commitments or interruption terms. The headline GPU name is therefore insufficient.
Should provider rankings be trusted?
A ranking is only meaningful if its criteria, weights, data freshness, missing-data treatment and commercial conflicts are disclosed. This page deliberately uses a comparison framework rather than an unsupported overall ranking.