基础设施

CHAPTER 07 # 基础设施：TPU / Pathways / JAX 的垂直整合 这是 Google 最难被资本直接复制的一处差异——它更多是时间的函数，而不只是资本的函数。

    阅读时长 **约 75 分钟**
    时间范围 **2021.01 – 2026.07**
    更新 **2026-07-25**
    交互图表 **6 个**
    来源 **88 条**





  ### 本章要点

1. **护城河的形状是一条十二年的日历，不是一张支票。**从 2013 年那次「信封背面的估算」到 2026 年第八代双芯片，八代硅、一条把编译器 / 拓扑 / 冷却 / 供电绑进同一张设计图的链条。抽掉其中一环，上面那层的设计就未必仍是最优——但这条链条正在被 Google 自己主动削薄（TorchTPU、vLLM on TPU、TPU 外售），见 §11.2 判断 6。

2. 第八代 TPU 分裂成 8t / 8i，是 roofline 公式被直接刻进硅的结果。8i 故意用 10.1 PFLOPS(FP4) 的峰值算力去换 8,601 GB/s 的 HBM 带宽和 384 MB 片上 SRAM——比训练芯片 8t 的 12.6 PFLOPS 低 20%。截至 2026-07-25 它只是官宣，尚未 GA。

3. **电力进入了约束集合，但它没有取代芯片供应。**官方原句是「power, not just chip supply, is a binding constraint」——两个限定词缺一个意思就变了^[1]；同一家公司的 CEO 在另一处把 wafer starts 称为 fundamental constraint、并认为电力「更可解」^[2]。两条口径共同支持「多重约束并存」，不支持任何排序（本章上一版写「约束已经从芯片供应变成电力」，是原句支持不了的强版本，已撤回，见 §8.0）。事实层面可核的是：2025 年 Google 用电 43.6 TWh（+37%），机队 PUE 1.09 在已披露样本中处于领先水平，总排放 +18%；单次 Gemini 文本 prompt 的能耗 12 个月内降了 33 倍，总用电仍涨 37%。

4. 同一个名字的 $/token 在涨，同一个档位的$/token 在跌，两件事同时为真。「Flash」这块牌子的 output 标价从 2024-08 的 $0.30 涨到 2026-07 的$7.50（25 倍）；而 Google 主力档位的 output 标价在 2025-06-17 → 2025-12-17 的 183 天里从 $10.00 降到$3.00（−70%）。跟踪名字还是跟踪档位，会得出完全相反的结论——而「跟踪固定能力门槛」这第三种做法，公开材料目前支撑不了（见 §10.4）。

5. 2026 Q2，Alphabet 第一次把 TPU 整机交付到客户自有数据中心并确认收入，资产负债表上的存货余额从 2025-12-31 的 $2.439B** 涨到 2026-06-30 的 **$9.991B（半年增加 $7.55B，为原值的 4.1 倍）。⚠️ 这是「存货」，不是「TPU 库存」——该科目同时装着待售 TPU 系统与 Pixel 等消费硬件，两者的比例官方未披露，因此全额都不能挂在 TPU 名下。客户与 TPU 代际同样未披露；Pichai 把「前沿 AGI 训练」列为算力分配第一优先级。「产能溢出」与「双轨产能规划」是两个竞争解释，现有披露不足以裁定，见 §7.2c。

    本章 11 节 · 7 个公式推导 · 35 张图（32 张论文/官方配图 + 3 张 deck 翻拍） · 6 个交互图表 ·
    关键词：TPU 8t/8i Boardfly Roofline Pathways 电力约束

   一、为什么这一章的主角不是芯片

   模型架构会被论文泄露、被开源复现、被蒸馏；数据会被爬取、被合成；人才会流动。但一条从 2013 年开始、跨越八代芯片、把编译器 / 运行时 / 拓扑 / 冷却 / 供电 / 电力采购全部纳入同一张设计图的垂直整合链条，更多是时间的函数，而不只是资本的函数。这是本章要论证的主线，其余全部是证据、公式，以及这条主线不成立的那些边界。提前说明一句：本章不打算论证这条护城河「不可复制」——§9.3 与 §11.1 会给出两组反向证据，其中一组来自 Google 自己的行为。

   起点是一次算术。据中文媒体对 NeurIPS 2025 上 Jeff Dean 与 Geoffrey Hinton 对谈的整理：2013 年前后 Google 做了一次「信封背面」的估算——如果一亿用户每天对手机做 3 分钟语音识别，用当时的 CPU 集群来跑，Google 全球机房的规模需要翻一倍；Jeff Dean 在走廊上拦住时任 CFO Patrick Pichette，拍板投入约 5000 万美元做一款只做推理的单槽 PCIe 加速卡^[3]。转述，非原话 这条起源故事的结果是有一手论文可核的：TPU v1 相对同代 CPU / GPU 有 15–30 倍性能、30–80 倍每瓦性能^[4]。

    **图 7.1** Google 博文的**装饰性题图**：三块竖向色带上并列三个扁平矢量芯片图标——左为四边带灰色引脚的针脚封装，中为绿色封装框内的灰色裸片，右为绿色 PCB 上一颗黄色芯片加白色走线。**⚠️ 读法只有一条：这张图不承载任何技术信息。**全图零文字、零标注、零数据，**连哪个图标对应 CPU、哪个对应 GPU、哪个对应 TPU 都没有标**（已切成左右两半各自全分辨率复核）。把 TPU 定位成 **DSA（domain-specific architecture）**、放弃通用性换「稠密矩阵乘 + 低精度」能效——这个论证出自本章正文与 fn1 的 ISCA 2017 论文，**不出自本图**；本图只作章节题图使用。
    [@src-ccf6eb1cf9]出处：Google Cloud Blog《3 things to know about Ironwood》, 2025

   2013 年深度学习刚在 ImageNet 上证明自己一年多，Transformer 还有四年才诞生，LLM 概念不存在。此时押注一款专用 ASIC，本质上不是押注「某个模型」，而是押注一个更抽象的判断：神经网络的一阶计算特征是稠密矩阵乘 + 低精度容忍，这个特征稳定到足以固化进硅。

   这个判断成立了——从 CNN 到 RNN 到 Transformer 到 MoE，十二年里模型换了四代，「大脉动阵列 + HBM + 片间直连」这个骨架一次没换。真正被验证的不是「TPU 有用」，而是**「ML 计算的一阶特征在十年尺度上是不变量」。所以后来者（OpenAI × 博通、Anthropic × AWS Trainium、Meta MTIA）追赶时，追的不是设计能力，而是这个判断被验证的十二年**。

   一个第三方的分析框架把这件事说得更直白。2026-03-31 一场面向内部的中文直播课里，讲师用一页幻灯片总结了「基础设施为什么是战略而不是配套」：自研加速器同时塑造训练成本、模型设计与长上下文 / 实时多模态服务的可行性；推理经济学直接塑造产品形态——「更小的快速模型、路由层、flash 层级不是可有可无的细节」；而拥有软硬一体栈才谈得上协同设计[80]。这份材料本身没有任何内幕信息，它的价值在于把公开事实重新切分成一条因果链。

    **图 7.2** 一份第三方综述对「基础设施即战略」的拆解（显示器翻拍，可见浏览器标签栏与「…的共享屏幕」水印）。页面分两栏：**左栏（蓝底）是四条 bullet**——自研加速器塑造训练成本与模型设计、推理经济学直接塑造产品形态、软硬一体栈才谈得上协同设计、所以 TPU 反复出现在 Gemini 的发布里；**右栏是三个金框卡片，不是四个**：*Research constraint*（The best idea on paper may be impossible at product cost）、*Serving constraint*（Latency and memory dominate real deployments）、*Strategic effect*（**Infrastructure choices shape which model family wins inside a company**）。最值得记住的是第三张——在大公司内部，模型路线之争往往不由论文质量决定，而由谁的架构在现有基础设施上跑得动决定。**本页全部为定性论断，无数据、无来源、无出处，只能当框架用，不能当事实引。**

   二、TPU 代际全谱系：八代硅、两条产品线、一次分裂

   2.1 前史（2015–2018）：v1 到 v3

   时间边界之外的三代必须标明是前史，它们解释了后面的一切，但不属于 2021.01–2026.07 这个窗口。

• v1（2015 部署 / 2016 公开）：28nm，只做推理，256×256 脉动阵列，92 TOPS(int8)，8 GB DDR3，34 GB/s。相对同代 CPU/GPU 性能 15–30×、perf/W 30–80×^[4]。

• v2（2017）：首次支持训练，引入 bfloat16。片上 router 4 条链路、每链路 500 Gbps，组成 2D torus；超算规模 256 芯片、11.5 PFLOPS、4 TB HBM^[5]。

• v3（2018）：官方定位「mid-life kicker」——同为 16nm，MXU 数量翻倍、时钟 700→940 MHz、HBM 容量翻倍、链路带宽 500→650 Gbps、规模 256→1024 芯片（>100 PFLOPS）^[6]。v3 是第一代液冷 TPU：冷板取代散热片让 ML 服务器体积近乎减半，因而芯片密度翻倍、液冷超算规模比风冷的 v2 大 4 倍^[7]。6 个生产应用在 1024 芯片上达到 97%–99% 的线性加速比^[5]。

      **图 7.3** 初代 TPU 的框图。读法：整张图只有一条主干——权重从 Weight FIFO 灌进 256×256 的 MMU，激活从 Unified Buffer 流过去。**没有缓存层级、没有分支预测、没有乱序执行**，这就是 DSA 与通用处理器的分野。
      [@src-b185fa5680]出处：Jouppi et al., ISCA 2017, arXiv:1704.04760
  
  
  
  
  
      **图 7.4** 同一颗芯片的裸片布局。关键读法是那三个百分比：**矩阵乘 24%、片上存储 29%、控制逻辑只有 2%**。通用 CPU 上恰好相反。面积分配是架构哲学最诚实的表达。
      [@src-b185fa5680]出处：Jouppi et al., ISCA 2017, arXiv:1704.04760
  
  
  
  
  
  
  
    **图 7.5** 脉动阵列（systolic array）的数据流动画（267 帧 GIF，**双面板**）。**左面板**是 **5 行 × 9 列**的处理单元阵列：每个单元由一条带红点的深色顶栏（驻留的权重）加下方一小片灰格构成，激活数据从底部的米黄色缓冲带以圆点形式逐拍注入，沿横向与纵向箭头**在相邻单元之间直接传递**，不返回中心存储。**右面板 OUTPUT** 随动画逐行填出五条「印刷数字 N × 手写数字 N = 一排亮度不同的圆点」，N 从 5 到 9——这是一个 MNIST 风格的乘加演示。读法：省掉的那些寄存器读写就是 TPU 能效优势的物理来源。**⚠️ 图上没有出现 “partial sum”、“register file” 或 “padding” 任何字样**：可以从像素直接看到的只有「相邻单元之间有传递箭头」，「部分和不写回寄存器堆」是对这些箭头的解读；「形状必须对齐到阵列边长」（见 §3.1 关于 padding 的讨论）则完全出自正文。
    [@src-78b2686596]出处：Google Cloud TPU System Architecture 文档, 2024

  2.2 v4 → Ironwood：官方规格全表

  下表全部取自 Google Cloud 官方文档或官方 Blog。凡是第三方数字都单独标注；— 表示官方未披露。

| | 代际 | announcement / Preview / GA 三种状态分列，不合并 | BF16 峰值 (TFLOPS/chip) | FP8 / INT8 | HBM 容量 | HBM 带宽 | ICI 带宽/chip | pod 规模 | 拓扑 cube / slice / pod 分列 | 官方 perf/W 声明

| | v1前史 | 2015 部署 / 2016 公开 | —（仅推理） | 92 TOPS (int8) | 8 GB DDR3 | 34 GB/s | 无（单卡） | 1 | — | vs 同代 CPU/GPU 30–80×

| | v2前史 | 2017 | ~46 | — | 16 GB | 700 GB/s | 4×500 Gbps | 256（11.5 PF） | 2D torus | —

| | v3前史 | 2018 | 123 | — | 32 GB | 900 GB/s | 4×650 Gbps | 1024（>100 PF） | 2D torus | 首代液冷

| | v4 | 2020 内部部署 announcement 2021-05-18（I/O） Cloud pod preview 2022-05 GA 2022-10 | 275 | 275 TOPS int8 | 32 GiB | 1,200 GB/s | 6 链路（3D 六向） | 4,096（1.1 EF） | cube 4×4×4 = 64 芯 slice (4i{\times}4j{\times}4k)（可非 2 的幂） pod 16×16×16 3D torus = 64 cube | vs v3 性能 2.1×、perf/W 2.7×

| | v5e | announcement 2023-08（Next ‘23） GA 2023-11-08 | 197 | 393 TOPS int8 | 16 GB | 800 GB/s | 400 GB/s（4 端口） | 256（50.6 PF bf16） | 无 cube 层级 pod 2D torus（256 芯上限） | perf/TCO 基准 0.65×（v6e = 1.0）

| | v5p | announcement 2023-12-06（与 Gemini 1.0 同期） GA 2024-04-09（Next ‘24） | 459 | 459 TFLOPS FP8模拟 | 95 GiB | 2,765 GB/s | 1,200 GB/s | 8,960（最大单切片 6,144） | cube 4×4×4 最大可调度 slice 6,144 = 96 cube pod 8,960 = 140 cube 3D torus | —

| | v6e (Trillium) | announcement 2024-05-14（I/O） GA 2024-12-11 | 918 | 1,836 TOPS int8 | 32 GB | 1,638 GB/s | 800 GB/s（4 端口） | 256（234.9 PF bf16） | 无 cube 层级 pod 2D torus + SparseCore | 峰值 4.7×、能效 +67% vs v5e

| | v7 (Ironwood / TPU7x) | announcement 2025-04-09 Preview 2025-11-24（release notes） 正式 GA 2026-03-31 | 2,307 | 4,614 TFLOPS FP8（原生） | 192 GiB HBM3e | 7,380 GB/s | 1,200 GB/s（9.6 Tb/s） | 9,216（42.5 EF FP8） | cube 4×4×4 pod 9,216 = 144 cube 3D torus + OCS 2 TensorCore + 4 SparseCore | perf/W 2× vs Trillium；≈30× vs 2018 年的 Cloud TPU v2

| | 8t（训练） | announcement 2026-04-22 截至 2026-07-25 无 Preview / GA 条目 | —（官方只给 FP4） | 12.6 PFLOPS (FP4) | 216 GB | 6,528 GB/s | 19.2 Tb/s | 9,600（121 EF FP4 / 2 PB 共享 HBM） | pod 内 3D torus，9,600 = 150 cube（cube 定义官方未重申，见 F7-4 局限） pod 间 Virgo 高基数织物 SparseCore + LLM Decoder Engine | perf/W 2×；训练性价比 2.7× vs Ironwood

| | 8i（推理） | announcement 2026-04-22 截至 2026-07-25 无 Preview / GA 条目 | —（官方只给 FP4） | 10.1 PFLOPS (FP4) | 288 GB | 8,601 GB/s | 19.2 Tb/s | 1,152（36×8×4，其中 1,024 活跃） | Boardfly，非 torus、无 cube： BB 4 芯 → Group 8 板 = 32 芯 → Pod 36 组 = 1,152 连接

• CAE | perf/W 2×；推理性价比 +80% vs Ironwood

    表 7.1 · TPU 代际官方规格全表，数据截止 **2026-07-25**。三条读法：**(1) announcement / Preview / GA 是三种不同状态，本表分列，不得互相顶替**——把 announcement 日当 GA 日是本项目已抓出的高频错误。**(2) cube / slice / pod 是三个不同层级**：v4 的 `4×4×4` 是 **64 芯的 cube**，不是 4,096 芯 pod 的拓扑；pod 一级才是 `16×16×16` 的 3D torus。**(3) 跨代比较峰值算力必须先对齐精度口径**——BF16、INT8、FP8、FP4 不可直接相除；FP8 在 v4 / v5p 上是**模拟**的，Ironwood 才是原生[@src-c2a4c2adc9]。规格来源：v4[@src-02aa879f45]、v5e[@src-b989393ecd]、v5p[@src-4ddab0f19b]、v6e[@src-05046fd7f0]、Ironwood[@src-b3d2608b0d]、8t/8i[@src-7fcb28f154]；GA / Preview 日期以 Cloud TPU release notes 为准[@src-6295285e27]。

  三个必须点出的细节：

1. v5e 与 v6e 是「E 线」（lite），不是「更新的 v5p」。单 TensorCore、2D torus、256 芯片 pod、HBM 只有 2 个 stack——它们是成本优化线，官方给 v5e 的口径就是 perf/TCO 基准值 0.65×^[8]。

2. **Ironwood 是 E 线与 P 线的合流。**官方文档明确写 TPU7x 在 9,216 芯片 pod 规模上「与 v5p 有诸多相似」，同时又被叙述为「首个为推理设计的 TPU」^[9][10]。但「Ironwood 是 inference-only」是不准确的：2025-11-06 那篇公告文档明确覆盖大规模训练、RL 与 serving^[11]。

