How we read, compute and rank

Where the numbers come from

Prices are read on each provider's own pricing page or API, on a schedule. A reading keeps the page it came from, the time it was read and the configuration it describes: GPU, count, vCPU, RAM, disk, region, rental mode and availability when the page shows it. Readings relayed by third-party aggregators are kept for context and flagged as secondary; they never enter a ranking.

Prices come from our own collector: every night it reads the public pricing pages and APIs of 158 providers and keeps every raw response as a receipt (17,255 of the 25,014 readings on file). Providers it does not read yet keep the dated readings of the market study we completed in October 2026, with their date, until they leave the 45-day window. GPU specifications are the manufacturers' published figures; the price history before our own daily readings began (October 30, 2026) comes from a dated market snapshot.

True cost

The list price per GPU-hour is rarely the whole bill. True cost adds the mandatory add-ons a provider publishes for that configuration: storage billed while the instance is stopped, egress, a public IPv4 address, a minimum charge. When a provider does not publish an add-on, the receipt says “not published” rather than assuming zero. Rankings use true cost; tables show both.

Freshness

A reading is fresh for 24 hours and recent until 7 days. Only readings from the last 45 days can be ranked, and every row shows its read date: the collector reads the providers’ own pages and APIs once a day, and the providers it does not read yet keep the dated readings of our October study, so the window covers six weeks rather than a day. Older readings stay listed, in grey, with their date, and are never counted in a median. When a provider is read again for the same GPU and mode, the older reading is superseded and hidden from the main tables; a provider read by the collector loses every older reading from other sources.

What is never ranked

• Offers the provider marks unavailable.
• Readings older than 45 days, and readings superseded by a newer one for the same provider, GPU and mode.
• Prices outside 0.3× to 3× the median for that GPU and mode, suspended until a second reading confirms them.
• Resold capacity: when a provider resells another cloud's machines, the offer is attributed to the operator and marked resold. Current mappings: runcrate → sesterce, omega-gradient → sesterce, gpunet → other clouds (the upstream is named in each offer), lightning-ai → other clouds (the upstream is named in each offer).
• Aggregator readings (secondary).

On marketplaces (akash-network, clore-ai, cloudrift, hyperbolic, io-net, lium, omega-gradient, prime-intellect, salad, shadeform, spheron, tensordock, theta-edgecloud, vast-ai) many hosts sell the same GPU at different prices. Podiums count the floor, the cheapest eligible host at reading time, once. Medians count every provider once, at its cheapest eligible offer: a provider that lists the same GPU in eight configurations does not get eight votes. Tables still show every offer and every host.

The three podiums

Every GPU page and the home page answer three questions, with one provider per step. Cheapest is the lowest true cost among eligible offers. Best value is the highest Value Score among providers with a Trust Score of at least 60. Most trusted is the highest Trust Score among providers with a fresh, eligible offer. Medians are published only when at least 3 providers hold an eligible offer.

Value Score

Value is throughput per dollar. Until measured benchmarks cover every GPU, throughput is estimated from the specification that limits each workload: memory bandwidth for LLM inference, FP16 tensor throughput for training and for image and video, and the geometric mean of both for general use. The estimate is divided by true cost, then expressed as a percentile across all fresh, eligible offers, so 70 means better than 70% of today's offers for that workload. Marked “estimated” wherever it appears.

Trust Score v0.1

The Trust Score reads what a provider publishes about itself, in six dimensions. Each criterion earns points only when the evidence is on the provider's own pages; “not disclosed” earns zero. Dimensions not yet measured, such as aggregated customer signal, are excluded from the denominator rather than counted as zero. The score is provisional (v0.1), dated, and shown with every criterion and its source on each provider page.

Trust at least 70 is labelled “trusted” in filters. A Trust Score is not a review score: it measures transparency and published guarantees, not satisfaction.

Price index and movers

Three baskets, Datacenter, Workstation and Consumer, each index the median fresh on-demand price of their member GPUs, one floor per marketplace, rebased to 100 at the start of the window. A basket is published only when at least 4 providers have a fresh offer. Movers compare a GPU's median today with 30 and 90 days ago; a move is published only with n ≥ 4 providers, and its confidence follows n: high from 8, medium from 5, low at 4. Changes compare the median of the first and of the last seven days of the window, on one source only: the daily series comes from a dated snapshot until it ends, then from our own daily readings, and a change is never computed across that junction. Moves beyond ±50% are not published: on these samples they come from a change in the set of providers, not from a change of price.

Model sizing

Weights. For every model we read the published checkpoint on Hugging Face: the parameter count from the safetensors headers and the size of the weight files on disk, at the precision they are published in (BF16, FP8, MXFP4, INT4, or a mix). That size is the weight figure at the native precision; the other precisions are estimates at 1 byte per parameter (8-bit) and 0.6 bytes per parameter (4-bit, because embeddings, norms and scales stay wider), and are labelled as estimates. Models whose repository could not be reached keep the figures of the internal study and are labelled as not cross-checked.

Runtime headroom. Weights are multiplied by 1.2 for the CUDA context, activations and allocator fragmentation; serving stacks reserve memory the same way, so a fit above 90% of the GPUs' total memory is flagged tight.

KV cache. When config.json is readable (directly, or through a public mirror of a gated repository, which is then cited), the cache per token and per layer is 2 × KV heads × head dimension × 2 bytes (FP16 cache); multi-head latent attention stores (latent rank + rope dimension) × 2 bytes instead; sliding-window layers hold at most their window. The figure shown is for one sequence at the chosen context; serving N concurrent sequences multiplies it by N. Image, video, speech and embedding models have no token cache and are sized on weights plus headroom only.

Fit and price. The smallest configuration is the fewest GPUs of one type, among 1, 2, 4 and 8, whose total memory covers the need. The price is the cheapest eligible on-demand offer for exactly that GPU count across every provider on file, under the ranking rules (in stock or stock unknown, newest reading per provider, no aggregator or outlier rows), with the next providers shown as alternatives; monthly figures assume 730 hours. Throughput figures are the internal study's single-stream estimates, dated and marked as such.

Throughput estimates

cards, precision and speed estimated from memory bandwidth and model size (internal study); cost recomputed by the site from verified prices. The 412 rows on file date from 2026-10-04. These are single-stream estimates: real serving with batching lowers the cost per token substantially, and measured results will replace them as they are published.

Independence and corrections

No provider pays to be listed or ranked, and no row is sponsored. Some outbound links carry a commission; they are marked, and commissions never influence a ranking, a score or a sentence. Errors are corrected on the page, with a note, and logged on the corrections page. See also the editorial policy.