3. Google TPU演进史：从TPU v1到v4的架构变迁，脉动阵列与矩阵计算单元的设计哲学
聊到AI芯片，Google的TPU是个绕不开的话题。我入行那会儿，大家还在争论GPU和FPGA谁更适合做推理，Google直接甩出一颗专用芯片，把整个行业震住了。今天咱们就从头捋一遍，看看TPU从v1到v4到底变了什么，以及那个经典的脉动阵列到底妙在哪里。
3.1 TPU v1：为推理而生的“大号矩阵乘法器”
TPU v1发布于2016年，但据说Google内部2014年就开始用了。它的定位非常明确：加速推理，尤其是神经网络中的矩阵乘法。
你想想看，那时候的深度学习模型，比如早期的ResNet、Inception，推理时最耗时的就是卷积层和全连接层。这些层说白了，就是一堆矩阵乘法和加法。TPU v1干脆把整个芯片设计成一个巨大的矩阵乘法单元。
核心参数（我凭记忆写的，不一定精确，但大差不差）：
- 制程：28nm
- 功耗：约75W（被动散热，这在当时数据中心里算很克制的）
- 算力：92 TOPS（INT8）
- 片上内存：28MB（统一缓冲区 + 累加器）
- 外部带宽：DDR3-2133，约34 GB/s
TPU v1没有复杂的控制逻辑，没有缓存层级，甚至没有指令集。它就是一个定制的脉动阵列，配合一个简单的指令队列。我刚开始看它的架构图时，第一反应是：“这也太粗暴了吧？”但后来发现，这种“粗暴”恰恰是它高效的原因。
3.2 脉动阵列：数据流驱动的计算美学
脉动阵列（Systolic Array）这个概念其实很老，80年代就有。但Google把它用活了。TPU v1用的是256x256的脉动阵列，也就是65536个乘加单元（MAC）。
它的工作方式很有意思：数据像血液一样在阵列中“脉动”流动。权重提前加载到每个MAC单元里，输入数据从左到右、从上到下依次流过，每个MAC单元完成一次乘加后，把结果传给下一个。
我画个简单的示意图，帮你理解这个数据流：
这种设计的好处是什么？数据复用率极高。每个输入数据被多个MAC单元共享，每个权重也被多个输入数据共享。相比GPU那种从寄存器文件反复取数的做法，脉动阵列的功耗低得多。
我个人习惯：在设计类似架构时，我会先画数据流图，看看哪些数据可以被复用。脉动阵列的本质就是“用空间换时间，用数据流换控制流”。
3.3 TPU v2：从推理到训练，引入BF16
TPU v2发布于2017年，最大的变化是：支持训练。训练和推理不一样，推理只需要前向传播，训练还需要反向传播和梯度更新。这意味着芯片需要更高的精度和更灵活的控制。
TPU v2引入了几个关键设计：
- BF16（Brain Floating Point 16）：Google自己搞的格式，动态范围和FP32一样，但精度只有7位。我一开始觉得这玩意儿不靠谱，但后来发现训练时真的够用，而且省带宽省功耗。
- 二维脉动阵列升级：从v1的256x256变成128x128，但每个MAC单元支持混合精度（BF16乘法 + FP32累加）。
- 增加向量单元（VPU）：用于处理非矩阵运算，比如激活函数、BatchNorm等。
- HBM高带宽内存：带宽从34 GB/s飙升到600 GB/s以上。
TPU v2还有一个有意思的点：它把多个芯片组成一个2D Torus拓扑，通过高速互联（ICI）连接。我记得当时Google的论文里提到，一个TPU v2 Pod有64个芯片，算力达到11.5 PFLOPS。这个规模在当时是相当惊人的。
3.4 TPU v3：液冷与算力翻倍
TPU v3在2018年发布，本质上是对v2的“暴力升级”。
| 特性 | TPU v2 | TPU v3 |
|---|---|---|
| 制程 | 16nm | 16nm（同代） |
| 算力（BF16） | 45 TFLOPS | 123 TFLOPS |
| HBM容量 | 8 GB | 16 GB |
| HBM带宽 | 600 GB/s | 900 GB/s |
| 散热方式 | 风冷 | 液冷 |
| 互联带宽 | 200 GB/s | 400 GB/s |
TPU v3把脉动阵列的时钟频率从700MHz提到940MHz，同时增加了HBM的数量。但代价是功耗飙升，不得不上了液冷。我在做数据中心芯片时也遇到过类似问题——性能翻倍容易，散热翻倍难。
我曾经踩过一个坑：在设计某款AI加速器时，只关注了算力指标，忽略了散热设计。结果样片跑起来温度直接破百，不得不重新做封装。TPU v3的液冷方案虽然成本高，但保证了芯片能稳定运行在极限频率下。
3.5 TPU v4：稀疏性与SparseCore
TPU v4在2021年发布，这次的变化更大。Google在架构上做了几个关键创新：
- SparseCore：专门处理稀疏矩阵的加速器。说白了，很多推荐系统里的Embedding表是稀疏的，用传统脉动阵列算效率极低。SparseCore用了一种“按需加载”的方式，只计算非零元素。
- 脉动阵列升级：从v3的128x128变成v4的？x？，具体尺寸Google没公开，但算力从123 TFLOPS提升到275 TFLOPS（BF16）。
- 光互联（OCI）：TPU v4 Pod用了光交换机，把芯片间的互联带宽提升到TB/s级别。这个技术在当时非常前沿，我到现在都觉得Google在互联上的投入很值得学习。
- 可重构拓扑：Pod内的芯片可以动态组成不同的拓扑结构，适应不同的模型并行策略。
TPU v4还有一个细节：它把编译器（XLA）和硬件做了深度协同。比如，编译器会自动识别稀疏模式，然后调度到SparseCore上。这种软硬件协同设计，是我认为Google最厉害的地方。
3.6 脉动阵列的设计哲学：为什么Google一直坚持？
从v1到v4，Google始终没有放弃脉动阵列。为什么？我总结了几点：
- 数据局部性：脉动阵列天然适合矩阵乘法，数据在阵列内流动，不需要频繁访问片外内存。这在带宽受限的场景下是巨大优势。
- 可扩展性：你可以把多个小阵列拼成大阵列，也可以把多个芯片拼成Pod。脉动阵列的规则结构让物理设计（布局布线）变得简单。
- 能效比：相比GPU的通用计算单元，脉动阵列的每瓦性能更高。Google的数据中心对功耗极其敏感，这一点很关键。
但脉动阵列也有缺点。比如，它处理不规则计算（如稀疏矩阵、动态形状）时效率不高。这也是为什么TPU v4引入了SparseCore——用专用单元弥补脉动阵列的短板。
我的看法：脉动阵列不是万能的，但在AI推理和训练的主流场景（密集矩阵乘法）中，它依然是目前能效比最高的方案之一。如果你在做一个AI芯片，不妨先问问自己：我的核心负载是什么？如果是矩阵乘法，脉动阵列值得认真考虑。
3.7 从TPU演进中我们能学到什么？
回顾TPU的四代产品，我看到了几个清晰的趋势：
- 从专用到通用：v1只做推理，v2开始支持训练，v4加入了稀疏计算。Google在逐步扩大TPU的适用范围。
- 从单芯片到系统：v1是单芯片，v2/v3是Pod，v4是光互联集群。Google越来越强调系统级设计。
- 从硬件到软硬件协同：XLA编译器、SparseCore的调度策略，都说明Google在把更多复杂度从硬件转移到软件。
这些趋势对我们做芯片设计也有启发。说白了，没有完美的架构，只有最适合当前负载的架构。TPU的演进史，就是Google不断在“专用”和“通用”之间找平衡的过程。
嗯，今天就聊到这里。下一章我们会深入分析脉动阵列的微架构设计，包括数据流调度、流水线平衡和时序收敛这些实战问题。到时候我会拿一个实际项目中的案例来拆解，敬请期待。