官方示範只改一行。Google 在 PyTorch Conference 把 TorchTPU 開源，和 Meta 的 PyTorch 團隊一起寫進部落格的句子是：把 model.to("cuda") 換成 model.to("tpu")，既有工作負載就能在 TPU 上跑。同一段括號立刻把峰值拿掉——模型的形狀、切分與算子若本來就偏向 GPU 架構，那一行改完只保證「能跑」，不保證吃滿矩陣單元。
Google Cloud 文件比新聞稿更硬：TorchTPU 取代 PyTorch/XLA，新工作負載請用它，舊的請遷過來。TechCrunch 把同一場發布寫成 Google 加入 Amazon，一起打 NVIDIA 靠 CUDA 鎖住開發者的那層軟體護城河。科技新報轉述同一組數字：約 85% 的 AI 應用寫在 PyTorch 上；那套工具 2016 年從 Meta 長出來時，NVIDIA GPU 已經是研究標配。
Amazon 的 TorchNeuron 先一天進場，裝置字串是 "neuron"，授權寫 Apache 2.0。Google 這次沒在公告裡把 TorchTPU 的授權寫死，但四個倉庫一起放：TorchTPU、vLLM-TorchTPU、SGLang-TorchTPU、TorchTitan。安裝指令是 pip install torch_tpu。Hacker News 首帖 13 小時內超過 300 分、60 多則留言；有人問這是不是在回應同一天 DeepSeek 開源推理框架，回覆幾乎同一句：大會時程排了好幾週，不是早上讀新聞下午交貨。
改一行能跑。峰值要另寫 kernel、對齊拓樸，還得接受 TPU 一顆只能被一個使用者行程佔住。
官方示範改一行，同一份文件把峰值拿掉
PyTorch 官方部落格把原則寫成三條，讀起來不像行銷。第一條叫 PyTorch Citizenship：執行期不依賴 JAX；要有紮實的 eager；torch.compile() 走 TorchDynamo 而不是 Lazy Tensor；分散式訓練 的 DDP、FSDP、DTensor 從 Process Group 這一層就接到 TPU collectives。第二條叫 Focus on the User：遷移應該像改 device 字串那麼短，但「不能靠那一次修改拿到峰值」。第三條才是效能野心：eager 要靠 JIT 把「一顆算子送一次」和「整圖編譯」中間那截補起來，並且用 bounded dynamism 減少形狀一變就整圖重編。
這三條等於承認兩件事。PyTorch/XLA 從 2020 年用 Lazy Tensor 硬接 TPU，跟不上社群把 PyTorch 往命令式、分散式、編譯器前端推的速度；編譯延遲高、沒有原生 eager、新興分散式原語落後。另一件事是硬體現實沒有被軟體一句話抹平。TPU 的 TensorCore 比較像單執行緒處理器，後面掛超寬的脈動陣列；要吃滿 MXU，張量寬度得夠。GPU 可以靠很多較小的 kernel 並行把 SM 填滿。官方自己寫：這跟 GPU 的使用方式不一樣。
安裝之後，裝置註冊靠 PyTorch 的 autoload。文件給的最小例子是 device = torch.device("tpu")，張量可以直接 device="tpu"。分散式後端從 nccl 換成 tpu_dist。想寫成硬體無關，可以用 torch.accelerator.current_accelerator()，讓同一支腳本在 GPU 與 TPU 之間切。torch.compile(model, backend="tpu") 已經能註冊成 Dynamo 後端；暫時限制是在 TPU 機器上會自動把 dynamic=False，因為 bounded dynamism 還沒當預設打開。
精度預設也不一樣。CUDA 上 PyTorch 預設 highest（純 FP32）；TorchTPU 預設 medium，也就是乘法走原生 BF16、累加走 FP32。TPU 的 MXU 就是為這一檔設計的。若你堅持 high，官方用三遍交叉項去逼近 FP32，MXU 計算量大約 3 倍；highest 六遍，大約 6 倍，而且會丟 TORCH_WARN_ONCE。多數深度學習工作負載被建議留在 medium。這不是小字。你若把一條在 GPU 上用 FP32 收斂的訓練腳本原樣搬過來，第一個該核對的不是速度，是 loss 還能不能對上。
Eager 還拆三種模式。預設 Strict：一顆 Aten 算子送一次，TPU 非同步執行，對齊你在 GPU 上習慣的 eager。Debug 把 TORCH_TPU_LAUNCH_BLOCKING=1 打開，變成同步，順便開邊界檢查。DeferAndFuse 把多顆算子攢到物化點（例如 .to("cpu")）再一起編譯，官方寫可以比 Strict Eager 快 50% 以上，並且因為融合少生暫時張量，尖峰 HBM 也比較低。這是 TorchTPU 自己加的混合檔，不是 PyTorch 上游的預設行為。
算子覆蓋寫「約 450 個 Aten ops」，略過結構性或 composite delegate；主流深度學習架構需要的 Core ATen，正向與反向都有。自訂 kernel 兩條已標 production ready：一條用 Pallas 包進 torch.tpu.pallas.jax_op，一條走 Tokamax 函式庫（MoE 的 grouped matmul、paged attention、gated deltanet、Kimi delta attention、MLA、TopK）。Helion DSL 還在實驗，賣點是同一套 PyTorch 風格程式可以對多種加速器。換句話說，執行期號稱不依賴 JAX，kernel 作者卻仍可能寫 Pallas。Hacker News 有人問「那 Jax 對 PyTorch 是不是只剩風格差異」，這正是那個縫。
PyTorch/XLA 被寫進「建議遷移」
Google Cloud 文件把動機寫得很乾：Cloud TPU 過去搭配 JAX 與 TensorFlow；PyTorch 要上 TPU，得走 PyTorch/XLA 的 lazy-tensor 錄圖，還得自己標記可編譯區段。TorchTPU 預設 eager，採 PyTorch 標準的「一裝置一行程」，現有工作負載與函式庫不必改結構。文件加了一句 Note：TorchTPU 取代 PyTorch/XLA。
這句話對還在維護 torch_xla 腳本的人，比開源本身更重。標記編譯區、忍受編譯延遲、沒有原生 eager——這些不是口碑，是官方現在願意寫進文件的失敗原因。TorchAX 也被點名，說那是把 PyTorch 塞進 JAX 的做事方式。TorchTPU 要當「原則上的 PyTorch 後端」，不是又一次翻譯層。
硬體側，部落格給了一組當代 TPU 的公開規格，方便你對表，而不是只聽「更快」。TPU 8i 的 HBM 寫 288 GB、頻寬 8.6 TB/s。TPU 8t 與 8i 的晶片間互連 ICI 寫雙向 19.2 TBps，切片內是 3D torus 或 Boardfly。跨切片走資料中心網路 DCN，TPU 8t 寫雙向 400 GBps。程式模型仍經 XLA：上層 IR 是 StableHLO，下層自訂 kernel 走 Mosaic；真正的 TPU ISA 專有、會改、不公開。對開發者來說，StableHLO／Mosaic 的位置接近 GPU 上的 PTX。
有一條限制會直接改工作流。一顆 TPU 只能被一個使用者空間行程存取。TorchTPU 為了對齊 PyTorch 生態，分散式採一裝置一行程，對上 JAX 的一主機一行程。代價是 RL 的訓練與取樣難以在同一顆裝置上共置，官方寫「正在找辦法放寬或繞過」。你若現在的後訓練迴圈把 trainer 和 sampler 釘在同一張卡上省 HBM，這條不能當「改 device 字串就好」。
分散式初始化也比 torchrun 預設多兩個變數：TORCH_TPU_TOPOLOGY（例如 "2,2,1"）和 TORCH_TPU_SLICEBUILDER_ADDRESSES（每顆裝置一個連接埠，用來組 ICI 網）。Cloud 環境可以用 torch.tpu.distributed.set_tpu_launch_env() 代填。單機八顆的啟動範例是先 eval $(python -m torch.tpu.distributed | sed 's/^/export /')，再 torchrun --nproc_per_node=8 train.py。
Collectives 預設走 Skinny Collectives：每一個集合通訊編成自己的「瘦」StableHLO 模組，保證各 rank 的 buffer 與同步旗標一致，避免 MPMD 造成死鎖或記憶體破壞。官方寫這個預設可能讓端到端再慢 30–40%，因為 XLA 沒辦法把計算和通訊重疊進去。補救有兩條可選：@spmd_safe 裝飾器，讓編譯器看見大圖裡的 collectives；以及還在 RFC 的 Compilation Handshake，用環境變數 TORCH_TPU_SPMD_HANDSHAKE_STAGE 控制要不要在編譯或派送前對圖。用錯 @spmd_safe 的風險，官方自己寫成「脆弱」。
拓樸感知的 mesh 不是裝飾。官方表格把張量平行（每層 all_reduce／reduce_scatter）放到最快的 ICI 環；context／sequence parallel 與 expert parallel 的 all_to_all 留在切片內；FSDP 的 all_gather／reduce_scatter 也走本地 ICI；純資料平行的梯度 all_reduce 才允許跨切片走 DCN。API 叫 torch.tpu.topology_aware_mesh()。GPU 上你用錯 mesh 多半只是慢一點；TPU 上 ICI 與 DCN 差一個數量級，用錯就是把每層通訊趕到乙太網。
覆蓋率與效能數字
「改一行就能跑」最容易被打槍的地方，是熱門權重根本過不了編譯。官方用持續測試回這槍。語料約 5,000 個 Hugging Face 模型，涵蓋 NLP、視覺、音訊、多模態與擴散，TPU 代數從 v5e 起測 eager 與 compiled。篩法分兩層：第一層看下載與趨勢，Qwen、Gemma、Mistral、DeepSeek、GLM、Kimi、Llama、Whisper、Stable Diffusion、FLUX、ViT 都在；第二層保證 500 多個架構家族至少各有一個代表，用來對 GPU 基線做數值核對。
截止寫進部落格時的表是這樣：
| 項目 | 口徑 | 數字 |
|---|---|---|
| 端到端測過的開源模型 | distinct 權重 | 4,917 |
| 架構家族 | Transformers、Diffusers 等 | 500+ |
| 第一層：不崩潰 | 熱門 LLM／視覺／音訊／多模態 | 98%（4,821／4,917） |
| 第二層：數值對得上 GPU | 架構代表 | 97%（638／657） |
| Bounded dynamism 數值 | 839 個因果 LLM | 99%（834／839） |
因果 大型語言模型 的通過條件是 TPU 與基線的 perplexity 相對差在 0.10 以內。視覺、音訊、encoder 用相對 MSE：相對 MSE ≤ 0.10，或絕對 MSE < 0.05。這不是「我們抽測了幾個明星模型」。4,917 這個分母本身就是聲明：失敗的那 96 個會是你第一批該自己復現的名單，官方沒把失敗清單公開貼在同一頁。
開箱效能他們用 Muse Glimmer 30B 的純 PyTorch 實作示範，只用 nn.Linear、nn.RMSNorm、F.scaled_dot_product_attention 和原生 collectives，故意不用模型專屬 kernel。單顆 TPUv7（對 PyTorch 露出兩個裝置，對應兩顆 TensorCore，所以 推理 用 world size 2 的 FSDP）：
| 場景 | 序列長度 | 吞吐量 | MFU |
|---|---|---|---|
| 單晶片推理（prefill） | 5,120 | 約 25.7k token／秒 | 59% |
| 單晶片推理（prefill） | 10,240 | 約 22.4k token／秒 | 51% |
| 4 晶片訓練（單主機，FSDP） | 5,120 | 每顆約 5.6k token／秒 | 38% |
| 4 晶片訓練 | 10,240 | 每顆約 4.6k token／秒 | 32% |
同一份 GPU／CUDA 出身的 TorchTitan 實作，只把尚未支援的 FlexAttention 換成普通 SDPA，再加上 torch.compile 與 SimpleFSDP，4 顆 TPUv7 訓練變成每顆約 5.3k token／秒（36% MFU，序列 5,120）與 4.2k（29% MFU，序列 10,240）。官方要證明的是：純 PyTorch、甚至原本為 GPU 寫的程式，在 TPU 上「夠用」。下一句立刻補：生產若要峰值，請走 Pallas 與 vLLM-TorchTPU、SGLang-TorchTPU、TorchTitan-TorchTPU。
Pod 規模他們拿 Qwen3 MoE 235B。64 顆 TPU v7 的冒煙測試：TorchTitan 1,828 token／秒，JAX／MaxText 1,937 token／秒。然後弱擴展拉到一顆 v7 Pod：
| 拓樸 | TPU v7 晶片 | TensorCore | 全域 batch | 每 TensorCore token／秒 | MFU | 步時 |
|---|---|---|---|---|---|---|
| 1 切片 FSDP | 1,024 | 2,048 | 32,768 | 2,236 | 28.8% | 29.3 秒 |
| 2 切片 HSDP | 2,048 | 4,096 | 65,536 | 2,214 | 28.5% | 29.6 秒 |
| 4 切片 HSDP | 4,096 | 8,192 | 131,072 | 2,095 | 26.9% | 31.3 秒 |
| 8 切片 HSDP | 8,192 | 16,384 | 262,144 | 2,104 | 27.1% | 31.2 秒 |
設定寫死：每 TensorCore local batch 16、序列 4096、BF16 混精、Tokamax Splash Attention、融合 cross-entropy、MoE grouped matmul、94 層 scan、activation offload、collective pipelining、全量 activation checkpoint、Graph Trainer。MFU 停在 27–29%，不是 52%。52% 那筆是 Qwen 3 8B 在最多 8,192 顆 Ironwood 上的另一條路徑，Google Cloud 部落格分開寫。標題若只留 52%，會把稠密小模型的上限，說成 235B MoE 的實績。
Llama 3 405B 在 1,024 顆 TPU v7x、8K 上下文窗口、BF16，官方寫每晶片 500 token／秒、MFU 超過 50%。FLUX.1-dev 那條優化故事更完整：開箱 eager 步時 11.49 秒 → DeferAndFuse 9.95 秒（1.15×）→ SimpleFSDP 6.52 秒（1.76×）→ SplashAttention 5.55 秒（2.07×）→ torch.compile(backend="tpu") 3.02 秒（3.80×）→ peephole 2.78 秒（1.08 samples／秒）。從 8 顆 v6e 拉到 256 顆，每樣本步時只從 0.92 秒走到 1.00 秒。這組數字證明的是「compiler-friendly 的 FSDP 加上 kernel 之後能近線性擴展」，不是「改一行就有 3.8 倍」。
推理、訓練、推薦三條產品線
Google Cloud 那篇比較像產品發布，把生態一次鋪滿。Meta PyTorch 工程總監 Jana van Greunen 的引言很直：不能被單一硬體架構卡住；TorchTPU 讓他們把 LLM、廣告與推薦工作負載部署到 Google TPU，並把意見直接送回工程團隊。Hugging Face 產品副總 Jeff Boudier 寫 Transformers v5 只要 device_map="tpu"；Diffusers 支援 eager、torch.compile 與張量平行。夜間 CI 專門跑 Transformers 套件。
推理側分三家。vLLM 的原生 PyTorch 後端和 Inferact 一起做，保留上游 worker、排程與 API 伺服器，加上連續批次、量化、多晶片平行與自訂 Pallas kernel。執行長 Simon Mo 的引言強調高吞吐量、低延遲、記憶體效率。SGLang 與 RadixArk 合作，賣點是 RadixAttention 重用請求間的 KV 快取，複雜多步生成少重算；CTO Banghua Zhu 說這條路讓他們把 SGLang 鋪到不同矽上的速度變快。分散式艦隊則放 llm-d 1.0，和 Red Hat、IBM 以及超過 500 名貢獻者、25 個組織一起，已進 CNCF Sandbox。路由器按前綴快取把請求送到已經握有上下文的副本，並把算力重的 prefill 與記憶體重的 decode 拆開。GKE 上同一組端點可以挑 GPU 或 TPU。
客戶引言來自 Zenteiq：用 GKE Inference Gateway（llm-d）做科學基礎模型的合成資料，前綴快取感知路由之後，每 1,000 顆 TPU v6e 的日產能從 1.47 億 token 拉到 5.97 億，約 4 倍。這是單一客戶、單一工作負載的數字，不是公開榜。
獨立評測 Google 引用 SemiAnalysis 的 InferenceX。官方轉述：TPU v7 配 vLLM-TorchTPU，InferenceX 8K／1K 每百萬 token 成本 2.01 美分，低於他們 9 月首次登場的 3.6 美分；AgentX（多輪、長上下文、高前綴重用、子代理突發）每百萬 token 0.83 美分，並稱 4 顆 v7 就站上 Pareto 前沿。這組數字要當成 Google 引用的第三方審計來讀，原始報告標題他們寫成 TPU Inference Externalization Full Steam Ahead — InferenceX。達成這組 TCO 的手段，部落格自己列了三個瓶頸級 kernel，不是開箱設定：
把 expert-parallel 的 MoE 層收成一支 SPMD 程式。原本在 DP8＋EP、concurrency 256 的 prefill 重負載下，reduce-scatter 單層要 1,190 微秒，佔裝置時間 22%，旁邊沒東西重疊。改完之後，每顆 TensorCore 把列量化成 FP8，用 SparseCore 非同步 all-gather；同時 Pallas top-k 選專家，再對專家索引與列縮放做第二次小 all-gather；本地專家的兩次 matmul 用遠端 DMA 把結果推回擁有該 token 的 TensorCore。單層因此拿掉 routed-row argsort、SparseCore permute／combine、兩次 grouped matmul，以及 combine 的 reduce-scatter。
Sequence-on-Lane 的注意力佈局解決 FP8 KV 快取的填充。TPU 向量單元以 32-bit word 工作，四個 FP8 值共用一個 word。8 路張量平行時每核只握模型兩個 KV head 之一，於是每個 word 一半是填充：每 token 每核 1,024 bytes 快取只裝 512 bytes 資料。新佈局把一頁的 token 沿 128 lanes 排、head 維度沿 sublanes，同一個 token 的四個值住進同一個 word，KV 記憶體與每步讀取減半。vllm-torchtpu 現在把這當成通用佈局。
Gated DeltaNet 佔 Qwen 3.5 60 層裡的 45 層，每頭固定 128×128 狀態而不是增長的 KV。concurrency 64 的 decode，把 kernel 裡所有算術拿掉也只再快 6%——瓶頸是狀態讀寫。官方用一支 Pallas kernel 把 convolution 與 recurrence 融合，decode 批次化，prefill 切 64 token 塊改寫成矩陣乘；狀態和 KV 快取共用 paged pool。這些是「2.01 美分」背後的工程，不是 device="tpu"。
訓練側，TorchTitan 已有 Llama 3 70B／405B、Qwen 3 8B／32B、MuseGlimmer 30B、Qwen 3 235B MoE、FLUX.1 12B 的配方，驗證跑到 8,000 顆 Ironwood（TPU v7x）。後訓練把 TorchTitan 接進 VeRL 的 GRPO：微調 與 RL 對齊時，TPU 後端與端到端參考配方已經上游。SimpleFSDP 被反覆強調，因為 FSDP2 用 module hook 插入 all-gather／reduce-scatter，會把 torch.compile 打成逐算子派送；SimpleFSDP 把集合通訊寫成可被追蹤的普通算子，XLA 才能融合、重疊、並把通訊卸到 SparseCore。
推薦模型走另一條矽。和 Meta 把 TPU 後端做進 TorchRec，瞄準 DLRM 這類高基數 embedding。32 顆 TPU v7x 上的 DLRM v2，官方寫步時 18.3 毫秒，與高度優化的 JAX 基線 100% 持平，loss 軌跡相同。這組數字用的還是基線 SparseCore kernel，進階管線還沒算進去。廣告與推薦是 Meta 願意在引言裡點名的生產負載，不是附贈 demo。
邊緣側，LiteRT（前 TensorFlow Lite）加入 PyTorch 生態。litert-torch.convert() 一次呼叫，建立在 torch.export() 與 Core ATen 上；LLM 可從 Hugging Face Transformer 轉去 LiteRT-LM，跑 Android、iOS、macOS、Windows、Linux、Web 與 IoT，加速路徑含 CPU（XNNPack）、GPU（開源 ML Drift）與各家 NPU。TPU agent suite 同步以預覽放上 GitHub，宣稱能自動處理上線、診斷、提問與推理效能調參，外掛接好幾種編碼 harness 與模型組合。TechCrunch 把它寫成 Google 比 Amazon 多做的那一層：不只改裝置字串，還派人（這裡是代理）幫你搬。
Ray 把 TPU 收成一等加速器，同一條工作流可把資料處理、訓練、RL、服務分別排到 CPU、GPU、TPU。Anyscale 首席架構師 Edward Oakes 的引言把它接上他們在 Ray Summit 講的 PARK 堆疊：PyTorch、AI 模型、Ray、Kubernetes。Google Cloud Next 那年已經把代理平台與雙 TPU 當整套系統賣，見：企業 AI 開始改買整套系統。這次開源的是那套系統底下，PyTorch 開發者每天要碰的那一層。
Amazon 同一週、NVIDIA 的護城河還剩什麼
Amazon 的說法幾乎用同一句話開頭：約 85% 的研究者與開發者把程式寫在 PyTorch；硬體選擇遠比程式本身窄。TorchNeuron 讓現有程式在 Trainium 上跑，改的是設定不是重寫，公開測試版對準大會，倉庫在 github.com/aws-neuron/torch-neuronx，授權 Apache 2.0，支援 Trainium2 與 Trainium3。裝置字串是 "neuron"，走 PyTorch 的 PrivateUse1。Eager（含新的 adaptive eager）、torch.compile、NKI 自訂 kernel、torch.profiler 對到 Neuron Explorer，都寫進 Neuron SDK 2.33 的發佈說明。
Amazon 多做了一件 Google 這次沒對齊宣傳的事：往 PyTorch 主專案提交程式，把框架裡綁死特定晶片的程式碼拆掉，讓預設就對任何硬體更開放。官方新聞稿還寫，每次建置對上「數十萬」個模型。早期採用者點名 Cartesia 的即時語音，以及 Lieber Institute for Brain Development 的藥物標的探索。Hugging Face、TorchTitan、vLLM 一樣被列成合作名單。vLLM Neuron 那一側給了可核對的相對數：相對 Neuron 2.32，GPT-OSS-120B 吞吐量最高約 2.5 倍，Qwen3-VL-32B 最多約 38%。
兩家雲的時程重疊不是巧合。Hacker News 留言第一層就有人貼 TorchNeuron 的 GitHub，下一則回「大會就在今天」。科技新報把結論寫成：晶片競爭從硬體效能與成本，延伸到軟體生態主導權。Amazon 想把 Trainium 賣到 AWS 之外的那條線，站內六月寫過：不再只是自研降本，而是雲商正面對打 NVIDIA。Google 這次是同一條戰線的另一端：TPU 過去最痛的不是峰值 flop，是 PyTorch 使用者不願意為它改架構。
CUDA 會不會因此塌，留言區比新聞稿誠實。有人寫「CUDA 當護城河那套，我們早就過了，跳到另一個對等堆疊在軟體上已經很普通」。下一則把硬體可得性拉回來：TPU 近乎買不到，Google 這次努力對他沒用；AMD 理論上更有機會給 NVIDIA 壓力，但看 GB300，NVIDIA 仍可能領先可行對手十年。另有人寫企業已經評估過 TPU 落地，決定再跟 NVIDIA 一代。TechCrunch 正文最後一段也不肯替 Google 收勝利：開發者不會只因為搬得動，就自動扔掉 NVIDIA 硬體。
供應確實是這套開源故事的暗線。Hacker News 問「Google 以外誰有 TPU」，回答分成三層：雲上租、賣給 Anthropic 這類大客戶做地端、以及品牌叫 TPU 但其實不是同一顆矽的 Coral／Pixel NPU。有人把 Coral 和資料中心 TPU 混在一起，立刻被糾正「只是行銷同名」。你現在能 pip install torch_tpu，不代表你能在實驗室桌上插一張 Ironwood。軟體護城河被削的是「程式必須為 CUDA 重寫」；沒被削的是「你要先拿到對的矽，而且那顆矽的 ISA 仍不公開」。
同一週還有另一條打 CUDA 的開源線，但層次不同。DeepSeek 把生產推理框架 DeepInfer 以 Apache 2.0 放上 GitHub，硬體寫 NVIDIA SM100 與華為昇騰 950，見：KV 快取、拆分、負載平衡沒放。月初那套昇騰工具鏈六件套，TileLang 對上 CUDA，950 超節點密集 GEMM 利用率寫 99.8%，見：昇騰六件套。TorchTPU 要搶的是 PyTorch 開發者的預設裝置字串；DeepInfer 要搶的是服務層中間件。兩者都在減「離開 NVIDIA 堆疊的工程稅」，但一個賣雲端 TPU 時數，一個讓自家模型在出口管制下的 ASIC 上能被複現。
開發者若真的要試，檢查清單比口號短，也比口號硬。機器得是 TPU VM，文件範例寫 v6e，Python 3.12。pip install torch_tpu 之後，分散式還要拓樸變數。預設精度是 BF16 medium，不要假設和 CUDA 的 FP32 預設可直接對 loss。預設 Skinny Collectives 可能吃掉 30–40% 端到端，要峰值就得證明程式是 SPMD，或接受 handshake 仍是 RFC。torch.compile 暫時 dynamic=False。一顆 TPU 一個行程，RL 共置先當做不到。4,917 個模型的 98% 是「不崩潰」，數值對 GPU 的是另一張較小的表。InferenceX 的 2.01 美分背後是 FP8 MoE SPMD 與 Sequence-on-Lane，不是開箱 vLLM。TPU agent suite 仍是預覽。Amazon 那側是公開測試版，Google 這側寫「已有最大的 Cloud 客戶用在生產推理與訓練」，但客戶名單除了引言裡的 Meta、Hugging Face、Inferact、RadixArk、Zenteiq，沒有變成一份可稽核的產能表。
採購判斷可以落在四個可驗證條件，而不是一句「多一個後端比較安心」。第一，你的模型是否落在那 4,917 裡、是否屬於 97% 數值通過的架構代表；不在名單上，遷移成本從「改一行」回到「自己過編譯」。第二，你要的是開箱 MFU 還是 Pallas 之後的 MFU；Qwen3 8B 的 52% 與 Qwen3 MoE 235B 在 8,192 顆上的 27% 不是同一句話。第三，每百萬 token 2.01 美分是 SemiAnalysis 那條 8K／1K 的轉述，且相對 9 月的 3.6 美分；你的流量若不是那個形狀，數字不能搬。第四，裝置拿不拿得到——雲上配額、地端是否在 Google 願意出貨的名單、以及團隊有沒有人會寫 Pallas。四條都過，TorchTPU 才是在打 CUDA 的鎖。缺任何一條，它比較像一份寫得極完整的遷移意向書。