我们最新的TPU：8tx与8i Max，为智能体时代打造
内容提要
谷歌发布第八代TPU四款系统：8t面向大规模训练，8i面向低延迟推理，8tx提供硬件级机密计算，8i Max以双芯片封装应对超长上下文和高算力密度。谷歌强调围绕芯片构建系统，通过模块化设计快速交付专用超算，同时开源TorchTPU、TPU Sync等软件栈以降低PyTorch开发者使用门槛，并推出GKE动态切片等技术提升利用率。
延伸解读
从芯片到系统：模块化设计如何加速专用超算交付
文章强调，设计新芯片需数年且受物理定律约束，而系统设计聚焦芯片周边的计算、网络与存储整合。谷歌自首代TPU起便押注系统平衡与模块化，将TPU作为AI Hypercomputer的构建块，使工程师能快速调整封装、高速内存、光网络与安全配置。这种思路让谷歌能在数月而非数年内交付专用超算，从而跟上AI软件的快速演进。
四款TPU各司其职：覆盖智能体全生命周期
第八代TPU首次在一年内推出四款系统，分别针对不同阶段：8t用于大规模基础模型训练，追求每瓦有效智能；8i作为推理引擎，将芯片间通信延迟降低最多一半；8tx面向受监管行业，提供硬件级机密计算，数据在使用中仍保持加密隔离；8i Max则通过双芯片封装，将计算、SRAM和HBM带宽翻倍，专攻百万级token上下文和超高算力密度。
软件栈开源：降低PyTorch开发者迁移门槛
谷歌正系统性地消除TPU采用障碍。上月开源的TorchTPU让PyTorch代码和Hugging Face模型无需重写即可在TPU上原生运行，并为vLLM、SGLang等主流推理引擎提供开箱即用的后端。此外，开源TPU agent套件可接入Claude Code、Cursor等工具，用自然语言自动化TPU上手、诊断瓶颈和调优内核。XLA Serving Engine则支持在Python训练后直接以低延迟C++运行时跨TPU、GPU和CPU部署。
应对智能体工作负载：内存墙与闲置浪费的解法
智能体常因等待数据库查询、外部工具或人工反馈而暂停数秒甚至数小时。新的Agent Compute Engine可在毫秒内挂起空闲会话并将工作内存移出芯片，降低运营成本。针对百万token上下文和持续强化学习带来的内存瓶颈，开源的TPU Sync将HBM、主机DRAM、共享存储和数据中心网络统一为分层内存体系，自动卸载KV缓存，并将KV传输延迟和首token时间降低90%以上。
Q&A
谷歌第八代TPU有哪些型号？各自定位是什么？
第八代TPU共有四款系统：TPU 8t面向大规模训练，追求最大“goodput”；TPU 8i是推理引擎，专为低延迟推理设计；TPU 8tx提供硬件级机密计算，适合受监管行业的安全推理和小规模训练；TPU 8i Max采用双芯片封装，面向超长上下文和高算力密度场景。
TPU 8tx如何实现硬件级数据安全？
TPU 8tx基于与TPU 8t相同的芯片，搭配第五代AMD EPYC CPU主机，将安全能力构建在硬件层，使敏感数据和模型权重在活跃使用期间也保持加密和隔离。它采用为实时推理设计的低延迟Boardfly网络，相比TPU 8t延迟降低最多2倍，性能损失接近零。
TPU 8i Max为什么采用双芯片封装？解决了什么问题？
TPU 8i Max将两颗低延迟TPU 8i芯片封装在一起，以解决智能体协作处理超长上下文时的内存墙瓶颈。它使计算、SRAM和HBM带宽同步翻倍，确保处理器始终拥有必要数据，避免大型工作负载停滞；同时在现有机架 footprint 内集成两倍硅片，提升每平方英尺和每瓦的算力密度。
谷歌如何降低PyTorch开发者使用TPU的门槛？
谷歌开源了TorchTPU，使PyTorch代码和Hugging Face模型无需重写即可在TPU上原生运行，并为vLLM、SGLang等主流推理引擎提供开箱即用的TPU后端。此外，开源TPU agent套件可接入Claude Code、Cursor等工具，用自然语言自动完成TPU入门、瓶颈诊断和内核调优；XLA Serving Engine支持用Python训练并直接以低延迟C++运行时在TPU、GPU和CPU上部署。
TPU Sync是什么？它如何优化超长上下文和强化学习场景？
TPU Sync是面向TPU集群的开源模型状态层，将芯片HBM、主机DRAM、共享存储和数据中心网络统一为协同设计的内存层级。它能自动将大规模KV缓存以毫秒级卸载到芯片外，在分离的预填充和解码节点间流式传输上下文，并同步强化学习权重，从而将KV传输延迟和首令牌时间（TTFT）降低90%以上。
GKE动态切片技术有什么作用？
GKE动态切片利用光路交换（OCS）技术，将物理硬件供给与逻辑切片形成解耦，可动态将TPU立方体组装成更大拓扑（超级切片）或分割为更小的隔离工作负载（子切片），无需手动重建节点池。这使作业启动时间最多缩短5倍，故障恢复速度最多提升4.5倍，从而提高整体集群利用率和有效算力。
