新聞 
40天不睡5人死磕 Gemini大戰DeepSeek慘烈內幕
40天不睡5人死磕 Gemini大戰DeepSeek慘烈內幕40天不睡5人死磕 Gemini大戰DeepSeek慘烈內幕
DeepMind的Gemini預訓練負責人 Vlad Feinberg自曝研發內幕：5人團隊為搶跑DeepSeek，在硅谷和巴黎雙城倒班、40天幾乎不眠不休死磕訓練。他不認為人工智能會取代所有人的工作，原因在於，人類在組織裡承擔的壹個關鍵角色，是構成壹張信任網絡。
Google DeepMind 的 Gemini 預訓練主管 Vlad Feinberg，最近在壹檔播客裡聊了聊他的日常。
在大眾的想象中，頂尖實驗室的研究員每天都在推導顛覆性的算法。但 Vlad 說，他職業生涯最重要的壹筆獎金，是谷歌傳奇人物 Jeff Dean 親手發給他的——當時他剛入職 Google Brain，沒有像當年同樣在谷歌的 Transformer 作者們壹樣，去寫那些能發到頂級會議上的第壹作者論文，而是默默幹了幾天最髒的活：調整編譯器和超參數，解決顯存溢出，把壹個叫 SFT 的微調任務塞進了壹堆老舊的 TPU 卡裡，這才讓第壹代 Bard 勉強跑通。
這種“幹髒活”的工程體驗，才是這輪大模型競爭最真實的樣子。Gemini 2.0 出來的時候，外界都在贊歎它作為壹個 MoE 模型有多神奇。但 Vlad 透露，背後其實只有 5 個人在頂著。
算力卡隨時會掛，數據索引隨時會斷，為了不白白浪費幾百萬美元的算力費，他們只能在硅谷和巴黎兩個大區之間 24 小時倒班，不眠不休地死磕了 40 天。甚至在 DeepSeek-V3 爆紅、華爾街日報制作表格拉踩谷歌已經落後時，Vlad 也是哭笑不得——媒體為了制造爆款新聞，在表格裡故意刪掉了（elided）排名其實高居第壹的 Gemini 2.0 Flash Thinking。
對於甚囂塵上的“程序員要失業”的恐慌，這位主管給出了壹個很幹脆的觀點：AI 永遠無法被“吊銷律師執照”，因為它不具備主體資格，無法承擔法律責任，所以人類永遠要為它的產出簽字並背書。
他的組裡有壹個叫 Nate Lintz 的普通工程師，之前在搜索部門寫後端基礎架構，就是靠著在業務裡幫大模型落地，解決最具體的推理開銷，最終內部轉崗到 DeepMind 成了技術支柱。
如果你也想去，Vlad 在他的博客裡放了壹個“硬核作業”（手寫壹個 Transformer 並手算 Scaling Laws 錄成視頻發給他），做完了他直接面你。以下是這次談話裡，他聊到的幾個極其真實的行業細節：
法律大模型可以背下所有判例，但它不能代表你出庭，因為它無法被“吊銷執照”。職業的底層邏輯是責任和信任的分配。因為 AI 無法承擔法律後果，代碼的終點永遠需要壹個具體的人來簽字、背書並承擔責任。這才是程序員不會被替代的終極底線。
寫再牛逼的學術論文，都不如幫團隊省下幾張卡的顯存。很多眼高手低的程序員在 AI 時代迷失在理論和框架中。但在研發壹線，最容易拿獎金的能力，是那些不體面的“重體力活”——優化編譯器、調試超參、在有限的芯片裡榨出最後壹絲算力。這種扎實的工程能力，才是跨越周期的硬通貨。
寫搜索基礎架構的普通碼農，也是能壹步步逆襲進 DeepMind 的。團隊核心成員 Nate Lintz 曾只是壹個寫後端搜索的普通工程師，他沒有高大上的 AI 背景，但通過在組內幫產品落地 LLM，默默解決大模型在搜索業務裡最頭疼的推理和算力開銷，在實戰中摸清了底層架構，最終順理成章地轉崗進入 DeepMind 並主導了核心推理設計。
華爾街日報為了拉踩谷歌，在對比 DeepSeek 時故意在表格裡刪掉了排名第壹的 Gemini 模型。當媒體為了制造“中國開源超越美國大廠”的新聞而興奮時，他們有意隱去了當時在 LMSYS 榜單上高居榜首的 Gemini 2.0 Flash Thinking。真實的技術對決背後沒有神話，只有 5 個工程師在硅谷和巴黎 24 小時倒班、死磕 40 天的硬撐。
你沒法把研究和落地分成兩種人
主持人：你寫過壹篇題為《如何進入前沿實驗室工作》的文章。現在前沿實驗室最需要的，到底是什麼樣的能力？也許我們可以先聊聊，這類工作的整體輪廓是什麼。
Vlad：現在前沿實驗室需要的能力，其實覆蓋范圍非常廣。大語言模型這種東西，和研究、和產品之間的關系，比過去的機器學習要緊密得多，所以它會牽動很多完全不同的方向。我寫那篇文章，並不是想開壹份面面俱到的清單，而是想提出幾個比較具體、可操作的方向，說明實驗室會在哪些能力上有很強的需求。
我重點寫的是內核開發和底層工程，也就是怎樣在真實運行環境中提升大語言模型的執行效率。我看到這類能力，在幾乎所有前沿實驗室，以及實驗室內部很多項目裡，需求都非常強。所以這是壹個特別值得單獨點出來的方向。更具體壹點說，每當我們做研究項目，需要修改神經網絡架構，或者重新思考服務方式，比如怎樣把鍵值緩存做得更好，類似這樣的事情，整個技術棧上的人都必須有能力把這些新方法高效地實現出來。
而所有這些變化的核心循環，本質上都是在制造能夠在大規模場景下運行的軟件系統：它要有高吞吐、低延遲。這其實是壹類非常基礎的工作，和傳統後端工程的思維是緊密相連的。所以我覺得，這對很多人來說都是壹個非常開放、非常值得專攻的方向。
主持人：我有些朋友在 OpenAI 和 Anthropic 工作，他們跟我說，那邊會區分偏應用的組織 and 偏研究的組織。我想知道 Google DeepMind 裡是不是也有類似區分？如果有的話，你能不能講講這兩者的差別？
Vlad：我們內部確實有不同的重點方向。比如在 Google DeepMind，就有團隊專門研究怎樣用 Gemini 這樣的語言模型，更好地改進搜索結果。從某種意義上講，這可以算是語言模型的壹種應用化方向。
但我其實不太願意把這種區分畫得特別死，因為把模型整合進真實產品，本身就需要很多非常硬核的研究工作。就拿我剛才說的那個例子來說，為了讓模型真正服務搜索，你得投入大量精力，確保模型回答的是事實，能引用來源，能給出非常精確、非常有依據的答案。
你還得評估這些來源本身的質量，確保它不是諷刺、不是玩笑、不是不可靠的信息。我覺得這恰恰說明，即便是在非常面向產品、非常“應用化”的人工智能方向裡，你其實仍然是在做研究。
當然，另壹方面，也確實存在那種更經典意義上的語言模型研究團隊，比如做預訓練、做後訓練。這些在 Google DeepMind 內部依然是比較獨立的團隊，目標就是打造業內最先進的模型。
也就是更純粹意義上的研究。不過我還是要補壹句：我們做的“純研究”之所以有意義，前提是它最後能被真正實現出來。所以我們既要負責把模型交付出來，確保訓練穩定推進，某種程度上像訓練任務的運維工程師壹樣，盯著整個訓練過程別出問題；同時我們也要負責提出訓練這些模型的方法配方。
這兩個角色根本分不開，必須同時承擔。所以我覺得，你當然可以把研究和應用看成壹條連續的光譜，但在今天這個時代，不管你站在哪壹側，最後都得能在這條光譜上自由切換。
主持人：我注意到還有另壹條光譜，就是軟件工程師到純人工智能研究員。你怎麼看這條光譜？軟件工程和人工智能研究之間，到底差別在哪？
Vlad：如果從我自己的經歷出發，我會說，我們做的很多事情，以及我們提出的很多新方法，它們真正的基礎其實是基礎設施層面的投入。
我可以稍後更詳細講講我團隊在做什麼，但先拿“蒸餾”舉個例子。所謂蒸餾，本質上是壹種知識遷移方式。你可以把它理解成：教師模型先在底層數據上提煉出某種統計信息，再把這些信息傳給學生模型，讓學生模型比完全沒見過這些額外信息時表現得更好。
但如果你說的是壹個超大語言模型，而且處理的是數萬億級別的詞元，這背後對應的計算投入就是極其驚人的，可能是數百萬、數千萬美元的算力成本。
這就意味著，你必須認真思考怎麼把整個系統優化到極致。因為你做的每壹個操作，都會被放大到極其巨大的規模：每壹秒都重要，每壹個字節的存儲都重要。
而這裡面很大壹部分工作，說到底就是非常傳統的軟件工程。尤其是蒸餾基礎設施，到現在大概已經經歷了叁到肆代演化。每壹代裡，我們都會退後壹步，重新審視當前在蒸餾研究中到底用了哪些方法，再從整體上想：我們的基礎設施該怎樣擴展，才能支持更廣泛的研究。
而且確實有幾個很明確的節點：你壹旦重新思考蒸餾系統的設計方式，蒸餾方法的研究速度就會明顯加快。
所以這其實是壹種非常典型的投入：你可能花肆個月時間重寫蒸餾基礎設施，最後換來的，是對蒸餾縮放規律的全新認識，而這種認識又會反過來轉化成非常強的模型表現。
所以它真的要求你跨越整個技術棧去工作。我幾乎無法想象，如果沒有這些蒸餾基礎設施層面的投入，我們能做出 Flash 3.0 那樣的結果。歸根到底，這些東西壹開始都來自壹份非常老派的設計文檔：你得想清楚，生成教師統計信息時，什麼樣的抽象才是對的；這些信息該存進什麼樣的存儲系統；在這種規模下，跨多個數據中心讀寫數據時，底層該如何支撐。
這些其實都是非常經典的分布式系統問題，不是嗎？
研究不是壹條直線，它更像在霧裡走圖
主持人：對，我也是這個意思。聽起來在現在這種計算規模下，確實有很多軟件工程、後端基礎設施類的問題。但我還是覺得，在那條光譜上的某個位置，應該會出現壹個真正的躍遷——需要壹些全新的能力。比如說，你把壹個普通後端工程師直接丟去改模型架構，這顯然和做基礎設施又不是壹個量級的跳躍。
你怎麼看這個區別？
Vlad：對，我覺得確實有這樣壹個分界點。研究這件事，本質上是壹種高風險、高回報的活動。我們常會說壹個詞，叫“研究品味”，也就是壹種高層次的直覺：在壹個項目裡，你面對很多不同的裡程碑和可能路徑時，到底應該沿著哪條路往前走。
從某種意義上說，軟件工程項目也可以被看成類似的壹張有向圖：你有壹堆中間產物要完成，最終才能到達目標。
但軟件工程裡的這張圖，整體上更接近確定性的。你先搭壹個服務，再搭另壹個服務，再搭第叁個服務；先把存儲層搞定，再處理上層功能。你大體可以穩定地壹路往前推進。
研究就不是這樣。研究裡的這張圖是帶隨機性的。因為其中壹些節點——比如某個研究想法，或者到達最終目標所必需的某個環節——並不保證能成功。
我覺得這要求壹種思維方式上的轉變。而這種轉變需要時間去學，也需要壹些專門培養出來的能力。這就是很多人在博士階段逐漸建立起來的那種東西。
如果要我用壹句比較簡潔的話來概括，我會想到 Jacob Steinhardt 教授的壹篇非常出色的文章。我很喜歡用他的框架來理解自己做的研究：研究是壹種馬爾可夫決策過程。
所謂馬爾可夫決策過程，指的是：在壹個研究項目裡，不同裡程碑之間存在壹張帶有隨機性的依賴圖。你可能必須先拿到某種結果，或者先證明某種結論，才能到達後面的目標。
類似地，在壹個機器學習研究項目裡，你可能得先把某種特征方案跑通，之後才有機會獲得某種圖像識別准確率，圖上的節點和路徑都會不斷展開。
這是壹種高度不確定的探索活動：某些方法可能有效，也可能無效；而壹種方法壹旦有效，又會為你打開壹組新的可能性。
在軟件工程裡，你也許可以把所有通往目標的路徑都列出來，然後問：最短路徑是什麼？
但研究裡，這種方法並不最優。因為壹旦圖上的邊不再可靠，有些節點甚至你還根本不知道——也許它們是隱藏的——那你處理問題的方式就必須改變。
具體來說，你必須同時考慮不同研究方向的成功率和時間投入，還得事先對這些概率做出估計。
而這和給壹個軟件項目寫設計方案，是完全不同的壹種思維活動。你得培養出壹種直覺：在你還沒真正做壹件事之前，先判斷它成功的可能性有多大。
很多人把這種能力和“研究品味”聯系起來，我覺得這是對的。因為你如果想真正穿行於這種研究過程裡，這種判斷力就是必須建立起來的核心能力。
主持人：聽起來你的意思是，研究裡有更多的不確定性。我還是想更具體壹點去理解這種工作的性質。如果你把壹個後端工程師扔進壹個做研究的團隊裡，具體會在哪些地方出現明顯短板？
Vlad：我第壹個想到的，就是你是否具備足夠的研究背景，足夠理解自己所處的研究版圖。
研究工作很大程度上要求你有壹種很謙遜的心態：你得承認，在你之前，這個方向已經有了大量投入；而在你真正了解這個主題上全人類目前最前沿的積累之前，你大概率不可能繼續把這個前沿往前推。
所以，在某個具體方向上建立扎實的已有工作認識，並真正做好相關文獻梳理，可能就是很多人最先會卡住的地方。你得有能力沿著壹個主題的引用脈絡壹路追下去，知道該讀什麼、怎麼讀。
因為你根本沒時間把所有論文都讀完，所以你必須培養壹種判斷力：哪些論文最值得讀？在不閱讀全文的情況下，怎麼判斷壹篇論文到底值不值得投入時間？
這是我最先想到的壹項必須建立起來的能力。
而且，光是要看懂這些研究級論文，你本身就得具備機器學習和計算機科學背景。再進壹步，還要看論文屬於哪個領域、講什麼內容；有些論文背後需要的數學基礎和課程訓練都很重，沒有這些前置知識，你根本不可能真正理解它的方法。
這件事非常重要，因為如果你不了解現有的方法論是什麼，你幾乎不可能在它的基礎上做出改進。
比如我前面提到，我們團隊做蒸餾。如果你想推進大語言模型蒸餾方向上的理解，你首先得很好地理解我們到底想用大語言模型去做什麼。
我簡單概括壹下：大語言模型研究，尤其在預訓練階段，核心就是縮放規律。
什麼叫縮放規律？很多人會特別關注它是不是冪律、指數是多少，但真正重要的其實不是函數形式本身。真正重要的是：對於壹套擴大語言模型的方法，當你不斷往壹次預訓練裡投入更多計算量時，你必須能夠預測，這個語言模型最終的測試損失會落在什麼位置。
為什麼這個問題重要？為什麼我們要預測模型的泛化誤差？
在傳統機器學習世界裡，比如說我們做圖像識別，打 ImageNet，你的測試損失就是那壹千個類別上的分類錯誤率。你提出壹個網絡結構，比如 VGG 或 ResNet，訓練壹下，再看它的分類錯誤率是多少，這就能估計這個模型在這類任務上的表現。
我們還可以通過驗證集來估計方法好不好。每當出現壹個新的網絡結構想法，我們訓練壹下，做壹系列驗證實驗，得到交叉驗證誤差，而這個誤差本身就是對最終測試誤差的估計。於是你就可以通過這個流程不斷迭代不同想法。
但大語言模型不是這樣。因為每壹次真正做預訓練，你投入的計算量都會比之前任何壹次都更大。
所以從某種意義上說，它像是壹個“壹次性”的 ImageNet 問題。你永遠沒有機會先完整地看壹遍真正的 ImageNet，再慢慢調。你只能先在 MNIST 上練，再到 CIFAR 上練，然後試圖根據這些經驗，設計壹種辦法，希望它第壹次上 ImageNet 就能直接奏效。
如果你真這麼做——我相信很多人都試過，我自己當年學這些東西的時候也壹樣——你會發現，它在 MNIST 上很好，在 CIFAR 上可能也不錯，但壹到 ImageNet 就突然崩掉。
你會慢慢意識到，很多東西並不會隨著規模自然泛化。
所以，我們在大語言模型裡做的大量工作，其實是在設計“配方”。所謂配方，就是壹個函數：輸入是你願意投入多少計算量，輸出是壹整套語言模型訓練流程。
如果你能把這套配方和壹種預測規則結合起來，而且這個預測規則能夠准確預測最終效果，那你就可以據此做決策，去改進你的訓練配方。
我剛剛這壹大段，其實是在給大語言模型研究的基本面貌提供背景。但這種理解之所以存在，是建立在大量早期語言模型縮放研究之上的，比如 Kaplan 的論文，比如 Chinchilla。
自從那兩篇論文之後，又有很多工作開始研究：除了參數量和訓練詞元數，究竟還有什麼因素會影響預測准確性，比如不同詞元的獨特數量等等。
但我會說，這兩篇論文對大語言模型來說都是基礎性文獻；而它們本身又建立在更長的壹條縮放研究脈絡之上，可以壹直追溯到最早期的 GPT。Google 這邊也通過 PaLM 系列論文積累了大量這方面的研究。
這些工作共同塑造了我前面描述的那種視角。而這種視角，基本上只有你自己親自沿著那條文獻線索走過壹遍，才會真正建立起來。
主持人：假設你要給自己的團隊選人，而你判斷壹個人是否適合幫助你推進前沿的標准，是他對前沿本身的理解，包括對已有文獻的掌握，而這又要求很多前置能力。我記得你在文章裡把其中壹部分叫作“數學成熟度”。
Vlad：對。我覺得，壹旦你具備了數學成熟度，理解這些論文、讀懂這些論文，其實並不難。
我剛才提到的那些論文，現在基本都已經算是入門門檻了，所以如果是候選人，我默認他們應該熟悉這些內容。
但更壹般地說，關鍵能力在於：你能不能鑽進這種級別的論文裡，把它真正讀懂；你能不能把論文裡的研究想法自己實現出來。這是壹項非常重要的能力。
我們會看到各種各樣的想法，它們未必都能直接應用到我們的領域。但如果你能深入理解它們，你就可以在這些想法上繼續迭代，並把它們改造到我們的應用場景裡。
所以當我們評估壹個人是否能處理這些機器學習論文中的數學概念時，這大概就是最關鍵的能力信號。它說明你能拿起壹篇陌生論文，判斷其中哪些想法可以遷移到 Google 的實際環境裡。
真正值錢的能力，常常在系統最底層
主持人：這肯定不是壹份窮盡清單，但我還是很好奇：還有哪些領域，是人們可以去深入鑽研、而且對前沿人工智能研究確實重要的？你提到了蒸餾，也提到了內核。聽起來內核幾乎在哪都很有用，但除了這些之外，還有沒有什麼你會順手列出來的方向？
Vlad：我覺得壹個非常有力量的方向，其實是編程語言研究。
因為如果我們能在編程語言層面創造出更好的抽象，就能極大促進內核開發。我覺得 ThunderKittens 就是壹個很好的例子。它提供了壹種抽象方式，讓你寫內核的時候，只需要圍繞肆個函數工作，而不是去面對壹大團隨意拼起來的 C 代碼。這樣壹來，你在開發那些能夠充分利用硬件的算法時，速度就會快得多。
這時候重點已經不只是編程語言研究本身，而是你是否對這種抽象充滿興趣，並願意和那些關注底層硬件的人壹起工作，比如去嘗試 CuTe 這類領域專用語言。
這類方向裡有很多都是圍繞特定硬件設計的專用語言。
除了編程語言和縮放規律相關文獻之外，我還會想到強化學習文獻。
特別是自從“基於人類反饋的強化學習”出現之後，我們已經看到像 PPO 這樣的深度強化學習算法，確實可以進入生產系統。曾經有壹段時間，這件事到底成不成立，其實還是有爭議的；但現在幾乎已經形成共識：這些算法確實會被應用在真實的生產環境裡。
而想理解它背後的理論，你通常得從強化學習的基礎壹路往上學，再走到今天非常豐富的各種價值型方法和策略梯度方法。
這是另壹個我覺得文獻脈絡極其豐富、非常值得慢慢爬進去的方向。
再往“後端工程師”壹點的方向說，除了內核本身之外，我覺得分布式系統和優化之間，還有壹個非常有意思的交叉地帶。比如：如何設計神經網絡訓練算法，讓它能在大量圖形處理器上訓練——這裡面會有很多有趣的問題：異步性、梯度的新鮮度、流水線方式會怎樣加劇梯度陳舊，等等。
你在訓練算法設計裡做出的這些系統性選擇，都會影響神經網絡的收斂情況和最終質量。
這些問題其實就算脫離大語言模型場景，也可以單獨研究，而且已經被研究很久了。所以如果你更偏基礎設施方向，那我會說，先把這些算法是怎麼運作的弄明白，會是壹個非常好的起點。
主持人：你覺得不同前沿實驗室之間，對人的要求會有差別嗎？比如說，如果有人想去 Google DeepMind，是不是會有某個方向比 Anthropic 更受重視？至少從技能組合上看，我感覺應該還是挺接近的。
Vlad：對，我覺得不同實驗室可能會在商業策略上有所差別，提供的產品和服務也會因為各自的專長和客戶類型不同而不壹樣。
但如果問大家真正看重什麼，我認為實驗室之間重疊其實非常大。我那篇文章發出去以後，你會看到 OpenAI 和 Anthropic 的人也在說：對，這些建議我們也認同。
所以我覺得，這至少算壹個小小的證據，說明大家在這件事上其實非常接近。
主持人：我覺得很多人之所以特別想往人工智能研究靠近，是因為他們在想：未來軟件工程也許沒那麼重要了。那研究這邊會不會也有類似問題——大語言模型以後會不會也把很多研究工作接過去？所以人工智能研究未必就比軟件工程更值得押注。
Vlad：我覺得研究能力只會越來越重要。
能夠處理工作規劃裡那些不確定、隨機的成分，會越來越成為我們工作的核心部分。你要學會怎麼在你做的任何事情裡利用人工智能——而且這件事甚至不必局限於軟件——這種能力應該立刻開始練，因為這些系統本來就不是確定性的。
你真正要思考的是：我怎樣圍繞這些大語言模型搭系統，讓自己把工作做得更有效？未來真正能把你和別人區分開的，就是這種能力。我覺得不管你具體做什麼，這壹點都成立。
坦白說，現在到處都是恐懼營銷。尤其有些人在談人工智能的時候，本來就在故意制造這種恐慌。我的感覺是，人們真正應該做的，是把注意力放回自己身上，想辦法讓自己變得更高效。
我並不認為人工智能會取代我們所有人的工作。原因在於，人類在組織裡承擔的壹個關鍵角色，是構成壹張信任網絡。組織本身就是壹組資源和壹群人，而這群人負責管理這些資源。
我們的壹項重要職責，就是把這些資源分配到特定目標上。
就算人工智能能大幅加快執行速度，關於資源如何分配的決定，最終還是必須落到具體的人身上。這件事永遠要有人負責。因為你不能把責任推給人工智能。
比如說，現在的大語言模型已經非常懂法律了，它可以幫你審合同之類的；但它不能代表你出庭，因為它不可能被吊銷律師執照。
我覺得這就是壹個非常尖銳的例子，說明為什麼法律職業依然會存在：即便大語言模型很擅長調用先例、理解法理，你還是需要壹個能為結果負責的人，去驗證人工智能的輸出，用人工智能來更高效地完成法律工作，而不是把自己的法律辯護整個交給壹個語言模型。
別被恐懼營銷帶著走
主持人：對，我覺得當初促使你寫那篇文章的原因，其實也正是這種恐懼氣氛。
Vlad：對。我真的覺得，人們應該擁有的是壹種更建設性的心態。
我之前看到壹條推文，好像是 Deedy 發的，裡面是那種很長的恐慌敘事，說什麼人工智能會制造壹個永久性的底層階級之類的。人很容易被卷進去。
但我覺得真正該想的是：我們每個人都對自己的未來擁有主動權。今天就可以開始投資那些對明天有意義的能力。這才是唯壹真正該做的事。光擔心，什麼也改變不了。
所以我想寫那篇文章，也是為了回應這壹點。因為我確實感覺到，這種情緒壹直在擴散。前陣子我去普林斯頓做講座，現場壹個很大的問題就是：我怎樣才能去 Google DeepMind 工作？
而且這幾乎就是大家知道我在做什麼之後，最常問我的問題。
所以我想，也許給出壹些更具建設性的方向，會對整個討論更有幫助。
主持人：關於那篇文章最後還有壹個問題。因為如果你想拿到壹個崗位，當然壹方面是能力本身，我們前面聊了很多你的能力是否匹配這個崗位；但另壹方面，其實還有“信號”——你如何向外界展示自己，以及什麼樣的信號是被看重的。
如果你要把自己推給這些前沿實驗室，什麼樣的信號最重要？
Vlad：最重要的是，拿出真實證據，證明你沿著這些方向做出過對別人有用的東西。比如內核開發。
現在已經有很多開源大語言模型了，你完全可以拿其中任何壹個來做優化。你甚至不壹定要把模型本身做得更強。很多場景下，只要你能證明：在某個設定裡，我把這個地方做快了，把那個地方做順了，這就已經很有價值了。
而且事情也不只是在圖形處理器上加速模型推理。圍繞大語言模型的服務棧，本身就是壹個非常復雜的分布式系統。它要維護鍵值緩存，還要處理各種負載均衡、請求排隊——這些都是後端服務裡再常見不過的問題。
這些項目壹直都需要幫助。所以像給 vLLM、SGLang 這種項目做貢獻，或者基於 TensorRT 做壹些實踐展示，都會很有價值。TensorRT 那邊我記得還有個分布式系統叫 Dynamo，它支持把推理服務拆分部署。你如果能展示自己基於這些組件做了項目，或者真正改進了這些組件——
對我來說，這會是非常強的候選人信號；同時我也覺得，這會是對開源社區非常受歡迎的貢獻。
主持人：還有壹點，我們前面很多討論都默認了壹條路徑：從外部跳進前沿實驗室。
但其實這些實驗室背後往往都有很大的組織體系，很多團隊並不是直接做最前沿研究的。比如在 Google 體系裡，有些基礎設施工程師可能本來在搜索團隊工作，有很強的後端能力，但領域背景沒那麼深，然後他們想內部轉到 Google DeepMind。
在這種內部轉崗的情況下，你的建議會和外部候選人不壹樣嗎？
Vlad：我以前在搜索那邊有壹位合作很緊密的同事，後來真的轉到了我團隊，叫 Nate Lintz。他非常厲害，現在在我們團隊裡負責了很多核心工作，特別是在 Flash 和 Flash-Lite 的推理協同設計方面。
我覺得他就是壹個很好的例子。他當時的思路是：我怎樣才能幫助自己所在的產品線，盡可能有效地采用這項技術？
所以我會說，如果你所在的組織不是直接造模型的，而是試圖利用這些模型，那這裡面其實有壹個很大的空白：如何真正把這些大語言模型高效地應用到你的組織裡，如何高效地把它們服務起來。
如果你能成為那個把這件事做得特別好的人，這不僅會給你的團隊創造巨大的業務價值——這顯然會讓你在本組織裡脫穎而出——同時，你也會自然而然成為我們研究團隊在對接產品落地時最重要的合作方之壹。因為我們會需要和你這樣的人協作，確保模型能在你們組織裡真正發揮作用。
所以到了那壹步，你也許會想轉崗，也許不會。你如果想轉，我們當然很歡迎。
但即便你不轉，其實你已經在做壹件非常前沿的事情了：把這種新技術整合進真實產品，讓真實用戶去使用。
所以，對這種情況，我的建議大體就是這樣。
先做出東西來，信號自然會出現
主持人：在那篇文章快結束的時候，作為收尾，你還發出了壹個很具體的邀請，因為我知道你當時在招人。要不要把那段再講壹下？
Vlad：對，我當時是在想：我怎麼才能真正做到“說到做到”？怎麼證明我不是只在嘴上說這些能力重要，而是真的願意按這個標准去看人？
我想表達的是：如果你能通過壹些具體練習，證明自己至少在我強調的那些能力上已經有了壹些初步證據——比如意圖、數學成熟度、韌性——那我願意認真看。
所以我列了幾項練習：有些是為了展示你對縮放規律已經有初步理解；有些是要你在工程層面願意深入細節，真正親手實現壹個 Transformer；還有壹些則是展示你願意掌握我們每天都會用到的那些基本數學，用來估算和設計這些大語言模型。
我現在已經記不清完整的練習清單了，但如果你把《縮放之書》裡的題目認真手寫做完，錄壹段自己講解過程的視頻，再加上我文章裡提到的 Transformer 練習，把這些都發給我——
那就是非常有力的東西。如果你能在紐約辦公室工作，我會非常願意面試你。
確實已經有不少人因此聯系我了。我其實已經收到過幾份提交，現在也已經在推進其中壹些人的面試流程。
所以，這件事工作量當然不小。但讓我很驚訝的是，我大概在文章發出後壹周內，就收到了回應。說明這件事確實是做得到的。
當然，我的招聘名額不是無限的，所以這個邀請雖然有效，但我也不可能招無限多人。
不過好的壹點是：這本身就是壹種非常強的自我成長信號。所以，不管你最後會不會因此去 Google DeepMind，這些事情都值得你為了自己去做。
而且我覺得，它也會幫助你准備去其他地方面試。
當然，如果你真的完成了這些練習之後聯系我，即便我這邊已經招滿了，我也認識很多其他正在招人的人，我也很樂意幫忙推薦。
真正有意思的，是把模型做對，也把硬件吃滿
主持人：接下來換個話題。我看到你是 Gemini 預訓練方向的負責人，我覺得挺有意思的，很想聽你從自己的角度高層次講講：在你看來，預訓練到底是什麼？以及這個方向上最重要的挑戰有哪些？
Vlad：可以。
作為預訓練方向的負責人，我們要做的事情其實很多。
我團隊負責交付的具體產品，包括 Flash 模型和 Flash-Lite 模型。這些模型會被用在搜索裡的 AI 概覽 and AI 模式上，也包括壹些供其他組織內部使用的壹方模型，比如廣告 and YouTube。
除此之外，我們還是 Google and Apple 合作中的關鍵技術負責人之壹，所以也會做那邊的技術工作。
這些是我團隊承擔的產品層面交付。
再往上，我們還要做研究，確保這些交付本身處在業界最先進水平。同時，我們也做壹些更通用的預訓練研究，再反過來貢獻給 Pro 系列模型。
如果從研究性質來分，我會說大體可以分成叁個方向。
第壹是前面提到過的蒸餾。
第贰是我喜歡稱之為“推理協同設計”的東西。也就是：設計那些在推理時足夠高效的神經網絡架構。具體來說，就是決定網絡的拓撲結構，決定 Transformer 裡門控層和線性層的矩陣形狀，決定注意力機制的形狀、注意力頭數量，諸如此類。目標是讓這些設計在你實際部署的硬件上，能盡可能高效地運行。
第叁個支柱，是新的量化方法。量化壹直是我特別有感情、也從加入 Google 以來壹直在研究的方向。它實際上會改變前兩個方向能夠做到什麼，因此推進模型壓縮的最前沿，也就成了我們團隊研究中的重要組成部分。
壹般來說，量化指的是：在某種意義上減少神經網絡權重表示所占據的體積。
通常在訓練時，神經網絡裡的那些矩陣參數是用叁拾贰位浮點數來存儲的。
但事實證明，在實際計算中，你根本不需要那麼高的精度，模型質量依然可以保持得很好。用壹些並不算復雜的方法，就能把這些權重的存儲精度壓縮到肆位。
也就是說，本來叁拾贰位浮點數能表示壹大段數值范圍、達到大約柒位精度的東西，現在居然能以相當高的保真度，用肆位整數來表示——而肆位整數覆蓋的范圍其實非常小，大約只是從負八到柒。這本身已經像奇跡壹樣了。
但更神奇的是，你甚至還可以把類似的量化變換應用到神經網絡運行時的激活值上。
壹旦做到這壹點，實際做矩陣乘法時，參與運算的數就會比以前小得多，因此運行神經網絡所需的電力也會顯著下降。
有意思的是，人工智能硬件總運營成本裡，有百分之九拾九都來自驅動這些芯片所消耗的電力。如果你能把這些運算做得更便宜，神經網絡就能更廉價、更高效地運行。
這會直接幫助你處理更多請求，也會改善時延。
所以量化研究的核心問題就是：我們怎樣把前沿繼續往肆位之外推進？
主持人：我在推特上經常看到壹種說法，老在討論“模型浮點運算利用率”。對於不在這個行業裡的人，或者說不了解這個概念的人來說，他們壹看到那個數字只有拾幾個百分點，就會覺得：哇，這不是浪費了絕大多數圖形處理器資源嗎？
我想請你幫大家解釋壹下，為什麼看起來“低”的模型浮點運算利用率，其實壹點也不低。順便也請你解釋壹下它到底是什麼。
Vlad：對。所謂模型浮點運算利用率，本質上是這樣算的：把神經網絡實際完成的浮點運算次數，除以在這段請求時間裡，硬件加速器理論上本可以完成的總浮點運算次數。
所以從某種意義上講，這個指標告訴我們：在多大比例的時間裡，我們真正有效利用了這塊加速器的浮點運算能力。
如果你想達到百分之百的利用率，那意味著你必須把硬件裡的矩陣乘法單元壹直吃滿。
也就是說，它只能不停地在循環裡做矩陣乘法，不能去讀內存，也不能做任何別的操作。
但這種計算在現實裡沒什麼意義。神經網絡需要做激活函數，需要做注意力計算，需要把中間結果寫回高帶寬顯存。所有這些操作，都需要使用內存總線，或者向量處理單元。甚至有些數學操作，本來就是底層硬件裡比矩陣乘法慢得多的部分。
這些因素都會導致模型不可能壹直按處理器標稱峰值運行。
所以你之所以看不到百分之百的利用率，是因為神經網絡有壹部分時間在讀寫內存，另壹部分時間在做壹些天生就比矩陣乘法慢的操作。
我前面提到的推理協同設計，其實很大壹部分就是在協調芯片的各種能力：和其他芯片之間的通信、內存帶寬、從內存中讀取參數的速度、浮點運算能力——這裡既包括矩陣乘法，也包括向量運算，比如做激活函數。
這些能力在硬件上都有不同的速率，而任意壹種計算都不可能天然精確匹配硬件每壹類能力的最佳節奏。
在設計神經網絡時，你要做的是選出壹組結構形狀，讓這個網絡能盡可能同時吃滿這些硬件單元，從而在推理時把利用率盡量拉高。
而讓這件事不只是壹個代數題的原因在於：這些設計選擇最終會影響你訓練出來的神經網絡質量。
所以推理協同設計真正有意思的地方就在於：我們怎樣設計出壹種神經網絡架構，它既能穩定地隨規模擴大，又有好的質量預測，同時還能讓推理時的硬件利用率盡可能高。
這種聯合優化，正是推理協同設計最有趣的地方。
而且它還是個常青問題。因為隨著硬件變化，浮點運算、內存帶寬、通信帶寬之間的相對關系也會變化，而這又會改變“什麼樣的神經網絡形狀才是最優”的答案。
很多關鍵工作，並不光鮮
主持人：換個話題。Google 有壹種叫“即時獎金”的機制，就是有人可以因為你做得特別好，給你壹筆壹次性的獎金。我在你的履歷裡看到，Jeff Dean 這位傳奇人物曾經給過你即時獎金。
如果你願意講講那個故事的話，我很想聽。為什麼他會給你這個獎金？
Vlad：那其實發生在 Gemini 項目剛開始的時候。
Jeff 當時給了壹批參與 Bard 第壹版發布的人即時獎金。我在那個非常龐大的項目裡，其實只做了壹個很小的貢獻。我幫忙做了監督微調，參與了 Bard 最早幾個發布版本中的某壹版。
那段經歷給我最大的啟發是：在那個時候，我還只是 Google Brain 裡壹個純做研究的人，我當時非常執著於壹件事——怎麼盡量多發第壹作者論文到 NeurIPS、ICML、ICLR。
我非常清楚地記得，當時我腦子裡的第壹反應其實是：我是不是應該繼續低頭寫論文？
很幸運的是，那時我的經理 Rohan Anil 非常鼓勵我們都投入這個方向。對我來說，這正好給了我需要的推動力——讓我真的卷起袖子，去做很多超參數調優 and 工程工作，想辦法讓這個模型在壹些非常老的張量處理器上跑起來，好為監督微調多爭取壹些訓練機會。
那次很小的初步參與，後來得到了 Jeff Dean 的認可。我覺得它也進壹步推動了我在大語言模型方向上的投入，最終把我帶到了今天的位置。
所以我會說，這件事的重點並不在於，我當時那壹點監督微調工作對最初發布到底幫了多大忙。
更重要的是，它讓微觀的我認識到：想參與那些高價值項目，你往往需要投入很多並不光鮮的工作。可能只是超參數調優，只是為了讓程序塞進特定內存預算裡，不停去擠壓編譯器表現、摳那點空間。
但這些工作，都會服務於更大的業務目標。而這件事，對於進入真正重要的項目來說，非常關鍵。
主持人：你在 Gemini 上也做了很久了，而且這還是壹個最高優先級項目，所以你壹定經歷過壹些事故或者“戰爭故事”。我很好奇，你最喜歡的壹段 Gemini 故事是什麼？
Vlad：如果讓我選，我最喜歡的應該是 Flash 2.0。
那真的是壹段非常艱難、也非常漫長的旅程。但我們當時最核心的優化目標之壹，是延續 Flash 1.5 已經建立起來的那個定位：做壹種非常快、時延很低、但質量依然很強的模型。
尤其是它必須快，因為搜索需要它在 AI 模式裡非常迅速地返回回答。
正因為如此，在 Flash 1 的時候，雖然我們已經知道混合專家模型，也知道它可以顯著提升容量，但當時壹個很現實的問題是：我們當然想用這種新架構，可你很難直接切過去。
因為混合專家模型的特點之壹就是參數通常更多。而參數壹多，就會占用更多高帶寬顯存。可我們部署所用的這些芯片，高帶寬顯存是有限的。
所以你就必須把這個混合專家模型切分到多塊芯片上。假設你有 N 個專家模塊，那你可能得把它們分布到 N 塊芯片上，或者按某個和 N 相關的比例分布。
這樣壹來，模型中間就會出現大量通信。當壹個詞元需要被路由到某個專家模塊，而這個詞元原本在第壹塊張量處理器上，卻必須送到最後壹塊去處理——你就在前向傳播過程中引入了巨大的通信量。
而這個操作的時延會隨著 N 的增加而急劇變大。混合專家模型的難點就在於，它會把 N 推得很高。這就成了壹個非常嚴重的瓶頸。
有意思的是，我們其實很早就知道流水線式服務這個思路。只是對稠密模型來說，它壹直沒有真正重要到必須采用。
我很清楚地記得，自己很早曾和 Sholto 聊過這個事。Sholto 當時說：對啊，你這裡主要受限於浮點運算量，所以做流水線並不會改變輸入預填階段的性能曲線。
後來證明他是對的。我試了壹下，然後就把這個想法擱置了。
但有意思的是，當時我團隊很小，我手下的壹位同事 Geng Yan 提出了壹個非常好的想法。他當時和 Rahul Arya 以及 Google 以色列團隊的幾位同事合作，提出把流水線式預填應用到混合專家模型上。
所謂流水線，就是說你不再把那 N 台機器並行地分給同壹層裡的 N 個專家模塊，而是把不同的層分配到不同機器上。
也就是說，不再是在某壹層裡把詞元在各台機器之間來回路由；而是某壹層的機器先處理你預填請求中的壹部分詞元，再把這些處理過的詞元傳給下壹台機器，讓它處理第贰層，再傳給第叁層、第肆層。
這樣壹來，所有專家模塊都可以常駐在單台機器上，或者更少數幾台機器上。它本質上改變了通信模式：從原來那種每壹層都要做大量詞元交換，變成了壹種可以被其他計算掩蓋掉的通信方式。
因為你可以把流水線式預填分攤到請求的不同部分。比如第贰層在處理請求前壹千個詞元時，第壹層所在的第壹台芯片已經可以開始處理第贰個壹千詞元了。
所以，這其實是壹種打破高帶寬顯存約束的方法：不是把專家模塊在機器之間搬來搬去，而是把網絡層分布到不同機器上。
正因為如此，通信開銷降下來了，混合專家模型的時延突然就變得非常有吸引力。
Gemini 2.0 的技術報告裡寫得很清楚：它是壹整個混合專家系列模型。而使這件事成為可能的原因之壹，就是這種推理階段的服務創新。
Dwarkesh and Reiner 有壹篇非常棒的文章，專門講這個優化，而且你甚至可以把它寫進《縮放之書》的代數框架裡去理解。
這也是壹個很好的例子，說明這種看似局部的改動，實際上會對大語言模型質量產生多麼巨大的影響。
真正讓 Flash 2.0 那段經歷如此有成就感的，是這個重大的混合專家決策。它在當時聽起來像個小技術選擇，但大家真的非常擔心：這個模型的時延到底能不能壓到合理范圍。
好在我最後推動了壹套非常透明的技術決策流程，把問題徹底查明了。最後我們做出了正確的判斷。
可接下來還得訓練它。
這是壹個在 Flash 這個規模上，我們訓練過的最大模型。我們知道這是對的方向，但接下來的肆拾天會是極其艱苦的過程，而且團隊非常小。
負責這次訓練輪班的人，可能只有伍個左右。我記得我們幾乎是壹天接壹天地交接，輪流做這種運維式工作：想辦法讓訓練任務壹直活著。因為在當時，這真的是壹個非常需要人工盯著的過程——你得確保所有東西都穩定推進，確保數據迭代器調好了，不會拖慢任務；如果數據裡有空洞、索引有問題，你必須立刻修補，因為每壹分鍾都在燒掉巨量算力。
主持人：那夜裡和周末怎麼辦？
Vlad：對，所以那肆拾天裡，我們基本沒怎麼睡。
我們必須在巴黎辦公室 and 山景城之間做雙班倒。
而讓這壹切最終變得特別值得的，是模型發布的時候，差不多正好趕上 DeepSeek-V3 出來。那時《華爾街日報》發了壹篇很誇張的“紅色恐慌”式文章，講什麼中國要靠開源模型接管人工智能之類的。
我記得我朋友給我發來壹張截圖，是大模型競技場排行榜的壹張表。最右上角是 ChatGPT，DeepSeek 緊隨其後。然後文章還在說，DeepSeek 只花了幾百萬美元訓練，就已經追得那麼緊。
我朋友就跟我說：哦，Gemini 落後太多了。因為那張表最底下放的是壹個我記得像 Flash 1.5 Pro 之類的版本。
然後我壹看，心想：這挺有意思的。我剛好壹直在看這個排行榜，因為我們剛發了壹個模型，而網站上的實際情況顯然不是那樣。
後來才發現，《華爾街日報》那篇文章裡把壹些行給省略掉了。所以如果你今天再回去看那篇文章，你就會看到，當時真正處在業界最前沿的模型——Flash 2.0 Thinking——其實在表格的右上角，遠遠領先於 DeepSeek-V3。這多少會讓他們當時想講的那個“開源壓倒壹切”的敘事不那麼成立。
但對我們團隊來說，那確實是壹次非常重要的成就。
做那個別人真心希望他成功的人
主持人：最後壹個問題。如果你可以回到自己剛大學畢業的時候，大概就是本科畢業那會兒，然後給那個時候的自己壹些建議——以現在的你所知道的這些東西——你會說什麼？
Vlad：你得去追那些這個世界今天真正面對的問題。去追那些人們在日常生活中真正遇到的挑戰。不要害怕自己切進去的只是這個問題裡較小的壹部分，或者聽起來沒那麼體面的那壹部分。
即便它不是那種“很高級”的研究、數學之類的東西，也沒關系。你要相信，只要你是在做重要的事，哪怕只是壹個更大項目裡的較小組成部分，你最終也會看到，真正推動前沿往前走的，到底是什麼。
我想，這裡面需要壹種面對問題時的謙遜。你真正該追求的是這個。
如果再說另壹條建議，也許更偏職業層面壹點，那就是：成為那種別人願意看到他成功的同事。
我的意思是，大家總會談什麼“職場精神病”、馬基雅維利式領導者，或者那種為了結果不惜壹切代價的人。他們也許能通過壓榨別人，換來壹些短期收益。
但這麼多年和各種樣的人共事下來，我覺得最有意思的是：我見過極少數那樣的人——其中有壹位特別親近，是我的朋友 and 導師 Todd Lipkin，也是最早帶我進入計算機科學的人——他們非常善良，而且你能從他們身上學到很多。你會真心覺得：我願意跟著這個人壹起做事，也願意幫助他成功。
特別是，如果你是那種能幫助別人把項目做成的人，能提出壹些項目，讓別人可以用自己的互補能力在其中發光的人，大家會注意到這壹點。將來他們也會更願意參與到你提出的項目裡，也會更願意支持你。
很多人壹想到職場互動，就會變得很犬儒，總想著博弈，想著怎麼占優。
但我的經驗是，這種更友好、更合作的方式，往往會培養出壹種很深的協作感 and 互相幫助的意願。而要把那些需要多人、多種能力共同跨線的大項目真正做成，這種東西太重要了。
所以，如果我能給更早版本的自己壹點人際層面、職業層面的建議，那就是：去做那種人。做那個別人會真心希望你成功的人。
主持人：我很喜歡這番建議，因為它正好對抗了那種很犬儒的建議。我也很喜歡，你最初那篇文章本身，就是在對抗那種“末日論”“永久底層階級”式的說法。非常感謝你今天抽時間來聊。真的很有意思，也非常感謝你。
Vlad：謝謝你邀請我，Ryan。
[物價飛漲的時候 這樣省錢購物很爽]
還沒人說話啊，我想來說幾句
Google DeepMind 的 Gemini 預訓練主管 Vlad Feinberg，最近在壹檔播客裡聊了聊他的日常。
在大眾的想象中，頂尖實驗室的研究員每天都在推導顛覆性的算法。但 Vlad 說，他職業生涯最重要的壹筆獎金，是谷歌傳奇人物 Jeff Dean 親手發給他的——當時他剛入職 Google Brain，沒有像當年同樣在谷歌的 Transformer 作者們壹樣，去寫那些能發到頂級會議上的第壹作者論文，而是默默幹了幾天最髒的活：調整編譯器和超參數，解決顯存溢出，把壹個叫 SFT 的微調任務塞進了壹堆老舊的 TPU 卡裡，這才讓第壹代 Bard 勉強跑通。
這種“幹髒活”的工程體驗，才是這輪大模型競爭最真實的樣子。Gemini 2.0 出來的時候，外界都在贊歎它作為壹個 MoE 模型有多神奇。但 Vlad 透露，背後其實只有 5 個人在頂著。
算力卡隨時會掛，數據索引隨時會斷，為了不白白浪費幾百萬美元的算力費，他們只能在硅谷和巴黎兩個大區之間 24 小時倒班，不眠不休地死磕了 40 天。甚至在 DeepSeek-V3 爆紅、華爾街日報制作表格拉踩谷歌已經落後時，Vlad 也是哭笑不得——媒體為了制造爆款新聞，在表格裡故意刪掉了（elided）排名其實高居第壹的 Gemini 2.0 Flash Thinking。
對於甚囂塵上的“程序員要失業”的恐慌，這位主管給出了壹個很幹脆的觀點：AI 永遠無法被“吊銷律師執照”，因為它不具備主體資格，無法承擔法律責任，所以人類永遠要為它的產出簽字並背書。
他的組裡有壹個叫 Nate Lintz 的普通工程師，之前在搜索部門寫後端基礎架構，就是靠著在業務裡幫大模型落地，解決最具體的推理開銷，最終內部轉崗到 DeepMind 成了技術支柱。
如果你也想去，Vlad 在他的博客裡放了壹個“硬核作業”（手寫壹個 Transformer 並手算 Scaling Laws 錄成視頻發給他），做完了他直接面你。以下是這次談話裡，他聊到的幾個極其真實的行業細節：
法律大模型可以背下所有判例，但它不能代表你出庭，因為它無法被“吊銷執照”。職業的底層邏輯是責任和信任的分配。因為 AI 無法承擔法律後果，代碼的終點永遠需要壹個具體的人來簽字、背書並承擔責任。這才是程序員不會被替代的終極底線。
寫再牛逼的學術論文，都不如幫團隊省下幾張卡的顯存。很多眼高手低的程序員在 AI 時代迷失在理論和框架中。但在研發壹線，最容易拿獎金的能力，是那些不體面的“重體力活”——優化編譯器、調試超參、在有限的芯片裡榨出最後壹絲算力。這種扎實的工程能力，才是跨越周期的硬通貨。
寫搜索基礎架構的普通碼農，也是能壹步步逆襲進 DeepMind 的。團隊核心成員 Nate Lintz 曾只是壹個寫後端搜索的普通工程師，他沒有高大上的 AI 背景，但通過在組內幫產品落地 LLM，默默解決大模型在搜索業務裡最頭疼的推理和算力開銷，在實戰中摸清了底層架構，最終順理成章地轉崗進入 DeepMind 並主導了核心推理設計。
華爾街日報為了拉踩谷歌，在對比 DeepSeek 時故意在表格裡刪掉了排名第壹的 Gemini 模型。當媒體為了制造“中國開源超越美國大廠”的新聞而興奮時，他們有意隱去了當時在 LMSYS 榜單上高居榜首的 Gemini 2.0 Flash Thinking。真實的技術對決背後沒有神話，只有 5 個工程師在硅谷和巴黎 24 小時倒班、死磕 40 天的硬撐。
你沒法把研究和落地分成兩種人
主持人：你寫過壹篇題為《如何進入前沿實驗室工作》的文章。現在前沿實驗室最需要的，到底是什麼樣的能力？也許我們可以先聊聊，這類工作的整體輪廓是什麼。
Vlad：現在前沿實驗室需要的能力，其實覆蓋范圍非常廣。大語言模型這種東西，和研究、和產品之間的關系，比過去的機器學習要緊密得多，所以它會牽動很多完全不同的方向。我寫那篇文章，並不是想開壹份面面俱到的清單，而是想提出幾個比較具體、可操作的方向，說明實驗室會在哪些能力上有很強的需求。
我重點寫的是內核開發和底層工程，也就是怎樣在真實運行環境中提升大語言模型的執行效率。我看到這類能力，在幾乎所有前沿實驗室，以及實驗室內部很多項目裡，需求都非常強。所以這是壹個特別值得單獨點出來的方向。更具體壹點說，每當我們做研究項目，需要修改神經網絡架構，或者重新思考服務方式，比如怎樣把鍵值緩存做得更好，類似這樣的事情，整個技術棧上的人都必須有能力把這些新方法高效地實現出來。
而所有這些變化的核心循環，本質上都是在制造能夠在大規模場景下運行的軟件系統：它要有高吞吐、低延遲。這其實是壹類非常基礎的工作，和傳統後端工程的思維是緊密相連的。所以我覺得，這對很多人來說都是壹個非常開放、非常值得專攻的方向。
主持人：我有些朋友在 OpenAI 和 Anthropic 工作，他們跟我說，那邊會區分偏應用的組織 and 偏研究的組織。我想知道 Google DeepMind 裡是不是也有類似區分？如果有的話，你能不能講講這兩者的差別？
Vlad：我們內部確實有不同的重點方向。比如在 Google DeepMind，就有團隊專門研究怎樣用 Gemini 這樣的語言模型，更好地改進搜索結果。從某種意義上講，這可以算是語言模型的壹種應用化方向。
但我其實不太願意把這種區分畫得特別死，因為把模型整合進真實產品，本身就需要很多非常硬核的研究工作。就拿我剛才說的那個例子來說，為了讓模型真正服務搜索，你得投入大量精力，確保模型回答的是事實，能引用來源，能給出非常精確、非常有依據的答案。
你還得評估這些來源本身的質量，確保它不是諷刺、不是玩笑、不是不可靠的信息。我覺得這恰恰說明，即便是在非常面向產品、非常“應用化”的人工智能方向裡，你其實仍然是在做研究。
當然，另壹方面，也確實存在那種更經典意義上的語言模型研究團隊，比如做預訓練、做後訓練。這些在 Google DeepMind 內部依然是比較獨立的團隊，目標就是打造業內最先進的模型。
也就是更純粹意義上的研究。不過我還是要補壹句：我們做的“純研究”之所以有意義，前提是它最後能被真正實現出來。所以我們既要負責把模型交付出來，確保訓練穩定推進，某種程度上像訓練任務的運維工程師壹樣，盯著整個訓練過程別出問題；同時我們也要負責提出訓練這些模型的方法配方。
這兩個角色根本分不開，必須同時承擔。所以我覺得，你當然可以把研究和應用看成壹條連續的光譜，但在今天這個時代，不管你站在哪壹側，最後都得能在這條光譜上自由切換。
主持人：我注意到還有另壹條光譜，就是軟件工程師到純人工智能研究員。你怎麼看這條光譜？軟件工程和人工智能研究之間，到底差別在哪？
Vlad：如果從我自己的經歷出發，我會說，我們做的很多事情，以及我們提出的很多新方法，它們真正的基礎其實是基礎設施層面的投入。
我可以稍後更詳細講講我團隊在做什麼，但先拿“蒸餾”舉個例子。所謂蒸餾，本質上是壹種知識遷移方式。你可以把它理解成：教師模型先在底層數據上提煉出某種統計信息，再把這些信息傳給學生模型，讓學生模型比完全沒見過這些額外信息時表現得更好。
但如果你說的是壹個超大語言模型，而且處理的是數萬億級別的詞元，這背後對應的計算投入就是極其驚人的，可能是數百萬、數千萬美元的算力成本。
這就意味著，你必須認真思考怎麼把整個系統優化到極致。因為你做的每壹個操作，都會被放大到極其巨大的規模：每壹秒都重要，每壹個字節的存儲都重要。
而這裡面很大壹部分工作，說到底就是非常傳統的軟件工程。尤其是蒸餾基礎設施，到現在大概已經經歷了叁到肆代演化。每壹代裡，我們都會退後壹步，重新審視當前在蒸餾研究中到底用了哪些方法，再從整體上想：我們的基礎設施該怎樣擴展，才能支持更廣泛的研究。
而且確實有幾個很明確的節點：你壹旦重新思考蒸餾系統的設計方式，蒸餾方法的研究速度就會明顯加快。
所以這其實是壹種非常典型的投入：你可能花肆個月時間重寫蒸餾基礎設施，最後換來的，是對蒸餾縮放規律的全新認識，而這種認識又會反過來轉化成非常強的模型表現。
所以它真的要求你跨越整個技術棧去工作。我幾乎無法想象，如果沒有這些蒸餾基礎設施層面的投入，我們能做出 Flash 3.0 那樣的結果。歸根到底，這些東西壹開始都來自壹份非常老派的設計文檔：你得想清楚，生成教師統計信息時，什麼樣的抽象才是對的；這些信息該存進什麼樣的存儲系統；在這種規模下，跨多個數據中心讀寫數據時，底層該如何支撐。
這些其實都是非常經典的分布式系統問題，不是嗎？
研究不是壹條直線，它更像在霧裡走圖
主持人：對，我也是這個意思。聽起來在現在這種計算規模下，確實有很多軟件工程、後端基礎設施類的問題。但我還是覺得，在那條光譜上的某個位置，應該會出現壹個真正的躍遷——需要壹些全新的能力。比如說，你把壹個普通後端工程師直接丟去改模型架構，這顯然和做基礎設施又不是壹個量級的跳躍。
你怎麼看這個區別？
Vlad：對，我覺得確實有這樣壹個分界點。研究這件事，本質上是壹種高風險、高回報的活動。我們常會說壹個詞，叫“研究品味”，也就是壹種高層次的直覺：在壹個項目裡，你面對很多不同的裡程碑和可能路徑時，到底應該沿著哪條路往前走。
從某種意義上說，軟件工程項目也可以被看成類似的壹張有向圖：你有壹堆中間產物要完成，最終才能到達目標。
但軟件工程裡的這張圖，整體上更接近確定性的。你先搭壹個服務，再搭另壹個服務，再搭第叁個服務；先把存儲層搞定，再處理上層功能。你大體可以穩定地壹路往前推進。
研究就不是這樣。研究裡的這張圖是帶隨機性的。因為其中壹些節點——比如某個研究想法，或者到達最終目標所必需的某個環節——並不保證能成功。
我覺得這要求壹種思維方式上的轉變。而這種轉變需要時間去學，也需要壹些專門培養出來的能力。這就是很多人在博士階段逐漸建立起來的那種東西。
如果要我用壹句比較簡潔的話來概括，我會想到 Jacob Steinhardt 教授的壹篇非常出色的文章。我很喜歡用他的框架來理解自己做的研究：研究是壹種馬爾可夫決策過程。
所謂馬爾可夫決策過程，指的是：在壹個研究項目裡，不同裡程碑之間存在壹張帶有隨機性的依賴圖。你可能必須先拿到某種結果，或者先證明某種結論，才能到達後面的目標。
類似地，在壹個機器學習研究項目裡，你可能得先把某種特征方案跑通，之後才有機會獲得某種圖像識別准確率，圖上的節點和路徑都會不斷展開。
這是壹種高度不確定的探索活動：某些方法可能有效，也可能無效；而壹種方法壹旦有效，又會為你打開壹組新的可能性。
在軟件工程裡，你也許可以把所有通往目標的路徑都列出來，然後問：最短路徑是什麼？
但研究裡，這種方法並不最優。因為壹旦圖上的邊不再可靠，有些節點甚至你還根本不知道——也許它們是隱藏的——那你處理問題的方式就必須改變。
具體來說，你必須同時考慮不同研究方向的成功率和時間投入，還得事先對這些概率做出估計。
而這和給壹個軟件項目寫設計方案，是完全不同的壹種思維活動。你得培養出壹種直覺：在你還沒真正做壹件事之前，先判斷它成功的可能性有多大。
很多人把這種能力和“研究品味”聯系起來，我覺得這是對的。因為你如果想真正穿行於這種研究過程裡，這種判斷力就是必須建立起來的核心能力。
主持人：聽起來你的意思是，研究裡有更多的不確定性。我還是想更具體壹點去理解這種工作的性質。如果你把壹個後端工程師扔進壹個做研究的團隊裡，具體會在哪些地方出現明顯短板？
Vlad：我第壹個想到的，就是你是否具備足夠的研究背景，足夠理解自己所處的研究版圖。
研究工作很大程度上要求你有壹種很謙遜的心態：你得承認，在你之前，這個方向已經有了大量投入；而在你真正了解這個主題上全人類目前最前沿的積累之前，你大概率不可能繼續把這個前沿往前推。
所以，在某個具體方向上建立扎實的已有工作認識，並真正做好相關文獻梳理，可能就是很多人最先會卡住的地方。你得有能力沿著壹個主題的引用脈絡壹路追下去，知道該讀什麼、怎麼讀。
因為你根本沒時間把所有論文都讀完，所以你必須培養壹種判斷力：哪些論文最值得讀？在不閱讀全文的情況下，怎麼判斷壹篇論文到底值不值得投入時間？
這是我最先想到的壹項必須建立起來的能力。
而且，光是要看懂這些研究級論文，你本身就得具備機器學習和計算機科學背景。再進壹步，還要看論文屬於哪個領域、講什麼內容；有些論文背後需要的數學基礎和課程訓練都很重，沒有這些前置知識，你根本不可能真正理解它的方法。
這件事非常重要，因為如果你不了解現有的方法論是什麼，你幾乎不可能在它的基礎上做出改進。
比如我前面提到，我們團隊做蒸餾。如果你想推進大語言模型蒸餾方向上的理解，你首先得很好地理解我們到底想用大語言模型去做什麼。
我簡單概括壹下：大語言模型研究，尤其在預訓練階段，核心就是縮放規律。
什麼叫縮放規律？很多人會特別關注它是不是冪律、指數是多少，但真正重要的其實不是函數形式本身。真正重要的是：對於壹套擴大語言模型的方法，當你不斷往壹次預訓練裡投入更多計算量時，你必須能夠預測，這個語言模型最終的測試損失會落在什麼位置。
為什麼這個問題重要？為什麼我們要預測模型的泛化誤差？
在傳統機器學習世界裡，比如說我們做圖像識別，打 ImageNet，你的測試損失就是那壹千個類別上的分類錯誤率。你提出壹個網絡結構，比如 VGG 或 ResNet，訓練壹下，再看它的分類錯誤率是多少，這就能估計這個模型在這類任務上的表現。
我們還可以通過驗證集來估計方法好不好。每當出現壹個新的網絡結構想法，我們訓練壹下，做壹系列驗證實驗，得到交叉驗證誤差，而這個誤差本身就是對最終測試誤差的估計。於是你就可以通過這個流程不斷迭代不同想法。
但大語言模型不是這樣。因為每壹次真正做預訓練，你投入的計算量都會比之前任何壹次都更大。
所以從某種意義上說，它像是壹個“壹次性”的 ImageNet 問題。你永遠沒有機會先完整地看壹遍真正的 ImageNet，再慢慢調。你只能先在 MNIST 上練，再到 CIFAR 上練，然後試圖根據這些經驗，設計壹種辦法，希望它第壹次上 ImageNet 就能直接奏效。
如果你真這麼做——我相信很多人都試過，我自己當年學這些東西的時候也壹樣——你會發現，它在 MNIST 上很好，在 CIFAR 上可能也不錯，但壹到 ImageNet 就突然崩掉。
你會慢慢意識到，很多東西並不會隨著規模自然泛化。
所以，我們在大語言模型裡做的大量工作，其實是在設計“配方”。所謂配方，就是壹個函數：輸入是你願意投入多少計算量，輸出是壹整套語言模型訓練流程。
如果你能把這套配方和壹種預測規則結合起來，而且這個預測規則能夠准確預測最終效果，那你就可以據此做決策，去改進你的訓練配方。
我剛剛這壹大段，其實是在給大語言模型研究的基本面貌提供背景。但這種理解之所以存在，是建立在大量早期語言模型縮放研究之上的，比如 Kaplan 的論文，比如 Chinchilla。
自從那兩篇論文之後，又有很多工作開始研究：除了參數量和訓練詞元數，究竟還有什麼因素會影響預測准確性，比如不同詞元的獨特數量等等。
但我會說，這兩篇論文對大語言模型來說都是基礎性文獻；而它們本身又建立在更長的壹條縮放研究脈絡之上，可以壹直追溯到最早期的 GPT。Google 這邊也通過 PaLM 系列論文積累了大量這方面的研究。
這些工作共同塑造了我前面描述的那種視角。而這種視角，基本上只有你自己親自沿著那條文獻線索走過壹遍，才會真正建立起來。
主持人：假設你要給自己的團隊選人，而你判斷壹個人是否適合幫助你推進前沿的標准，是他對前沿本身的理解，包括對已有文獻的掌握，而這又要求很多前置能力。我記得你在文章裡把其中壹部分叫作“數學成熟度”。
Vlad：對。我覺得，壹旦你具備了數學成熟度，理解這些論文、讀懂這些論文，其實並不難。
我剛才提到的那些論文，現在基本都已經算是入門門檻了，所以如果是候選人，我默認他們應該熟悉這些內容。
但更壹般地說，關鍵能力在於：你能不能鑽進這種級別的論文裡，把它真正讀懂；你能不能把論文裡的研究想法自己實現出來。這是壹項非常重要的能力。
我們會看到各種各樣的想法，它們未必都能直接應用到我們的領域。但如果你能深入理解它們，你就可以在這些想法上繼續迭代，並把它們改造到我們的應用場景裡。
所以當我們評估壹個人是否能處理這些機器學習論文中的數學概念時，這大概就是最關鍵的能力信號。它說明你能拿起壹篇陌生論文，判斷其中哪些想法可以遷移到 Google 的實際環境裡。
真正值錢的能力，常常在系統最底層
主持人：這肯定不是壹份窮盡清單，但我還是很好奇：還有哪些領域，是人們可以去深入鑽研、而且對前沿人工智能研究確實重要的？你提到了蒸餾，也提到了內核。聽起來內核幾乎在哪都很有用，但除了這些之外，還有沒有什麼你會順手列出來的方向？
Vlad：我覺得壹個非常有力量的方向，其實是編程語言研究。
因為如果我們能在編程語言層面創造出更好的抽象，就能極大促進內核開發。我覺得 ThunderKittens 就是壹個很好的例子。它提供了壹種抽象方式，讓你寫內核的時候，只需要圍繞肆個函數工作，而不是去面對壹大團隨意拼起來的 C 代碼。這樣壹來，你在開發那些能夠充分利用硬件的算法時，速度就會快得多。
這時候重點已經不只是編程語言研究本身，而是你是否對這種抽象充滿興趣，並願意和那些關注底層硬件的人壹起工作，比如去嘗試 CuTe 這類領域專用語言。
這類方向裡有很多都是圍繞特定硬件設計的專用語言。
除了編程語言和縮放規律相關文獻之外，我還會想到強化學習文獻。
特別是自從“基於人類反饋的強化學習”出現之後，我們已經看到像 PPO 這樣的深度強化學習算法，確實可以進入生產系統。曾經有壹段時間，這件事到底成不成立，其實還是有爭議的；但現在幾乎已經形成共識：這些算法確實會被應用在真實的生產環境裡。
而想理解它背後的理論，你通常得從強化學習的基礎壹路往上學，再走到今天非常豐富的各種價值型方法和策略梯度方法。
這是另壹個我覺得文獻脈絡極其豐富、非常值得慢慢爬進去的方向。
再往“後端工程師”壹點的方向說，除了內核本身之外，我覺得分布式系統和優化之間，還有壹個非常有意思的交叉地帶。比如：如何設計神經網絡訓練算法，讓它能在大量圖形處理器上訓練——這裡面會有很多有趣的問題：異步性、梯度的新鮮度、流水線方式會怎樣加劇梯度陳舊，等等。
你在訓練算法設計裡做出的這些系統性選擇，都會影響神經網絡的收斂情況和最終質量。
這些問題其實就算脫離大語言模型場景，也可以單獨研究，而且已經被研究很久了。所以如果你更偏基礎設施方向，那我會說，先把這些算法是怎麼運作的弄明白，會是壹個非常好的起點。
主持人：你覺得不同前沿實驗室之間，對人的要求會有差別嗎？比如說，如果有人想去 Google DeepMind，是不是會有某個方向比 Anthropic 更受重視？至少從技能組合上看，我感覺應該還是挺接近的。
Vlad：對，我覺得不同實驗室可能會在商業策略上有所差別，提供的產品和服務也會因為各自的專長和客戶類型不同而不壹樣。
但如果問大家真正看重什麼，我認為實驗室之間重疊其實非常大。我那篇文章發出去以後，你會看到 OpenAI 和 Anthropic 的人也在說：對，這些建議我們也認同。
所以我覺得，這至少算壹個小小的證據，說明大家在這件事上其實非常接近。
主持人：我覺得很多人之所以特別想往人工智能研究靠近，是因為他們在想：未來軟件工程也許沒那麼重要了。那研究這邊會不會也有類似問題——大語言模型以後會不會也把很多研究工作接過去？所以人工智能研究未必就比軟件工程更值得押注。
Vlad：我覺得研究能力只會越來越重要。
能夠處理工作規劃裡那些不確定、隨機的成分，會越來越成為我們工作的核心部分。你要學會怎麼在你做的任何事情裡利用人工智能——而且這件事甚至不必局限於軟件——這種能力應該立刻開始練，因為這些系統本來就不是確定性的。
你真正要思考的是：我怎樣圍繞這些大語言模型搭系統，讓自己把工作做得更有效？未來真正能把你和別人區分開的，就是這種能力。我覺得不管你具體做什麼，這壹點都成立。
坦白說，現在到處都是恐懼營銷。尤其有些人在談人工智能的時候，本來就在故意制造這種恐慌。我的感覺是，人們真正應該做的，是把注意力放回自己身上，想辦法讓自己變得更高效。
我並不認為人工智能會取代我們所有人的工作。原因在於，人類在組織裡承擔的壹個關鍵角色，是構成壹張信任網絡。組織本身就是壹組資源和壹群人，而這群人負責管理這些資源。
我們的壹項重要職責，就是把這些資源分配到特定目標上。
就算人工智能能大幅加快執行速度，關於資源如何分配的決定，最終還是必須落到具體的人身上。這件事永遠要有人負責。因為你不能把責任推給人工智能。
比如說，現在的大語言模型已經非常懂法律了，它可以幫你審合同之類的；但它不能代表你出庭，因為它不可能被吊銷律師執照。
我覺得這就是壹個非常尖銳的例子，說明為什麼法律職業依然會存在：即便大語言模型很擅長調用先例、理解法理，你還是需要壹個能為結果負責的人，去驗證人工智能的輸出，用人工智能來更高效地完成法律工作，而不是把自己的法律辯護整個交給壹個語言模型。
別被恐懼營銷帶著走
主持人：對，我覺得當初促使你寫那篇文章的原因，其實也正是這種恐懼氣氛。
Vlad：對。我真的覺得，人們應該擁有的是壹種更建設性的心態。
我之前看到壹條推文，好像是 Deedy 發的，裡面是那種很長的恐慌敘事，說什麼人工智能會制造壹個永久性的底層階級之類的。人很容易被卷進去。
但我覺得真正該想的是：我們每個人都對自己的未來擁有主動權。今天就可以開始投資那些對明天有意義的能力。這才是唯壹真正該做的事。光擔心，什麼也改變不了。
所以我想寫那篇文章，也是為了回應這壹點。因為我確實感覺到，這種情緒壹直在擴散。前陣子我去普林斯頓做講座，現場壹個很大的問題就是：我怎樣才能去 Google DeepMind 工作？
而且這幾乎就是大家知道我在做什麼之後，最常問我的問題。
所以我想，也許給出壹些更具建設性的方向，會對整個討論更有幫助。
主持人：關於那篇文章最後還有壹個問題。因為如果你想拿到壹個崗位，當然壹方面是能力本身，我們前面聊了很多你的能力是否匹配這個崗位；但另壹方面，其實還有“信號”——你如何向外界展示自己，以及什麼樣的信號是被看重的。
如果你要把自己推給這些前沿實驗室，什麼樣的信號最重要？
Vlad：最重要的是，拿出真實證據，證明你沿著這些方向做出過對別人有用的東西。比如內核開發。
現在已經有很多開源大語言模型了，你完全可以拿其中任何壹個來做優化。你甚至不壹定要把模型本身做得更強。很多場景下，只要你能證明：在某個設定裡，我把這個地方做快了，把那個地方做順了，這就已經很有價值了。
而且事情也不只是在圖形處理器上加速模型推理。圍繞大語言模型的服務棧，本身就是壹個非常復雜的分布式系統。它要維護鍵值緩存，還要處理各種負載均衡、請求排隊——這些都是後端服務裡再常見不過的問題。
這些項目壹直都需要幫助。所以像給 vLLM、SGLang 這種項目做貢獻，或者基於 TensorRT 做壹些實踐展示，都會很有價值。TensorRT 那邊我記得還有個分布式系統叫 Dynamo，它支持把推理服務拆分部署。你如果能展示自己基於這些組件做了項目，或者真正改進了這些組件——
對我來說，這會是非常強的候選人信號；同時我也覺得，這會是對開源社區非常受歡迎的貢獻。
主持人：還有壹點，我們前面很多討論都默認了壹條路徑：從外部跳進前沿實驗室。
但其實這些實驗室背後往往都有很大的組織體系，很多團隊並不是直接做最前沿研究的。比如在 Google 體系裡，有些基礎設施工程師可能本來在搜索團隊工作，有很強的後端能力，但領域背景沒那麼深，然後他們想內部轉到 Google DeepMind。
在這種內部轉崗的情況下，你的建議會和外部候選人不壹樣嗎？
Vlad：我以前在搜索那邊有壹位合作很緊密的同事，後來真的轉到了我團隊，叫 Nate Lintz。他非常厲害，現在在我們團隊裡負責了很多核心工作，特別是在 Flash 和 Flash-Lite 的推理協同設計方面。
我覺得他就是壹個很好的例子。他當時的思路是：我怎樣才能幫助自己所在的產品線，盡可能有效地采用這項技術？
所以我會說，如果你所在的組織不是直接造模型的，而是試圖利用這些模型，那這裡面其實有壹個很大的空白：如何真正把這些大語言模型高效地應用到你的組織裡，如何高效地把它們服務起來。
如果你能成為那個把這件事做得特別好的人，這不僅會給你的團隊創造巨大的業務價值——這顯然會讓你在本組織裡脫穎而出——同時，你也會自然而然成為我們研究團隊在對接產品落地時最重要的合作方之壹。因為我們會需要和你這樣的人協作，確保模型能在你們組織裡真正發揮作用。
所以到了那壹步，你也許會想轉崗，也許不會。你如果想轉，我們當然很歡迎。
但即便你不轉，其實你已經在做壹件非常前沿的事情了：把這種新技術整合進真實產品，讓真實用戶去使用。
所以，對這種情況，我的建議大體就是這樣。
先做出東西來，信號自然會出現
主持人：在那篇文章快結束的時候，作為收尾，你還發出了壹個很具體的邀請，因為我知道你當時在招人。要不要把那段再講壹下？
Vlad：對，我當時是在想：我怎麼才能真正做到“說到做到”？怎麼證明我不是只在嘴上說這些能力重要，而是真的願意按這個標准去看人？
我想表達的是：如果你能通過壹些具體練習，證明自己至少在我強調的那些能力上已經有了壹些初步證據——比如意圖、數學成熟度、韌性——那我願意認真看。
所以我列了幾項練習：有些是為了展示你對縮放規律已經有初步理解；有些是要你在工程層面願意深入細節，真正親手實現壹個 Transformer；還有壹些則是展示你願意掌握我們每天都會用到的那些基本數學，用來估算和設計這些大語言模型。
我現在已經記不清完整的練習清單了，但如果你把《縮放之書》裡的題目認真手寫做完，錄壹段自己講解過程的視頻，再加上我文章裡提到的 Transformer 練習，把這些都發給我——
那就是非常有力的東西。如果你能在紐約辦公室工作，我會非常願意面試你。
確實已經有不少人因此聯系我了。我其實已經收到過幾份提交，現在也已經在推進其中壹些人的面試流程。
所以，這件事工作量當然不小。但讓我很驚訝的是，我大概在文章發出後壹周內，就收到了回應。說明這件事確實是做得到的。
當然，我的招聘名額不是無限的，所以這個邀請雖然有效，但我也不可能招無限多人。
不過好的壹點是：這本身就是壹種非常強的自我成長信號。所以，不管你最後會不會因此去 Google DeepMind，這些事情都值得你為了自己去做。
而且我覺得，它也會幫助你准備去其他地方面試。
當然，如果你真的完成了這些練習之後聯系我，即便我這邊已經招滿了，我也認識很多其他正在招人的人，我也很樂意幫忙推薦。
真正有意思的，是把模型做對，也把硬件吃滿
主持人：接下來換個話題。我看到你是 Gemini 預訓練方向的負責人，我覺得挺有意思的，很想聽你從自己的角度高層次講講：在你看來，預訓練到底是什麼？以及這個方向上最重要的挑戰有哪些？
Vlad：可以。
作為預訓練方向的負責人，我們要做的事情其實很多。
我團隊負責交付的具體產品，包括 Flash 模型和 Flash-Lite 模型。這些模型會被用在搜索裡的 AI 概覽 and AI 模式上，也包括壹些供其他組織內部使用的壹方模型，比如廣告 and YouTube。
除此之外，我們還是 Google and Apple 合作中的關鍵技術負責人之壹，所以也會做那邊的技術工作。
這些是我團隊承擔的產品層面交付。
再往上，我們還要做研究，確保這些交付本身處在業界最先進水平。同時，我們也做壹些更通用的預訓練研究，再反過來貢獻給 Pro 系列模型。
如果從研究性質來分，我會說大體可以分成叁個方向。
第壹是前面提到過的蒸餾。
第贰是我喜歡稱之為“推理協同設計”的東西。也就是：設計那些在推理時足夠高效的神經網絡架構。具體來說，就是決定網絡的拓撲結構，決定 Transformer 裡門控層和線性層的矩陣形狀，決定注意力機制的形狀、注意力頭數量，諸如此類。目標是讓這些設計在你實際部署的硬件上，能盡可能高效地運行。
第叁個支柱，是新的量化方法。量化壹直是我特別有感情、也從加入 Google 以來壹直在研究的方向。它實際上會改變前兩個方向能夠做到什麼，因此推進模型壓縮的最前沿，也就成了我們團隊研究中的重要組成部分。
壹般來說，量化指的是：在某種意義上減少神經網絡權重表示所占據的體積。
通常在訓練時，神經網絡裡的那些矩陣參數是用叁拾贰位浮點數來存儲的。
但事實證明，在實際計算中，你根本不需要那麼高的精度，模型質量依然可以保持得很好。用壹些並不算復雜的方法，就能把這些權重的存儲精度壓縮到肆位。
也就是說，本來叁拾贰位浮點數能表示壹大段數值范圍、達到大約柒位精度的東西，現在居然能以相當高的保真度，用肆位整數來表示——而肆位整數覆蓋的范圍其實非常小，大約只是從負八到柒。這本身已經像奇跡壹樣了。
但更神奇的是，你甚至還可以把類似的量化變換應用到神經網絡運行時的激活值上。
壹旦做到這壹點，實際做矩陣乘法時，參與運算的數就會比以前小得多，因此運行神經網絡所需的電力也會顯著下降。
有意思的是，人工智能硬件總運營成本裡，有百分之九拾九都來自驅動這些芯片所消耗的電力。如果你能把這些運算做得更便宜，神經網絡就能更廉價、更高效地運行。
這會直接幫助你處理更多請求，也會改善時延。
所以量化研究的核心問題就是：我們怎樣把前沿繼續往肆位之外推進？
主持人：我在推特上經常看到壹種說法，老在討論“模型浮點運算利用率”。對於不在這個行業裡的人，或者說不了解這個概念的人來說，他們壹看到那個數字只有拾幾個百分點，就會覺得：哇，這不是浪費了絕大多數圖形處理器資源嗎？
我想請你幫大家解釋壹下，為什麼看起來“低”的模型浮點運算利用率，其實壹點也不低。順便也請你解釋壹下它到底是什麼。
Vlad：對。所謂模型浮點運算利用率，本質上是這樣算的：把神經網絡實際完成的浮點運算次數，除以在這段請求時間裡，硬件加速器理論上本可以完成的總浮點運算次數。
所以從某種意義上講，這個指標告訴我們：在多大比例的時間裡，我們真正有效利用了這塊加速器的浮點運算能力。
如果你想達到百分之百的利用率，那意味著你必須把硬件裡的矩陣乘法單元壹直吃滿。
也就是說，它只能不停地在循環裡做矩陣乘法，不能去讀內存，也不能做任何別的操作。
但這種計算在現實裡沒什麼意義。神經網絡需要做激活函數，需要做注意力計算，需要把中間結果寫回高帶寬顯存。所有這些操作，都需要使用內存總線，或者向量處理單元。甚至有些數學操作，本來就是底層硬件裡比矩陣乘法慢得多的部分。
這些因素都會導致模型不可能壹直按處理器標稱峰值運行。
所以你之所以看不到百分之百的利用率，是因為神經網絡有壹部分時間在讀寫內存，另壹部分時間在做壹些天生就比矩陣乘法慢的操作。
我前面提到的推理協同設計，其實很大壹部分就是在協調芯片的各種能力：和其他芯片之間的通信、內存帶寬、從內存中讀取參數的速度、浮點運算能力——這裡既包括矩陣乘法，也包括向量運算，比如做激活函數。
這些能力在硬件上都有不同的速率，而任意壹種計算都不可能天然精確匹配硬件每壹類能力的最佳節奏。
在設計神經網絡時，你要做的是選出壹組結構形狀，讓這個網絡能盡可能同時吃滿這些硬件單元，從而在推理時把利用率盡量拉高。
而讓這件事不只是壹個代數題的原因在於：這些設計選擇最終會影響你訓練出來的神經網絡質量。
所以推理協同設計真正有意思的地方就在於：我們怎樣設計出壹種神經網絡架構，它既能穩定地隨規模擴大，又有好的質量預測，同時還能讓推理時的硬件利用率盡可能高。
這種聯合優化，正是推理協同設計最有趣的地方。
而且它還是個常青問題。因為隨著硬件變化，浮點運算、內存帶寬、通信帶寬之間的相對關系也會變化，而這又會改變“什麼樣的神經網絡形狀才是最優”的答案。
很多關鍵工作，並不光鮮
主持人：換個話題。Google 有壹種叫“即時獎金”的機制，就是有人可以因為你做得特別好，給你壹筆壹次性的獎金。我在你的履歷裡看到，Jeff Dean 這位傳奇人物曾經給過你即時獎金。
如果你願意講講那個故事的話，我很想聽。為什麼他會給你這個獎金？
Vlad：那其實發生在 Gemini 項目剛開始的時候。
Jeff 當時給了壹批參與 Bard 第壹版發布的人即時獎金。我在那個非常龐大的項目裡，其實只做了壹個很小的貢獻。我幫忙做了監督微調，參與了 Bard 最早幾個發布版本中的某壹版。
那段經歷給我最大的啟發是：在那個時候，我還只是 Google Brain 裡壹個純做研究的人，我當時非常執著於壹件事——怎麼盡量多發第壹作者論文到 NeurIPS、ICML、ICLR。
我非常清楚地記得，當時我腦子裡的第壹反應其實是：我是不是應該繼續低頭寫論文？
很幸運的是，那時我的經理 Rohan Anil 非常鼓勵我們都投入這個方向。對我來說，這正好給了我需要的推動力——讓我真的卷起袖子，去做很多超參數調優 and 工程工作，想辦法讓這個模型在壹些非常老的張量處理器上跑起來，好為監督微調多爭取壹些訓練機會。
那次很小的初步參與，後來得到了 Jeff Dean 的認可。我覺得它也進壹步推動了我在大語言模型方向上的投入，最終把我帶到了今天的位置。
所以我會說，這件事的重點並不在於，我當時那壹點監督微調工作對最初發布到底幫了多大忙。
更重要的是，它讓微觀的我認識到：想參與那些高價值項目，你往往需要投入很多並不光鮮的工作。可能只是超參數調優，只是為了讓程序塞進特定內存預算裡，不停去擠壓編譯器表現、摳那點空間。
但這些工作，都會服務於更大的業務目標。而這件事，對於進入真正重要的項目來說，非常關鍵。
主持人：你在 Gemini 上也做了很久了，而且這還是壹個最高優先級項目，所以你壹定經歷過壹些事故或者“戰爭故事”。我很好奇，你最喜歡的壹段 Gemini 故事是什麼？
Vlad：如果讓我選，我最喜歡的應該是 Flash 2.0。
那真的是壹段非常艱難、也非常漫長的旅程。但我們當時最核心的優化目標之壹，是延續 Flash 1.5 已經建立起來的那個定位：做壹種非常快、時延很低、但質量依然很強的模型。
尤其是它必須快，因為搜索需要它在 AI 模式裡非常迅速地返回回答。
正因為如此，在 Flash 1 的時候，雖然我們已經知道混合專家模型，也知道它可以顯著提升容量，但當時壹個很現實的問題是：我們當然想用這種新架構，可你很難直接切過去。
因為混合專家模型的特點之壹就是參數通常更多。而參數壹多，就會占用更多高帶寬顯存。可我們部署所用的這些芯片，高帶寬顯存是有限的。
所以你就必須把這個混合專家模型切分到多塊芯片上。假設你有 N 個專家模塊，那你可能得把它們分布到 N 塊芯片上，或者按某個和 N 相關的比例分布。
這樣壹來，模型中間就會出現大量通信。當壹個詞元需要被路由到某個專家模塊，而這個詞元原本在第壹塊張量處理器上，卻必須送到最後壹塊去處理——你就在前向傳播過程中引入了巨大的通信量。
而這個操作的時延會隨著 N 的增加而急劇變大。混合專家模型的難點就在於，它會把 N 推得很高。這就成了壹個非常嚴重的瓶頸。
有意思的是，我們其實很早就知道流水線式服務這個思路。只是對稠密模型來說，它壹直沒有真正重要到必須采用。
我很清楚地記得，自己很早曾和 Sholto 聊過這個事。Sholto 當時說：對啊，你這裡主要受限於浮點運算量，所以做流水線並不會改變輸入預填階段的性能曲線。
後來證明他是對的。我試了壹下，然後就把這個想法擱置了。
但有意思的是，當時我團隊很小，我手下的壹位同事 Geng Yan 提出了壹個非常好的想法。他當時和 Rahul Arya 以及 Google 以色列團隊的幾位同事合作，提出把流水線式預填應用到混合專家模型上。
所謂流水線，就是說你不再把那 N 台機器並行地分給同壹層裡的 N 個專家模塊，而是把不同的層分配到不同機器上。
也就是說，不再是在某壹層裡把詞元在各台機器之間來回路由；而是某壹層的機器先處理你預填請求中的壹部分詞元，再把這些處理過的詞元傳給下壹台機器，讓它處理第贰層，再傳給第叁層、第肆層。
這樣壹來，所有專家模塊都可以常駐在單台機器上，或者更少數幾台機器上。它本質上改變了通信模式：從原來那種每壹層都要做大量詞元交換，變成了壹種可以被其他計算掩蓋掉的通信方式。
因為你可以把流水線式預填分攤到請求的不同部分。比如第贰層在處理請求前壹千個詞元時，第壹層所在的第壹台芯片已經可以開始處理第贰個壹千詞元了。
所以，這其實是壹種打破高帶寬顯存約束的方法：不是把專家模塊在機器之間搬來搬去，而是把網絡層分布到不同機器上。
正因為如此，通信開銷降下來了，混合專家模型的時延突然就變得非常有吸引力。
Gemini 2.0 的技術報告裡寫得很清楚：它是壹整個混合專家系列模型。而使這件事成為可能的原因之壹，就是這種推理階段的服務創新。
Dwarkesh and Reiner 有壹篇非常棒的文章，專門講這個優化，而且你甚至可以把它寫進《縮放之書》的代數框架裡去理解。
這也是壹個很好的例子，說明這種看似局部的改動，實際上會對大語言模型質量產生多麼巨大的影響。
真正讓 Flash 2.0 那段經歷如此有成就感的，是這個重大的混合專家決策。它在當時聽起來像個小技術選擇，但大家真的非常擔心：這個模型的時延到底能不能壓到合理范圍。
好在我最後推動了壹套非常透明的技術決策流程，把問題徹底查明了。最後我們做出了正確的判斷。
可接下來還得訓練它。
這是壹個在 Flash 這個規模上，我們訓練過的最大模型。我們知道這是對的方向，但接下來的肆拾天會是極其艱苦的過程，而且團隊非常小。
負責這次訓練輪班的人，可能只有伍個左右。我記得我們幾乎是壹天接壹天地交接，輪流做這種運維式工作：想辦法讓訓練任務壹直活著。因為在當時，這真的是壹個非常需要人工盯著的過程——你得確保所有東西都穩定推進，確保數據迭代器調好了，不會拖慢任務；如果數據裡有空洞、索引有問題，你必須立刻修補，因為每壹分鍾都在燒掉巨量算力。
主持人：那夜裡和周末怎麼辦？
Vlad：對，所以那肆拾天裡，我們基本沒怎麼睡。
我們必須在巴黎辦公室 and 山景城之間做雙班倒。
而讓這壹切最終變得特別值得的，是模型發布的時候，差不多正好趕上 DeepSeek-V3 出來。那時《華爾街日報》發了壹篇很誇張的“紅色恐慌”式文章，講什麼中國要靠開源模型接管人工智能之類的。
我記得我朋友給我發來壹張截圖，是大模型競技場排行榜的壹張表。最右上角是 ChatGPT，DeepSeek 緊隨其後。然後文章還在說，DeepSeek 只花了幾百萬美元訓練，就已經追得那麼緊。
我朋友就跟我說：哦，Gemini 落後太多了。因為那張表最底下放的是壹個我記得像 Flash 1.5 Pro 之類的版本。
然後我壹看，心想：這挺有意思的。我剛好壹直在看這個排行榜，因為我們剛發了壹個模型，而網站上的實際情況顯然不是那樣。
後來才發現，《華爾街日報》那篇文章裡把壹些行給省略掉了。所以如果你今天再回去看那篇文章，你就會看到，當時真正處在業界最前沿的模型——Flash 2.0 Thinking——其實在表格的右上角，遠遠領先於 DeepSeek-V3。這多少會讓他們當時想講的那個“開源壓倒壹切”的敘事不那麼成立。
但對我們團隊來說，那確實是壹次非常重要的成就。
做那個別人真心希望他成功的人
主持人：最後壹個問題。如果你可以回到自己剛大學畢業的時候，大概就是本科畢業那會兒，然後給那個時候的自己壹些建議——以現在的你所知道的這些東西——你會說什麼？
Vlad：你得去追那些這個世界今天真正面對的問題。去追那些人們在日常生活中真正遇到的挑戰。不要害怕自己切進去的只是這個問題裡較小的壹部分，或者聽起來沒那麼體面的那壹部分。
即便它不是那種“很高級”的研究、數學之類的東西，也沒關系。你要相信，只要你是在做重要的事，哪怕只是壹個更大項目裡的較小組成部分，你最終也會看到，真正推動前沿往前走的，到底是什麼。
我想，這裡面需要壹種面對問題時的謙遜。你真正該追求的是這個。
如果再說另壹條建議，也許更偏職業層面壹點，那就是：成為那種別人願意看到他成功的同事。
我的意思是，大家總會談什麼“職場精神病”、馬基雅維利式領導者，或者那種為了結果不惜壹切代價的人。他們也許能通過壓榨別人，換來壹些短期收益。
但這麼多年和各種樣的人共事下來，我覺得最有意思的是：我見過極少數那樣的人——其中有壹位特別親近，是我的朋友 and 導師 Todd Lipkin，也是最早帶我進入計算機科學的人——他們非常善良，而且你能從他們身上學到很多。你會真心覺得：我願意跟著這個人壹起做事，也願意幫助他成功。
特別是，如果你是那種能幫助別人把項目做成的人，能提出壹些項目，讓別人可以用自己的互補能力在其中發光的人，大家會注意到這壹點。將來他們也會更願意參與到你提出的項目裡，也會更願意支持你。
很多人壹想到職場互動，就會變得很犬儒，總想著博弈，想著怎麼占優。
但我的經驗是，這種更友好、更合作的方式，往往會培養出壹種很深的協作感 and 互相幫助的意願。而要把那些需要多人、多種能力共同跨線的大項目真正做成，這種東西太重要了。
所以，如果我能給更早版本的自己壹點人際層面、職業層面的建議，那就是：去做那種人。做那個別人會真心希望你成功的人。
主持人：我很喜歡這番建議，因為它正好對抗了那種很犬儒的建議。我也很喜歡，你最初那篇文章本身，就是在對抗那種“末日論”“永久底層階級”式的說法。非常感謝你今天抽時間來聊。真的很有意思，也非常感謝你。
Vlad：謝謝你邀請我，Ryan。
[物價飛漲的時候 這樣省錢購物很爽]
| 分享: |
| 注： |
| 延伸閱讀 |
推薦: