AREX Feed Article
Google 发布 TPU 8tx 与 TPU 8i Max，一年内第八代 TPU 系统增至四款
11 月 9 日，宣布扩展第八代 TPU 产品组合，新增两款系统：面向机密与安全推理的 TPU 8tx，以及把两颗 TPU 8i 芯片封装进单一封装的 TPU 8i Max。官方称，这是公司首次在一年内推出四款 TPU 系统——此前的 4 月 22 日已在 ——并称 TPU 业务目前有近 100 家客户，涵盖前沿实验室、交易公司、零售商和大学。
硬件之外，Google 当天开源了 ，一个为 TPU 集群管理 KV 缓存与权重传输的开源 C++ 库。官方口径称，它能将 KV 缓存传输延迟降低超过 90%，并在重负载开源 MoE 模型的前缀缓存与分离式推理负载中，把首字延迟（Time to First Token，TTFT）平均降低 90%。加上 10 月开源的 TorchTPU，官方称其思路是把模块化定制芯片与开放易用的软件栈结合，以 AI 行业的节奏交付新硬件和系统配置。
一年四款：芯片慢、系统快的发布节奏
Google 在博客里专门区分了「新芯片」和「新系统」：设计一颗新芯片，意味着在硅晶圆上排布数十亿个晶体管，是受物理定律和漫长制造周期约束的多年工程；而系统是把算力、网络和存储围绕芯片组合起来，包括如何封装，可以数月内交付而非数年。第一代 TPU 发布时，Google 就把 TPU 定位为 AI Hypercomputer 架构里的积木，封装、高速内存、光网络和安全模块都可以围绕芯片快速调整。
这次两款新系统都没有新硅片：TPU 8tx 建在与 8t 相同的硅片上，TPU 8i Max 直接复用两颗 8i。Google 解释了需求来源：随着计算从人的尺度转向 agent 的尺度，企业要求加速器能在模型庞大的上下文窗口里推理；一些受监管程度高的客户则要求针对特殊工作负载的专用加密能力。与 Google DeepMind 共同设计的传统不变，变化在于外部组织现在越来越多地对其具体需求提出反馈。
TPU 8tx：数据在内存里运算时也保持加密
TPU 8tx 是第八代的第三款系统，对准的是要在最敏感数据旁边运行前沿或专有模型、自主 agent 的受监管企业与政府，官方称它也适合小规模训练。
常规做法里，数据在存储和网络传输时加密，但进入内存被处理时必须解锁。TPU 8tx 把保护做进硬件层：与 8t 同硅片、搭配第 5 代 AMD EPYC CPU 主机，官方称敏感数据和模型权重在被主动使用时也保持受保护与隔离。网络沿用为 8i 实时推理打造的低延迟 Boardfly 网络；按官方口径，其延迟最高可达 TPU 8t 的一半，且几乎不损失性能。对照之下，4 月发布的 8t 与 8i 均运行在 Google 自研的 Axion ARM CPU 主机上，8tx 则改配 AMD EPYC。
训练级算力加推理级网络放在同一套系统上，意味着组织可以在单一系统里用私有数据微调模型、把大模型蒸馏成小模型、用强化学习训练 agent，而不必把敏感数据在多个集群之间搬运——这是 Google 给 8tx 列出的三类同机操作。
TPU 8i Max：两颗 8i 封进一个封装，带宽与算力翻倍
第四款系统对准的是内存墙。Google 描述的场景是：数十个 AI agent 同时处理整个软件代码库或数小时的视频时，内存带宽会率先成为瓶颈。它的做法是把两颗低延迟的 8i 芯片放进单一封装——算力、SRAM 和 HBM 带宽相对单颗 8i 全部翻倍，让处理器始终拿得到数据，大型工作负载不停摆。由于现有机架占地内容纳了双倍硅片，数据中心每平方英尺和每瓦能部署的算力随之增加。
今年 4 月发布的 8t 与 8i 奠定了这代芯片的基线：8t 面向大规模训练，单个 superpod 可扩展至 9,600 颗芯片、2 PB 共享 HBM，算力 121 ExaFLOPS；8i 面向延迟敏感的推理，配 288 GB HBM 与 384 MB 片上 SRAM（为上代 3 倍），片间互连带宽翻倍至 19.2 Tb/s。官方当时的口径是：8t 训练性能较上代最高提升 2.7 倍，8i 推理性价比提升 80%。至此四款系统各管一段：8t 大规模训练，8i 低延迟推理，8tx 机密计算，8i Max 超大上下文窗口与单机架计算密度。
TPU Sync 开源：把 HBM、DRAM 和数据中心网络编成一层
TPU Sync 是这批发布里当天开源的新库。Google Cloud 在同日发表的技术文章中把它称为 TPU 集群的「模型状态层」（model-state layer）：芯片 HBM、主机 DRAM、共享存储和数据中心网络被当作一个统一设计的内存层级，KV 缓存与 RL 权重在四层之间直接搬运，而不是困在某颗芯片里让加速器空转。
推理侧，TPU Sync 自动把较旧的 KV 块从 HBM 分层移出到主机内存（实验性支持继续下沉到共享存储），让 256K 到 100 万以上 token 的长会话不至于耗尽 HBM 容量；在 prefill 与 decode 分离的部署中，它用主机到主机的流水线把已算好的上下文直接送到 decode 节点；RL 侧，它向框架暴露底层 DMA 与网络原语，用于训练器与采样器之间的权重同步（实验性模块）。
支撑这些口径的数字出自 Google 2026 年 7 月的内部测试（TPU v7x/Ironwood，受控实验条件）：Qwen3 235B 的中位 KV 传输延迟从数秒降至约 230 ms；低并发条件下，2350 亿～4800 亿参数 MoE 模型的 TTFT 平均下降 90%；持续高流量下 235B 模型的 token 吞吐提升 30%～70%。技术文章同时注明，实际性能随系统配置、带宽、并发和负载而变化。
TPU Sync 以 C++ 实现，经 TorchTPU 和 JAX 接入，直接作为 vLLM（Inferact 维护的 vLLM-TorchTPU）、SGLang（RadixArk）与 llm-d 的 KV 缓存连接器，代码已开源在 （Apache 2.0 许可）。Google 称 Meta 与 Wayfair 等已在采用或评估这套栈。
TorchTPU、XLA Serving Engine 与 agent 计算配套
TorchTPU 的开源发生在 10 月 20 日的 ：它由 Google 与 Meta 的 PyTorch 团队共同开发，让现有 PyTorch 代码和 Hugging Face 模型原生跑在 TPU 上，Transformers v5 里部署到 TPU 只需设置 device_map="tpu"；代码在 仓库，vLLM、SGLang、llm-d、TorchTitan、Ray 均有 TPU 后端。Meta PyTorch 工程总监 Jana van Greunen 在当时的发布文章中说：「TorchTPU 是一大步前进——让我们能与核心机器学习系统团队灵活地共同开发硬件，同时在关键生产用例上支持 LLM、广告和推荐系统工作负载。」
11 月 5 日，Google 又开源了 （Apache 2.0）：模型用 Python 训练，再导出为 XLA SavedModel，由低延迟 C++ 运行时直接服务，去掉 Python 解释器开销。官方研究称，短请求吞吐达到其所能构建的最好 Python 服务器的 2～5 倍；其内部版本已支撑 YouTube Shorts、Google Ads、Search 和部分 Gemini Omni，每秒超过 600 万次查询。文档同样写明边界：它是轻量的一次性推理引擎，长上下文自回归大模型仍建议用 vLLM 或 SGLang。
同篇博客还汇总了两项配套能力。其一是 Agent Compute Engine：官方博客称，当 agent 因等待数据库查询、外部工具或人工反馈而暂停时，它会在毫秒级挂起空闲会话并把工作内存移出芯片，以削减基础设施成本；其 介绍了底层设计——每个 agent 会话运行在硬件隔离的微虚拟机里，沙箱内不持有任何持久凭证。其二是 GKE dynamic slicing 正式 GA：借助光交换（OCS）技术把 TPU cube 动态组合成更大的拓扑（super-slicing）或切分成隔离的小工作负载（sub-slicing），官方称任务启动时间最高降至原来的五分之一，故障恢复速度最高提升 4.5 倍。
性能口径：关键数字都来自 Google 的测试或其援引
延迟减半、三项翻倍、90%、80%、2.7 倍、启动提速——这些数字全部出自 Google 自己的口径。在性能证据上，官方博客援引的第三方基准是 SemiAnalysis 的 与 ：Google 称其原生 vLLM-TorchTPU 软件栈在这两项测试真实 agent 编码与长上下文负载的基准上取得了领先的性价比成绩，但这是 Google 自行援引的第三方，本报道无法独立核验其具体结果；TPU Sync 的 90% 则来自技术文章脚注里的内部测试说明。近 100 家客户同样出自 Google 的描述，博客点名过的客户包括 4 月发布中的 Citadel Securities。
目前外界能直接运行检视的，是 GitHub 上已上线的 与 代码；而 8tx 与 8i Max 的供货时间和定价，官方博客均未提及。