FLOP Estimation Engine

Gringras, David

Corrected Apr 1, 2026

v1.3.2·2026-05-08

Three back-solves to facility-level compute capacity, run independently. Hardware (GPU count × peak FP16 dense TFLOP/s × interconnect efficiency × MFU) is the narrowest bound; the power path (thermal envelope, PUE-adjusted, mapped back to GPU count and FLOP/s) widens as more parameters intervene; the capex path (capex decomposition through GPU unit price) widens further still. Reconciliation across the three is the credibility signal; the spread, when it exists, names the parameter doing the work.

A facility’s compute capacity has three back-solves: from disclosed GPU count, from disclosed electricity capacity, from disclosed construction cost. Agreement across the three is the credibility signal; divergence, when it appears, comes with the spread and the parameter responsible for it.

Step 1

Estimation Path

GPU count and model known. Narrowest estimation bounds.When the number and type of GPUs in a facility are known. Produces the most precise estimate.

Assumed GPU Model

FP16: 990 TFLOP/s (dense)TDP: 700WCost: $30K ($25K–$40K)

Step 2

Input Parameters

GPU Count

Source: User input

Shared Parameters

Interconnect efficiencyNetwork overhead (performance lost to communication between GPUs)

Source: Epoch AI (Sevilla et al, 2022)|Fraction of peak throughput achievable across multi-node interconnect. 0.85 for NVLink, 0.7 for InfiniBand/Ethernet backend. Ethernet surpassed InfiniBand in AI back-end network market share in 2025 (Dell'Oro Group); UEC 1.0 spec released June 2025. Meta validated Ethernet RoCE at 24K-GPU scale for LLaMA 3.

MFU (Model FLOP Utilization)Training efficiency (fraction of peak speed achieved during AI training)

Source: Calibrated to PaLM 540B Table 3 (MFU 0.462) + LLaMA 3 405B (MFU 0.384) + SemiAnalysis 100K-H100 reference (FP16 MFU 0.40 on trillion-parameter training, 2024-06-17); recalibrated above Epoch 2022 LLM default of 0.30|Fraction of peak FLOPs achieved during training. Epoch AI (Sevilla et al, 2022) recommends 0.30 for LLMs, 0.40 for other networks. PaLM 540B (Chowdhery et al, 2022, Table 3) reports MFU 0.462 — the highest published MFU figure we can verify against a primary source; the related HFU (hardware FLOP utilization, including rematerialization) is 0.578, a distinct metric, not the upper endpoint of an MFU range. LLaMA 3 405B (Meta 2024) achieves 380 TFLOP/s/GPU sustained on 16K H100 = 0.384 MFU. SemiAnalysis (Patel et al, "100,000 H100 Clusters", 2024-06-17) reports FP16 MFU of 0.40 on trillion-parameter training runs across the 100K-H100 reference cluster — the 0.40 default coincides with this figure and is recalibrated above Epoch’s 2022 LLM recommendation to reflect 2023–2025 frontier-lab achievements. Bounds 0.20–0.50 cover poorly-parallelized small-model runs through the published PaLM ceiling with a small headroom margin. We have not located any public training run with a measured MFU exceeding 0.50; if one surfaces, the upper bound widens with citation.

Step 3

Estimation Results

Path A: Hardware-Based

Peak FP16 ThroughputMaximum processing speed9.89e18 FLOP/s

Training ThroughputEffective training speed3.36e18 FLOP/s

Daily FLOP Budget

what is this?what is this?

2.91 × 10²³FLOP/day

Estimation bounds (log scale)0.6 orders of magnitude

1.03 × 10²³2.91 × 10²³4.06 × 10²³

Bounds vary interconnect efficiency and MFU across documented ranges. These are parameter sensitivity ranges derived from input bounds, not distributional estimates.

What these defaults are calibrated against

MFU 0.40 is SemiAnalysis’s reported FP16 figure on trillion-parameter H100 training runs (Patel et al, “100,000 H100 Clusters”, 2024-06-17), corroborated by LLaMA 3 405B at 0.384 and PaLM 540B at 0.462. PUE 1.15 is grounded in operator fleet disclosures (Microsoft FY25 1.16, AWS 2024 1.15, xAI Memphis 1.18, Stargate Abilene 1.12, Google fleet 1.09, Meta FY23 1.08), not in SemiAnalysis, which does not publish a PUE for the 100K H100 reference. GPU share of IT load 0.49 is a Scrutica-editorial midpoint between the in-server share of ~0.55 implied by SemiAnalysis’s 700 W / 1,275 W per-GPU server decomposition and the cluster-level ~0.47 once external networking/storage is added; the cluster-level decomposition itself is Scrutica-derived, not published by SemiAnalysis. Dense FP16 specs throughout (no 2:4 sparsity). Interconnect-efficiency 0.85 reflects NVLink topology (Epoch AI, Sevilla et al, 2022). The calibration substrate is a US hyperscaler-class deployment.

Export-restricted variants ship with reduced NVLink aggregate bandwidth: H800 runs at 400 GB/s vs H100’s 900 GB/s, A800 at 400 GB/s vs A100’s 600 GB/s (NVIDIA / Lenovo product datasheets, corroborated against export-control analyses). The Tensor Core BF16 throughput on the SXM SKUs is architecturally unchanged (NVIDIA never published a public H800 SXM5 datasheet, but the SM count and Tensor Core pathway match H100; the H800 PCIe variant matches H100 PCIe at 1,513 TFLOPS BF16 with sparsity per the Lenovo product guide). The narrowed bandwidth bites at the cluster scale where the defaults were measured: tensor-parallel and pipeline-parallel collectives stall on inter-GPU bandwidth, and achievable MFU drops. For clusters built on these variants, the achievable MFU and interconnect-efficiency parameters live closer to the lower end of the documented range; the calculator does not apply this adjustment automatically because the exact bandwidth penalty is workload-dependent.

The calculator’s default settings are calibrated against measured behavior on a US H100 cluster. Export-restricted variants (H800 in China, A800) carry the same compute throughput but ship with NVLink bandwidth cut from 900 to 400 GB/s on H800 and 600 to 400 GB/s on A800 — the export-control’s structural effect on training throughput. At large cluster scale this lowers achievable utilisation; for facilities operating on those variants, move the MFU and interconnect-efficiency settings toward the lower end of the parameter range rather than accepting the US-calibrated defaults.

EU AI Act · 10²⁵ Cumulative FLOP threshold

This facility could reach the threshold in 34 days of continuous training at current estimated capacity.

At current estimated capacity, this facility could accumulate enough compute to cross the threshold in 34 days of continuous operation.

The 10²⁵ threshold is cumulative training FLOP (a total), not a daily rate. Actual training runs include downtime, checkpointing, and communication overhead.

AI models trained above this threshold (10²⁵ cumulative FLOP) must be reported under the EU AI Act as general-purpose AI systems with potential systemic risk, which triggers requirements for red-teaming, incident reporting, and cybersecurity measures. The days shown assume continuous operation; actual training includes downtime and restarts, so real timelines will be longer.

Full Methodology

Note on FP16 Performance FiguresNote on Performance Measurement

GPU TFLOP/s values use dense (no structured sparsity) FP16/BF16 Tensor Core specs: A100: 312, H100/H200: 989.5, MI300X: 1,307.4, B200: 2,250 TFLOP/s. NVIDIA’s 2:4 structured sparsity doubles these rates (H100 = 1,979; B200 = 4,500) and AMD’s matrix engines likewise publish a sparsity-inclusive 2,614.9 for MI300X. Most production training does not enable structured sparsity, so the dense baseline is the right reference and the MFU parameter is calibrated against it. Same convention as Epoch AI’s ml_hardware dataset.

The Compute Cost Index uses the same dense BF16 throughput (989.5 TFLOP/sper H100), so $/petaFLOP-day values compare directly to MFU-normalized throughput here. A reader deriving $/SCU from cloud $/hour against sparsity-inclusive vendor specs will read values ~2× lower than the index; the discrepancy is the dense-vs-sparsity convention, not pricing divergence between the two surfaces.

GPU vendor TFLOP/s figures differ by measurement convention. This calculator uses dense FP16 (no structured sparsity), the convention Epoch AI publishes against; cloud-provider marketing typically quotes a sparsity-inclusive figure roughly twice as high. The two numbers describe the same hardware. The separate Compute Cost Index uses the same dense FP16 standard, so its $/petaFLOP-day values compare directly to the throughput numbers shown here.

Default-parameters derivation (Hardware path)

10,000 H100 SXM5 GPUs at the documented defaults (interconnect efficiency 0.85, MFU 0.4). The interactive calculator below hydrates on JS and exposes every parameter as an adjustable slider.

Hardware-path FLOP derivation steps at default parameters (10,000 H100 SXM5)
Step	Formula	Result
Peak FP16	gpu_count × per_gpu_fp16_tflops	9.89 × 10¹⁸ FLOP/s
Effective FP16	peak × interconnect_efficiency (0.85)	8.41 × 10¹⁸ FLOP/s
Training Throughput	effective × mfu_assumption (0.4)	3.36 × 10¹⁸ FLOP/s
Daily FLOP Budget	training × 86,400	2.91 × 10²³ FLOP/day

At this daily budget, the EU AI Act 10²⁵ FLOP threshold is reached in approximately 34.4 days. Adjust GPU count, model, interconnect efficiency, and MFU in the interactive calculator below.

Cross-validation · 10 frontier runs

Cross-validation against publicly-disclosed frontier runs

The calculator above runs three independent estimation paths against any facility. The table applies the same paths to 10 publicly-known frontier-class training runs (≥10²⁵ FLOP) for which the lab disclosed hardware count or Epoch derived a central FLOP estimate. Where both exist, both appear in the same row; the column-level disagreement is what the calculator can audit, not a synthesized best-of figure.

Model	Hardware (lab disclosure)	Epoch FLOP	Epoch confidence	Source provenance
Grok 4 xAI · Jul 2025	200,000 GPUs (class undisclosed) via Epoch derivation	5.0e+26 FLOP T2	Speculative

Data Provenance

Primary67%Research33%

Sources

Source	Tier
NVIDIA Spec Sheets	T1
Epoch AI GPU Specs	T2
MLPerf Benchmarks	T1

Processing

Three estimation paths: hardware (GPU count x FP16 spec), power (MW / PUE / GPU TDP), cost (capex / GPU unit price). Outputs are parameter sensitivity ranges, not statistical confidence intervals. Every assumption is adjustable and its source documented inline.

Reading this data

~valueEstimated — derived, modeled, or inferred. Hover for method and source.

valueDerived from another measured field (e.g. power from GPU count).

Source conflict — multiple sources disagree. Click for competing values.

hoverHover any annotated value to see authority tier, method, source, and vintage.

Full methodology

Facility DirectoryInfrastructure

The facilities this estimates

Threshold AtlasGovernance

Apply these estimates against the EU AI Act 10²⁵ trigger and other regulatory regimes

Step 1

Estimation Path

GPU count and model known. Narrowest estimation bounds.When the number and type of GPUs in a facility are known. Produces the most precise estimate.

Assumed GPU Model

FP16: 990 TFLOP/s (dense)TDP: 700WCost: $30K ($25K–$40K)

Step 2

Input Parameters

GPU Count

Source: User input

Shared Parameters

Interconnect efficiencyNetwork overhead (performance lost to communication between GPUs)

MFU (Model FLOP Utilization)Training efficiency (fraction of peak speed achieved during AI training)

Step 3

Estimation Results

Path A: Hardware-Based

Peak FP16 ThroughputMaximum processing speed9.89e18 FLOP/s

Training ThroughputEffective training speed3.36e18 FLOP/s

Daily FLOP Budget

what is this?what is this?

2.91 × 10²³FLOP/day

Estimation bounds (log scale)0.6 orders of magnitude

1.03 × 10²³2.91 × 10²³4.06 × 10²³

Bounds vary interconnect efficiency and MFU across documented ranges. These are parameter sensitivity ranges derived from input bounds, not distributional estimates.

What these defaults are calibrated against

EU AI Act · 10²⁵ Cumulative FLOP threshold

This facility could reach the threshold in 34 days of continuous training at current estimated capacity.

At current estimated capacity, this facility could accumulate enough compute to cross the threshold in 34 days of continuous operation.

The 10²⁵ threshold is cumulative training FLOP (a total), not a daily rate. Actual training runs include downtime, checkpointing, and communication overhead.

Full Methodology

Note on FP16 Performance FiguresNote on Performance Measurement

Comparison · Epoch AI — AI Models documentation (Estimation)

FLOP Estimation Engine · Scrutica vs Epoch AI methodology

Epoch's training-FLOP formula is hardware-path single-shot (chip-time × peak FLOP/s × utilization rate). Scrutica runs three back-solves independently — hardware, power-thermal envelope, and capex — then surfaces the spread between them as the credibility signal, with every parameter adjustable inline. The comparison shows where Scrutica adds path multiplicity and per-architecture calibration that Epoch's published methodology does not surface.

Dimension	Scrutica	Epoch AI	What Scrutica adds
Estimation paths	Three independent back-solves run in parallel: hardware (GPU count × peak TFLOP/s × interconnect × MFU × hours), power-thermal (facility MW / PUE / GPU TDP), capex (facility USD × GPU-fraction / per-GPU price). Reconciliation across the three is the credibility signal; the spread names the parameter doing the work.

Bound-tightness ranking

Cross-path bound-tightness ranking

368 facilities with both inputs

For each facility with disclosed chip count AND disclosed nameplate power, the hardware-path and power-path FLOP estimators run independently. The ranking surfaces the two ends of the agreement distribution: tight rows (credibility signal; independent inputs reconcile under the methodology defaults) and loose rows (substrate-gap suspect; GPU model unknown but power disclosed, or vice versa). Cost path is excluded at the facility level; the methodology panel below explains why.

Tight (≤1.5×) 169Loose (>3×) 22

Facility	Country	Divergence	Inputs
Sakura's B200s Phase 2	JP	1.00× 0% normalized	10,000 GPUs 16 MW
xAI Fulton Georgia	US	1.02× 2% normalized	12,448 GPUs 20 MW
SK Group AWS Uslan Phase 2	KR	1.04× 4% normalized	60,000 GPUs 103 MW
Ubilink.AI Supercomputer	TW	1.06× 6% normalized	1,024 GPUs 2 MW
Lawrence Livermore NL RZAdams	US	1.06× 6% normalized	512 GPUs 1 MW
Nebius Kansas City Phase 2	US	1.07× 7% normalized	26,000 GPUs 40 MW
xAI Colossus Memphis Phase 3	US	1.07× 7% normalized	230,000 GPUs 352 MW
TensorWave MI300X Cluster 1 Phase 1	US	1.07× 7% normalized	1,000 GPUs 2 MW
Oracle OCI MI300x	US	1.07× 7% normalized	16,384 GPUs 25 MW
Vultr Chicago Cluster	US	1.07× 7% normalized	3,000 GPUs 5 MW

What this ranking means

Tight bounds (ratio ≤ 1.5×): the two independent inputs reconcile under the methodology defaults. Strong credibility signal on the FLOP estimate; not a guarantee of absolute correctness.
Loose bounds (ratio > 3×): substrate gaps suspected. Common causes include GPU model unknown but power disclosed (the H100 SXM5 default does not match deployed hardware), nameplate power capacity oversized for actual draw, or a partial GPU count (a phase-1 figure against a full-build power capacity). Loose rows are the investigation queue.
Tightness is a CREDIBILITY signal, not an absolute-correctness signal. A facility where both inputs are wrong in the same direction (e.g., both nameplate-only, both phase-1) will reconcile tightly without being right.
Cost path is NOT included at the facility level: Scrutica's substrate has no per-facility total-investment figure (organization- level capex is annualized + multi-facility-pooled). The /flop-engine FlopCalculator UI runs all three paths against user-supplied inputs interactively; this ranking is hardware-vs-power only.

Hardware-path defaults to h100_sxm5 for any facility whose specific GPU model is not disclosed at the row level (the substrate carries gpu_count without per-row hardware_type for most facilities). Both paths use the same H100 baseline, so a divergence here reflects (gpu_count, power_capacity_mw) reconciliation, not hardware-mix uncertainty.