在 AI 从静态模型向自主代理（Agent）演进的过程中，硬件基础设施正在经历一次范式转移。传统 AI 加速器的设计目标是为离线训练或单次推理服务，而代理时代的工作负载呈现出截然不同的特征：多步骤推理、持续循环、动态计算图、以及大量代理之间的协作通信。这些特性对硬件的内存带宽、互连延迟和系统级协同提出了前所未有的要求。Google 于 2026 年 4 月发布的第八代 TPU（Tensor Processing Unit）——TPU 8t 与 TPU 8i—— 正是针对这一趋势的系统性回应。本文将从架构细节出发，解析 TPU 8i 作为 “代理时代推理引擎” 的设计哲学与工程实现。
从单一架构到双芯片分工：第八代 TPU 的定位转变
过去十年间，Google 的 TPU 系列一直采用相对统一的架构思路，兼顾训练与推理需求。然而，随着大规模语言模型进入生产部署阶段，推理算力的需求呈现爆发式增长；与此同时，AI 代理的兴起意味着模型需要反复执行 “推理 — 执行 — 反馈” 的闭环循环，这一工作负载模式与传统的离线训练或单次推理存在本质差异。
Google 在第八代 TPU 中首次引入了双芯片策略：TPU 8t 定位为大规模训练超级计算机，专注于最大化计算吞吐量和规模扩展能力；TPU 8i 则专门针对低延迟推理场景进行了优化，尤其是代理之间的高频交互所引发的延迟放大效应。这种分工并非简单的性能划分，而是在硬件层面实现了 “训练 — 推理” 生命周期的端到端加速：TPU 8t 负责将前沿模型的训练周期从数月压缩到数周，而 TPU 8i 则确保这些模型在部署后能够以毫秒级延迟响应代理工作流中的每一次调用。
值得注意的是，Google 明确指出两款芯片都可以运行各种工作负载，但专用架构能够解锁显著的计算效率提升。这一设计选择反映了硬件开发周期长且需要预判数年后的技术需求这一现实 —— 早在 Agent 概念尚未大规模普及之前，Google 便已经预判到社区将从单纯的模型训练转向对推理基础设施的强烈需求。
TPU 8i 的核心架构创新：突破内存墙
代理场景对推理硬件的核心挑战在于 “内存墙”（Memory Wall）问题。当模型规模达到数百亿参数时，每次推理请求都需要将大量激活值（KV Cache）保留在高速存储层级中，以便后续推理步骤复用。在传统架构下，处理器往往因为等待数据从高带宽内存（HBM）加载到片上计算单元而处于空闲状态 ——Google 将这一现象形象地称为 “候诊室效应”（Waiting Room Effect）。
TPU 8i 通过以下四项关键创新彻底重构了内存层次结构，以消除这一瓶颈：
首先，在容量层面，TPU 8i 配备了 288 GB 的高带宽内存（HBM），同时提供了 384 MB 的片上 SRAM—— 这一数字是上一代 Ironwood 的三倍。更大的片上 SRAM 意味着模型在推理过程中的活跃工作集（Active Working Set）可以完整地保留在芯片内部，无需频繁访问外部 HBM，从而将数据访问延迟降低一到两个数量级。
其次，在 CPU 主机层面，TPU 8i 系统采用了 Google 自研的 Axion ARM 架构 CPU，每个服务器节点配置了双倍于前代的 CPU 数量。通过非均匀内存访问（NUMA）架构实现资源隔离，系统得以针对推理吞吐量进行端到端性能优化，避免了传统 x86 架构中 CPU 成为加速器配重的常见瓶颈。
第三，针对现代混合专家模型（Mixture of Experts，MoE）的通信需求，TPU 8i 将芯片间互连（ICI）带宽翻倍至 19.2 Tb/s。全新的 Boardfly 架构将网络直径（Network Diameter）缩减超过 50%，确保在整个 Pod 中数据能够以最短路径在任意两个芯片之间传输，这对于需要在多个专家模块之间动态路由的代理推理流程至关重要。
第四，TPU 8i 集成了全新的片上集合加速引擎（Collectives Acceleration Engine，CAE），专门负责全局归约和 All-Reduce 等集体通信操作。该引擎将片上延迟降低了最多 5 倍，使得在大规模代理集群中各节点之间的状态同步开销几乎可以忽略不计。
这四项创新共同构成了 TPU 8i 的 “代理推理引擎” 定位：它不仅是一颗更快的推理芯片，更是一个为持续、自主、多步推理工作流而重新设计的计算平台。根据 Google 公布的数据，TPU 8i 实现了每美元性能提升 80%，这意味着企业可以在相同成本下支持接近两倍的用户请求量。
TPU 8t：面向万亿参数训练的超级计算架构
虽然本文的核心关注点是 TPU 8i 所代表的代理推理场景，但第八代 TPU 的另一极 ——TPU 8t—— 同样值得关注，因为它为代理系统的后端提供了训练基础设施保障。
TPU 8t 单个超级计算机 Pod 可以扩展至 9,600 颗芯片，配备 2 PB 共享高带宽内存，双向芯片间带宽是上一代的两倍，整体提供 121 ExaFlops 的计算能力。这一规模的架构设计使得最复杂的模型可以共享一个统一的超大内存池，从而无需进行模型分区即可加载完整参数集。
在可靠性方面，TPU 8t 设定了一个极具挑战性的目标：97% 以上的 “-goodput”（有效计算时间占比）。为了实现这一目标，系统配备了包含实时遥测、故障链路的自动检测与重路由、光路交换（OCS）在内的全套 RAS（可靠性、可用性、可服务性）功能。在万亿参数训练规模下，每一个百分点的 - goodput 提升都意味着数天的有效训练时间增益。
TPU 8t 还引入了名为 Virgo Network 的新型互连架构，配合 JAX 和 Pathways 软件栈，能够实现接近线性的扩展能力，支持单一逻辑集群中多达一百万颗芯片的互联。这意味着未来的代理系统可以在前所未有的规模上实现模型的持续预训练和微调。
从硅到数据中心的系统级效率优化
代理时代的基础设施面临另一层约束：电力。在现代数据中心中，电力供应已经成为与芯片供应同等重要的瓶颈因素。Google 在第八代 TPU 中将效率优化提升到系统层面，而不仅仅是芯片级指标。
具体而言，TPU 8t 和 TPU 8i 均实现了相比上一代 Ironwood 高达两倍的每瓦性能提升。Google 采用了第四代液冷技术来支撑更高的功率密度，同时在芯片层面集成了网络连接功能，显著降低了数据在 Pod 之间流动时的功耗成本。更有说服力的数据是，Google 数据中心在过去五年中实现了每单位电力六倍的计算能力提升，这一成就依赖于从硅到数据中心全栈的协同设计。
对于代理系统而言，这种系统级效率优化意味着可以在不显著增加碳足迹的前提下，支持更大规模的并发代理实例和更长的推理链。
软件生态与开发者友好性
硬件能力的释放离不开软件栈的配合。第八代 TPU 支持主流机器学习框架，包括原生 JAX、MaxText、PyTorch、SGLang 和 vLLM。开发者可以在不改变代码习惯的前提下将工作负载迁移到新硬件上。
尤为值得关注的是，TPU 8i 和 TPU 8t 提供了裸金属访问（Bare Metal Access）模式，允许客户直接操控硬件而无需经过虚拟化层开销。这对于追求极致性能的代理系统开发者而言至关重要 —— 在高频推理场景中，虚拟化层带来的每一次额外跳转都可能累积成可感知的延迟。
此外，Google 还开源了 MaxText 参考实现和用于强化学习的 Tunix 工具，为代理系统的训练与部署提供了从能力验证到生产部署的完整路径。
工程化参数的实践建议
对于计划采用第八代 TPU 构建代理系统的工程团队，以下参数值得关注：
在内存配置层面，代理推理场景应优先利用 TPU 8i 的 384 MB 片上 SRAM 承载 KV Cache，建议将活跃上下文窗口完整保留在片上，以避免 HBM 访问带来的延迟波动。对于超过单芯片容量的模型，建议通过 Boardfly 拓扑结构将通信路径压缩至最小网络直径配置。
在扩展策略方面，单一 TPU 8i Pod 支持的 Boardfly 分层拓扑结构从四个全互连芯片构建块逐步扩展到八个板级全互连组，最终 36 个组全互连构成完整 Pod。代理系统在进行水平扩展时应参考这一拓扑结构，确保新增代理实例在 Pod 内部署时遵循局部性原则，以最大化 ICI 带宽利用率。
在性能监控层面，片上 Collectives Acceleration Engine 提供了细粒度的延迟遥测能力，建议集成到代理系统的监控仪表盘中，实时追踪 All-Reduce 延迟指标。当 CAE 延迟出现显著上升时，往往意味着代理间的协作负载已经接近互连带宽阈值，需要考虑扩容或负载均衡策略。
在可靠性配置方面，TPU 8t 的自动 ICI 链路故障重路由机制适合长时间训练任务，而 TPU 8i 的 RAS 能力则更适合需要高可用性的代理服务场景。建议为关键代理服务配置双 Pod 热备，并通过 OCS 实现硬件故障时的无感知切换。
小结
第八代 TPU 标志着 Google 从通用 AI 加速器向场景定制化硬件的战略转型。TPU 8i 作为代理时代的推理引擎，通过突破内存墙、压缩网络延迟、加速集合通信四大核心创新，为自主代理的多步推理、持续学习和大规模协作提供了硬件层面的原生支持。配合 TPU 8t 在训练侧的超级计算能力以及从硅到数据中心的系统级效率优化，第八代 TPU 构建了一套完整的代理时代基础设施栈。对于正在构建或规划代理系统的技术团队而言，理解并利用这些硬件特性，将成为在未来几年保持系统竞争力的关键因素之一。
资料来源：Google Cloud Blog - "TPU 8t and TPU 8i technical deep dive" (https://cloud.google.com/blog/products/compute/tpu-8t-and-tpu-8i-technical-deep-dive)