Thanks for writing this, Katja, and Peter for sharing.
Agree with a lot of the specific points, though I found the title/thesis somewhat incongruent with the content.
The various instances (?) of “slowing down AI” that you talk about seem pretty different in nature to me, and not all seem like they really are about slowing down AI in the sense that I/my colleagues might construe it.
Reducing compute investment, gating compute access in some way, getting people to switch from capabilities work to safety work, increasing restraint on deployment, coordinating on best practices, raising the alarm, etc. seem to be pretty diverse things. And many are happening already. Some could reasonably count as “slowing down” to me, while others don’t (I’d maybe define slowing down AI as something like “reducing the rate of improvement in peak and/or average AI capabilities in the world, regardless of whether or how they are deployed or not”).
I agree that there is relatively little work on slowing AI in the above sense and that there are some misconceptions about it, but many of the arguments you make address misconceptions about the feasibility and value of AI policy generally, not slowing down specifically.
I think restraining deployment would reduce the rate of improvement in peak AI capability in the world, via reduced funding. Do you think otherwise? How does that work?
Is it 1. restraining deployment won’t reduce funding, or 2. restraining deployment would reduce funding, but reduced funding won’t reduce the rate of improvement, or 3. restraining deployment would reduce funding, and reduced funding would reduce the rate of improvement, but still the whole argument doesn’t work for reason X?
- Compute cost reduction is important for driving AI capabilities forward (among other things), and historically is mostly driven by things other than deployment of the most powerful systems (general semiconductor progress/learning curves, spillover from videogame related investments, deployment of systems other than the most powerful ones, e.g. machine translation, speech recognition, etc.). This may be changing as the share of NVIDIA’s datacenter revenue increases and more companies deploy powerful LMs but for a long time this was the case.
- Other drivers of AI progress such as investment in new algorithms via hiring people at top labs, algorithmic progress enabled by more compute, and increasing the amount of money spent on compute are only somewhat tied to deployment of the most powerful models. Again this may change over time but see e.g. all of DeepMind’s value provided to Google via non-cutting-edge (or fairly domain specific) things like speech synthesis, as well as claims that it is a long-term investment rather than something which requires immediate revenue. Again these things may change over time but they have been true for some time and still have at least some truth.
- Restraint is not all or nothing, e.g. given deployment of some system, it can be deployed more or less safely, there can be more or less alignment across companies on best practices, etc. And on the current margin, doing better w.r.t. safety is mostly bottlenecked by good ideas and people to execute on those ideas, rather than adjusting the “safety vs. speed” knob (though that’s relevant to an extent, too). Given that situation, I think there is a lot of marginal additional restraint to be done without preventing deployment or otherwise significantly compromising lab interests (again, this could change eventually but right now I see plenty of opportunity to do “restraint-y” things that don’t entail stopping all deployment).
Thanks for writing this, Katja, and Peter for sharing.
Agree with a lot of the specific points, though I found the title/thesis somewhat incongruent with the content.
The various instances (?) of “slowing down AI” that you talk about seem pretty different in nature to me, and not all seem like they really are about slowing down AI in the sense that I/my colleagues might construe it.
Reducing compute investment, gating compute access in some way, getting people to switch from capabilities work to safety work, increasing restraint on deployment, coordinating on best practices, raising the alarm, etc. seem to be pretty diverse things. And many are happening already. Some could reasonably count as “slowing down” to me, while others don’t (I’d maybe define slowing down AI as something like “reducing the rate of improvement in peak and/or average AI capabilities in the world, regardless of whether or how they are deployed or not”).
I agree that there is relatively little work on slowing AI in the above sense and that there are some misconceptions about it, but many of the arguments you make address misconceptions about the feasibility and value of AI policy generally, not slowing down specifically.
I think restraining deployment would reduce the rate of improvement in peak AI capability in the world, via reduced funding. Do you think otherwise? How does that work?
Is it 1. restraining deployment won’t reduce funding, or 2. restraining deployment would reduce funding, but reduced funding won’t reduce the rate of improvement, or 3. restraining deployment would reduce funding, and reduced funding would reduce the rate of improvement, but still the whole argument doesn’t work for reason X?
A few aspects of my model:
- Compute cost reduction is important for driving AI capabilities forward (among other things), and historically is mostly driven by things other than deployment of the most powerful systems (general semiconductor progress/learning curves, spillover from videogame related investments, deployment of systems other than the most powerful ones, e.g. machine translation, speech recognition, etc.). This may be changing as the share of NVIDIA’s datacenter revenue increases and more companies deploy powerful LMs but for a long time this was the case.
- Other drivers of AI progress such as investment in new algorithms via hiring people at top labs, algorithmic progress enabled by more compute, and increasing the amount of money spent on compute are only somewhat tied to deployment of the most powerful models. Again this may change over time but see e.g. all of DeepMind’s value provided to Google via non-cutting-edge (or fairly domain specific) things like speech synthesis, as well as claims that it is a long-term investment rather than something which requires immediate revenue. Again these things may change over time but they have been true for some time and still have at least some truth.
- Restraint is not all or nothing, e.g. given deployment of some system, it can be deployed more or less safely, there can be more or less alignment across companies on best practices, etc. And on the current margin, doing better w.r.t. safety is mostly bottlenecked by good ideas and people to execute on those ideas, rather than adjusting the “safety vs. speed” knob (though that’s relevant to an extent, too). Given that situation, I think there is a lot of marginal additional restraint to be done without preventing deployment or otherwise significantly compromising lab interests (again, this could change eventually but right now I see plenty of opportunity to do “restraint-y” things that don’t entail stopping all deployment).