如果一家 AI 团队想把模型从 Nvidia GPU 搬到 Google TPU，过去不像换一台电脑那么简单，更像搬家时连插座和水管都要重接。模型虽然用 PyTorch 写成，接入 TPU 却常要经过 PyTorch/XLA 这座桥，并修改不少代码。Google 与 Meta 联合开源的 TorchTPU，想把这件事变成更接近“换个设备选项”：把 model.to("cuda") 改成 model.to("tpu")，现有工作负载通常就能先跑起来。
这值得关注，因为 PyTorch 是广泛使用的 AI 开发框架，而 TPU——Google 为机器学习设计的专用加速芯片——此前并不是它的原生设备。TorchTPU 试图让 TPU 与 CPU、GPU 一样，成为 PyTorch 直接认识的硬件。相关官方发布集中在 2026 年 10 月 20 日，Meta 工程师 Zongwei Zhou 在次日的 PyTorch 大会主题演讲中表示，Meta 计划借此迁移更大规模的 LLM 工作负载。本文性能数据主要来自项目方公布，尚不能视为独立复现。
“原生”到底改变了什么？
关键是 Backend——把 PyTorch 通用运算翻译成特定芯片指令的软件层。TorchTPU 接入 PyTorch 的底层调度机制，支持标准 PyTorch tensor（承载模型数据的多维数组）、eager execution（代码写到哪就执行到哪），也支持 torch.compile：它会经 StableHLO/XLA 把整段计算编译给 TPU。多机训练所需的 torch.distributed 也在支持范围内。
换句话说，开发者可以继续使用熟悉的 PyTorch 写法，不必先把模型改造成另一套框架的工程。官方已将 TorchTPU 定位为 PyTorch/XLA 的替代方案，并弃用旧栈；但“弃用”不等于现有 PyTorch/XLA 立即不能使用。
围绕训练和推理的工具也开始接上。vLLM-TorchTPU、SGLang-TorchTPU 面向模型推理，TorchTitan 面向大规模训练；Ray 和 llm-d 则可帮助工作负载跨多台 Kubernetes 主机扩展。故事里最耐人寻味的一点是：PyTorch 诞生于 Meta，而 TPU 长期更贴近 Google 自家的技术路线。如今两家公司共同给 TPU 补上 PyTorch 的“原生身份”。据 Google Cloud 和 Tom's Hardware，SGLang-TorchTPU 已在 Meta 的生产环境运行，这让此次发布不只是一份接口声明。
能跑起来，不等于跑得快
Google 公布了一组规模测试：Qwen3 235B MoE——一种每次只调用部分“专家”模块的大模型——通过 TorchTitan 与 TorchTPU 扩展到 8192 颗 TPU v7x，取得 28% MFU。MFU，即模型浮点运算利用率，用来衡量芯片理论算力有多少真正花在模型计算上。团队还报告了近线性的弱扩展：增加芯片和任务规模后，单颗芯片的吞吐量大体保持稳定。
不过，这组结果来自项目方，外部报道主要是转述。更重要的是，“改一行代码”只代表接口兼容、模型可以启动，并不代表已经达到 TPU 的峰值性能。原本面向 GPU 设计的模型结构、数据分片方式和算子，仍可能需要重新调优。所谓 Hugging Face 模型“开箱即用”也应谨慎理解：现有材料没有证明所有模型都已逐一验证。
为什么值得继续看？
CUDA——Nvidia 长期经营的 GPU 编程平台——真正难以替代的，不只是硬件，而是围绕它形成的库、工具和开发经验。TorchTPU 的意义，是让团队至少能用同一种 PyTorch 语言接触另一类芯片，把迁移的第一步变轻。
这场竞争也不只发生在 Google。AWS 几乎同期推出 Trainium 的原生 PyTorch 后端 TorchNeuron，同样主打少改代码。硬件厂商争夺的焦点，正在从“谁有替代芯片”延伸到“谁更容易接住现有软件工作流”。但供应商锁定并未消失：接口可以统一，性能优化、芯片容量和供应仍掌握在各家平台手中。
局限与未知
- 8192 颗芯片、28% MFU 与近线性扩展尚缺独立复现，也没有材料提供与其他硬件或旧方案的同条件比较。
- 少量代码修改能让模型启动；达到理想性能仍要投入分片、算子和模型结构调优。
- Meta 表达了迁移更大规模工作负载的计划，但材料没有披露迁移范围、时间表与实际收益。