「履歷基本上就是 AI 的時間軸」，這是許多人對 Gemini 背後的核心推動者、Google 首席人工智慧科學家 Jeff Dean 的評價。從 2000 年代初重寫 Google 搜尋全棧到重啟兆參數稀疏模型，再到將 TPU 與前緣機器學習研究協同設計，Jeff Dean 以一種低調的方式，幾乎塑造了現代 AI 技術棧的每一層。他親歷了多輪規模革命：從 CPU、分片索引，到能跨文字、影片、程式碼進行推理的多模態模型。
近日，他在一場深度對話中的犀利言論備受熱議。不少業界人士直呼，「資訊量超大」。在這場訪談中，Dean 拋出了諸多獨家觀點與極具前瞻性的判斷。
「大一統模型的時代真的來了。關鍵在於，模型正在變得越來越強，不再需要領域專家。」他表示，未來是專用模型加模組化模型的組合，可以同時擁有並在不同場景下調用 200 種語言、超強機器人模組、超強醫療模組。「模型知識是可安裝的，像下載軟體包一樣。」
作為「電腦歷史上最高產的工程師之一」，Dean 還大方分享了自己現在用 AI 寫程式碼的方式，並表示，「未來很可能每個人都能擁有 50 個虛擬實習生，讓他們組成小組，只需要對接 5 個小組，讓他們各自幹活。」
而且，Dean 詳細透露了 Google 內部「衝前緣」的模式和推動團隊架構改進和模型能力升級的思考。除此之外，他還提出並拆解了多個有趣的問題，包括：為什麼蒸餾是每一次 Flash 模型突破的核心驅動力、為何能耗而非算力正成為真正瓶頸、如何提前 2–6 年進行硬體與模型的協同設計、為什麼下一次躍遷不只來自更大的上下文視窗而是來自能「彷彿在處理兆 token」的系統等。
以下是詳細對話內容，我們在不改變原意的基礎上進行了翻譯和刪減，以饗讀者。
Shawn Wang：今天我們請到了 Google 首席 AI 科學家 Jeff Dean，歡迎您。能邀請到您真的太榮幸了，我看過您無數場演講，您的職業生涯堪稱傳奇。首先必須要說，恭喜你們拿下了「帕雷托前緣」（Pareto Frontier）。
Jeff Dean：謝謝。帕雷托前緣確實很棒，能站在這個位置很不錯。
Shawn Wang：對，我覺得是兩者兼備。你既要佔據帕雷托前緣，要有頂尖能力，也要兼顧效率，然後提供大家願意用的一系列模型。這其中一部分源於你們的硬體工作，一部分來自模型工作，肯定還有很多日積月累的獨門秘訣。能看到這一切如此絲滑地整合在一起，真的非常震撼。
Jeff Dean：是的沒錯。就像你說的，這不是單一因素，而是技術棧從上到下一整套東西的結合。所有這些加在一起，才讓 Google 能夠做出能力極強的大模型，同時也透過軟體技術，把大模型的能力遷移到更小、更輕量的模型裡，這些小模型成本更低、延遲更低，但在自身規模下依然能力很強。
Alessio Fanelli：那在守住帕雷托前緣下限這方面，你們有多大壓力？我感覺很多新實驗室都在拼命衝性能上限，因為要融資之類的。而你們有數十億用戶。我記得你們早年做 CPU 的時候就討論過：如果每個 Google 用戶每天用三分鐘語音模型，你們就得把 CPU 數量翻倍。現在 Google 內部是怎麼討論的？怎麼權衡「衝前緣」和「必須落地部署」這兩件事？
Jeff Dean：我們一直希望擁有前緣、甚至推動前緣的模型，因為只有這樣才能看到去年、半年前不存在的新能力。但同時我們也知道，這些頂尖模型雖然有用，但對很多更廣泛的場景來說，速度偏慢、成本偏高。所以我們的思路是：同時做兩條線，一條是高能力、低成本的模型，支援低延遲場景，讓大家能更輕鬆地用在智能體程式設計等任務上；另一條是高端前緣模型，用於深度推理、解決複雜數學問題這類場景。兩者不是二選一，而是都有用。而且透過蒸餾這一關鍵技術，你必須先有前緣模型，才能把能力蒸餾到小模型裡。所以這不是非此即彼，而是相輔相成。
Alessio Fanelli：你和 Jeffrey 在 2014 年就提出了相關方案。
Jeff Dean：別忘了還有 L'Oreal Vinyls 那篇工作。
Alessio Fanelli：都是很早以前了。我很好奇，你怎麼看待這些思路的迭代週期？比如稀疏模型這類想法，你們會怎麼重新評估？下一代模型裡，哪些舊思路值得重新撿起來？你參與過很多後來影響巨大的想法，但在當時未必能看出來。
Jeff Dean：蒸餾最早的出發點是，我們當時有一個很大的影像資料集，3 億張圖。我們發現，如果為不同影像類別訓練專用模型，比如這個專攻哺乳動物，那個專攻室內場景，先在更寬泛的影像上預訓練，再對聚類後的類別用增強資料微調，效果會好很多。但如果把這 50 個模型當成一個大集成模型，實際部署並不現實。於是蒸餾的思路就來了：把這些獨立的專家模型「壓縮」成一個可以實際部署的形態。這和我們今天做的事本質差不多，只是我們不再用 50 個模型的集成，而是先訓練一個超大模型，再把它蒸餾成小得多的模型。
Shawn Wang：我還在想，蒸餾是不是和強化學習的革新也有關係？我試著表達一下，強化學習會讓模型在分佈的某一部分突飛猛進，但可能在其他區域有損失，是一種不太均衡的技術。但也許可以透過蒸餾把它「收回來」。大家的普遍期望是：提升能力的同時不在其他地方退步。這種無損能力融合，我感覺一部分應該可以透過蒸餾實現，但我還沒太理清，相關論文也不多。
Jeff Dean：我覺得蒸餾的一個核心優勢就是：你可以用很小的模型，配合超大資料集，透過多次遍歷資料，從超大模型那裡拿到邏輯機率輸出，引導小模型學到只用硬標籤學不到的行為。我們觀察到，蒸餾可以讓小模型接近大模型的效果。這對很多人來說都是最佳平衡點。現在 Gemini 已經好幾代了，我們都能讓新一代的 Flash 版本達到甚至大幅超越上一代 Pro 版本的效果。我們會繼續這麼做，因為這是一個很健康的方向。
Shawn Wang：達拉之前問過：最早的路線圖是 Flash、Pro、Ultra。你們是不是一直拿著 Ultra 當「母模型」，從它裡面蒸餾？Ultra 就是那個終極源頭嗎？
Jeff Dean：我們有很多種模型，有些是內部模型，不對外發布或部署；有些是 Pro 級別模型，我們也可以從它蒸餾出 Flash 級別模型。這套能力很重要，推理時的動態擴充套件也能提升模型效果。
Shawn Wang：明白。而且顯然 Flash 的成本優勢帶來了絕對統治力。最新資料好像是 50 兆 token，我記不清了，反正每天都在變。
Jeff Dean：對，希望市場份額也在往上走。
Shawn Wang：我是說從成本上看，Flash 太經濟了，幾乎什麼場景都能用。現在 Gmail 裡有，YouTube 裡有，到處都有。
Jeff Dean：我們也在越來越多的搜尋產品裡用上它，包括各種 AI 模式。
Shawn Wang：我的天，Flash 都進 AI 搜尋模式了？我都沒想到。
Jeff Dean：Flash 模型的一大優點不只是成本更低，還有延遲更低。延遲其實非常關鍵，因為未來我們會讓模型做更複雜的事，生成更多令牌。比如你不再只讓它寫個迴圈，而是讓它寫一整套軟體包。能低延遲完成這些就特別重要。Flash 是一條路徑，我們的硬體平臺也支撐了很多服務能力，比如 TPU，晶片間的互聯性能極高，非常適合長上下文注意力、稀疏專家模型這類技術。這些對規模化部署至關重要。
Alessio Fanelli：那從 Pro 到 Flash 的蒸餾，會不會存在一個臨界點，差不多滯後一代？我有種感覺：很多任務今天 Pro 已經飽和了，到下一代，同樣任務在 Flash 的價位上就能飽和。再過兩代，Flash 幾乎能做所有人需要的一切。那當大部分用戶都滿足於 Flash 時，你們怎麼說服內部繼續投入去推 Pro 的前緣？我很好奇你怎麼看。
Jeff Dean：如果用戶的需求分佈是靜止不變的，那確實會這樣。但現實往往是：模型越強，人們對它的期待就越高。我自己就有體會：一年前我用模型寫程式碼，簡單任務還行，複雜的就不行；現在我們在複雜程式碼上進步巨大，我就會讓它做更難的事。不止程式設計，現在你會讓它分析全球可再生能源部署、寫一份太陽能報告，這些都是一年前沒人會讓模型做的複雜任務。所以你依然需要更強的模型去拓展邊界，同時也能幫我們找到瓶頸：哪裡還不行，該怎麼改進，讓下一代更強。
Alessio Fanelli：你們內部會用一些專屬基準或測試集嗎？因為每次公開的都是那幾個基準，從 97% 漲到 99%，你們內部怎麼推動團隊：我們真正要做的目標是什麼？
Jeff Dean：公開基準有它的價值，但生命週期有限。剛出來時很難，模型只有 10%–30% 正確率，你可以一路優化到 80%–90%。但一旦到 95% 左右，邊際收益就極低了，要么是能力已經達標，要么是訓練資料裡出現了洩漏或相似內容。所以我們有一批不公開的內部基準，確保訓練資料裡完全沒有，代表模型目前還不具備、但我們希望它擁有的能力。然後我們去評估：是需要更專業的資料？還是架構改進？或是模型能力升級？怎樣才能做得更好。
Shawn Wang：能不能舉個例子：某個基準直接啟發了架構改進？我正好順著你剛才的話問。
Jeff Dean：我覺得 Gemini 模型尤其是 1.5 首次推出的長上下文能力，就是這麼來的。我們當時的目標就是。
Shawn Wang：當時所有人一擁而上，全是一片飄綠的圖表，我就在想：怎麼大家同一時間都突破了？
Jeff Dean：Stack Benchmark 這種基準，在 1k、2k、8k 上下文長度上早就飽和了。我們真正在推的是 100 萬、200 萬上下文的前緣，因為這才有真實價值：你可以把上千頁文字、幾小時影片放進上下文裡真正使用。單針查詢已經飽和，我們需要更複雜的「多針查詢」，或是更真實的長上下文理解與生成任務，才能衡量用戶真正需要的能力，而不只是「你能不能找到這個商品編號」。
Shawn Wang：本質是檢索，是機器學習裡的檢索。我想站在更底層一點說：你看到一個基準，發現需要改某個架構才能解決，但你真的應該改嗎？有時候這只是一種歸納偏置。就像曾在 Google 工作的 Jason Wei 說的：你可能短期贏了，但長期不一定能擴充套件，甚至以後還要推翻重做。
Jeff Dean：我不太會糾結具體要用什麼方案，而是先想清楚：我們到底需要什麼能力？我們非常確定，長上下文是有用的，但現在的長度還遠遠不夠。你真正想要的，其實是回答問題的時候能把整個網際網路都納入上下文，對吧？但這靠單純擴容現有方案是做不到的，現在的演算法複雜度是平方級的。一百萬 tokens 已經是現有方案的極限了，你不可能做到十億、更別說兆 tokens。但如果你能營造出一種「模型可以關注兆 tokens」的效果，那就太厲害了，應用場景會多到爆炸。
這相當於能把整個網際網路當成上下文，能處理 YouTube 影片的所有畫素，以及我們能提取到的深層表徵；不只是單個影片，而是海量影片。在個人版 Gemini 層面，只要你授權，模型還能關聯你所有的個人狀態：你的郵件、照片、文件、機票資訊等等。我覺得這會非常非常有用。問題在於，如何透過演算法改進和系統級優化，讓模型真正有意義地處理兆 tokens。
Shawn Wang：對了，我之前算過一筆帳：一個人每天不停說 8 小時話，一天最多也就生成 10 萬 tokens 左右，這個量現在完全裝得下。
Jeff Dean：沒錯。但如果你想理解所有人上傳的影片內容，那就完全不是一個量級了。
Shawn Wang：而且還有個經典例子：一旦跳出文字，進入蛋白質這類資訊密度極高的領域，資料量就爆炸了。
Jeff Dean：Gemini 從一開始就堅持做多模態。對很多人來說，多模態就是文字、圖片、影片、音訊這些人類熟悉的模態。但我認為，讓 Gemini 理解非人類模態也非常重要。比如 Waymo 自動駕駛汽車的雷射雷達資料、機器人感測器資料，還有各類醫療模態：X 光、核磁共振、醫學影像、基因組資訊等等。世界上可能有幾百種資料模態，我們至少要讓模型知道：這是一種有意義、有價值的模態。哪怕你沒有在預訓練裡把所有雷射雷達、MRI 資料都訓進去，至少加一小部分進去也是很有用的，能讓模型對這類資訊有基本概念。
Shawn Wang：正好趁這個機會，我想問一個一直想問你的問題：有沒有「王者模態」，也就是能統攝其他所有模態的模態？舉個簡單例子：視覺在畫素級別就能編碼文字，Deepseek 那篇 OCR 論文就證明了這點。而且視覺也能處理音訊，因為可以轉成語譜圖，本質也是視覺任務。這麼說的話，視覺是不是就是王者模態？
Jeff Dean：視覺和動態時序非常重要。這裡說的動態，是影片，而不是靜態圖片。進化讓眼睛獨立演化了 23 次，是有原因的，感知周圍世界的能力太關鍵了，而這正是我們希望這些模型具備的能力。模型要能解讀我們看到、關注到的事物，並幫我們利用這些資訊去做事。
Shawn Wang：說到動態理解，我必須誇一句：Gemini 目前依然是市面上唯一原生支援影片理解的模型，我經常用它看 YouTube。
Jeff Dean：其實很多人還沒真正意識到 Gemini 模型的能力。我在演講裡舉過一個例子：給模型一段過去 20 年裡 18 個經典體育瞬間的 YouTube 集錦，裡面有喬丹總決賽絕殺、足球進球等等。你直接把影片丟給它，說：「幫我做一個表格，列出所有事件、發生時間和簡短描述。」
它真的能直接從影片裡抽出資訊，生成一張 18 行的表格。大多數人根本想不到，模型可以直接把影片轉成結構化表格。
Alessio Fanelli：你剛才提到「把整個網際網路納入上下文」，Google 本身就是因為人類處理不了全網資訊，才需要做搜尋排序。這對大模型來說邏輯完全不一樣：人類看搜尋結果可能只看前五六條，但對大模型來說，是不是要給它 20 條高度相關的內容？Google 內部是怎麼思考的：如何打造一種比傳統人類搜尋更寬泛、覆蓋更廣的 AI 模式？
Jeff Dean：即使在大模型出現之前，我們的排序系統也是這麼做的：索引裡有海量網頁，大部分都不相關，先用輕量方法篩出一批相關的，比如縮到 3 萬個文件，再一步步用更複雜的演算法、更精細的信號去精排，最終只展示給用戶 10 條左右結果。大模型系統的思路不會差太多。你看似要處理兆 tokens，但實際流程是：先篩出大約 3 萬個文件、大概 3000 萬有用 tokens；再從中精挑細選出 117 個真正值得關注的文件，用來完成用戶任務。
你可以想象這套系統：先用輕量模型、高併發處理，篩出初始 3 萬候選；再用更強一點的模型把 3 萬縮到 117；最後用最強的模型去深度理解這 117 個內容。只有這樣的系統，才能營造出「模型能處理兆 tokens」的效果，就像 Google 搜尋確實在搜全網，但最終只給你最相關的一小部分。
Shawn Wang：我經常跟不了解 Google 搜尋歷史的人說，Bert 剛出來就直接用進了搜尋，效果提升非常明顯。這對 Google 來說肯定是最核心的資料。
Jeff Dean：大模型帶來的文字表示方式，讓我們跳出了「關鍵字必須精確匹配網頁」的硬限制，真正做到主題和語義相關，而不是字面對應。
Shawn Wang：我覺得很多人根本沒意識到，大模型已經接管了 Google、YouTube 這種超高流量系統。YouTube 有個語義標識機制，每個 token 對應一個影片，用碼本預測影片，以 YouTube 的規模來說，這太誇張了。
Jeff Dean：最近 Grok 也用在了可解釋 AI 上。其實在大模型大規模用於搜尋之前，我們就一直在弱化「用戶輸入什麼就必須匹配什麼」的思路。
Shawn Wang：你有沒有梳理過這一路的演進歷程？
Jeff Dean：我 2009 年在一個網路搜尋與資料挖掘會議上做過一次演講，講了 1999 到 2004、2005 年左右，Google 搜尋和檢索系統的五六代架構演進，那部分內容我們沒有正式發過論文。2001 年發生了一件關鍵的事：我們在多個維度擴容系統。一是把索引做大，覆蓋更多網頁，品質自然會提升，索引裡沒有的頁面，你永遠搜不出來。二是擴容服務能力，因為流量暴漲。我們用的是分片架構，索引變大就加分片，比如從 30 片變成 60 片，以此控制延遲。流量變大就增加副本。
後來我們算了一筆帳：一個資料中心有 60 個分片，每個分片 20 個副本，一共 1200 臺帶硬碟的機器。這些機器的記憶體加起來，剛好能把整個索引全放進記憶體。於是 2001 年，我們直接把全量索引塞進記憶體，效果直接起飛。在此之前，你必須非常謹慎，因為每個查詢詞都要在 60 個分片上觸發一次磁碟尋道，索引越大效率越低。但全量記憶體索引後，哪怕用戶只輸入三四個詞，你擴充套件成 50 個相關詞都沒問題，可以加同義詞，比如 restaurant、restaurants、cafe、bistro 全都一起搜。我們終於能開始理解詞義，而不是死磕用戶輸入的字面形式。
那是 2001 年，遠在大模型之前，但思路已經是：放寬嚴格字面匹配，靠近語義理解。
Alessio Fanelli：你設計系統的原則是什麼？尤其是在 2001 年，網際網路規模每年翻幾倍、漲三倍，現在大模型也是每年規模和能力跳一大截。你有什麼一貫的設計原則？
Jeff Dean：首先，設計系統時，必須先抓住最關鍵的設計參數：每秒要扛多少查詢？網際網路有多大？索引要做多大？每個文件存多少資訊？怎麼檢索？流量再漲兩三倍還能不能扛？我一個很重要的設計原則是：把系統設計成能擴容 5～10 倍，但不用更多。因為一旦變成 100 倍規模，整個設計空間會完全不一樣，原來合理的方案會直接作廢。比如從磁碟索引到記憶體索引，就是流量和機器足夠多之後才變得可行的，一下子開啟了全新架構。
我很喜歡在寫大量程式碼之前，先在腦子裡把設計空間推演一遍。回到 Google 早期，我們不僅在瘋狂擴大索引，索引更新頻率才是變化最誇張的指標。以前是一個月更新一次，後來我們做到了單頁面一分鐘內更新。
Shawn Wang：這就是核心競爭力對吧？
Jeff Dean：沒錯。新聞類查詢，如果你的索引還是上個月的，那就完全沒用。
Shawn Wang：新聞是個特殊場景，你們當時就不能把它拆成獨立系統嗎？
Jeff Dean：我們確實推出了 Google 新聞，但用戶在主搜尋裡輸新聞相關關鍵字，也必須拿到最新結果。
Shawn Wang：所以你們還要分類頁面，判斷哪些頁面該高頻更新、頻率是多少。
Jeff Dean：背後有一整套系統，用來決定頁面的更新頻率和重要度。有些頁面雖然變化機率低，但只要更新價值極高，依然會非常頻繁地重新抓取。
Shawn Wang：說到延遲和儲存，我必須提你的一篇經典之作：《每個程式設計師都該知道的延遲數字》。背後有什麼故事嗎？就是隨手整理的？
Jeff Dean：裡面大概列了八九種、十來項指標：快取失效開銷、分支預測失敗開銷、記憶體訪問開銷、從美國發資料包到荷蘭的時間等等。
Shawn Wang：順便問一下，為什麼是荷蘭？是因為 Chrome 的關係嗎？
Jeff Dean：我們當時在荷蘭有個資料中心。其實這就回到了快速估算這件事上。這些都是最基礎的指標，你可以拿它們來做判斷：比如我要做圖片搜尋、生成縮圖，我是提前算好縮圖，還是實時從大圖裡生成？需要多少頻寬？會產生多少次磁碟尋道？你只要手裡有這些基礎數值，幾十秒就能在腦子裡做一遍推演。等你用更高階的庫寫軟體時，也要培養出同樣的直覺：比如在某種結構裡查一次資料大概要多久。
Shawn Wang：這就是簡單的位元組換算，沒什麼特別的。我在想，如果你要更新那篇文章的話……
Jeff Dean：我覺得很有必要去算一下模型裡的計算量，不管是訓練還是推理。
Jeff Dean：一個很好的視角是：你需要從記憶體裡搬運多少狀態，片上 SRAM、加速器的 HBM、DRAM，還是網路傳輸？然後對比一下，資料搬運的成本，和矩陣乘法單元裡一次實際乘法運算的成本差多少。其實計算成本非常非常低，根據精度不同，大概不到 1 pJ。
Shawn Wang：哦，懂了，你是用能耗來衡量的。
Jeff Dean：對，核心就是能耗，以及如何做出能效最高的系統。在同一塊晶片上，只是從一邊的 SRAM 傳到另一邊，能耗就可能達到 1000 pJ。這就是為什麼加速器一定要用批處理（batching）。如果你把一個模型參數從片上 SRAM 搬到乘法單元，要花 1000 pJ，那你最好把這個參數重複用好多次。這就是 batch 維度的意義。batch 設成 256 就還好，但如果是 1，那就非常不划算。
Shawn Wang：對，沒錯。
Jeff Dean：因為你花了 1000 pJ，就為了做一次 1 pJ 的乘法。
Shawn Wang：我從來沒聽過從能耗角度去解釋批處理。
Jeff Dean：這就是大家用 batch 的根本原因。理論上，batch=1 延遲最完美，但能耗和計算效率的浪費實在太大了。
Shawn Wang：延遲是最好的。
Jeff Dean：對，但代價太高。
Shawn Wang：那有沒有類似當年「把索引全放進記憶體」這種神級技巧？比如 NVIDIA 這次押注 SRAM 搞 Grok，引起很大轟動。我在想，你們做 TPU 的時候是不是早就看到這一點了？畢竟要支撐你們的規模，肯定提前預判到了。從這些現象裡，你們總結出了哪些硬體創新或洞察？
Jeff Dean：TPU 有很規整的結構，2D 或 3D 網格，很多晶片連在一起，每塊都掛著 HBM。
在部署某些模型時，從 HBM 拿資料比從片上 SRAM 拿資料，成本和延遲都高得多。所以如果模型夠小，你可以用模型並行，把它分散到很多晶片上，吞吐量和延遲都會明顯提升。把一個中小模型打散到 16、64 塊晶片上，如果全都能放進 SRAM，提升會非常巨大。這不算意外，但確實是個好技巧。
Alessio Fanelli：那 TPU 的設計呢？你們怎麼決定改進方向？舉個例子，有沒有辦法把 1000 pJ 降到 50？值得為了這個專門設計一顆新晶片嗎？最極端的就是有人說，直接把模型燒進 ASIC。領域變化這麼快，多少事值得用硬體來解決？內部是怎麼討論的？
Jeff Dean：我們 TPU 晶片設計架構團隊和高層建模專家之間有大量協作。因為你需要協同設計：根據機器學習研究的未來方向，去定義下一代 TPU 應該長什麼樣。做 ML 硬體的人都知道，今天開始設計一顆晶片，可能兩年後才進資料中心，還要用三四年。你必須預測未來 2～6 年，人們會想跑什麼機器學習計算。所以，要有一批人去研究：哪些思路在那段時間裡會起效、會更重要。這樣我們才能把有用的硬體特性，加到未來幾代的 TPU 裡。
Shawn Wang：晶片迭代週期是兩代之後？
Jeff Dean：差不多。小改動可以塞進下一代，大改動必須提前更早啟動設計。只要條件允許，我們都會這麼做。有時會加一些試探性的功能，佔晶片面積不大，但如果成了，能直接快 10 倍；就算不成，也就浪費一點點面積，問題不大。但如果是特別大的改動，我們就會非常謹慎，做大量實驗來確認方向是對的。
Alessio Fanelli：那有沒有反過來的情況：因為晶片設計已經定了，所以模型架構不能那麼走，因為不匹配？
Jeff Dean：肯定有。你會反過來調整模型架構，讓它在那一代晶片上訓練和推理更高效。兩邊是互相影響的。比如未來一代晶片支援更低精度，你甚至可以提前用那個精度訓練，哪怕當前一代還不完全支援。
Shawn Wang：那精度到底能壓到多低？
Jeff Dean：很多人在說三值精度。我個人非常支援極低精度，因為能省巨大量的能耗。能耗是按每位元傳輸算的，減少位元數是最直接的方式。業界已經在極低位元精度上取得了很多效果，再配上一組權重的縮放因子，效果就很穩。
Shawn Wang：有意思，低精度，但帶縮放權重。我以前沒想過這點。
Shawn Wang：說到這，我覺得精度這個概念本身在採樣場景裡就很奇怪。我們堆了這麼多算力超強的晶片，最後前面還要掛一個隨機數生成器。現在業界有往能量基模型、能量導向處理器發展的趨勢，你顯然也思考過，能說說你的看法嗎？
Jeff Dean：確實有幾個有意思的方向。能量基模型是一個，不按順序逐 token 解碼的擴散模型是另一個。還有 speculative decoding（推測解碼），相當於一個很小的草稿 batch，先預測 8 個 token，有效 batch size 就擴大 8 倍，最後接受其中 5～6 個。這樣分攤下來，把權重搬到乘法單元裡的成本就被攤薄了，能帶來幾倍的提升。這些都是非常好的技巧。而且一定要從真實能耗、延遲、吞吐量這幾個角度去看，你才會找到正確的方向：要么能服務更大模型，要么同等模型成本更低、延遲更低。
Shawn Wang：這個思路在理論上很吸引人，只是還沒真正成為主流。但某種意義上還挺有美感的，如果從硬體底層就設計好，我們就不用搞那麼多取巧的辦法。
Jeff Dean：還有一些更前緣的方向，比如模擬計算基底，而不是數字電路。理論上能效可能極高，但問題是你要跟數字系統對接，數模、模數轉換那部分會吃掉大部分能效優勢。但即便只看數字方向，靠更專用、更高效的硬體，能效上我們還有巨大的提升空間。
Alessio Fanelli：你還看到哪些有意思的研究方向？或者有什麼在 Google 暫時沒法做，但希望其他研究者去嘗試的方向？
Jeff Dean：我們的研究佈局已經很廣了。有很多開放問題：怎麼讓模型更可靠，能做更長、更複雜、包含大量子任務的事情？怎麼實現模型調用其他模型當工具，組合起來完成遠比單模型更有意義的工作？這部分非常有意思。還有，怎麼讓強化學習在不可驗證的領域也能生效？這是個很棒的開放問題。如果能把數學、程式碼上的進步，複製到其他沒那麼容易驗證的領域，模型能力會再上一個大臺階。
Alessio Fanelli：之前 Noam Brown 來節目裡說，他們已經用深度推理證明了這點。某種意義上，你們的 AI 模式也是不可驗證的。我在想這裡面有沒有共通的線索？比如都在做資訊檢索、返回 JSON。是不是檢索就是那個可以打分、可以驗證的部分？你怎麼理解這個問題？
Jeff Dean：可以用其他模型來評估第一個模型的結果，甚至做檢索。比如讓另一個模型判斷：檢索回來的內容相關嗎？2000 條裡最相關的 50 條是哪些？這類方法其實非常有效。甚至可以就是同一個模型，只是換個提示詞，從「檢索系統」變成「評判器」。
Shawn Wang：我總覺得有一道很明顯的坎：好像簡單的事都做完了，剩下的都特別難。其實每年大家都這麼覺得。尤其是 RLVR 這塊，所有人都在問：不可驗證問題的下一階段到底怎麼做？然後大家都說：不知道，等著評判。
Jeff Dean：這個領域好就好在，有無數聰明人在給這些難題想創造性的解法。大家都看得很清楚：模型在某些事上很強，但在邊緣場景就會拉胯。提出技巧、驗證效果、推動進步，就是這個領域研究的核心。你想想兩年前，我們連 GSM8K 這種小學數學題都費勁。現在呢？模型已經能純靠語言解國際奧數、埃爾德什級別的問題。一年半裡能力的躍遷是驚人的，其他領域我們暫時還沒完全看清楚路徑，但有一些已經看到曙光，我們會全力把這種飛躍複製過去。
Shawn Wang：沒錯。
Alessio Fanelli：比如 YouTube 縮圖生成，這個功能會非常實用，我們太需要了。這簡直就是 AGI 級別的需求。
Shawn Wang：對內容創作者來說絕對是。
Jeff Dean：我不是 YouTube 創作者，所以對這個問題沒那麼敏感，但我知道很多人很在意。
Shawn Wang：確實大家很看重。畢竟大家真的會「以封面論影片」。回到奧數那個話題，我到現在還覺得不可思議：一年前我們還在搞 AlphaProof、AlphaGeometry 這些專門的系統，今年直接一句「算了，全都塞進 Gemini 就行」。你怎麼看這件事？過去大家普遍認為，符號系統和大模型必須結合，但後來大家直接選擇：全都用大模型解決。
Jeff Dean：我覺得這很合理。人類確實會操作符號，但我們腦子裡大概率沒有一個明確的符號系統，而是某種分佈式表徵，本質上接近神經網路。大量神經元在特定情況下產生啟用模式，讓我們能推理、規劃、做思維鏈，發現一條路走不通就換一條。在很多方面，基於神經網路的模型，其實是在模擬我們直覺中大腦裡發生的事情。所以對我來說，把完全離散、獨立的符號系統，和另一套完全不同的思考機制分開，從來就不太合理。
Shawn Wang：有意思。對你來說可能理所當然，但一年前我可不是這麼想的。
Jeff Dean：你看奧數任務也是一樣，最開始要翻譯成 Lean 語言、用專門工具，第二年還要專用幾何模型，到今年直接換成一個統一模型，就是線上正式版模型，只是多給了一點推理資源。
這其實很好，說明通用模型的能力大幅提升，不再需要專用模型。這和 2013 到 2016 年那波機器學習的發展非常像：以前每個任務都要單獨訓模型，識別路標訓一個，語音識別訓一個。現在，大一統模型的時代真的來了。關鍵在於，這些模型在從未見過的新任務上泛化能力如何，而它們正在變得越來越強。
Shawn Wang：而且不再需要領域專家。我之前採訪過相關團隊的人，他說：我完全不懂奧數，不知道比賽在哪舉行、規則是什麼，我只管訓模型。挺有意思，現在只要有機器學習這種通用技能，給資料、給算力，就能搞定幾乎任何任務。這大概就是所謂的「苦澀教訓」吧。
Jeff Dean：我認為，通用模型在絕大多數情況下都會勝過專用模型。
Shawn Wang：這點我想再追問一下。我覺得這裡有個漏洞：模型的容量是抽象的，它能裝下的知識只有參數量對應的位元數。誰都知道 Gemini Pro 有幾兆參數，但具體沒人知道。但像 Gemma 這類模型，很多人想要開源、本機跑的小模型，它們必然裝不下所有知識。大模型有條件什麼都知道，但小模型在蒸餾、壓縮的過程中，其實會記住很多沒用的東西。所以我們能不能把知識和推理剝離開？
Jeff Dean：你確實希望模型把推理做到最強，同時具備檢索能力。讓寶貴的參數空間去記那些可以查到的冷僻知識，其實不是最優使用方式。你更希望參數用在更通用、更多場景都有用的能力上。但同時，你也不想讓模型完全脫離世界知識。比如知道金門大橋大概有多長，對「橋有多長」有個基本概念，這類常識是有用的。它不需要知道世界上某個偏僻小橋的長度，但具備相當規模的世界知識是有幫助的，模型越大，能裝的就越多。但我確實認為，把檢索和推理結合起來，讓模型擅長多輪檢索，會是關鍵方向。
Shawn Wang：並且基於中間檢索結果做推理，會讓模型看起來比實際強得多。比如個人版 Gemini。
Jeff Dean：我們不太可能把我的郵件拿去訓 Gemini。更合理的方式是：用一個統一模型，把檢索我的郵件、我的照片當成工具，讓模型基於這些資訊去推理、互動，分多輪完成任務。這樣才合理。
Alessio Fanelli：你覺得垂直領域模型有意義嗎？比如很多人說「我們要做最好的醫療大模型、最好的法律大模型」。這些只是短期過渡方案嗎？
Jeff Dean：不，我覺得垂直模型是有價值的。你可以從一個很強的基座模型出發，然後在醫療、機器人這類垂直領域富集資料分佈。我們不太可能把所有機器人資料都塞進 Gemini 訓練，因為要保持能力均衡。我們會給它看一部分機器人資料，但如果你想做一個極致優秀的機器人模型，就要在通用模型基礎上，再用更多機器人資料去訓練。它可能會因此損失一點翻譯能力，但機器人能力會大幅提升。
我們訓練基座 Gemini 時，一直在做這類資料配比權衡。我們很想加入 200 多種語言的資料，但這會擠佔其他能力：可能 Pearl 程式設計就沒那麼強了，Python 還能保住，但其他小眾語言或多模態能力可能會受影響。所以我認為，未來是專用模型加模組化模型的組合。你可以同時擁有 200 種語言、超強機器人模組、超強醫療模組，在不同場景下調用。比如處理醫療問題時，就把醫療模組和基座模型一起用上，效果會更好。
Shawn Wang：可安裝的知識。
Jeff Dean：沒錯。
Shawn Wang：像下載軟體包一樣。
Jeff Dean：一部分可安裝知識可以來自檢索，另一部分應該來自預訓練，比如提前用 1000 億、1 兆 token 的醫療資料訓好。
Shawn Wang：Gemma 3 的論文裡已經有一點這個味道了。
Alessio Fanelli：問題是，你到底需要幾千億 token，才能追上前緣基座模型的進步速度？如果我想做一個更強的醫療模型，而主模型 Gemini 還在不停進化，我需要 500 億 token 嗎？1000 億？如果需要一兆醫療 token，那資料根本就不存在。
Jeff Dean：醫療是一個特別有挑戰的領域。很多醫療資料我們沒有合適的訪問權限，但很多醫療組織希望用自己的私有資料訓模型。所以機會在於：和大型醫療機構合作，為它們定製模型，效果很可能比只用公開資料訓練的通用模型更好。
Shawn Wang：對了，這和語言的話題也有點像。你最喜歡舉的一個例子就是：把低資源語言放進上下文裡，模型直接就能學會。
Jeff Dean：對，我們用過一個叫 Calaba 的語言，資源極度稀缺，全世界只有大概 120 個人說，還沒有文字。
Shawn Wang：直接放進上下文就行，把整個資料集塞進去。
Jeff Dean：像索馬里語、阿姆哈拉語這類語言，世界上是有一些文字的。我們不會把所有資料都放進 Gemini 訓練，但放得越多，模型能力就越強。
Shawn Wang：我個人對語言學有副業興趣，大學時修過幾門課。如果我是語言學家，能用上這些模型，我會去問關於語言本身的根本性問題。比如薩丕爾—沃爾夫假說：你說的語言在多大程度上影響你的思維？有些語言裡存在其他語言沒有的概念，也有很多概念是重複的。還有一篇很有名的論文提到「柏拉圖表徵」：比如「杯子」的圖片，配上大量帶「cup」的文字，最後表徵會收斂到差不多同一個位置。這套邏輯理論上也適用於語言，但有些地方不適用，而這些不適用的地方，恰恰反映了人類獨有的概念差異，有些概念甚至英語裡都不存在。這部分我覺得非常有意思。
Jeff Dean：我早年做過一個模型，把文字表徵和影像模型結合起來，在 ImageNet 這類資料上訓練，然後把頂層表徵融合。你會發現，給模型一張它從未見過的新圖片，它往往能給出正確標籤。比如，模型學過望遠鏡和雙筒望遠鏡，但沒見過顯微鏡。給它看顯微鏡的圖片，它居然能輸出「microscope」這個標籤，儘管從來沒見過帶這個標籤的圖。
Shawn Wang：這太酷了。
Shawn Wang：以你的視野，我們聊了硬體、模型、研究，你最希望被問到哪一類問題？
Jeff Dean：有件事我覺得挺有意思的。1990 年我本科畢業論文做的就是神經網路並行訓練。那時候我就覺得，神經網路是正確的抽象方向，只是算力遠遠不夠。系裡那臺 32 核的並行計算機，只能跑出稍微有趣一點的模型，遠遠解決不了真實問題。直到 2008、2009 年，摩爾定律帶來了足夠的算力，加上更大的資料集，神經網路才真正開始解決大家關心的真實問題：語音、視覺，最後是語言。
2011 年底我在 Google 開始做神經網路時，就堅定地認為：我們要用大規模並行計算，把神經網路的規模拉上去。我甚至把本科論文裡的一些思路重新撿了起來，包括模型並行、資料並行，並且做了對比。可以說，我從 8 歲就開始琢磨這些事了，只不過那時候叫法不一樣。
Shawn Wang：那篇論文是公開的嗎？我們能找到嗎？
Jeff Dean：可以的，網上就能查到。過去這 15 年裡，把這些技術整合在一起，全力做規模化，是非常關鍵的。這既包括硬體層面的進步，比如推動 TPU 這類專用晶片的研發，也包括軟體層面，做更高階的抽象，讓人們能更方便地把想法交給計算機去實現。
Shawn Wang：你當時是否認同這個觀點？或者現在有不同的復盤？
Jeff Dean：說的是算力配額的「大腦市場」機制？
Shawn Wang：對，算力配額。David 之前在 OpenAI 做負責工程的副總裁，後來也去過 Google。他的核心觀點是：OpenAI 敢於 all in，把賭注全壓在一件事上；而 Google 更加「民主化」，每個人都有自己的配額。如果你相信規模化很重要，那就是一個全公司層面的關鍵決策。
Jeff Dean：我部分同意。事實上，我當時還寫過一頁紙的備忘錄，說我們把資源碎片化是很愚蠢的。那時候，Google 研究室和 Brain 團隊在做大語言模型，其他部門在做多模態，DeepMind 那邊也在做 Chinchilla、Flamingo 這些模型。結果就是，我們不僅算力被拆分，最優秀的人才和精力也被拆分了。我當時就說，這樣太傻了，為什麼不合併起來，集中力量做一個從頭就是多模態、全能的大一統模型？這就是 Gemini 項目的起源。
Shawn Wang：你這一頁紙的備忘錄成了，很不錯。當時名字想好了嗎？大家都知道，Gemini 是你取的。
Jeff Dean：是我取的。當時還有另一個候選名字，但我覺得，兩個團隊合在一起，某種意義上就像雙胞胎。而且 NASA 也有 Gemini 計劃，是阿波羅登月之前非常關鍵的一步。所以這個名字很合適，代表雙子攜手。
Alessio Fanelli：很棒。我知道時間不多了，最後很好奇：你現在怎麼用 AI 寫程式碼？你可以說是計算機歷史上最高產的工程師之一。我看過一篇文章，講你和 Sanjay 的合作方式，你說過：要找到和你思維合拍的人結對程式設計，兩個人加起來才會是互補的合力。我就在想，你怎麼看待程式碼智能體？你會怎麼塑造一個和你思維相容的程式碼助手？現在的工具你打幾分？未來方向在哪？
Jeff Dean：首先，程式碼工具相比一兩年前已經強太多了，現在真的可以把更複雜的任務交給它們。人類工程師和程式碼模型之間的互動方式，其實會反過來決定它怎麼配合你。你可以讓它寫完備的測試，也可以讓它幫你 brainstorm 性能優化思路。你和它互動的方式，會決定它的輸出風格、解決問題的粒度，以及你希望它更自主，還是更頻繁地和你對齊。沒有哪一種風格是萬能的。有些問題你需要高頻互動，有些問題你直接說「幫我把這個實現出來」就行。
未來會出現更多獨立軟體智能體，幫你代勞各種事情。難點在於設計合適的人機互動模式、介面，決定它什麼時候該打斷你：「我需要更多指引」或者「我做完了，下一步做什麼」。這部分我們還沒有終極答案，模型變強之後，互動模式還會變。你可以想象成：你帶了 50 個實習生，你會怎麼管理？如果他們能力很強，你可能真的會想要 50 個。
Shawn Wang：但管理成本也很高。
Jeff Dean：沒錯。但未來很可能每個人都能擁有 50 個虛擬實習生。那你該怎麼安排？你肯定會讓他們組成小組，你不用管 50 個人，只需要對接 5 個小組，讓他們各自幹活。最終會演變成什麼樣，我也不完全確定。
Alessio Fanelli：那人與人的協作呢？AI 輔助程式設計的好處是能帶來新的思路。但如果有大量程式碼智能體在並行寫程式碼，其他人要介入就很困難，因為要追上巨量的上下文。你會不會擔心，團隊裡的人會變得更孤立？
Jeff Dean：有可能。但反過來想，傳統沒有 AI 輔助的團隊，50 個人幹活，組織結構天然是層級化的，各組之間互動不多。但如果是 5 個人，每人管理 50 個虛擬智能體，這 5 個人之間的溝通頻寬，反而可能比傳統 5 個組長協調 50 個人的模式更高。
Alessio Fanelli：那你自己的工作節奏有改變嗎？會不會花更多時間和人對齊架構、設計目標？
Jeff Dean：我覺得很有意思的一點是：以前教別人寫軟體，都會說要把需求文件寫清楚，但大家其實都不當回事。但現在，如果你要讓智能體幫你寫程式碼，你必須極其清晰地定義需求，這會直接決定輸出品質。你沒說它要處理某種邊界情況、沒強調性能要求，它就可能不做。人們會越來越擅長清晰、無歧義地描述目標，這其實不是壞事，不管是不是工程師都是一項有用的技能。
Shawn Wang：我開玩笑說，現在給模型下指令，和高階高管溝通沒區別，像寫內部備忘錄一樣，字斟句酌。而且我認為多模態非常重要。Google 的 Anti-Gravity 團隊一上來就做了很強的多模態，包括影片理解。這是你能給模型的、最高頻寬的「提示詞」，非常強。
Alessio Fanelli：你平時是怎麼整理自己腦子裡那些經驗的？比如你那種超強的性能優化直覺，大家都說你一眼就能看出哪裡能提效。那如果把這些經驗寫成通用文件，再讓模型去檢索學習，會不會很有價值？就像邊界情況，就是個很好的例子。做系統的人腦子裡都有特定的邊界場景，但現在每次都要重複說一遍。你覺得人們會花更多時間去寫文件、提煉通用經驗嗎？
Jeff Dean：我確實認為，寫得好的軟體工程指南會非常有用。既可以給模型當輸入，也可以讓其他開發者參考，讓他們在寫提示詞時，更清楚底層系統應該實現什麼。不一定需要為每個場景單獨定製，只要有通用指南，放進程式碼智能體的上下文裡，就會很有幫助。比如分散式系統，可以列出：要考慮哪些故障類型、有哪些處理方案，像 Paxos 複製、雙寫請求、只要一個返回即可容忍故障等。把 20 個這類分散式系統設計技巧總結一下，就能很大程度提升程式碼智能體生成可靠、健壯分散式系統的能力。
Shawn Wang：我就在想，Gemini 什麼時候能自己造出 Spanner（解決了分散式系統 CAP 不可能三角的關係型資料庫）？
Alessio Fanelli：搞不好程式碼它早就全看過了。這就是個好例子。CAP 定理是公認的真理，不能打破，但最後你們還是做出了看似打破它的東西。
Shawn Wang：我很好奇，模型算不算某種意義上「打破」了它？你會說你們打破了 CAP 定理嗎？在特定假設下，比如精準時鐘同步的前提下。
Alessio Fanelli：有時候你不必死守所謂的真理。但模型有時候會過於相信你告訴它的東西。
Jeff Dean：回到提示詞和迭代的問題。我一直想做一個對比實驗：一種是，用三次快速但普通的模型調用，中間加入人類對齊，人看一遍結果，再給新提示；另一種是，花很久寫一個超長、超精細的提示詞，直接丟給一個超強模型一次做完。我想看看這兩種方式的效果差距。很多時候效果不好，不是模型不行，而是需求描述不完整，模型根本不可能猜到你想要什麼。
Shawn Wang：就是定義不清晰，模型可以生成 10 個結果，只有一個是你想要的。而用輕量快模型多輪互動，反而夠用。
Jeff Dean：我非常重視延遲。低延遲互動體驗，比慢 10 倍、20 倍的系統舒服太多。未來我們會看到模型、軟體、硬體整體延遲比現在低 20 倍、50 倍，這對需要大量互動的系統至關重要。
Shawn Wang：現在有兩個極端，一邊是極致快，另一邊是 DeepThink 這種極致深思考。
Jeff Dean：如果不考慮成本和延遲，所有人都會一直用 DeepThink。如果底層硬體和系統把延遲再提 20 倍，成本下來，沒理由不用。
Shawn Wang：帕雷托曲線會一直往上走，不斷外擴。我們來問點預測吧。你有沒有什麼一直關注的小測試，或者哪些東西你覺得現在還不夠好，但很快能實現？
Jeff Dean：我說兩個不算這一類的預測吧。第一，了解你、能訪問你所有授權的個人資料的個性化模型，相比通用模型會帶來巨大的價值提升。能關聯我所有的郵件、照片、看過的影片、一切資訊，這會非常有用。第二，越來越專用的硬體會讓模型延遲更低、能力更強、成本更親民，這一點也會非常關鍵。
Shawn Wang：你說的低延遲，大家一般用 token 每秒衡量。現在大概是 100 token/s，你覺得能到 1000？10000 有意義嗎？
Jeff Dean：絕對有。因為有思維鏈推理。你可以並行做更多輪推演，生成更多程式碼，再用思維鏈校驗正確性。10000 token/s 會非常強。
Shawn Wang：到 10000 token/s，人就不用讀程式碼了，直接讓模型生成。
Jeff Dean：它最終不一定輸出 10000 token 程式碼，可能只有 1000 token 程式碼，但背後有 9000 token 的推理過程，這樣的程式碼品質會高得多。
Alessio Fanelli：就像「如果我有更多時間，我會寫一封更短的信」。Jeff，今天太棒了，感謝你的時間。
Jeff Dean：很開心，謝謝邀請。
參考連結：https://youtu.be/F_1oDPWxpFQ
聲明：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。