不可复现！现实世界又锤了一次TPU

TPU vs. GPU的讨论仍然热闹非凡，但很显然，这种讨论让我们离真相越来越近，我们已经开始看到有一线程序员在吐槽了…

我终于把模型搞到这么大了，结果发现我手里的所有关键工具链（比如数据管道、内核优化、推理加速、分布式脚本等），全他妈是针对NVIDIA B200 + CUDA + PyTorch深度定制的。现在想换到谷歌的Jax + TPU根本跑不通，也复现不出原来那个速度、那个显存占用、那个稳定性。 

真是预期之外啊。

是不是有些笑不活了？！我们知道对比TPU vs. GPU、借此看空英伟达GPU的这段叙事肯定会反转，但以这种形式，依然出乎我们的预料。

模型干的越大，越能给一线的算法工程师更清晰的认识（其实他们早已经很清楚，只是资本市场刚好需要“英伟达杀手”的叙事），现实世界是这样的：

• FlashAttention-2/3、TensorRT-LLM、vLLM、DeepSpeed、Torch.compile的所有黑魔法，只有NVIDIA的CUDA有。
• 99%的第三方SOTA实现（Gemma、Qwen、DeepSeek、LLaMA系列的各种优化版）只给了PyTorch+CUDA代码。
• 你真想用谷歌的Jax？要么自己从头重写一堆fused kernel，要么性能直接腰斩甚至更多。
• B200出来那一刻，NVIDIA把单卡FP8性能直接干到40+ PFLOPS，TPU就算理论值再高，实际端到端训练/推理吞吐还是被反超，Google的TPU v6/Trillium虽然理论带宽高，但实际多pod跨域通信延迟和重配置时间惨不忍睹，很多团队实测到4~8个pod就掉到70% scaling efficiency了。

• NVIDIA正在力推的下一代kernel语言cuteDSL，已经和torch.compile深度融合。写一个kernel就能同时覆盖训练和推理，性能比手写CUDA还高5~15%。而谷歌Jax的XLA到现在还在各种“编译失败”和“fallback到慢路径”的崩溃边缘。

总结一句话就是：

在真金白银的、现实的大模型生产环境里，TPU几乎找不到能对抗B200/GB300的场景了，反而在各种关键细节上被反杀。

在真实世界，理想很容易碎成现实的碎片。

开发者会发现，手里的SOTA工具链，全是为CUDA量身定制。虽然谷歌Jax的XLA自动优化在理论上很高效，但它是一个不透明的黑盒。当模型的性能不理想或出现意想不到的精度问题时，开发者缺乏像CUDA那样直接干预和调试底层代码的能力。这种“难以工作”的感觉，源于XLA 在面对复杂、定制化模型时，牺牲了开发者的精细控制权。

更关键的是，B200的NVFP4支持将FP8计算推到200+ PFLOPS，结合NVSwitch的低级控制（如自定义路由和集体通信），让端到端吞吐碾压TPU。

弄来弄去，结果就是这句话：

“我以为我在选技术栈，其实是技术栈选了我，而它选择的是英伟达。”

还有一句对谷歌JAX/XLA的评论也狠：

“Jax is amazing but xla is making it hard to work with and mosaic is still young”

这句话翻译解释过来是： 

Jax这个语言本身是真香，代码写得优雅得像艺术品，但编译后端XLA就是个随时爆炸的雷。Mosaic（Google最新推的TPU专用kernel语言）才刚出生，连文档都写不全，社区生态更是0。 

其实， 本文开头的那位老哥最后一句吐槽“What an unexpected turn of events”还可以这样翻译：

真他妈操蛋啊！