Carbon of Compute · Method report← Back to the leaderboard

The Carbon of Compute - Methodology & Calculations

The default operational catalogue combines measured, derived and estimated inputs. Each result includes scenario assumptions for host electricity, idle capacity, facilities, grid and hardware allocation. A matched H100 BF16 text-chat benchmark is an optional filter, not the catalogue admission rule. These are conditional estimates, not measurements of commercial API deployments or equal-quality answers.

To reproduce an admitted model: python build/trace.py <model_id>. Current worked values and the source ledger are generated in the companion report from the same admitted data as the page.

Operational review, 2026-09-05; catalogue check, 2026-10-10: 84 numerical models: 16 with measured energy and 68 documented estimates. The matched filter contains 13 checkpoints; three further measured checkpoints use other declared hardware/precision conditions. Six older rates are repaired and thirty-six releases use explicit reference transfers; four entries still need a defensible transfer premise. Observation dates and checkpoint hashes are not published; neither retrieval nor page generation is the measurement cutoff.

Data status, 2026-10-10: the hardware figures on this page use the REEL component values rebuilt on 2026-09-09 against REEL export pin f13459771c, the snapshot the published database was generated from. The component values in sections C1 to C3 and the host basis are generated from the pinned files, data/embodied.json and data/hardware_basis.yaml, when the page is built. data/hardware_basis.yaml records the rebuild and the SHA-256 of data/embodied.json. An HTML build does not rerun the inventory or change stored training inputs.


0. The master equation

Total gCO₂e per 1,000 visible output tokens =

TOTAL = ( Operational + IT-Embodied + Facility )  +  Training-amortized

Training is optional and excluded by default. The default carbon result is Operational + IT-Embodied + Facility. Selecting a training scenario adds the training term above; explicit shared links retain that selection.

  • All four terms are gCO₂e per 1,000 visible output tokens.
  • Measured chat configurations have thinking off; generated completion tokens use the visible-answer convention without an extra multiplier. Estimated thinking scenarios retain explicit total-generated/visible ratios. The stored energy already includes the ratio; answer-only divides once. Task-specific hidden-token splits remain uncertain.
  • Water is computed separately (mL/1k), not part of the carbon total.
  • The carbon result has a low/central/high scenario envelope, not a statistical confidence interval or a range for every input. Training-numerator uncertainty is not fully quantified. The token leaderboard and benchmark-response view each show a documented scenario span for covered water, not a complete uncertainty interval.

Default scenario (what the page opens on): grid = US average 386 gCO₂e/kWh, PUE = 1.15, hardware life = 5 yr, lifetime busy-fraction scenarios = 0.15–0.55 (central 0.33), workload = chat turn, training = excluded. The generated default ranking and initial browser state use the same training-mode setting.

0.1 Two kinds of inputs

Everything in the model is one of two things:

  • SHARED assumptions - the same for every model: the boundary/overhead constants, the data-center context (PUE, grid, utilization, lifetime), the embodied-amortization machinery, the facility adders, and the training denominator. These are the "context" a model runs in. (§B-overhead, §C3–C4, §D, §E.)
  • LLM-UNIQUE parameters - the handful that differ per model: operational energy, accelerator, reasoning flag, and training tCO₂e. (§B-inputs, §C2.)

Operational energy and paired GPU-time vary across checkpoints and configurations. Hardware share is not forced to be constant: measured mean GPU power differs, and the central selects minimum observed energy rather than minimum modeled carbon. This is a benchmark scenario, not a survey of live fleet hardware.


A. Functional unit & standardized workloads

Internal unit: gCO₂e per 1,000 visible output tokens. The displayed default is per 1,000,000, with per-1k and per-task controls. The benchmark includes its prompt-processing work in measured serving energy and divides by generated output tokens. Tokenizers and answer quality differ. Output counts provide a transparent allocation unit, not proof of equivalent useful work.

Workload controls scale output volume only. Input token counts below are contextual assumptions, not a separately measured prefill-energy model. There is no validated long-context, RAG, coding-tool or agent-session uplift; a selected task label does not make the chat measurements task-specific. The agentic and uncached profiles in section A.2 add an input term as a declared engineering scenario; they do not change the presets or the ranking.

The public workload cards therefore describe illustrative visible-output volumes. Their research/chat ratio of 300 is the chosen output-volume ratio, not a measured ratio between complete agent sessions and chat turns. API billing output can include reasoning already represented in a per-visible rate. Subtracting a reported reasoning counter does not automatically recover native visible tokens; unresolved denominators support illustrative scenarios only.

Accelerator control: native measured configurations use paired GPU-time with a stored H100/B200 manufacturing scenario; the public summary does not confirm the exact board SKU. Other estimates reconstruct GPU-time from energy and assumed power. Overrides change manufacturing allocation using rated power while holding operational energy fixed; they do not predict another chip’s performance.

Workload Input tok Visible output tok Source / basis
Chat turn 1,000 300 OpenRouter 100T production token study (late-2025 median)
Coding task 6,000 1,000 programming ≈ 3–4× chat input; >50% of production tokens
Reasoning question 1,000 600 visible answer only; thinking tokens handled by the model's per-token rate
Deep-research session 50,000 90,000 SWEnergy session scale

Image/video are unit-incommensurable with tokens → reported on a separate media side-board (§A.1), not the token board. Functional-unit choice follows the Software Carbon Intensity spec (Green Software Foundation / ISO/IEC 21031).

A.1 Media side-board (image & video)

Image and video generation cannot share the token functional unit, so they live on a separate side-board (live in data/leaderboard_data.json → media) with their own units:

Media Functional unit Basis Rows
Image gCO₂e per 1024×1024 image (~30 denoising steps) op-per-image 8 (open diffusion + closed)
Video gCO₂e per second of 720p/24fps video (~50 steps) op-per-second (per-clip also shown) 13

Each media row is built with the same machinery as an LLM row - operational energy normalized to the node basis (§B), then × idle × PUE × grid, on the same default scenario (US grid, PUE 1.15, util 0.33). IT-embodied and facility are included (amortized over the accelerator-hours the generation uses, exactly as §C–D), so the split is comparable to the token board. Training is EXCLUDED from the headline media number (image/video training runs are not yet inventoried to the same bottom-up standard), as in the text leaderboard default. Media evidence has not been admitted under the new LLM benchmark protocol and remains a separate older evidence set.

A.2 Agentic input term (2026-10-15)

Rates are per output token, measured or estimated on short chat-style requests. Agent tools and long documents can send several hundred input tokens for each output token, most of them read from a prompt cache. That input work is not counted in the leaderboard or the presets; the agentic and uncached profiles add it as a separate input term. The defaults were set on 2026-10-15; the multiplier applies to water too. The values and their source lines are in the page data, in the input_term block.

E_node = e_gen x [ u + r_in x (F + k x W + c x R) ] / (1 + r_in x x_bench)
  • e_gen is node energy per generated output token: the row's rate, divided once by its declared thinking ratio where it has one (the same division as the thinking-off view).
  • x_bench is the number of input tokens per output token in the short requests behind the rate, about 0.3 to 1. That prompt work is already inside e_gen. The bracket is in units of a decode token, so it is applied to the decode part of the rate only, e_gen / (1 + r_in x x_bench).
  • F, W and R are fresh input, cache writes and cache reads per generated output token. Cache writes are fresh prefill.
  • The multiplier scales operational, IT embodied and facility carbon, which are all linear in node energy, and the covered water lines: operational water and hardware water. It never scales the training term.
Parameter Central Range Label
r_in, fresh prefill per short-context decode token 0.45 (0.453) 0.05 to 0.46 Estimated; DeepSeek production node-time split at c = 0.01; node time, not energy; 0.05 is a weak latency-basis floor; the top is not a ceiling
c, cache read per fresh prefill token 0.01 0.0025 to 0.1 Declared choice; 0.0025 is the Mao and Zhou transfer ratio; 0.1 is a list-price sensitivity, not a bound; c = 1 is the uncached stress case only
u (decode) and k (cache writes), long-context factor 1 1 to 3.4 Declared: no long-context uplift; 3.4 is dense attention at d = 16,384 and 239k context (Cavagna, extrapolated past its 8,192-token test range); 5.7 is stress only
x_bench, input tokens per output token in the requests behind the rate 1.0 0.3 to 1 Declared choice; the central takes the top of the range, so no prompt work is counted twice; 0.3 gives the upper edge of the figures

The agentic profile is our own measurement of 24 hours of agentic coding sessions with Claude Opus 5.5 (2026-10-14 18:28 to 2026-10-15 18:28 UTC): five groups of agent sessions and 24,845 model responses, counted from the token usage of each response only. Over all sessions there were about 495 context tokens per output token (494.8:1); one session group ran at 212:1 and another at 1,177:1. Cache writes were 1.344 per cent of the cache tokens of the two session groups used for the shape, so 500 context tokens per output token give 6.72 cache writes and 493.3 cache reads; fresh input was 0.005 per output token, taken as 0. Output includes thinking. The per-session token extraction is not public; these summary figures are its record. The public vLLM AgentX trace (median 142K input and 444 output tokens per request, about 320:1 taking the ratio of the two medians) is the external cross-check.

Case Multiplier
Central (r_in 0.453, c 0.01, u = k = 1, x_bench 1.0) 4.32
Central with the benchmark prompt at x_bench 0.3 5.53
Low (r_in 0.05, c 0.0025) 1.33
Central r_in, c 0.0025 3.17
Dense attention, d 16,384, 204k to 239k context 10.0 to 11.0
Dense attention, d 8,192, 239k context (stress) 17.5
List-price cache read, c 0.1 18.2
List-price cache read of Opus 5.5 and Sonnet 5.5, c 0.05 10.5
Uncached stress, c 1 157

Central arithmetic: (1 + 0.453 x (6.72 + 0.01 x 493.3)) / (1 + 0.453 x 1.0) = 6.2788 / 1.453 = 4.32.

For the agentic coding sessions we measured, counting the input raises the result per billed output token about 4.3 times in the central case. In the low case it raises the model's own low-scenario rate at least 1.3 times. We found no upper bound. It is higher if attention cost grows with context (about 10 to 11 times for a dense-attention model) or if cache reads cost more than assumed.

Profile Input term Use
Chat none Today's calculation and the ranking. The rate already carries the benchmark's own prompt work, so adding a term would count it twice.
Agentic, cached c = 0.01 The measured shape.
Long context, uncached c = 1 Stress case only.
  • The benchmark's own prompt. The chat rate already includes the prompt work of its short requests, about 0.3 to 1 input token per output token. The input term multiplies only the rest of the rate, taking the prompt at 1 input token per output token, the top of that range, so no prompt work is counted twice. If the prompt was nearer 0.3, every agentic and uncached figure would be 1.28 times higher (5.53 instead of 4.32 in the central case), so the central may be up to about 22 per cent too low. This is an under-count we accept rather than a double count. Before 2026-10-18 the whole chat rate was multiplied, which put every agentic and uncached figure 1.14 to 1.45 times too high. One row that shows agentic figures has a rate from production data rather than from benchmark requests: Gemini 2.5 Flash, a transfer from the Gemini Apps average per prompt. The prompt work inside that rate is not known and may be larger than this allows for.
  • Boundary of c. It covers KV retrieval only. Attention of new tokens over the cached context sits in u and k, so the two terms do not count the same work.
  • Holding caches. The electricity of holding prompt caches between turns is not counted. The busy-fraction setting spreads only the manufacturing footprint over busy hours and adds no electricity. The only electricity allowance that could cover part of it is the flat 1.12 idle allowance. So this leaves something out; it does not count anything twice.
  • Water and training. Water scales with the same multiplier as carbon. Two water lines scale: operational water (on-site cooling, per IT kWh, and electricity-generation water, per facility kWh) and hardware water (manufacturing water, allocated by the same GPU time as IT embodied carbon, where the row has a water inventory). The training term does not scale, and no training water is included.
  • Training on the billed basis. Training is amortized per visible output token. The agentic and uncached figures are per billed output token, which includes thinking, so where training is included the Scope 3 estimator divides training by the same thinking ratio as the rate and adds it once per billed token.
  • The floor on the card. The floor is the low multiplier (1.33) times the model's own low-scenario rate: the lowest operational, hardware and facility values over its configurations, its utilization range and its hardware range. It is not the low multiplier times the central rate, which would not be a floor. The agentic card prints the floor as a multiple of the model's own central chat basis per billed token, and beside it the low multiplier. The Scope 3 estimator prints absolute "at least" figures on billed output, from the same low-scenario rate and, where training is included, the low training estimate.
  • Opus row group held. Opus 4.8, Opus 5, Opus 5.5, Fable 5 and Fable 5.1 show no agentic or uncached figure and no comparison of Opus with Sonnet per token. Their rate is per visible output token. To put it per billed token it is divided by the number of billed tokens per visible token, and for these models that number is an older assumption of 7 (4 to 11) that has not been checked against measured token use (see the reasoning usage pilot section).
  • Rows with a borrowed thinking ratio held (2026-10-15). A model's rate per billed token is its rate per visible token divided by its thinking ratio, so a ratio that is too high for that model pulls the agentic figure down. When these figures were first worked out, five models came out below their own chat figure: Kimi K3, Kimi K2 Thinking, Kimi K2.5, GPT-5.5 Pro and Qwen3-Max. Only a ratio measured on the same model or the same backbone (research/11_reasoning_premiums.md, section 3) is accepted. The following rows are held for the same reason as the Opus group, because their ratio was set by class analogy, inferred from a token count, re-anchored to another model or copied from another model by a proxy recipe: Gemini 2.5 Pro, gpt-oss-120b, Gemini 3 Flash, o3, o4-mini, DeepSeek V4-Pro, DeepSeek V4-Flash, GLM-5, Kimi K2 Thinking, MiniMax M2, Nemotron 3 Super, Qwen3-Max, Grok 4.3, GPT-5.5 Pro, Gemini 3.5 Flash, GPT-6 Astra, GPT-5.6 Sol, GPT-5.6 Terra, GPT-6.1 Sol, GPT-6 Sol, GPT-5.6 Luna, GPT-6 Luna, Gemini 3.1 Pro Preview, Gemini 3.6 Flash, Gemini 3.7 Flash, Gemini 3.8 Flash, Gemini 3.5 Flash-Lite, Grok 4.5, Grok 4.6, Muse Glimmer-30B, Qwen3.8-27B, Qwen3.8-Flash-Next, Qwen3.6-35B-A3B, Command A+, GLM-5.3, GLM-5.3-Flash, Kimi K3, Kimi K2.5, MiniMax M3, Nemotron 3.5 Lightning and Hy4-preview. The source line of each ratio is in the page data, in input_term.held_rows. DeepSeek-R1, Gemini 2.5 Flash and Qwen3 235B-A22B keep their figures. Every model with a thinking ratio is on one of the two lists.
  • Transfer. Applying the Opus 5.5 token shape to any other model, including Sonnet 5.5 and Haiku 5.5, is a transfer. Haiku 5.5 is the weakest: its prompts over 100,000 tokens are billed at 5 times its input price, a different long-context regime.
  • Declared choices. c = 0.01 and u = k = 1 are declared choices, not measurements. r_in comes from server time, not measured energy, at one provider for one model family. No value here is a Claude measurement.
  • Scope 3 estimator. Four fields match provider usage data: uncached input, cache writes, cache reads and output. Anthropic's input_tokens excludes cache reads and writes. In the chat profile the three input fields are off and the estimator gives the chat basis, because the chat rate already carries the benchmark's own prompt work. An agentic or uncached row with input tokens and no output tokens has no figure, and the total is unavailable until its output is entered.

