TorchTPU 開源解析：52% MFU 與 8,192 顆 TPU，為何不能混讀？（2026）

2026 年 10 月 20 日，Google 在 PyTorch Conference 公開了 TorchTPU，並由 Mark Lohmeyer 與 Bill Jia 在 Google Cloud 部落格以〈TorchTPU is now open source: Run native PyTorch on TPUs〉說明這套與 Meta PyTorch 團隊共同開發的原生後端。它讓 PyTorch 使用者多一條通往 TPU 的路；要讀懂進展，得把「程式能跑」「訓練能擴大」與「每件工作更便宜」分開看。

先看公告承諾，再核對合作方與技術報告，最後回到導入決策。最容易誤讀的兩個數字，是 52% MFU 與 8,192 顆 TPU：它們出現在同一場發布裡，卻不能直接當成同一筆測試。

TorchTPU 的核心：把熟悉的 PyTorch 帶到另一種晶片

PyTorch 是寫模型與張量運算的軟體框架；TPU 是 Google 的 AI 加速器；TorchTPU 是兩者之間的後端。Google 的現行架構文件說明，預設 eager 模式保留逐步開發與檢查的操作方式，之後可以透過 torch.compile 擷取計算圖，再走 OpenXLA／StableHLO 編譯路線。PyTorch 過去已有 PyTorch/XLA，因此這次的重點是原生執行語意與生態整合的改變。

TorchTPU lets you debug your models with eager mode

中文：TorchTPU 讓你使用 eager 模式除錯模型。

Google Cloud 原文節錄

框架本身的 PrivateUse1 官方教學可獨立核對這種擴充方式：外部硬體後端能向 PyTorch 註冊運算與裝置能力。這支持「沿用熟悉介面」的設計可行性；它沒有替任何特定模型保證速度。公開程式庫則能檢查實作、編譯快取與分散式範例，授權為 Apache 2.0。

把它想成同一份菜單接上另一間廚房：點菜方式更接近原來的習慣，仍要確認廚具、食材處理與出菜節奏。保留上層程式，是有價值的工程成果；底層硬體的差異，也仍然影響怎麼把工作做得好。

整套發布想解決的，是模型之外的接線

Hugging Face 的整合公告提供具體入口：Transformers v5 用 device_map="tpu" 載入模型；Diffusers 可先以 pipe.to("tpu") 做 eager 開發，再選擇編譯。這些是官方範例的入口，實際執行仍需要 TPU 環境與相符套件。本文依公開資料判讀，未在 TPU 上執行模型或測量效能。

Google 還把推論引擎 vLLM、SGLang，叢集路由 llm-d，訓練用 TorchTitan、強化學習用 VeRL，以及工作排程 Ray 串成一條路。讀者不必背下每個名字：模型後端負責算，服務引擎負責接住請求，路由與排程負責把工作送到合適資源。vLLM-TorchTPU 專案也已公開。要補這層分工，可以接著讀 LLM 推論引擎入門。

原文也介紹 LiteRT 的裝置端部署，以及仍處早期預覽的 TPU agent suite。前者延伸到手機、桌機等端點，後者協助上手、診斷與調校；兩者補的是不同環節，不能由「同場公布」推導為功能成熟度相同。整篇公告真正的訴求，是讓團隊有機會在既有工具鏈內選擇硬體。

TorchTPU 的 52% MFU 與 8,192 顆 TPU，先分開成績單

Google Cloud 公告寫到 Qwen3 8B 的「最高 52% MFU」，也提到最多 8,192 顆 Ironwood TPU 的擴展。這是 Google 提供的效能描述，不能把兩個上限拼成「8B 模型在 8,192 顆上達 52%」。要理解大規模測試，應另讀 TorchTPU 團隊刊於 PyTorch 的技術報告。

該報告的 Case Study 3 使用 Qwen3 MoE 235B，序列長度 4,096，採 BF16、SimpleFSDP／HSDP，並搭配 Pallas kernels、activation checkpointing 等最佳化。下面只摘錄同一張表的兩個端點；數字屬作者團隊測試，並非 AlphaLab 重跑。

TPU v7 晶片數	總批次量	MFU	每步時間
1,024	32,768	28.8%	29.3 秒
8,192	262,144	27.1%	31.2 秒

