GPT-4 sits above the EU's systemic-risk line on a number OpenAI never disclosed

The number the law now draws on

Training compute is the total number of floating-point operations, the additions and multiplications on decimal numbers, that a computer runs to train a model from scratch. Bigger runs need more operations, so the field uses the figure to rank models by scale. Since 2024 it is also where two governments draw the frontier. The European Union's AI Act presumes that a general-purpose model has high-impact capabilities, and so poses systemic risk, once the compute used to train it passes 10²⁵ floating-point operations.¹ The United States set a reporting trigger an order of magnitude higher, at 10²⁶ operations, in Executive Order 14110.²

The odd thing about these lines is that the number they rest on is almost never measured. Consider GPT-4, which sits just above the EU threshold. Its training compute is usually given as about 2.1 × 10²⁵ operations, a figure the research group Epoch AI reconstructed from the hardware GPT-4 was believed to run on and how long it trained. OpenAI has never published the number.³ The quantity that would place GPT-4 on the wrong side of Europe's systemic-risk line is an outside estimate, not a disclosure.

Training compute measures the size of a training run and nothing else. It is not the model's capability, not the dollars a lab spent, not the energy a finished model burns answering a single query, and not how fast it answers. Each of those is a separate number this course measures on its own: the price of a token, the energy a query costs, the tokens per second it produces. Training compute answers one question: how large the run was.

Rebuilding a run's compute after the fact

Because the true operation count is rarely reported, it has to be rebuilt, and there are two standard ways to do it. The first works from the hardware. Multiply the number of chips by each chip's peak speed in operations per second, by the wall-clock time the run took, by the fraction of that peak the run actually reached.⁴ That last fraction has a name: model FLOPs utilization, or MFU, the ratio of the work a run really did to the theoretical maximum if every chip ran flat out the whole time.⁵

The second method skips the hardware and works from the model's own dimensions. For a standard dense transformer, training costs about six floating-point operations for every parameter, for every token it trains on. Multiply the parameters by the tokens by six and you have the compute. The rule comes from the 2020 scaling-laws work of Kaplan and colleagues.⁶ The Chinchilla team relied on the same approximation and checked it against an exact operation count, finding the difference very small.⁷

The six is not arbitrary. A forward pass through the network costs about two operations per parameter per token, one multiply and one add. Training also runs a backward pass to work out how to adjust each parameter, and that pass costs about twice the forward one. Two for the forward pass, times three for forward-plus-backward, gives six.⁶

Meta's Llama 3.1 405B makes the rule concrete. It is a dense model with 405 billion parameters, trained on 15.6 trillion tokens. Six times 405 billion times 15.6 trillion is about 3.8 × 10²⁵ operations, and 3.8 × 10²⁵ is exactly the figure Meta reported.⁸ When both methods can be run on the same model they rarely disagree by more than a factor of 1.7.⁴ For a disclosed, dense model, the estimate is a good one.

The loose joints

Both methods hide a soft spot, and the soft spots are physical. Start with utilization. A chip's peak speed is a ceiling it reaches only when every arithmetic unit stays fed with data. In a real run spread across thousands of chips, they spend time waiting on memory and on messages to one another, so throughput lands well below peak. Google's PaLM reached 46.2% MFU, and that was high for the field, managed only after heavy engineering.⁵ Llama 3.1 405B logged between 38% and 43%.⁸ When a lab discloses nothing, an estimator has to pick a fraction. Epoch defaults to 30% for large language models.⁴ For older models with no details at all, earlier work assumed 10% and guessed the chip from the year of publication.⁹

That single fraction moves the whole answer. Get the utilization wrong by a factor of two and the compute estimate is wrong by a factor of two, before any other error enters. For Llama, where the parameters and tokens are known, the guess only nudges a number the 6ND rule already pins down. For GPT-4, where nothing is disclosed, the utilization is a guess sitting on top of a guessed chip count and a guessed training time, and the wide error bars never appear next to the tidy 2.1 × 10²⁵.

The 6ND rule has its own blind spot. It assumes every parameter does work on every token, which is true for a dense model like Llama but false for a mixture-of-experts model, the now-common design that routes each token to a few specialist sub-networks and leaves the rest idle. Counting all the parameters when only a fraction fire overstates the compute, so the rule has to be run on the active parameters instead. And both methods count only the final training run. The failed runs, the abandoned experiments, and the later rounds of tuning on human feedback that turn a raw model into a usable one are all left out.⁹

So the number is almost never measured. GPT-4 exists in public only as an estimate, and even Llama's disclosed figure is Meta's own 6ND-and-hardware accounting, not a reading from an instrument. Disclosure is the exception, and a disclosed figure is still an estimate. It is just the lab's own.

From run size to risk class

Everything so far reads the number forward, from a run to its size. Meta discloses 3.8 × 10²⁵ to say how big Llama's run was; Epoch's database catalogs runs by scale. Read that way, the number does honest work.

Regulation reads it the other way, from the size back to a judgment about the model. The EU AI Act treats crossing 10²⁵ operations as a reason to presume high-impact capabilities and systemic risk.¹ Executive Order 14110 set its 10²⁶ reporting trigger the same way. It added a far lower line of 10²³ operations for models trained mainly on biological sequence data, and a separate line of 10²⁰ operations per second for the computing clusters themselves.² That order was revoked on 20 January 2025 by Executive Order 14148, so the US trigger is no longer in force, though the EU line remains and the reasoning behind both is the same.¹⁰

The law is not naive about this. The EU threshold is a rebuttable presumption, a starting assumption a developer can argue against rather than a fixed verdict.¹ The Act's own text calls training compute only one of several approximations for a model's capabilities, to be revised as hardware and methods improve.

Whether the line is a good one is genuinely contested. Heim and Koessler argue that training compute is the best early-warning metric available: it can be known before a model ships, it correlates with capability and risk, and an outside auditor can verify it. They still grant that it is "an imperfect proxy for risk" and belongs only as a first filter inside a broader regime.¹¹ Sara Hooker argues the other side. The link between compute and risk is uncertain and moving. Better algorithms and data let a smaller, cheaper model match a larger one, so a fixed FLOP line will wave through some dangerous systems and stop some harmless ones.¹²

The two frontier cases show the strain. The model the public most wants classified, GPT-4, is on the wrong side of the EU line only by Epoch's estimate. The one that disclosed, Llama 3.1 405B, gave a figure that is still its own accounting. As of June 2025 Epoch counted 33 announced models above the EU line, most of them estimates rather than disclosures.³ The frontier is being drawn with a ruler whose markings are, for the most part, inferred.