3. **第八代是 Google 第一次在同一代里出两颗完全不同的芯片。**这是制度性转折，第三节整节讲它。

    **图 7.6** Ironwood（TPU v7）官方架构块图。读法：虚线的 Chip Package 内**并不是两片硅，而是三片**——右上角图例并列了 **Logic Chiplet（两片）**与 **SerDes Chiplet（一片）**。每片 Logic Chiplet 各含 **1 个 TensorCore**（TCS + 2×XLU + VPU/Vmem + 2×MXU）、1 条 Memory and DMA Interconnect、**2 个 Sparse Core**（两片合计 4 个）、4 个 HBM3 Ctrl 及其下 **4 层 8-hi HBM3E Stack**（两片合计 8 层）；右侧独立的 SerDes Chiplet 单独承担片间互联（ICR Router + 6× Link stack + 6×112G SerDes octals + PCS）。**⚠️ 图上不含任何容量或带宽数字**——规格表口径的 192 GiB / 7,380 GB/s 以及「每片 96 GB」都来自官方文档而非本图。跨代比较「每芯片」数字时，封装口径的变化会悄悄放大代差。
    [@src-b3d2608b0d]出处：Google Cloud TPU7x 官方文档, 2025
   
   
   
   
   
   
   
      **图 7.7** Ironwood 计算板实拍：绿色 PCB 上并排**四颗** Ironwood 芯片封装，银色加强框上有 *Ironwood* 丝印，**中央金色封装顶面完全裸露、尚未加装任何散热组件**（已放大到 1400 px 二次确认）；板缘另见若干**鳍片式**散热片、电感与密集贴片元件。**⚠️ 这张照片不能用作液冷的图证**：画面里没有冷板块体、没有进出水嘴或快接头、也没有软管与分水管，唯一可见的散热件是风冷形态的鳍片。它展示的是**裸板与封装形态**；§5.2「液冷让芯片密度翻倍」那条论证的依据是 OCP 的 Deschutes 规格文档[@src-aaade64671][@src-42dfdf5d21]，其物理形态请看下面的**图 7.25**（TPU v4 液冷主板，冷板 + 软管 + 分水管齐全）。
      [@src-ccf6eb1cf9]出处：Google Cloud Blog, 2025-11
   
   
   
   
   
      **图 7.8** Ironwood superpod 的机房实景。9,216 芯片单域、约 1.77 PB 共享 HBM，官方说它「跨越近 **10 MW**」[@src-c2a4c2adc9][@src-ccf6eb1cf9]——这个数字是第八节讨论电力约束的起点。**注意它只说明单 pod 的功率量级，不说明电力已经成为第一约束**（那个更强的说法本章不主张，见 §8.0）。
      [@src-ccf6eb1cf9]出处：Google Cloud Blog, 2025-11

   （1）Ironwood 的完整状态链只有一条：2025-04-09 announcement → 2025-11-24 Preview → 2026-03-31 正式 GA。三个日期对应三种不同状态，不能互相顶替。2025-11-06 那篇 Google Cloud 博客标题写 GA、正文却写 “coming weeks”^[11]——它是一篇营销公告，当时产品仍处 Preview；2025-11-24 的 Cloud TPU release notes 仍把 TPU7x 标为 Preview，直到 2026-03-31 才出现正式 GA 条目^[12]。凡是把 2025-11-06 当作 GA 日的材料都需要修正。

   **另外两个必须切开的日期：**本项目的技术档案把「Ironwood GA」记在了 2026-04-22 的 Cloud Next ‘26 上——这是错的（正式 GA 是 2026-03-31），04-22 只属于 TPU 8t / 8i 的 announcement，与 Ironwood 的产品状态无关，本章以 release notes 为准。

   （2）第八代的制程与代工没有官方口径。媒体报道存在两种互相冲突的说法：一路称 TSMC 2nm、8t 由 Broadcom 协同设计、8i 由 MediaTek 协同设计、目标 2027 年底量产^[13]；另一路的第三方分析写作 3nm^[14]。Google 官方 blog 只说「今年晚些时候 GA」，从未确认制程节点、代工伙伴或量产时间^[1][15]。本章正文一律不写制程数字。MediaTek 版本「据称便宜 20–30%」同样是第三方口径^[14]。

   （3）代号 Sunfish / Zebrafish：本章正文一律不用。Google 的三份第八代官方材料从头到尾只写 8t / 8i，没有出现过任何鱼类代号^[1][15][16]。媒体侧多数同向使用「8t = Sunfish、8i = Zebrafish」，本项目复核到的唯一反向来源同时把年份写错，不足以支撑「两说对半」这种冲突叙事——所以这里既不制造冲突，也不采用代号。**处理口径：正文只用 8t / 8i；确需提及代号时，必须写明它是媒体口径而非官方命名。**本章上一版在规格表与小节标题里直接把代号当作官方名写，已改。

   2.3 第八代：8t 与 8i

   2026-04-22 Google Cloud Next ‘26，Google 第一次在同一代 TPU 里发布两颗完全不同的芯片^[1][15][16]。截至 2026-07-25，Cloud TPU release notes 里没有 8t / 8i 的 Preview 或 GA 条目——它们是 announced，不是 available^[12]。

    **图 7.9** 第八代 TPU 的官方主视觉，**左右双面板**（中间一道黑色竖分隔）：**左面板封装丝印 TPU 8t，右面板 TPU 8i**（两处丝印各自放大到 1480 px 逐字确认），身后均为虚化的 PCB 与相邻封装。肉眼可见的唯一结构差异是 **8i 的封装轮廓更宽、更接近正方**。读法：这张图本身就是本章第三节的论点——Google 认为训练与推理的计算特征已经分家到必须用两块硅分别服务。**⚠️ 全图除这两处型号丝印外没有任何文字或规格数据**：训练/推理分工、制程、代工与鱼类代号都不在图上（代号问题见上方批判块第 3 条）。
    [@src-d53fe6a270]出处：Google Cloud Next '26, 2026-04-22

   8t：训练侧的四项硬技术

• **原生 FP4。**官方原文把动机写成「降低每参数比特数，最小化能耗高昂的数据搬运，并让更大的模型层装进本地硬件缓冲」，顺带把 MXU 吞吐翻倍^[1]。注意它的第一动机是内存搬运而不是算力——这与 §3.1 的 roofline 分析完全一致。

• **Virgo Network。**新的 scale-out 织物：高基数交换机、扁平两层无阻塞拓扑、多平面独立控制域。官方数字：单张 Virgo 织物可连 134,000 颗 TPU 8t，无阻塞对分带宽 47 Pb/s，交付 >1.7K ExaFLOPS，接近线性扩展；配合 JAX + Pathways，单个训练集群可扩到 100 万颗以上芯片（跨多个数据中心站点）^[16]。

• **TPUDirect RDMA / TPUDirect Storage。**绕过 host CPU 与 DRAM，HBM 与 NIC / Lustre 直连；配合 Managed Lustre 10 TB/s，存储访问比 Ironwood 快 10×^[16]。

• **VPU / MXU 重平衡。**更均衡的向量单元扩展，让量化、softmax、layernorm 与矩阵乘重叠，减少「暴露的向量时间」^[1]。这是一次很具体的 Amdahl 修补：MXU 越快，非矩阵乘的那部分越成为新瓶颈。

    **图 7.10** TPU 8t ASIC 块图。图上能直接读到的：**SparseCore 被保留**——Logic chiplet 上并排 **2 个 Sparse core**；**TensorCore 只有一个**（TCS + 2×XLU + VPU/Vmem + 2×MXU）；配 **6 个 HBM3E 控制器与 6 层 12-hi HBM3E stack**；片间互联交给独立的 SerDes chiplet（ICR Router + 6× Link Stack + 6×224G SerDes octals）。**⚠️ 图上不存在名为 “LLM Decoder Engine” 的模块**（已把整个 logic chiplet 区放大到 1450 px 逐块辨读确认）；**“SparseCore 被强化” 同样没有图证**——图上只画出两个方块，没有任何关于卸载 all-gather 的文字。这两点都出自官方 blog 正文[@src-7fcb28f154]，**引用时必须标为文字来源，不能标为读图所得**；「训练芯片正在吸收推理芯片的特征」这个判断也随之只能挂在 blog 措辞上。（原图有两处拼写笔误：`Chip manger`、图例里的 `Memory and DNA`。）
    [@src-7fcb28f154]出处：Google Cloud Blog《Inside the eighth-generation TPU》, 2026
  
  
  
  
  
  
    **图 7.11** 8t 机柜到 **Virgo / Jupiter 两级网络**的连接（左右两区，外框是一栋 *Data center building*）。**左区 Virgo Network**：底部 TPU 8t 机柜内每台主机挂 **4 颗 8t 芯片**（标 ×8），机内走 **ICI (Inter-Chip Interconnect)/SPOCS**，向上经三条独立彩色平面接入标着 *2-layer switching* 的两层交换簇；图例 ① 明写 *fully non-blocking*、② *Resilient fabric with independent planes*。**右区 Jupiter Network**（原图注完全没提的那一半）：*Optical Circuit Switch (Apollo)* + 三个 Aggregation blocks 再上联 *Distributed Global WAN*，对应图例 ③ *Expandable to multi-datacenter sites*。**⚠️ 本图没有画出 pod 内的 3D torus**，也没有出现 torus / 环面 / 立方体任何画法或字样——「pod 内仍是 torus」须另引表 7.1 与官方规格，不能据本图。图上真正画出来的是：**芯片间用 ICI，机柜以上换成高基数交换织物，再往上是 Jupiter 与跨站点 WAN 三级**。
    [@src-7fcb28f154]出处：Google Cloud Blog, 2026-04-22

  8i：推理侧的三项反直觉选择

• 288 GB HBM + 384 MB 片上 SRAM（Ironwood 的 3 倍），目标是「把 KV cache 整个搬上硅」；HBM 带宽 8,601 GB/s，约为 8t 的 1.3 倍^[1]。

• **CAE 取代 SparseCore。**每颗 8i 有 2 个 TensorCore（core die）+ 1 个 CAE（chiplet die），替代 Ironwood core die 里的 4 个 SparseCore，把 all-reduce / all-gather 这类归约与同步硬件化，片上集合通信延迟降低 5×^[1]。

• Boardfly 拓扑，放弃 3D torus。层级是：Building Block（一托盘 4 芯片用内部 ICI 两两全互联，对外留 16 条链路）→ Group（8 块板铜缆全互联，用掉 11 条外部链路）→ Pod（36 组经 OCS 全互联）。⚠️ 本章上一版把托盘内写成「组环」，与官方图 7.13 面板 (a) 直接冲突——那一格画的是 4 颗芯片的完全图（4 条边 + 2 条对角线）并明写 Fully connected，四节点的环只有 4 条链路、没有对角线，已按图更正。算术核对：36 × 8 × 4 = 1,152 颗，官方另说「最多 1,024 颗活跃」，即 1,024 活跃 + 128 备件，与 v5p 的留备件传统一致^[1]。

      **图 7.12** TPU 8i ASIC 块图。读法：**8i 图上已经不再画出任何 SparseCore**（对照图 7.6 的 Ironwood：两片 Logic Chiplet 各 2 个，共 4 个），取而代之的是 SerDes chiplet 的 ICI 区内那个**绿框高亮的 SC-CAE** 块——芯片面积从「embedding 的不规则访存」重新分配给了「解码时每生成一个 token 就要做一次的小规模同步」。底部的 chiplet 分解插图进一步说明它以**独立 chiplet** 形式落地：整颗芯片由 **TN1 / TN2 两个 TensorCore chiplet + 一个 SC-CAE chiplet** 拼成。同时注意 8i 是**双 TensorCore（共 4 个 MXU）+ 8 个 HBM 控制器 / 8 层 12-hi HBM3E**，比图 7.10 里 8t 的单 TensorCore + 6 层明显更宽。**⚠️ 图上未印出 288 GB、8,601 GB/s、384 MB 中的任何数字**；「4 个 SparseCore 变成 1 个 CAE」里的「4」是与前代对比的数字，出自图 7.6 与规格表，不出自本图。（图上的准确标签是 `SC-CAE`，带连字符。）
      [@src-7fcb28f154]出处：Google Cloud Blog, 2026-04-22
  
  
  
  
  
      **图 7.13** Boardfly 的三层结构（**三面板，自左向右逐层聚合，三个层级数都印在图上**）。**面板 (a)**：*4 TPUs on each tray which is building block (BB)*——四颗 TPU 8i **两两全互联**（图上画的是 4 条边加 2 条对角线的完全图，不是环）。**面板 (b)**：*Group (G) of 8 fully connected trays/BB*——8 个 BB 经 **BB-BB#2 Cu links** 全互联。**面板 (c)**：*Fully connected · 36 groups*——36 个 G 之间再次全互联。读法：三个面板下方都写着 **Fully connected**，靠层级把全互联的成本压下来。**⚠️ 图上没有出现 “Boardfly” 或 “Dragonfly” 任何字样**：把它归为 Dragonfly 式高基数拓扑是本章按标准拓扑术语给出的判断（见 F7-3 结论块），**「Google 官方也用 Dragonfly 这个词」这一点本图无法证实，须另引 blog 原文**。
      [@src-7fcb28f154]出处：Google Cloud Blog, 2026-04-22

  2.4 交互：三张代际对比图

    TPU 代际对比（可切指标）
    切换 tab 看算力 / 显存 / 互联；悬停看每条的口径备注
  
  
  
  
  
  
  
  
  
  
  
  
  
        ⚠️ **三组柱子不可直接相加或相除**：BF16、FP8/INT8、FP4 是三种不同精度。**v4 / v5p 的 FP8 是模拟的，Ironwood 才是原生；FP4 只有第八代原生支持**[@src-c2a4c2adc9][@src-7fcb28f154]。v2 / v3 属前史，未入图。
  
  
  
  
  
  
  
  
        读法：**带宽的涨幅一直快于容量**，直到第八代出现分叉——8i 同时把容量（288 GB）和带宽（8,601 GB/s）推到全系最高，而 8t 反而回落到 216 GB / 6,528 GB/s。这一条差异就是 §3.4 的全部内容。
  
  
  
  
  
  
  
  
        读法：ICI 带宽在 v5p → Ironwood 之间**整整一代没有增长**（都是 1,200 GB/s），而算力涨了 5 倍——这条「算力涨、片间带宽不涨」的剪刀差，是 MoE 通信瓶颈的直接来源（见 第 6 章 · B18 MoE all-to-all 通信开销）。8i 的 pod 规模是 1,152 连接 / 1,024 活跃两个口径，图上取活跃数。
  
  
  
  
  
  
  
  
    数据来源：Google Cloud 官方规格文档 v4[@src-02aa879f45] / v5e[@src-b989393ecd] / v5p[@src-4ddab0f19b] / v6e[@src-05046fd7f0] / TPU7x[@src-b3d2608b0d]，第八代取自官方架构深潜博客[@src-7fcb28f154]。文字替代见上方**表 7.1**，逐格数字与本图一致。

  三、★把公式刻进硅：roofline 如何解释了双 SKU

  这一节是全章的核心。它要论证的是：第八代 TPU 分裂成两颗芯片，不是产品线扩充，而是可以被两条公式完整解释的一次专用化——Google 只是第一个把它做成产品的公司。请注意「解释」与「证明」的区别，本节自始至终只做前者：官方从未披露第八代的制程、die 面积与功耗预算，因此没有任何公开材料能把「roofline 长这样」推进到「所以必须造两颗芯片」。能确证的是官方规格与官方自述的 workload specialization 相互一致。

  3.1 Roofline 与 ridge point

    F7-1
    Roofline 模型与机器平衡点
    Williams, Waterman & Patterson, CACM 2009；规格代入 Google Cloud TPU 官方文档
  
  
  
  
  
      符号表

| | (P_{\text{peak}}) | 芯片峰值算力，单位 FLOP/s

| | (BW) | HBM 带宽，单位 Byte/s

| | (I) | 算术强度 = 完成的浮点运算数 ÷ 从 HBM 搬运的字节数，单位 FLOP/Byte

| | (P) | 该 kernel 实际可达的算力，单位 FLOP/s

| | (I^{*}) | ridge point（机器平衡点），单位 FLOP/Byte

| | (b) | 每个权重元素的字节数（BF16 = 2，FP8 = 1，FP4 = 0.5）

      任何 kernel 的执行时间都不小于两件事各自需要的时间：把 \(F\) 次浮点运算做完，以及把 \(M\) 字节从 HBM 搬完。二者可以完全重叠，所以

      \[ t \;\ge\; \max\!\left(\frac{F}{P_{\text{peak}}},\; \frac{M}{BW}\right) \]
      这一步只用了「时间不能为负」和「两条资源可并行」两个前提，没有任何模型假设。



      把可达算力定义为 \(P = F/t\)，代入上式并令 \(I = F/M\)：

      \[ P \;=\; \frac{F}{t} \;\le\; \min\!\left(P_{\text{peak}},\; \frac{F}{M}\cdot BW\right) \;=\; \min\big(P_{\text{peak}},\; I\cdot BW\big) \]
      这就是 roofline：在 log–log 图上它是一条斜率为 1 的斜线（带宽屋顶）接一条水平线（算力屋顶）。



      两条屋顶相交处即 ridge point，令 \(I^{*}BW = P_{\text{peak}}\)：

      \[ \boxed{\;I^{*} \;=\; \frac{P_{\text{peak}}}{BW}\;} \]
      \(I  I^{*}\) 时**算力受限**。




      代入官方规格，得到各代 TPU 的 ridge point（以下 v4–Ironwood 的 BF16 数字与本项目公式档案 B19 一致；第八代为本文按官方 FP4 规格自行代入）：

| | 芯片 | 精度口径 | (P_{\text{peak}}) | (BW) | (I^{*}) (FLOP/Byte)

| | TPU v4 | BF16 | 275 TFLOPS | 1,200 GB/s | 229

| | TPU v5p | BF16 | 459 TFLOPS | 2,765 GB/s | 166

| | TPU v6e | BF16 | 918 TFLOPS | 1,638 GB/s | 560

| | Ironwood | BF16 | 2,307 TFLOPS | 7,380 GB/s | 313

| | Ironwood | FP8（原生） | 4,614 TFLOPS | 7,380 GB/s | 625

| | TPU 8t | FP4（原生） | 12,600 TFLOPS | 6,528 GB/s | 1,930

| | TPU 8i | FP4（原生） | 10,100 TFLOPS | 8,601 GB/s | 1,174

          表 7.2 · 各代 TPU 的 ridge point。**注意 \(I^{*}\) 并不单调上升**：v5p 比 v4 低（HBM 涨 2.3× 而算力只涨 1.67×），v6e 因为砍 HBM 冲到 560，Ironwood 又回落——**在 166–625 区间内震荡，跨代看不出任何单调规律**。**⚠️ 因此不要按「训练导向的世代平衡点更低 / 推理导向更高」这类跨代类型学去归纳，那种归纳既无证据也与本表数据不符**（本章早先版本写过这句，已删）。**可以说的只有同代同精度的一条：同为原生 FP4 的第八代双芯片，8i 的 ridge（1,174）比 8t（1,930）低约 **39%**。**

• 计算与访存可以完全重叠；忽略了 VMEM / CMEM 这一层中间缓存的命中效应。

• 用的是芯片级峰值算力与 HBM 带宽，忽略了片间通信这条第三条屋顶——多芯片系统严格说需要三维 roofline。

• 官方峰值算力是理论值；实际 MXU 在非理想形状、混合精度、有 transpose 时达不到。

• **跨精度比较 ridge point 是有陷阱的。**8t 的 1,930 与 Ironwood BF16 的 313 不在同一口径上；把它们并排解读成「平衡点涨了 6 倍」是错的。同精度下唯一成立的对照是 8t 与 8i（都是原生 FP4）：(1174.3/1930.1=0.608)，即 8i 的 ridge 比 8t 低 39.2%。这条结论只对第八代这一对芯片成立，不可推广成任何跨代规律。

• Ironwood / 8t 的 SparseCore、8i 的 CAE 都不在这条 roofline 里——它们处理的正是低算术强度的不规则算子。

