谷歌开源 TorchTPU：改几行配置把 PyTorch 搬上 TPU，英伟达的护城河松了？

人工智能应用大多用 PyTorch 写，而 PyTorch 从诞生起就围着英伟达 GPU 转。这个组合稳了将近十年，也成了英伟达最难被撼动的软件护城河。当地时间周二，谷歌宣布在 GitHub 开源 TorchTPU，让 PyTorch 应用可以直接跑在谷歌自研的张量处理单元上。

一分钟速览

• 谷歌开源 TorchTPU，为 TPU 提供原生 PyTorch 支持。
• 开发者只需修改少量配置，不必重写应用代码，就能把现有 PyTorch 应用迁到 TPU 和谷歌云。
• 谷歌联合 Meta、Hugging Face、vLLM 开发方 Inferact、SGLang 开发方 RadixArk 等共建兼容性。
• 亚马逊此前一天发布 TorchNeuron，把 PyTorch 应用迁往 Trainium 和 AWS。
• 两家都在推动 PyTorch 与英伟达硬件解耦，但开发者是否会集体迁移仍是未知数。

PyTorch 为什么成了兵家必争之地

PyTorch 最初由 Meta 在 2016 年开发，2022 年移交给 Linux 基金会。它现在是 AI 应用最常用的开发框架之一，有统计称约 85% 的人工智能应用在使用它。研究者用它写模型，初创公司用它搭训练和推理流水线，云厂商用它定义「什么样的代码能跑在我的芯片上」。

问题在于，PyTorch 的很多底层能力是围绕英伟达 GPU 和 CUDA 生态打磨出来的。算子库、编译路径、分布式训练、性能调优工具，默认答案往往是「先在英伟达上跑通」。换芯片意味着改代码、调性能、重新踩坑，很多团队算完账就放弃了。

TorchTPU 想做的，是把这道迁移成本压到足够低。谷歌的说法是，现有 PyTorch 应用只需简单修改配置，不需要重写代码，就能迁到 TPU，再顺势迁到谷歌云。为了不让「能跑」变成「跑得慢」，谷歌还拉上了 Meta、Hugging Face、Inferact 和 RadixArk，保证 TorchTPU 与主流开发工具、推理框架的兼容性。

不止一个框架，是一整套迁移工具

谷歌同时推出了 TPU 智能体套件，帮助开发者在迁移过程中排查和修复错误；还升级了 LiteRT，这个工具用于在手机、笔记本和嵌入式设备上运行 AI 模型，升级后能更好地支持基于 PyTorch 开发的应用。把这几件事连起来看，谷歌想要的不是「多一个框架」，而是从云端训练到端侧推理的一条完整路径。

亚马逊的动作几乎同步。当地时间周一，亚马逊发布 TorchNeuron，让 PyTorch 应用无需重写代码就能移植到 Trainium 芯片和 AWS。亚马逊还表示，会向 PyTorch 主项目提交代码，把各类功能与英伟达芯片解耦，让 PyTorch 原生兼容多种硬件。

两家云厂商的策略很清楚：模型层打不过，就从框架层动手。只要开发者迁移的成本足够低，芯片采购就不再是默认选项，而是一次可以重新计算的选择题。

护城河不会一夜消失

但「可以迁移」不等于「会迁移」。英伟达的优势不只是硬件性能，还包括十几年的工具链、社区答案、调优经验和人才储备。一个团队遇到性能问题，搜索到的教程、问到的同行、招到的人，大概率都熟悉 CUDA。这种生态惯性很难靠一个开源仓库扭转。

TPU 也有自己的限制。它更适合大规模、形状规整的训练任务，对某些动态形状、稀疏计算或特殊算子的支持不如通用 GPU。TorchTPU 能解决「代码能不能跑」，但解决不了「跑了之后性价比是否真的更高」。企业最终还是会看单位算力的训练成本、推理延迟和云服务的整体账单。

对开发者的实际影响

短期看，最直接的受益者是已经在谷歌云上、又想尝试 TPU 的团队。过去他们需要专门的迁移项目，现在可以先拿一个非核心任务试水，改配置、跑基准、算成本，再决定要不要扩大。对初创公司来说，这意味着芯片选择可以晚一点锁定，不必在产品还没验证时就把技术栈绑死在某一家硬件上。

中长期看，PyTorch 与硬件的解耦会改变云厂商的竞争方式。过去卖芯片，后来卖「芯片加框架加工具链」，现在则要证明「同样的 PyTorch 代码，在我的云上更便宜、更稳」。这对开发者是好事，对英伟达则是更直接的定价压力。

趋势洞察

AI 基础设施的竞争，正在从单点硬件参数转向「迁移成本」。谁能把开发者的沉没成本降到最低，谁就有机会在下一轮算力采购里分到份额。谷歌和亚马逊同时押注 PyTorch 兼容层，说明它们已经接受一个现实：不可能让所有人重写代码，只能让现有代码更容易跑在自己的芯片上。

至于英伟达的护城河会不会松，答案可能不在开源仓库里，而在未来两年的招聘市场和性能基准里。当新一代工程师默认「PyTorch 可以跑在任何芯片上」，硬件厂商的真正竞争才算开始。