谷歌TPU八代进化史：从搜索加速到AI基建

你打开谷歌云控制台，准备租一批算力跑模型训练。下拉菜单里躺着八个版本：v2、v3、v4、v5e、v5p、v6e、Ironwood、8t/8i。价格差三倍，参数表像密码本。选错了，训练周期拖长两周；选对了，同等预算能多跑一轮实验。

这不是简单的"新比旧好"。每一代TPU背后，是谷歌对AI工作负载理解的迭代，也是一场关于"到底什么在拖慢模型"的持续诊断。

一颗芯片里的权力结构

理解选型困境，得先看清TPU内部的权力分配。谷歌官方文档反复出现五个关键词，它们决定了你的模型是跑得顺畅还是卡在奇怪的地方。

矩阵乘法单元（MXU，Matrix Multiply Unit）是绝对的计算核心。从v1到v5p，它一直是128×128的脉动阵列——16,384个乘加器同时开工。这个规格锁了整整四代，直到Trillium（v6e）才扩到256×256，单周期运算量翻四倍。如果你的模型全是矩阵乘法，这是最直接的红利。

但计算只是故事的一半。高带宽内存（HBM，High Bandwidth Memory）才是那个沉默的瓶颈。模型权重和激活值都挤在这里，容量不够就得切分模型，带宽不够则算力空转。每一代TPU的HBM都在扩容提速，但需求涨得更快——GPT-4级别的模型把HBM压力推到了新高度。

芯片间互联（ICI，Inter-Chip Interconnect）解决的是"一群芯片怎么协作"。分布式训练时，梯度同步速度直接决定扩展效率。ICI带宽不够，加芯片反而拖慢整体进度。从v4开始，谷歌把拓扑结构从二维环面（2D torus）升级到三维环面（3D torus），任意两芯片间的最大跳数减少，通信延迟被压缩。

SparseCore是v4引入的特化单元，专门处理嵌入（embedding）操作——推荐系统和大词表模型的命脉。v5p和Ironwood塞了四个，v6e减到两个。这个增减不是随意为之，反映的是谷歌对工作负载优先级的判断迁移。

最后，TensorCore是上述单元的封装容器。一个TensorCore里有一个或多个MXU，搭配向量处理单元（VPU）和标量单元。单芯片配一个还是两个TensorCore，直接决定峰值算力天花板。

v1：秘密武器的诞生（2015）

第一代TPU从未对外销售。它生于一个具体而紧迫的问题：谷歌搜索、地图、街景的推理成本正在失控。

芯片内置256×256的8位脉动阵列，INT8精度下跑出92 TOPS。功耗约40瓦，以当时的标准堪称高效。但它只能做推理，不能训练——架构上就没考虑反向传播。

谷歌保密超过一年。2016年I/O大会上，桑达尔·皮查伊（Sundar Pichai）宣布它已在数据中心运行一年多。整件事的动机被他说得很直白：避免谷歌数据中心的规模翻倍。

这是一个关键信号。TPU从第一天起就不是"炫技芯片"，而是成本工程的工具。这个基因贯穿后续所有版本。

v2与v3：首次对外开放（2018-2019）

v2是谷歌第一次把TPU做成云产品。2018年推出，核心变化是补齐训练能力——增加了对浮点运算的支持，MXU支持bfloat16格式。

单芯片峰值算力提升到180 TFLOPS（bfloat16）。内存用上了HBM，容量16GB，带宽600 GB/s。这些数字今天看很小，但当时足以支撑ResNet级别的模型训练。

v3在2019年跟进，算是v2的制程升级版。MXU阵列保持128×128，但频率提升、HBM扩容到32GB、带宽翻倍到900 GB/s。单芯片算力跳到420 TFLOPS，功耗也涨到200瓦。

两代产品的拓扑都是二维环面，最多256颗芯片组成一个pod。对当时的用户来说，这个规模足够用了——Transformer刚崭露头角，GPT-2参数量的1.5亿在v3 pod面前不算负担。

v4：拓扑革命与SparseCore登场（2021）

v4是架构层面的重新设计，不是简单提频扩核。

最显眼的变化是三维环面拓扑。芯片在三个维度上连接邻居，最大跳数从O(√N)降到O(∛N)。对大规模分布式训练，这意味着梯度同步的延迟地板被撬开一块。

SparseCore首次出现。推荐系统的嵌入表查找是CPU密集型操作，拖慢整体流水线。谷歌选择用专用硬件 offload 这部分，而非让MXU分心。v4每芯片配两个SparseCore。

单芯片HBM提升到32GB，但带宽跳到1.2 TB/s——增幅比容量更激进。MXU保持128×128，但频率和效率优化后，峰值算力达到275 TFLOPS（bfloat16）。pod规模扩展到4096颗芯片，是v3的16倍。

这代产品开始暴露谷歌的权衡逻辑：不盲目追峰值算力，而是针对特定瓶颈做手术。拓扑和SparseCore都是这种思路的产物。

v5e与v5p：同代分叉，场景细分（2023）

v5系列首次在同一世代推出两个分支，标志着谷歌对"一个尺寸 fits all"的放弃。

v5e是"效率版"。单芯片峰值算力197 TFLOPS，低于v4的275 TFLOPS，但每美元性能更优。HBM 16GB，带宽819 GB/s——比v4缩水，但针对推理和中小模型训练刚好够用。没有SparseCore，因为目标场景用不上。

v5p是"性能版"。MXU终于提速，配合其他优化，峰值算力冲到459 TFLOPS。HBM 95GB，带宽2765 GB/s——容量和带宽都是v5e的数倍。SparseCore加到四个，明确瞄准大模型训练和推荐系统。pod规模8960颗芯片，接近v4的两倍。

