Methodology

Rental offers are quoted per GPU-hour, but an hour on two different GPUs buys different amounts of compute. Flopmark divides each hourly price by the product’s published dense BF16 tensor throughput, converting unlike rentals into the cost of the same quantity of compute.

For example, a GPU offered at $2.40 per hour with 800 dense BF16 TFLOPS costs $3.00 per dense BF16 PFLOP-hour: $2.40 × 1,000 ÷ 800.

Dense throughput

We use the rate without a structured‑sparsity multiplier. Sparse peak figures assume a model can skip a prescribed share of its weights; dense throughput is available without that workload‑specific condition.

BF16 inputs

BF16 is widely supported across current training and inference accelerators. It offers the range of FP32 with smaller operands, making it a more consistent cross‑generation reference than vendor‑specific FP8 modes.

PFLOP‑hour

One PFLOP‑hour is one quadrillion floating‑point operations per second sustained for one hour. Pricing this fixed amount removes both GPU model names and raw device speed from the comparison.

FP32 accumulation

The matrix multiplications use BF16 inputs while accumulating partial results in FP32. Fixing accumulation precision avoids comparing unlike vendor throughput claims.

The v1.1.0 panel contains nine exact products: RTX 3090 24 GB, RTX 4080 16 GB, RTX 4090 24 GB, RTX 5090 32 GB, H100 PCIe 80 GB, H100 SXM5 80 GB, L40S PCIe 48 GB, H200 SXM5 141 GB, and L40 PCIe 48 GB. Each valid product receives equal weight.

1. CollectUse the latest complete snapshot inside each provider’s freshness limit.
2. AdmitRequire an exact hardware match, a valid USD price, and positively available inventory. A direct cloud's posted price also keeps voting for up to 6 hours after its offer sells out.
3. VoteCollapse quotes into independent supply votes and take their median for each GPU.
4. NormalizePublish both USD per GPU-hour and USD per dense BF16 PFLOP-hour for the product.
5. ComposeTake the equal mean of the normalized product prices that are valid and not stale.

A recorded quote does not automatically enter the index. It must pass the current method at calculation time.

Exact hardware

Broad labels such as “H100” do not combine PCIe and SXM variants.

GPU count

Only H200 SXM5 accepts eight GPUs, when the raw USD node-hour price equals eight times the stored per-GPU price. All other offers must contain one GPU.

Positive availability

Available/limited inventory votes; unknown inventory does not. Unavailable inventory votes only as a sold-out vote from a direct cloud within 6 hours of its last counted in-stock vote, and a product needs at least one in-stock vote.

Independent vote

A marketplace with hundreds of listings still contributes one provider median.

Quality checks

Ambiguous units, currency, duplication, timing, or identity can exclude a record.

A product round needs at least three independent supply votes from at least three distinct collecting providers. Vote count and collector count are separate requirements.

A valid product round may be retained for up to 1,800 seconds when the next attempt lacks quorum, but only when its complete publication identity matches the composite. The v1.1.0 composite needs seven of nine valid, non-stale products and cannot mix methodology versions. Every composite names its fresh, retained, and missing products.

Disruption ladder. Every product and the composite is in one of three states, published as state. Fresh: the latest attempt produced the round being served. Carried: the latest attempt failed quorum (fewer than three votes or three collecting providers for a product, fewer than seven of nine products for the composite), and the last valid round is served for at most 1,800 seconds from its effective time. A product round is carried only while its complete publication identity matches. Suspended: the round is 1,800 seconds old or older, a product round fails the identity match, or status is unavailable. Nothing is servable, and the single-product and index current endpoints return HTTP 503; the product list is a status listing that always returns 200 and must not be used to settle. Carrying never extends the 1,800 second limit.

The change from v1.0.1 (seven products, six required) to v1.1.0 is a level break. The expanded panel and H200 admission can move the value without a market price change. Values remain unadjusted USD per dense BF16 PFLOP-hour. No history is rescaled or chain-linked.

Every parameter in this method is published as one machine-readable document, generated from the code that calculates the rounds, with a content hash: GET /v1/methodology/current/parameters, or GET /v1/methodology/:version/parameters for a released version. It lists the quorum, the composite rule, the 1,800-second carry limit and the 24-hour snapshot cap, each provider's freshness limit and expected collection interval, the excluded quality flags, source policies with their exceptions and marketplace floors, GPU-count rules, the dense BF16 TFLOPS for each product, and the version of every policy.

A change to any of these voting parameters is a methodology release. Their hash for each version is pinned in the release commit and checked in CI, so a change cannot ship under an existing version. Version dense-bf16-v1.1.2 was already live when the endpoint was added, so its pin dates from first publication on 2026-10-29 and reflects the code deployed then. Each provider's connector mapping version and expected collection interval, and the sensitivity diagnostics, are published in a separate operational section outside the hash, because they do not change what can vote or how a price is computed. For any round, GET /v1/rounds/:roundId/coverage shows which expected providers voted and why each of the others did not. See the API reference.

The data a round depends on is public. The API serves the round, the receipt it cites, and the observations the receipt cites. scripts/reproduce.ts in the Flopmark repository reruns the calculation code the reconciler uses against that data. It works for any round whose receipt and observations the API still stores, and exits with code 2 for a round it cannot find them for.

bun scripts/reproduce.ts sha256:<round id>
bun scripts/reproduce.ts sha256:<round id> --base-url https://api.flopmark.com --product-only

The script fetches /v1/rounds/:roundId, the receipt it cites at /v1/receipts/:receiptId, and the observations at /v1/receipts/:receiptId/observations. It checks that the round hash and receipt hash match their ids and that every observation matches its recorded hash. It then reruns admission, voting, and normalization and rebuilds the round. It prints PASS when the rebuilt round has the published id, and FAIL with every differing field otherwise.

Composite rounds

Pass a composite round id to reproduce each product round it lists, then the composite result.

Coverage

By default the script fetches, hashes, and routes again every observation in the receipt, one request per 200 observations, paced under the API limit of 60 requests a minute. --product-only checks only the observations routed to the product and says in the result that the rest were not checked.

Exit codes

0 for PASS, 1 for FAIL, 2 when verification could not run: the API was unreachable, data was missing, or the round was published under a different methodology version than your checkout. For an older round, check out the commit that published it.

Older rounds

Verification checks a receipt's capability entries against digests pinned for the hardware registry version it records, so a later registry release does not make earlier receipts unverifiable and a forged capability is rejected. A receipt from another methodology release replays only as unpinned, which is not verified. Rebuilding the round needs the checkout of the methodology version that published it.