谷歌Meta开源TorchTPU TPU成原生设备

时间：2026年10月20日（美国加州圣何塞 PyTorch Conference North America 2026 开幕当日；消息经北京时间10月21日凌晨核验） 地点：美国加利福尼亚州圣何塞 PyTorch Conference North America 会场；代码同步托管于 GitHub 仓库 google-pytorch/torch_tpu 人物：谷歌 AI 与计算基础设施副总裁兼总经理 Mark Lohmeyer、谷歌工程副总裁 Bill Jia；Meta PyTorch 工程总监 Jana van Greunen、Meta PyTorch-TPU 负责人 Zongwei Zhou；Hugging Face 产品副总裁 Jeff Boudier；Inferact 联合创始人兼首席执行官 Simon Mo；RadixArk 联合创始人兼首席技术官 Banghua Zhu；谷歌 AI 推理技术负责人 Qi Zhou；Zenteiq.ai 创始人 Sashikumaar Ganesan 事件详情：谷歌在 PyTorch Conference 2026 上宣布，与 Meta PyTorch 团队共同开发的 TorchTPU 正式以开源方式发布，代码托管于 GitHub 的 google-pytorch/torch_tpu 仓库，采用 Apache-2.0 许可证。TorchTPU 的核心意义是让 TPU 成为 PyTorch 的一等原生设备：开发者只需把设备初始化改成 tpu，即可沿用熟悉的 PyTorch API 在 TPU 上训练与服务，不必再走 JAX 或 XLA 改写路线。 执行层采用 Eager First 理念，共提供三种 eager 模式。Debug Eager 逐算子下发并每次与 CPU 同步，专门用于定位形状不匹配、NaN 与显存溢出；Strict Eager 保持单算子下发但异步执行，尽量贴近 PyTorch 默认体验；Fused Eager 通过对算子流做自动反射并即时融合成更大的计算块，官方称相比 Strict Eager 可带来 50% 至 100% 以上的性能提升，且无需用户额外配置。三种模式共用一套编译缓存，可单机运行，也可配置为跨多机持久化。 静态编译路径上，TorchTPU 用 Torch Dynamo 捕获 FX 图，但不经过 Torch Inductor，而是以 XLA 作为主后端编译器，把 PyTorch 算子直接翻译成 StableHLO，复用 XLA 针对 TPU 拓扑（ICI 片间互联、TensorCore 与 SparseCore 协同）打磨的优化路径。自定义算子支持用 Pallas 与 JAX 编写，可用 torch_tpu.pallas.custom_jax_kernel 装饰接入底层下发路径，Helion 内核支持仍在推进。发行方式为 pip install torch_tpu==0.2.0，要求 Python 3.11 及以上，源码构建依赖 Bazel。该仓库创建于 2026 年 3 月，正式公开后数小时内 GitHub 星标为 121、开放 issue 为 256。 生态侧同步落地。模型侧与 Hugging Face 合作后，Transformers v5 部署到 TPU 只需传入 device_map="tpu"，Diffusers 也原生支持 eager、torch.compile 与张量并行，并配套了针对 Transformers 测试套件的 TPU 夜间持续集成流水线。推理侧与 Inferact 合作推出原生 PyTorch 版 vLLM 后端 vllm-torchtpu，支持连续批处理、量化、多芯片并行与自定义 Pallas 内核；与 RadixArk 合作推出 SGLang-TorchTPU，同日开源，首批支持 Muse Spark Open、GLM-5.3 Flash、GLM-5.3、Kimi K3、DeepSeek V4、Ling 3.1 Flash、Qwen3.8、Gemma 4 与 MiniMax H3 等模型，默认启用 FP8 KV cache，KV cache 在 TPU 设备之间以及主机内存之间通过谷歌开源的传输库 TPU Sync 搬运，并可配合 TorchTitan 与 Miles 充当强化学习训练的 rollout 引擎。此外，谷歌与 Red Hat、IBM 及 500 多名贡献者、25 个组织共同发布 llm-d 1.0（CNCF Sandbox 项目），在 GKE 上可用同一个 llm-d 端点在 GPU 与 TPU 之间做前缀缓存感知路由与调度。训练侧以 PyTorch 原生的分布式训练参考实现 TorchTitan 为代表。 背景：在此之前，PyTorch 模型要在 TPU 上跑主要依赖 PyTorch/XLA 路线，开发者需要改写代码或转入 JAX 生态，迁移成本高。谷歌此前代号 TorchTPU 的项目已多次被媒体报道，指向降低迁移门槛并正面挑战英伟达 CUDA 生态的主导地位；Meta 作为 PyTorch 维护方与谷歌联合推进，也让这套后端从一开始就落在主流框架的演进路线里。同期 AWS 也在推动让 PyTorch 直跑自有加速器的开源后端，PyTorch 生态围绕非英伟达硬件的补齐正在加速成形。谷歌云官方博客把这件事定位为让客户在 TPU、GPU、CPU 之间获得选择，PyTorch 官方博客则直接以谷歌与 Meta 的开源合作来介绍 TorchTPU。 影响：对开发者而言，训练与推理代码基本不用改，只换设备标识，就能复用 vLLM、SGLang、llm-d、TorchTitan、Ray、TorchRec、Hugging Face 与 LiteRT 等既有技术栈；对云厂商而言，TPU 第一次以主流开源框架原生消费的方式进入软件栈，削弱了 CUDA 生态的迁移锁定；对国产模型而言，SGLang-TorchTPU 首批支持清单已包含 Kimi K3、DeepSeek V4、Qwen3.8 与 MiniMax H3，意味着这些开放权重模型可以直接在 Google Cloud TPU 上做生产级服务。谷歌给出的性能数字均为厂商自述：Zenteiq 称基于 GKE Inference Gateway 与 llm-d，在每 1000 台 TPU v6e 上把每日生成 token 产能从 14.7 亿提升到 59.7 亿，聚合推理吞吐提升 4 倍以上；官方称 Fused Eager 相比 Strict Eager 提升 50% 至 100% 以上。这些数据目前均无独立第三方复现。需要同时提示的是：仓库开放 issue 仍有 256 个，整体处于早期阶段；SGLang 侧的结构化输出与函数调用、DFlash2 与 DSPark 仍标注为实验性；TorchTPU 更像一次生态卡位，其对现有 TPU 用户迁移成本的真实降幅，仍需等第三方实测。 总结：TorchTPU 的意义不取决于单一性能数字，而在于 TPU 第一次以 PyTorch 原生设备的形态进入主流开源训练与推理栈，且由 Google、Meta、Hugging Face、Inferact、RadixArk、Red Hat、IBM 多方共同完成，覆盖了训练、推理、集群调度三层。对计划把推理负载迁往 TPU 的团队，这套栈提供了比 JAX 路线低得多的迁移成本；对英伟达而言，开源软件栈的补齐是硬件优势之外必须正面应对的生态变量。 参考来源： https://cloud.google.com/blog/topics/ai-infrastructure/torchtpu-is-now-open-source-run-native-pytorch-on-tpus https://developers.googleblog.com/torchtpu-running-pytorch-natively-on-tpus-at-google-scale/ https://pytorch.org/blog/introducing-torchtpu/ https://github.com/google-pytorch/torch_tpu https://www.lmsys.org/blog/2026-10-20-sglang-torchtpu https://github.com/sgl-project/sglang-torchtpu/ https://github.com/vllm-project/vllm-torchtpu https://m.36kr.com/p/3974090497126663 https://docs.cloud.google.com/tpu/docs/pytorch-on-tpu?hl=zh-cn https://torchtpu.readthedocs.io/