TPU 与 GPU：它们是什么、有什么区别，以及哪些工作负载适合各自
发布: (2026年5月1日 GMT+8 09:53)
13 分钟阅读
原文: Dev.to
Source: Dev.to
GPU 与 TPU 在 Google Cloud 上的对比
如果你在 Google Cloud 上进行机器学习工作，你一定会面临一个选择：GPU 实例还是 TPU？
大多数团队默认使用 GPU，因为他们已经熟悉它。但随着推理成本上升以及 TPU 工具链的日趋成熟，了解每种芯片的实际作用以及何时一种优于另一种是很有价值的。
本文涵盖
- GPU 与 TPU 是什么
- 它们的工作原理
- 哪些工作负载在各自平台上表现更好
- Google 目前的 TPU 产品线（包括在 Google Cloud Next 2026 上宣布的第八代芯片）
图片占位符
图片来源：Google Cloud
1. 背景
GPUs
- 最初是为渲染视频游戏而构建的。
- 因为底层数学——大规模并行浮点运算——相同，GPU 能很好地处理 AI 工作负载。
- 研究人员在 2012 年左右意识到这一点，GPU 很快成为训练神经网络的默认硬件。
TPUs
- 在 2013 年，Google Brain 的工程师计算出，如果每位 Android 用户每天仅使用语音搜索三分钟，Google 将需要 将全球数据中心容量翻倍。
- 在如此规模上使用通用 GPU 进行推理成本过高且耗电。
- Google 的解决方案：一款 专门为神经网络数学设计的芯片。
- 第一个 TPU 于 2015 年在 Google 数据中心投入生产，并于 2018 年以 Cloud TPU 形式公开提供。
- 核心理念：剔除 GPU 从图形起源中携带的所有功能，完全专注于 矩阵乘法——这一原则至今仍驱动每一代 TPU 的设计。
2. 芯片工作原理
2.1 GPU 架构
- 一个拥有 数千个较小核心 的并行处理器。
- 与 CPU（8–64 个强大的通用核心）相比，高端 GPU 如 NVIDIA H100 拥有数千个核心，能够在一次指令下对大量数据点并行执行 (SIMD – 单指令多数据)。
- 支持的 精度格式：FP32、FP16、BF16、INT8、FP8。
- 可运行 PyTorch、TensorFlow、JAX、CUDA 库、仿真、渲染管线等。
- 由于这种广泛的支持，GPU 还配备了纹理映射、分支预测等硬件，这些在纯矩阵乘法时会处于空闲状态。
- 内存：NVIDIA H100 配备 80 GB HBM2e（封装在芯片上）。对于 AI 工作负载而言，内存带宽往往是瓶颈，而非原始计算能力。
2.2 TPU 架构
- 为一种工作而生：张量运算，尤其是神经网络训练和推理核心的矩阵乘法。
- 关键硬件：收缩阵列（systolic array）。
- 在标准处理器中，每个操作都要从内存读取输入、计算并将结果写回。
- 在收缩阵列中，数据在乘加单元的网格中流动。权重只需加载一次，输入在网格中传递，结果在单元之间 无需返回主内存，从而消除持续的内存往返。
- 精度：Google 从早期代数就加入了 BF16 支持；GPU 则是后来才加入。近期的芯片（GPU 与 TPU）均原生支持 FP8，提升推理吞吐量。
- 局限性：
- 对 动态控制流、可变长度序列和自定义操作 的处理较差。
- 最适合 静态计算图，这正是大多数 transformer 模型的特性。
3. 选择合适的加速器
3.1 推荐使用 GPU 的情况
| 工作负载类型 | 原因 |
|---|---|
| PyTorch‑first teams | 大多数研究代码、开源检查点和微调指南都假设使用 GPU。 |
| TensorFlow ops not on Cloud TPU | 某些 TensorFlow 操作在 TPU 上不可用（参见 Google 的操作列表）。 |
| Dynamic inputs (variable‑length sequences, conditional branches, custom CUDA extensions) | GPU 能够优雅地处理这些情况；TPU 可能会比较棘手。 |
| Medium‑to‑large models with larger effective batch sizes | GPU 在批量大小上具有良好的可扩展性。 |
| Multi‑cloud or on‑prem deployments | TPU 仅在 Google Cloud 上提供。 |
| Mixed workloads (ML training + scientific simulation + rendering) | GPU 为通用用途；TPU 为专用加速。 |
| Small teams moving fast | GPU 工具链（分析器、调试器、社区教程）更成熟，诊断性能问题更容易。 |
3.2 TPU 的优势
| 工作负载类型 | 原因 |
|---|---|
| Training massive deep‑learning models (e.g., large language models) | TPU 能高效处理海量矩阵计算。 |
| Models dominated by matrix computations | 其 systolic array 在密集线性代数计算上表现出色。 |
| Long‑running training jobs (weeks or months) | TPU pod 提供高吞吐量并降低每个 token 的成本。 |
| Ultra‑large embeddings (advanced ranking & recommendation) | TPU 的内存架构针对大型权重矩阵进行了优化。 |
| Large‑scale transformer training | TPU pod 可通过 Google 的 Inter‑Chip Interconnect (ICI) 扩展至数万颗芯片；在 TPU pod 上训练类似 Gemma 的模型通常比在 GPU 集群上更快且成本更低。 |
| High‑volume production inference | TPU v6e (Trillium) 与 Ironwood 专为推理设计；Ironwood 相比 v6e 每芯片性能提升 >4×。 |
| Models with no custom PyTorch/JAX ops | 纯 TensorFlow/JAX 工作负载可以直接映射到 TPU 硬件。 |
| Google open‑weight models (e.g., Gemma 4, released Apr 2026) | 针对 TPU 服务进行优化；Google 提供 JAX 参考实现以及通过 vLLM 在 Cloud TPU 上部署的社区指南。 |
3.3 不适合 TPU 的工作负载
- 需要频繁分支或大量逐元素操作的线性代数程序。
- 需要 高精度算术（例如 FP64）的工作负载。
- 在主训练循环中包含 自定义操作 的神经网络工作负载。
4. Google的当前TPU阵容（截至 Cloud Next 2026）
| 代际 | 代号 | 主要用途 | 峰值计算* | 能效 | 主要特性 |
|---|---|---|---|---|---|
| v5e | – | 通用训练与推理 | – | – | 基准代 |
| v6e (Trillium) | – | 大批量推理 | – | – | 为服务优化的内存带宽 |
| Ironwood | – | 下一代推理 | 4× 相比 v6e 每芯片性能 | +67 % 相比 v5e | 原生 FP8 支持，降低延迟 |
| v8 (第 8 代) | – | 大规模训练集群 | 4.7× 相比 v5e 的峰值计算 | +67 % 能效提升 | 通过 ICI 可扩展至数万芯片，集成 vLLM 用于服务 |
*峰值计算值相对于 v5e 代，并由 Google 提供。
5. 快速要点
- GPU = 多功能、工具成熟，适用于所有环境（云端、本地）。非常适合动态模型、混合工作负载，以及已经深耕 PyTorch 的团队。
- TPU = 专为密集矩阵运算设计，在大规模训练和高吞吐推理（当工作负载符合静态图时）方面表现出色。最佳使用场景是 Google Cloud，尤其是以 Transformer 为主的工作负载和 Google 发布的模型。
选择与您的 framework、workload characteristics 和 deployment environment 相匹配的加速器。
Google TPU 第八代概览
关键要点
- 两款新芯片：TPU 8t（训练）和 TPU 8i（推理）。
- 均运行在 Google 的 Axion ARM 主机 CPU 上，并使用液体冷却。
- vLLM 现已支持 TPU v6e，可用于离线批量推理和在线 API 服务。
TPU v6e（推理）
- 每个 pod 256 芯片 – 仍是成本敏感型推理工作负载的主力。
- 单芯片规格
- 4,614 FP8 TFLOPS
- 192 GB HBM3E 内存
- 7.37 TB/s 内存带宽
- 9.6 Tb/s 芯片间互连
- Pod 扩展 – 最多 9,216 芯片 → 42.5 FP8 ExaFLOPS 每个 pod（约为前一代单芯片性能的 4 倍）。
- 在 Google Cloud Next 2025 上宣布。
TPU 8t – 训练芯片
- 用途：高吞吐量模型训练。
- Pod 配置 – 9,600 芯片，2 PB 共享 HBM 内存，121 FP4 ExaFLOPS 计算（约为 Ironwood 每个 pod 计算的 3 倍）。
- 芯片间带宽 – 19.2 Tb/s 每芯片（是 Ironwood 的两倍）。
- 网络结构 – Virgo Network 可在数据中心内部连接 134 k 芯片，理论上在跨站点时可连接 > 1 M 芯片。
- 数据通路增强
- TPUDirect RDMA 与 TPU Direct Storage 绕过主机 CPU，使大规模传输带宽翻倍。
- 效率目标 – 97 % 有效利用率（即 97 % 的周期用于实际学习）。
TPU 8i – 推理芯片
- 用途：低延迟、高吞吐量推理（尤其是 Mixture‑of‑Experts）。
- Pod 配置 – 1,152 芯片，11.6 FP8 ExaFLOPS 每个 pod。
- 内存 – 每芯片 288 GB HBM（比 8t 更多）+ 384 MB 芯片上 SRAM（是 Ironwood 的 3 倍）。
- 性能
- 推理时每美元性能提升 80 %。
- 每瓦性能提升 2 倍。
- 互连 – Boardfly 将最大网络跳数从 16 降至 7，对 MoE 模型至关重要。
- 计算单元 – 用 Collectives Acceleration Engine (CAE) 替代 Ironwood 的 SparseCores，将集合操作延迟降低 5×。
为什么推理芯片的内存更多？
大规模 MoE 推理受限于内存带宽。服务 token 需要比训练更快地流式传输权重和 KV‑cache，因此 8i 在每芯片上配备了更多的 HBM。
工具与生态系统
| 领域 | 推荐工具 |
|---|---|
| 研究与开发 | GPUs（生态成熟，社区庞大） |
| TPU 上的生产 AI | JAX、TensorFlow、PyTorch XLA、vLLM（用于 TPU v6e） |
| 模型参考实现 | MaxText – TPU 的 LLM 参考实现（GitHub） |
| 开源权重 LLM | Gemma – DeepMind 库（GitHub） |
| 推理服务 | Gemma 4 在 TPU 上，定制服务栈 |
延伸阅读
- Google Cloud Blog – TPU 8t and TPU 8i technical deep dive
- Google Cloud Blog – Ironwood: The first Google TPU for the age of inference
- Google Cloud Blog – Training large models on Ironwood TPUs
- Google Cloud Blog – Performance per dollar of GPUs and TPUs for AI inference
- Google Cloud Blog – Building production AI on Google Cloud TPUs with JAX
- GitHub – MaxText: LLM reference implementation for TPUs
- GitHub – Gemma open‑weight LLM library (DeepMind)
- TechRadar – Google Cloud unveils eighth‑generation TPUs
TL;DR
- TPU 8t：大规模训练 pod（9,600 芯片，121 FP4 ExaFLOPS），双倍芯片间带宽，Virgo 结构实现大规模扩展。
- TPU 8i：面向推理的 pod（1,152 芯片，11.6 FP8 ExaFLOPS），更大芯片内存，Boardfly 互连，CAE 加速集合操作。
- 两款芯片相较前代 Ironwood 在每美元性能和每瓦性能上都有显著提升，并且已被最新工具链（JAX、vLLM、MaxText 等）全面支持。
TPUSprint (the original segment’s signature)