B. Operational energy

Operational evidence review

The protocol is coc-h100-bf16-chat-v1: ML.ENERGY text conversation (lm-arena-chat), NVIDIA H100, BF16 weights and thinking off. Among published configurations with p95 smoothed client inter-token gaps at most 50 ms, choose the lowest observed GPU joules per output token. The 50 ms threshold is our explicit comparison scenario, not a first-token or end-to-end latency guarantee. The source configures 1,024 sampled conversation prompts and a 4,096-token output cap. Model tokenizers, answer lengths and quality differ.

The factual inputs come from the public presentation summary at commit 5d899ea5. Source array indices and row hashes distinguish configurations, including duplicate configuration tuples. These summaries omit raw-run timestamps, runtime revisions and exact model-weight hashes. vLLM 0.11.1 and task settings are benchmark-declared provenance, checked against public code; they are not independently verified per run. No gated raw data, prompts or responses were downloaded.

The data publisher's packaging instructions supply an Apache-2.0 data license. Our input is a scoped extraction of published factual observations with attribution and explicit transformations. This does not imply a code license for the leaderboard repository or independent validation of its raw measurements.

Units and boundaries

GPU Wh / 1,000 output tokens = GPU joules / output token / 3.6
active node Wh = GPU Wh * 1.43
facility electricity Wh = active node Wh * 1.12 * selected PUE
operational gCO2e = facility electricity Wh / 1,000 * grid gCO2e/kWh

GPU energy already sums the participating GPUs. Do not multiply it by GPU count again. The same measured configuration supplies mean power, throughput, GPU count, precision and latency.

Public summaries identify H100 or B200 but do not confirm an exact board SKU. Mapping to stored REEL hardware plus host inventories is a manufacturing-allocation scenario. Facility refrigerant uses the shared default for measured configurations; the checkpoint author is not an observed serving operator. Estimated rows retain their explicitly assumed provider-specific refrigerant scenarios.

Host factor 1.43 and idle uplift 1.12 are transferred from Google’s production decomposition; these are scenario assumptions. Legacy full-stack inputs use their declared source overhead normalization, including the existing 1.217 division. Google’s 0.24 Wh May 2025 Gemini Apps aggregate is an explicitly labelled family proxy using an assumed 300 visible tokens per prompt; neither the denominator nor a version attribution was disclosed by Google.

Configuration span and uncertainty

For measured models, central means the lowest observed GPU-energy configuration in the declared group, with the 50 ms screen applied only to the matched cohort. Low/high bounds evaluate each complete qualifying configuration with the declared low/high environmental scenarios, then take extrema of complete totals. Energy from one run is never paired with power or GPU-time from a different run. The span is not a confidence interval, a production-load distribution or coverage of all possible deployments. Meter uncertainty, run-to-run variability, software changes and transferred host/idle assumptions are not fully quantified.

Admission and missing evidence

The operational register reviews all 40 previously active entries. Declared predecessor transfers, power reconstructions and answer-length/reasoning assumptions can be Estimated. Estimates need not belong to the matched benchmark. The current catalogue includes 84 numerical scenarios: 16 Measured and 68 Estimated. Fable, Astra, the Claude 5.5 models, the GPT-6 Sol and Luna models and other admitted releases have explicit reference-transfer recipes, with unquantified transfer error disclosed; they are not measurements of their commercial deployments. Muse Spark 1.1, Muse Spark 1.3, Nova 2 Lite and GPT-Rosalind remain unestimated because a numerical reference or concrete architecture/work premise has not been established. Missing evidence is not zero impact.

Current measurements and a worked example are generated below under Operational evidence review. PUE and grid factors remain selectable scenarios from the older snapshot, not claims about each model's deployment location.

The Pacific Northwest setting retains 305 gCO₂e/kWh as a legacy engineering estimate for an annual-average grid scenario. The exact life cycle uplift behind 305 has not been reconstructed; EPA's annual-average generation data do not establish this life cycle number. It is not a marginal-emissions factor. The numerical setting is retained pending source reconstruction, rather than silently replacing its accounting boundary.

Serving-work boundaries across sources

The broad comparison combines differing source workloads, hardware, precision and latency criteria. In particular, the additional measured groups select lowest observed energy without the 50 ms p95 token-gap screen used by the optional H100 BF16 cohort. Applying that screen within their existing hardware/precision groups changes selected GPU energy by about 4.02x (Llama 3.1 405B), 4.82x (DeepSeek V3.1) and 1.95x (Llama 4 Maverick). Those are configuration sensitivities, not factors applied to this leaderboard or equal-quality API comparisons.

Google's Gemini Apps measurement, sections 3.1-3.2 includes supporting scoring, ranking, classification and routing models; its source excludes external networking and data storage. Single-checkpoint energy measurements do not establish coverage of separately executed supporting models. Host, idle and PUE uplifts do not add routing, safety, retrieval, storage or tool-service work. Each breakdown identifies its service boundary, and transfers inherit the anchor's boundary limitations. Unequal auxiliary-work coverage can affect ranking; its magnitude is unquantified. Do not remove broader source coverage or add a blanket percentage to compensate.

C. IT-embodied carbon (the REEL moat)

C1. Component anchors - REEL bottom-up, characterized to kgCO₂e

REEL's public foreground inventory records process inputs and outputs from public sources. Its screening calculation links purchased energy and materials to licensed ecoinvent 3.12 background cumulative LCIA (IPCC 2021 GWP100) and applies public IPCC AR6 GWP100 characterization to direct fab-gas emissions. Carbon of Compute reads the resulting composite component impacts. Licensed background results are distinct from direct-emission characterization factors; describing this as characterization-factor-only use would omit the upstream supply chains. The foreground inventory does not redistribute licensed background inventories. Public outputs must also protect original licensed factors and readily invertible results.

Anchor REEL dataset Capacity modeled kgCO₂e Used by
5 nm logic wafer (300 mm) wafers/node_5nm_taiwan_best_practice 1,189.942 per wafer H100, H200, B200, MI300X
7 nm logic wafer (300 mm) wafers/node_7nm_moderate 1,093.153 per wafer A100, MI300X
3 nm logic wafer (300 mm) wafers/node_3nm_taiwan_best_practice 1,319.755 per wafer not used by a listed accelerator
CoWoS-S 2.5D interposer and assembly, per package packaging/cowos_25d 8.92 per package H100, H200, B200, A100, MI300X
HBM3 8-Hi stack memory_components/hbm3_8hi 16 GB 13.519 per stack H100, A100
HBM3 12-Hi stack memory_components/hbm3_12hi 24 GB 19.811 per stack MI300X
HBM3e 8-Hi stack memory_components/hbm3e_8hi 24 GB 13.985 per stack H200, B200
HBM3e 12-Hi stack memory_components/hbm3e_12hi 36 GB 20.601 per stack not used by a listed accelerator
DDR5 DRAM IC (1-beta, FBGA) memory_components/dram_ic_1beta_fbga 2 GB 0.56 per package host system DDR5
NAND package (232 layers, FBGA) memory_components/nand_flash_ic_232l_fbga 1024 GB 12.738 per package host bulk storage
DDR5 DRAM, per GB DRAM IC ÷ 2 GB 0.2799 per GB host system DDR5
NAND, per GB NAND package ÷ 1024 GB 0.0124 per GB host bulk storage

These values reproduce data/embodied.json at REEL export pin f13459771c (file SHA-256 8e26816480f5, recorded in data/hardware_basis.yaml); this table is generated from that file when the page is built. Anchors are stored to three decimals and per-GB values to four, each from the unrounded REEL value, so a per-GB value can differ in its last digit from the printed anchor over its capacity (DDR5: 2 x 0.2799 = 0.5598 kg, printed 0.56).

C2. Per-accelerator BOM (public specs) × anchors → kgCO₂e

