{"slug": "how-slower-does-takeoff-go-with-10x-less-compute", "title": "How slower does takeoff go with 10× less compute?", "summary": "A new model estimates that a 10x reduction in R&D compute for an AGI company would slow AI progress by about 6x in the median case, with an 80% confidence interval of 3.5x to 8x. The model accounts for cuts to training, experimentation, and agent compute, and assumes software efficiency improvements are applied only to future FLOPs, not retroactively.", "body_md": "*About 6x slower in the median case, with an 80% confidence interval of 3.5x to 8x. *\n\nDefine the \"R&D compute\" (in, say, H100-equivalents) of an AGI company at a given time to be the total compute in use across the following categories:\n\nWith less R&D compute, the company would need to make cuts across these categories. For now, we'll assume they maintain the same allocation across the three areas, that is, we'll assume they achieve the reduction in the total via a reduction to each category.\n\nThe capability level of your best AI model is represented by its *effective training compute*, . is a stock, with units of \"2025-FLOP\". evolves according to\n\nwhere is training system performance (a flow, units: FLOP/yr) and is software efficiency (units: 2025-FLOP per FLOP). We will call this quantity *effective training system performance*.\n\nTraining system performance and software efficiency tend to grow exponentially over time, so the \"rate of AI progress\" will be operationalized as the relative growth rate of (i.e. the time derivative of , which equals ). We will use the symbol for this.\n\nHuh? Why this model?\n\nOther models of AI takeoff (the AI Futures Model, Tom Davidson's FTM, Epoch AI's GATE) compose effective compute multiplicatively from two stocks:\n\nwhere is cumulative training compute (a stock, units: FLOP, satisfying ). In other words, they apply today's software efficiency to every FLOP ever spent on training, \"pulling outside the integral\". Our formulation instead applies to the flow: , so . An algorithmic improvement raises the value of each FLOP spent from now on, but never retroactively upgrades FLOP spent under older algorithms.\n\nA large, sudden compute reduction is precisely where the formulations come apart. Physically, the cut is a cut to flows: the rates at which FLOP are spent on experiments, agents, and training all drop by 10x. The multiplicative model has no training flow among its state variables, only the stock $C$, so the cut has to be translated into a statement about $C$. There are two natural translations, and neither is good:\n\nThe remaining simplification is treating AI progress as a single continuous training run that has been underway since the beginning of time. (Mathematically, the integral defining $E$ runs from minus infinity to the present.) In reality, frontier training runs sometimes start from scratch, have different lengths, and may only be underway during parts of the year. We think this still captures the dynamics relevant to compute reductions, but it directionally favors the compute-reduced project: some capabilities may require architectural changes or otherwise require starting from scratch, i.e. re-accumulating $E$ from zero, which is far more costly at a reduced flow, and this model assumes you never need to do this. In other words, if anything, a real 10x cut probably buys somewhat more slowdown than the model estimates.\n\nSoftware improves via the semi-endogenous growth law\n\nThat is, the relative growth rate of software efficiency is research effort divided by a difficulty term that rises with the software level already achieved. parameterizes how much harder further improvements get as climbs (the \"fishing out\" of ideas). (Human and AI labor also enter research effort, but experiment compute carries almost all of the weight in the relevant regime, and the labor cut matters less and less as automation saturates.)\n\nWe are going to compare two quantities:\n\nWhen we cut R&D compute by in this model, since assumed proportional reductions across all categories, the immediate effect is a reduction in , and therefore also a reduction in the rate of AI progress .\n\nWhat happens after that? To figure this out, we can look at how changes over time. Differentiating,\n\nThis term equals the relative growth rate of , , or the growth rate of effective training system performance . We will call the growth rate of effective training system performance . The equation above then becomes\n\n(This has the form of the \"logistic differential equation\", with carrying capacity .) Qualitatively, it says that when effective training system performance grows faster than capabilities (), then the growth rate of capabilities increases (). Conversely, when capabilities are growing faster than ETSP is, then capabilities growth will slow.\n\nHence, after falls by , the subtraction on the right hand side is positive, meaning that is increasing. That is, *the rate of capabilities progress will initially fall by , then pop back up again, until effective compute is growing at the same rate as software efficiency*. It will continue to increase so long as exceeds , gradually approaching the fixed point where and .\n\nIf training system performance (the raw hardware) remains constant after the reduction, then is just the growth rate of software efficiency, determined by experiment compute and AI labor, which today proceeds at perhaps 1 OOM per year. With less compute for experiments, and less compute to run automated researchers, the growth rate falls, but probably by less than . Say it falls by some factor with .\n\nNow we have to determine how the rest of takeoff goes. Both trajectories have to traverse the same interval of capability, from the level at the cut to whatever level counts as the end of takeoff, and the time this takes is\n\nIn steady state , so if the slowed trajectory's is lower at every capability level (with the same N throughout), the integrand is larger everywhere and the total time is longer. So we want to show that the ratio of the two trajectories' software growth rates at matched capability is constant, and to find it.\n\nDividing the default trajectory's software law of motion by that of the reduced-compute trajectory yields\n\nwhere we are making the approximation that research effort exhibits constant elasticity to experiment compute over the relevant range. [1] Intuitively, the factor is the direct slowdown at that capability level, and the second factor adjusts for the increased \"fishing out\" effect associated with the greater software content of the trajectory with reduced compute.\n\nNow we determine his determines how much more software the reduced-compute trajectory holds. At the fixed point , we have . Taking logs,\n\nWe can write this identity once for each trajectory at the same , and subtract:\n\nRearranging yields\n\nHence the software ratio (at steady state) is indeed independent of capability level. By substituting, finally we can solve for :\n\nThis makes sense in the extreme cases:\n\nAfter modifying the [AI Futures Model](https://www.aifuturesmodel.com/) to use the continuous training run ODE described above, I simulated the effect of compute reductions while sampling from our [parameter distributions](https://docs.google.com/document/d/1ru6Okbxb6XuH18Cz8439sdQJazMV39hNxsWDokh97r0/edit?tab=t.0#heading=h.6d8mrcidguap). The various approximations involved in the derivation held relatively well:\n\nThe slowdown factor does not depend greatly on the specific capability level at which the reduction occurs. Here, with the relevant parameters held fixed at our median estimates, you can see that N ranges from 5.2 to around 6:\n\nThere is significant uncertainty in our estimates of N, mostly driven by [our uncertainty about the current rate of software progress](https://docs.google.com/document/d/1ru6Okbxb6XuH18Cz8439sdQJazMV39hNxsWDokh97r0/edit?tab=t.0#bookmark=kix.jfh5oqvflv41). The main other important parameter determining N in the AI Futures Model is the [current-day software progress elasticity to experiment compute](https://docs.google.com/document/d/1ru6Okbxb6XuH18Cz8439sdQJazMV39hNxsWDokh97r0/edit?tab=t.0#bookmark=id.z11wqimj4fl4), which we estimated by polling AI researchers.\n\nIn the [AI Futures Model](https://www.aifuturesmodel.com/) this is approximately true, since during takeoff, research effort is highly bottlenecked on experiment compute.", "url": "https://wpnews.pro/news/how-slower-does-takeoff-go-with-10x-less-compute", "canonical_source": "https://www.lesswrong.com/posts/7jcPg79p3kD5ir3CL/how-slower-does-takeoff-go-with-10-less-compute", "published_at": "2026-07-08 10:04:06+00:00", "updated_at": "2026-07-08 10:11:38.086335+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-research", "ai-infrastructure"], "entities": ["AGI company", "H100", "Epoch AI", "Tom Davidson"], "alternates": {"html": "https://wpnews.pro/news/how-slower-does-takeoff-go-with-10x-less-compute", "markdown": "https://wpnews.pro/news/how-slower-does-takeoff-go-with-10x-less-compute.md", "text": "https://wpnews.pro/news/how-slower-does-takeoff-go-with-10x-less-compute.txt", "jsonld": "https://wpnews.pro/news/how-slower-does-takeoff-go-with-10x-less-compute.jsonld"}}