• v6e 的 (I^{*}=560) 看起来很差，但 v6e 是性价比导向的芯片，官方给它的衡量指标是 perf/TCO 而不是 MFU^[17]。用错指标会得出「v6e 是退步」这种错误结论。

      **ridge point 是一颗芯片的「性格」。**它低，说明这颗芯片偏向带宽、适合低算术强度的负载（解码）；它高，说明这颗芯片偏向算力、必须喂给它大矩阵乘（训练与 prefill）。**一颗芯片只能有一个 ridge point**——这是双 SKU 这个决策**可被理解**的地方，但它**不构成**「必须造两颗」的证明：同样与这条公式相容的方案还包括单芯片折中、或用不同的 pod 配置（如 §3.5 的拓扑分化）去承接同一颗硅的两类负载。
  
  
  
  
  
  
  
  **这条公式真正的杀伤力在于它把「该造什么芯片」变成了一个可计算的问题。**它说：如果你的负载算术强度是 8（长上下文解码中的注意力部分大致就是这个量级，见 第 6 章 · B19 TPU 算术强度与 roofline），那么无论你把峰值算力堆到多高，**你能用上的都只有 \(8 \times BW\)**。多出来的 MXU 是纯浪费——而在电力成为约束之后，纯浪费不再只是浪费钱，是浪费一个再也拿不到的 MW。
  
  
  
  
  
  
  
      **图 7.13a** 2017 年初代 TPU 的 roofline（**单面板** log-log 散点，图内标题 *TPU Log-Log*）。纵轴 TeraOps/sec、横轴 Ops/weight byte，均为对数轴。按网格线像素标定实测：**脊点约 1,330 ops/weight-byte、屋顶约 91 TeraOps/s**（与常引的 1,350 及 TPU v1 的 92 TOPS 峰值吻合，标定自洽）。六个负载点的数值印在图上、运算强度为实测：**脊点左侧的访存受限斜段上有四个**——LSTM0 = 3.7（OI≈64）、LSTM1 = 2.8（OI≈96）、MLP1 = 9.7（OI≈164）、MLP0 = 12.3（OI≈203）；**另外两个在脊点右侧**——CNN0 = 86.0（OI≈2,830）已达屋顶的**约 94%**、明确算力受限，CNN1 = 14.1（OI≈1,730）虽然运算强度更高，实测却只有屋顶的约 1/6。**⚠️ 所以准确说法是「六类负载里多数、而不是全部，是访存受限」**，卷积类反而是算力受限的那一头；同时 CNN0 与 CNN1 的对照说明**高运算强度并不自动兑现为高吞吐**。这与「TPU 从第一代起就把 HBM 带宽当成一等指标」的取向一致（Google 未把这张图表述为该取向的原因）。
      [@src-b185fa5680]出处：Jouppi et al., In-Datacenter Performance Analysis of a Tensor Processing Unit, ISCA 2017
  
  
  
  
  
      **图 7.13b** 六年后的同一张图，换成 **TPU v4 / v3 / A100 三条屋顶线**对照（单面板）。像素标定实测（六条绿线的位置反算出 54/75/87/158/162/340，与图上印刷值逐一吻合，佐证标定可靠）：屋顶高度 **A100 约 320、TPU v4 约 270、TPU v3 约 130 TeraOps/s**；脊点 **v3 约 145 → v4 约 225**，**A100 约 170**（均为读图值，±10%）。所以「脊点右移」**只在 v3 → v4 这条代际线上成立，A100 的脊点夹在两者之间，三条并不构成单调右移**。本图信息量最大、原图注却完全没提的部分是**那六条绿色竖直虚线**——它们标出各生产负载的运算强度：CNN1 (54)、DLRM1 (75)、BERT1 (87)、BERT0 (158)、DLRM0 (162)、LLM (340)。把竖线与脊点对照即可读出：CNN1 / DLRM1 / BERT1 在三款硬件上都落在访存受限斜段；**BERT0 与 DLRM0 恰好卡在 v3 与 A100 的脊点之间、且仍在 v4 脊点左侧**——同一个负载在 v3 上算力受限、换到 v4 反而变回访存受限，这是脊点右移最直观的后果；只有 LLM (340) 落在三条曲线的平台区。脊点右移意味着「每搬一个字节必须算更多次才不亏」，这解释了为什么算术强度只有个位数的算子相对成本会逐代变大、算子融合从「优化」变成「必需」。**⚠️ 两点须注意：图中**没有任何实测性能数据点**，绿线只标运算强度、不标达成吞吐，所以本图不存在「实测点到屋顶的垂直距离」这回事；LayerNorm / softmax / RoPE 三个算子名也不在图内，是正文举的例。**（本地图片为论文页裁切，底部原题注 *Figure 16: Roofline models for TPU v4, TPU v3, and A100 plus* 被从中间截断。）
      [@src-9eee0ed8a5]出处：Jouppi et al., TPU v4: An Optically Reconfigurable Supercomputer for ML, ISCA 2023

  3.2 交互：四代 TPU 的 roofline 与瓶颈切换

    Roofline 交互图：拖动看瓶颈在哪一侧切换
    滑杆 1 调算术强度 \(I\)；滑杆 2 假想地把四颗芯片的 HBM 带宽同时乘以一个系数
  
  
  
  
  
    四条曲线的精度口径分别是：v5e = BF16、Ironwood = 原生 FP8、8t / 8i = 原生 FP4；峰值算力与 HBM 带宽均取官方规格[@src-b989393ecd][@src-b3d2608b0d][@src-7fcb28f154]，ridge point 为本文按 \(I^{*}=P_{\text{peak}}/BW\) 计算。**带宽系数 \(k\) 是假想变量，不对应任何真实产品**，它的作用是让读者看到「加带宽 = 把 ridge point 往左推 = 让更多负载落进算力受限区」。文字替代见上方**表 7.2**。
  
  
  
  
  
  展开：这张图的四个 ridge point 与它们的含义（文字替代）

• **v5e（BF16）：246 FLOP/Byte。**E 线的小 HBM 让它的平衡点并不高，但绝对算力也低。

• **Ironwood（FP8）：625 FLOP/Byte。**原生 FP8 把算力翻倍而带宽不变，平衡点相应翻倍——量化提高绝对吞吐，但同时抬高了「要多大 batch 才不亏」的门槛。

• **TPU 8t（FP4）：1,930 FLOP/Byte。**全系最高。它默认你会喂给它大矩阵乘。

• **TPU 8i（FP4）：1,174 FLOP/Byte。**同精度下比同代训练芯片低 39%。同一代、同一精度、同一家公司，两个平衡点相差这么多，与官方自述的 workload specialization（训练 / 推理分工）一致——但 roofline 只能说明这种规格组合是自洽的，不能证明它是设计决策的必要原因。

  3.3 临界 batch (B^{*})：把 roofline 翻译成一个可操作的数字

    F7-2
    解码阶段的临界 batch size
    由 F7-1 推出；规格代入 Google Cloud TPU 官方文档
  
  
  
  
  
      符号表

| | (N_{\text{act}}) | 一次前向真正被读取的激活参数量（MoE 只算被选中的专家），单位：个

| | (B) | 并发解码的序列数（batch size）

| | (b) | 权重每元素字节数

| | (B^{*}) | 算力受限与带宽受限的分界 batch

      解码一步，权重必须从 HBM 完整读一遍，字节数为 \(N_{\text{act}}\,b\)；而这一遍权重被 \(B\) 条序列共享，产生的浮点运算是 \(2N_{\text{act}}B\)（每个参数一次乘、一次加）。于是这一步的算术强度是

      \[ I_{\text{decode}} \;=\; \frac{2N_{\text{act}}B}{N_{\text{act}}\,b} \;=\; \frac{2B}{b} \]
      \(N_{\text{act}}\) 被约掉了——**解码的算术强度与模型多大无关，只与并发数和精度有关**。这是本推导里最反直觉的一步。



      要落在算力受限区，需要 \(I_{\text{decode}} \ge I^{*}\)。代入 F7-1 的 \(I^{*}=P_{\text{peak}}/BW\)：

      \[ \frac{2B}{b} \;\ge\; \frac{P_{\text{peak}}}{BW} \quad\Longleftrightarrow\quad \boxed{\;B \;\ge\; B^{*} \;=\; \frac{b\,P_{\text{peak}}}{2\,BW}\;} \]



      代入官方规格（v5e / v6e / Ironwood / 8i 与本项目公式档案一致，8t 为本文按同式代入）：

| | 芯片 | 峰值 | HBM 带宽 | (b) | (B^{*})

| | TPU v5e | 393 TOPS (int8) | 800 GB/s | 1 | ≈ 246

| | TPU v6e | 1,836 TOPS (int8) | 1,638 GB/s | 1 | ≈ 560

| | Ironwood | 4,614 TFLOPS (FP8) | 7,380 GB/s | 1 | ≈ 313

| | TPU 8t | 12.6 PFLOPS (FP4) | 6,528 GB/s | 0.5 | ≈ 482.5（约 483）

| | TPU 8i | 10.1 PFLOPS (FP4) | 8,601 GB/s | 0.5 | ≈ 293.6（约 294）

          表 7.3 · 临界 batch。核对：\(B^{*} = I^{*}\cdot b/2\)，与表 7.2 完全自洽——**8t：\(1930.1\times0.5/2 = 482.5\)；8i：\(1174.3\times0.5/2 = 293.6\)**。**两个数都写足一位小数再给整数，是为了跨章可核**：只写「293」会被读成向下截断，与公式章 B19 的「294」对不上，而它们其实是同一个 293.57。

• 每一步解码把激活权重完整读一遍；对 MoE 只读被路由到的那部分专家。

• 暂不计 KV cache 的读取。加上 KV cache 后分母变大、算术强度进一步下降，实际门槛只会更难达到（见 第 6 章 · B1 KV cache 显存推导）。

• 忽略 padding：batch 不是阵列边长的整数倍时还有额外损失。

• **量化并不降低这个门槛。**把 (b) 减半的同时 (P_{\text{peak}}) 通常翻倍，(B^{}) 完全不变。Ironwood BF16 与 FP8 的 (B^{}) 都是 313，就是这个原因。量化省的是 HBM 容量和绝对吞吐，不是「需要多大 batch」。

• MoE 更糟：每个专家只被 (kB/N) 个 token 用到，摊销权重读取所需的 batch 还要再乘 (N/k)。以 384 专家、top-8 计，这个倍数是 48。

• 这条式子只约束 FFN / 投影层。注意力部分的算术强度只由 GQA 分组大小决定，加 batch 完全无效——那是另一条更难越过的线。

      要让昂贵的 MXU 不空转，解码时必须同时在飞几百条序列；**而每条序列都拖着一份 KV cache**。于是 KV cache 容量成为真正的瓶颈——这正是 TPU 8i 把片上 SRAM 提到 384 MB、HBM 提到 288 GB 的原因。**厂商在这一格上的所有宣传，都是 \(B^{*}\) 这个不等式的直接推论；它是一个随容量与带宽移动的工程约束，不是一条固定的边界。**
  
  
  
  
  
  
  
  
  
  
      **图 7.14** 五种**注意力配置**下推理显存的构成（单面板**堆叠柱**，红 = model 权重、黄 = kv cache；纵轴 Inference memory (MB)）。按刻度像素标定实测：**模型权重在五种配置下恒为约 3,295 MB**，KV cache 则从 **global only 的 1,744 MB 一路降到 1:3 / sw=1024 的 446 MB**，总高 5,039 → 3,740 MB。**⚠️ 本章上一版把红黄两段说反了，已按图更正**：即便在最费显存的 **global only** 配置下，**KV cache 也只占总显存的约 35%（1,744 / 5,039 MB），占约 65% 的是模型权重**；其余四种配置 KV 占比更低（12%–23%）。真正的看点是**滑窗交替能把 KV cache 压掉约四分之三，而权重一分不变**——权重是常数项，只有 KV cache 是架构手段能动的那一项。**⚠️ 另两点也须更正：图上没有出现 “32k” 字样，横轴是注意力配置而不是上下文长度；图上更没有 batch 轴。**所以「batch 要几百、每条序列各拖一份 cache，于是先触到容量约束」**是 F7-2 的推论，不是这张图的读数**——本图是单条序列口径，把它当作 batch 结论的图证会正好读反。
      [@src-cf5ce22f4d]出处：Gemma 3 技术报告, 2025
  
  
  
  
  
      **图 7.15** KV cache 随上下文长度的增长（单面板，**两条曲线对照**，纵轴是**绝对显存 MB 而非占比**）。黄线 **2B global only**（全部为全局层）从 1K 时的近 0 一路涨到 **128K 时约 6,973 MB**；红线 **2B L:G=5:1, sw=1024**（5 层滑窗配 1 层全局）在同一点只有**约 1,133 MB**，相差约 6 倍。读法的要点是两条线的**斜率差**：全局层的数量决定曲线有多陡；**红线并不是水平的**——它仍保留 1/6 的全局层，所以在 64K 之后同样明显上翘。这与图 7.14 是同一件事的两个切面：架构侧的滑窗交替与硬件侧的大容量片上 SRAM，是在解同一道题的两端（**8i 那个 384 MB SRAM 的数字出自规格表，不在本图上**）。Gemma 是开源线的证据，Gemini 主线的注意力实现**官方从未披露**，不能据此反推。
      [@src-cf5ce22f4d]出处：Gemma 3 技术报告, 2025

  3.4 8t 与 8i：一次教科书级的 roofline 决策

  现在把前两条公式的结论摆在一起看第八代的规格：

| | 维度 | TPU 8t（训练） | TPU 8i（推理） | 差异的方向

| | 峰值算力 (FP4) | 12.6 PFLOPS | 10.1 PFLOPS | 8i 低 20%

| | HBM 带宽 | 6,528 GB/s | 8,601 GB/s | 8i 高 32%

| | HBM 容量 | 216 GB | 288 GB | 8i 高 33%

| | 片上 SRAM | 128 MB | 384 MB | 8i 是 3 倍

| | ridge point (I^{*}) | ≈1,930 FLOP/B | ≈1,174 FLOP/B | 同精度 FP4 下 8i 低 39.2%

| | 临界 batch (B^{*}) | ≈ 482.5（约 483） | ≈ 293.6（约 294） | 同上，低 39.2%

| | 网络拓扑 | 3D torus | Boardfly（高基数） | 带宽敏感 vs 延迟敏感

| | 专用单元 | SparseCore + LLM Decoder Engine | CAE（集合通信加速引擎） | 不规则访存 vs 高频小同步

    表 7.3b · 第八代双 SKU 的规格对照，全部为官方披露[@src-7fcb28f154]；ridge point 与 \(B^{*}\) 为本文按 F7-1 / F7-2 代入官方规格计算。数据截止 2026-07-25，两颗芯片**均尚未 GA**。




把这张表翻译成一句话：**8i 是一颗用峰值算力换带宽的芯片。**它多给 32% 的 HBM 带宽和 3 倍的 SRAM，同时峰值算力低 20%。这在 perf/$ 的语言里是「亏了」，在 roofline 的语言里是「把 ridge point 往左推了 39%，让更多解码负载落进算力受限区」。


  **这里必须先划一条方法论边界，否则下面整节会读成过强的因果。****Google 从未披露第八代任一颗芯片的制程节点、die 面积或 TDP**（见 §2.2 的批判块：2nm / 3nm 只是互相冲突的媒体报道）。因此本章**不能**写「在同一制程、同一功耗预算下，roofline 的数学要求两颗芯片」——这句话的两个前提都是未披露的，结论也超出了 roofline 能承载的强度。**roofline 能做的只有一件事：说明官方公布的这组规格与官方自述的 workload specialization 是自洽的、可解释的。它不能证明这组规格是唯一解，也不能证明分裂是被数学「要求」的。**本节以下所有推理都在这个限定内。



  因为训练和解码落在 roofline 的**两侧**，而 roofline 只有一个拐点。

  训练与 prefill 是矩阵–矩阵乘：一次处理 \(T\) 个 token，算术强度约为 \(\min(2T/b,\ d/b)\)，几百个 token 就能轻松越过 1,930；**它们要的是尽可能高的 \(P_{\text{peak}}\)**。解码是矩阵–向量乘：算术强度只有 \(2B/b\)，而 \(B\) 受 KV cache 容量与延迟 SLO 双重压制；**它要的是尽可能高的 \(BW\)**。

  只要硅面积与功耗预算是有限的，\(P_{\text{peak}}\) 与 \(BW\) 之间就存在取舍——**这是一个定性的工程事实，不是一条可以代入数字的定理**：取舍曲线的具体形状取决于制程、HBM 代际、封装与 die 面积，而这四项**官方一项都没公布**。所以本章只说到这里：**「一颗芯片同时服务两侧」需要在一条真实存在的取舍曲线上找折中，而 Google 选择了不折中。**官方给这次分裂的宏观动因是电力——当能量成为硬约束时，通用性的代价会被放大。**这是一个与证据相容的解释，不是被证明的因果链。**



### 3.5 拓扑侧的同一道题：torus 直径与 Boardfly

算术强度决定了要多大 batch；**网络直径决定了凑齐这个 batch 要付多少延迟税**。第八代在拓扑上做的分裂，和在带宽上做的分裂是同一个决策。



    F7-3
    k-ary n-cube 的网络直径与对分带宽
    TPU v4 论文 (arXiv:2304.01433) + Google Cloud 第八代架构深潜博客





      符号表

| | (n) | torus 的维数（v2/v3/v5e/v6e 为 2，v4/v5p/Ironwood/8t 为 3）

| | (k) | 每维的边长（节点数）

| | (N) | 总节点数，(N=k^{n})（等边情形）

| | (D) | 网络直径：任意两点之间的最大最短跳数

| | (k_x,k_y,k_z) | 不等边 torus 三个维度的边长

| | (b_{\text{link}}) | 单条链路的单向带宽，Byte/s

| | (B_{\text{bisect}}) | 对分带宽：把系统切成两半时穿过切面的总带宽

      在一维环（\(k\) 个节点首尾相连）上，任意两点的最短距离最多是绕半圈，即 \(\lfloor k/2 \rfloor\) 跳。torus 的各维彼此独立，最坏情况是每一维都要走半圈，于是

      \[ D \;=\; n\left\lfloor \frac{k}{2} \right\rfloor \]
      「各维独立」成立是因为 torus 上的维序路由（dimension-order routing）逐维消解坐标差，各维代价可加。



      不等边情形直接把各维分别算：Google 官方在第八代博客里对一个 \(8\times 8\times 16\) 的 1,024 芯片 torus 给出

      \[ D_{\text{torus}} \;=\; \frac{8}{2}+\frac{8}{2}+\frac{16}{2} \;=\; 4+4+8 \;=\; \mathbf{16}\ \text{跳} \]
      同样 1,024 个节点，若摆成 \(32\times32\) 的 2D torus，\(D = 16+16 = 32\) 跳——**维数从 2 升到 3，直径直接减半**。



      固定 \(N\)，把 \(k = N^{1/n}\) 代回，得到直径关于维数的连续形式：

      \[ D(n) \;=\; \frac{n}{2}\,N^{1/n} \]
      对 \(N = 4096\)：\(D(2)=64\)、\(D(3)=24\)、\(D(4)\approx 16\)。

      看上去维数越高越好，但每升一维，每颗芯片要多两个物理 SerDes 端口和两组线缆。v4 每芯片 6 条 ICI 链路，正好是 3D 的 \(2n\)；四维要 8 条，在 2020 年的封装与线缆预算下不划算。**「3D」是 \(D(n)\) 的收益曲线与 I/O 成本曲线的交点，不是审美。**



      再看带宽侧。把 \(k_x\times k_y\times k_z\) 的 torus 沿 \(x\) 维切开，切面是一个 \(k_y\times k_z\) 的平面，每个位置有**两条**链路被切断（torus 的环绕边让每对节点之间有两条路径），于是

      \[ B_{\text{bisect}} \;=\; 2\,k_y k_z\, b_{\text{link}} \]
      核对官方数字：v4 全 pod 是 \(16^3=4096\) 芯片，切面 \(2\times16\times16 = 512\) 条链路，官方对分带宽 **24 TB/s**[@src-02aa879f45]，反推每链路约 47 GB/s，与 v4 每芯片 6 条 ICI 的规格自洽。




      关键推论：对等边 3D torus，\(k_yk_z = N^{2/3}\)，所以

      \[ B_{\text{bisect}} \;\propto\; N^{2/3} \qquad\text{而}\qquad \text{全 all-to-all 的数据量} \;\propto\; N \]
      于是一次全 pod all-to-all 的耗时 \(\propto N/N^{2/3} = N^{1/3}\)。**3D torus 上的 all-to-all 随规模的立方根变慢**；而全带宽 fat-tree 上它与 \(N\) 无关。

• 维序路由、无拥塞、链路带宽均一；真实系统里热点专家会让尾延迟远高于均值。

• 对分带宽公式假设沿最短的一维切；沿长维切会得到更大的数值，官方数字通常取最小值。

• all-to-all 的 (N^{1/3}) 结论是理想带宽模型，未计消息启动延迟；小消息时延迟主导，结论会更糟。

• (D) 是最坏情况跳数，平均跳数约为它的一半。用直径衡量吞吐会偏悲观，用它衡量尾延迟才准确——而解码恰恰是尾延迟敏感的。

• torus 的劣势只在 all-to-all。对 all-reduce（数据并行的主要模式），ring 算法在 torus 上是带宽最优的，且 3D torus 的对分带宽绝对值很高。说 torus「不好」是错的，准确说法是它在两种通信模式上的排序恰好相反。

