In January 2025, the outgoing US administration published a rule sorting almost every country on Earth into three tiers for the purpose of buying advanced AI chips. India, a nuclear power with a fifty-billion-dollar IT services industry and its own space program, landed in Tier 2 — trusted enough to buy Nvidia H100s, but not trusted enough to buy them without a government-to-government agreement or a cap on how many could sit in a single data center. The rule was scrapped by the incoming administration four months later, before it ever took effect, but the episode was not really about that one rule. It revealed something students of AI often miss entirely: the thing being regulated was never the software. It was the arithmetic hardware underneath it — measured, licensed, and rationed the way enriched uranium is. Around the same time, India's own government was running a parallel exercise domestically. The IndiaAI Mission, approved by the Cabinet in March 2024 with an outlay above ten thousand crore rupees, does not buy GPUs and hand them to whoever wants one. It empanels private data-center operators, negotiates a subsidized per-hour compute rate, and allocates access to approved startups, researchers, and academic labs through a government-mediated queue. Two governments, two very different politics, converged on the same mechanism: control the compute, and you control what gets built on top of it. That mechanism — and the technical vocabulary needed to reason about it precisely — is this chapter.
Why compute, and not data or algorithms, is the governable layer
A regulator who wants to constrain frontier AI development has three candidate levers: the training data, the algorithm, and the compute. Data is nearly impossible to govern at the point of use — it is copied at zero marginal cost, sourced from millions of scattered origins, and un-auditable once absorbed into model weights. Algorithms are worse: a transformer architecture is published math, a training recipe is a few hundred lines of code, and both propagate through papers, blog posts, and open-source repositories faster than any agency can track. Compute is different in kind. Training a frontier model today consumes tens of thousands of GPUs running for months, drawing megawatts from a handful of hyperscale data centers, built from chips fabricated at a handful of leading-edge foundries (overwhelmingly TSMC, using EUV lithography machines that only one company — ASML — can supply). Every link in that chain is a physical, countable, licensable bottleneck. You cannot smuggle a training run the way you can copy a dataset. This is the structural insight behind every compute-governance regime built since 2022: regulate the chips, the data centers, and the cumulative arithmetic actually spent, because that is the one part of the stack that cannot hide.
This gives compute governance two distinct sub-problems, which the rest of this chapter treats in turn. The hardware layer asks: who is allowed to acquire and operate the chips in the first place (export controls, domestic allocation schemes like IndiaAI's empanelment)? The training-run layer asks: once you have the chips, how much cumulative arithmetic have you actually spent building a given model, and does that quantity cross a line that triggers disclosure or safety obligations? Answering the second question requires a precise, non-negotiable unit of measurement, which is where the mathematics begins.
Measuring compute: a stock, not a rate
A floating-point operation (FLOP) is one multiply or one add on real numbers. Confusion enters immediately because two related quantities get named almost identically: FLOP/s (FLOPs per second) is a rate — how fast a chip or cluster computes, the number quoted on an Nvidia spec sheet (an H100 delivers roughly 1,000 TFLOP/s in dense FP16). Total training FLOPs is a stock — the cumulative arithmetic spent across an entire training run, obtained by integrating that rate over the whole duration. A cluster of 10,000 H100s running for 90 days at, say, 40% achieved utilization performs roughly 10,000 × 1×10^15 × 0.4 × (90×86,400) seconds ≈ 3×10^25 FLOPs total — a single number describing the entire training run, independent of how the compute was scheduled across chips or time. Every compute-governance threshold in force today — the EU AI Act's systemic-risk trigger, the now-revoked US executive order's reporting trigger — is written against this cumulative stock, not the rate. That distinction is subtle enough that it is worth flagging as a standing trap before going further; the misconception section below returns to it directly.
For a transformer, there is a well-established shortcut for estimating that stock without simulating the whole training run: for a model with N trainable parameters trained on D tokens, total training compute is approximately
C ≈ 6 · N · D (FLOPs)The factor of 6 comes from counting multiply-adds through one full training step. A forward pass through a dense transformer costs about 2ND FLOPs (each of the N parameters is touched by one multiply and one add per token, summed over D tokens). The backward pass, which computes gradients with respect to both the activations and the weights, costs roughly twice the forward pass, or 4ND FLOPs. Summing forward and backward gives 2ND + 4ND = 6ND. This approximation was popularized by Kaplan et al., "Scaling Laws for Neural Language Models" (OpenAI, 2020), and refined two years later by Hoffmann et al., "Training Compute-Optimal Large Language Models" (DeepMind, 2022) — the paper that introduced the Chinchilla model and showed that most contemporary labs were training far too few tokens relative to their parameter count. Hoffmann et al. found that for a fixed compute budget, loss is minimized when parameters and training tokens are scaled together at roughly D ≈ 20N — twenty training tokens for every parameter. That ratio becomes the second tool in the worked example below.
Worked example: does a real training run cross a real threshold?
GPT-3 175B (Brown et al., "Language Models are Few-Shot Learners," OpenAI, 2020) was trained with N = 175 billion parameters on D = 300 billion tokens. Applying the 6ND rule:
def training_compute(N, D):
return 6 * N * D
N = 175e9 # parameters
D = 300e9 # training tokens
C = training_compute(N, D)
print(f"{C:.3e}") # 3.150e+23
print(f"{1e25 / C:.1f}x below EU threshold") # 31.7x below EU threshold
print(f"{1e26 / C:.1f}x below US threshold") # 317.5x below US thresholdTracing it by hand: 6 × 175×10⁹ × 300×10⁹ = 6 × 5.25×10²² = 3.15×10²³ FLOPs — consistent with independently published estimates of GPT-3's training compute. Two real regulatory lines exist to compare this against. The EU AI Act (Regulation (EU) 2024/1689, Article 51) presumes a general-purpose AI model carries "systemic risk" once its cumulative training compute exceeds 10²⁵ FLOPs, triggering mandatory model evaluation, incident reporting, and cybersecurity obligations. The US Executive Order 14110 (October 2023) required developers to report to the federal government, under the Defense Production Act, any training run exceeding 10²⁶ FLOPs (or 10²³ FLOPs for a model trained primarily on biological sequence data) — before that order was revoked by Executive Order 14179 in January 2025. Dividing, GPT-3's training run sat roughly 32× below the EU line and 317× below the old US line: nowhere close to either. That is expected — GPT-3 predates both rules by three years, and the thresholds were calibrated against the frontier of 2023–24, not 2020.
The more interesting question is the reverse one: how large would a model have to be, trained compute-optimally, to actually cross the EU's 10²⁵ line? Substitute the Chinchilla ratio D = 20N into C = 6ND:
C = 6N(20N) = 120N²
N = √(C / 120)For C = 10²⁵: N = √(10²⁵/120) = √(8.33×10²²) ≈ 2.89×10¹¹ ≈ 289 billion parameters, with D = 20N ≈ 5.77×10¹² ≈ 5.8 trillion training tokens. Verifying: 6 × 2.89×10¹¹ × 5.77×10¹² ≈ 1.00×10²⁵ — the algebra closes exactly. So a compute-optimal model only about 1.65× larger than GPT-3 in parameter count, but trained on nearly nineteen times more tokens, is enough to cross the EU's systemic-risk line. This is roughly the scale independent analysts have estimated (without official confirmation from any lab) for the current frontier — which is precisely why the threshold was set there: it is meant to bracket the handful of labs actually training at the frontier, not the thousands of teams fine-tuning smaller open models.
A real mechanism, drawn
The misconception this chapter needs to kill
The near-universal error, once a student sees a phrase like "10²⁵ FLOPs," is to picture it as a speed limit on the deployed chatbot — as if a model answering questions faster, or serving more users, were somehow getting closer to a legal red line. It is not. The 10²⁵ and 10²⁶ thresholds in the EU AI Act and the old US executive order measure the one-time, cumulative arithmetic spent creating the model's weights during training — a fixed quantity, finished the moment training ends, that never changes no matter how the model is served afterward. Inference throughput (tokens generated per second, or FLOP/s at serving time) is an operational, business-driven number that has nothing to do with it: a lab could serve a frontier model to a billion users at enormous aggregate FLOP/s, or throttle it to a handful of researchers, without moving the training-compute figure by a single FLOP either way. The reason regulators anchored on the training stock rather than the serving rate is exactly the point made earlier about scaling laws — what the model learned, and therefore what it is capable of, is set once during training. Deployment scale reflects a market decision, not a capability change, and a threshold written against it would let a lab dodge every obligation simply by metering its API.
From threshold to obligation: Responsible Scaling Policies
Crossing a compute threshold is a legal trigger, but it does not by itself tell a lab whether the resulting model is actually dangerous — FLOPs are a proxy for capability, not a direct measurement of it. The technical safety layer that sits on top of compute governance is the capability evaluation: run the model against a battery of tests specifically designed to surface dangerous capabilities before public release, and gate deployment on the results. Anthropic's Responsible Scaling Policy formalizes this as a ladder of AI Safety Levels (ASL), consciously modeled on the biosafety level (BSL) system used for handling pathogens. ASL-2 describes current-generation models: capable but not assessed as providing meaningful uplift toward catastrophic misuse. ASL-3 is triggered by specific evaluation results — for instance, a model that measurably increases a novice's ability to design or produce biological or chemical weapons beyond what is already achievable using existing tools and search — and requires hardened deployment (stricter usage monitoring, more resistant safeguards against jailbreaks) and hardened security (measures to prevent weight theft), before that model can ship at all. The link back to compute governance is direct: the EU Act's Article 51 threshold and a lab's own ASL evaluations are two independent gates guarding the same event, and a model can trip either one first — a smaller, unusually specialized model might clear a capability eval concern well before it reaches 10²⁵ FLOPs, while a much larger general-purpose model might cross the FLOP line with no elevated capability at all.
Evaluation is not the only technical safety tool that depends on compute — interpretability research does too, in the opposite direction: instead of gating a model based on scale, it tries to open the model up and read out what it actually represents internally. Anthropic's interpretability team demonstrated in "Towards Monosemanticity" (Bricken et al., 2023) and its follow-up "Scaling Monosemanticity" (Templeton et al., 2024) that training a sparse autoencoder on a model's internal activations can decompose an otherwise tangled neuron into millions of individually interpretable features — one found in Claude 3 Sonnet fired specifically on descriptions of the Golden Gate Bridge, across languages and modalities. That autoencoder is itself a second neural network, trained on activation data harvested from billions of forward passes through the original model, which means safety research of this kind consumes non-trivial compute in its own right — a reason some governance proposals, including provisions once floated for EO 14110, carve out separate reporting exemptions or dedicated compute allocations for safety and alignment research clusters, distinct from frontier capability training runs.
Back to the hardware layer: export controls and the India case
The training-run thresholds above only bind at all if a lab can assemble enough chips to approach them, which routes the story back to the hardware chokepoint. The US Bureau of Industry and Security first restricted export of advanced AI accelerators (Nvidia's A100 and H100 among them) to China in October 2022, using two technical metrics — total processing performance and performance density — to define which chips counted as controlled, then tightened those metrics in October 2023 after Nvidia introduced cut-down variants (the A800, H800) specifically to sit just below the original line. The January 2025 "AI diffusion" framework generalized this from a single-country ban into the three-tier system described at the start of this chapter, sorting nearly every country by trust level rather than targeting one adversary — which is precisely why India's Tier 2 placement drew objection from Indian policymakers before the rule was rescinded four months later. IndiaAI Mission's empanelment model, running in parallel, is a domestic mirror of the same instinct applied inward: rather than every Indian startup independently negotiating cloud contracts abroad, the government pre-qualifies data-center operators, negotiates a bulk subsidized rate, and allocates hours to approved applicants — access to compute as a state-mediated resource, the same conceptual move export controls make at the international border, just applied within one country's own market.
Active recall
Attempt each question before reading its answer.
Q1. A startup trains a 70-billion-parameter model on 1.4 trillion tokens (Chinchilla's own compute-optimal configuration). Compute the total training FLOPs and state how far it sits from the EU's 10²⁵ threshold.
Q2. The same startup later doubles its token budget to 2.8 trillion tokens, keeping the same 70B parameters, and continues training the same model. Does the total cumulative training compute double? Where does the run now sit relative to the EU threshold, and does the fact that this was a continuation of an earlier run change whether it counts toward that threshold?
Q3. A lab wants to train, compute-optimally (D = 20N), a model that lands exactly on the old US EO threshold of 10²⁶ FLOPs rather than the EU's 10²⁵. Solve for N and D, and state how the required parameter count compares to the 289-billion-parameter figure derived earlier for the EU line.
Q4. Explain, in one or two sentences, why the EU AI Act's Article 51 threshold is written against cumulative training compute rather than a model's inference throughput (FLOP/s at serving time).
Q5. Classify each of the following as acting at the hardware-acquisition layer, the training-run layer, or the deployment layer of compute governance: (a) a BIS export-license denial for an H100 sale; (b) the EU Article 51 systemic-risk reporting obligation; (c) an RSP capability evaluation gating a model's release; (d) IndiaAI Mission's empanelment of approved GPU cloud providers.
Q6. A classmate argues: "A chatbot that answers 500 tokens per second is clearly high-risk under the EU compute rule, since that's a huge amount of FLOPs." What is wrong with this claim?
Worked answers
A1. C = 6ND = 6 × 70×10⁹ × 1.4×10¹² = 5.88×10²³ FLOPs. Dividing, 10²⁵ / 5.88×10²³ ≈ 17.0 — the run sits about 17× below the EU threshold, comfortably clear of Article 51 obligations.
A2. Total compute does not simply double in the naive sense of "run the same training twice" — but since C = 6ND is linear in D at fixed N, doubling the token count from 1.4T to 2.8T does exactly double the total FLOPs: C = 6 × 70×10⁹ × 2.8×10¹² = 1.176×10²⁴ FLOPs, still about 8.5× below the EU threshold (10²⁵/1.176×10²⁴ ≈ 8.5). Critically, because Article 51 is written against cumulative training compute for a given model, continued training counts toward the same running total rather than resetting — a lab cannot dodge the threshold by training in several shorter stages and treating each as a fresh, independently-measured run.
A3. Solve N = √(C/120) with C = 10²⁶: N = √(10²⁶/120) = √(8.33×10²³) ≈ 9.13×10¹¹ ≈ 913 billion parameters, with D = 20N ≈ 1.83×10¹³ ≈ 18.3 trillion tokens. Since C scales as N² at fixed D/N ratio, moving the target compute up by exactly one order of magnitude (10²⁵ → 10²⁶) moves the required parameter count up by √10 ≈ 3.16×: 913 billion is indeed about 3.16 times the 289 billion derived for the EU line, and the same 3.16× ripples through to the token count as well, since D is pinned to 20N.
A4. Training compute reflects what the model actually learned — a fixed quantity set once, at the moment training ends, that determines the model's capabilities. Inference throughput reflects only how many queries a business chooses to serve and at what speed, which says nothing about capability and could be throttled at will, so anchoring the legal threshold to it would let a lab evade every obligation by simply slowing down its API rather than by building a genuinely less capable model.
A5. (a) hardware-acquisition layer — it decides who may physically obtain the chips before any training happens. (d) also hardware-acquisition layer, applied domestically rather than at a national border. (b) training-run layer — it is triggered only once cumulative FLOPs from an actual training run cross the line. (c) deployment layer — it gates whether a finished, already-trained model is allowed to ship, independent of its exact FLOP count.
A6. Tokens-per-second at inference time is a rate (FLOP/s), not the cumulative training stock (total FLOPs) the EU threshold is written against. A model's serving speed depends entirely on deployment choices — how many GPUs the lab allocates to serving it, how aggressively responses are batched — and can be changed after release without retraining anything; it carries no information about how much compute was spent creating the model's weights in the first place, so it cannot be substituted for the quantity Article 51 actually measures.
Think About It
Think about this: How would you explain compute governance and ai safety to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.
Key Takeaways — Summary and Recap
Let us recap what we covered: the core ideas behind compute governance and ai safety, how they connect to real-world applications, and why they matter for your journey in computer science. Remember these key points as you move forward. For competitive exam preparation (CBSE, JEE, BITSAT), focus on understanding the WHY behind each concept, not just the WHAT.