What CoreWeave currently offers

CoreWeave positions its cloud around accelerated computing rather than a broad catalogue of general-purpose cloud services. Its current pricing page lists NVIDIA GB300 NVL72, GB200 NVL72, HGX B300, HGX B200, GH200, HGX H100, HGX H200, L40, L40S and A100 configurations, alongside CPU, storage and networking products. That breadth matters because the provider decision is not simply whether CoreWeave has a GPU. It is whether the required accelerator, node topology, region and surrounding infrastructure match the workload.

For the GPU Cloud Decision Cluster, the most important current systems are HGX H100, H200 and B200 because they connect directly to AIDataCenterHQ's live H100, H200 and B200 sourcing guides. CoreWeave also exposes newer GB200 and GB300 systems, which shows why provider profiles require frequent review rather than a one-time static description.

Primary source: CoreWeave Cloud Pricing, checked 25 September 2026.

CoreWeave public GPU pricing snapshot

CoreWeave's published North America table currently shows the eight-GPU HGX H100 at $49.24 per hour on demand, HGX H200 at $50.44 per hour, and HGX B200 at $68.80 per hour. The same page also publishes spot rates for these systems. Europe currently carries the same on-demand figures for those three HGX systems, although spot prices differ slightly by region.

SystemGPU countVRAM per GPUNorth America on-demandInterpretation
HGX H100880 GB$49.24/hourSystem-level price, not a one-GPU listing.
HGX H2008141 GB$50.44/hourHigher-memory Hopper system with only a modest node-price premium in the current table.
HGX B2008180 GB$68.80/hourBlackwell system with a different memory and cost envelope.

Dividing these node rates by eight produces approximate derived figures of $6.16, $6.31 and $8.60 per GPU-hour respectively. Those calculations are useful for normalization, but they do not make the offers identical to single-GPU instances elsewhere. The CoreWeave node includes its own CPU, system RAM, local storage and infrastructure assumptions.

Source and pricing unit: CoreWeave pricing. Values are public list observations, not negotiated enterprise quotes or guaranteed real-time capacity.

How should CoreWeave pricing be normalized?

The first rule is to preserve the original billing object. CoreWeave's HGX H100, H200 and B200 rows are eight-GPU systems. A competing provider may advertise one GPU, a dedicated server, a serverless inference unit or a committed cluster. Comparing only the dollar number without retaining the billing unit creates a false comparison.

A useful normalized record should therefore include currency, region, GPU model, GPU count, VRAM, vCPU allocation, system RAM, local storage, on-demand or spot status, source timestamp and commitment assumption. Derived per-GPU-hour cost can then be calculated as a secondary metric. For sustained training, the more important metric may be cost per completed training run, cost per token, or cost per useful GPU-hour after utilization losses.

Spot pricing adds another decision layer. CoreWeave currently publishes materially lower spot prices for several GPU systems, but interruptible capacity is not equivalent to on-demand capacity. Fault-tolerant batch workloads may benefit, while tightly scheduled training or latency-sensitive production inference may require a different availability model. Use the GPU Cloud Pricing Comparator for changing observations and the ROI Calculator for workload-level economics.

Where CoreWeave can fit different AI workloads

H100 remains relevant for teams with established Hopper software stacks and workloads that do not require the additional memory of H200. H200 is particularly relevant where model weights, KV cache or scientific workloads benefit from 141 GB HBM3e per GPU. B200 changes the envelope again with 180 GB per GPU and Blackwell architecture, but the higher published node price means teams should quantify whether the memory and throughput advantages translate into lower total workload cost.

CoreWeave's product page describes H100 and H200 at supercomputer scale and emphasizes generative-AI training, fine-tuning and inference. That positioning is consistent with a provider designed for large accelerated workloads, but a buyer still needs to confirm actual capacity, region, networking and scheduling for the intended deployment. Marketing claims about performance should not substitute for workload benchmarking.

Provider product context: CoreWeave NVIDIA HGX H100/H200.

CoreWeave compared with the broader GPU-cloud market

CoreWeave should be compared against providers that solve the same operational problem, not against every company that sells access to a GPU. Lambda can be relevant where teams want self-service instances plus larger committed clusters. RunPod can be relevant where granular GPU rental and multiple deployment models matter. Crusoe can be relevant where teams are assessing AI-focused cloud infrastructure with its own accelerator portfolio and commercial model.

The forthcoming direct comparison pages will normalize those differences rather than declare a universal winner. Until then, the GPU Cloud Providers hub remains the parent directory and decision framework. The correct shortlist depends on accelerator, scale, region, network, storage, support, commitment and workload economics.

Constraints and questions to resolve before choosing CoreWeave

Public pricing is not the same as guaranteed capacity. A listed system may be unavailable in the required region or at the required scale when the workload must start. Buyers should confirm capacity, reservation terms, support levels, data-transfer costs, storage economics, orchestration requirements and the practical path for moving workloads if assumptions change.

Spot capacity deserves special treatment because lower prices come with interruption risk. In addition, newer accelerators can create software, scheduling or utilization constraints that reduce the value of a theoretically faster GPU. A procurement model should therefore test best-case and conservative utilization scenarios rather than assume published peak performance translates directly into business output.

Finally, compare CoreWeave with owned or colocated infrastructure when utilization is sustained. The answer can change with GPU utilization, financing, power, cooling, staffing and refresh cycles. AIDataCenterHQ's Data Centers, Power and Cooling sections provide the infrastructure context for that broader decision.

Methodology, freshness and limitations

This page uses public CoreWeave pricing and product pages as the primary evidence for current configurations and list prices. Values were checked on 25 September 2026 and should be treated as fast-changing F2 data. AIDataCenterHQ does not infer private discounts, negotiated contracts, future availability or unlisted regional capacity.

Every consequential price observation should retain the original source, billing unit, region, configuration and timestamp. Derived per-GPU figures are calculations for comparison convenience and do not change the underlying commercial unit. Before procurement, recheck the provider's current page and confirm capacity directly.

Related GPU cloud pages

Adjacent technology, IP and commercialization resources

CoreWeave procurement can intersect with AI infrastructure contracting, technology commercialization, patent strategy and cross-border deployment issues. 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.

Frequently asked questions

Does CoreWeave publish H100, H200 and B200 pricing?

Yes. Its current public pricing page lists eight-GPU HGX H100, H200 and B200 systems with on-demand prices and spot prices for supported regions.

Is CoreWeave's published HGX price per GPU?

No. The H100, H200 and B200 rows discussed here are eight-GPU systems. A per-GPU-hour figure must be explicitly derived and should retain the node context.

Is H200 automatically better value than H100 on CoreWeave?

Not automatically. The current list-price gap is small at the node level, but value depends on whether the workload benefits from H200's larger memory and bandwidth.

Should CoreWeave spot pricing be compared directly with on-demand alternatives?

Only after accounting for interruption risk and workload tolerance. Spot and on-demand capacity solve different availability requirements.