• 跨 pod 时带宽掉一个量级：v5p 的 DCN 带宽是 50 Gbps/芯片，比 ICI 的 1,200 GB/s 低约 192 倍。任何跨 pod 的专家并行在通信上都是灾难。

      **Boardfly 就是对 \(D = 16\) 这个数字的正面回应。**官方给的层级是 BB（4 芯片）→ Group（8 板全互联）→ Pod（36 组经 OCS 全互联），任意芯片对之间最多 **7 跳**，相对 torus 的 16 跳**减少 56%**，整体 all-to-all 延迟改善「最高 50%」[@src-7fcb28f154]。这是 Dragonfly 高基数思想在 1,024 芯片尺度上的应用。
  
  
  
  
  
  
  
  
    同样 1,024 颗芯片：16 跳 vs 7 跳
    最坏情况路径的逐跳对照
  
  
  
  
  
  
  
    本图为按官方描述手绘的示意图，非官方原图；层级结构与跳数均取自 Google Cloud 第八代架构深潜博客[@src-7fcb28f154]。**示意图把路径画成一条直线，实际 torus 是三维环绕结构**，官方原图见下方图 7.16。
  
  
  
  
  
  
  
    **图 7.16** Boardfly 的 7 跳网络直径官方示意。**本图画的是「最坏情况那一条路径」本身**：从 **Group N** 里的 *Start* 出发，先在组内经 **①②③** 三跳走到出口 building block；**第 ④ 跳**是穿过中间那个标着 *Optical hop* 的 **OCS** 光跳，落到 **Group M**；再经组内 **⑤⑥⑦** 三跳抵达 *Destination*。跳数之所以能压到 7，靠的就是中间那一次长距光跳**把「远处」直接拉近**——**而且全程只有一跳是光跳**。**⚠️ 图上没有任何链路总数、OCS 端口数或成本数字**：「代价是链路总数与 OCS 端口数上升、高基数拓扑用成本换直径」是本章按拓扑成本模型给出的推论，不是读图所得。另注意图中每组只示意画了 4–5 个 building block，**不是完整的 8 板拓扑**（完整层级见图 7.13）。
    [@src-7fcb28f154]出处：Google Cloud Blog, 2026-04-22
  
  
  
  
  
    **为什么这是「公式刻进硅」解释力最强的一个例子。**训练的瓶颈是 all-reduce 带宽，torus 的邻居通信效率最高 → 8t 保留 torus；推理的瓶颈是 all-to-all 延迟 + 访存带宽，torus 的 16 跳直径变成尾延迟税 → 8i 换 Dragonfly 式高基数拓扑降到 7 跳；解码严重访存受限 → 8i 给 3 倍 SRAM 与更高 HBM 带宽，**而峰值算力反而更低**。三条设计决策与三条公式一一对应，**这个对应关系很整齐，但整齐不等于因果**：Google 从未公开说过这三个决策是由这三条公式导出的，右边这个 批判 块给的是另一条同样能解释全部规格的时间线。
  
  
  
  
    **但双 SKU 也可能是被迫的。**把时间线摊开看，另一个解释同样成立：Google 在 2025 年发现自己在 MoE 在线推理上打不过 NVL72。3D torus 的 \(O(N^{1/3})\) 直径对稳定的稠密训练是最优性价比，对「任意芯片随时要和任意芯片说话」的 MoE 解码是灾难。**Boardfly 是对这个结构性劣势的正面回应，而且它只解决了 pod 内的问题**——跨 pod 依然要走 OCS 与数据中心网络，带宽骤降。所以 2026–2027 的胜负手是一个可证伪的问题：**前沿 MoE 模型的「有效通信域」需要多大？**需要 1,024 芯片，Boardfly 够用；需要 4,096，8i 就要付跨 pod 的代价。

  四、OCS 光路交换：Google 最被低估的一手

  TPU v4 那篇 ISCA 2023 论文真正的主角不是芯片，是 Palomar 光路交换机^[18]。

  4.1 Palomar：把「重新布线」变成「改路由表」

  **问题是什么。**v3 的 2D torus 在 1,024 芯片规模上，某些环绕链路已经长到必须用光纤（电缆有距离上限），而光链路比电链路贵 10 倍以上。要再扩 4 倍到 4,096 芯片，光链路数量会爆炸，同时 2D torus 的对分带宽和整机可用性都撑不住。

  Google 的解法是不做「光互连」，做「光交换」——用 3D MEMS 微镜阵列做一台毫秒级切换的电路交换机。关键工程点全部来自论文原文^[18][19]：

• Palomar 是 136×136 端口（128 可用 + 8 备用，用于链路测试与修复），基于 3D MEMS 微镜，切换时间毫秒级。

• 用环行器（circulator）让同一根光纤双向传光，端口与线缆数量直接减半。

• 一个 (4^3) cube 有 6 个面，每面 16 条链路 = 96 条光链路。为了做出 3D torus 的环绕边，对面两个面的链路必须接到同一台 OCS，因此每个 cube 连 (6\times16\div2 = \mathbf{48}) 台 OCS。

    **图 7.17** 4×4×4 cube 到 OCS 的连接（**双面板**）。**上面板**用三维坐标画出 64 颗芯片的立方体（节点标 000–333），并把 X / Y / Z 三个方向的环绕边以带坐标标签的短线（`X+[0][0]`、`Y+[0][@src-0b1b396f1b]`、`Z−[@src-0b1b396f1b][0]` 等）引出立方体之外。**下面板**给出这些环绕边的物理落地：立方体分别连向 **X OCS / Y OCS / Z OCS 三组**光交换机，**每组都用花括号标注 ×16**，每条连线也标 ×16，三色缆线绕回立方体即构成环绕边。**⚠️ 所以图上是「三组、每组 16 台，合计 48 台」，不是「三台」**——这与上面 §4.1 第三条算出的 \(6\times16\div2=48\) 完全一致（本章上一版的图注写成「三台 OCS」，与自己的正文打架，已更正）。读法：3D torus 的拓扑不是被焊死在机架上的，而是每天由 OCS 现场拼出来的。（本地图片为论文页裁切：顶部残留正文末行「…64 chips), yielding the desired total of 4096 TPU v4 chips.」，底部残留被截断的原题注。）
    [@src-9eee0ed8a5]出处：Jouppi et al., TPU v4, ISCA 2023

  4.2 OCS 的可扩展式

    F7-4
    OCS 端口数决定的 pod 规模上限
    由 TPU v4 论文的 OCS 连接方案推出
  
  
  
  
  
      符号表

| | (P_{\text{OCS}}) | 单台 OCS 的可用端口数（v4 时代为 128）

| | (N_{\max}) | 一个 OCS 域内可容纳的最大 TPU 芯片数

| | (C) | cube 数量

      每个 cube 有 64 颗芯片、96 条对外光链路，经环行器折半后占用 **48 台 OCS 上各 2 个端口**（一进一出）。因此一台 OCS 能服务的 cube 数是

      \[ C \;=\; \frac{P_{\text{OCS}}}{2} \]



      芯片总数 = cube 数 × 每 cube 芯片数：

      \[ \boxed{\;N_{\max} \;=\; 64\,C \;=\; 64\cdot\frac{P_{\text{OCS}}}{2}\;} \]
      代入 \(P_{\text{OCS}} = 128\)：\(N_{\max} = 64\times 64 = \mathbf{4096}\)——**正是 TPU v4 的 pod 规模**。




      反过来用它做外推。Ironwood 的 pod 是 **9,216 = 144 cube**，反推需要 \(P_{\text{OCS}} = 288\)；v5p 的 8,960 = 140 cube（144 里留 4 个 cube 做备件，与官方「最大可调度切片 6,144 = 96 cube」的留量政策一致[@src-4ddab0f19b]）；TPU 8t 的 **9,600 = 150 cube**，反推 \(P_{\text{OCS}} = 300\)。

      中文媒体转述 SemiAnalysis 的说法正是「Google 主力 OCS 已升级到 300×300 / 288 端口」转述[@src-641c810714]。**三代 pod 规模与端口数的算术完全自洽，但它仍是推断，不是官方规格。**

• cube 大小恒为 (4^3=64)，且每 cube 的对外链路数与 v4 相同。第八代若改变了 cube 定义，整条外推失效。

• 假设一个 pod 只用一层 OCS，没有 OCS 级联。

• 忽略为备件预留的端口。

• 官方从未披露 v4 之后的 OCS 端口数。本推导是从 pod 规模反推端口数，属于「用结论倒推前提」，只能说它自洽，不能说它被证实。标 待核。

• 8i 的 Boardfly 已经不是 cube 结构，这条式子对它不适用。

      **pod 规模不是「Google 想做多大就做多大」，它是一台交换机端口数的 64 倍。**这解释了为什么 TPU 的 pod 规模是 4096 → 8960 → 9216 → 9600 这样一串看似奇怪的数字：**它们全都是 64 的整数倍，而倍数由 OCS 决定。**

  **OCS 换来了什么？**论文列了六条，这里挑三条最硬的：

1. **成本与功耗几乎白送。论文原文：「OCS 及其光学组件占整机资本成本 1 GW（Anthropic 一手声明^[20]）。「2027 年起 Google/Broadcom 合计 5 GW」这个数在冻结日没有一手支撑，详见下方 §7.2 末尾的口径说明。

| | 指标 | 2026 Q2 | 同比 / 环比

| | 总营收 | $119.8B | +24% YoY

| | Google Cloud 营收 | $24.8B | +82% YoY

| | Cloud 营业利润率 | 35.6% | 去年同期 20.7%

| | Cloud backlog | $514B | 含 TPU 系统销售协议

| | 单季 capex | $44.9B | +107% YoY；约 60% 服务器 / 40% 数据中心与网络

| | FY2026 capex 指引 | $195–205B | 上调自$180–190B

| | 模型 API token 吞吐 | 约 220 亿 token/分钟 | 上季度 160 亿

| | Gemini App MAU | 9.5 亿 | —

| | AI Mode MAU | >10 亿 | —

| | 存货（资产负债表期末余额，TPU 系统与 Pixel 混装） | $9.991B 2026-06-30 | 2025-12-31 为$2.439B 半年增加 $7.55B，为期初的 4.1 倍；2025-06 无可比单列余额，不能算同比；TPU 与 Pixel 的比例未披露，全额不得称「TPU 库存」

    表 7.6 · Alphabet 2026 Q2 关键财务与算力指标，数据截止 2026-07-22 电话会[@src-9f4a08bfb1][@src-7775dbd964][@src-646dcb0e6c]。**存货一行取 Q2 SEC 文件的资产负债表口径**[@src-7775dbd964]；不要与现金流量表里的「存货变动」调整额（2025 H1 \$0.628B / 2026 H1 \$7.739B）混用，两者不是同一个东西。**另注：这一行是混合科目，含待售 TPU 系统与 Pixel，比例未披露**，见上方批判块。





  因为它同时改变了三件事。**（1）收入性质**：从「云服务（按使用计费、高毛利、收入递延）」变成「硬件销售（一次性确认、带库存成本、毛利率结构完全不同）」。Other Cost of Revenues 里出现「TPU 系统库存成本」这一项，意味着 Alphabet 的损益表**第一次有了硬件公司的成分**。**（2）竞争位置**：Google 从「Nvidia 的大客户 + 云上竞争对手」变成「Nvidia 在数据中心销售环节的直接竞争者」。**（3）但优先级没变**：Pichai 的原话把话说得非常明白——第一优先级是分配在前沿竞争 AGI 开发所需要的算力[@src-30dc71eda9]。

  所以准确的说法不是「Google 要做芯片公司」，而是**「用产能换生态位与现金流，同时保住内部优先权」**。这与 Nvidia 的「所有人都是客户」是不同的商业契约。**但「内部优先权」目前只有一条证据——CEO 在电话会上的口头排序[@src-30dc71eda9]，没有任何披露显示这条排序在产能分配上被如何执行。**而「这些产能到底是内部用剩的、还是一开始就分了内外两条线」，是一个本章无法裁定的问题，两个竞争解释见 **§7.2c**。



### 7.2 追问：把 TPU 卖给 Anthropic 这类对手，是商业胜利还是战略失焦？

Anthropic 的 Claude 是与 Gemini 竞争最直接的模型。Google Cloud 把 TPU 大规模承诺给它，等于把自己最稀缺的战略资产交给正在试图打败自己姊妹部门的公司。四层理由与一条反驳：



    **1 · 规模经济的分母。**TPU 的固定成本（设计、流片 mask、编译器团队、OCS 与液冷研发）是巨额沉没成本，摊到越多芯片上越便宜。最多 100 万颗的承诺[@src-97c582cac1]直接把分母做大了一个量级，**Gemini 自己的每芯片成本因此下降**。

    **2 · 对 Nvidia 的价格战武器。**第三方观察极辛辣：「OpenAI 连一颗 TPU 都还没部署，就已经因为竞争威胁让整个实验室的 Nvidia 机队降价约 30%。」[@src-0923568307]**TPU 的存在本身就是议价工具，哪怕从没启用。**

    **3 · 第三方背书。**Anthropic 是世界上最挑剔的 buyer 之一，它的大规模采购直接服务于 Google Cloud 面向所有其他买家的销售。

    **4 · 股权对冲。**Google 持有 Anthropic 股权，Anthropic 的成功部分对冲了 Gemini 的失败风险。




    第三方批评：「Gemini 需求激增时，这些承诺让 Google 自己的 DeepMind 研究员缺算力。」[@src-3020c282f7]中文媒体的措辞更重：「谷歌领导层在战略上对 Scaling Law 缺乏绝对信仰，竟然把珍贵的 TPU 算力打包卖给或租给了竞争对手，而不是留给自家的 DeepMind。」[@src-641c810714]

    **最有力的证据不是这些评论，而是 Pichai 的回应本身。**他在 2026 Q2 电话会上主动给出算力分配的优先级排序（前沿 AGI 训练第一、云客户第二、自家产品第三）[@src-30dc71eda9]——**一个不存在的争议不需要被 CEO 在财报电话会上排序。这说明张力是真实的。**

    更值得注意的是**中文圈与英文圈的叙事完全相反**：英文媒体把同一件事写成「Google Cloud 赢得大客户」的中性商业新闻，中文媒体读成「战略优先级错乱的证据」[@src-641c810714]。同一组事实，两种评价框架——**这个分歧本身比任何一方的结论都更有信息量。**






  **还有一个结构性矛盾没人能解决：双 SKU 之后，产能分配变成了内部政治问题。**8t 和 8i 的产线、HBM 配额、数据中心机位都要提前几个季度分配，但「明年需要多少训练算力 vs 多少推理算力」取决于 Gemini 4 的训练方案、agent 产品的采用速度、外部客户的用量、外售订单的交付——**四个都无法准确预测的变量**。Pichai 那套优先级本质上是一份**配给制的宣告**，而配给制在需求高增长期一定会得罪人。



#### 7.2b Anthropic × Google × Broadcom 的容量数字：逐条分清谁说了什么

这组交易被广泛引用，但流传的几个数字来自**不同主体、不同文件、不同确定性等级**。本章把它们拆开列，**并且不采用其中最常被引用的那个「5 GW」**。

| | 说法 | 谁说的 / 出自哪份文件 | 本章是否采用

| | 最多 100 万颗 TPU；2026 年上线 >1 GW | Anthropic 2025-10-23 一手公告^[20] | **采用。**双方官宣，措辞明确。

| | 「multiple gigawatts」的下一代 TPU 算力，2027 年起上线 | Anthropic 2026-04 一手公告页^[21] | 采用，且照抄原措辞。这一页没有给出任何具体 GW 数字。

| | 约 3.5 GW；Broadcom 供应 TPU 及网络组件至 2031 | Broadcom 监管文件，经权威行业媒体转述^[22] | **有条件采用，条件必须一并写出：**该 filing 把规模挂在 “continued commercial success” 这类前提条款下，不是无条件的交付承诺。引用 3.5 GW 时不得省略这个条件。

| | 5 GW（2027 年起 Google/Broadcom 合计） | 无一手来源 | **不采用。**Anthropic 04 月页面只写 multiple gigawatts；Broadcom filing 写的是 3.5 GW 且带条件。**冻结日找不到任何一手声明说「5 GW」。**本章早先版本写了这个数，已删。

| | $200B / 5 年**；**Alphabet 至多$40B 投资 | 匿名消息源，双方均未证实 | 不采用存疑（与 REVIEW-03 IF18 一致）。

    表 7.6b · Anthropic–Google–Broadcom 容量数字的来源分级。**这张表的价值不在于数字本身，而在于示范一件事：同一笔交易的「规模」在一手公告、监管文件与匿名消息源三层里是三个不同的数，且逐层变大。引用时不写清是哪一层，等于默认读者接受最大的那个。**




#### 7.2c ★「外售是产能溢出」还是「双轨产能规划」：两个竞争解释，现有披露裁不了



    **反方主张：「溢出」这个词用错了。**溢出的定义是「先满足自己，多出来的卖掉」，
      是一个**事后**处置动作；而资产负债表上半年多出来的 **\$7.55B** 存货是
      **事前**为交付而制造的成品。内部优先与为外售预先建产可以同时为真，
      **但那就不该叫溢出，应该叫双轨产能规划。**




    三条可核事实支持这个方向：

• 存货余额从 $2.439B 涨到 $9.991B，而这批货在 Q2 时点上还没确认为收入——CFO 明说今年只确认现有协议中相对小的一部分，绝大部分收入落在 2027^[23]。先造后卖，是硬件厂商的节奏，不是云厂商的节奏。

• Other Cost of Revenues 里出现「向客户销售 TPU 系统的库存成本」这一项^[24]，说明这条产线在会计上已经被单独识别。

• 这些协议已经计入 $514B 的 Cloud backlog^[23]——backlog 是签约在先、交付在后，与「多出来的卖掉」在时间方向上相反。

    ★**反方成立需要一个它拿不到的前提：那 \$7.55B 增量确实主要是 TPU。**
      而这个科目是**混合的**——待售 TPU 系统与 Pixel 等消费硬件装在同一行，
      **比例官方从未披露**（见 §7.1 批判块）。**把全额当成 TPU 备货，就是把一个混合科目全归到一个产品上**；
      Pixel 也有自己的季节性备货节奏。
  
      **因此反方的证据强度是：方向可信，量级不可核。**
  
  
  
  
    双方都不足以裁定归因之争
  
    **两个竞争解释并列，本章不判权重：**
  
    **竞争解释 A（产能溢出的变现）**——成立条件：TPU 产能的规划量由内部需求决定，外售只消化内部用不掉的部分。
      **支持它的证据**：Pichai 在 Q2 电话会主动给出的分配优先级（前沿 AGI 训练第一、云客户第二、自家产品第三）[@src-30dc71eda9]；
      以及同一场会上「Q3 要扩大第三方算力作为过桥」这句话——**一家自己都要去租算力的公司，很难说它在为外售扩产。**
  
    **竞争解释 B（双轨产能规划）**——成立条件：存货增量中 TPU 占主导，且这批产能在规划阶段就分了内外两条线。
      **支持它的证据**：上面三条（先造后卖、库存成本科目、backlog 时间方向）。
  
    **能把两者分开的数据只有一个，而它没有公开：存货科目里 TPU 与消费硬件的拆分，
      或者「按外售协议排产的芯片数 / 总产量」这个比值。**在拿到之前，
      本章把「外售是产能溢出的变现」**从结论降级为两个并列假说之一**，
      TL;DR 与 §7.1 的表述已同步改。
  
      ★**注意这条反方即使成立，也不改变 Pichai 优先级排序这个事实本身**——
      它只说明「优先级排序」与「为外售预先建产」并不互斥。**推翻「溢出说」不等于证明了「双轨说」。**
  
  
  
  
    **2027-06-30 前可判**：① Alphabet 是否在 10-Q/10-K 附注里拆分存货构成（拆了就能直接裁定）；
    ② TPU 系统销售是否被单列为可辨识收入项（见 §11.2 判断 3）；
    ③ 若 2026 Q3–Q4 存货余额继续以同样斜率上升、而 TPU 收入确认仍未爬坡，则 B 的证据增强。

  八、★约束不只有芯片供应：电力进入约束集合，但没有取代芯片

  8.0 ★先把这一节的主张定死：本章不主张任何约束之间的排序

  这一节有一句可定位的官方原话作为支点，但这句话被广泛读过头了，包括本章上一版。先看原文：

  In today’s data centers, power — not just chip supply — is a binding constraint.
  
  
    Google Cloud 官方技术博客（机构表述，非个人发言）
    2026-04-22
    《Inside the eighth-generation TPU: An architecture deep dive》
    [@src-7fcb28f154]来源
  
  
  
  
  
  在今天的数据中心里，电力——**而不只是**芯片供应——是**一个**硬约束。
  
  译文译自上方英文，以英文为准
  
  
  
  
  **“not just chip supply”** 与 **“a binding constraint”**。原句说的是「**电力也是一个硬约束**」，
    **不是**「电力才是硬约束」，更**不是**「电力取代了芯片供应」。**本章上一版把小节标题写成「约束已经从芯片供应变成电力」、
    把译文写成「才是硬约束」，两处都是原句支持不了的强版本，已改。**
  
  同一家公司还有第二条口径必须一并写出：Pichai 在一次长访谈里把 **wafer starts（晶圆起片）称为 fundamental constraint**，
    并说「电力与能源**更可解**」、许可（permitting）**也可能**成为约束[@src-3c510c0260]。
    **⚠️ 这段话出自播客访谈，不是财报电话会**——本项目此前有材料把它记成财报电话会，是错的。
  
  
  
  
  本轮反方调研提出过一条更强的说法：**「Google Cloud 的芯片博客说电力是约束、Pichai 把电力排在后面，所以这是 Google 内部两个官方口径在打架，而 CEO 的排序更可信。」**
    **这条说法本章不采用，并在此明确撤回。**
  
  理由是逐字层面的：博客写的是 “power, **not just chip supply**, is **a** binding constraint”，
    它**没有**说「不是芯片供应」，也**没有**说电力排第一；Pichai 说的是晶圆是根本约束、电力**相对**更可解、许可也可能成为约束。
    **一句在讲「不止一个约束」，另一句在讲「这几个约束的可解程度不同」——两句在逻辑上完全相容，共同支持的是「多重约束并存」。**
    把它们读成互相否定，需要先把 “not just” 误读成 “not”，把 “a” 误读成 “the”。
  
  ★**这次误读值得留在原地当反面教材，因为它是一个很典型的越界：**
    发现「电力是第一约束」这个强版本证据不足，是对的；**但从「正方不够充分」跳到「所以内部有冲突、CEO 那条才是真相」，
    是把一个竞争解释直接立成了新真因。**推翻一个排序，不等于证明了另一个排序。**本章两个排序都不主张。**
  
  
  
  
  
    **反方主张：「约束已经从芯片供应变成电力」是一个尚未被证据支持的排序判断。**
      能被证据支持的只有更弱的一句：**time-to-power 在部分地区、部分时段，是并列约束之一。**
  
  
  
  
    三条真实证据：