BOM reconstructed from publicly known specs (die area, HBM stack count, package) - never from private product bills of materials. Die carbon = wafer / dies-per-wafer, where dies-per-wafer is geometric (REEL's dies-per-wafer calculator), no defect-yield derate (an optimistic/lower-bound simplification).

All figures below are kgCO₂e per physical accelerator, generated from the same pinned files as the leaderboard.

Accelerator Logic die HBM (stacks; derate) Package Board REEL bottom-up total Vendor PCF per device HBM share of REEL total
NVIDIA H100 SXM5 80GB 19.5 67.6 (HBM3 16GB×5; 1) 8.9 35.0 131.0 164 (NVIDIA HGX H100 Product Carbon Footprint: 1,312 per 8-GPU baseboard; 1,312 / 8 = 164) 51.6%
NVIDIA H200 SXM 141GB 19.5 82.6 (HBM3e ~23.5GB×6; 0.9792) 8.9 35.0 146.0 none published 56.6%
NVIDIA B200 192GB 34.5 111.9 (HBM3e 24GB×8; 1) 8.9 45.0 200.3 284.25 (NVIDIA HGX B200 Product Carbon Footprint: 2,274 per 8-GPU baseboard; 2,274 / 8 = 284.25, stored rounded as 284) 55.9%
NVIDIA A100 SXM 80GB 17.9 67.6 (HBM2e 16GB×5; 1) 8.9 30.0 124.4 128 (Falk 2025 teardown c-t-gate) 54.3%
AMD MI300X 192GB 47.7 158.5 (HBM3 24GB×8; 1) 8.9 45.0 260.1 none published 60.9%

The package line (CoWoS-S 2.5D, 8.9 kg) is the silicon interposer and 2.5D assembly only. It does not include the HBM stacks, which are counted once through the HBM anchor: for H100, 5 stacks of 16 GB at 13.519 kg each (derate 1) give 67.6 kg, so the breakdown die 19.5 + HBM 67.6 + package 8.9 + board 35.0 = 131.0 kg counts each component once.

HBM derating. HBM is derated to each accelerator's nameplate GB per stack: only the capacity-scaling DRAM core-die portion is scaled by nameplate ÷ anchor GB, and the fixed per-stack portion (base logic die, TSV, package, assembly) is unchanged. The rule is defined in build/build_embodied.py; the factor applied to each accelerator is the derate in the table above. A source that attributes about 42% of CoWoS process energy to the HBM it packages refers to the packaged components' share, not to the package line above (QC-confirmed 2026-06-27; not a double count).

Vendor comparison. Differences from vendor product footprints depend on component coverage, manufacturing assumptions and allocation. An HBM share inferred from an accelerator-board PCF is not a standalone HBM PCF, and a REEL/vendor bracket is not a statistical uncertainty interval. Sources: NVIDIA HGX H100 / B200 Product Carbon Footprint summaries; Falk et al. 2025 (arXiv:2509.00093, A100 teardown).

A100 capacity caveat (QC note 2026-06-27). The Falk 2025 teardown PCF is the 40 GB A100, while REEL models the 80 GB SXM (twice the HBM). Read the A100 pair as a capacity-spanning comparison, not a like-for-like REEL-versus-vendor delta. The A100's HBM figure is computed from the HBM3 8-Hi stack anchor (five stacks at its declared 16 GB, derate 1), so HBM3 stands in for the A100's HBM2e; the generation difference is not modeled. A100 is not in the live model list, so this affects the reference tables, not any ranked row.

Corrected hardware basis used by the calculator. The leaderboard does not amortize the accelerator alone. Since the hardware basis reconciliation (research/60_hardware_basis_reconciliation_2026-09-06.md, data/hardware_basis.yaml, landed 2026-09-07), each physical accelerator carries its share of the retained host and bulk storage, and for H100 and B200 the basis is a corrected native-method scenario pair. The method is the record's and is unchanged; the figures on this page were recomputed with it at REEL export pin f13459771c and supersede the earlier figures the dated record prints. These endpoints are method scenarios, not confidence intervals. A100 keeps its vendor/REEL midpoint and H200 and MI300X keep their REEL-only sensitivity, as the reconciliation record states; their boundary and topology uncertainties are not resolved by the H100/B200 correction. B200 uses the H100 board geometry as a declared transfer.

Retained host and bulk storage per accelerator: (1,994.9 + 203.8) / 8 = 274.838 kg. The correction removes the duplicated baseboard printed circuit board (553 x 416 mm x 507 kg/m² / 8 = 14.579 kg per device), which both the accelerator board allowance and the retained host count, at both endpoints. At the vendor endpoint it also removes the retained host NVSwitch share (25.7 / 8 = 3.2125 kg), because the HGX baseboard PCF already includes the NVSwitch chips.

Accelerator REEL plus host Vendor PCF plus host Central Basis
NVIDIA H100 SXM5 80GB 391.258 421.046 406.2 corrected: baseboard overlap removed at both endpoints, host NVSwitch share removed at the vendor endpoint; central is the midpoint
NVIDIA H200 SXM 141GB 420.838 none published 420.8 retained REEL-only sensitivity 294.586 to 483.963 (x0.7 and x1.15)
NVIDIA B200 192GB 460.558 541.296 500.9 corrected: baseboard overlap removed at both endpoints, host NVSwitch share removed at the vendor endpoint; central is the midpoint
NVIDIA A100 SXM 80GB 399.238 402.838 401.0 retained vendor/REEL midpoint; no board-overlap correction asserted
AMD MI300X 192GB 534.938 none published 534.9 retained REEL-only sensitivity 374.456 to 615.178 (x0.7 and x1.15)

Endpoints are shown to three decimals as the calculator computes them; the central is rounded to one decimal as the leaderboard shows it.

C3. Per-GPU amortization basis (accelerator + its share of host + bulk storage)

Per-token embodied amortizes the accelerator plus its share of host compute and bulk storage. NVMe bulk storage is folded into the per-token basis and amortized over active GPU-hours like the rest of the server silicon; it was previously excluded as a facility service. Its SSD boundary is the least-settled line in the host basis. Reversible: drop storage_total in build_embodied.py to restore exclusion.

basis_central = midpoint(REEL_with_corrected_host, vendor_with_corrected_host)
shared host/fabric/storage = (1,994.9 + 203.8) / 8 = 274.8375 kg/device
H100-class baseboard area proxy = 0.553 x 0.416 = 0.230048 m2
remove duplicated baseboard PCB = 0.230048 x 507 / 8 = 14.579292 kg/device
vendor endpoint also removes duplicated host NVSwitch = 25.7 / 8 = 3.2125 kg/device
H100 REEL endpoint = 131.0 + 274.8375 - 14.579292 = 391.258 kg/device
H100 vendor endpoint = 1,312 / 8 + 274.8375 - 14.579292 - 3.2125 = 421.046 kg/device
H100 central = (391.258 + 421.046) / 2 = 406.2 kg/device
B200 REEL endpoint = 200.3 + 274.8375 - 14.579292 = 460.558 kg/device
B200 vendor endpoint = 2,274 / 8 + 274.8375 - 14.579292 - 3.2125 = 541.296 kg/device
B200 central = (460.558 + 541.296) / 2 = 500.9 kg/device

These lines are generated from data/embodied.json (REEL export pin f13459771c) and data/hardware_basis.yaml when the page is built; the endpoints are the ones the calculator uses. The landing page's per-GPU amortization basis (406 kg) is the stored per_gpu_amortization_basis, 405.8 kg: the H100 REEL total plus the retained host share before any correction (131.0 + 274.8375 = 405.8375, stored as 405.8); the host share is checked against it, and it is not the corrected H100 central of 406.2 kg.

The retained accelerator board allowance already includes a baseboard share. The downstream reconciliation therefore removes that share from the common host addition for H100/B200; the vendor endpoint also removes the duplicated switches. The rectangular footprint comes from NVIDIA's OCP HGX Form Factor R1 specification, Table 8. Its use for B200 is an explicit H100-class geometry transfer. The residual motherboard area is a proxy, not a measured laminate inventory.

Manufacturing reference Central kg CO2e/device Source/reference span Basis
H100 reference 406.2 391.3–421.0 corrected native method scenarios
B200 reference 500.9 460.6–541.3 corrected native method scenarios
Google v6e reference 676.7 676.7–676.7 published hardware with fabric reference
Ironwood physical-class proxy 500.9 460.6–541.3 transferred hardware method scenarios
Claude mixed-fleet proxy 977.7 460.6–977.7 physical hardware reference scenarios

Host and fabric BOM per 8-GPU server, REEL-modeled (server_8xh100 in data/embodied.json, kgCO₂e): 2× Xeon CPU (Intel 7 ~10nm, ~1600mm² total) 34.2; System DRAM 2 TB DDR5 573.2; 10× NIC/DPU (ConnectX-7, proxy) 80.0; UBB + mainboard PCB (proxy 507 kg/m² × 0.6 m²) 304.2; 6× PSU 3.3kW (proxy) 108.0; Chassis + mechanical (steel, proxy) 120.0; 4× NVSwitch (TSMC 4N ~300mm², baseboard scale-up) 25.7; Network fabric (scale-up+scale-out, 8-GPU share) 749.6 = 1,994.9 kg. Bulk storage adds 203.8 kg per server, amortized on top: NVMe storage 16 TB (bulk; folded into per-token basis 2026-07-07). The network fabric (scale-up and scale-out, 749.6 / 8 = 93.7 kg per accelerator) is REEL's white-paper Networking BOM: optical transceivers 37.5 (REEL-modeled; no public PCF, the largest fabric line and a flagged gap), leaf/ToR switches 16.1, spine switches 11.8 (REEL-modeled), NVLink rack switch trays 11.3, DAC/AOC and cabling 8.7, NVLink copper backplane 8.3. Each is read from LINES in the white paper's dc_embodied_split.py (quantity x unit kg / 576 accelerators). These lines are rounded to one decimal from the split; unrounded they sum to 93.68 against the stored 93.7. The on-baseboard NVSwitch (25.7 kg per server) is the intra-node NVLink tier, kept additional to the rack switch trays (a pure-HGX or pure-NVL72 node carries one tier, so counting both is a small conservative over-count). (System DDR5, 573.2 kg or 28.7% of host compute, is 2,048 GB at 0.2799 kg/GB: the REEL 16 Gb DDR5 die anchor (memory_components/dram_ic_1beta_fbga, 0.56 kg per 2 GB package, rounded from 2 x 0.2799 = 0.5598 kg) over its own capacity, with no die-class transfer. It is the second-largest host line, after the network fabric. The pinned DDR5 value sits below the open Boavizta DDR5 range of about 0.4 to 1.0 kg/GB recorded in research/09_qc_dc_embodied.md; this page does not reconcile the two. The white paper's 0.15 LPDDR5X is Grace/NVL72 memory, not an x86 DDR5 RDIMM.)

External hardware references: every model assigned the same physical reference uses the same manufacturing basis. The Google v6e source is per chip, including its CPU-host share and tray SSDs: 323 + 260 kg manufacturing/transport, with construction excluded because facility impacts are handled separately. Add the retained 93.7 kg/device fabric reference once. Google excludes auxiliary storage beyond its trays; adding the full shared storage amount again as though local SSDs were absent would overlap its boundary.

Claude uses a named Google v5p-class manufacturing reference (585 + 299 kg plus the same fabric), with v6e and B200 reference alternatives. Actual Trainium/TPU deployment shares, host topology and manufacturing impacts are unknown. Ironwood uses a B200 physical-class reference; dual-die/HBM similarities support an engineering analogy, not equal measured manufacturing impacts. The B200 PCF states 180 GB per GPU while the stored REEL recipe totals 192 GB; raw-versus-usable correspondence is unresolved, so no capacity ratio is applied. These are source/reference scenario spans, not confidence bounds on proprietary devices. The v6e manufacturing source has no added numerical bounds; its uncertainty remains unquantified. TPU/Trainium water stays unavailable because a carbon reference is not a water inventory.

C4. Amortize over paired GPU-time

observed watts/GPU = measured aggregate GPU power / GPU count
GPU-hours / 1,000 tokens = GPU Wh/1,000 / observed watts/GPU
                       = GPU count / (aggregate output tokens/second * 3.6)
embodied gCO2e/1,000 = basis kg * 1,000 / (life years * 8,760 * utilization) * GPU-hours/1,000

REEL supplies a physical component inventory, subsequently characterized using Carbon's background data. It does not supply tokens served during a device's lifetime. Manufacturing per workload therefore equals the device's manufacturing footprint multiplied by workload accelerator-hours divided by lifetime active accelerator-hours. This is an allocation of the inventory, not a replacement of REEL with electricity data. Paired measured throughput/time is preferred. When it is missing, accelerator energy divided by the declared operating power estimates device time; that extra assumption remains visible.

Native measured hardware allocation uses the selected measurement's mean power and throughput. Estimated inputs use declared power and energy-based GPU-time; seven repaired throughput recipes use exact GPU-time and the reciprocal of their stated host factor. For transferred hardware, that serving time is allocated to the explicitly assumed manufacturing asset. Thus embodied share can differ across models on the same hardware. Lifetime utilization is the fraction of installed life allocated to active serving; it is not the benchmark batch size or an SM-utilization measurement. Hardware overrides retain rated-power allocation as an explicitly hypothetical manufacturing scenario and do not predict operational performance on another chip. Low/high results preserve each configuration's paired energy and GPU-time. All admitted estimates propagate their low/central/high energy scenarios through hardware and facility work as well. This changes previous ranges that varied operational energy while holding allocation work central; the three retained 600 W recipes (Phi-4, Mistral NeMo 12B and Qwen2.5 72B) now use that same declared power for allocation rather than the 700 W hardware fallback. Their operational electricity is unchanged.

The retained 0.15 / 0.33 / 0.55 lifetime busy fractions are engineering allocation scenarios, not measured fleet occupancy or a calibrated uncertainty interval. They refer to time serving at the selected configuration's rate across the installed asset's life. SM utilization, performance relative to peak throughput and commercially reserved capacity are different quantities; FlexPipe/LithOS occupancy observations do not establish this lifetime fraction. No matching production observation validates the chosen band. The measured configuration's active time and this separate lifetime-allocation assumption must remain distinct.

D. Facility (non-IT), per kWh of provisioned IT energy

From REEL's Modeling the AI Factory reference hall (1 MW IT, liquid-cooled). All adders are gCO₂e per kWh of IT energy, so they scale per token: facility/1k = (node_Wh × idle / 1000 kWh) × (fe + gen + refrigerant).

Adder gCO₂e/kWh-IT Basis / source
Facility embodied [†] 2.5 (1.8–8) annualized non-IT equipment manufacturing carbon ÷ annual IT energy (EPD line-item BOM; derivation below)
Standby diesel genset 1.7 (0.8–5.4) 0.73 kgCO₂e/kWh-generated (EIA/DEFRA) × ~0.23% of annual energy (testing + outage)
Refrigerant fugitive provider-specific (below) IPCC 2006 GL Vol.3 Ch.7 Tier 2 (chillers)

[†] "Facility embodied" = facility plant (power chain + cooling equipment) only - it deliberately excludes the building shell (concrete/steel structure, land, fit-out). Read the label as "facility plant (power + cooling)". The shell is a real but separately-bounded contribution (often campus-amortized over 15–30 yr and not attributable per token without a hall-occupancy model); omitting it is a conservative, clearly-bounded choice, not an oversight.

Where facility-embodied comes from (central 2.5, range 1.8–8)

It is the manufacturing carbon of the non-IT facility equipment (power chain + cooling), amortized over service life, divided by the hall's annual IT energy. Reference hall (REEL Modeling the AI Factory): 1 MW IT × 8,760 h × ~0.9 load = 7.88 GWh IT/yr. The basis is the EPD-anchored line-item BOM, annualized:

Line as-built service life annualized EPD / LCI anchor
UPS 40.0 t 15 yr 2.67 t/yr ABB EPD (~33 kg/kW)
Transformers (2×1.5 MVA, N+1) 66.0 t 30 yr 2.20 t/yr EPD-Italy / Matelec (~14 kg/kVA)
Standby genset (embodied only) 60.0 t 30 yr 2.00 t/yr ABB AMG-class, mass-scaled
Floor PDUs 30.0 t 20 yr 1.50 t/yr EPD build-up
Li-ion battery (LFP) 7.4 t 8 yr 0.93 t/yr Peiseler 2024 (54–69 kg/kWh)
Facility cabling (Cu/Al) 20.0 t 30 yr 0.67 t/yr Prysmian/Nexans EPD
Switchgear 12.0 t 30 yr 0.40 t/yr ABB EPD
Power chain 10.4 t/yr → 1.32 g/kWh-IT
Cooling (CDUs, cold plates, manifolds, coolant, CRAH, heat-rejection, pumps/piping) 57.3 t 5–20 yr 4.2 t/yr REEL mass + Trane/CIBSE TM65 (no liquid-cooling EPD) → 0.53 g/kWh-IT
Facility total (bottom-up) 14.6 t/yr → 1.85 g/kWh-IT

Shipped central = 2.5: the bottom-up 1.85 nudged up for (a) 2N power redundancy in real hyperscale halls (vs the N+1 modeled), (b) shorter practical service lives than nameplate, and (c) the cooling line being a likely under-count (no public EPD exists for CDU / cold-plate / manifold hardware). Range 1.8 (bare BOM / campus-amortized floor) – 8 (full single-hall allocation, EPD-conservative upper).

Why not 5.0? An earlier "EPD top-down" estimate reached 5.0 by taking "facility ≈ 12% of total hall embodied" and multiplying by an assumed compute embodied of 40–60 g/kWh-IT. But facility hardware (transformers, UPS, gensets) weighs the same tonnage regardless of which GPU PCF you choose, so the share method circularly inflates facility when you pick a heavier compute anchor - it double-applies REEL's embodied premium. The line-item sum (1.85) is the non-circular basis. This is a small line (~0.2–1.4% of a typical total) - negligible on dirty grids, but it climbs to a few percent on clean grids, so the central is set honestly rather than conservatively averaged.

Where "genset 1.7" comes from

1.7 g/kWh-IT = 0.73 kgCO₂e/kWh-generated × 0.0023 (fraction of annual energy from the generator) × 1000. - 0.73 kgCO₂e/kWh: EIA diesel CO₂ (2.69 kg/L) ÷ genset efficiency (~3.7 kWh/L); DEFRA gas-oil corroborates. - ~0.23% of energy (0.0023): NFPA-110 monthly testing (~30 h/yr at ~50% load = 15 equiv-h) + ~2 h/yr outage at full load + startup/load-bank margin ≈ 20 equiv-h ÷ 8,760 h ≈ 0.0023. (The bare 17 h floor is ~0.0019 ≈ 0.19%.) Low end (0.8) = HVO renewable diesel; high end (5.4) = more outage runtime.

Refrigerant - IPCC Tier 2 (chiller life cycle), provider-aware

annual_loss_kg = charge × [ annual_leak + (install_loss + eol_loss)/lifetime ]
charge = 0.22 kg/kW × (1 MW × cooling_capacity_factor 0.15) ;  refrigerant_g/kWh-IT = annual_loss × GWP × 1000 / annual_IT_kWh

Inputs: charge 0.22 kg/kW (Trane CenTraVac), annual leak 2.5% (optimistic end of IPCC chiller 2–15% band), install 0.5%, EoL 5%, life 20 yr, cooling-fraction 0.15 (liquid-cooled residual chiller). Most common refrigerant (R-134a, GWP 1526 AR6) by default; low-GWP for operators known to use it: Google → R-1234ze (GWP 1.37), Microsoft & OpenAI/Azure → R-513A (GWP 672). Result: R-134a 0.178 g/kWh-IT; R-513A 0.078; R-1234ze ~0.00016. Sources: IPCC 2006 Guidelines; IPCC AR6 GWP100; EPA/ASHRAE leak-rate ranges.

Water (mL/1k, reported separately) - three potential layers

On-site cooling uses IT electricity times the selected cooling WUE. Electricity-generation water uses facility electricity including PUE times a consumption factor. Hardware water uses the selected accelerator's available manufacturing-water inventory and paired GPU-time. A carbon estimate is not a manufacturing-water inventory.

Electricity-generation water is included. Regional life cycle estimates combine licensed ecoinvent 3.12 water results with public generation-mix assumptions. Both reservoir scenarios use the existing inputs: including reservoirs adds gross evaporation allocated entirely to hydropower; excluding reservoirs removes that contribution. These scenario choices do not quantify all uncertainty in geography, evaporation accounting or allocation.

Hardware component coverage: accelerator die, HBM and package; host CPU, system DRAM and NVSwitch. Storage, boards, NICs, PSUs, chassis and fabric have no corresponding water terms in this snapshot. A model having a hardware-water input does not imply complete hardware-manufacturing water. Missing quantities are unquantified and are not established to be minor. REEL 1.0 exports may supply some component inventories, but the Carbon builder must also map their quantities, units, capacity and overlap correctly. Locking the upstream data alone does not add omitted terms.

Displayed water covers cooling, electricity generation and available hardware water. It omits training water and separate facility-equipment manufacturing water. TPU/Trainium manufacturing inventories remain unavailable, including when selected as an override. These are partial results and cannot establish a total-water comparison of deployments. Both views show a scenario span for the covered-water subtotal. In the token leaderboard, each complete operational configuration or declared energy/device-time scenario is evaluated with the cooling regime's low/high WUE and high/low lifetime busy fractions. Sum cooling, generation and available hardware water within each complete scenario before taking the minimum and maximum. This preserves paired energy and device time rather than combining unrelated layer extrema.

The selected grid, reservoir option, PUE, hardware life and accelerator inventory remain fixed while constructing the span. The existing manufacturing-water inventory and generation-water factor have no added numerical uncertainty bands. Missing generation or hardware inventories remain null and outside the covered subtotal and its span. Model-transfer error, background-data uncertainty and omitted layers are not covered by these endpoints. Thinking-off applies the same existing visible-output conversion once to the central and both endpoints. The separate benchmark-response view retains its documented configuration, cooling and allocation scenarios. Neither span is a statistical confidence interval.

The cooling-factor snapshot is unchanged. Its default 0.30 L/kWh retains the documented source ambiguity between withdrawal and consumption; it has not been recertified as measured net consumption. The IT-electricity denominator and accelerator-specific water selection are preserved. An omitted public component must be labelled as a publication restriction, not absent evidence or an environmental improvement.

E. Training-amortized

Coverage and ranking (2026-09-05): training is excluded by default. A missing training numerator is stored as null, separately from a known central with unquantified uncertainty. With training included, that model has no carbon total and is omitted from the carbon ranking; an organization total containing it is also unavailable. Choosing Exclude training compares operation, IT manufacturing and facility contributions for every model, including models with no training estimate. This changes the comparison's boundary, not the missing value. Water retains its separately stated coverage. The historical training table is not used to fill calculator gaps.

Comparability of new evidence: common units alone do not establish a matched comparison. Record the checkpoint, precision, workload, reasoning/token accounting, runtime, batch, hardware and energy boundary when known; identify unknowns rather than filling them by implication. Benchmark observations may be reused where terms permit. Explicit Estimated transfers may use a named predecessor/family assumption or a documented architecture/work premise. Trace every multiplier, carry energy and GPU-time together, and preserve source scenarios. This permits a useful reference scenario without claiming a validated model-specific prediction. Transfer error remains unquantified until validation data support residuals or bounds; the displayed range must not be described as complete uncertainty. Prices and expected ranks do not set transfer coefficients. A matched or validated claim requires the corresponding evidence. Detailed differences belong in breakdowns and shared source notes.

train_gCO₂e/1k = training_tCO₂e × 1e9 / lifetime_served_tokens[TIER]

Numerator: stored training scenarios, not uniformly disclosed footprints. training_tco2e is read from data/models.yaml; frontend builds do not recompute it. Inputs include published figures, compute-based reconstructions, proxies from related models and rough estimates where evidence is sparse. The compute-based method is op = GPU_h × TDP_W × load × cluster_overhead × PUE × grid_CI / 1e9, plus allocated manufacturing where modeled (basis_kg × GPU_h / (life × 8760), converted from kg to tonnes). Hardware, grid and scope assumptions vary by source.

Claude training assumptions (separate from operational evidence):

Calculator model Stored training central (tCO₂e) Evidence status
Claude Sonnet 4.6 24,000 Epoch Sonnet 4 compute proxy, not a disclosure for Sonnet 4.6; assumed Trainium2 power, load and electricity
Claude Opus 4.8 42,000 Scenario based on an Epoch Opus 4 compute proxy, not a disclosure for Opus 4.8
Claude Haiku 4.5 800 Rough estimate; documented evidence gap

Public third-party compute estimates are not Anthropic-reported carbon footprints. Anthropic's response in the December 2025 Foundation Model Transparency Index declined to disclose training energy, carbon and water. This dated source is not a claim that no disclosure could subsequently appear. The Claude proxies require review when the training dataset is refreshed.

Training-estimate scenarios: data/training_uncertainty.yaml supplies model-specific bounds from the existing training research (report 27, Part 2, reviewed June 2026). These are sensitivity scenarios, not provider measurements or confidence intervals. For eight models, the low/high compute-hour assumptions scale the stored training central with power, grid and other assumptions held fixed. Opus 4.8 uses the report's explicit illustrative 21,000-120,000 tCO₂e range, retaining the stored 42,000 t proxy central. The report's inconsistent 277M-hour central versus 60-200M-hour band is not used for scaling; 120,000 t is a scenario endpoint, not the result of that hours band.

training_low_g/1k  = training_low_tCO₂e × 1e9 / lifetime_tokens_high
training_high_g/1k = training_high_tCO₂e × 1e9 / lifetime_tokens_low

Of the numerical models, eight new measured checkpoints and thirty-six new release proxies have no accepted training numerator. Earlier admitted entries retain their authored training assumptions and individually documented sensitivity bounds. Missing numerators exclude a model only when training is included; missing bounds remain explicit. Operational evidence class does not certify the training estimate. No arbitrary percentage has been assigned to fill the gap. Excluding training removes both its central and range contributions. Changing the assumed lifetime output changes the central allocation, while the range still spans the lifetime band.

A scenario central still contributes to the total and ranking. Even the modeled training bands omit uncertainty in some electricity, hardware, model-version and training-stage assumptions. The range does not capture all training uncertainty.

Denominator - lifetime_served_tokens, TIERED. Total OUTPUT tokens a model serves over production life (proprietary [GAP] → the band is the load-bearing object, not the central). Tiered by model class because the flagship serves the most tokens/day but has the shortest peak life + (in the consumer channel) a minority router share, while the mid/workhorse tier is the largest bucket and an open-weight model's per-model volume is lowest and most dispersed:

Tier low central high
Flagship (frontier default) 5×10¹³ 2×10¹⁴ 7×10¹⁴
Mid / workhorse (mini, flash, sonnet, haiku) 1×10¹⁴ 5×10¹⁴ 1.5×10¹⁵
Open-weight (per model) 2×10¹³ 1×10¹⁴ 5×10¹⁴

Selected by serving_tier_of(m) (open license → open_weight; closed default → flagship; workhorse closed models tagged serving_tier: mid). Provider "tokens processed" headlines are converted to OUTPUT tokens at ~15 % (output-heavy chat vs context-heavy agentic; falling over time as agentic/RAG grow). Cross-checked three independent ways (demand throughput + bottom-up users×usage + supply-side installed-capacity) - all land in the same band. The tool's "Training amortized over" control walks the band (typical / widely-served / narrowly-served) or excludes the training layer entirely.

Worked example - Llama 3.3 70B (open-weight tier, central denominator)

train = 3,400 t × 1e9 / 1e14 = 0.034 gCO₂e/1k = 34 gCO₂e/1M   [bottom-up, Meta Llama 3.x card 7.0M H100-h × 2.03 overhead]

The training-only conversion above is unchanged. Its share of a total depends on the current operational measurement and selected scenario; the generated example below uses the current inputs. Training is excluded by default.


F. Reasoning models and totals

Measured configurations use non-thinking text chat; tokenizers and formatting differ. The benchmark does not measure reasoning-on energy. Other rows can use stated reasoning-inclusive engineering scenarios.

Stored reasoning-inclusive energy is not multiplied again. The answer-only scenario divides by each declared central total-generated/visible ratio; the full scenario range is scaled by that same central divisor. These are engineering assumptions, not exact recoveries of hidden traces. The inconsistent gpt-oss 10-13x source was replaced with a throughput reconstruction using one consistent assumed ratio of 5 (3-10).

A request for a reasoning model requires its own task, token split and serving evidence. Neither a total-token ratio across models nor a documentation example establishes that model's general energy premium. The thinking control does not change the admitted non-thinking measurements.

Reasoning usage pilot, September 6, 2026

Our direct API pilot observed GPT-6 Astra, Claude Fable 5.1, Fable 5 and Opus 5 on 24 short synthetic prompts, three repeats and three effort configurations per model. The 864 main attempts cover chat, small code exercises, elementary math/logic and short extraction/summarization. Inputs were only 27–266 common-reference tokens. These are usage observations; operational electricity and hardware time were not measured.

The accepted usage profiles retain each task and effort separately. The primary profile uses the provider default: response-confirmed medium for Astra, omitted effort documented as high for Claude. Low and upward effort are separate configurations, not uncertainty endpoints. Provider labels do not imply equal compute. Deep research, long contexts, tools and cache use were not tested.

Reported total output O includes reported thinking H. The ratio O/(O-H) describes reported output relative to nonreasoning output; it does not establish hidden/visible tokens or an energy premium. Exact native visible-text counts were unavailable. The future request-energy adapter must keep input, generated work and visible-answer denominators explicit. The current numerical rates still use the previously declared energy proxies, including the borrowed Astra 6 (4–10) and inherited Claude 7 (4–11) scenarios. These are legacy calculation assumptions, not measured defaults for these four models. Their observed usage profiles supersede those borrowed descriptions for the tested conditions; they cannot be substituted into the existing visible-token formula without reconciling its boundary.

Fable 5.1 reported zero thinking on every low-effort main response; this does not mean zero physical internal compute or certainty about future tasks. Fable 5 code and Opus 5 code/summarization ratios condition on completed responses because refusals occurred. All refused attempts remain in the all-attempt input/output accounting; zero reported output does not mean zero impact. Automated answer checks do not establish equal-quality task success. Prompt-cluster bootstrap intervals describe this completed-set sample, not total footprint uncertainty. Independent review reproduced the 12 model/effort aggregate ratios and identified a streaming-smoke counter repair required before any streamed follow-up; all main measurements were non-streamed.

Default total = operational electricity + hardware manufacturing + facility. Training remains excluded by default. If training is included and the exact checkpoint's numerator is unavailable, the carbon total and rank are unavailable. Configuration range endpoints sum the components of each complete configuration before taking extrema, with separately documented training scenarios added when applicable.

Source-native benchmark responses, September 6, 2026

An optional workload view now uses the public source's mean GPU joules per response for the same 119 configurations across 16 measured model groups. It preserves the existing selected configuration (minimum observed energy per output token within its group), which does not necessarily minimize energy per response. Model-generated response lengths differ and answer quality has not been harmonized.

For each configuration, GPU J/response = GPU J/output token × mean native output tokens. Aggregate active accelerator-seconds per response are device count × mean native output / aggregate output throughput. This is an allocation of benchmark serving time, not response latency and not whole-node energy divided by GPU rated power. Source GPU joules are measured in aggregate; the carbon and covered-water results add the existing host, idle, PUE, grid, hardware and facility assumptions. Cooling water uses IT electricity. Device time excludes already allocated spare capacity before the utilization assumption is applied.

The request interface keeps source energy, source boundary, energy-idle coverage and active device time explicit. It rejects unsupported units and boundaries. Missing energy/device time prevents a complete carbon total; missing manufacturing/generation water remains null with a partial-coverage subtotal. Range endpoints come from complete paired configurations and the existing allocation scenarios, not separately minimized components or a statistical confidence interval. Benchmark hardware/thinking stay fixed, training is excluded, and no prefill/decode split or new-context prediction is inferred from one aggregate observation. Source and rights: pinned public summary, publisher data declaration. The September 6 retrieval does not date the underlying runs.

Pilot adoption hold: the API pilot is not connected to either energy calculation. No pilot-driven footprint reduction has been made. Anthropic's accounting documentation distinguishes raw reasoning from displayed summaries; OpenAI's reasoning guide likewise describes undisplayed reasoning in reported output. These are token-accounting contracts, not complete physical-compute measurements. Provider-specific prompting, difficult/long-context tasks and complete tool sessions need their own prospective evaluation; guidance alone supplies no numerical energy multiplier. Original counters, including explicit zeros and unresolved refusal counters, remain observations of the tested workloads. The three streamed smoke records now have a separate offline repair sidecar; the non-streamed main measurements are unchanged.

G. Training scoreboard (separate section - sources)

Location-based tCO₂e, boundaries NOT harmonized. Training stages, infrastructure, power assumptions and manufacturing coverage differ by source. Meta's Llama 3.1 card explicitly mentions PUE adjustment; BLOOM's dynamic-only and manufacturing-inclusive figures have different boundaries. Do not treat these as a like-for-like ranking. Full data + URLs in data/training.yaml.

Model tCO₂e conf Source
Grok 4 154,000 medium Epoch AI 2025 (246M H100-h, Memphis gas)
GPT-4 ~13,000 (1,035–14,994 grid-dep) low Ludvigsen 2023 (leak-based)
Llama 3.1 (8B + 70B + 405B) 11,390 high Meta model card; full family, not 405B alone (8,930)
GPT-3 552 high Patterson et al. 2021
DeepSeek-V3 807–860 medium DeepSeek-V3 report (GPU-h disclosed; CO₂ derived)
BLOOM-176B 24.7 (50.5 incl. embodied) high Luccioni et al. 2023; dynamic-energy estimate vs broader footprint

Training footprints depend on both compute requirements and electricity supply. The BLOOM and Llama examples use different compute quantities, hardware and boundaries, so their ratio cannot isolate the effect of the grid.


H. Assumptions and evidence limits

  • The broad view combines measured configurations and documented engineering estimates. It is not an audited comparison of commercial endpoints or answer quality. Native output tokens are not interchangeable units of useful work.
  • Published summaries omit run dates, raw repeat distributions and checkpoint hashes. Runtime and workload settings are benchmark-declared. Retrieval date is not data freshness.
  • The matched cohort’s energy minimum is conditional on a 50 ms p95 token-gap screen; the three additional measured groups have no latency screen. Estimated central values follow their individual recipes. It does not constrain first-token or whole-request latency.
  • Host/idle factors, grid, PUE, equipment lifetime and lifetime utilization are scenario assumptions. Their full uncertainty is unquantified. Grid values have not been comprehensively revalidated in this operational pass.
  • Workload presets linearly scale the chat rate by output tokens. They do not simulate long-context prefill, caching, changing decode context, agents, tools or additional test-time compute. They are illustrative output-volume scenarios. The agentic and uncached profiles (section A.2) add prefill and cache reads as a separate input term with declared parameters; they leave decode context growth at the declared factor of 1, do not count holding caches and do not cover tool services.
  • Documented cross-model proxies remain Estimated. Hardware, workload, architecture and serving transfer uncertainties are not fully quantified; differing evidence methods limit fine-grained ranking.
  • Training has its own evidence and allocation boundaries. Newly admitted checkpoints with no accepted numerator carry null, not zero. Historical training comparisons remain separate.
  • Water is incomplete as described above. The embodied values are read at build time from data/embodied.json, rebuilt on 2026-09-09 against REEL export pin f13459771c and recorded in data/hardware_basis.yaml; an HTML build does not regenerate the underlying inventory.

I. Selected historical and supporting sources

  • Operational / boundary: Google 2025, arXiv:2508.15734 · Microsoft/Oviedo (Joule 2026) arXiv:2509.20241 · Jegham et al. 2025 arXiv:2505.09598 · ML.energy Leaderboard v3 · Epoch AI (epoch.ai) · Lin 2025 (405B).
  • Embodied: REEL LCI 1.0 (GWP screening export) · ecoinvent 3.12 LCIA (IPCC 2021 GWP100) factors + IPCC AR6 · NVIDIA HGX H100/B200 PCF summaries · Falk et al. 2025 arXiv:2509.00093 (A100 teardown) · REEL's dies-per-wafer calculator.
  • Facility: REEL Modeling the AI Factory (reference hall) · IPCC 2006 GL Vol.3 Ch.7 (refrigerant Tier 2) · IPCC AR6 GWP100 · EIA / DEFRA (diesel) · EPDs (transformers/UPS/batteries) · WRI EWIF + provider WUE (MSFT/AWS/Meta).
  • Grid/PUE: eGRID2023 · Ember · Uptime Institute 2024 · provider sustainability reports.
  • Workloads/units: Green Software Foundation SCI / ISO-IEC 21031 · OpenRouter token study · SWEnergy.
  • Training: Meta model cards · DeepSeek-V3 report (arXiv:2412.19437) · Patterson 2021 (arXiv:2104.10350) · Luccioni 2023 (arXiv:2211.02001) · Touvron 2023 (arXiv:2307.09288) · Epoch AI (Grok) · Ludvigsen 2023.

Per-finding citations with URLs travel with each value in the underlying data files.

September 5 coverage follow-up

The September 5 draft included 78 numerical scenarios: 16 Measured and 62 Estimated, with the 13-model matched cohort still optional. Thirty new releases and six repaired earlier rates use explicit transfers recorded in data/proxy_estimates.yaml; these supersede the earlier six holds and 39-waiting checkpoint. Muse Spark 1.1, Muse Spark 1.3 and Nova 2 Lite remain unestimated because a numerical predecessor or concrete architecture/work premise has not been established. Same-family membership alone does not prove energy equivalence; the assumption is named, and its error remains unquantified.

The GPT-5.5 retained non-thinking baseline is a chosen engineering scenario, not its current API default (medium reasoning). GPT-5.5 Pro uses the same backbone with parallel work, represented by the existing illustrative 7 (4-12) total-work ratio across all branches. MiMo-V2-Flash now uses the documented API-default thinking-off scenario. New training inputs remain null. Cooling water still uses IT electricity, accelerator-specific manufacturing water is preserved, and TPU/Trainium gaps are not inferred from carbon.

October 10 catalogue check

A second release check read first-party OpenAI and Anthropic pages on October 10, 2026. It adds six numerical rows, all Estimated reference transfers from already reviewed baseline rows, never from another transfer: Claude Opus 5.5 (released September 22) from Opus 4.8 with its 7 (4-11) work profile, because thinking is always on; Claude Sonnet 5.5 (September 28) from the Sonnet 4.6 non-thinking scenario and Claude Haiku 5.5 (October 7) from the Haiku 4.5 non-thinking scenario, both chosen direct-answer scenarios that do not represent their adaptive-thinking API defaults; GPT-6 Sol (September 22) and GPT-6.1 Sol (September 29) from the GPT-5.5 non-thinking scenario with the o3 work profile 6 (4-10), because reasoning is on at their medium default; and GPT-6 Luna (September 22) from the gpt-oss-120b class reference, continuing the premise used for GPT-5.6 Luna. The draft now includes 84 numerical scenarios: 16 Measured and 68 Estimated. GPT-Rosalind, generally available to approved life sciences organizations from September 8, is registered without an estimate: OpenAI names no base model, predecessor or architecture for it. Makers' statements that a release needs less compute to serve carry no ratio and are not applied as efficiency gains. GPT-6 Astra availability and the Fable and Mythos 5.1 pair were rechecked with no change to their entries. Every earlier row is unchanged.

Contribution bars are 100% stacked: the numbers carry magnitude and the bars show composition. Water bars describe only the covered subtotal. Large values and range endpoints use comma grouping; this display change does not change calculations.

Operational evidence review

Reviewed September 5, 2026; catalogue rechecked October 10, 2026. The broad default admits 84 models: 16 measured operational inputs and 68 documented estimates. The 13-checkpoint H100 BF16 non-thinking text-chat protocol is an optional comparison filter, not an admission requirement. Three further checkpoints use B200 BF16/FP8 or H100 FP8 without a latency ceiling. Six earlier rates have been repaired through explicit transfers; 4 releases still need a defensible transfer premise. Measured inputs comprise 119 selected factual configurations from the publisher's public summary. Different hardware, tasks, precision and proxy assumptions limit rank comparisons; these are not forecasts of live commercial APIs.

Attribution: ML.ENERGY public summary, benchmark configuration source, data publisher license declaration. No gated raw runs, prompts or responses were accessed. The benchmark declares vLLM 0.11.1; the summaries do not identify individual run dates, checkpoint hashes or runtime revisions. The export date is not a measurement cutoff.

Current benchmark inputs and generated results

US grid 386 gCO2e/kWh; PUE 1.15; five-year hardware life; utilization 0.33; training excluded. Release dates refer to model/checkpoint-family releases, not exact benchmark revisions. Water includes cooling, electricity generation and covered hardware manufacturing. Carbon ranges span complete configurations and the stated environmental scenarios; they are not confidence intervals.

Checkpoint / release source Release GPU Wh/1k output Hardware / precision / GPUs / max sequences / p95 gap ms Carbon g/1k (scenario span) Water subtotal mL/1k
Qwen/Qwen3-14B 2025-04-29 0.032063 H100 / bfloat16 / 1 / 192 / 47.29 0.024490 (0.023786–0.172192) 0.219582
Qwen/Qwen3-235B-A22B-Instruct-2507 2025-07-21 0.505311 H100 / bfloat16 / 8 / 96 / 46.96 0.392332 (0.378546–1.852548) 3.500833
Qwen/Qwen3-30B-A3B-Instruct-2507 2025-07-30 0.037076 H100 / bfloat16 / 2 / 256 / 39.89 0.028801 (0.027783–0.210476) 0.256957
Qwen/Qwen3-32B 2025-04-29 0.076371 H100 / bfloat16 / 2 / 128 / 42.73 0.058829 (0.056942–0.408543) 0.526150
Qwen/Qwen3-8B 2025-04-29 0.022773 H100 / bfloat16 / 1 / 256 / 42.26 0.017361 (0.016875–0.108949) 0.155749
google/gemma-3-12b-it 2025-03-12 0.046143 H100 / bfloat16 / 1 / 128 / 41.09 0.035330 (0.034280–0.172462) 0.316544
google/gemma-3-27b-it 2025-03-12 0.085043 H100 / bfloat16 / 2 / 128 / 40.38 0.065261 (0.063265–0.383262) 0.584329
meta-llama/Llama-3.1-70B-Instruct 2024-07-23 0.179933 H100 / bfloat16 / 4 / 96 / 44.49 0.138808 (0.134277–0.917190) 1.240930
meta-llama/Llama-3.1-8B-Instruct 2024-07-23 0.021289 H100 / bfloat16 / 1 / 256 / 38.75 0.016151 (0.015730–0.109278) 0.145103
meta-llama/Llama-3.3-70B-Instruct 2024-12-06 0.186323 H100 / bfloat16 / 4 / 96 / 39.72 0.143190 (0.138729–0.936809) 1.281540
meta-llama/Llama-4-Scout-17B-16E-Instruct 2025-04-05 0.480303 H100 / bfloat16 / 4 / 32 / 34.76 0.378453 (0.363013–1.449642) 3.362581
nvidia/NVIDIA-Nemotron-Nano-12B-v2 2025-08-29 0.125783 H100 / bfloat16 / 1 / 16 / 12.98 0.097148 (0.093932–0.178941) 0.868196
nvidia/NVIDIA-Nemotron-Nano-9B-v2 2025-08-18 0.070415 H100 / bfloat16 / 1 / 32 / 47.19 0.054185 (0.052469–0.141647) 0.484768
meta-llama/Llama-3.1-405B-Instruct 2024-07-23 0.281956 B200 / bfloat16 / 8 / 4096 / 616.29 0.212815 (0.207423–5.134430) 1.920108
meta-llama/Llama-4-Maverick-17B-128E-Instruct-FP8 2025-04-05 0.134498 H100 / fp8 / 8 / 384 / 69.31 0.105299 (0.101261–0.787668) 0.937325
deepseek-ai/DeepSeek-V3.1 2025-08-21 0.168429 B200 / fp8 / 8 / 3072 / 357.32 0.129463 (0.125195–2.151584) 1.162943

Current worked example: Llama 3.3 70B

GPU energy: 0.67076323 J/output token ÷3.6 = 0.186323119 Wh/1k output. Aggregate GPU power 2223.79743 W ÷4 GPUs gives 555.949357 W/GPU. GPU-time = 4 ÷(3315.32399 tokens/s ×3.6) = 0.00033514405 GPU-hours/1k. GPU count is not multiplied into the already aggregate energy measurement. Node energy is GPU energy ×1.43; IT energy includes ×1.12 idle allowance; facility electricity includes ×1.15 PUE. Cooling uses IT electricity ×0.30 L/kWh; generation water uses facility electricity including PUE and the selected regional reservoir scenario. Hardware allocation uses that paired GPU-time. A hypothetical hardware override uses rated-power allocation and does not predict the checkpoint's speed or energy on another chip.

Review of the 40 previous operational inputs

Prior measured/derived/estimated labels were evidence descriptions, not admission certificates. The following dispositions distinguish acceptable declared assumptions from specific arithmetic or source failures. Throughput-based estimates use assumed power, not metered energy. Low/high scenarios are not confidence intervals.

Previous model Decision Evidence gap / required next evidence Sources
Llama 3.1 8B replace_with_benchmark Replace inherited input with exact-checkpoint H100 BF16 non-thinking chat measurements selected by the shared protocol. source 1
Llama 3.3 70B replace_with_benchmark Replace inherited input with exact-checkpoint H100 BF16 non-thinking chat measurements selected by the shared protocol. source 1
Llama 3.1 405B replace_with_measurement Published B200 bfloat16 conversation configurations, thinking off, without a latency ceiling. Exact conditions shown; not part of the matched H100 BF16 cohort. source 1
Qwen3-32B (non-thinking scenario) replace_with_benchmark Replace inherited input with exact-checkpoint H100 BF16 non-thinking chat measurements selected by the shared protocol. source 1
DeepSeek-V3 retain_estimate The V3-0324 benchmark transfer and assumed production-batching discount are engineering judgments. ML.ENERGY measures GPU energy; the earlier node-labelled reference already involved scenario overhead. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1
DeepSeek-R1 retain_estimate The 2 Wh/1k central and 1-30 span are inherited batched-serving/visible-answer scenarios, not directly metered R1 energy. Hidden-thinking premium 5 (3.5-10) is a task-dependent assumption; the answer-only view divides once. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1
Mistral Large 2 replace_with_proxy Dense 123/70 active-work transfer from complete-request H100 BF16 configurations. Mistral LCA response carbon is not inverted to infer electricity. Open weights remain usable even if the hosted 2407 endpoint retires. Model-transfer error remains unquantified. source 1
Gemini 2.5 Flash retain_estimate Transfer from May 2025 Gemini Apps aggregate, with an assumed 300 visible tokens per prompt. Google did not disclose that denominator or attribute the aggregate to Gemini 2.5 Flash. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1
Gemini 2.5 Pro retain_estimate Family transfer assumes 2.5 times the 0.8 Flash scenario to obtain 2.0; the old 2.2x wording did not reproduce the stored rate. This is modelled, not a Google version-specific measurement. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1
Llama 4 Scout replace_with_benchmark Replace inherited input with exact-checkpoint H100 BF16 non-thinking chat measurements selected by the shared protocol. source 1
Llama 4 Maverick replace_with_measurement Published H100 fp8 conversation configurations, thinking off, without a latency ceiling. Exact conditions shown; not part of the matched H100 BF16 cohort. source 1
Gemma 3 27B replace_with_benchmark Replace inherited input with exact-checkpoint H100 BF16 non-thinking chat measurements selected by the shared protocol.
Phi-4 retain_estimate Proxy from R1-Distill-Qwen-14B: assumed 600 W GPU / approximately 3,700 output tokens/s /3.6 gives 0.045 Wh/1k. Architecture, software and throughput transfer are assumptions. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified.
Mistral NeMo 12B retain_estimate Assumed 600 W GPU /4,500 output tokens/s /3.6 gives 0.037 Wh/1k. The 4,500 rate is an explicit BF16/FP8 blend judgment. NVIDIA compares Minitron-8B with NeMo, not directly Llama-8B; the original 8B proxy chain is only an analogy. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified.
Qwen2.5 72B retain_estimate Llama-3.3-70B proxy with assumed four GPUs at 600 W each and 3,500 aggregate output tokens/s: 2,400 /3,500 /3.6 =0.190 Wh/1k GPU energy. Architecture and workload transfer are assumptions. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1
Qwen3 235B-A22B retain_estimate GPUStack Instruct-2507 BF16 sibling transfer to original Qwen3 hybrid: 8x700 W assumed /4015.36 OUTPUT tokens/s /3.6 × 1.43 host × 3.5 total/visible assumption. The 8424.86 total-token denominator was wrong. Span combines vLLM/SGLang output-throughput endpoints and declared 2.5-5 thinking scenarios; not matched-quality production measurements. source 1 current recipe
gpt-oss-120b retain_estimate GPUStack ShareGPT, vLLM0.10.2 TP2 async on 2 H100: 7648.67 aggregate OUTPUT TPS. Assumed 2 × 700 W /TPS /3.6 × 1.43 host × 5 generated/visible ratio. The declared 3–10 ratio supplies the span at this configuration; no measured separation of hidden/visible tokens or power. Replaces inconsistent10-13x wording and rank calibration. source 1 current recipe
Claude Opus 4.8 retain_estimate Historical Claude-3.7 infrastructure reconstruction transferred to Opus with assumed serving/reasoning and hardware changes; no Opus-4.8 power measurement. The 0.6-6 span is a judgment scenario, not the claimed 3.5 API endpoint alone. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1
Claude Sonnet 4.6 retain_estimate Historical Claude-3.7 predecessor scenario, with assumed serving and hardware efficiency. No Sonnet-4.6 operational measurement. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1
Claude Haiku 4.5 retain_estimate Smaller-model analogy; active parameter count, serving and hardware are assumptions, not Anthropic disclosures. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1
Gemini 3 Flash retain_estimate Historical Google-family transfer of the 0.24 Wh Gemini Apps aggregate with an assumed 300 visible tokens, not a Gemini-3-Flash measurement. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1
GPT-5 retain_estimate Historical GPT-4o infrastructure scenario scaled by assumed model size, batching and hardware efficiency. No GPT-5 power measurement. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1
GPT-5.5 retain_estimate Historical GPT-4o-class scenario adjusted by assumed Blackwell efficiency. No GPT-5.5 power measurement. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1
o3 retain_estimate Jegham reconstructs infrastructure using API timing and inferred hardware/power. The further 4.6-to-0.8 batching adjustment is an engineering judgment, not measured power. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1
o4-mini retain_estimate Jegham reconstructs infrastructure using API timing and inferred hardware/power. The 6.59-to-0.6 adjustment is approximately division by 11, not the common 5.7 previously claimed. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1
DeepSeek V3.1 replace_with_measurement Published B200 fp8 conversation configurations, thinking off, without a latency ceiling. Exact conditions shown; not part of the matched H100 BF16 cohort. source 1
Mistral Large 3 retain_estimate Estimated active-parameter transfer from the repaired Qwen Instruct-2507 node recipe × 41/22. H100 serving energy transferred unchanged to a B200 allocation scenario; no assumed B200 efficiency discount. Span covers only the two reference engine throughputs; architecture/hardware transfer uncertainty remains unquantified. Full-model metadata corrected to 675B total/41B active; the language component is 673B/39B. This proxy explicitly retains the full-model 41/22 active-count analogy. Native allocation uses the transferred H100-serving GPU-time and700W power with the B200 manufacturing proxy; it does not infer a B200 performance improvement. source 1 source 2 current recipe
DeepSeek V4-Pro retain_estimate Native GB200 end-to-end FP4 serving scenario with 24 prefill and 8 decode GPUs: 8933 TOTAL tokens/s/GPU at 8192 input / 1024 generated output; divide throughput by 9. Assume 1200 W/GPU peak from NVIDIA device template, × 1.43 host and × 5 generated/visible ratio (3.5-9 scenarios). This is a peak-power reconstruction, not metered energy. Native GPU-hour allocation also assumes1200 W. Stored B200 manufacturing is an explicit GB200 proxy; exact board/CPU allocation and power/transfer uncertainty are unquantified. Replaces the unsupported500k tokens/s/MW conversion. Published article row is the accepted measurement report; the linked workflow does not match V4-Pro, so its underlying run/export pin remains unresolved. source 1 current recipe
DeepSeek V4-Flash replace_with_proxy Remove the V4-Pro scenario reasoning ratio point-by-point; scale generated work 13/49; apply the retained Flash work profile 4 (2.5-6) once. GB200 1200W peak-power serving assumption with stored B200 manufacturing proxy. Native Flash decode-only graph is not used as whole-request energy. The Pro article-to-run provenance gap remains. Model-transfer error remains unquantified. source 1 source 2
GLM-5 retain_estimate GLM-5 FP8+MTP on H200: published total-token throughput 347.9-851.9 per GPU at 8192 input / 1024 generated tokens is divided by 9 to obtain output TPS. Assumed 700 W/GPU × 1.43 host; central uses geometric-mean throughput and assumed 5 total/visible ratio, endpoints 3.5-7.5. This linearly transfers the benchmark work per generated token to a visible-answer scenario; it does not model a changed input/output mix. source 1 current recipe
Kimi K2 Thinking retain_estimate vLLM Kimi-K2-Thinking on 8 H200: TP8+DCP8 yields695.13 aggregate outputTPS; TP8 yields485.78. Random8k input/4k output cap, actual average output442/389;6/2 failed requests respectively. Assumed 8 × 700 W /TPS /3.6 × 1.43 host × 7 generated/visible ratio. Span combines both serving configurations and declared 5–10 ratio. Request failures, power and token-split uncertainty are unquantified; no R1 rank ceiling. current recipe
MiniMax M2 retain_estimate MiniMax-M2.5 FP8 on 8xH100 transferred to M2: total-token throughput at 8192 / 1024 is divided by 9 to obtain output TPS. Assumed 700 W/GPU × 1.43 host, central concurrency64 (2317 total TPS/GPU) and assumed 3.5 total/visible ratio. Span covers concurrency4-128 and declared 2.5-6 thinking scenarios. Sibling and fixed-workload transfer uncertainty is unquantified. source 1 current recipe
MiMo-V2 Flash replace_with_proxy Complete-request measured DeepSeek-V3.1 B200 FP8 reference scaled by 15/37 active work. Correct the scenario to API-default thinking off. Native MiMo decode-only graph is not used as complete inference. Hybrid attention/MTP efficiencies are unquantified. Model-transfer error remains unquantified. source 1 source 2
Nemotron 3 Super replace_with_proxy Same-provider hybrid full-request reference at branded 12/12 active work; apply retained assumed profile 3 (2-6) once. Super has 120B resident weights, latent MoE and MTP; dense Nano12 transfer does not quantify those effects. Carry H100 reference GPU-time; do not claim a B300 measurement. Model-transfer error remains unquantified. source 1 source 2 source 3
Gemma 4 (31B) retain_estimate Historical H100 throughput reconstruction: assumed700 W /1260 outputTPS /3.6 × 1.43 host =0.221 node Wh/1k; retained 0.30 central adds an explicit engineering judgment. The0.20-0.45 span is a judgment scenario, not measured variability. Expected-rank and peer-cluster cross-checks are not evidence. Default non-thinking; thinking-on is a runtime mode, not a separate checkpoint.
Qwen3-Max retain_estimate Explicit R1-class proxy with assumed architecture and reasoning. No disclosed throughput for this closed service; prior FIRMED wording overstated evidence. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified.
Grok 4.3 retain_estimate Historical MoE/predecessor analogy with assumed hardware and reasoning. Prices do not validate an energy rate, and architecture remains undisclosed. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1
GPT-5.4 mini replace_with_proxy Retain the earlier explicitly named gpt-oss-120b class premise, replacing untraceable B200 TPS with pinned H100 complete-request configurations. Remove each source reasoning ratio once. Actual mini architecture and hardware remain undisclosed. API none default is confirmed; no price or quality scaling. Model-transfer error remains unquantified. source 1 source 2
GPT-5.5 Pro replace_with_proxy Provider confirms the same GPT-5.5 backbone with parallel test-time compute. Apply the retained work profile 7 (4-12) to the existing non-thinking base scenario once. Profile means total generated work across all branches per final visible token; no additional parallel multiplier. Actual branch count/work ratio is unquantified. Source endpoints are inherited engineering judgments, not measured bounds. Model-transfer error remains unquantified. source 1 source 2
Gemini 3.5 Flash retain_estimate Historical Google-family transfer with assumed 300 visible tokens. May 2025 Gemini Apps aggregate does not identify Gemini 3.5 Flash. Existing low/high values are documented historical judgment scenarios, not measured variability or a confidence interval; transfer uncertainty is not quantified. source 1

Explicit model transfers

Thirty new release scenarios and six repaired legacy inputs use the same explicit transfer procedure. Family equivalence keeps a named predecessor's energy rather than inventing an efficiency gain. Architecture transfers scale energy and GPU-hours together by disclosed active-parameter ratios. A class reference needs a stated physical/work premise; price or performance scores are not energy coefficients. All are Estimated, including transfers from measurements. Reference hardware describes the calculation scenario, not verified deployment.

When changing the reasoning profile, remove the source scenario's own total-generated/visible ratio where known, otherwise its declared central ratio; then apply the named target assumption once. Inherited profiles are kept unchanged. For Pro, the work factor includes all parallel branches; no additional parallel multiplier is added. The answer-only control is a counterfactual allocation, not an assertion that a required-thinking API supports that mode. Source spans preserve paired energy and GPU-time. Parameter scaling does not model attention, resident weights, routing, tokenization, precision or speculative decoding. Model-transfer error remains unquantified: even a wide scenario span is not a confidence interval or evidence of a reliable rank. New releases never inherit a training numerator.

Model Reference / work multiplier Scenario and limitations Primary transfer sources
Mistral Large 2 Llama 3.3-70B-Instruct; active_parameters; 1.75714 Dense 123/70 active-work transfer from complete-request H100 BF16 configurations. Text-only non-thinking reference scenario. Mistral LCA response carbon is not inverted to infer electricity. Open weights remain usable even if the hosted 2407 endpoint retires. Model-transfer error remains unquantified. source 1
DeepSeek V4-Flash DeepSeek V4-Pro; active_parameters; 0.265306 Remove the V4-Pro scenario reasoning ratio point-by-point; scale generated work 13/49; apply the retained Flash work profile 4 (2.5-6) once. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. GB200 1200W peak-power serving assumption with stored B200 manufacturing proxy. Native Flash decode-only graph is not used as whole-request energy. The Pro article-to-run provenance gap remains. Model-transfer error remains unquantified. source 1
MiMo-V2 Flash DeepSeek V3.1 (non-thinking scenario); active_parameters; 0.405405 Complete-request measured DeepSeek-V3.1 B200 FP8 reference scaled by 15/37 active work. Correct the scenario to API-default thinking off. Text-only non-thinking reference scenario. Native MiMo decode-only graph is not used as complete inference. Hybrid attention/MTP efficiencies are unquantified. Model-transfer error remains unquantified. source 1
Nemotron 3 Super NVIDIA Nemotron Nano 12B v2 (non-thinking scenario); active_parameters; 1 Same-provider hybrid full-request reference at branded 12/12 active work; apply retained assumed profile 3 (2-6) once. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Super has 120B resident weights, latent MoE and MTP; dense Nano12 transfer does not quantify those effects. Carry H100 reference GPU-time; do not claim a B300 measurement. Model-transfer error remains unquantified. source 1
GPT-5.4 mini gpt-oss-120b; class_reference; 1 Retain the earlier explicitly named gpt-oss-120b class premise, replacing untraceable B200 TPS with pinned H100 complete-request configurations. Remove each source reasoning ratio once. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Actual mini architecture and hardware remain undisclosed. API none default is confirmed; no price or quality scaling. Model-transfer error remains unquantified. source 1
GPT-5.5 Pro GPT-5.5; family_equivalence; 1 Provider confirms the same GPT-5.5 backbone with parallel test-time compute. Apply the retained work profile 7 (4-12) to the existing non-thinking base scenario once. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Profile means total generated work across all branches per final visible token; no additional parallel multiplier. Actual branch count/work ratio is unquantified. Source endpoints are inherited engineering judgments, not measured bounds. Model-transfer error remains unquantified. source 1
GPT-6 Astra GPT-5.5; family_equivalence; 1 Use the existing GPT-5.5 non-thinking energy scenario as an OpenAI frontier-family reference; apply the existing o3 total-generated/visible work profile 6 (4-10) once. No tier, monitoring, speed, price or capability multiplier. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Short-context API usage was observed by task and effort on September 6, 2026; see the shared reasoning notes. The stored visible-token energy rate retains the legacy borrowed work scenario pending a compatible request-energy and token-denominator adapter. Serving efficiency, hardware, batching and energy remain estimated. The pilot's reported-output/nonreasoning ratio is not a hidden/visible ratio or energy measurement. Monitoring overhead and multi-agent work are not separately quantified. source 1
GPT-5.6 Sol GPT-5.5; family_equivalence; 1 Use the existing GPT-5.5 non-thinking energy scenario as an OpenAI frontier-family reference; apply the existing o3 total-generated/visible work profile 6 (4-10) once. No tier, monitoring, speed, price or capability multiplier. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. Astra monitoring overhead is not added; Sol ultra multi-agent work is outside this single-response scenario. Required thinking is represented by an assumed work profile, not a measured default. source 1
GPT-5.6 Terra GPT-5.5; family_equivalence; 1 Use the existing GPT-5.5 non-thinking energy scenario as an OpenAI frontier-family reference; apply the existing o3 total-generated/visible work profile 6 (4-10) once. No tier, monitoring, speed, price or capability multiplier. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. Astra monitoring overhead is not added; Sol ultra multi-agent work is outside this single-response scenario. Required thinking is represented by an assumed work profile, not a measured default. source 1
GPT-5.6 Luna gpt-oss-120b; class_reference; 1 Small-model class reference to the explicitly named OpenAI gpt-oss-120b complete-request reconstruction. Inherit its 5 (3-10) generated/visible profile; no price-based energy scaling. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Luna parameters and real serving hardware are undisclosed. This continues the explicit open-MoE class premise used for GPT mini; neither equal architecture nor deployment is asserted. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. source 1
Claude Fable 5.1 Claude Opus 4.8; family_equivalence; 1 Anthropic frontier-family reference: retain the existing Opus 4.8 per-visible energy and 7 (4-11) work profile without a second thinking multiplier. No assumed generation-to-generation efficiency gain. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Short-context API usage was observed by task and effort on September 6, 2026; see the shared reasoning notes. The stored visible-token energy rate retains the legacy Opus 4.8 work scenario pending a compatible request-energy and token-denominator adapter. Reported zero thinking at low effort applies only to the observed sample. Serving efficiency and hardware remain estimated; Trainium/TPU manufacturing water remains unavailable. Safeguards, fallback routes, agent retries and parallel work are not separately quantified. source 1
Claude Fable 5 Claude Opus 4.8; family_equivalence; 1 Anthropic frontier-family reference: retain the existing Opus 4.8 per-visible energy and 7 (4-11) work profile without a second thinking multiplier. No assumed generation-to-generation efficiency gain. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Short-context API usage was observed by task and effort on September 6, 2026; see the shared reasoning notes. Completed code profiles exclude refused attempts. The stored visible-token energy rate retains the legacy Opus 4.8 work scenario pending a compatible request-energy and token-denominator adapter. Serving efficiency and hardware remain estimated; Trainium/TPU manufacturing water remains unavailable. Safeguards, fallback routes, agent retries and parallel work are not separately quantified. source 1
Claude Opus 5 Claude Opus 4.8; family_equivalence; 1 Anthropic frontier-family reference: retain the existing Opus 4.8 per-visible energy and 7 (4-11) work profile without a second thinking multiplier. No assumed generation-to-generation efficiency gain. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Short-context API usage was observed by task and effort on September 6, 2026; see the shared reasoning notes. Completed code and summarization profiles exclude refused attempts. The stored visible-token energy rate retains the legacy Opus 4.8 work scenario pending a compatible request-energy and token-denominator adapter. Serving efficiency and hardware remain estimated; Trainium/TPU manufacturing water remains unavailable. Safeguards, fallback routes, agent retries and parallel work are not separately quantified. source 1
Claude Sonnet 5 Claude Sonnet 4.6; family_equivalence; 1 Sonnet-family reference equivalence to the retained Sonnet 4.6 non-thinking scenario. No tokenizer or price correction is inferred. Text-only non-thinking reference scenario; thinking-enabled workloads need a separately quantified work profile. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. This chosen direct-answer scenario is not a claim about every API effort setting; Trainium/TPU manufacturing water is unavailable. source 1
Gemini 3.1 Pro Preview Gemini 2.5 Pro; family_equivalence; 1 Pro-family reference to the active Gemini 2.5 Pro full-stack scenario. Retain its 5 (3-9) work profile; do not revive the retired 3 Pro identity or inherit its training. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. Google fleet aggregate evidence is not a measurement of this checkpoint. TPU water remains unavailable. source 1
Gemini 3.6 Flash Gemini 3.5 Flash; family_equivalence; 1 Flash-family reference equivalence to the retained 3.5 Flash full-stack scenario, with its 4 (2.5-7) work profile. No assumed Lite discount or upgrade efficiency gain. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. Google fleet-median energy uses an assumed visible-output denominator; the reference profile is not a measurement of the API effort default. TPU manufacturing water remains unavailable. source 1
Gemini 3.7 Flash Gemini 3.5 Flash; family_equivalence; 1 Flash-family reference equivalence to the retained 3.5 Flash full-stack scenario, with its 4 (2.5-7) work profile. No assumed Lite discount or upgrade efficiency gain. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. Google fleet-median energy uses an assumed visible-output denominator; the reference profile is not a measurement of the API effort default. TPU manufacturing water remains unavailable. source 1
Gemini 3.8 Flash Gemini 3.5 Flash; family_equivalence; 1 Flash-family reference equivalence to the retained 3.5 Flash full-stack scenario, with its 4 (2.5-7) work profile. No assumed Lite discount or upgrade efficiency gain. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. Google fleet-median energy uses an assumed visible-output denominator; the reference profile is not a measurement of the API effort default. TPU manufacturing water remains unavailable. source 1
Gemini 3.5 Flash-Lite Gemini 3.5 Flash; family_equivalence; 1 Flash-family reference equivalence to the retained 3.5 Flash full-stack scenario, with its 4 (2.5-7) work profile. No assumed Lite discount or upgrade efficiency gain. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. Google fleet-median energy uses an assumed visible-output denominator; the reference profile is not a measurement of the API effort default. TPU manufacturing water remains unavailable. source 1
Grok 4.5 Grok 4.3; family_equivalence; 1 Grok-family reference equivalence to the retained 4.3 scenario, including its 6 (4-9) generated/visible profile once. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. Tool execution, concurrent branches and tokenizer differences are unquantified. source 1
Grok 4.6 Grok 4.3; family_equivalence; 1 Grok-family reference equivalence to the retained 4.3 scenario, including its 6 (4-9) generated/visible profile once. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. Tool execution, concurrent branches and tokenizer differences are unquantified. source 1
Muse Glimmer-30B Qwen3-32B (non-thinking scenario); active_parameters; 0.925 Dense reference at 29.6/32 active work, carrying the measured H100 BF16 Qwen3-32B configurations and the existing compact-reasoner work scenario 5 (3-10). Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. 29.6B includes the perception encoder; using the total as text-active work is a disclosed simplifying over-allocation. Image processing and local 4-bit deployment are outside this reference. Active work is scaled linearly; attention, routing, resident-weight memory, batching, tokenization and precision effects are not separately quantified. Source configuration span is not a bound on this transfer error. source 1
Qwen3.8-27B Qwen3-32B (non-thinking scenario); active_parameters; 0.84375 Dense Qwen reference at 27/32 active work, with the existing Qwen work profile 3.5 (2.5-5). Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. The new model has hybrid linear attention; no speed discount is inferred, and its xhigh default has no measured visible-token ratio. Active work is scaled linearly; attention, routing, resident-weight memory, batching, tokenization and precision effects are not separately quantified. Source configuration span is not a bound on this transfer error. source 1
Qwen3.8-Flash-Next Qwen3-30B-A3B-Instruct-2507; active_parameters; 2 Sparse Qwen reference at 6/3 active backbone work, with Qwen profile 3.5 (2.5-5). Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. The card separates 125B backbone, 51B n-gram embeddings and 4B MTP; total shown is their sum. The 6B active figure excludes extra lookup/MTP work; these memory and speculative-compute burdens remain unquantified. Active work is scaled linearly; attention, routing, resident-weight memory, batching, tokenization and precision effects are not separately quantified. Source configuration span is not a bound on this transfer error. source 1
Qwen3.6-35B-A3B Qwen3-30B-A3B-Instruct-2507; active_parameters; 1 Sparse Qwen reference at 3/3 active work, with Qwen profile 3.5 (2.5-5). Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. The 35B model has Gated DeltaNet/attention hybrid layers; no unmeasured hybrid speed advantage is assumed. Active work is scaled linearly; attention, routing, resident-weight memory, batching, tokenization and precision effects are not separately quantified. Source configuration span is not a bound on this transfer error. source 1
GLM-5.3 GLM-5; family_equivalence; 1 GLM frontier-family reference to the repaired GLM-5 whole-request reconstruction, with its 5 (3.5-7.5) work profile once. The 5.3 card establishes the same base as 5.2, not equivalence to GLM-5. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. The 5.2/5.3 architecture transfer and new max-effort behaviour remain unquantified; parameters are left unresolved here. source 1
GLM-5.3-Flash DeepSeek V3.1 (non-thinking scenario); active_parameters; 0.486486 Sparse-MLA class reference at 18/37 active work, using full-request B200 FP8 measurements and the retained GLM profile 5 (3.5-7.5). Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Newly trained sparse/linear hybrid, multimodal and mHC changes are outside the measured reference; default max effort does not determine a numeric work ratio. Active work is scaled linearly; attention, routing, resident-weight memory, batching, tokenization and precision effects are not separately quantified. Source configuration span is not a bound on this transfer error. source 1
Kimi K3 Kimi K2 Thinking; active_parameters; 3.25 Kimi-family active-work transfer 104/32 from the complete-request K2 Thinking reconstruction; inherit its 7 (5-10) work profile once. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. K3 uses hybrid KDA/Gated MLA and MXFP4/MXFP8; no quantization discount or image-compute term is assumed. This H200 reference does not identify K3 deployment. Active work is scaled linearly; attention, routing, resident-weight memory, batching, tokenization and precision effects are not separately quantified. Source configuration span is not a bound on this transfer error. source 1
Kimi K2.5 Kimi K2 Thinking; active_parameters; 1 Kimi-family transfer 32/32 active work from the K2 Thinking complete-request reconstruction; retain its 7 (5-10) work profile. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Vision encoder work and agent swarms are excluded from this text-only reference. Active work is scaled linearly; attention, routing, resident-weight memory, batching, tokenization and precision effects are not separately quantified. Source configuration span is not a bound on this transfer error. source 1
MiniMax M3 MiniMax M2; active_parameters; 2.3 Scale the repaired M2/M2.5 whole-request reconstruction by the maker-disclosed active-parameter ratio 23B / 10B = 2.3. Energy and GPU time scale together; the inherited 3.5 (2.5-6) work scenario is included once. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Engineering transfer, not measured MiniMax M3 energy. Its approximately 428B resident parameters, sparse attention, multi-token prediction, vision encoder, context length, precision and batching are not represented by active-parameter scaling. No sparse-attention speedup discount or actual H100 serving configuration is asserted. Transfer error is unquantified; the displayed span carries source and work scenarios only. Public weights use the MiniMax Community License with commercial conditions, not an unrestricted open-source license. source 1 source 2 source 3 source 4 source 5
Nemotron 3.5 Lightning Qwen3-30B-A3B-Instruct-2507; active_parameters; 1 Sparse 30B/A3B reference with multiplier 3/3 and the existing Nemotron reasoning-work profile 3 (2-6). Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Hybrid execution, MTP, DSpark/DFlash and low-bit deployment improvements are not credited without energy measurements. Active work is scaled linearly; attention, routing, resident-weight memory, batching, tokenization and precision effects are not separately quantified. Source configuration span is not a bound on this transfer error. source 1
Hy4-preview DeepSeek V3.1 (non-thinking scenario); active_parameters; 1.32432 DeepSeek-like sparse-attention reference at 49/37 backbone work and a declared DeepSeek reasoning profile 5 (3.5-10). Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. 770B/49B exclude the optional MTP layer (10B/0.7B); speculative execution is not modelled. The first-party card explicitly cites DeepSeek/GLM architectural influence. Active work is scaled linearly; attention, routing, resident-weight memory, batching, tokenization and precision effects are not separately quantified. Source configuration span is not a bound on this transfer error. source 1
Mistral Medium 3.5 (26.04) Llama 3.3-70B-Instruct; active_parameters; 1.82857 Dense 128/70 active-work reference using complete-request H100 BF16 measurements. No speculative-decoding or FP8 efficiency discount. Text-only direct-answer reference scenario; thinking-enabled requests are not represented. Active work is scaled linearly; attention, routing, resident-weight memory, batching, tokenization and precision effects are not separately quantified. Source configuration span is not a bound on this transfer error. source 1
Mistral Small 4 (26.03) Qwen3-30B-A3B-Instruct-2507; active_parameters; 2.16667 Sparse 6.5/3 active-work reference using full-request H100 BF16 measurements. Text-only non-thinking reference scenario. Reasoning effort is configurable; this selected direct-answer scenario does not cover thinking work. Active work is scaled linearly; attention, routing, resident-weight memory, batching, tokenization and precision effects are not separately quantified. Source configuration span is not a bound on this transfer error. source 1
Command A+ Qwen3-235B-A22B-Instruct-2507; active_parameters; 1.13636 Sparse 25/22 active-work reference and the existing sparse-reasoner profile 3.5 (2.5-5). Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. H100 BF16 reference; the vendor 1 B200/2 H100 W4A4 minimum is memory fit, not energy or this serving configuration. Active work is scaled linearly; attention, routing, resident-weight memory, batching, tokenization and precision effects are not separately quantified. Source configuration span is not a bound on this transfer error. source 1
Soofi S 30B-A3B Base Qwen3-30B-A3B-Instruct-2507; active_parameters; 1.06667 Sparse 3.2/3 active-work reference for text generation. Report uses the nominal 30B/A3B name but discloses 31.6B total /3.2B active. Base-model text continuation reference; not an instruction-following service. This is a base-model continuation scenario, not an instruction/chat quality equivalent. Hybrid Mamba state and cache behaviour are unquantified. Reported 253,000 B200 training hours remain separate from inference and do not become a training carbon numerator. Active work is scaled linearly; attention, routing, resident-weight memory, batching, tokenization and precision effects are not separately quantified. Source configuration span is not a bound on this transfer error. source 1
GPT-6.1 Sol GPT-5.5; family_equivalence; 1 Use the existing GPT-5.5 non-thinking energy scenario as an OpenAI frontier-family reference; apply the existing o3 total-generated/visible work profile 6 (4-10) once, because reasoning is always on with a medium default. No tier, speed, price or capability multiplier. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. The maker's upgrade from GPT-6 Sol and near-Astra scores carry no energy ratio; Ultrafast and multi-agent work are outside this single-response scenario. Required thinking is represented by an assumed work profile, not a measured default. source 1 source 2
GPT-6 Sol GPT-5.5; family_equivalence; 1 Use the existing GPT-5.5 non-thinking energy scenario as an OpenAI frontier-family reference; apply the existing o3 total-generated/visible work profile 6 (4-10) once, because the API default effort is medium with reasoning on. No tier, speed, price or capability multiplier. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. The maker's statements on similar training methods to Astra and lower-cost serving carry no energy ratio. A none-effort request is not represented. Required thinking is represented by an assumed work profile, not a measured default. source 1 source 2
GPT-6 Luna gpt-oss-120b; class_reference; 1 Small-model class reference to the explicitly named OpenAI gpt-oss-120b complete-request reconstruction, continuing the premise used for its predecessor GPT-5.6 Luna and for GPT mini. Inherit its 5 (3-10) generated/visible profile, as the API default effort is medium with reasoning on; no price-based energy scaling. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Luna parameters and real serving hardware are undisclosed. Neither equal architecture nor deployment is asserted. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. A none-effort request is not represented. source 1 source 2
Claude Opus 5.5 Claude Opus 4.8; family_equivalence; 1 Anthropic frontier-family reference: the maker places Opus 5.5 in the Opus line after Opus 5 with thinking always on. Retain the existing Opus 4.8 per-visible energy and 7 (4-11) work profile without a second thinking multiplier. The maker's statement that it needs less compute to serve than Opus 5 gives no ratio, so no efficiency gain is applied. Text-only single-response reference scenario; not an agent session or a provider-default effort measurement. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. Serving efficiency and hardware remain estimated; Trainium/TPU manufacturing water remains unavailable. Safeguards, fallback routes to Opus 4.8, agent retries and parallel work are not separately quantified. source 1 source 2
Claude Sonnet 5.5 Claude Sonnet 4.6; family_equivalence; 1 Sonnet-family reference equivalence to the retained Sonnet 4.6 non-thinking scenario, as for Sonnet 5. No tokenizer, speed or price correction is inferred. Text-only non-thinking reference scenario; thinking-enabled workloads need a separately quantified work profile. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. The API default is adaptive thinking at high effort; this chosen direct-answer scenario, with up-front thinking off, does not represent it or any other effort setting. Fallback routes and Trainium/TPU manufacturing water are not quantified. source 1 source 2
Claude Haiku 5.5 Claude Haiku 4.5; family_equivalence; 1 Haiku-family reference equivalence to the retained Haiku 4.5 non-thinking scenario; the maker names Haiku 4.5 as the predecessor. No tokenizer, speed or price correction is inferred. Text-only non-thinking reference scenario; thinking-enabled workloads need a separately quantified work profile. Version-specific serving efficiency, batch, context, precision and hidden-token ratio are unmeasured. Equal central rates mean assumed reference equivalence, not equal measured performance. The API default is adaptive thinking at medium effort; this chosen direct-answer scenario does not represent it or any other effort setting. The updated tokenizer uses slightly more tokens per task by the maker's account, unquantified here. Trainium/TPU manufacturing water is unavailable. source 1 source 2

Catalogue refresh: 2026-09-05

Release checks are separate from calculation evidence. Earlier operational synthesis: June 26, 2026; visible/hidden-token harmonization: July 9; training synthesis: June 27. Research from September 4 is reconciled below. A second check on October 10, 2026 added the OpenAI and Anthropic releases made available after September 5 and rechecked existing entries; its dated notes appear under corrections.

Dated release register

This complete register retains every checked release, including identities now admitted through explicit Estimated transfers. Missing evidence is not zero impact. Dates marked unresolved are not inferred from model names or page edits. No blanket uncertainty band is assigned.

Model / source Release or availability date Availability and evidence gap
GPT-6.1 Sol; aliases: GPT 6.1 Sol, Sol 6.1 2026-09-29 OpenAI API, ChatGPT Work and Codex for Plus, Pro, Business, Enterprise and Edu users; not yet in ChatGPT Chat at release. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger. Provider disclosure, 2026-09-29: OpenAI describes GPT-6.1 Sol as an upgrade to GPT-6 Sol. The model page lists reasoning effort low, medium (default), high, xhigh and max; none and minimal are not supported. No parameter count, architecture, hardware or energy figure is disclosed.
GPT-6 Sol; aliases: GPT 6 Sol 2026-09-22 OpenAI API, ChatGPT Work and Codex for Plus, Pro, Business, Enterprise and Edu users; the model page points to GPT-6.1 Sol as the newer Sol model (October 10 check). Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger. Provider disclosure, 2026-09-22: OpenAI states GPT-6 Sol and Luna were trained with similar methods as GPT-6 Astra, and that improvements in caching and inference let it serve them at lower cost. No ratio, parameter count, hardware or energy figure is given. The model page lists reasoning effort none, low, medium (default), high, xhigh and max.
GPT-6 Luna; aliases: GPT 6 Luna 2026-09-22 OpenAI API, ChatGPT Work and Codex for paid plans; Free and Go users in the desktop app. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger. Provider disclosure, 2026-09-22: OpenAI presents GPT-6 Luna as the cost-sensitive, high-volume tier of the GPT-6 family and compares it with its predecessor GPT-5.6 Luna. The model page lists reasoning effort none, low, medium (default), high, xhigh and max. No parameter count, architecture, hardware or energy figure is disclosed.
GPT-Rosalind 2026-09-08; General availability to eligible organizations through the trusted-access program; the research preview start was not established in this check Approved users at eligible Enterprise or Business organizations, in ChatGPT Enterprise, Codex and the API for internal research only. Life sciences model under trusted access. OpenAI names no base model, predecessor, parameter count or architecture for it, so no quantitative predecessor or concrete architecture/work premise for a model transfer was established; a generic size or price-based assignment would invent the missing basis.
Claude Haiku 5.5; aliases: Haiku 5.5 2026-10-07 Claude API and Amazon Web Services, Google Cloud and Microsoft Azure. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger. Provider disclosure, 2026-10-07: Anthropic compares Haiku 5.5 with its predecessor Haiku 4.5 and describes it as the first Haiku-class model with an adjustable effort setting. The models overview lists adaptive thinking (not always on) with medium default effort. Anthropic states Haiku 5.5 has an updated tokenizer, similar to Sonnet 5.5's and Opus 5.5's, that uses slightly more tokens per task. No parameter count, hardware or energy figure is disclosed.
Claude Sonnet 5.5; aliases: Sonnet 5.5 2026-09-28 Claude API and Amazon Web Services, Google Cloud and Microsoft Azure. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger. Provider disclosure, 2026-09-28: Anthropic calls Sonnet 5.5 the second model in the Claude 5.5 family and an upgrade over its predecessor Sonnet 5. The models overview lists adaptive thinking (not always on); default effort is high on the Claude Platform and medium in the Claude apps. Integrations that ran Sonnet with thinking off move to a between_tools setting that keeps up-front thinking off. Higher-risk cybersecurity tasks fall back to Sonnet 5. No parameter count, hardware or energy figure is disclosed.
Claude Opus 5.5; aliases: Opus 5.5 2026-09-22 Claude and API, including Amazon Web Services, Google Cloud and Microsoft Azure. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger. Provider disclosure, 2026-09-22: Anthropic calls Opus 5.5 the first model in the Claude 5.5 family and states it requires less compute to serve than Opus 5; no ratio is given. Thinking can no longer be switched off; the models overview lists adaptive thinking always on with medium default effort. Cybersecurity tasks blocked by safeguards are re-routed to Opus 4.8. No parameter count, hardware or energy figure is disclosed.
GPT-6 Astra; aliases: GPT 6 Astra, Astra 2026-09-03 Limited rollout; broader access announced, not confirmed generally available. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger. Provider disclosure, 2026-08-18: OpenAI estimates monitoring overhead at roughly 20% of monitored inference compute, with substantial variation across training/evaluation workloads. This is a compute ratio for the described monitoring setup, not Wh/token or an uncertainty percentage. Reported company statement; secondary lead, 2026-09-03: Fast Company attributes more than 100,000 training GPUs to OpenAI research VP Aidan Clark. Retained as a partial training-scale lead; no provider-hosted GPU-count disclosure was verified in this check. GPU count alone is not GPU-hours or energy.
GPT-5.6 Sol 2026-07-09 General release following June 26 limited preview. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
GPT-5.6 Terra 2026-07-09 General release following limited preview. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
GPT-5.6 Luna 2026-07-09 General release following limited preview. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Claude Fable 5.1; aliases: Fable 5.1, Claude Mythos 5.1 2026-09-01 Fable generally available; Mythos variant restricted to vetted organizations. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Claude Fable 5 2026-06-09 Access interrupted June 12; restored July 1. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Claude Opus 5 2026-07-24 Claude and API. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Claude Sonnet 5 2026-06-30 Claude and API. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Gemini 3.1 Pro Preview 2026-02-19 Preview API endpoint. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Gemini 3.6 Flash 2026-07-21 Generally available API endpoint. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Gemini 3.7 Flash 2026-08-13 Generally available API endpoint. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Gemini 3.8 Flash 2026-09-02 Generally available API endpoint. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Gemini 3.5 Flash-Lite 2026-07-21 Generally available API endpoint. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Grok 4.5 2026-07-16 Released to API and coding products. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Grok 4.6 2026-08-12 Available API model. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Muse Spark 1.3 2026-09-02 Available in Muse Code and Meta Model API including max reasoning (September 5 recheck). Muse Code is an agent product. Contributor pricing is not evidence of separate model training; no supported energy/training allocation. No quantitative predecessor or concrete architecture/work premise for a model transfer was established; a generic size or price-based assignment would invent the missing basis.
Muse Spark 1.1 2026-07-09 Public API preview and Meta AI thinking mode. Closed Muse model; Llama-family training disclosures cannot be transferred. No quantitative predecessor or concrete architecture/work premise for a model transfer was established; a generic size or price-based assignment would invent the missing basis.
Muse Glimmer-30B 2026-08 Open weights; card gives month only. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Qwen3.8-27B Unresolved Open weights; release day unresolved in checked card. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Qwen3.8-Flash-Next Unresolved Open weights; release day unresolved in checked card. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Qwen3.6-35B-A3B Unresolved Open weights; exact initial release day unresolved in opened card. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
GLM-5.3 2026-08-14; Availability in ZCode; first weight-release day not independently established Open weights and ZCode. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
GLM-5.3-Flash 2026-08-26; Availability in ZCode; first weight-release day not independently established Open weights and ZCode. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Kimi K3 Unresolved Open weights and API documented; initial release day unresolved. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Kimi K2.5 Unresolved Open weights; January 29 card change is not initial release date. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
MiniMax M3 2026-06-01 API launch 2026-06-01; public weights verified 2026-09-06 under MiniMax Community License (weight release date not independently established). Admitted as an Estimated 23B/10B active-parameter transfer from the M2/M2.5 reconstruction. Maker discloses approximately 428B total and 23B active parameters; model-specific energy, serving configuration and training remain incomplete. Parameter-count cross-check, 2026-09-06: The maker's approximate 23B active count differs from 26B in this vLLM recipe. This transfer retains the maker's count; the discrepancy is unresolved and is not used as an uncertainty interval.
Nemotron 3.5 Lightning 2026-08-11 BF16 and NVFP4 open checkpoints. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Hy4-preview Unresolved Open preview weights; initial release day unresolved. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Mistral Medium 3.5 (26.04) 2026-04; Version month; exact release day not established Available model; modified MIT weights. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Mistral Small 4 (26.03) 2026-03; Version month; exact release day not established Available model; Apache 2.0 weights. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Command A+ 2026-05-20 Open weights and managed deployment. Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.
Amazon Nova 2 Lite 2025-12-02 Available through Bedrock. Earlier omitted release. Extended reasoning supported; no matched inference rate, training total or manufacturing-water inventory verified. No quantitative predecessor or concrete architecture/work premise for a model transfer was established; a generic size or price-based assignment would invent the missing basis.
Soofi S 30B-A3B Base Unresolved Gated beta card; public report July 10, revised July 22 (not a verified weight-release date). Admitted as an explicit Estimated reference scenario; exact-model inference and training evidence remain incomplete. See the model breakdown and proxy transfer ledger.

Existing-entry corrections

  • gemini3_pro: Retire from active estimates; preserve archive and uncertainty tests. Do not transfer to Gemini 3.1 Pro Preview.
  • qwen3_32b: Label retained non-thinking scenario; downgrade hardware uplift to engineering estimate. Thinking is model-card default but its cost is not established here.
  • qwen3_235b: Original hybrid remains; use International thinking tariff when reasoning is on, non-thinking tariff in answer-only scenario.
  • mistral_large2: Correct disclosure status; retain legacy proxy pending life cycle boundary reconciliation.
  • llama33_70b: Preserve documented reconstruction and disclose model-card inconsistency.
  • deepseek_v3: Historical table includes context extension and post-training. Keep its 837 t separate from calculator 807 t.
  • gpt6_astra: 2026-10-10 recheck, no change to the September entry: the API model catalogue lists gpt-6-astra with unchanged 10 input and 50 output standard rates, and the September 29 changelog makes its Ultrafast mode available to API customers subject to rate limits. No first-party statement of general availability was found; the October 7 page titled GPT-6 for everyone refused this check's request (HTTP 403) and was not read, so the limited-rollout wording stands.
  • claude_fable_51: 2026-10-10 recheck, no change to the September entry: Fable 5.1 remains generally available at 10 input and 50 output with cache reads 0.25, and Mythos 5.1 remains limited to trusted-access programs. The Opus 5.5 announcement states that the expanded Cyber Verification Program will include a tier with access to Claude Mythos models; that widens a trusted-access route, not general availability. Fable 5 list rates are unchanged at 10 and 50.

External reference calculations

These conversions are generated from separate reference inputs. They do not change the historical training table, any calculator training numerator, or any lifetime visible-output denominator. Reporting precision is source-limited, and these are not confidence intervals.

Reference Calculation and boundary
Google API activity 22 billion processed tokens/min → 31.68 trillion/day → 950.4 trillion per assumed 30 days; 37.5% above 16 billion/min. Aggregate mixed input/output/hidden tokens; extrapolation, not measured lifetime output.
Mistral study 20.4 kt → 20,400 tCO2e; 281,000 m3 → 281,000,000 L. Manufacturing and an 18-month usage horizon complicate the training-only boundary. Separate Le Chat 400-token example: 2.85 gCO2e/1k and 112.5 mL/1k. Not an exact-model inference rate.
OLMo 7B paper, card 104 MWh → 104,000 kWh GPU energy. Paper: ×0.610 kg/kWh ×1.1 PUE ÷1000 → 69.784 tCO2e (about 70). Card instead lists 0.656 and 75.05 t. Excludes tuning, debugging and downtime; no silently merged carbon row.
DeepSeek V3 2,664,000 pretraining +119,000 context-extension +5,000 posttraining = 2,788,000 H800-hours, excluding prior research and ablations. Historical 837 t remains distinct from calculator 807 t.
Soofi S Approximately 253,000 B200-hours; no energy/carbon conversion without average load, overhead, PUE and grid. Reported compute is not a complete development footprint.

Price and hardware boundaries

The scatter juxtaposes hosted-service tariffs with conditional footprint estimates; it does not measure those services. Thinking tokens can be billed, so this is not the cost of identical visible work. Qwen International hybrid pricing is $8.40/1M thinking output and $2.80 non-thinking, selected with the reasoning scenario. Selected Anthropic and Google tariffs were rechecked September 5; OpenAI and Anthropic tariffs for the releases added October 10 were read from first-party pages that day; other entries retain their older access dates.

The REEL component values were rebuilt on 2026-09-09 against REEL export pin f13459771c, the snapshot the published database was generated from, and this page reads them from that pinned file (recorded in data/hardware_basis.yaml). TPU/Trainium manufacturing water is still unknown. On-site cooling uses IT electricity; generation water uses facility electricity including PUE and the regional life cycle water estimate. A carbon estimate is not a manufacturing-water inventory.

← Back to The Carbon of Compute leaderboard

Built on REEL LCI. Browse the underlying electronics inventory datasets or read the REEL LCI methodology report.