Table of Contents
Jeff Dean co-founded Google Brain and now serves as a research director at Google DeepMind, continuing to push the frontier of AI research. In a recent public talk, he took a closer look at a claim that sounds like marketing copy but has genuine technical substance: AI computing power has increased by a million-fold over the past decade. What does that actually mean for the future?
TL;DR
The million-fold compute growth in AI comes from three parallel technical tracks: specialized hardware (GPU to TPU), distributed training frameworks at the software layer, and efficiency improvements in model architectures themselves. The compounding effect of these three tracks means training a large language model today operates at an entirely different efficiency level than ten years ago. The next question isn’t whether growth will continue, but which direction it should go.
Where the Million-Fold Came From
Moore’s Law alone — transistor counts doubling every two years — contributed roughly 100x of improvement over this period. The million-fold figure comes largely from elsewhere:
Hardware specialization
General-purpose CPUs are inefficient at matrix multiplication. GPU’s massively parallel cores provided a 10–100x speedup for deep learning training. But GPUs are still general-purpose accelerators designed for graphics. Google’s TPUs, designed from 2016 onward, made more aggressive optimizations specifically for neural network matrix operations, with substantially better energy efficiency than GPUs.
Distributed training systems
Training a modern large language model may use thousands to tens of thousands of accelerators simultaneously. This requires solving hard engineering problems: how to partition the model (pipeline parallelism, tensor parallelism), how to synchronize gradients (AllReduce communication), how to prevent a single node failure from crashing the entire training run. Google’s Pathways system and the Jax/XLA compiler stack are outputs of this work.
Architecture efficiency
The Transformer architecture itself is more parallelizable than previous RNN/LSTM approaches. Techniques like Flash Attention optimize memory access patterns for the attention mechanism, enabling longer sequence training at the same compute budget. Mixed-precision training (FP16/BF16) fits more parameters into the same memory.
graph LR
A[Moore's Law] -->|~100x| D[Total Compute Gain]
B[Specialized Hardware GPU/TPU] -->|100s to 1000s x| D
C[Software and Architecture Innovation] -->|100s x| D
D --> E[Million-fold Total Effect]
What This Scale of Compute Enables
Dean’s talk isn’t about “compute is impressive” — it’s about specific scientific problems that were previously intractable and are now becoming solvable:
Protein structure prediction: AlphaFold2 is the clearest example. But Dean emphasizes the problems that come after — protein dynamics (the folding pathway, not just the end state), protein-small molecule interactions, protein design. These require even greater compute than AlphaFold itself.
Climate modeling: Earth’s climate is a complex system of coupled physical PDEs. Traditional supercomputer climate models are resolution-limited by compute budgets. AI models like Google’s GraphCast can run higher-resolution predictions in shorter time and now surpass traditional numerical methods on many accuracy metrics.
Medicine and genomics: Predicting disease risk from genomic sequences, predicting treatment outcomes from EHR data — these require training large models on massive datasets, where compute scale directly determines achievable accuracy.
The Next Phase: Smarter Allocation, Not Just Bigger
Dean points to a key shift: from “train one huge model, use fixed compute at inference” to “dynamically allocate inference compute based on problem difficulty.”
Mixture of Experts (MoE) architecture is one direction: the model has many expert sub-networks, with only a small subset activated per token. Total parameter count is large but actual compute remains manageable. This lets you scale the model’s knowledge capacity without proportionally scaling compute costs.
Another direction is “thinking time” at inference: letting models spend more reasoning steps on hard problems (chain-of-thought, MCTS search) rather than outputting in one pass. OpenAI’s o1/o3 and Google’s Gemini Thinking are exploring this space.
What This Means for Engineers
If you’re building AI applications, Dean’s talk carries an implicit message worth noting: the democratization of compute lags far behind frontier research. The compute scale big companies use today won’t reach typical developers for another three to five years. This means applications you build now will have dramatically lower compute costs in a few years — making things that seem “too expensive to run” today become viable.
On the other side, compute scarcity makes “achieving better results with less compute” a persistently valuable research direction. Quantization, distillation, and fine-tuning small models on specific tasks will remain engineering-valuable for the foreseeable future.
Summary
AI’s million-fold compute growth isn’t a marketing exaggeration — it’s the real compounding result of three tracks: hardware, software, and architecture. Jeff Dean’s perspective is worth particular attention because he has been a direct contributor to Google’s TPU design, TensorFlow/Jax, and large-scale scientific AI projects like AlphaFold. His predictions describe things he helped build.
References
Answers come from this article only. Click any prompt below or open the chat at the bottom right.
🇺🇸 English
Jeff Dean helped found Google Brain, and today he's a research director at Google DeepMind. In a recent talk, he took on a claim that sounds like pure marketing but turns out to have real technical teeth: AI computing power has grown a million-fold over the past decade. Not doubled. Not a hundred times. A million. So the question becomes — where did all that come from, and where does it go next?
Let's start with what's surprising. You might assume this is just Moore's Law doing its thing — transistors doubling every couple of years. But Moore's Law only accounts for maybe a hundred-fold of improvement across this whole period. That leaves a factor of ten thousand coming from somewhere else. And that "somewhere else" is really three stories running in parallel.
The first is hardware specialization. Here's the core problem: a general-purpose CPU is genuinely bad at matrix multiplication, which is the thing deep learning does constantly. GPUs, with their massively parallel cores, gave you a ten-to-a-hundred-fold speedup right away. But GPUs were originally built for graphics — they're general-purpose accelerators wearing a different hat. So starting around 2016, Google designed TPUs, chips built specifically for the matrix math that neural networks live on. More aggressive optimization, and a lot better energy efficiency than GPUs for that particular job.
The second story is distributed training systems. When you train a modern large language model, you're not using one chip or ten — you might be coordinating thousands, even tens of thousands of accelerators at the same time. And that's a brutal engineering problem. How do you split the model across all those chips — do you slice it by layers, or slice the math inside each layer? How do you keep everyone's gradients in sync when they all need to share updates? And critically, how do you make sure that when one node fails — and at that scale, something is always failing — the entire multi-week training run doesn't just die? Google's answer here is systems like Pathways and the Jax and XLA compiler stack.
The third story is architecture efficiency — the models themselves getting smarter about how they use compute. The Transformer, for instance, is far more parallelizable than the older recurrent networks it replaced, so it maps onto all that hardware much better. Then there are tricks like Flash Attention, which reorganizes how the attention mechanism reads and writes memory, so you can train on much longer sequences without spending more compute. And mixed-precision training — using smaller number formats like sixteen-bit floats — lets you pack more parameters into the same memory.
Now here's the key insight: these three tracks multiply together. Roughly a hundred-fold from Moore's Law, hundreds-to-thousands-fold from specialized hardware, another few hundred from software and architecture. Stack those on top of each other and you land in million-fold territory. That's the compounding. Training a large model today happens at a completely different efficiency level than it did ten years ago — not because of any single breakthrough, but because three curves bent upward at once.
But Dean's talk isn't really a victory lap about big numbers. What he's actually excited about is what this scale of compute unlocks — scientific problems that were flatly impossible before and are now becoming tractable.
The clearest example is protein structure prediction. AlphaFold2 cracked the shape of proteins, and that was huge. But Dean points past it to the harder problems waiting on the other side: protein dynamics — not just the final folded shape, but the actual pathway of how it folds — how proteins interact with small molecules, and designing entirely new proteins from scratch. Every one of those needs even more compute than AlphaFold did.
Then there's climate modeling. Earth's climate is this massive tangle of coupled physical equations, and traditional supercomputer models are limited in resolution by how much compute you can throw at them. AI models like Google's GraphCast can now run higher-resolution forecasts in less time — and on a lot of accuracy measures, they've started beating the classic numerical methods. And in medicine and genomics: predicting disease risk from someone's genome, predicting treatment outcomes from health records. These are problems where the scale of compute you can bring directly sets the accuracy you can reach.
So where does it go from here? Dean flags a shift in mindset. The old model was: train one enormous model, then spend a fixed amount of compute every time you use it. The new idea is to allocate compute dynamically, based on how hard the actual problem is.
One direction is Mixture of Experts. Picture a model with lots of specialized sub-networks — experts — but for any given piece of input, only a small handful actually switch on. So the total knowledge stored in the model can be gigantic, while the compute you spend on each token stays modest. You scale up what the model knows without scaling up what it costs to run.
The other direction is giving models thinking time. Instead of blurting out an answer in one pass, you let the model spend more reasoning steps on genuinely hard problems — chains of thought, searching through possibilities. This is exactly the territory that OpenAI's o1 and o3, and Google's Gemini Thinking models, are exploring right now.
Now, if you're an engineer building AI applications, there's a quieter message tucked inside all this. The democratization of compute lags way behind the frontier. The scale the big labs are playing with today won't reach an ordinary developer for another three to five years. And the flip side of that is genuinely useful to internalize: applications you'd build today will cost dramatically less to run in a few years. Things that feel too expensive to even attempt right now are going to quietly become viable. Meanwhile, because compute is scarce, the craft of getting better results from less of it stays valuable — quantization, distillation, fine-tuning small models for specific jobs. That work isn't going out of style anytime soon.
So let me leave you with three things to hold onto. First: the million-fold isn't hype — it's the real compounded product of three separate tracks, hardware, software, and model architecture, all multiplying together. Second: the payoff isn't bragging rights, it's scientific problems — protein dynamics, climate, genomics — that simply weren't reachable before. And third: the next phase isn't just about building bigger, it's about spending compute more intelligently — routing it to the experts and the problems that actually need it. And the reason Dean's read on this is worth trusting is simple. He didn't just watch this happen. He helped design the TPUs, he built the software stacks, he worked on AlphaFold. When he predicts where this goes next, he's describing the things he's been building all along.
🇹🇼 中文
「我們快把訓練 LLM 的資料用完了」——這幾乎成了 AI 圈的共識。可是在一場輕鬆的訪談裡,Google 首席科學家 Jeff Dean 卻說:其實還有很多資料,我們遠遠沒到底。
先講講這個人為什麼值得聽。Jeff Dean 是這行的傳奇,他領導過 Google Brain,共同打造了 MapReduce——那套讓上千台電腦像一台機器一樣協作的東西——也一起做了 TensorFlow。他在 Google 內部的地位到什麼程度呢?同事幫他編了一堆「Chuck Norris 式」的玩笑。公司裡甚至有一個聊天群叫「資料中心失火」,裡頭會出現這種故障故事:一顆遙遠的超新星爆炸、一道宇宙射線剛好打中記憶體、把某個 bit 的 0 翻成了 1。人稱「計算機科學界的 Chuck Norris」。這樣一個人怎麼看 AI 的資料瓶頸,特別有意思。
先回答最核心的問題:LLM 真的快沒資料訓練了嗎?
Jeff Dean 承認一件事——世界上公開的「文字」資料,我們確實已經用掉相當多了。但他不覺得這會擋住前進,理由有好幾個。
第一,影片資料還沒真正拿去訓練。網路上有海量有價值的影片,現在幾乎還是一塊沒動用的礦。第二,合成資料。有很多辦法可以生成合成資料再拿去訓練。第三,對既有資料做更多次利用——同一批資料多跑幾遍,還能持續逼出更強的模型。第四,更好的演算法,想辦法從每一筆資料裡榨出更多資訊。
你聽出重點了嗎?他其實是在把問題重新定義。真正的變數不是「資料量有多少」,而是「你能從資料裡萃取出多少資訊」。所以 Jeff Dean 的態度很淡定:能做的事還多得很,他一點都不擔心資料會變成天花板。
接著主持人丟了一個更尖銳的問題:如果愈來愈多資料是 AI 生成的,然後又拿去餵給下一個 AI,那大家不就都在同一批東西上原地打轉、愈訓愈糊嗎?
主持人還分享了自己的直覺。那種樂觀的說法是——只要算力夠大,就能翻遍海量資料,就算有用的訊號只是大海裡的一根針,系統終究學得到。但他說,我自己以前那些很爛的小實驗根本不是這麼回事,反而必須對資料非常小心。
Jeff Dean 的回答是:整體來說,這套邏輯是成立的。但——有非常多細節要做對,它才會真的變成現實。然後他舉了一個很具體的例子,來說明「細節」到底長什麼樣。
這個例子就是用 RL rollouts 解程式題。
想像你在做強化學習訓練,要解一道用高階描述給出的程式問題。做法是這樣:對同一道題,你不是只生一個解,而是探索一百種、甚至一千種不同的解法路徑。但這些候選解不會照單全收,而是要通過一層一層的過濾。
第一關,能不能編譯?光是這一關就很殘酷——一千個候選裡,可能當場就刷掉八百個,連編都編不過。編得過的,進第二關:有沒有通過單元測試?沒過的,丟掉。通過的,再進第三關:跑得好不好、效能夠不夠?不好的,繼續淘汰。最後剩下的那少數幾個好解,才拿去訓練。
Jeff Dean 想講的就是這個機制。生成這個動作本身,一定會製造大量雜訊,一千個解裡絕大多數是垃圾。但只要你手上有可靠、而且能自動判斷的過濾條件——編譯、測試、效能——你就能把海量的自我生成內容,一步步收斂到真正高品質的那幾個訊號。
這才是「合成資料為什麼有用」的真正核心。它的價值從來不在「生成」這一步,而在「生成加上篩選」這整套流程有沒有做得夠細。你能不能自動判斷好壞,決定了合成資料到底是助力還是毒藥。
好,收個尾,記三件事。
第一,與其焦慮資料的總量,不如去想怎麼從資料裡萃取更多資訊——這是 Jeff Dean 對整個問題的重新框定。第二,未動用的影片、合成資料、對既有資料更聰明的重複利用,前面還有很大的空間,資料見底這件事被誇大了。第三,合成資料要真的有用,關鍵不是能不能生成,而是有沒有一套能自動判斷好壞的過濾機制——生成上千個解,用編譯和測試層層淘汰,剩下的才是值得學的訊號。
生成很便宜,篩選才是真功夫。
Tags
Related Articles
Google's AI Endgame: What You Actually Missed at I/O 2026
Google I/O 2026's core signal isn't any single product feature — it's that Google has completed the shift from 'AI assistance tools' to 'AI agents': Gemini 3.5 Flash, Gemini Omni, Gemini Spark, and Antigravity 2.0 all point in the same direction — AI isn't your assistant, it's your agent.
RAG's Five Stages: From Pipeline to Reasoning Retrieval, and the Naive RAG on My Own Site
Over the past two years RAG evolved from a 'linear pipeline' to 'loop-based reasoning'. It maps cleanly to five stages: Naive, Advanced, Modular, Graph, Agentic. The real inflection point is control moving from pipeline to agent — a System 1 → System 2 shift. Looking back at engineer-news's own RAG stack, it's stuck at the Naive edge — so this post also lays out what to fix next.
Building a Real RAG: 5 Infra Lessons from InfiniFlow's 2024 Year-in-Review
The previous post zoomed out for a five-stage panorama of RAG. This one zooms in on the five infra lessons any real RAG has to face: document ingestion, contextualized chunking, three-lane hybrid search, tensor reranker, and GraphRAG's semantic gap. Each lesson is checked against engineer-news's current stack, ending with a priority list for a personal site.