• 官方原句自带两个限定词（“not just”、“a”）——它是并列表述，不是排序表述^[1]。

• 同一家公司的另一条口径把晶圆列为根本约束，并认为电力「更可解」^[2]。 如果电力已经是第一约束，很难解释为什么 CEO 会说它更可解。

• capex 构成不支持「电力主导」：官方口径是约 60% 服务器 / 40% 数据中心与网络^[23]—— 服务器（含芯片）仍是大头，电力相关支出被包在后 40% 里，官方从未单列过它的占比。

    反方成立的条件：只要「第一约束」这个说法需要一个**跨地区、跨时段的排序证据**，
      而公开材料只提供了单点表述与单向投资信号，反方就成立。
  
      **正方要成立，需要的是本材料没有的东西**：例如 Google 披露「因电力不足而未能上线的算力占比」，
      或「因缺芯片而延期 vs 因缺电而延期的项目数对比」。**这类数据一条都没有公开。**
  
  
  
  
    正方收窄归因之争
  
    **本节主张按弱版本重写，最终表述只有这一句（跨章统一口径，与第 11 章一致）：**
  
    **「强版『电力已取代芯片、且普遍是第一约束』无证据；弱版『time-to-power 在部分地区是并列约束之一』成立。」**
  
    据此本章保留两条判断，都可证伪：
  
      ① **电力已经进入约束集合**——证据是第八代 TPU 专门做了集成电源管理、按实时需求动态调整功耗，
      效率指标全部改用每瓦 / 每美元（perf/W 最高 **2×** 被放在性能宣传第一位）[@src-7fcb28f154]，
      以及一连串把能源与数据中心绑在一起的投资动作（PJM 区域、Intersect 收购、SMR 与聚变 offtake，见 §8.4）。
  
      ② **竞争指标因此从 FLOPs 部分转向 FLOPs/W**——这一条恰好是自研 ASIC 相对通用 GPU 最容易做出差异的地方，
      但**「能做出差异」不等于「能形成护城河」，后者另有反方，见 §8.3 末尾**。
  
      **本章不再主张任何约束之间的排序，也不再使用「电力才是硬约束」这种表述。**
  
  
  
  
    **什么证据会分出胜负**：① Alphabet 或任一超大规模厂商披露「因电力交付延迟而推迟上线的算力占比」；
    ② capex 构成里首次单列电力/并网相关支出；③ Pichai 或 CFO 在电话会上明确给出约束的排序（而不是并列列举）。
    **在这三件事发生之前，任何排序说法都是叙事，不是证据。**

  8.1 capex：2021→2026 五年约 8.1 倍，以及 2023 年那个奇怪的 2.4%

| | 年份 | 资本开支 | YoY | 备注

| | 2020 | $22.28B | −5.4% | 疫情压缩

| | 2021 | $24.64B | +10.6% | 本材料时间线起点

| | 2022 | $31.49B | +27.8% | —

| | 2023 | $32.25B | +2.4% | ChatGPT 之后的第一年，几乎没动

| | 2024 | $52.54B | +62.9% | —

| | 2025 | $91.45B | **+74.1$27.85B

| | 2026（指引） | **$195–205B** | **区间 +113中值$200B 对 2025 实际值为 +118.7% | 初始指引 + 两次上调，见下

| | 2027 | 「相对 2026 显著增加」 | — | Q1 与 Q2 2026 电话会两次重申

    表 7.7 · Alphabet 资本开支。2021–2025 实际值来自 10-K / 季报（此处经第三方数据库汇总核对[@src-a043e7e77e]，FY2025 的 $91.45B 有官方财报直接支持[@src-be8eb159b1]）；2026 为官方指引[@src-9f4a08bfb1]。**2026 那一行的 YoY 必须写成区间**：指引本身是 \$195–205B 的区间，对 2025 的 \$91.45B 分别是 +113.2% 与 +124.2%；**把它压成「约 +115%」这样一个数是伪精确**（本章早先版本如此，已改）。




2026 年的指引一共有**三档，其中两次是上调**——上调次数与档位数不是一回事，这一点值得点明：**初始指引** $175–185B（2026-02-04 Q4 电话会）[@src-be8eb159b1]；**第一次上调** 2026-04-29 Q1 电话会到 $180–190B，CFO 说明原因是 3 月完成的 Intersect 收购[@src-67ea357f9c][@src-e4652155a4]；**第二次上调** 2026-07-22 Q2 电话会到 **$195–205B**，理由是「产能交付的加速」[@src-9f4a08bfb1]。同一场会上，Alphabet 还披露了两个反差极强的事实：**一边在卖芯片**（Q2 首次向客户数据中心交付 TPU 并确认收入），**一边在租别人的算力**（「鉴于供给受限的环境，我们计划在 Q3 扩大第三方算力的使用作为过桥策略」）[@src-9f4a08bfb1]。

#### 8.1b 这笔钱从哪来：2026 年 6 月的融资，以及它最容易被读错的地方

capex 翻倍需要对应的资金来源，而 2026 上半年 Alphabet 的资本结构发生了本章时间窗内最大的一次变化。**这里有一个必须分清的三层口径，混用会把「计划」读成「已完成」：**

| | 口径 | 金额 | 它到底是什么

| | 融资方案定价口径（headline） | $84.75B** | 2026-06 由$80B 提议 upsize 后定价**的总规模。这是方案规模，不是已募得金额。

| | 其中：ATM 授权 | $40B | at-the-market 增发授权额度，截至 06-30 未动用。授权 ≠ 发行 ≠ 到账。

| | 截至 2026-06-30 的实际净到账 | $49.6B | Q2 SEC 文件口径的股票增发净收入^[24]。本章凡涉及「已到手的钱」一律用这个数。

| | 同期长期负债 | $46.5B → **$98.2B** | 2025-12-31 → 2026-06-30；2026 上半年净举债 $56.226B^[24]。

    表 7.7b · 2026-06 Alphabet 股权融资的三层口径。**「Alphabet 募得 847.5 亿美元」是错的写法**：84.75B 是含 40B 未动用 ATM 授权的定价口径，06-30 实际净到账为 49.6B[@src-a050ce2edd][@src-7775dbd964]。





  **把这三层拼起来才看得出这次融资的性质：Alphabet 没有一次性把 84.75B 拿走，而是给自己留了一个 40B 的「随时可开的水龙头」。**ATM 授权的意义正在于此——它让公司可以按市场情况分批增发，而不必在一个时点承受全部稀释。对读者的实际含义是：**84.75B 是这家公司在 2026 年愿意为算力承担的股权稀释上限，49.6B 是它已经承担的部分，两者之间那 35B 的差额本身就是一个可观察的信号**——如果 2027 年 ATM 被动用，说明 capex 的资金缺口比 Q2 时预计的更大。




  ChatGPT 是 2022 年 11 月发布的，Google 内部拉响了 code red。但 2023 年的 capex 只比 2022 年多 **2.4%**。这不是决策迟缓，而是**基础设施的相位差**：数据中心从选址到通电要 2–4 年，芯片从流片到量产要 1.5–2 年。2022 年底做的决定，最早在 2024 年的财报上才看得见——而 2024 年 capex 就跳了 62.9%。

  **这条 2.4% → 62.9% → 74.1% → 2026 指引区间 +113%…+124% 的曲线，是「AI 需求冲击」经过基础设施传递函数之后的输出。**它同时暗示了一件更麻烦的事：**如果需求在 2027 年掉头，capex 也要 2–3 年才刹得住**，那时账上会留下巨额折旧。Alphabet 自己在每次电话会上都重复同一句警告：技术基础设施投资的大幅增加将继续以更高折旧费用和数据中心运营成本（如能源）的形式给损益表带来压力[@src-67ea357f9c]。



### 8.2 交互：capex 与 token 量的剪刀差



    capex 与月度 token 处理量的剪刀差（2021–2026）
    对数 Y 轴 · 点击图例可切换系列 · 悬停看每个数据点





    **两条曲线的单位不同，共用一条对数轴只为看斜率，不可比较绝对高度。**capex 单位为十亿美元（2021–2025 为实际值[@src-a043e7e77e][@src-be8eb159b1]，2026 取指引区间中值 $200B[@src-9f4a08bfb1]）；token 单位为万亿 token/月，取 Pichai 在 I/O 与财报上披露的官方值[@src-f3054c38c0]（9.7 T @2024-05、480 T @2025-05、3,200 T @2026-05），中间点 980 T @2025-06 来自 Logan Kilpatrick 与 Demis Hassabis 的公开表述、经媒体转述转述[@src-9a08270b59]。





  展开：图中每个数据点的数值（文字替代）

| | 时间 | Alphabet capex（十亿美元/年） | 月度 token 处理量（万亿）

| | 2021 | 24.64 | —

| | 2022 | 31.49 | —

| | 2023 | 32.25 | —

| | 2024 | 52.54 | 9.7（2024-05）

| | 2025 | 91.45 | 480（2025-05）· 980（2025-06）

| | 2026 | 195–205（指引，图取 200） | >3,200（2026-05）

      表 7.8 · 剪刀差图的原始数据。**同一时间窗（2024 → 2026）内：月度 token 量 9.7 T → 3,200 T，涨 **329.9 倍**；capex \$52.54B → 指引中值 \$200B，涨 **3.81 倍**。**另一个常被混用的口径是「以 2021（\$24.64B）为基准 capex 涨约 8.1 倍」——那是**五年**的数，**不可与两年的 token 增幅相除**，理由见下。







  本章早先版本在这里写过一个「效率指数 \(330/8\approx 41\)」。**这个数是错的，而且错得很典型，值得当作反面教材留在原地。**

  错因是**分子分母的时间窗不一致**：330 倍是 **2024-05 → 2026-05 两年**的 token 增幅，8 倍却是 **2021 → 2026 五年**的 capex 增幅。用两年的分子去除五年的分母，等于人为把分母放大了两倍多，结果把这个比值压低了一半以上。**任何形如「A 涨了 X 倍、B 只涨了 Y 倍」的对比，第一件要核的事永远是 X 和 Y 是不是同一段时间的。**

  按同一时间窗（2024 → 2026）重算：

  \[ \frac{3{,}200/9.7}{200/52.54} \;=\; \frac{329.9}{3.81} \;\approx\; \mathbf{87} \]
  即 **≈87，不是 41**。这个数比原来大一倍多，**但它并不因此更「有力」**——它的口径问题比它的数值问题严重得多，见下。




  先给它一个诚实的名字：**吞吐 / capex 描述性指数**。它**只是两个异质端点的比值**，不是效率的度量，更不是生产函数。

  **分子分母的口径根本不同，这一点必须写在最前面：**

• **分子（token）**覆盖 Google 多个 surface 的合计处理量——Search AI Overviews、AI Mode、Gemini App、Workspace 等等（见 §10.5 度量 A）。它既不是收入，也不是同一种 token：一个 thinking token 与一个 AI Overviews 摘要 token 在成本上差着量级。

• **分母（capex）**覆盖 Alphabet 全部技术基础设施，官方口径约 60% 服务器 / 40% 数据中心与网络^[23]，并非全部用于 AI——Search、YouTube、Workspace 的常规基础设施都在里面。

• 时间性质也不同：token 是某个月的流量快照，capex 是全年的支出；用当年 capex 去配当年 5 月的月度 token，本身就是一次近似。

  **因此本章不对它做因果分解。**以下四个因素都会把这个比值推高——(a) TPU 代际 perf/W 的复利（官方每代约 1.67–2×）；(b) 精度下降（BF16 → FP8 → FP4）；(c) MoE 稀疏化；(d) 服务栈优化（连续批处理、分离式 prefill/decode、KV cache 复用）——但**这个指数无法给它们分配任何权重**，甚至无法把「效率提升」与「产品结构变化」（例如 AI Overviews 这类短输出 surface 占比上升）分开。**早先版本在这里做过一次四路因果分解，那是把一个描述性比值当成了可分解的模型，已删除。**
  
  它**还能**说的只有一句，而且是弱陈述：**在这两年里，token 处理量的增速（约 330×）远快于技术基础设施支出的增速（约 3.8×）。**这与「2024–2026 的 capex 暴涨主要由需求拉动、而非效率停滞」这一解释**相容**，但不构成对它的证明——同样相容的解释还包括产品结构向低成本 surface 倾斜、以及 capex 存在 2–3 年的交付滞后（见上一段的相位差讨论）。Pichai 连续多季说 “supply constrained”，是这条解释链上更直接的一个佐证[@src-9f4a08bfb1]。

  8.3 用电、PUE、水，以及一个「与 Jevons 相容、但没被证成 Jevons」的观察

| | 指标 | 2025 值 | 变化

| | 全球用电量 | 43.6 TWh | +37% YoY，公司史上最大单年增幅；相对 2019 涨 >250%

| | 机队平均 PUE | 1.09（TTM），季度值 1.08 | 开销能耗比行业均值低约 83%

| | 每单位电力的算力 | 5 年提升 >3 倍 | 官方归因「主要来自 TPU 能效改进及其在 AI 上的部署」

| | 运营排放（Scope 1+2 市场法） | −2% YoY | 连续第 9 年 100% 匹配可再生电力采购

| | 总排放（含 Scope 3） | +18% YoY | 相对 2019 基准 +81%；供应链排放 +25%

| | 用水 | 10.9 十亿加仑 | +34%；补给 7.7 十亿加仑（78%）

| | 新签清洁能源 | >12 GW | 史上最多；2010–2025 累计 240+ 份协议 / 近 35 GW

    表 7.9 · Google 2026 环境报告（覆盖 2025 财年）关键指标。官方摘要见 Google Blog[@src-1a1c10467a]，PUE 逐园区明细见官方数据页[@src-0be70a8386]；43.6 TWh、用水 +34%、总排放 +18% 等具体数字经权威媒体转述报告全文[@src-2ce245ce19][@src-1a9e08ffcb]。




Google 自己的坦白很直接：**「我们的 AI 基础设施建设速度，目前快于电网脱碳的速度。」**译文，转述自报告[@src-2ce245ce19] 供应链排放上升被归因于台湾、日本、越南、印度的半导体供应商所在电网清洁能源可及性有限。

**单次推理的能耗。**2025 年 8 月 Google 发了一篇方法学论文，给出：Gemini 应用中位文本 prompt 消耗 **0.24 Wh 能量、0.03 g CO2e、0.26 mL 水**[@src-9661fc2a4a]。这个口径的严谨性值得称道——它不只算加速器功耗，还包含 host CPU、DRAM、为可靠性预留的**空闲冗余系统**，以及机队平均 PUE 1.09 的全部数据中心开销。2026 年环境报告进一步披露：**中位 Gemini 文本 prompt 的能耗在 12 个月里下降了 33 倍**[@src-1a1c10467a]。


  本章上一版在这里做过一次除法。设总能耗 \(E = q\cdot e\)（\(q\) 是 prompt 数量、\(e\) 是单 prompt 能耗），
    把「\(e\) 降 33 倍」与「\(E\) 涨 37%」代进去：

  \[ \frac{q_{\text{new}}}{q_{\text{old}}} \;=\; \frac{E_{\text{new}}/E_{\text{old}}}{e_{\text{new}}/e_{\text{old}}} \;=\; \frac{1.37}{1/33} \;\approx\; 45 \]
  然后写成「**需求量涨了约 45 倍**」。**这个推论已撤回。**错因不是算术，算术是对的（\(1.37\times 33 = 45.21\)），
    错在**分子分母根本不是同一个边界**：

• (E)（+37%）是 Alphabet 全公司用电——Search、YouTube、Workspace、广告系统、办公与全部训练负载都在里面，AI 推理只是其中一块，官方从未披露它占几成^[25]。

• (e)（÷33）只覆盖「Gemini 应用的中位文本 prompt」——不含图像、视频、音频、长上下文、agent 多轮，也不含任何训练^[25][26]。

• 连「中位」这个统计量本身也不可乘：中位 prompt 的能耗下降 33 倍，不蕴含总推理能耗下降 33 倍——如果同期请求结构向长上下文与多模态倾斜，均值和中位会朝不同方向走。

  所以 \(E=q\cdot e\) 这个恒等式在这里**不闭合**：等号左边的 \(E\) 装的东西比右边 \(q\cdot e\) 多得多。
    **硬口径：45（或 45×）在本章只作为「两个不同边界的数字相除会得到什么量级」的演示，不得当作需求量的推断，也不得被引用为 Gemini 请求量的增长率。**
  
  ★**这次错误的形状值得记住：它不是算错，是把两个口径不同的真数字放进了同一个公式。**
    本章 §8.2 那个「≈87」的吞吐/capex 指数踩的是同一个坑的另一半（时间窗不一致），
    两处放在一起，构成本章最实用的一条方法论提醒：**做除法之前，先把分子分母的边界写在纸上。**
  
  
  
  
  剩下的是**一条弱得多、但完全站得住的陈述**：**在 2025 这一年里，单位能效的改进没有让 Google 的总用电下降。**
    这句话只用到两个官方数字各自的原始口径，不需要把它们相除。
  
  它**与** Jevons 悖论**相容**——效率提升伴随总量上升，确实是 Jevons 的表面特征。
    **但相容不是证明。**要真正判定这是 Jevons（即：效率提升本身**导致**了需求扩张），至少需要三样本章没有的东西：
    ① AI 推理能耗从总用电里单列出来；② 需求扩张中「因为变便宜了所以多用」与「因为多了新产品入口所以多用」的分解；
    ③ 一个反事实——如果效率没提升，需求会是多少。**Google 在同期还上线了 AI Overviews、AI Mode、Gemini App 的多个默认入口，
    这些是分发动作，不是价格弹性。**
  
  **因此本章的写法是：把它称为「一个与 Jevons 相容的观察」，不称为「Jevons 悖论的教科书样本」。**
    本章上一版用了后者，那是把一个未做识别的因果机制当成了已证事实。
  
  
  
  
  
    **反方主张：本章第八节自己拆了自己的台。**如果效率提升总是被需求增长吃掉，
      那么 perf/W 的改进最终转化为**更多的 token、更低的单价**，
      受益者是使用方与整个市场，**而不是把效率做出来的那家公司**。
      在这个意义上，「perf/W 是护城河」这个推论不成立。
  
  
  
  
    两条：

