# The neocloud index

> How the neocloud index is calculated from the published H100 and B200 rates of the specialist GPU clouds: which rate counts as a quote, how each is normalized, and why it is never averaged with the hyperscaler figure.

Updated 2026-09-06. Canonical: https://gpuquant.com/docs/neocloud-index

The neocloud index is the list price of one GPU-hour on the specialist GPU clouds: 16 providers, H100 and B200 only, each read from its own published price list. It is the second tier beside the [reference price](https://gpuquant.com/docs/reference-price), built by the same rules, and the same GPU-hour sells for roughly a third of the hyperscaler list price on it.

## What counts as a quote

1.  Only an on-demand rate against a stated configuration counts. A published “from” floor, a committed or reserved rate, a spot or preemptible rate and a rate in a currency other than USD are stored and labelled and never enter the index.
2.  Every quote is normalized to USD per individual GPU-hour on the 8-GPU node the reference price also holds constant. A provider that publishes a node rate is divided by the node's GPU count; one that publishes a per-GPU rate is used as published.
3.  A provider whose published figure cannot be read as either is kept out, with the reason stated on its row below and on the market-data page.

## How the index is computed

1.  The index is the **average** of the eligible providers' figures, the same estimator as the reference price, so the two are the same kind of number and can sit beside each other. The median is computed and stored beside it.
2.  A provider that has not republished holds its last reading forward, before the average, and every index row records how many providers were observed that month and how many were held.
3.  The calculation version is **v2**. Version 1 published a median; version 2 publishes the mean, for the reason above.

The panel is wide, so the providers at the edges pull the average more than they would a median. That is the cost of one estimator across the product, and it is why the median is stored on every row.

## Why the tiers stay apart

A single blended figure would hide the three-fold gap between what the same GPU costs on a hyperscaler and on a specialist cloud, which is the most useful fact the two numbers carry. The two tiers are stored under separate keys, every read of the shared tables says which tier it wants, and nothing on the site averages across them.

## History

No neocloud publishes a price archive. Every point is a reading GPUQuant took of the live page or feed, or of a dated Internet Archive capture of the same page parsed by the same code. A month not captured cannot be recovered, and a provider's series begins where its first readable capture does. Some providers also publish spot, preemptible, reserved and commitment rates beside the on-demand one; those are stored and listed under the provider on the market-data page and never averaged.

## The providers

Each provider's published figure, how it is normalized, and anything a reader needs to judge the number.

**CoreWeave** (CoreWeave instance pricing table)

CoreWeave publishes a whole-node hourly rate beside the node GPU count. The rate is divided by that count.

[Published prices](https://www.coreweave.com/pricing)

**Nebius** (Nebius AI Cloud pricing table)

Nebius publishes a per-GPU-hour rate directly, in two columns: preemptible and on-demand. The on-demand column is the list price. The vCPU and RAM figures beside it are per GPU, not per node.

[Published prices](https://nebius.com/prices)

**Verda** (Verda instance-types API)

The API publishes a whole-instance \`price\_per\_hour\` beside \`gpu.number\_of\_gpus\`. The rate is divided by that count. The eight-GPU instance is the one the index reads.

Verda and DataCrunch are the same company. The API host is the pre-rename domain, which is expected and not a redirect to a third party.

[Published prices](https://api.datacrunch.io/v1/instance-types)

**Hyperstack** (Hyperstack GPU pricing table)

Hyperstack publishes a per-GPU-hour rate directly, in two tables: on-demand and a reserved "starting from" rate.

Hyperstack orders its on-demand table by price, so the B200 row sits at the foot of it below the older cards rather than at the top. Reading the first few rows would miss it entirely.

[Published prices](https://www.hyperstack.cloud/gpu-pricing)

**GMI Cloud** (GMI Cloud pricing page)

GMI publishes a per-GPU-hour figure prefixed "from". It is stored as a floor and does not enter the index.

Every GMI figure is a "from" price against no stated configuration. Stored and labelled, excluded from the index.

[Published prices](https://www.gmicloud.ai/pricing)

**Civo** (Civo GPU pricing table)

Civo publishes a whole-instance hourly rate against a named size whose label states the GPU count, for instance "8 x NVIDIA H100 - 80GB". The rate is divided by that count.

Civo publishes commitment rates for B200 but shows N/A in the on-demand column, so Civo contributes an H100 quote and no B200 quote.

[Published prices](https://www.civo.com/pricing)

**Sesterce** (Sesterce Cloud compute catalog)

Not applicable until a readable source exists.

Tracked but not ingested. Reaching Sesterce needs an account on cloud.sesterce.com so the catalog request can be identified and read.

[Published prices](https://cloud.sesterce.com/compute)

**E2E Networks** (E2E Networks GPU pricing table)

E2E publishes a per-GPU-hour rate under 1x, 2x, 4x and 8x tabs, but only the 1x table is in the served HTML. The single-GPU rate is what GPUQuant can read.

E2E fills its 2x, 4x and 8x tabs client-side, so the only readable rate is the single-GPU one. It is stored and excluded from the index, which holds the node size constant at eight. E2E also quotes USD on the page while billing Indian customers in INR; the published USD figure is what GPUQuant stores.

[Published prices](https://www.e2enetworks.com/pricing)

**RunPod** (RunPod public GraphQL catalog)

RunPod publishes a per-GPU-hour rate directly: \`uninterruptablePrice\` is the on-demand rate and \`minimumBidPrice\` is the spot floor.

GPUQuant reads Secure Cloud only. Community Cloud is capacity rented out by third parties and is materially cheaper, so including it would put someone else's hardware in RunPod's series. RunPod also answers with a rate only where an eight-GPU pod is currently available, so a missing month is a coverage gap rather than a price move and is recorded as such.

[Published prices](https://api.runpod.io/graphql)

**Crusoe** (Crusoe Cloud pricing table)

Crusoe publishes a per-GPU-hour rate directly.

Crusoe shows "Contact sales" in both the on-demand and spot columns for B200, so Crusoe contributes an H100 quote and no B200 quote.

[Published prices](https://crusoe.ai/cloud/pricing/)

**Lambda** (Lambda GPU cloud pricing table)

Lambda publishes a per-GPU-hour rate under 8x, 4x, 2x and 1x tabs, and the rate falls as the node grows. The 8x tab is the one the index reads.

[Published prices](https://lambda.ai/service/gpu-cloud)

**Voltage Park** (Voltage Park pricing page)

Only the headline "starting at" per-GPU-hour figure is in the server-rendered HTML. It is stored as a floor and does not enter the index.

Voltage Park renders its rate table client-side, so the only readable figure is the "starting at" headline. Reading the table itself needs a browser step this pipeline deliberately does not have. B200 is not named on the page at all.

[Published prices](https://www.voltagepark.com/pricing)

**Yotta Shakti Cloud** (Shakti Cloud pricing page)

Yotta publishes an INR per-month rate against a named size stating the GPU count. GPUQuant records the published rupee figure and does not convert it.

Published in INR per month. GPUQuant applies no exchange rate to a published list price, because the result would move on days Yotta did not change its price. Stored, labelled, excluded from the index. Yotta names no B200 rate on the page.

[Published prices](https://shakticloud.ai/pricing)

**Vultr** (Vultr bare metal plans API)

The API publishes a whole-machine \`hourly\_cost\` beside \`gpu\_count\`. The rate is divided by that count. \`hourly\_cost\_preemptible\` is the same machine interruptible, stored as preemptible.

The API also carries \`deploy\_ondemand\` and \`deploy\_preemptible\` flags, which say what can be launched at the moment of the read. They are recorded as evidence and do not change the price: the plan lists a rate whether or not stock is available, which is the same signal GPUQuant reads from every other price list.

[Published prices](https://api.vultr.com/v2/plans-metal?per_page=500)

**DigitalOcean** (DigitalOcean GPU Droplets pricing page)

The embedded size list carries a whole-Droplet hourly price beside the GPU count of the size: \`gpu-h100x8-640gb\` at $35.28 an hour is eight GPUs, divided by eight. The page also prints one 12-month reserved rate per GPU family, per GPU, stored as reserved against the same size.

The one-GPU and eight-GPU H100 sizes are priced at the same per-GPU rate. The index reads the eight-GPU size, because that is the unit it is defined on, and the one-GPU size is recorded outside the tracked set.

[Published prices](https://www.digitalocean.com/pricing/gpu-droplets)

**Together AI** (Together AI pricing page, GPU Clusters)

Together prices HGX nodes per GPU per hour, in its own words ("All prices are per GPU per hour"), for clusters sized from 8 GPUs upward. The on-demand column is read as the published per-GPU rate. Reserved rates are quoted by term, from 7 to 30 days up to 181 days and more; the shortest term is stored as reserved and the others are kept as evidence.

The H100 on-demand rate is marked as a promotion on the page, $5.49 listed and $3.99 charged until 30 September 2026. GPUQuant records the rate a customer is charged, which is what the GPU Clusters table prints, and keeps the promotion text as evidence on the row.

[Published prices](https://www.together.ai/pricing)