What an occupied GPU hour finishes

No fleet-wide row appears in this table, and that is deliberate: yield differs by card, so a blended figure moves whenever the mix of work shifts between a faster and a slower card — which would read as reliability changing on a day when nothing about reliability changed. A fleet total is published separately below, as a portfolio outcome rather than a statement about any card.

Below the replication floor, and therefore unnumbered: RTX 3080 and RTX 5070 Ti. Each is backed by a single physical card, and a card that ran hundreds of attempts in a day is one observation of that card, not hundreds. The fleet does run them, and this record states no yield for them. Same two-card floor the goodput exports apply. The suppressed cells are listed in fleet-completion-yield.json.

2026-08-25 has no archived snapshot at all, and is shown as a gap rather than a zero — a date with no snapshot is not a claim that the fleet ran no work that day. The current UTC day is excluded throughout, because the archive file for it can still change.

GPUDeck was running on this fleet on every day in this table, so there is no untreated period to compare against and no claim of improvement is made or implied here. Nothing in this record says the software raised these numbers, held them anywhere, or prevented any particular loss; a change between two days is not evidence that anything caused it. What it establishes is narrower and checkable: unfinished paid work is a real, recurring, measurable cost on a production fleet, at a rate with a denominator rather than an anecdote. Whether the product reduces it would need a fleet running without it, and we do not have one.

Realized network yield, whole fleet

Across 12 non-overlapping snapshots the fleet finished 92.5% of everything it started (50,746 of 54,855). That covers every card the fleet ran, including the ones whose per-card cells are suppressed above: the two-card floor governs what can be said about a card, not what the fleet did. This is a portfolio outcome, not a hardware one: it moves when work shifts between a higher- and a lower-yielding lane even though no card behaved differently, so it must not be read as any card’s reliability — the per-card cells above are the only hardware statement this record makes. 2026-08-21, 2026-08-27, 2026-08-29 is excluded because its measurement window overlaps a snapshot already counted, and the same completions must not be added twice. Computed over 2026-08-20, 2026-08-22, 2026-08-23, 2026-08-24, 2026-08-26, 2026-08-28, 2026-08-30, 2026-08-31, 2026-09-01, 2026-09-02, 2026-09-03, 2026-09-04.

Every published figure above is regenerable from fleet-completion-yield.csv, which carries the started and completed counts each percentage is computed from, plus the measurement window each row was observed over. Suppressed cells are listed with their started and completed counts and NO rate: the replication floor withholds the per-card claim, not the underlying evidence, so a reader can see exactly how much was set aside and recompute anything they like from it. What is withheld is the percentage, because one physical card cannot evidence a property of a card model. The lifecycle archive also records two occupancy counters that are deliberately not published: they cannot be reconciled against the started and completed counts in either direction, so any rate built on them would have a denominator we cannot define. The reason is recorded in the JSON beside the data.

Replication. Every cell on this page comes from a single operator and a single day. 11 of the 12 rows below rest on one physical card on at least one side, marked ●. Across the whole table 11 distinct cards contributed. Attempt counts are not replication: a card that ran 600 attempts in a day is still one card, and confidence that treats those attempts as independent would be wrong by roughly the square root of that count.

No range is claimed for this vintage. Only 1 of the 12 rows below is both free of the host confound and supported by at least two physical cards on each side. One row is not a range, so none is stated. The individual ratios stand as what they are — single cells, each reproducible from the dated open dataset — and the equal-memory table below is the cleaner contrast for this day.

A deployment here is a GPU together with the host, virtualisation layer, software stack and dispatch it ran under — not the card in isolation. These ratios do not isolate a hardware effect, which is why the confounded rows are separated above rather than averaged in.

Goodput is measured on production hosts, and the host is inside the measurement. The class anchoring the widest ratios above runs under a virtualisation layer that reserves part of its memory and cannot be configured away, so treat those ratios as a result that includes a known hosting disadvantage rather than as a property of the hardware alone. The equal-memory table, where both classes sit on comparable hosts, is the cleaner contrast.

Stated per workload and never combined. A single figure across workloads would move with the mix of work each class happens to be sent, which is a fact about dispatch rather than about the hardware — the same substitution this record exists to refuse. Yield is recorded as production loss under the observed network regime, not as a property of any class.

Derived from the goodput table above — no additional observations. This is the same set of measured pairs, reinterpreted as a price threshold rather than an output ratio, so it is a second reading of one body of evidence and not a second, independent result.

Read every row as a threshold, not a price. A multiple of 1.82x on a row says the larger-memory GPU is the cheaper way to finish that workload at any hourly rate below 1.82 times the smaller one; at exactly that multiple the two cost the same. The daggered rows are not usable this way, because part of their headroom is a hosting penalty specific to this fleet.

Read it as a threshold, not a price. A ratio of 4.00x says the larger class is the cheaper way to finish this workload at any hourly multiple below four times; above it, the smaller class wins. The comparison holds where both classes see the same share of billed time spent occupied — where utilisation differs, scale each side by its own occupied-to-billed fraction before comparing.

Pairs are fixed by largest memory, then lowest permanent class index, both chosen before any measurement was read. Selecting the fastest and slowest observed classes instead would pick each comparison on its own outcome. These 12 rows are drawn from 3 distinct GPU-model pairings, so they show how a small number of comparisons behave across many workloads rather than that many independent comparisons; the GPUs in each row are named so this is checkable.