【對談】傑夫·迪恩：AI 的勝負不在模型，在 TPU 底下那層你看不到的東西
AI 圈有一批人你永遠不會在財經雜誌封面上看到，但他們決定了這個產業往哪裡走。傑夫·迪恩（Jeff Dean）是其中一個——Google 第 30 號員工，從 1999 年搜尋引擎還擠在帕羅奧圖一間小辦公室的年代就在了，後來主導 Google 的 AI 研究超過十年。外界現在吵的是誰的模型比較厲害，誰的算力比較多，Open Source 和閉源誰會贏。這場 OpenXLA Dev Labs 的爐邊對談選在這個當口讓他開口，問的不是模型，問的是這一切底下那層你看不見的東西——晶片，編譯器，網路，可靠性。那才是真正決定勝負的地方。
每天精選 6 則要聞、一則產業名人訪談，五分鐘跟上。
這場談話有幾個值得記的點：第一，TPU 的誕生不是因為 Google 想做硬體，而是因為算帳算出來不做不行；第二，訓練規模擴大到十萬顆晶片之後，可靠性變成一個系統工程問題，不是買更好的零件就能解決；第三，傑夫·迪恩點出硬體設計流程本身太慢，必須自動化才能跟上 AI 演進的速度；第四，推論端的需求正在從訓練端分離出來，未來的硬體要分開設計；第五，Google 把整個 AI 軟體堆疊開放原始碼，背後有一套明確的生態策略。合在一起的意思是：這不只是 Google 自己的技術路線圖，而是整個 AI 基礎建設的演進藍圖。
◎TPU 的起點是一道算術題，不是一個雄心
2013 年傑夫·迪恩做了一個估算：假設一億人每天對著手機講幾分鐘話，用上他們剛做好的深度學習語音模型來辨識，Google 要把電腦數量加倍才服務得起——而那只是 Google 一個小角落的功能。這個數字讓人清醒。結論不是放棄，而是通用 CPU 不夠用，要做專用晶片。第一代 TPU(Tensor Processing Unit，Google 自製的 AI 加速晶片）在 2015 年完成，專門跑低精度的矩陣運算，其他什麼都不做。和當時同期的 CPU，GPU 相比，每瓦效能高出 30 到 80 倍。傑夫·迪恩說，他當時去找 CFO，說我們要買很多，但還不確定拿來幹什麼——CFO 同意了。這個細節說明一件事：在技術判斷清楚的前提下，Google 願意在看不到明確用途的情況下先卡位。
◎十萬顆晶片在一起，可靠性不是軟體補丁問題
訓練 Gemini 模型動用過十萬顆 TPU。規模到了這個量級，一個硬體托盤（tray）壞掉不再是擇期修的問題，因為它牽連的整個訓練叢集每耽誤一分鐘都有代價。現場負責基礎建設的 Bill 說，他們用一個叫 good foot 的指標追蹤訓練叢集的有效利用率——早期只有 50% 到 70%，意思是一半的算力在空轉或等待恢復，現在已經推到 95% 甚至 98%。怎麼做到的？訓練開始前先用軟體掃描整個叢集的健康狀態，有問題的元件直接排除；訓練途中發現問題立即替換；資料中心維護排程要跟訓練排程協調。傑夫·迪恩補充了一個更根本的觀點：最難處理的不是機器掛掉，而是機器還在運作但算錯了——2 加 2 算出 5，靜默地汙染你的模型權重，不會有任何錯誤訊息。這種問題在早年 Google 用消費級個人電腦跑搜尋時就遇過，解法是在軟體層做校驗，讓系統能在硬體不可靠的前提下仍然得出正確結果。
◎硬體設計流程本身太慢，專用晶片才能普及
傑夫·迪恩對未來最鮮明的一個判斷是：專用硬體的方向是對的，但現在的設計流程太慢，慢到跟不上 AI 演進的速度。現在做一顆晶片，從高階規格到實際可用，通常要 150 個人花兩年。你今天下的賭注，要到兩到六年後才知道對不對。AI 的走向在六個月內就可以大變，賭兩年後的需求本來就是個不可能的任務。他的答案是：用強化學習或演化演算法把硬體設計流程自動化，讓搜尋空間機器來跑。如果設計週期能壓縮到 10 個人三個月，那你就不需要賭那麼遠的未來，三到六個月後你需要什麼就設計什麼。專用晶片的普及，取決於這件事能不能做到。
◎推論和訓練要分開設計，工具速度跟不上模型
過去兩三年 AI 圈的硬體投資幾乎全壓在訓練端。傑夫·迪恩說現在這個重心正在移動——大模型成熟了，大量流量開始流向推論端，尤其是 AI 代理（agent）場景。推論的需求和訓練根本不一樣：模型權重不變，只有請求和快取（KV cache）在動，所以核心問題是怎麼把資料搬運量壓到最低。更有意思的觀察是：當推論硬體夠快，現有的工具鏈反而變成瓶頸。他舉了個例子——如果模型生成程式碼的速度已經超過編譯器編譯的速度，那編譯器的速度才是那個需要解決的問題。Google 內部因此已經在加速一些工具的執行速度。把訓練時代的硬體思維直接搬到推論端，不會有好結果。
◎開放原始碼不是公關，是生態策略
TensorFlow，JAX，Kubernetes，穩定的 XLA 編譯器中間表示（HLO，硬體無關的計算圖格式），這些 Google 都開放了。傑夫·迪恩說得直接：你不可能一個人把所有事情做好，讓外面的人看得到，改得了，幫你找問題，整個生態才會一起進步。但 Bill 說的那段更務實：Google 現在還在推 PyTorch 在 TPU 上的支援（torch TPU 專案），因為 PyTorch 在社群裡已經是主流，要讓使用者從 GPU 換到 TPU，最低的門檻就是讓他們不需要改太多程式碼。策略很清楚：自己的東西開放，同時擁抱社群已經選擇的工具。這不是讓步，這是在替 TPU 找到更大的使用基礎。
傑夫·迪恩這場談話有個底層邏輯貫穿始終：真正的護城河不在模型，在模型底下那層你看不到的系統——晶片，編譯器，網路拓撲，可靠性工程。這些東西要花五年才建得起來，建好之後又因為彼此整合而產生別人難以複製的優勢。你若只在意 ChatGPT 的新功能，你看到的只是冰山頂端；這場對談說的是水面下的部分。
描述 2013 年的算力估算：若一億人每天用幾分鐘語音辨識，Google 需要把全部電腦數量加倍，由此引出研發 TPU 的起因。
說明 TPU v1 定位於推論，目標是低精度線性代數，相較同期 CPU/GPU 每瓦效能高出 30 到 80 倍。
介紹 TPU v2 起設計理念：整合高速互連的超算架構；TPU v3 導入液冷；TPU v4 引入光學可重組網路（OCS），讓機架可像樂高積木一樣重新組合。
說明 good foot 指標（訓練叢集有效利用率）的演進：早期約 50–70%，現在可達 95–98%，並列舉訓練前健康掃描，訓練中即時替換，資料中心排程協調三項改善措施。
提醒靜默資料錯誤（silent data error）的威脅：晶片過熱時可能算出錯誤結果卻不產生任何警示，是規模化訓練最難偵測的故障類型。
論述硬體設計自動化的必要性：若能以 10 人，3 個月完成一顆晶片設計（現在需 150 人，2 年），專用硬體才能跟上 AI 演進速度；提到用強化學習自動搜尋設計空間的方向。
分析推論端硬體需求與訓練端的差異，並指出當推論速度超過工具鏈（如編譯器）速度，工具鏈本身成為瓶頸；舉 Google 內部已在加速內部工具的實例。
回答規模擴展提問：TPU v8 最大單一 Pod 約 9,600 顆晶片，採 3D Torus 高速互連；更大規模的跨 Pod 訓練由 Pathways 軟體透過資料中心網路甚至廣域網路串接，目前仍維持全同步訓練。
看完今天的，讓明天的自己送上門
每天精選 6 則要聞、一則產業名人訪談，五分鐘跟上。
已出刊 128 期 ・ 隨時可退訂
