⚙️ Google 一年上了四套 TPU：8i Max 把两颗芯片塞进一个封装，内存带宽直接翻倍

同一代芯片，Google 一年发了四套系统。新出的 TPU 8tx 解决的是「数据正在被计算时也不能被看见」，TPU 8i Max 则干脆把两颗 8i 焊进同一个封装，用翻倍的内存带宽去撞那堵「内存墙」。

3分钟看懂：这次到底发了什么

2026 年 11 月 9 日，Google 在官方博客上补上了第八代 TPU 家族的最后两块拼图：TPU 8tx 和 TPU 8i Max。加上 4 月 Google Cloud Next 上发布的 TPU 8t（训练）和 TPU 8i（实时推理），这一代一共四条产品线。

Google 自己强调的一点是：这是它第一次在一年内推出四套 TPU 系统。署名作者是 SVP 兼首席技术官 Amin Vahdat。

一句话分工：

• TPU 8t：大规模训练，官方口径训练性能比上代最高 2.7 倍
• TPU 8i：低延迟推理，官方口径推理性价比比上代好 80%
• TPU 8tx：机密推理 + 小规模训练，数据在「使用中」也保持加密隔离
• TPU 8i Max：超长上下文、单机架最高算力密度

8i Max 是怎么绕开「内存墙」的

AI Agent 跑起来之后，瓶颈往往不在算力，而在内存带宽：几十个 Agent 同时在读一整个代码库，或者一起处理几个小时的视频，芯片大部分时间在等数据。

Google 的解法很直接——把两颗低延迟的 TPU 8i 放进同一个封装。官方给的说法是：算力翻倍、SRAM 翻倍、HBM 带宽翻倍，而且塞进原有 20 机架尺寸里，等于同样的机架、同样的功耗面积，算力密度翻倍。

绝对值参数 Google 没有在博客里公布，媒体侧给出的数字基本对得上：

• HBM 容量从 288GB 提到 384GB
• HBM 带宽从 8.6 TB/s 提到 17.2 TB/s
• 片上 SRAM 从 384MB 提到 768MB

这几组绝对值来自 ServeTheHome、TrendForce、Wccftech 的转述与测算，本文基于多家媒体转述整理；TrendForce 也明确提到，Google 尚未官方确认 8i Max 的 HBM 总容量。所以拿这几个数去和英伟达 Rubin 对比时，要记住口径差异。

对比一下背景：上一代 TPU 8i 用的是 288GB HBM3e 加 384MB 片上 SRAM，专门拿来放 KV Cache，减少对外部内存的依赖。8i Max 就是在同一套思路上把「能装多少」和「每秒能搬多少」同时拉高一倍。

8tx：数据在计算的时候也得是加密的

另一个新系统 TPU 8tx 解决的是合规问题。

平时数据「存着」和「传着」都是加密的，但一旦进了内存开始算，就必须解密——这就是金融、医疗、政府场景最不敢上云的那一段。8tx 的思路是把这一层做进硬件：数据和使用中的模型权重都待在一个隔离的可信执行环境（TEE）里，对外不可见。

实现上它没有做新芯片：沿用 TPU 8t 的硅片，主机侧换成 Google 定制的第五代 AMD EPYC「Turin」处理器。ServeTheHome 的拆解是，双路 Turin 提供 128 条 PCIe Gen5 通道，四颗 TPU 加速卡加高速网卡正好不超配。这对 AMD 是个实打实的胜利——在非 AMD 加速器的系统里拿到了主机 CPU 的插槽。

网络拓扑上，8tx 没有用训练用的 torus，而是借了推理向 8i 的 Boardfly：最大跳数更少。Google 的说法是，多步 Agent 场景下延迟比 TPU 8t 低一半，性能损失接近零。

顺带一个常被忽略的点：因为 8tx 同时有训练级算力和推理级网络，企业可以在同一个集群里用私有数据微调、把大模型蒸馏成小模型、再用强化学习训 Agent，不用把敏感数据搬来搬去。

四套系统放一起看

为什么是「新系统」而不是「新芯片」

Google 在博客里花了不少篇幅解释这件事，逻辑值得记一下：设计一颗新芯片要在晶圆上排几十亿个晶体管，受制程和制造周期约束，动辄几年；而「系统」指的是芯片周围的算力、网络、存储怎么配——封装、高速内存、光网络、安全模块。后者几个月就能改一版。

所以 8i Max 本质上是用封装的复杂度换制程的时间。这也是当下所有做 AI 加速卡的厂商共同的动作：制程越来越贵、越来越慢，就在封装和系统层面找增量。

Google 还提了一句自家的循环：用 AlphaChip 强化学习系统、加上 Gemini，把芯片布局从几周压到几小时。这话听着像宣传，但它确实是这轮「一年四套系统」能成立的工程前提。

