Google 的 TPU 论文其实是一份系统设计回顾 #
Google 与 UC Berkeley 的研究人员 Norman Jouppi、Sridhar Lakshmanamurthy、Cliff Young 和 David Patterson 发表了一篇回顾文章，梳理了 Google 五代训练超级计算机——从 TPU v2 到 TPU7x，即 Ironwood。
标题数据很亮眼：据作者报告，八年多来，每芯片 HBM 容量和带宽增长约 10×，按论文的低精度比较基准归一化后，每芯片峰值性能增长约 100×，整个 pod 的总性能增长约 3,600×。Ironwood 可扩展至 9,216 颗芯片，每芯片配备 192 GiB HBM 和约 7.38 TB/s 的 HBM 带宽。
但这不只是关于一颗更快 ASIC 的故事。这篇论文想说明的是：只有把芯片架构、内存、互连、编译器、散热、供电和故障恢复当作一台计算机来统一设计，AI 加速器才能经久耐用。
| TPU 演进信号 | TPU v2 | Ironwood | 为何重要 |
|---|---|---|---|
| 每 pod 芯片数 | 256 | 9,216 | 并行计算更多，但调度和故障管理难度大得多 |
| 每芯片 HBM | 16 GiB | 192 GiB | 模型状态更大，容量瓶颈更少 |
| 每芯片 HBM 带宽 | 约 0.7 TB/s | 约 7.38 TB/s | 持续为矩阵引擎供给数据 |
| 每芯片峰值 BF16 | 46 TFLOPS | 2,307 TFLOPS | 在相同 BF16 精度基准下约为 50× |
| 每芯片峰值 FP8 | 不适用 | 4,614 TFLOPS | 在模型精度允许的情况下，更低精度可提升吞吐量 |
| 可直接寻址的 pod HBM | 4 TiB | 约 1.77 PiB | 超级计算机级内存成为一等设计资源 |
这一比较需要谨慎对待。FP8 和 BF16 是不同的数值格式，因此论文中约 100× 的节点性能标题不应被解读为 通用的应用加速。在同等 BF16 基准下，所述峰值提升更接近 50×。实际训练吞吐量仍取决于 模型形态、利用率、通信和软件。
为什么最初的 ASIC 没有过时 #
反对 ASIC 的经典理由是它太死板。定制芯片要花几年设计，而 AI 模型几个月就可能变样。TPU v2 立项时，Transformer 还不是主流负载。而按论文给出的 2026 年内部负载构成，Transformer 变体已占 Google 训练用量的 74%，RNN 则几乎绝迹。
但 TPU v2 的框图在 Ironwood 上依然一眼可辨。真正经久不衰的，不是对某个神经网络的硬编码实现，而是那些始终契合机器学习计算方式的通用原语：
- 用于稠密矩阵乘法的脉动阵列。
- 保留数值范围的窄浮点格式，包括 BF16 和 FP8。
- 用于高容量、高带宽模型数据的 HBM。
- 用于集合通信的定制芯片间互连。
- 由编译器管理 DMA 和暂存 SRAM，而不是传统类 CPU 的缓存层级。
- 用于激活、归一化、量化及其他非矩阵运算的向量单元。
这是“AI ASIC 仍有增长空间”这一说法最有力的证据。成功的 ASIC 不必预测每一个未来模型，只需加速那些在模型创新之下保持稳定的计算结构，同时把可编程性留给编译器、向量路径、数值格式和互连。
架构的成长靠的是扩展组件，而不是反复推倒重来 #
TPU v2 引入了两个大型 TensorCore，每个 TensorCore 都采用标量控制、宽 VLIW 指令、向量通道、编译器管理的向量内存和一个 128×128 矩阵乘法单元。Ironwood 仍然使用两个 TensorCore，但内部资源更宽、数量更多。
矩阵路径从 TPU v2 的两个 128×128 BF16 脉动阵列扩展到 Ironwood 的四个 256×256 BF16 阵列。FP8 运算可以使用四个 512×512 阵列。向量寄存器结构有所扩展，VLIW 指令宽度增加了 50% 以上，以控制新增的并行硬件。
从 TPU v4 开始，XLA 编译器可以将两个物理 TensorCore 组合成一个逻辑“Megacore”。这是硬件/软件协同设计的一个典型例子：芯片保留实用的双核结构，而编译器可以向模型暴露一个更大的有效核心。
架构稳定性也保护了软件投资。随着首选编程环境从 TensorFlow 向 JAX 和更底层的 Pallas 内核演进，XLA 始终是核心编译器层。模型和编译器优化不必随着每一代芯片而从头开始。
HBM 不是配件，而是计算架构的一部分 #
TPU v1 受限于传统 DRAM 带宽，因此 TPU v2 采用了 HBM。Ironwood 现在为每颗芯片搭配八个 HBM3E 堆栈，提供 192 GiB 容量和约 7.38 TB/s 带宽。
这解释了为什么 AI 加速器需求会远远超出计算裸片。 完整封装依赖于 HBM 晶圆、先进逻辑、中介层或其他 高密度集成、基板、组装、测试和散热材料。 只有当内存和互连能够让其保持忙碌时，更多计算才有价值。
| 供应链层级 | 为何 TPU 级 ASIC 增加需求 | 主要设计验证关注点 |
|---|---|---|
| HBM 堆栈 | 容量和带宽随每一代加速器上升 | 供应商产能配额、堆栈代次、已知良好裸片质量和封装良率 |
| 先进封装 | 逻辑和多个 HBM 堆栈必须以极高带宽通信 | 基板/中介层产能、翘曲、组装良率和热循环 |
| 大电流供电 | 数千个加速器产生巨大且快速变化的负载 | VRM 效率、瞬态响应、遥测、冗余和元件温度 |
| 液冷 | 高密度加速器托盘超出实际风冷范围 | 冷板、泵、歧管、泄漏检测和设施水兼容性 |
| 光连接 | 大型 pod 需要跨机架和故障域的可重构链路 | 光引擎可靠性、连接器清洁度、插入损耗和可维护性 |
| 网络与时钟 | 训练需要协调的集合通信 | 带宽、拥塞、时钟、固件和拓扑验证 |
因此，对买家来说，“AI 芯片需求”还包括功率级、控制器、磁性元件、电容器、光学组件、连接器、时钟和监控器件。即便 TPU ASIC 本身无法在公开市场订购，这些周边组件往往仍可买到。
光路交换把故障变成了拓扑问题 #
随着 pod 规模扩大，要求每个节点和主机都保持健康已不现实。TPU v4 在芯片间网络下层引入了光路交换机（OCS）。本地 4×4×4 立方体内的电网络保持固定，光链路则可以把多个立方体连成更大的 3D 环面。
这带来三个好处：
- 故障资源可以被绕过，健康的立方体重新接入。
- 调度器可以从可用立方体中拼出请求的切片，而不必找到一个完全连续的块。
- 新机架可以逐步安装、测试并投入使用。
这个教训不限于 Google 的具体拓扑。到了数千个节点的规模，可用性本身就是一种架构属性。如果系统频繁停顿、等待大块连续分配，或因故障恢复而损失时间，那么理论上更快的芯片反而可能带来更少的有效训练。
Google 报告称，在非常大规模的多 pod 训练中，有效训练吞吐超过 90%。有效训练吞吐不同于峰值 FLOPS：它是在扣除通信、故障、恢复和其他开销之后，实际保留下来的有用训练进展。
Ironwood 为静默错误增加硬件检查 #
大规模、长时间运行的训练作业容易发生静默数据损坏。导致作业崩溃的故障是可见的，而间歇性算术错误则可能降低收敛速度或模型质量。
Ironwood 通过矩阵引擎中的功能性内建自测试和向量路径中的硬件重放来解决这一问题。重放机制对操作进行采样，并利用原本空闲的指令槽重复执行，而不改变架构状态。一旦出现不匹配，就能定位出有缺陷的单元，再由光网络将其从生产中移除。
这对 ASIC 来说是一个重要机会。可靠性功能可以围绕实际工作负载和数据通路来设计。但同时也提高了验证要求：生产测试、老化筛选、遥测和集群级故障分析都成为加速器架构的一部分，而不再只是工厂环节的工作。
能效正在成为容量指标 #
论文报告称，从 TPU v2 到 Ironwood，pod 每 TDP 瓦峰值性能提升了近 30 倍。这一点很重要，因为电网接入和设施供电正日益限制 AI 数据中心的扩张。更高效的加速器不仅能降低电费，还能在固定的兆瓦包络内实现更高的训练吞吐量。
作者还提出了计算碳强度（CCI），以每次浮点运算对应的二氧化碳当量克数来衡量。与每瓦性能不同，CCI 既能涵盖运行阶段的电力排放，也能涵盖制造环节的隐含排放。
流传的摘要中有一处单位换算需要更正。按论文中的示例值计算，`3.14 × 10²³ FLOPs × 265 × 10⁻¹⁸ gCO₂e/FLOP` 约为 `8.3 × 10⁷ grams`，即约 83 公吨 CO₂e，而不是 8300 万吨。这个估算本身只是把工作负载的 FLOPs 与平均 CCI 粗略相乘，不能当作对某次具体模型运行的完整审计。
TPU 能否证明 ASIC 将取代 GPU？ #
不能。TPU 证明的是：只要专业化选择在合适的层面上，并有成熟软件栈支撑，ASIC 就能保持可编程性、不被边缘化。它并不能证明每家公司都该去做定制加速器。
| 平台 | 最大优势 | 主要限制 | 典型适用场景 |
|---|---|---|---|
| 定制 AI ASIC | 效率高、路线图可控，可针对具体工作负载设计系统 | NRE 极高、开发周期长、软件负担重 | 超大规模厂商，以及稳定的大批量工作负载 |
| GPU | 可编程性强、生态成熟、可从公开市场采购 | 功耗、成本，以及对供应商平台的依赖 | 快速变化的研究和通用 AI 基础设施 |
| FPGA | 可重构、流水线确定、接口可定制 | 对许多密集训练工作负载而言，密度和效率偏低 | 原型设计、网络、预处理和专用推理 |
| 商用 AI 加速器 | 兼具部分 ASIC 效率，又不必自研芯片 | 生态较小，存在供应商和平台风险 | 希望采用经过验证的替代平台的企业 |
Google 的优势在于：能看清工作负载、部署量巨大、掌控 XLA/JAX、拥有数据中心，并且能够协同设计模型和硬件。规模较小的公司与其花多年时间自研芯片和编译器，不如直接购买 GPU 或商用加速器，收益可能更大。
未来很可能是异构的：GPU 负责广泛的可编程性，定制 ASIC 负责稳定的高规模工作负载，CPU 负责编排，FPGA 或网络 ASIC 则围绕数据通路部署。
这对组件采购意味着什么 #
TPU 是 Google 自己掌控的基础设施，并非市面上的通用元器件。买家别指望能单独买到 Ironwood 芯片，再自己搭一块兼容板卡。真正的商机主要在周边的 AI 基础设施 BOM，以及采用类似思路的其他商用器件。
AI 基础设施组件 RFQ 清单 #
- 明确具体的平台、板卡或机柜认证要求，不能只写“用于 AI 服务器”。
- 提供完整的制造商零件编号、封装、版本以及合格供应商限制。
- 确认每个电源组件的电压、电流、遥测、瞬态和散热要求。
- 涉及 HBM 相关封装和基板时，核实代次、装配流程、可追溯性以及认证责任归属。
- 光模块需注明数据速率、传输距离、连接器、波长、温度以及固件/管理要求。
- 锁定冷却接口、冷却液规格、材料兼容性和泄漏检测要求。
- 量产前确认生命周期、PCN/EOL 流程、批次一致性和失效分析支持。
- 加速器、内存或网络部件若有变动，一律按工程变更处理；标称带宽相近并不代表兼容。
采购前必须确认现货、配额、日期码、批次状况和交期。在 AI 基础设施里，具体经过认证的元件和平台版本，比笼统的“数据中心级”标签重要得多。
更大的启示：当系统本身就是产品时，ASIC 胜出 #
TPU 的回顾为 AI ASIC 提供了强有力的论据，但并不支持孤立的定制芯片。Google 的优势来自在扩展 HBM、数值格式、互连、编译器能力、散热、电源效率和韧性时，保持一组稳定且有用的计算原语。
这就是为什么 TPU v2 能够从 Transformer 之前的工作负载过渡到以 Transformer 为主的 2026 组合中存活下来。该 ASIC 足够专用以实现高效率，同时在矩阵/向量层面又足够通用以持续演进。
对半导体行业而言，机会巨大：定制 AI 计算将与 GPU 一同扩张，而每个加速器集群都会带动一个规模大得多的内存、封装、电源、光学、网络和散热元件生态系统。持久的竞争单元不再只是一颗芯片——而是一台完整、可编程且可维护的超级计算机。
主要参考资料 #
- Jouppi 等，“Google 从 TPU v2 到 Ironwood 的训练超级计算机”
- Google Cloud TPU7x (Ironwood) 文档
- Google Cloud：Ironwood TPU