一句話結論
Google 於 2026 年 10 月 20 日開源 TorchTPU（Apache 2.0、PyPI 套件 torch-tpu 0.2.0），讓原本為 NVIDIA GPU 寫的 PyTorch 程式只要把 torch.device("cuda") 改成 torch.device("tpu")、分散式後端從 nccl 改成 tpu_dist，就能搬上 Google Cloud TPU——這是雲端大廠第一次把「脫離 CUDA」做到「改兩行程式碼」的程度，但離 CUDA 崩塌還很遠。
事件：48 小時內，兩家雲端巨頭同時對 PyTorch 動手
這則新聞的重點不在單一產品，而在時間點。
- 10 月 19 日（週一）：Amazon 在 PyTorch Conference 2026（San Jose）把原本封測中的 TorchNeuron 轉為公開測試並開源，讓 PyTorch 應用可以直接跑在自家 AI 晶片 Trainium 與 AWS 上，不需重寫；同時宣布要向上游 PyTorch 提交程式碼，把各種功能與 NVIDIA 晶片的「硬綁定」拆開。
- 10 月 20 日（週二）：Google 宣布 TorchTPU 開源，目標是自家 Cloud TPU。
TechCrunch 的報導把這件事定性得很直白：Google 加入了 Amazon 的行列，一起攻打 NVIDIA 用 AI 應用開發者築起的堡壘。理由也很簡單——PyTorch 是目前 AI 應用的預設語言，據部分統計有 85% 的 AI 應用建立在它之上。PyTorch 由 Meta 在 2016 年開發，2022 年移交 Linux Foundation；它誕生的年代，NVIDIA GPU 早已是 AI 研究的標準硬體，因此很多功能天生就是為 GPU 寫的。
換句話說：誰控制了「開發者寫程式時面對的那一層」，誰就控制了硬體的銷售。 Google 與 Amazon 這次動的是這一層。
TorchTPU 到底是什麼？
用最白話的說法：它是讓 PyTorch 把 TPU 當成「原生裝置」的後端，取代過去要手動標註編譯區塊、基於 Lazy Tensor 的 PyTorch/XLA 老路線。
依 Google 官方部落格與 PyTorch 官方部落格的說明，核心架構可以拆成這幾塊：
| 層次 | 技術 | 白話解釋 |
|---|---|---|
| 裝置註冊 | PyTorch C++ Dispatcher 的 PrivateUse1 | TPU 變成 torch.device("tpu")，跟 cuda、cpu 平起平坐 |
| 張量語義 | 原生 torch.Tensor、一進程一裝置 | 保留 view（視圖）與原地修改（in-place）語義，不會出現 Lazy Tensor 那種「行為不一樣」的坑 |
| 執行模式 | Strict（預設）／Debug／DeferAndFuse | 除錯時開 TORCH_TPU_LAUNCH_BLOCKING=1；要效能開 TORCH_TPU_DEFER_AND_FUSE=1 自動融合算子 |
| 編譯鏈 | TorchDynamo → FX graph → StableHLO → OpenXLA/XLA | 走 torch.compile() 的圖模式，最後由 XLA 產生 TPU 機器碼 |
| 編譯快取 | 三層（進程記憶體／主機跨進程／GCS 遠端） | 避免每次啟動都重編譯，這在 TPU 上特別重要 |
| 算子 | 約 450 個核心 ATen 算子；自訂算子可用 Pallas／Tokamax／Helion | 覆蓋 LLM、視覺、語音的前向與反向運算 |
| 動態形狀 | Bounded Dynamism（有界動態性） | 設定形狀上限後只編譯一次，處理變動長度序列時不必反覆重編譯 |
值得注意的是 TorchTPU 不是 Google 自己關門做的。官方說法是與 Meta 的 PyTorch 團隊自 2025 年中開始聯合開發，並在推出前與 Hugging Face、Inferact（vLLM）、RadixArk（SGLang） 等社群專案對接，確保 TorchTPU 的函式庫行為跟原本 PyTorch 一致。這個組合很關鍵：vLLM 與 SGLang 是目前開源推論的兩大主幹，兩邊都支援，等於解決了「模型跑得動但伺服不起來」的問題。
Google 自報的效能與成本：好看，但要看清是誰說的
⚠️ 以下數字來自 Google 官方部落格與 SemiAnalysis 的測試，屬於「廠商自報 + 第三方實測」的混合，本站未獨立重跑。看數字時請記得這個前提。
| 情境 | 規模 | 官方宣稱數據 |
|---|---|---|
| 訓練（TorchTitan + Qwen 3 8B） | 8,192 顆 TPU v7x（Ironwood） | 52% MFU，接近線性弱擴展 |
| 訓練（Llama 3 405B，8K 文本） | 1,024 顆 TPU v7x | 每晶片每秒 500 tokens、50%+ MFU |
| 微調優化階梯（FLUX.1 12B） | 單機比較 | 未調優 Eager 11.49 秒 → DeferAndFuse 1.15x → SimpleFSDP 1.76x → Splash Attention 2.07x → 完整 torch.compile 3.80x，降到 2.78 秒 |
| 推論成本（Qwen 3.5 397B，vLLM-TorchTPU） | Ironwood，InferenceX 8K/1K | 每百萬 token 約 2.01 美分 |
| 推論成本（AgentX 長文本代理情境） | Ironwood | 每百萬 token 約 0.83 美分 |
| 模型覆蓋率（Hugging Face CI） | 4,917 個模型、500+ 架構家族 | Tier 1 模型無崩潰通過率 98%；Tier 2 架構與 GPU 數值對齊率 97% |
另一個值得記住的點：支援世代。官方文件與測試涵蓋 TPU v5e、v6e（Trillium）、v7x（Ironwood），架構上也已為下一代鋪路。這代表 TorchTPU 不是實驗品，而是對應到 Google Cloud 目前主力與下一代機隊。
至於「每 token 兩美分」這類數字，還有一個現實變數：它只算加速器成本，不含網路、儲存、資料搬運與人力。真正要比 TCO，得用自家的工作負載重跑一次。
開發者實際怎麼用？三步驟，但要先有 TPU
官方 README 給的路徑相當樸素，這也是這次最「有說服力」的地方——沒有新框架、沒有新語言。
步驟 1：安裝（官方原文）
python -m venv .venv
source .venv/bin/activate
pip install torch_tpu==0.2.0 --extra-index-url https://download.pytorch.org/whl/cpu
注意那個 --extra-index-url。README 特別警告：不加這個參數，pip 會安裝 CUDA 版的 torch——在這個「要脫離 CUDA」的專案裡踩到這個坑，算是很有象徵意義的細節。
步驟 2：改裝置與分散式後端
import torch
import torch.distributed as dist
# 原本的 GPU 寫法
# device = torch.device("cuda")
# dist.init_process_group(backend="nccl")
# TorchTPU 寫法
device = torch.device("tpu")
dist.init_process_group(backend="tpu_dist")
model = MyModel().to(device)
步驟 3：在 TPU VM 上跑。README 明講筆記本（Marimo 格式）需要跑在 TPU VM 上，最簡單是 v6e 的 GCE 執行個體。
如果你用 Hugging Face Transformers v5，依官方整合說明只要指定 device_map="tpu"；用 vLLM 走 vLLM-TorchTPU、用 SGLang 走 SGLang-TorchTPU，兩者都保留上游的 API Server 與排程器。
四倉庫結構：torch_tpu（後端）、vllm-torchtpu（推論）、sglang-torchtpu（推論）、torchtitan（大規模訓練）。
TorchTPU vs. TorchNeuron：同一天出生的雙胞胎，不同的宿主
| 比較面向 | Google TorchTPU | Amazon TorchNeuron |
|---|---|---|
| 目標硬體 | Cloud TPU（v5e／v6e／v7x Ironwood） | AWS Trainium 2／3 |
| 裝置名稱 | torch.device("tpu") | torch.device("neuron") |
| 編譯工具鏈 | TorchDynamo → StableHLO → OpenXLA | Neuron Compiler |
| 自訂 kernel | Pallas／Tokamax／Helion | NKI（Neuron Kernel Interface） |
| 專屬推論引擎 | vLLM-TorchTPU、SGLang-TorchTPU | vLLM Neuron |
| 分散式 | tpu_dist（DDP／FSDP2／DTensor） | FSDP／DTensor／DDP／TP |
| 上游策略 | 與 Meta、Hugging Face 合作鬆綁 CUDA 硬綁定 | 提交上游 PR 解除硬體綁定 |
兩家的策略其實是同一句話：把「PyTorch 原生支援」變成硬體的入場券。過去你要用 TPU 或 Trainium，得接受一套不太一樣的程式模型；現在兩家都在說「你什麼都不用改」。
五個還沒解決的限制（這才是判斷關鍵）
- 硬體綁在 Google Cloud。軟體是 Apache 2.0 開源，但 TPU 是 Google 自家 ASIC，你買不到、也搬不回自家機房。開源的是「上車的門票」，不是「車」。
- 單一使用者行程存取 TPU。目前 TPU 硬體只允許一個 user-space 行程存取，這讓「訓練與取樣放同一個行程」的 RL 同置（colocation）做法跑不起來，必須改用 Ray／VeRL 這類分散式解耦架構。
- MXU 的 256 對齊問題。TPU 的矩陣運算單元是 256×256 的脈動陣列；維度或 head dim 沒有補到 256 的倍數時，利用率會掉（例如 head dim 128 的模型，最多只能吃到一半）。這是硬體體質，不是軟體 bug。
- 第七代還沒有原生 FP4。Ironwood 在極低精度推論上仍需走 FP8／MXFP4 轉換，對比 NVIDIA Blackwell 的原生 FP4 加速仍有缺口。
- 純 Eager 模式很慢。出箱不調優的效能差很多，必須靠
torch.compile、DeferAndFuse或自訂 Pallas 算子才吃得到 TPU 的紅利——這代表「零改動」只成立在能跑，不成立在跑得快。
還有一個務實門檻：目前 GitHub 上 google-pytorch/torch_tpu 只有約 200 顆星、超過 250 個 open issue（2026-10-20 以 GitHub API 查詢）。剛開源的專案本來就是這個樣子，但這說明它現階段是「可以開始試」，不是「可以放心上 production」。
另外有個小細節值得記錄：GitHub API 回報的授權欄位是 Other / NOASSERTION，但 repo 內的 LICENSE 檔案本文是 Apache License 2.0。API 的授權偵測對這種多層目錄的授權檔常常判不出來，遇到類似狀況請以 LICENSE 檔案本文為準。
對 CUDA 護城河的影響：不是崩塌，是「轉換成本」被壓低
把情緒拿掉，這件事的實質影響有三層：
第一層：轉換成本（switching cost）被壓低。 過去企業要從 CUDA 換到別家硬體，得重寫核心邏輯與 MLOps 管線，動輒數月；現在是「改 1～2 行 + 換後端」。門檻一旦低到「一週可以試一次」，採購談判的空間就出現了。
第二層：抽象層上移。 當開發者寫的是 PyTorch / torch.compile，而不是裸 CUDA 語法，底層是 GPU、TPU 還是 Trainium，就越來越像「可替換的計算資源」。這才是 Google 與 Amazon 真正想要的位置——把晶片變成耗材，把框架變成合約。
第三層：但 CUDA 不會明天就倒。 CUDA 的護城河不只編譯器，還包括除錯工具鏈、十幾年的教學文件、大學課程、以及整整一代熟悉它的工程師。這些東西不會因為一個後端開源就消失。比較合理的描述是「漸進侵蝕」——轉換成本下降 + 非 NVIDIA 硬體每美元性價比拉開，慢慢改變採購比例。
至於 SemiAnalysis 那句「Ironwood 在推論每美元效能上比 B200 高 19%–50%」、以及「高併發情境下 TCO 優勢可達 76.7%–130.2%」，屬於第三方分析機構的特定測試條件結論，不是在說 TPU 全面比較強。拿來當「值得重新試算成本」的訊號可以，拿來當結論就過頭了。
對台灣開發團隊的實務意義
- 如果你的模型服務跑在 GCP 上，這是最該排進 backlog 的一次測試：把一個推論服務用
vLLM-TorchTPU起起來，量一下自家真實流量的每 token 成本，跟現在的 GPU 帳單對照。一天就能有答案。 - 如果你的服務在 AWS 或自建機房，TorchTPU 對你的意義不是「快點搬」，而是「多了一個議價籌碼」。
- 如果你在做推論最佳化，值得先讀 vLLM-TorchTPU 與 SGLang-TorchTPU 的實作差異（前者走 Pallas megakernel，後者保留 RadixAttention prefix cache 並做 HBM／host DRAM 兩層 KV 快取），因為它們決定了你在 TPU 上的吞吐上限。
- 不要現在就為了 TorchTPU 改寫架構。200 顆星、250 個 open issue 的專案，適合放在 side project 與 benchmark 裡，不適合放在核心服務的關鍵路徑上。
站內延伸閱讀
- vLLM：具備 PagedAttention 的高吞吐量 LLM 推論引擎 — 這次 TorchTPU 的推論主力就是 vLLM，先搞懂它的排程與 KV 快取
- GGUF 量化完整教學 2026：Q4_K_M、Q5_K_M、Q8_0 差在哪？VRAM 怎麼算？ — 換硬體前先把「精度 vs 記憶體」這筆帳算清楚
- AMD 正式反擊 NVIDIA！Helios 機櫃級 AI 系統效能超越 Vera Rubin 15% — 另一條「去 CUDA 化」路線：換硬體而不換軟體堆疊
- AirLLM 完整教學 2026：4GB 顯卡跑 70B — 沒有 TPU 預算時的省 VRAM 路線
資料來源與查證方式
- TechCrunch，Julie Bort，〈Google has joined Amazon in attacking Nvidia’s stronghold with AI app developers〉，2026-10-20 — 連結
- Google Cloud Blog，〈TorchTPU is now open source: Run native PyTorch on TPUs〉（經 NotebookLM 彙整）
- PyTorch 官方部落格，〈Introducing TorchTPU〉（經 NotebookLM 彙整）
- Google Developers Blog，〈Announcing New vLLM and SGLang Inference Engines on TPU〉（經 NotebookLM 彙整）
- GitHub
google-pytorch/torch_tpu：README 安裝指令、功能清單、LICENSE 本文；星數／issue 數／授權欄位以 GitHub API 於 2026-10-20 查詢 - MarkTechPost、Unite.AI 對本次發布的技術拆解（經 NotebookLM 彙整）
- SemiAnalysis InferenceX 成本測試數據（第三方分析，非本站實測）
查證邊界：本文未在 TPU VM 上實際執行 TorchTPU，安裝步驟與參數取自官方 README 原文；效能與成本數字為 Google 官方與 SemiAnalysis 的宣稱，本站未獨立驗證。若官方後續更新版本或數據，以官方當下公告為準。