• **行业已经换了度量衡，而且是所有人都换了。**Nvidia 在 A5X / Vera Rubin 的官方口径里， 把「每兆瓦 token 吞吐提升最高 10×」与「每 token 成本降低最高 10×」并列放在最前面^[27]—— 这是 Nvidia 自己也在用每兆瓦口径打广告。一个所有竞争者都在优化、并且都能拿到进步的指标，很难同时是某一家的护城河。

• 一个自证的位置：同一批 GPU 云既在强调每兆瓦效率的重要性，又公开表示短期不部署 TPU^[28]。 「perf/W 是第一指标」和「TPU 因此有护城河」被同一批人分别接受与拒绝——这说明这两件事之间没有必然联系。

    **⚠️ 关键口径警告，两个 10× 与 2× 不可对比**：Google 的 perf/W **2×** 是**芯片级**指标（同精度、同口径的硬件比值）[@src-7fcb28f154]；
      Nvidia 的 **10×** 是**系统级** tokens/MW，含精度下降、专家并行、prefill/decode 分离与整套推理软件栈，
      且是在匹配交互性目标的条件下测的[@src-5a37387ce0]。**把 2× 与 10× 直接相比是错的，本章不做这个对比。**
  
  
  
  
    反方成立的条件：perf/W 的改进能被竞争对手在**可比时间尺度**内跟上，
      且改进带来的收益通过降价**完全**传导给需求方。
  
      **反方不成立的条件**：如果 perf/W 的代际改进存在持续的领先窗口，
      那么在窗口期内，同样一兆瓦上跑出更多 token 的一方就有真实的成本优势——
      **而这正是本章 §9.2 的第三方 TCO 估算在量化的东西，只不过那些估算本身有很强的限定（见 §9.2、§9.3）。**
  
  
  
  
    正方收窄归因之争
  
    **正方需要收窄成两句，不能合并：**
  
      ① **perf/W 被抬到第一位**——成立，三方口径同向（Google 官方原句、Nvidia 的每兆瓦 token 营销、GPU 云的表述）。
  
      ② **perf/W 因此是 Google 的护城河**——**未证明**：它要求「Google 的 perf/W 领先幅度 > 竞争者的追赶速度」，
      **而本章根本找不到能横比的口径**（上面那条 2× vs 10× 的警告说的就是这件事）。**缺口径，就不存在「谁领先多少」这个可回答的问题。**
  
    ★**但反方也不能反向立成新真因**：「Jevons 成立 ⟹ 效率不产生竞争优势」这一步同样缺一环——
      它默认了收益**完全**传导。**在供给受限的市场里，效率优势可以先转化为「同样电力下多服务多少客户」，
      而不是先转化为降价。**Q2 2026 Google 一边卖芯片一边租第三方算力，正是供给受限的直接证据[@src-9f4a08bfb1]。
      **因此这里的正确结论是「①成立、②未证明」，不是「perf/W 没有价值」。**
  
  
  
  
  
  
  
  
    **图 7.30** AI 数据中心功耗的行业趋势（第三方估算，**堆叠面积图**）。原图注完全没提、而恰恰是本图信息量最大的三件事：（1）**面积分两层**——深青色是 **AI 芯片本身的功耗（TDP）**，浅色是**冷却、网络等其余数据中心功耗**，后者始终是大头；（2）**右端的斜纹区是「基于不完整数据的外推」**，不是实测；（3）图上以三条虚线给出量级参照——**纽约州峰值用电 ≈ 31 GW、荷兰 ≈ 19 GW、新西兰 ≈ 7 GW**，曲线右端已逼近纽约州量级。**⚠️ 两条重要限制：本地图片的横轴刻度与标题被整个裁掉，图上没有任何时间刻度，因此「趋势」覆盖的年份区间无法从本图判读**；另外纵轴量纲是 **GW**，而 Ironwood 单 pod 的近 10 MW = **0.01 GW**，在 5–35 GW 的纵轴上根本不可见——**说它是「这条曲线上的一个点」只是修辞，本图只用于交代整体量级背景**。本图为第三方数据机构的估算与汇总，不是官方数字。
    [@src-0afd26430c]出处：Epoch AI — Data Insights: AI datacenter power, 2026（第三方，可信度 C）

  8.4 从买电到造电：Fervo / Kairos / CFS / Suncatcher

  Google 的能源策略在 2021–2026 之间发生了一次性质变化：从「买绿电证书匹配用电量」变成**「为尚不存在的技术付首付」**。

•   2021
    Fervo Energy 增强型地热 + 对 Commonwealth Fusion 的首笔 R&D 投资
  
    完成世界首个企业级增强型地热（EGS）项目（Nevada），后与多家公用事业合作推出「清洁转型电价」，把该商业试点扩大到 **25 倍**[@src-8fc6794fd0]。

•   2024-10-14
    Kairos Power：全球首份企业采购多座 SMR 的协议
  
    总计 **500 MW**，首堆 **2030** 年上线，2035 年前完成部署（约 7 座反应堆）。技术路线：氟化盐冷却 + 陶瓷卵石燃料，低压运行[@src-8fc6794fd0]。

•   2025-06-30
    Commonwealth Fusion Systems：迄今最大的企业直接聚变能采购
  
    从 CFS 位于 Virginia 州 Chesterfield 的首座商业电站 ARC 采购 **200 MW**（ARC 规划容量 400 MW，2030 年代初供电）。同时进行第二笔股权投资并获得未来电站采购选择权[@src-038ad7c8c3]。

•   2025-07-15
    PJM 区域：未来两年超 $25B 数据中心/AI 基建 + $3B 二十年水电现代化协议
  
    Ruth Porat 在宾州能源创新峰会上宣布[@src-d923516451]。

•   2025-11
    Project Suncatcher：把 TPU 送上太阳同步轨道
  
  
      合适轨道上太阳能板的产能可达地面的 **8 倍**且近乎连续；**Trillium (v6e) 通过了 67 MeV 质子束辐照测试**——HBM 子系统最敏感，在累积剂量 **2 krad(Si)** 后开始出现异常（已是 5 年任务预期屏蔽剂量 750 rad(Si) 的近 3 倍），单芯片测到最高 **15 krad(Si)** 未出现 TID 硬故障，这是**首个公开的高性能 ML 加速器辐照测试结果**；星座设计为 81 颗卫星、1 km 半径平面编队、650 km 晨昏太阳同步轨道；星间链路台架演示 **1.6 Tbps 双向**；经济性拐点估算在发射成本降至约 **$200/kg** 时；与 Planet Labs 合作，**2027 年初**发射两颗原型星[@src-0a20cf0a3d][@src-7a6cee9db6][@src-dd49ee9349]。

•   2025-12-22 → 2026-03
    Intersect 收购：$4.75B 现金加承担债务，2026 年 3 月完成
  
    强化能源与数据中心共址；这笔收购正是 2026-04-29 capex 指引上调到 $180–190B 的直接原因[@src-e4652155a4][@src-67ea357f9c]。

  这里有一个容易被混淆、但决定了上述全部投资逻辑的概念差别：

    **「100% 匹配可再生电力」**（Google 已连续 9 年做到）是**年度能量匹配**——一年买的绿电总量等于一年的用电总量，但夜里用的可能仍是煤电。
  
  
  
    **「24/7 无碳能源（CFE）」**（Google 的真正目标，**未达成**）是**逐小时匹配**——每一小时的用电都由同一电网区域的无碳电源供应。

  **这个差别正是 Google 押注 SMR、地热、聚变的全部理由：风光是「能量」，核裂变 / 聚变 / 地热是「可调度的容量」。**年度匹配靠买风光证书就能做到；逐小时匹配必须有 firm capacity。Google 自己的表述是「支持那些有路径在未来十年内提供清洁 firm 容量的技术」^[29]。三个具体瓶颈也写在环境报告里：电网接入项目的长期排队延迟、割裂的电网、缺乏可靠的 24/7 清洁电力。

  **两者都是，而且这不矛盾。**技术上它有真东西：Trillium 的辐照测试是首个公开的高性能 ML 加速器抗辐射数据，81 星编队的动力学、1.6 Tbps 星间光链路台架演示、$200/kg 的经济性拐点分析，都是可复核的工程内容[@src-7a6cee9db6][@src-dd49ee9349]。
  
  但它同时是一份**面向电网监管者与地方社区的政治声明**：当你在 20 个地方申请 GW 级并网、被质疑抢占居民用电时，说「我们正在研究把算力搬到太空」的效果，远好于说「我们会付更多钱买电」。
  
  更值得注意的是它揭示的**成本结构判断**：Google 认为在某个时间点上，「把 TPU 送上天 + 承受辐射与散热的全部代价」会比「在地球上再申请一个 GW」更便宜。**这句话本身就是对地面电力稀缺程度最强的一个背书。**至于 2027 年那两颗原型星，我的判断是它的主要产出不会是算力，而是**数据**——真实轨道上 HBM 的软错误率、光链路的对准稳定性、被动散热的极限。这些数据决定的是 2030 年代的决策，不是现在的。
  
  
  
  
  因为**电力和厂房的交付周期比芯片长**。芯片可以催代工厂加单，数据中心的变电站、输电线路、并网许可催不动。2025 年 Fluidstack 在 TeraWulf 的 Lake Mariner 园区（前燃煤电厂改造）租赁产能部署 **Google TPU**，服务对象是 Anthropic；Google 为这笔 10 年租约提供 **$32 亿的兜底担保**，并把在 TeraWulf 的股权提高到约 **14%**；合同 IT 负载合计 360 MW[@src-ea68365713][57b]。
  
  这类前加密矿场的价值不在于机房本身，而在于**它们已经拿到了并网容量**。所以这笔交易的本质不是租算力，是**租并网许可**。这也解释了为什么 Google 愿意用「兜底 + 股权」这种非常规结构：它不是在买服务，是在**为一个电力资产的产权做安排**。Q2 2026 电话会上「扩大第三方算力使用作为过桥策略」这句话，也应该在同一个框架下读——**过的不是算力的桥，是电力交付时间的桥。**

  8.5 perf/W 为什么被抬到了 perf/$ 前面——以及这个判断的适用范围

  过去 15 年，算力扩张先后被算法、数据、芯片供应与电力交付所约束（**这是作者对公开事实的归纳，不是被独立验证的分期，也不主张后一项「取代」了前一项——按 §8.0，本章不做约束排序**）。当电力进入约束集合时，有三件事被推着发生：
  
  **(a) perf/W 被抬到 perf/$ 前面。**第八代 TPU 的宣传语已经这样排序了：两颗芯片的共同卖点是 perf/W 2×，各自的差异化卖点（训练性价比 2.7×、推理性价比 +80%）排在后面[@src-7fcb28f154]。**注意这是厂商的表述顺序，不等于成本结构的排序**——它是一个可观察的信号，不是一个被披露的账。
  
  **(b) 通用性的代价被放大。**如果每一瓦都要抢，那么一颗为「训练和推理都还行」而设计的芯片，在两种负载上都要付出折中的代价。专用化（训练/推理分芯、FP4、CAE）是应对这一压力的**一条路径**——但不是唯一一条：把同一颗硅配上不同的 pod 拓扑与服务栈，同样能吃掉一部分折中损失。**Google 选了分芯，这是一个可观察的选择，不是被物理定律逼出来的唯一解。**
  
  **(c) 能源采购成为 AI 公司的核心能力之一。**一家搜索公司先变成能源公司的客户，再变成能源项目的投资人，最后开始研究把机房送上轨道。这条轨迹本身就是 perf/W 被抬到前面的最好注脚。
  
  
  
  
  
    **反方主张：上面 (a)(b)(c) 三条被写成了普遍规律，但它们的成立高度依赖「在哪张电网上建」。**
      同一个物理量在不同电网里是完全不同性质的问题——几十 GW 的新增连续负载，
      相对某些国家的总发电功率是个位数百分比，相对另一些国家则是数量级不同的比例。
      **如果约束的种类因地域而异，那么「perf/W 被抬到第一」就不完全是技术判断，
      里面掺着一个关于美国电网接入与许可流程的判断——而 Pichai 自己就把许可列成了可能的约束之一[@src-3c510c0260]。**
  
  
  
  
    证据在 Google 自己的环境报告里：它自陈的三个瓶颈是**「电网接入项目的长期排队延迟、割裂的电网、缺乏可靠的 24/7 清洁电力」**[@src-1a1c10467a]。
      **这三条全部是许可、排队与交付节奏问题，不是「发电量不够」**；而排队与许可制度是逐个司法辖区不同的。
      §8.4 里那笔 TeraWulf 交易也指向同一处：值钱的不是机房，是**已经拿到的并网容量**[@src-ea68365713]。
  
  
  
  
    ★**反方成立的边界必须写清楚，否则它自己就会越界。**
      「把新增 AI 负载的功率除以某国的平均发电功率」这类算式，**只能用来演示分母有多大，不能用来下国别结论**：
      它默认了负载可以任意选址、电网内部无阻塞、且全部发电容量都可被数据中心使用——三条都不成立。
      **更不能把连续负载与「风光名义装机」相除**，因为名义装机不是可调度容量（这正是 §8.4 那条「能量 vs 容量」区分的意思）。
  
      **因此本章不写「某国不可能、某国轻松」这类结论。**本项目此前的反方材料写过这类国别判断，**本章不采用。**
  
  
  
  
    正方收窄归因之争
  
    **收窄后的表述：约束的存在是普遍的，约束的种类与紧度是地域性的。**
      (a)(b)(c) 三条在「电网接入排队长、许可周期长」的辖区里成立得最强，
      在并网容量宽裕的辖区里，perf/$ 完全可能仍是第一位。
  
      ★**但反方也不能推到「所以 perf/W 只是监管的影子、不可能是护城河」**——
      这一步同样缺识别：**即使约束的来源是监管，「同样一兆瓦跑出多少 token」仍然是一个真实的工程量**，
      它由芯片、拓扑与软件栈共同决定，不由许可流程决定。**约束的来源与能力的归属是两个问题。**

  九、与 Nvidia 生态的对照，以及必要的祛魅

  9.1 75% 毛利率意味着什么

| | 指标 | Q4 FY2026 | FY2026 全年

| | 营收 | $68.13B |$215.9B（+65%）

| | 数据中心营收 | $62.3B（+75$193.7B（+68%）

| | GAAP 毛利率 | 75.0% | 71.1%

| | 非 GAAP 毛利率 | 75.2% | 71.3%

    表 7.10 · NVIDIA FY2026 财务数据（财年截至 2026-01-25）[@src-300b1f6d8d]。




75% 毛利率意味着**售价约为成本的 4 倍**。翻译成买家视角的一个恒等式：**一个自研 ASIC 的买家，只要自己「设计 + 流片 + 系统集成 + 组织」的总加价低于 4×，在同等性能下就赢。**Google 的实际情况是它通过 Broadcom 采购 TPU，要付给 Broadcom 一笔不低的毛利；第三方判断是这笔加价「远低于 Nvidia 在 GPU 及整套系统（CPU、交换机、网卡、系统内存、线缆连接器）上赚的加价」[@src-0923568307]。

### 9.2 第三方 TCO 估算：全部为建模估算，非官方


  **本小节的每一个数字都是第三方建模估算，Google 与 Nvidia 均未披露任何一项。**它们的价值在于给出量级和方法，不在于精确。任何把它们当作事实引用的做法都是错误的。

| | 对照 | 第三方估算值 | 性质

| | Google 内部：Ironwood 单芯片全成本 TCO vs GB200 服务器 代际限定：Ironwood(v7) vs GB200 那一代；时间限定：2025-11 那份建模 | 低约 44% 第三方情景估算，非实测 | SemiAnalysis 情景建模^[30]；Google 与 Nvidia 均未披露任何一项输入，也从未确认这个结果

| | 外部客户（Google 加毛利后）：TPU v7 每小时 TCO vs GB200 / GB300 | 低约 30% / 41% | 同上

| | Anthropic 通过 GCP 的 TPU 价格 | 约 $1.60 / TPU-hour | 同上

| | 建模假设的 MFU | TPU 40% vs GPU 30% | 同上（此假设有争议，见 §9.3）

| | 盈亏平衡点 | Anthropic MFU ≥ 19% 即与 GB300 打平；Google 自用 MFU ≥ 约 15% 即与 30% MFU 的 GB300 打平 | 同上

| | TPU v6e (Trillium) 公共标价（美国区，chip-hour） | on-demand $2.70** 1 年承诺 **$1.89 3 年承诺 $1.22 | 官方定价页，非估算^[31]（但见下方关于标价有效性的警告）

    表 7.11 · 第三方 TCO 估算汇总。**除最后一行的公共标价外，全部为建模估算，非官方披露。**
      **★引用本表任何一行时必须带三个限定：(1) 它是第三方情景估算，不是实测，也不是任何一方披露的成本；
      (2) 代际限定——对照的是 Ironwood / v7 与 GB200 / GB300 那一代，
      同一份来源自己就说下一代（VR200 vs 8）的训练 TCO 优势会从 1.52× 收窄到 1.23×（见 §9.3），**所以这些数字有明确的保质期**；
      (3) 时间限定——建模发表于 **2025-11**，冻结日至今没有更新版本。**
      **三者缺一，这些数字就会被当成「Google 的成本比 Nvidia 低 44%」这种事实陈述来传播——而它不是。**





  **关于标价的重要警告（值得完整引用）：**「没有任何主要 TPU 客户付得起接近 $2.7/hr/chip 的价钱，因为 TPU v6e 的 BOM 只是 H100 的一小部分。众所周知，大多数云都会把标价定得很高，好让销售代表用『二手车推销员』的手法给出巨额折扣，让客户觉得占了便宜。」译文[@src-0923568307]

  **因此任何用标价做的 TPU vs GPU 成本对比都是无效的**，包括那篇广为流传的「TPU v6e 每美元性能差 5 倍」的基准[@src-2e3411deed]。



  本章早先版本在这张表里写过「TPU v6e 三年承诺用量折后低至约 **\$0.39 / chip-hour**」，来源是一家第三方博客[@src-8a2d1c0159]。**这个数已删除。**理由是它**与冻结日的官方定价页对不上**：官方公开的三年承诺价是 **\$1.22**，不是 \$0.39——差 3.1 倍[@src-2115b68903]。

  \$0.39 **不是不可能**：大客户的合同价确实可能远低于公共承诺价（上面那段引语说的正是这件事）。但**它不是「官方三年承诺价」，而是一个来源不明的合同级传闻**。本章的处理原则是：**公共价按官方定价页写，合同价只在拿到合同级一手证据时才写**；两者不能混在一张表里，否则读者会把传闻当牌价。






    **图 7.31** **MLPerf Training v2.0（2022-06 提交轮次）**的跨平台对照。**完整设置必须一并读**：benchmark 版本 **v2.0**；提交方为各厂商自己（**vendor-run**，含 Google 自提交的 TPU v4 成绩）；对比的是**各自最快提交**而非同芯片数——**图上每根柱内都标了芯片数，逐组并不相等**（如 A100 1,280 对 TPUv4 2,048、A100 112 对 TPUv4 128）；逐条任务的 batch、精度与目标 quality threshold 由 MLPerf 规则固定、论文未逐条复述。**结果（按图上标注值逐条读出）：五组中 TPU v4 相对 A100 分别为 1.05 / 1.15 / 1.37 / 1.67 / 1.87×，即区间是 1.05–1.87×**——**⚠️ 本章上一版写的「1.2–1.7×」两端都收窄了，已按图更正**；功耗一侧则与图顶残留的原文一致：*A100s use on average 1.3x–1.9x more power*。同组里还有 Graphcore IPU BOW 的两个点（0.06 与 0.12，均为 256 芯片）。论文自己承认 A100 与 Graphcore Bow 都是 full-reticle die（826 / 832 mm²），比 v4 的 200k 上下文要加价一倍**（3.1 Pro：2.00 → 4.00）——长上下文的 attention 项随 \(L\) 线性增长，而 KV cache 的 HBM 占用也随 \(L\) 线性增长、挤压并发数 \(B\)，**分母变小、分子变大，两头夹击。这是一个真实的成本台阶，不是价格歧视。**