這張圖要傳達的是：增加資源並同時增加工作量後，整體吞吐量能持續放大。從表格可直接算出，晶片數與總批次量都增加八倍，而每步時間相近；它展示大型配方的弱擴展能力。若問題是「固定同一批工作，加八倍晶片能縮短多少時間」，則需要另一種固定工作量的比較。

MFU 可理解為模型有效浮點運算相對硬體理論運算能力的利用程度。它有助檢查硬體是否被用起來，卻不是另一種晶片的速度倍率，也不是帳單折扣。不同模型、精度與運算口徑的 MFU，應連同配置閱讀。52% 與 27.1% 來自不同描述，單看大小也不足以判定哪個系統比較好。

96.5% 的分母，也會改變你對相容性的理解

Of the tests that run on TPU, 96.5% pass.

中文：在實際於 TPU 執行的測試中，96.5% 通過。

Hugging Face，2026 年 10 月 20 日整合公告

Hugging Face 同時承認仍有失敗案例，並將 nightly CI 與公開儀表板描述為建置中的工作。這是合作方揭露的測試進度，值得參考；96.5% 的分母是有在 TPU 上執行的測試，不能改寫成全部 Transformers 測試通過率、Hub 模型支援率，或你的服務成功率。

同一篇文章的 kernel 加速數字，基準也是同一種 TPU 上的預設實作。這可以說明某些熱點值得最佳化，無法直接拿來宣稱 TPU 比 GPU 快同樣倍數。看到漂亮百分比，先找比較對象、測試單位與被排除的範圍，通常比先比較數字大小更有用。

AlphaLab 的判讀：值得增加選項，採用條件仍要寫清楚

一、我同意的改變，是降低開始比較的成本

研究與服務團隊的資產，除了模型權重，還包括除錯習慣、測試、部署工具與維護經驗。若能保留這些工作，嘗試另一種加速器的門檻會降低。開源也讓外部工程師更容易定位與回報問題。這些進展足以讓 TPU 進入更多團隊的候選清單。

二、我存疑的外推，是把熟悉介面直接換成便宜

晶片的每小時價格只是成本的一部分。第一次編譯、形狀改變後的行為、資料搬運、失敗重試，以及維護另一組配方的工程時間，都會影響每件合格工作的代價。Google 有擴大 TPU 採用的商業動機，Meta 與 Hugging Face 也參與整合；合作方背書能證明參與，不能代替獨立的通用成本審計。

三、弱擴展的價值，在大吞吐需求；固定任務要另開碼表

能把更大的工作量穩定分散出去，是訓練平台的重要能力。對小團隊而言，最急迫的問題可能反而是少量請求的等待時間、偶發長序列，或一個實驗多久能看到結果。先判斷自己的瓶頸，再決定哪張成績單有用，才能避免用大型叢集的答案解小工作負載的問題。

四、可對帳的承諾，是更新之後仍能完成同樣工作

原文想讓開發者在工具不必大換血的情況下取得硬體選擇。最值得追蹤的後續證據，是固定模型與品質目標後，每次更新需要改多少程式、重做多少調校，以及端到端成本能否維持改善。這與 TorchNeuron 的原生後端路線相鄰；本文特別補上 TPU 的弱擴展口徑與不同 MFU 成績不能混讀的問題。

下一步：先寫一張屬於自己工作負載的比較表

已有授權 TPU 測試環境的團隊，可以先選一個範圍小、品質能判分的模型；沒有環境，就先整理輸入形狀分布、精度、自訂算子與分散式依賴。先把比較條件寫出來，再決定是否投入試搬。

要回答的問題	應保留的證據
是否做對同樣工作？	固定模型、資料與品質門檻，保存輸出差異及失敗案例。
等待是否改善？	分開記錄首次編譯、暖機後吞吐量、尾延遲與形狀變動。
擴大資源有何用？	標明固定工作量或同步增加批次量，記錄實際晶片數。
總成本是否下降？	把實例、資料搬運、重試與工程時間一起除以合格完成量。

品質門檻可以接著用 AI Evals 的方法制定；效率倍率的閱讀可參考 MAI-Base-2 預訓練效率分析。若你關心供給面的算力，資料中心容量如何變成可用算力則補上硬體以外的交付條件。

TorchTPU 值得期待的，是讓換硬體更接近一場可做的比較。先要求同樣品質，再看延遲與總成本；當同一份工作在新版本與真實流量下仍然過關，這個新增選項才會變成可靠的部署能力。