InfoQ 於 2026 年 10 月 25 日報導，在美國聖荷西舉行的 PyTorch Conference North America 2026 上，Google 與 Meta 宣布開源 TorchTPU，這是一套讓 PyTorch 能原生執行於 Google Tensor Processing Units（TPU）的後端。Meta 是 2016 年創建 PyTorch 的公司，其軟體工程師 Zongwei Zhou 在 10 月 21 日的主題演講中表示，Meta 計畫用 TorchTPU 把更大規模的大型語言模型工作負載搬到 TPU 上。這項宣布不只是新增一個硬體選項，而是試圖改寫 PyTorch 與非 GPU 加速器之間的整合方式。
背景與問題：從 PyTorch/XLA 到原生後端 過去 PyTorch 要在 TPU 上執行，主要透過 PyTorch/XLA。這是一套 2020 年出現的 lazy-tensor 橋接方案，lazy tensor 的意思是運算不會立刻逐項執行，而是先累積成圖再編譯，以配合 XLA 編譯器與 TPU 的執行模式。問題在於，依此次公告說法，舊方案需要侵入式修改原始程式碼，對模型開發者與維護團隊造成負擔。TorchTPU 的目標是把移植模型簡化到近似一行程式碼：把 model.to("cuda") 改成 model.to("tpu")。Google Cloud 在公告中表示，有了 TorchTPU，TPU 就和 GPU、CPU 一樣，成為 PyTorch 的原生選項；該公告由 Core ML/AI 工程副總裁 Bill Jia 共同撰寫。
Bill Jia 與 Zongwei Zhou 的主題演講題為 Workload Fungibility in the Agentic Era: Bringing Native PyTorch to Cloud TPUs，工作負載可替換性（fungibility）是核心概念。PyTorch Foundation 執行董事 Mark Collier 在先前的演講中指出，推論已經超越訓練，成為資料中心最大的工作負載，市場對 token（模型輸入輸出的基本計量單位）產生「難以置信的渴求」。他描述社群目標是讓模型能在任何雲、任何晶片執行，並連接到任何代理。基金會投影片也用數字呈現市場變化速度：DeepSeek 的 Flash 模型在 37 天內便宜 60%，Kimi K3 在相同硬體上於 33 天內快 68%。Agentic AI Foundation 執行董事 Mazin Gilbert 則表示，代理的 token 消耗量在 2026 年 2 月 6 日超過人類消耗量，之後成長 14 倍，而人類同期只成長 2.8 倍，形容這是一條爆炸性曲線。不過，這些公開數據來自單一平台 OpenRouter，實務上引用前必須先確認適用範圍。
核心內容：技術路徑與生態系 TorchTPU 的關鍵在於接入 PyTorch 的低階 dispatcher。dispatcher 是 PyTorch 決定某個運算要交給哪個後端實作的機制，因此硬體廠商能在不改造上層模型的情況下註冊自己的執行路徑。演講者表示，Hugging Face 模型可直接使用，vLLM 與 SGLang 推論引擎可原生執行，TorchTitan 則支援稠密模型、混合專家模型（mixture-of-experts, MoE）與擴散模型的規模化訓練。Ray 與 llm-d 負責在 Kubernetes 上跨主機擴展 TPU 工作負載。此次開源的專案共有四個：TorchTPU、vLLM-TorchTPU、SGLang-TorchTPU 與 TorchTitan。
規模化成果方面，Bill Jia 展示超過 8,000 顆 TPU 晶片時仍接近線性擴展，且每晶片吞吐量隨叢集變大大致保持穩定。Google 公布的結果包括：Qwen3 235B 混合專家模型在 8,192 顆 TPU v7x 上執行，達到 28% 模型 FLOPs 利用率（衡量硬體有效算力使用程度的指標）。不過公告也坦承，一行程式碼只是起點。因為模型的形狀、分片（sharding）與運算算子可能偏向 GPU 架構，單靠改裝置字串無法達到 TPU 尖峰效能，但模型應該可以開箱即用。為了補上調校落差，Jia 宣布 TPU agent suite，已在 GitHub 預覽，能接入程式開發輔助環境，自動化處理上線、診斷與效能調校。Zhou 表示，Meta 的 PyTorch 團隊與 Google 共同開發 TorchTPU，目標是讓 TPU 成為「第一級原生 PyTorch 目標」，以滿足生產環境對效能、可靠性與可維護性的需求，並強調一切都是開源且今日可用，這只是開始。Meta 的 PyTorch 工程總監 Jana van Greunen 則在 Google Cloud 公告中說明動機：Meta 推進 AI 前沿需要巨大運算規模與深度硬體多樣性，不能被單一硬體架構限制。
產業脈絡：可攜性與新型鎖定 Google 並非唯一採取此路線的廠商。AWS 在 10 月 20 日把 TorchNeuron 推進公開測試，這是針對自家 Trainium 晶片的原生 PyTorch 後端，唯一程式碼變更是 .to('neuron')。兩個後端都透過 PrivateUse1 註冊；PrivateUse1 是 PyTorch 提供給自訂硬體的擴充點。TorchNeuron 首版仍有缺口：The Next Web 報導指出，它尚未支援動態輸入形狀，並略過約 22,000 個 PyTorch 測試。Blair Hayes 在 Forkast 的分析中主張，鎖定並沒有消失，只是轉移了位置：PyTorch 擴充點提供開發者共通語言，但最佳化與供應層仍牢牢由廠商控制。在 Hacker News 上，TorchTPU 發布討論達到 379 分，反應中既有鬆一口氣，也有實務疑慮。有留言說，以前必須和 XLA 搏鬥才能讓 PyTorch 跑在 TPU 上，現在終於有第一方支援；也有人問到底哪裡可以買到 TPU。一名任職公司的留言者曾評估 Google 地端 TPU，但態度保留，表示他們決定至少再等一個世代，繼續使用 Nvidia。
訓練、部署與工具鏈 可攜性訴求也延伸到資料中心之外。在部署機器人策略的 ExecuTorch 議程中，Meta 的 Anthony Shoumikhin 與 Jacob Szwejbka 主張，策略模型可以從訓練到裝置端都留在 PyTorch，不需要轉換堆疊；同一套量化與算子圖可執行於 NVIDIA Jetson 上的 TensorRT，以及 Intel 上的 OpenVINO 等目標。訓練場次則把成本數字講得更清楚。RadixArk 的 Yueming Yuan 介紹 Miles 強化學習框架時表示，把兩個 log-probability 計算融合成一個 kernel，使該步驟快超過 10 倍。Delta updates 在一次大型執行中，把每次權重同步搬移的資料量從 62 GB 降到 1 GB 以下。強化學習訓練代理的開源工具也貫穿多場議程：Anyscale 的 SkyRL 將訓練、推論與環境分離，並用 Ray 協調；Hugging Face 的 OpenEnv 在 10 月 22 日加入 Agentic AI Foundation，讓每個 RL 環境有一致介面。Hugging Face 的 Sergio Paniego Blanco 使用 TRL 與 OpenEnv，透過四個程式代理訓練一個小型 Liquid AI 模型，使其在保留任務上的分數從 42% 提升到 54%。
影響與限制 對考慮搬遷的團隊而言，這項進展的實務意義是：一行裝置變更能讓模型跑起來，但不代表已調校到最佳狀態，因此必須為分片與 kernel 工作編列預算，並先確認 TPU 容量。TorchTPU 讓 PyTorch 生態系多了一條原生 TPU 路徑，並以 vLLM、SGLang、TorchTitan、Ray 與 llm-d 覆蓋推論、訓練與跨主機擴展；然而，公告本身也點出形狀、分片與算子偏好帶來的效能限制，而 AWS TorchNeuron 的功能缺口與廠商控制最佳化層的爭論，說明可攜性提升不等於硬體鎖定完全消失。想進一步了解的開發者，可以閱讀 TorchTPU 公告與 repository，或參考 InfoQ 對 PyTorch Conference 2024 的報導；議程錄影預計在活動後兩週內上架 PyTorch Foundation 的 YouTube 頻道。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。