### 10.3 交互：推理成本计算器



    推理成本计算器（Ironwood 规格 · 全部为估算）
    调激活参数量、并发、带宽利用率、芯片小时成本，看 $/M token 曲线与 Gemini 标价的距离





    **⚠️ 全部为估算，非官方。**芯片规格取 Ironwood 官方值（FP8 峰值 4,614 TFLOPS、HBM 7,370 GB/s）[@src-b3d2608b0d]；\(b=1\)（FP8）、\(\rho_{\text{kv}}=0.3\)、prefill/大 batch 区的 MFU 取 0.45，均为本文假设。芯片小时成本的默认值 $1.60 是**第三方建模估算**[@src-0923568307]，不是 Google 公布的价格。横轴超过临界 batch 之后曲线走平，是因为负载从带宽受限切换成算力受限——这正是 F7-1 的 roofline 在成本维度上的投影。**Gemini 的激活参数量官方从未披露，滑杆上的数值只是量级示例，不代表任何真实模型。**




### 10.4 价格曲线悖论：同名单价在涨，同档单价在跌



    「Flash」这块牌子的名义标价（2024-05 → 2026-07）
    对数 Y 轴 · 全部为官方标价





    数据全部来自 Gemini Developer API 官方定价页与官方降价公告[@src-f290f3149a][@src-aee6d5fc4c]，单位为美元 / 每百万 token，时间取各型号的发布或价格生效日。文字替代见下方段落中的逐点列举。




把这条曲线读出来：2024-05 的 1.5 Flash（≤128K 档）是 0.35 / 0.53；**2024-08-12 生效的降价把它压到 0.075 / 0.30，这是名义单价的历史最低点**；此后 2.0 Flash 0.10 / 0.40、2.5 Flash 0.30 / 2.50、3 Flash 0.50 / 3.00、3.5 Flash 1.50 / 9.00、3.6 Flash 1.50 / 7.50。**从 2024-08 的低点到 2026-07，「Flash」的 output 标价涨了 25 倍，input 涨了 20 倍。**年化：


  本章早先版本把这次降价写成「**−78% / −71%**」，直接抄了官方公告的两个百分比。**其中 output 那个数与本章表 7.13 自己列的价格算不出来。**逐项复算：

• Input（≤128K，standard）：(0.075/0.35 - 1 = -78.6%)。与官方公告的「−78%」一致，无冲突。

• Output（≤128K，standard）：(0.30/0.53 - 1 = -43.4%)。官方公告写的是「−71%」，两者差 27.6 个百分点，不是舍入误差。

  **冲突不做拼接，只做登记。**要让 −71% 成立，降价前的 output 价必须约为 **\$1.03**（\(0.30/(1-0.71)\)）——而本项目技术档案里归档的 2024-05 数字是 **\$0.53**，且档案自己就给它标了 待核。两个可能的解释都无法在冻结日证实：**(a)** \$0.53 抄错或抄自某个非 standard 层级；**(b)** 官方的 −71% 对应的是 **>128K 档**或另一个快照日的价格，而不是 ≤128K standard 档。
  
  **因此本章的写法是：input 写 −78.6%（两方一致）；output 只写两个价格与各自日期、层级，并把 −43.4%（按归档价算）与 −71%（官方公告）并列，不合成任何单一百分比。**需要注意的口径维度有四个，缺一个就不可比：**≤128K / >128K**、**standard / batch**（1.5 时代尚无 Batch 层级）、**生效日期**（公告 2024-08-08、生效 2024-08-12）、以及**是否含 thinking token**（1.5 代没有 thinking，2.5 代之后才有，这使得跨代的 output 单价本身就不同质）。
  
  
  
  
  \[ \left(\frac{7.50}{0.30}\right)^{1/1.94} \;=\; 25^{0.515} \;\approx\; 5.2 \]
  (7.2)
  名义单价年均上涨约 5.2 倍。连最便宜的档位也在涨：2.0 Flash-Lite（0.075 / 0.30）到 3.5 Flash-Lite（0.30 / 2.50），input 涨 4 倍、output 涨 8.3 倍。

  **那什么在降？把「同一档能力」的标价放在一起看，它在降。**但这句话要说得可核验，就必须把「同一档能力」这五个字拆开——下面先给能核的部分，再给不能核的部分。

| | 项 | Gemini 2.5 Pro | Gemini 3 Flash | 可核程度

| | 标价（$/M token，≤200K，standard） | 1.25 / 10.00 | 0.50 / 3.00 | A · 官方定价页^[32]。input −60.0%、output −70.0%，这两个百分比是纯算术，无争议。

| | 日期 | 2025-06-17 GA | 2025-12-17 preview | A · 相隔 183 天

| | 能力对比的原文 | 「Gemini 3 Flash 在多项基准上超过 2.5 Pro，同时快 3 倍，成本只是一小部分」译文 | B · 厂商自述^[33]。没有点名是哪些 benchmark、哪个 harness、是否开 thinking、pass@1 还是 maj@k。

| | 「快 3 倍」的口径 | 官方未给出测速方法、输入/输出长度、并发或服务层级 | C · 无独立测速来源。本章没有找到可引用的第三方 tok/s 对照，因此这一项不进入任何计算。

    表 7.13b · 「2.5 Pro 级能力」这个说法能核到什么程度。**只有第一行进入本章的结论。**





  早先版本从上表第一行出发，做了两步外推，**两步都不成立**：

  **第一步：把厂商的一句 benchmark 表述当成「能力等价」。**「在多项基准上超过 2.5 Pro」不等于「等于 2.5 Pro 的能力」——它既没说是哪些基准（未超过的那些呢？），也没给 harness / thinking / 采样口径。**SPEC §0.2 第 5 条明确要求 benchmark 必须标注版本号、日期、harness、是否 thinking、pass@1 还是 maj@k；这里一项都没有，因此它不足以定义一个「能力档位」。**

  **第二步：把一次价格对比 annualize。**早先版本写 \((0.30)^{2}=0.09\)，即「等能力 $/token 年降约 91%」。**这是把两个时点的一次比较当成了一条指数曲线上的两个采样点。**要让年化成立，至少需要：同一能力定义下的**多个**时点、每个时点的口径一致、且有理由相信这个过程是指数的。这里只有**一对**模型、**一个**价格比、**一句**厂商表述。**用 n=1 的观测去拟合年复合率，得到的数字看起来很精确，但它的置信区间是整个实数轴。**

  **因此本章只报观察到的标价降幅，不给年化：在 2025-06-17 → 2025-12-17 这 183 天里，Google 主力档位的标价从 1.25 / 10.00 变成 0.50 / 3.00，即 input −60%、output −70%；同期厂商声称后者在若干未点名的基准上表现更好。**这句话每一个成分都能回到一手来源，而「等能力 $/token 年降 91%」不能。




  因为**「一个 token」在 2024 年和 2026 年不是同一个东西**。三重变化叠加：

  **1 · token 的信息密度可能上升。**厂商定价对齐的是它自己声明的「能力档位」，不是「字符」。**但这一条是解释，不是被测量的事实**——公开材料里没有「每 token 信息密度」的可比度量。

  **2 · thinking token 被计入 output。**官方定价页每一行都写着 “Output price (including thinking tokens)”[@src-f290f3149a]。一个「思考」模型为回答同一个问题会产生数倍到数十倍的 output token。厂商有两个选择：保持单价、让用户看到账单暴涨；或者提价、但让每个 token 更有效。Google 选了后者，并且用「3 Flash 比 2.5 Pro 少用 30% thinking token」来做卖点——**厂商把「思考效率」内化为定价的一部分，与「thinking token 已是主要成本项」这一判断一致**（这是与证据相容，不是证明：Google 没有披露过 thinking token 在其推理成本中的占比）。

  **3 · 产品线在向上重定位。**2024 年的 Flash 是「便宜的小模型」；2026 年的 Flash 被厂商定位成「打得过上一代 Pro 的主力模型」，真正的低价位交给了 Flash-Lite。**名字没变，位置变了。**这一条**可以直接从定价表读出来**，是三条里唯一完全可核的。

  **结论（收窄版）：只看「Flash」这个名字的 $/token，会得出「AI 在涨价」；只看「Google 主力档位」的标价，会得出「AI 在降价」。两者都对，因为它们跟踪的不是同一个对象。**要做商业模型，就必须先定义你跟踪的是**名字、档位、还是某个固定的能力门槛**——第三种最有用，也**最难做**，因为公开材料目前给不出一个跨代一致、口径可核的能力门槛定义。**本章不宣称自己有这样一个定义，也因此不给「等能力 $/token 的年降速率」这个数。**



### 10.5 token 量：官方披露过的最惊人的一组数字

| | 时间 | 月度 token（全部 surface） | 出处口径

| | 2024-05（I/O 2024） | 9.7 万亿 | I/O 2026 keynote 回溯^[34]

| | 2025-05（I/O 2025） | 480 万亿 | 同上；约 50×/年

| | 2025-06 | >980 万亿 | Logan Kilpatrick / Demis Hassabis 公开表述，经媒体转述转述^[35]

| | 2026-05（I/O 2026） | >3.2 千万亿 | Pichai keynote 原文：两年前每月 9.7 万亿 token……去年 I/O 增长到约 480 万亿。快进到今天，这个数字跳了 7 倍，超过每月 3.2 千万亿^[34]

    表 7.14 · 度量 A：全部 surface 的月度 token 处理量（含 Search AI Overviews、AI Mode、Gemini App、Workspace）。两年增长 **330 倍**，复合月增长率约 1.28×。

| | 时间 | API token/分钟 | 折合月度

| | 2025 Q4（2026-02 财报） | >100 亿 | 约 432 万亿/月

| | 2026 Q1（2026-04 财报） | 160 亿 | 约 691 万亿/月

| | 2026 Q2（2026-07-22 财报） | 约 220 亿 | 约 950 万亿/月

    表 7.15 · 度量 B：模型 API 的 token 速率，口径更窄，只含直接 API 调用[@src-be8eb159b1][@src-67ea357f9c][@src-9f4a08bfb1]。





  **这两条曲线必须分开看，否则会得出「2026 年 7 月的量比 2025 年 7 月还低」的荒谬结论。**度量 A 包含所有内部 surface，度量 B 只是开发者与企业的直接 API 调用。2026 Q2 的比值是 3200/950 ≈ 3.4——**即 Google 自己的产品消耗的 token 是外部 API 的 2.4 倍。**


配套的 Q2 2026 官方数字：每月超过 **900 万开发者**在用 Google 的模型；**近 500 家 Cloud 客户**在过去一年各自处理了超过 1 万亿 token；过去 12 个月**超过 2,000 家企业**消耗了超过 1,000 亿 token；Gemini Enterprise 被**近 90% 的财富 100 强**采用[@src-9f4a08bfb1][@src-646dcb0e6c]。




    **图 7.33** AlphaEvolve 落到 Google 自身基础设施的**三个方向**（三面板信息图）：**(a) 数据中心层——Borg Scheduling**、**(b) 硬件层——TPU Circuit Design**、**(c) 软件层——Gemini Training**。读法：这三格连起来正是**本章那条因果链的闭环**——AlphaEvolve 由 Gemini 驱动，去优化调度、TPU 电路布局与 Gemini 自己的训练，更好的 TPU 又训出更好的 Gemini。**⚠️ 本图是纯示意信息图，全图只有这 6 行标签文字，没有任何数字、百分比或坐标轴**：下面这些收益数字与限定条件全部出自正文与官方博客，不出自本图。2026-07-09 它已通过 Gemini Enterprise Agent Platform 向 Cloud 客户 GA[@src-16f74db008]。**但增益是个位数百分比、每一步都要过自动评估器与人类采纳，与「智能爆炸」相距若干个数量级。**
    [@src-1b5c7b4997]出处：Google DeepMind, AlphaEvolve, 2025



## 十一、九个软肋、六条可证伪判断，与本章的自我审计

### 11.1 九个软肋





      TPU 直到 2026 年 Q2 才第一次交付到客户自有数据中心，此前只能通过 GCP 租。对客户而言这是供应商锁定；**对 Google 而言这也是一种反向锁定**——它的软件栈与 TPU 深度耦合，使得 Google 自己在需要用 GPU 时反而不如别人顺手。**Google 一边推 vLLM on TPU、一边推 TorchTPU，本质是在拆自己筑的那道围栏。**








      真正精通 TPU 栈的工程师几乎全部出自 Google 系。第三方对「Anthropic 为什么能用好 TPU」的解释就是「它有前 Google 编译器专家」[@src-0923568307]——**这从反面说明了人才池的狭窄**。TorchTPU（2026-04 preview）是对这个成本的正式承认[@src-7fcb28f154]。








      公开确认的大规模外部 TPU 用户主要是 Anthropic，加上 2025-11-06 那篇 Ironwood 公告点名的 Lightricks、Essential AI，以及 Fluidstack 这个代管方[@src-ccf6eb1cf9][@src-ea68365713]。Nebius、Lambda、CoreWeave 均表示短期内不会部署 TPU[@src-7fd787e67a]——**但这三家是 Nvidia 生态里的 GPU 云、与 Nvidia 有投资绑定轮次与金额待核、且证词出自同一批报道，因此只能读作「外部多租户市场广度未证明」，不能读作「TPU 只对 Google 有经济性」，完整处理见 §9.5。****Meta 的 TPU 洽谈是 The Information 的报道，经 Reuters 转述转述[@src-12c7f37b2f]，至今（2026-07）未见双方任何正式确认。**








      见 §6.6。**基于公开软件栈的第三方 TPU 基准可能系统性低估某些配置（公开栈支持最弱的 MoE 在线推理、多主机 wide-EP 首当其冲），而基于 Google 内部数据的评估无法被独立验证**——在这两类之间，外界目前缺少一个公允评价 TPU 真实性能的位置。








      见 §9.4。A4 / A4X / A4X Max / G4 全线 Blackwell 产品，2026 年再加 A5X（Vera Rubin NVL72），单站点规划到 8 万张 Rubin、跨站点 96 万张[@src-5a37387ce0]。**Google Cloud 是 Nvidia 最大的渠道之一，OpenAI 在 Google Cloud 上跑 GB300 做 ChatGPT 推理。**








      第三方判断：TPU 8 仍用 HBM3E，而 Nvidia Rubin 押 HBM4；内存带宽是 decode 的决定性变量，**384 MB SRAM 补不回 HBM 的代差**；训练 TCO 优势据估从 1.52× 缩到 1.23×[@src-0923568307][@src-641c810714]。**这个判断是可证伪的，见 §11.2 判断 1。**








      Alphabet 的年度折旧摊销从 2024 到 2025 涨了约 38%[@src-a043e7e77e]，而 capex 在 2026 年要再翻一倍以上。更微妙的是 2026 年突然长大的那一行：**资产负债表存货余额从 2025-12-31 的 \$2.439B 涨到 2026-06-30 的 \$9.991B**[@src-7775dbd964]（口径说明见 §7.1 的批判块；**不要用媒体流传的 \$0.628B → \$7.739B，那是现金流量表的调整额**）。**⚠️ 这一行不叫「TPU 库存」——它同时装着待售 TPU 系统与 Pixel 等消费硬件，比例官方未披露**，所以下面这段风险描述适用于「存货这一行」整体，**不能换算成任何一个 TPU 的具体金额**。

      这意味着 Google 从「资本开支 → 折旧」的云模式，部分转向了「存货 → 销货成本」的硬件厂商模式。**两种模式的现金流特征、毛利率结构和风险敞口完全不同**：云模式下一台没租出去的机器只是利用率低，硬件模式下一批没卖出去的 TPU 是要计提减值的存货。而 AI 硬件的代际更替周期只有 12–18 个月。








      见 §7.2 末尾的批判块。**Pichai 的优先级排序本质上是一份配给制的宣告**，而配给制在需求高增长期一定会得罪人。








      运营排放 −2%，但总排放 +18%、供应链排放 +25%、相对 2019 基准 +81%，用水 +34%[@src-1a1c10467a][@src-1a9e08ffcb]。**「PUE 1.09 在已披露样本中领先」与「总排放创历史最大增幅」并存**——效率叙事在绝对量面前正在失效。这是一个会在 2027–2030 转化为监管风险和社区阻力的变量，而不只是 CSR 报告的一页。







### 11.2 六个可证伪的判断（2026H2–2028）

| | 判断 | 证伪标准

| | 1 · v8 是保守的一代，v9 才是胜负手。 TPU 8 仍是 HBM3E，而 Rubin 押 HBM4；内存带宽是 decode 的决定性变量。 | 若 2026H2–2027H1 有可信的第三方测量显示，TPU 8i 在同等 MoE 模型上的 cost/token 比 VR200 NVL144 低 30% 以上，则说明 Boardfly + CAE 的系统级微创新足以抵消内存代差，本判断错误。强化标准：若 2027 年的 v9 仍不上 HBM4 + 更先进制程，则代差会被拉到 2×。

| | 2 · Boardfly 会在 2027 年上溯到训练侧。 8t 保留 torus 是因为稠密预训练的流量确实可编排，但 MoE 的专家并行正在把 all-to-all 引入训练。 | 若 TPU 9t（假设 2027–2028）仍是纯 3D torus，则说明训练侧的通信模式仍足够规则，本判断错误。佐证信号：8t 已经引入了「LLM Decoder Engine」这个官方语焉不详的模块，且 SparseCore 的描述已从「embedding 查表」扩展到「数据依赖的 all-gather」。

| | 3 · TPU 外售在 2027 年之前不会成为有意义的收入线。 Q2 2026 首次交付，但 Alphabet 自己说大部分收入在 2027。 | 若 2026 Q4 或 2027 Q1 财报里 TPU 系统销售被单独列为可辨识的收入项且占 Cloud 营收 >10%，则本判断错误。关键观察点：Meta 的 TPU 交易是否官宣——至今只有媒体报道，没有任何一方正式确认。

| | 4 · 「同名档位的 $/token 上涨」会继续，且会成为公开争议。 由 thinking token 计入 output + 产品线向上重定位共同驱动，两个驱动力都没有减弱迹象。注意本判断跟踪的是「Flash 这个名字」，不是某个固定能力门槛——后者缺乏可核定义，见 §10.4。 | 若 2027 年 Google 发布的下一代 Flash 主力型号 output 标价低于 7.50，则涨价趋势逆转。次级预测：会有厂商开始提供「按任务计费」或「按有效 token 计费」，以规避 thinking token 带来的账单不可预测性。