这个分叉让选型变得复杂，但也更诚实。v5e适合预算敏感、模型规模适中的团队；v5p为追求扩展效率的大模型训练而生。谷歌不再假装一颗芯片能同时服务好两个世界。

v6e（Trillium）：MXU终于扩容（2024）

Trillium是v6e的代号，也是MXU规格停滞四代后的首次突破。

256×256的脉动阵列，单周期运算量四倍于前代。配合频率提升，峰值算力达到918 TFLOPS（bfloat16）——v5p的两倍。稀疏运算峰值1836 TFLOPS，利用结构化稀疏性进一步榨取效率。

但MXU扩容的代价是面积和功耗。Trillium的应对是先进封装和制程，同时把SparseCore减到两个。这个削减引发过讨论：是嵌入操作的重要性下降，还是晶体管预算被迫向MXU倾斜？谷歌没有明确解释。

HBM 32GB，带宽1640 GB/s。容量不算慷慨，但带宽增速追上了算力涨幅，避免内存成为绝对瓶颈。ICI带宽也翻倍，三维环面拓扑延续。

Trillium的定位微妙：算力数字漂亮，但HBM容量限制了单芯片能承载的模型规模。它更适合数据并行度高的场景，或者配合模型并行策略使用。

Ironwood：推理专用，内存怪兽（2025）

Ironwood是谷歌首款专为推理设计的云端TPU，不再兼顾训练。

这个定位解放了设计约束。训练需要高精度和梯度稳定性，推理可以接受更低精度换取吞吐。Ironwood支持INT8和FP8，峰值算力在INT8下达到惊人的数值——但谷歌更强调其"每瓦性能"和"延迟特性"。

真正的杀手级规格是HBM：192GB容量，带宽7.2 TB/s。这是为超大模型推理准备的——GPT-4级别的参数如果全塞进单芯片内存，就能避免跨芯片通信的开销。四个SparseCore保留，推荐系统的在线推理场景被重点照顾。

ICI带宽进一步提升，但拓扑针对推理负载优化。训练需要全对全的梯度聚合，推理更多是请求路由和批处理，通信模式不同。

Ironwood的发布传递了一个信号：推理和训练的硬件分化正在加速。试图用同一套芯片兼顾两者，效率损失越来越大。

v8t与v8i：下一代的预览（2025）

谷歌在2025年I/O大会上披露了下一代TPU的命名：v8t和v8i。t代表训练（training），i代表推理（inference），延续v5e/v5p的分叉策略。

具体规格尚未完全公开，但官方透露了几个方向：v8t的MXU将进一步扩大，v8i的HBM容量继续膨胀。两者都会采用更激进的稀疏计算支持，以及针对多模态模型的特化优化。

拓扑方面，三维环面可能向更高维度或更灵活的动态拓扑演进。谷歌提到"可重构互联"，暗示芯片间的连接关系可能根据工作负载动态调整，而非固定布线。

软件栈的改进被反复强调。TPU的历史痛点之一是编译器和框架支持的滞后，v8系列承诺与JAX、PyTorch的更深集成，以及自动并行策略的优化。

选型的隐藏维度

看完八代进化，回到最初的问题：控制台里八个版本怎么选？

峰值算力是最不重要的指标。v5p的459 TFLOPS和v6e的918 TFLOPS差距巨大，但如果你的模型塞不进HBM，算力只是数字游戏。

先看内存容量。模型参数量×精度字节数，就是单芯片需要的HBM下限。不够就得模型并行，通信开销指数级增长。v5p的95GB和Ironwood的192GB，是两条清晰的分水岭。

再看内存带宽。大batch推理或训练时，权重读取速度决定算力利用率。v5p的2765 GB/s和v6e的1640 GB/s，意味着同样算力下前者更能"喂饱"MXU。

SparseCore的存在与否，决定嵌入-heavy的模型（推荐、广告、大词表NLP）能不能跑顺。v5e没有，v5p和Ironwood有四个，v6e有两个——这个分布不是随机的。

ICI带宽和拓扑影响扩展效率。小于64颗芯片的pod，二维和三维环面差别不大；超过256颗，v4以后的三维拓扑开始显现优势。

最后看精度支持。训练需要bfloat16或更高，推理可以降到INT8/FP8。Ironwood的推理特化包括对这些低精度的硬件优化，同等算力数字下实际吞吐更高。

谷歌的赌注与行业的镜像

TPU的八代进化，是一部AI工作负载的诊断史。v1解决推理成本，v2/v3补上训练能力，v4攻克通信拓扑，v5分叉场景，v6释放MXU算力，Ironwood押注推理分离，v8准备多模态和多租户。

每一步都不是"更快更强"的简单叙事，而是对瓶颈的精准打击。HBM、ICI、SparseCore的轮番登场，说明谷歌认为AI基础设施的约束在持续转移——算力、内存、通信、特化操作，没有一劳永逸的解。

这对行业的启示是：硬件选型正在变成架构设计的一部分。不是先写好模型再找芯片，而是根据芯片特性调整模型结构和并行策略。JAX的pjit、PyTorch的FSDP，这些框架层的抽象，本质上是在弥合硬件能力与模型需求之间的缝隙。

谷歌云TPU的定价页面还会继续膨胀。下一代的命名可能更复杂，分叉可能更细。但核心的判断逻辑不变：找到你的真实瓶颈，然后匹配那个针对性解决了瓶颈的版本。峰值算力只是入场券，能不能跑顺全看细节的对齐。