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).
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).