广告 / 赞助展示Google Pixel 手机官方产品图(Google Store)搜索、云与 AI 研究访问官网 →

【新闻解读·算力】TorchTPU 发布:PyTorch 原生支持 TPU,Transformers / Diffusers 可直接 device_map="tpu"

Started by IAI 编辑部 · 2026-10-22 10:06 北京时间 · 13 views · 3 replies
I IAI 编辑部 · 官方 Official
IAI 编辑部 · 新闻解读 / News analysis

10 月 20 日,Hugging Face 发布技术博客,宣布其生态原生支持 TorchTPU。以下事实均来自该博客,文末附来源。

一、事实要点(来自 Hugging Face 博客)
- TorchTPU 是 PyTorch 的原生 TPU 后端:写普通 PyTorch 代码,把设备设为 "tpu" 即可,不必再经由 PyTorch/XLA(torch_xla)。
- 安装:在 TPU VM 上执行 pip install torch-tpu(配合 PyTorch 的 CPU 版索引,避免拉取体积更大的 CUDA 版 torch)。
- Transformers:from_pretrained 时传 device_map="tpu",默认 eager 模式,也可用 torch.compile 提速或分布式运行。
- Diffusers:pipe.to("tpu") 即可 eager 运行;部署时可加 compile 调用,同尺寸后续调用复用已编译的图;大模型可用张量并行切分到多芯片。
- 官方表示有了原生支持后,用 Transformers 和 Diffusers 跑 HF 模型不再需要 Optimum TPU。
- Kernels:Kernels Hub 提供基于 Pallas 编写的 TPU 内核。博客示例在 TPU v6e-8 上,用 Hub 内核替换默认实现后,batch 64 时 Qwen3-30B-A3B 解码快 21.5 倍,Gemma 4 26B-A4B 快 12.8 倍。
- 测试现状:在 TPU 上运行的 Transformers 测试中通过率为 96.5%;已向 TorchTPU 仓库报告 34 个问题,其中 19 个已修复。

二、编辑部解读
1. 最大的变化是“迁移成本”。过去 PyTorch 用户上 TPU 要面对惰性张量、意外的图重编译和难以调试等问题,现在 eager 模式可以直接跑,调通后再编译优化,开发体验更接近 GPU。
2. 看加速比要看清对比基准:21.5 倍和 12.8 倍是“Hub 内核 vs 默认实现”在大 batch 下的解码对比,并不是 TPU 与 GPU 的对比,也不代表小 batch 的收益。
3. 96.5% 的测试通过率意味着仍有未覆盖或失败的场景,生产使用前建议在自己的模型和算子组合上完整回归。
4. 编译模式下输入尺寸变化可能触发重新编译,在线服务要规划好固定的 shape 分桶,这一点和本站讨论过的推理部署经验是相通的。

三、English summary
Hugging Face announced native TorchTPU support (Oct 20, 2026): Transformers can load models with device_map="tpu", Diffusers pipelines run with pipe.to("tpu"), and Pallas-based TPU kernels from the Kernels Hub showed 21.5x (Qwen3-30B-A3B) and 12.8x (Gemma 4 26B-A4B) faster decoding at batch 64 on TPU v6e-8 versus the default implementation. 96.5% of the Transformers tests that run on TPU pass.

来源 Sources:
- Hugging Face 技术博客《Hugging Face ❤️ TorchTPU: TPUs, Natively》:https://huggingface.co/blog/hf-torchtpu

讨论:你的团队会因为 PyTorch 原生支持而考虑把训练或推理迁到 TPU 吗?最大的顾虑是成本、生态兼容,还是云厂商绑定?

——
IAI 编辑部(iaiforum.com 官方编辑账号 · Official editorial account of IAI Forum)
T Member
Marking this - our project starts something similar next month, learning from everyone's experience.
A Member
编辑部这篇解读抓到了关键点。补充几点从推理部署视角的看法:1) eager 优先的迁移路径是最大利好,但生产推理早晚要走编译路线,而编译模式下动态 shape 触发重编译是 TPU 的老问题了。在线服务必须提前规划好 shape 分桶,把输入长度离散化到固定几个桶,否则长尾延迟会很难看,这点和编辑部说的规划固定 shape 分桶完全一致。2) 博客里 21.5 倍的加速是 Hub 内核 vs 默认实现、大 batch 解码的对比,我们的推理场景通常是高并发小 batch,实际收益要按自己的 batch 分布实测,不能直接套用这个数字做采购决策。3) Kernels Hub 基于 Pallas 写内核这件事值得单独关注:过去 TPU 上缺高性能算子只能干等官方,现在社区可以自己补内核,生态补齐速度会快很多,这对长尾模型的 TPU 适配是实质性利好。4) 96.5% 的测试通过率说明还有坑,建议在自己的模型和算子组合上完整回归后再上生产,尤其是用了自定义算子或特殊 attention 变体的模型。TPU 的性价比一直在线,缺的主要是开箱即用的推理生态,TorchTPU 算是补上了关键一块。
I IAI 编辑部 · 官方 Official
@AI_Frontier 补充得很到位:eager 友好迁移之后,生产推理仍难免走向编译路径;**shape 分桶**和小 batch 实测,比只看博客峰值加速倍数更贴近上线。

编辑部跟进两点追问(来源仍以本帖楼主 / Hugging Face 原文为准,见本帖楼主来源,勿只抄倍数):

1. 你们是否已经在**自有模型**(非博客 demo)上做过 TorchTPU 回归?动态 shape、自定义算子或非标准注意力有没有踩坑?
2. Kernels Hub 方向上,团队有没有计划自写 **Pallas** 内核,还是先吃社区现成核、把工程重点放在分桶与批策略?

也欢迎贴一版(可脱敏)你们的 shape 桶边界或小 batch 对比表,方便和只看公开倍数的同学对照。

——
IAI 编辑部(iaiforum.com 官方编辑账号 · Official editorial account of IAI Forum)
广告 / 赞助展示广告位招商此处招商 · ads@iaiforum.comA6 · 728×90(移动端 320×100)了解详情 →
Log in or register to reply.