TPU 上手两周，账单比跑分更说明问题

被朋友安利了谷歌的 TPU，说他们那边训练成本压下来了。我让团队去开了配额，前后折腾将近两周，试试看到底好不好用。

先说清楚这是什么东西。TPU 是谷歌自研的专用芯片，术语叫 ASIC，就是为某一类特定任务做的芯片，不像 GPU 那样什么都能干。最早是 2016 年 Google I/O 上公布的，设计方是博通，谷歌内部 2015 年就在用了，2018 年才放到云上对外。最新的产品线分两条，训练的 TPU 8t 和推理的 TPU 8i。

我们没买硬件。2026 年 4 月谷歌才确认开始向部分客户交付 TPU 硬件，我们这种量级排不上，走的是 Google Cloud 上开 TPU VM，按小时租。

开配额本身就花了一周多，要说明用途、规模、大概跑多久。这段体验一般，但也能理解，算力紧的时候谁都这样。

真正的坎在迁移。我们原来的训练脚本是 PyTorch 写的，TPU 对 JAX 和 TensorFlow 最顺，PyTorch 要过一层叫 XLA 的编译器。团队三个人，第一个脚本跑通花了大概四天，中间卡得最多的是算子不支持，报错信息也不太友好。改完之后反而顺了。

惊喜的地方是通信。多卡训练最烦的是自己搭互联、调 all-reduce 那一堆，TPU 这块芯片之间是直连的，代码里基本不用管。这块省下来的是人。

优点先说能效比。最新的 TPU v7，代号 Ironwood，据说显存容量追平了英伟达的 B200，能效上更占优。谷歌早年公布过第一代的数据，性能比当时的 CPU 和 GPU 高 15 到 30 倍，每瓦性能也高一个量级。这个口径有点老，但方向一直没变。大集群也省心，规模上去之后，互联和调度这块不用自己造轮子。账单结构也清楚，租的时候按芯片小时算，不像自建机房那样一笔糊涂账。

缺点也有三条。我最在意的是生态绑得紧，迁进去费劲，迁出来也费劲，属于战略层面的问题。小模型不划算，算力再强，模型小到一定程度，瓶颈在数据加载不在计算，租它属于浪费。还有就是拿不到硬件，想自建基本没戏，只能接受云上租这个形态。

我的判断是看情况，而且是偏保守的那种看情况。

模型规模大、要长期反复训、团队里有人愿意啃 JAX 的，这三条缺一条，投入产出比就算不过来。反过来，模型还在快速试错阶段的中小团队，或者已经在 PyTorch 生态里沉了很深的，就不合适。迁一次的成本，很可能比省下来的那部分算力钱还高。我这边算过，按我们现在的量，回本周期大概在一年上下，前提是训练任务持续饱和。

有一点得说清楚，TPU 顶替不了 GPU。它更像是在特定任务上把单位成本压下去的一条路。黄仁勋自己都说过，ASIC 领域里谷歌的 TPU 是个特殊的存在。这话从对手嘴里出来，分量不一样。

之前写端侧那篇的时候我说过，适配和工具链比跑分重要。放到 TPU 上，这个判断没变。

真要迁的话，性能那关其实好过，迁移成本才是要提前算清楚的。