CoreWeave Competitors: How to Compare GPU Clouds Without a Price Table

Every article comparing GPU clouds is a table of dollars-per-hour, and every one of those tables is out of date within a month — because GPU pricing moves with supply, and supply in this market moves faster than anyone’s publishing schedule.

Worse, the hourly rate is not the number that decides your bill. Utilisation, data movement, storage, provisioning latency and minimum commitments routinely matter more, and none of them appear in the comparison tables. This post deliberately quotes no prices. It covers the criteria that survive a price change, which is the only kind of comparison worth writing down.

The landscape, by shape rather than by name
What decides your bill, in order
The technical questions the tables leave out
Deciding without a spreadsheet of stale prices
How this fits the rest of the stack
FAQ

The landscape, by shape rather than by name

The providers in this space are not variations on one product. They fall into distinct categories with genuinely different trade-offs, and knowing which category you need eliminates most of the list immediately.

Hyperscalers. The large general-purpose clouds. Most expensive per GPU-hour, and the only option if your workload is entangled with the rest of their ecosystem — managed identity, existing data, compliance posture already established.
Specialist GPU clouds. Built specifically for accelerated compute, with high-bandwidth interconnect and clusters designed for training. Better price per unit of work than hyperscalers, and they expect you to bring your own operational maturity.
Marketplaces and aggregated capacity. They broker capacity from many sources, including individual operators. Cheapest headline rates, most variable reliability, and the right answer for interruptible work.
Serverless inference. You send requests, they run a model, you pay per token or per second. No instance to manage at all, and no control over what is underneath.

Training a large model from scratch and serving inference to an application are different problems, and a provider excellent at one can be a poor fit for the other. The first filter is which of those you are doing.

For most teams building a product rather than a foundation model, the honest answer is that they need inference, and inference has a much wider and cheaper set of options than the training-focused comparisons suggest.

What decides your bill, in order

Hourly rate is on this list. It is not at the top.

Utilisation. A cheap GPU idle half the time costs more per unit of work than an expensive one running continuously. If your workload is bursty and you are renting by the hour on a reserved instance, utilisation dominates every other factor by a wide margin.
Egress. Moving data out is a real and frequently underestimated line. Training on data stored in one provider and computing in another means paying transfer on every epoch. Check egress pricing specifically — it is where the surprise usually lives.
Storage. Datasets and checkpoints are large and persist between runs. Storage priced separately from compute is normal; storage you forgot you were paying for between projects is also normal.
Minimum commitment. Some capacity is only available on multi-month or multi-year terms. That can be a large discount or an expensive mistake, depending on how confident you are about a workload that did not exist last quarter.
Provisioning latency. How long from requesting capacity to running on it. Minutes and weeks are both real answers in this market, and if it is weeks, that changes how you plan entirely.
The hourly rate. Which matters, once the above are settled.

A team that fixes its utilisation problem typically saves more than a team that switches providers for a better hourly rate — and the utilisation fix does not require a migration.

The technical questions the tables leave out

For anything beyond a single GPU, these determine whether the capacity is usable for your workload at all.

Interconnect between GPUs in a node, and between nodes. Multi-GPU training is bounded by how fast gradients synchronise. High-bandwidth intra-node links and a fast fabric between nodes are the difference between near-linear scaling and paying for eight GPUs to get the throughput of three.
VRAM per GPU. This is a hard constraint, not a performance dial. A model that does not fit does not run, and quantisation is a quality trade rather than a free workaround. Size this first.
Storage throughput. A fast GPU starved by a slow data pipeline is an expensive idle GPU. Check the read bandwidth available to a training node, not just the capacity.
Preemption policy. Spot and interruptible capacity is much cheaper and can vanish with little notice. Fine for checkpointed training, unacceptable for serving user requests.
Region and residency. Where the hardware physically is, for latency and for any regulatory requirement about where data may be processed.

Interconnect is the one that most often invalidates a price comparison. Two providers quoting the same GPU at the same rate can differ by a factor of two or three in actual training throughput because of what connects those GPUs, and that difference never appears in a dollars-per-hour column.

Deciding without a spreadsheet of stale prices

A sequence that produces a defensible answer and does not depend on any number being current.

Size the workload. Model size, VRAM required, single-GPU or multi-node, training or inference, continuous or bursty. Most of the market disqualifies itself at this step.
Decide the interruption tolerance. Checkpointed training tolerates preemption and unlocks the cheapest capacity. User-facing inference does not.
Locate the data. Compute close to it, or budget the egress honestly. This constraint frequently decides the provider on its own.
Benchmark two candidates on your actual workload. Not on a synthetic benchmark, and not for an hour. Run something real for a day and measure throughput per dollar. This is the only number that means anything.
Then compare prices, using the throughput figure you measured rather than the rate card.

Step four is the one teams skip and the one that pays for itself immediately. The variance between providers on real workloads is much larger than the variance in their advertised rates, and it goes in both directions.

One more thing worth saying plainly: most applications that use AI do not need GPU hosting at all. If you are calling a model API and building a product around it, your infrastructure problem is an ordinary web application problem — a service, a database, a queue, some storage. The GPU question only arrives if you are running the model yourself, and running the model yourself is a decision, not a default.

How this fits the rest of the stack

If your application calls a model API rather than hosting one, the recurring cost is the ordinary stack around it — the service handling requests, the database holding results, the storage, and the bandwidth. That is the part worth modelling before you build, and the RunxBuild hosting calculator puts those lines together. RunxBuild hosts the application layer: Python, Node, Go and Docker services deployed from a repository, managed Postgres or MySQL alongside, with autoscaling between a floor and a ceiling plan for workloads whose traffic is uneven.

Useful related references:

FAQ

What should I compare GPU cloud providers on?

Utilisation, egress pricing, storage, minimum commitment, provisioning latency and interconnect — roughly in that order — before hourly rate. A cheap GPU that sits idle or that is starved by a slow data pipeline costs more per unit of work than an expensive one running continuously.

Why do GPU cloud price comparisons go out of date so fast?

GPU pricing tracks supply, and supply in this market changes faster than articles get updated. Any published table is a snapshot. Criteria that do not move — interconnect, VRAM, egress structure, preemption policy — are more durable than the numbers.

Do I need a GPU cloud to build an AI product?

Usually not. If you call a model API, your infrastructure need is an ordinary web application: a service, a database, storage and bandwidth. GPU hosting only becomes relevant if you run the model yourself, which is a deliberate choice rather than a requirement.

What is the difference between training and inference hosting?

Training wants many GPUs with fast interconnect, high storage throughput, and tolerates interruption if checkpointed — which unlocks much cheaper capacity. Inference wants low latency, predictable availability and elastic scaling, and cannot generally use preemptible capacity. A provider strong at one may be weak at the other.

Is spot or preemptible GPU capacity worth using?

For checkpointed training, yes — it is substantially cheaper and an interruption costs you the time since the last checkpoint. For anything serving user requests, no. The saving is not worth requests failing when capacity is reclaimed.