| | 5 · 到 2027 年，电力与并网交付仍会留在 Gemini 规模的约束集合里。 ★这一条已按 §8.0 改写：原版写的是「电力而非芯片将是第一约束」，那是一个本章不主张的排序判断，已删。现版只主张「仍在集合里」，不主张它排第几。Pichai 已连续多季说 supply constrained；Q2 2026 甚至要租第三方算力过桥。 | 若 2027 年 Alphabet 电话会不再提「供给受限」，或 capex 增速显著低于 token 量增速且没有需求下滑，则约束已解除、本判断错误。⚠️ 判据的已知弱点：「不再提供给受限」测的是披露话术，不完全是物理约束；而且即使它仍被提及，也无法分辨受限的是芯片、电力还是许可——**要真正裁定，需要 Alphabet 单列「因电力交付延迟推迟上线的算力占比」，这项披露目前不存在。**佐证信号：Google 的 24/7 CFE 目标（2030）与 Kairos SMR 首堆时间（2030）撞在同一年——这不是巧合，是同一个规划表。

| | 6 · TPU 的护城河会从「技术」转向「人才网络」，并因此变浅。 Anthropic 能把 TPU 用好，第三方的解释是它有前 Google 编译器专家。 | 若到 2028 年，除 Anthropic 外仍没有第二家非 Google 系团队在 TPU 上做出前沿模型，则技术门槛论成立、本判断错误。加速因素：TorchTPU + vLLM on TPU + MaxText 的持续开源，都在主动降低这个门槛——Google 正在为了扩大市场而亲手削薄自己的护城河。这是一个理性的权衡，但它是不可逆的。

    表 7.16 · 六个可证伪判断。这些是**作者判断**，不是事实陈述；每一条都附了可以在未来 24 个月内机械核对的证伪标准。
      **★阈值锚定审计见 §11.4**——其中判断 1 与判断 4 的阈值锚在**会漂移的第三方估算与当期标价**上，检验时必须重取当时的快照，不能拿冻结日的数当固定终点线。




#### 11.2b 三条「观察清单」——够不上可证伪判断，但值得盯

下面三条**不放进表 7.16**，因为它们缺主体、阈值或裁定方中的至少一项，**叫「预测」会高估它们的成色**。
  它们的正确定位是**观察项**：一旦触发，本章的某个判断就需要回头重估。

• O1 · TPU 系统销售是否在财报里被单列为可辨识收入项（观察窗：至 2027-06-30 的各季财报与 10-Q）。 为什么够不上判断：单列与否首先测的是披露政策，不是业务规模；不单列既可能因为规模小，也可能因为不构成可报告分部。 触发后要重估的是：§7.2c 的两个竞争解释（若同时披露存货构成，可直接裁定），以及表 7.16 判断 3。

• O2 · Nebius / Lambda / CoreWeave 中是否有任一家改口（判据具体到：在季报或官方公告中确认 TPU 部署容量，单位为 MW 或芯片数；观察窗至 2028）。 为什么够不上判断：三家有共同商业利益与共同信源，改口与不改口都可能由投资人关系而非经济性驱动（见 §9.5）。 触发后要重估的是：§9.5 的第 ② 句（外部多租户市场广度）。

• O3 · 官方 PyTorch/XLA 文档里 eager 模式的性能数字是否被上修（观察窗：随文档更新，无固定日期）。 为什么够不上判断：文档数字的更新节奏不受任何公开承诺约束，不更新不等于没有改进； 而且本章尚未逐条回核过那份文档的当前数字（见 §9.5 的待核标记），连基线都还没固定，就更谈不上阈值。 触发后要重估的是：§6.6 第三笔账与 §9.5 里「迁移成本高」这条旁证的强度。执行前的第一步是先把基线核实并写下来。

  11.3 本章结论：垂直整合的真实经济学

  把三层收益拆开看：
  
  **第一层（最常被提及，也最容易被高估）：省掉 Nvidia 的毛利。**Nvidia FY2026 Q4 GAAP 毛利率 75.0%[@src-300b1f6d8d]，但 Google 要付 Broadcom 的加价，还要自己承担设计、流片、编译器、运维的全部成本。**净收益有多大，公开材料只有一个数：内部 TCO 低约 44%——而这个数必须带满三个限定才能引用**：它是 **SemiAnalysis 的第三方情景估算、不是实测也不是任何一方的披露**；它是 **Ironwood(v7) vs GB200 那一代的对照**；它出自 **2025-11 的那份建模**，冻结日没有更新版[@src-0923568307]。
  
  **而且这一层收益不但是线性的，还是有保质期的。**线性是指：省 44% 就是省 44%，不会复利。有保质期是指：**同一份第三方估算自己给出的下一代数字是收窄的**——训练 TCO 优势从 GB200/v7 的 **1.52×** 缩到 VR200/v8 的 **1.23×**，HBM 带宽性价比差距从 1.32× 收窄到 1.10×[@src-641c810714]。**如果这个估算成立，那么「44%」描述的是一个会被通用硬件代际跃迁部分吞掉的窗口，而不是一个稳态优势。**（注意「如果成立」这四个字：这仍是同一类第三方建模，只不过这一次它的方向对 Google 不利。**不能因为一个估算的结论对自己不利就给它更高的可信度。**）
  
  **第二层（本章认为最实的一层）：调度自由度。**OCS 让任意 job 现场拼出最优拓扑；Pathways 让一个 Python 进程编排 9,216 颗芯片；GSPMD 让并行策略与模型代码解耦；内存冗余副本把 goodput 从 85% 拉到 97%。这些收益的共同特征是**它们让「可行的实验空间」变大**——v4 论文里「搜索出来的拓扑 + 并行策略组合比专家手选快 1.2 倍」这个例子，只有在你能任意重构拓扑时才存在。**买 GPU 的人买到的是算力；自研的人买到的是「问不同问题的权利」。**
  
  **★但这一层与第八节直接冲突，交叉点必须写出来。**反方在这一层的姿态是**回避而非反驳**——Nvidia 的公开论述打的全是通用性与可替换性，
    而**通用性与调度自由度是两个正交维度**，打不到一起。**真正削弱这一层的不是 Nvidia，是本章自己的第八节**：
    「拼出最优拓扑的权利」只有在**「你想跑的实验比你能跑的实验多」**时才值钱。
    **当边际约束从「有没有合适的拓扑」变成「有没有那一兆瓦」时，这个权利的边际价值会下降**——
    因为最优拓扑省下的是**时间与利用率**，而电力约束卡的是**能不能开机**，两者不在同一个维度上互相抵扣。
  
    **该怎么定这层的强度，取决于一个本章无法回答的问题：在 Google 当前的边际决策上，卡住的是拓扑还是兆瓦？**
    §8.0 已经说明我们没有裁定约束排序的证据，**所以这一层的强度也只能给一个区间，不能给一个值。**
  
  **第三层（最难量化，也最决定性）：反馈回路的长度。**Gemini 团队发现 MoE 在线推理的 all-to-all 是瓶颈 → 这个信号在 Google 内部走到 TPU 架构团队要几周 → 两年后变成 TPU 8i 的 CAE 和 Boardfly。同样的信号在一家用 GPU 的公司里，要走到供应商的路线图，然后和其他所有客户的需求排队。
  
  **所以答案是：省钱是第一层，可以被追平；调度自由度是第二层，需要同时拥有硬件和软件；反馈回路是第三层，需要同时拥有硬件、软件和前沿模型团队。在公开材料上，Google 是目前三层都能一一对应上的公司**——但这句话有三处需要立刻收窄。**其一，「三层都有」不等于「三层都在有效运转」**：第三层的证据是一条时间线上的巧合（团队发现瓶颈 → 两年后出现对应硬件），Google 从未披露过这条内部链路的实际决策记录。**其二，第三层不是 Google 独有**：OpenAI × Broadcom、Anthropic × AWS / Google / Broadcom 都在搭同样的结构，而 Anthropic 已经在别人的硅上跑出了前沿模型——这本身就说明第三层**不必自有硅也能部分成立**（该判断按 §9.5 的裁定同步收窄）。**其三，第一层有保质期、第二层的强度取决于边际约束是拓扑还是兆瓦**，两条都写在上面。
  
  **因此更稳的说法是：这条护城河的宽度不取决于 TPU 有多好，取决于「自有反馈回路」相对「借用别人的硅 + 自己的编译器人才」还能领先多久。**
    **⚠️ 而「这个差距正在收窄」这句话，本章现在只能作为一个方向性判断给出，不能引 §9.3 当证据**——
    §9.3 的裁定是**MFU 之争双方都不成立**，它证明不了收窄，也证明不了没收窄。
    真正指向收窄的只有两条较弱的信号：Anthropic 用非自有硅做出了前沿模型；以及 Google 自己在主动降低迁移门槛（TorchTPU、vLLM on TPU、TPU 外售）。
    **两条都是行为信号，不是测量。**
  
  
  
  
  **最后一条反面意见，值得单独留在结尾：垂直整合的收益与技术不确定性成反比。**这个反馈回路的延迟很长——芯片 3–4 年设计周期。如果 2027 年架构范式又变了（比如线性注意力真的取代了 softmax attention、或者推理从自回归转向扩散），**为 2026 年 workload 精心设计的 8t / 8i 可能生不逢时**。Jeff Dean 自己讲过这个不对称：芯片设计师今天画的电路要 2.5–6 年后才变得相关，而 ML 范式每 6–12 个月翻一次[@src-905b209662]转述，非原话。
  
  **把公式刻进硅是一件强大的事，前提是那条公式在硅出厂时还成立。**

  11.4 单点数据脆弱性登记表

  脆弱不等于错误。这张表登记的不是本章的错误，而是本章那些只靠一个数据点、一份第三方建模、 一次口径选择、或一个会随季度变动的快照站着的结论。登记它们的理由很实际：下一次数据更新时，得有人知道该回头改哪里。 最后一列刻意写成「什么变化会让它需要重估」，而不是「它可能是错的」——前者是一个可执行的监测项，后者只是一句免责声明。

| | # | 本章的结论 | 它实际建立在什么之上 | 脆在哪 | 什么变化会让它需要重估

| | V1 | 垂直整合的第一层收益 ≈ 内部 TCO 低约 44%（§9.2、§11.3） | 单一第三方、单一时点：SemiAnalysis 2025-11 的一份情景建模^[30]。Google 与 Nvidia 均未披露任何输入，也从未确认结果 | 它是估算不是实测；它的核心输入「TPU 40% vs GPU 30% MFU」本身是假设值（§9.3 已裁定这对数不可比）； 而且只对 Ironwood vs GB200 那一代成立——同类估算给下一代的数是 1.52× → 1.23× | ① SemiAnalysis 或任一独立机构发布覆盖 8t/8i vs VR200 的新建模；② Alphabet 首次披露 TPU 单独的毛利率或单位成本； ③ MFU 假设被实测数据替换（见 §9.3 的三条判据）

| | V2 | $1.60 / TPU-hour——F7-7 全部算例、goodput 折算、成本计算器默认值都用它（§5、§10.2、§10.3） | 与 V1 同源的同一份建模、同一个时点^[30] | 本章最集中的单点依赖：三处独立结论共用一个第三方数字，看起来是三条证据，实际是一条。 且它是合同价的估计值，与官方公共标价（v6e 三年承诺 $1.22）不同口径、不同代际 | ① 出现任何合同级一手证据（客户披露、诉讼材料、监管文件）；② Google 公布 Ironwood/8i 的公共定价页； ③ 该建模发布更新版且改了这个数——届时三处算例必须一起重算，不能只改一处

| | V3 | 2026 capex 指引 $195–205B，以及由它推出的一切增速对比（§8.1、§8.2） | 指引不是实际支出，且一年内已经出现三档、两次上调（$175–185B →$180–190B → $195–205B）^[36][37][23] | 一个半年内被改过两次的数被当成分母用在 §8.2 的「≈87」里。指引还会继续修订； 实际值与指引的偏差在冻结日无法预知 | ① 2026 Q3 / Q4 电话会再次调整指引；② FY2026 实际值公布（届时 §8.2 的比值必须用实际值重算）； ③ Alphabet 改变 capex 的口径定义（例如把租入算力计入或剔除）

| | V4 | 存货余额 $9.991B（半年 +$7.55B）及其支撑的「商业模式质变」判断（§7.1、§7.2c、软肋 7） | 单季资产负债表快照^[24]，且是混合科目——待售 TPU 系统与 Pixel 等消费硬件装在同一行，比例官方未披露 | 两层脆弱叠在一起：(a) 季度数会回落，一个季度的暴涨不构成趋势； (b) 分不清 TPU 占几成，所以任何由它推出的 TPU 外售规模判断都缺分母。 §7.2c 的两个竞争解释之所以无法裁定，根源就在这里 | ① 10-Q / 10-K 附注首次拆分存货构成（这一条一旦发生，§7.2c 可以直接裁定）； ② 连续两个季度余额继续同斜率上升，或掉头回落；③ 出现存货减值计提

| | V5 | Anthropic 的 GW 级承诺（最多 100 万颗 TPU / 2026 上线 >1 GW / 约 3.5 GW 至 2031）（§7.2、表 7.6b） | 一手公告用的是「最多」与「multiple gigawatts」^[20][21]； 3.5 GW 出自 Broadcom 监管文件的媒体转述，且挂在 “continued commercial success” 这类前提条款下^[22] | 「最多」与「有条件」都不是交付承诺。本章已删掉无一手支撑的「5 GW」，但保留的这几个数仍然是上界而非计划值； 一旦被去掉限定语引用，就会变成对 TPU 外售规模的高估 | ① Anthropic 或 Google 披露实际上线容量（MW 或芯片数）；② Broadcom filing 的条件条款被触发或解除； ③ 双方公告改用无条件措辞

| | V6 | 表 7.16 六条可证伪判断的阈值（§11.2） | 判断 1 的「低 30% 以上」锚在尚不存在的第三方测量与一个可能改名的产品配置上； 判断 3 的「>10% Cloud 营收」锚在一个同比 +82% 的分母上； 判断 4 的「低于 7.50」锚在 2026-07-25 当日的 3.6 Flash 标价上 | ★这三条与 ARC-AGI-3 的 7.78%、GDPval-AA 的 440 Elo 是同一种失效模式： 把一个会漂移的快照当成固定终点线。判断 3 尤其隐蔽——Cloud 营收高速增长时， 「占比 >10%」这个门槛的绝对金额每季都在变，同一笔 TPU 收入去年过线、今年就可能不过线 | 检验时必须重取当时的快照，不能沿用冻结日的数：判断 1 要固定对照配置与 benchmark； 判断 3 应改为绝对金额 + 占比双阈值；判断 4 要以检验当日的现役主力 Flash 标价为基线， 而不是 7.50 这个 2026-07 的数。这三处是本章已知的欠账。

| | V7 | 「电力进入约束集合」（§8.0 保留的弱版本） | 两条口径：一句官方博客表述^[1] + 一次播客访谈^[2]； 加上一批投资动作作为行为证据 | 没有任何量化披露支撑它——Google 从未公布「因电力交付延迟推迟上线的算力占比」， 也从未在 capex 里单列电力支出。本章因此只能主张「在集合里」，不能主张排第几（这也是判断 5 被改写的原因） | ① 出现前述任一量化披露；② 官方在电话会上明确给出约束排序而非并列列举； ③ 出现「芯片交付充足但项目仍因并网延期」的具名案例

| | V8 | 单 prompt 能耗 12 个月降 33 倍（§8.3） | 单一年度报告的一句披露^[25]，口径是「Gemini 应用的中位文本 prompt」 | 中位数不含图像 / 视频 / 音频 / 长上下文 / agent 多轮，也不含训练； 方法学论文^[26]定义的是某一时点的口径，两年之间口径是否完全一致，官方没有说明。 本章已因此撤回由它反推的 45× 需求量推算 | ① 2027 年报告改变能耗核算口径或不再披露这个比值；② 官方给出分模态 / 分负载的能耗拆分； ③ 出现独立第三方的能耗测量

| | V9 | 三家独立 AI 云拒绝部署 TPU（§6.6、§9.5、软肋 3） | 同一批报道、三位高管、一个信源链^[28]； 且三家与 Nvidia 的投资绑定在本章仍标 [待核] | 信源不独立、利益方向一致。本章已据此把结论收窄成「外部市场广度未证明」， 但如果那三句引语的语境被误读（例如是对特定时间窗的回答），连这个弱结论也要重写 | ① 任一家公开确认 TPU 部署容量（见 O2）；② 拿到 Nvidia 对三家投资的一手文件，把 [待核] 落实； ③ 出现与这三家无关的独立 GPU 云给出相反表态

| | V10 | MegaScale 55.2% MFU 作为「MFU 差距不纯粹来自硬件」的证据（§9.3） | 单篇论文^[38]：12,288 颗 Ampere、标准 175B 稠密、BF16 | 三个维度都与争议焦点（当代硬件、MoE、FP8）不同。本章已把它的作用限定为「削弱强版本」，不作为任何正面结论的证据； 但它仍是这一节唯一的 GPU 侧实测数 | ① 出现 MoE + ≥10k 卡 + 含 MFU 的第二篇系统论文；② 任一方公开同团队 / 同模型 / 同精度的 TPU–GPU 对照； ③ 论文被更正或撤回

| | V11 | Gemini 1.5 Flash 那次降价的 output 降幅（§10.4） | 官方公告写 −71%，与本项目归档的降价前价 $0.53 算出的 −43.4% 对不上；归档价本身标 待核^[39] | 这是一处已登记但未解决的冲突。本章的处理是并列两个口径、不合成单一百分比——代价是这一格永远无法进入任何计算 | ① 找到 2024-05 的官方定价页存档；② 官方澄清 −71% 对应的档位（≤128K / >128K）与层级； ③ 归档价被更正

| | V12 | 8t / 8i「截至 2026-07-25 无 Preview / GA 条目」（表 7.1、§2.3） | Cloud TPU release notes 的一次快照^[12] | release notes 随时会加条目；这句话的有效期最短，可能在本章交付后的任何一周失效。 同类脆弱还有制程与代工（媒体两说、官方无口径）与代号（官方只写 8t/8i，见 §2.2 批判块第 3 条） | release notes 出现 8t / 8i 的 Preview 或 GA 条目——届时表 7.1 的状态列与 §2.3 全节都要改

    表 7.17 · 本章的单点数据脆弱性登记表（**12 条**）。
      **V1 与 V2 是本章最深的一处承重点**：§9.2 的成本对照、§5 的 goodput 折算、§10.2 的两条成本公式、§10.3 的计算器，
      全部压在**同一份第三方建模的同一个时点**上——它们看起来是四条独立论证，实际共用一个数字。

      **★可证伪阈值锚定审计结论**：本章六条判断里，**判断 2、5、6 锚定在事件上**（是否仍是纯 3D torus、是否仍提供给受限、是否出现第二家非 Google 系团队），
      **判断 1、3、4 锚定在会漂移的快照上**（尚不存在的第三方测量、一个高速增长的营收分母、当日标价）——

      **后三条与 ARC-AGI-3 的 7.78%、GDPval-AA 的 440 Elo 是同一种失效模式**（这两个数的完整评测条件见第 8 章，此处只借用它们作为失效样例），
      检验时必须重取当时的快照，具体改法见 V6 行。

      事件锚定不会漂移，但它更容易缺可测定义——判断 6 的「前沿模型」在本章就没有给出操作性定义，这是另一处已知欠账。





  来源







































































































    ← 总览
    上一章：核心公式推导
    下一章：Agent 与世界模型



    Gemini 认知体系全景 · 材料时间边界 2021.01 – 2026.07 · 事实冻结于 2026-07-25



    本章中，正文为有出处的事实陈述；**紫色「本质洞察」**与**橙色「批判 / 局限」**为作者判断。
    引语标「转述」者非原话，标「译文」者以英文原文为准。数字凡官方未披露的均标注为外部估算。