软件这次一起放出来的东西

硬件只是表层，这轮更值得注意的是软件栈同时开了一串口子：

• TorchTPU 开源（上月）：PyTorch 代码和 Hugging Face 模型可以原生跑在 TPU 上，不用重写；vLLM、SGLang 也有现成后端
• TPU agent suite（预览）：直接插进 Claude Code、Cursor、Google Antigravity 这类编码工具，用自然语言做上手、瓶颈诊断、kernel 自动调优
• XLA Serving Engine 开源：Python 训练、C++ 低延迟运行时直接对外服务，TPU / GPU / CPU 通吃
• Agent Compute Engine：Agent 是「有状态」的，经常等数据库、等工具、等人回话，这个软件会自动挂起和恢复空闲会话，省的是运营成本
• TPU Sync 开源：把芯片 HBM、主机 DRAM、共享存储、数据中心网络做成一层统一内存层级，KV Cache 毫秒级换出芯片，官方称 KV 传输延迟和首 token 时间（TTFT）降低 90% 以上
• Cloud Pathways 在 GKE 上正式可用、GKE 动态切片正式可用：靠光交换（OCS）现场拼拓扑，任务启动最多快 5 倍，故障恢复最多快 4.5 倍

适用场景：谁该关心、怎么用

• 手上跑的是长上下文 Agent：一次要吃几万个 token 的代码库、文档、视频，8i Max 的带宽和 SRAM 就是为你准备的
• 受监管行业要上云但数据不能明文进内存：8tx 是目前 Google 给出的答案
• 已经在用 PyTorch、不想重写代码就想试 TPU：TorchTPU + vLLM 这条路今年才算真正通了。怎么用：先在 Cloud TPU 上把现有 PyTorch 脚本原样跑一遍，再按官方给的 vLLM / SGLang 后端起服务，最后用 TPU agent suite 做瓶颈诊断和 kernel 调优
• 关心供应链的人：TrendForce 提到台积电是主要受益方，三星和 SK 海力士大致五五分掉 Google 的 HBM3E 订单，三星今年对 Google 的 HBM 出货预计翻倍

不适用场景：别急着对号入座

• 你只需要单卡小模型推理：8i Max 的双芯封装和机架密度跟你没关系，成本也不合适
• 你要的是买一张卡插工作站：TPU 不走这条路，它只在 Google Cloud 或客户自有数据中心里以系统形态交付
• 你在等价格和交货时间：这轮 Google 一个字没提，别按媒体测算的规格去排预算
• 你想拿 8i Max 和英伟达 Rubin 直接比带宽：口径不同，8i Max 是「一个封装两颗芯片」的系统级数字，比较前先统一单位

避坑与注意事项

• 这不是四颗新芯片，是四套系统。8tx 复用 8t 硅片，8i Max 是两颗 8i 同封装。看到「Google 发布四款新芯片」的说法，那是转述失真
• 绝对值参数不是官方给的。384GB / 17.2 TB/s / 768MB 来自媒体，Google 官方只说了「翻倍」
• 「延迟降一半」有前提：是相对 TPU 8t，且是 Boardfly 拓扑下的多步 Agent 场景
• 机密计算不等于绝对安全：TEE 保护的是「使用中」的数据，侧信道、供应链这些层面它管不了
• 别把它当现货：8i Max 的双芯封装意味着良率和产能都有不确定性，TrendForce 的另一篇报道提到联发科承接的 TPU v9 出货可能滑到 2028 年一季度

成本与价格：目前只有一条线索

Google 没有公布 8tx 和 8i Max 的单价、也没有给出按小时计费的 Cloud TPU 价格。能确认的只有两件事：

1. 8i 相对上代的官方口径是「推理性价比好 80%」，这是价格性能比，不是降价
2. TPU 现在有接近 100 家客户，且开始以「装进客户自己的数据中心」的方式交付，商业模式已经不完全是云租赁

真要评估费用，现阶段只能拿 8i 的现价做基准，再按「同机架翻倍算力」去推单位算力成本，误差会很大。

行动建议

• 第一步：如果你在做长上下文 Agent，先去 Google Cloud 文档确认 8i Max 的可用区域和配额，别等价格公布才动手
• 第二步：受监管行业先看 8tx 的 TEE 边界文档，重点确认「密钥由谁管」——这决定了它能不能过你的合规评审
• 第三步：工程团队把 TorchTPU 的迁移成本估一遍，官方说法是不用重写代码，但真实项目里 kernel 级别的手工调优仍难避免
• 第四步：采购侧把「系统级对比」写进需求文档，明确要求供应商同时给带宽、SRAM、机架密度、功耗四项，否则很容易被单芯片峰值算力带偏

参考来源