Revisiting algorithmic progress

That assumption is still there because your interpretation is both not true and not justified by this analysis. As I've noted several times before, time-travel comparisons like this are useful for forecasting, but are not causal models of research: they cannot tell you the consequence of halting compute growth, because compute causes algorithmic progress. Algorithmic progress does not drop out of the sky by the tick-tock of a clock, it is the fruits of spending a lot of compute on a lot of experiments and trial-and-error and serendipity.

Unless you believe that it is possible to create that algorithmic progress in a void of pure abstract thought with no dirty trial-and-error of the sort which actually creates breakthroughs like Resnets or GPTs, then any breakdown like this relying on 'compute used in a single run' or 'compute used in the benchmark instance' simply represents a lower bound on the total compute spent to achieve that progress.

Once compute stagnates, so too will 'algorithmic' progress, because 'algorithmic' is just 'compute' in a trenchcoat. Only once the compute shows up, then the overflowing abundance of ideas will be able to be validated and show which one was a good algorithm after all; otherwise, it's just Schmidhubering into a void and a Trivia Pursuit game like 'oh, did you know resnets and Densenets were first invented in 1989 and they had shortcut connections well before that? too bad they couldn't make any use of it then, what a pity'.

even a pause which completely stops all new training runs beyond current size indefinitely would only ~double timelines at best, and probably less

I'd emphasize that we currently don't have a very clear sense of how algorithmic improvement happens, and it is likely mediated to some extent by large experiments, so I think is more likely to slow timelines more than this implies.

I think this question is interesting but difficult to answer based on the data we have, because the dataset is so poor when it comes to unusual examples that would really allow us to answer this question with confidence. Our model assumes that they are substitutes, but that's not based on anything we infer from the data.

Our model is certainly not exactly correct, in the sense that there should be some complementarity between compute and algorithms, but the complementarity probably only becomes noticeable for extreme ratios between the two contributions. One way to think about this is that we can approximate a CES production function

$$Y(C,A)=(\alpha C^{\rho }+(1-\alpha )A^{\rho }{)}^{1/\rho }$$

in training compute $C$ and algorithmic efficiency $A$ when $C/A\approx 1$ by writing it as

$$Y(C,A)=AY(e^{\log \left(C/A\right)},1)=A(\alpha e^{\rho \log \left(C/A\right)}+(1-\alpha ){)}^{1/\rho }\approx A(1+\alpha \rho \log \left(C/A\right){)}^{1/\rho }\approx C^{\alpha }{A}^{1-\alpha }$$

which means the first-order behavior of the function around $C/A\approx 1$ doesn't depend on $\rho$, which is the parameter that controls complementarity versus substitutability. Since people empirically seem to train models in the regime where $C/A$ is close to $1$ this makes it difficult to identify $\rho$ from the data we have, and approximating by a Cobb-Douglas (which is what we do) does about as well as anything else. For this reason, I would caution against using our model to predict the performance of models that have an unusual combination of dataset size, training compute, and algorithmic efficiency.

In general, a more diverse dataset containing models trained with unusual values of compute and data for the year that they were trained in would help our analysis substantially. There are some problems with doing this experiment ourselves: for instance, techniques used to train larger models often perform worse than older methods if we try to scale them down. So there isn't much drive to make algorithms run really well with small compute and data budgets, and that's going to bias us towards thinking we're more bottlenecked by compute and data than we actually are.

I would guess that making progress on AGI would be slower. Here are two reasons I think are particularly important:

1. ImageNet accuracy is a metric that can in many ways be gamed; so you can make progress on ImageNet that is not transferable to more general image classification tasks. As an example of this, in this paper the authors conduct experiments which confirm that adversarially robust training on ImageNet degrades ImageNet test or validation accuracy, but robustly trained models generalize better to classification tasks on more diverse datasets when fine-tuned on them.

   This indicates that a lot of the progress on ImageNet is actually "overlearning": it doesn't generalize in a useful way to tasks we actually care about in the real world. There's good reason to believe that part of overlearning would show up as algorithmic progress in our framework, as people can adapt their models better to ImageNet even without extra compute or data.

2. Researchers have stronger feedback loops on ImageNet: they can try something directly on the benchmark they care about, see the results and immediately update on their findings. This allows them to iterate much faster and iteration is a crucial component of progress in any engineering problem. In contrast, our iteration loops towards AGI operate at considerably lower frequencies. This point is also made by Ajeya Cotra in her biological anchors report, and it's why she chooses to cut the software progress speed estimates from Hernandez and Brown (2020) in half when computing her AGI timelines.

   Such an adjustment seems warranted here, but I think the way Cotra does it is not very principled and certainly doesn't do justice to the importance of the question of software progress.

Overall I agree with your point that training AGI is a different kind of task. I would be more optimistic about progress in a very broad domain such as computer vision or natural language processing translating to progress towards AGI, but I suspect the conversion will still be significantly less favorable than any explicit performance metric would suggest. I would not recommend using point estimates of software progress on the order of a doubling of compute efficiency per year for forecasting timelines.

You would do it in log space (or geometrically). For your example, the answer would be ${23}^{0.65}\approx 7.67$.