Google Jupiter DCN揭秘：Apollo OCS光交换，重构传统CLOS迈向百万卡集群的范式革命

AGI小咖

本文深度剖析Google Jupiter DCN 在迈向 Exaflops（百亿亿次）算力时代的架构演进，揭示其如何利用 Apollo OCS 光交换技术实现从传统多级 CLOS 到 Direct Mesh 的范式转移。继前文推演复盘 Google ICI 后端网络从4x4x4 Cube 到TPUv7 9216 Pod的Twisted 3D Torus环面组网拓扑背后的原理和数学实现 ，本期我们将继续剥洋葱式的 推演复盘Jupiter DCN 如何利用一套包含 73,728 块 400G DCN IPU 网卡，以及 4,608 台 12.8T ToR (TH3)、2,304 台 25.6T Leaf (TH4) 和 2,304 台 25.6T Spine (TH4) 的庞大物理网络，支撑起 147,456 颗 TPU v7 的超大规模集群 ，在此基础上进一步阐述集群背后 从感知（CSIG）、传输 (Falcon)、接口（SAI）到调度（Orion）的全栈协同体系，阐述其如何通过全域精细化治理突破物理瓶颈 ， 为未来迈向百万卡超大规模集群 提供了一套从芯片互联到数据中心架构的标准化工程范本。

1、双万亿时代的物理墙与系统重构

随着大模型参数规模突破万亿级别、训练数据集跨越万亿Tokens 量级，单芯片算力增长已难以匹配指数级增长的模型复杂度。为突破内存墙、通信墙与计算墙的物理瓶颈，Google 采用了异构双平面的组网架构：

• ICI 后端网络（内存语义平面）：不同于竞品通常采用的 InfiniBand 或 RoCEv2，Google 部署了轻量级的 G-ICI (Google Inter-Chip Interconnect) 专有协议。该协议摒弃了传统网络栈的帧开销，专注于张量并行（TP） 与 流水线并行（PP）的微秒级同步以及 Pod 内部的高频梯度同步（All-Reduce），实现了跨芯片的 HBM 内存空间全局寻址 。
• Jupiter DCN 前端网络（存储与管控语义平面）：与互联网上其他公开渠道常看到的2022年以前采用5层CLOS架构组网不同，本文特指2022年后引入 OCS 光交换核心层的 Jupiter Evolving 架构，除了常规的 全局检查点（Checkpoint）读写和海量训练数据加载 外，Jupiter DCN 的独特之处在于依托 Multislice 全栈技术，承担了跨 Pod 的数据并行（DP） 和 完全分片数据并行（FSDP） 流量 ， 实现了多租户环境下的全局资源调度与线性扩展。

2、Google ICI 后端网络架构演进回顾

在《Google TPU架构揭秘：OCS光交换，从4x4x4 Cube到9216卡Ironwood的进化引擎》文章中深度复盘 Google TPU 智算集群的网络架构演进，重点剖析 3D Torus 拓扑与 OCS（光交换）技术的协同机制。 以图1全景拓扑图为例， 文章从最小拓扑单元 4x4x4 Cube 出发推演复盘 TPUv4 4096 Pod标准3D Torus环面与 TPUv7 9216 Pod的Twisted 3D Torus环面组网拓扑背后的原理和数学实现， 随后对比TPUv5e/v6e 的2D Torus Mesh务实架构， 揭示 Google 如何在万卡集群规模下实现确定性低延迟与极致 TCO（总拥有成本）优化，并对比 AWS 与 NVIDIA 的异构技术路线 ，结合上下游供应链生态与CPO技术趋势分析，展望未来TPU架构“芯片出光、全光直连”全新范式。

图 1: Google TPU v7 Ironwood 9216 节点 ICI后端网络全景图

3、Jupiter DCN 物理网络架构：光电融合拓扑深度解析

承接上文，接下来我们深度分享一下如图2所示Google如何用 一套物理与逻辑高度解耦、硬件与软件深度协同的 Jupiter DCN（数据中心网络） 支撑 147,456 颗 TPU v7 的 超大规模 AI 集群 。 这套基于 Ethernet/Falcon 协议的Jupiter DCN前端网络与 TPU 内部基于 3D Torus/G-ICI 协议（9.6T/chip）的 ICI 后端专网实现了彻底的物理隔离 ， Jupiter DCN全网部署了 73,728 块 400G DCN IPU 网卡 ，4,608 台 12.8T ToR (TH3)、2,304 台 25.6T Leaf (TH4) 和 2,304 台 25.6T Spine (TH4) 交换机 ， 接下来我们一起剥洋葱式解构庞大的物理网络集群背后分层设计的奥秘。

3.1 拓扑层级视图：基于 Apollo OCS 的分层解构

Google Jupiter DCN 的核心变革在于引入光交换（OCS）重构了传统的数据中心网络拓扑 ， 如图 2 全景拓扑图 展示了从最底层的计算节点（Tray）到最顶层的光互联核心（OCS Core）的完整数据路径。

（一） 联合Intel定制IPU网卡

作为整个拓扑图的最小原子接入单元， 每个计算托盘（Tray）集成 4 颗 TPU v7 芯片与 1 颗 Host CPU（Google Axion 或 Intel Xeon） ，通过PCIe 5.0 x16链路（单向64GB/s）实现 CPU与TPU无损通信 互联。 在网络接入方面每个托盘配置了2 张 Google Titanium IPU 网卡：Google与Intel联合研发和定制的基于 Intel E2200（代号：Mount Morgan）ASIC 的 单芯片支持 400Gbps 吞吐与 PCIe Gen 5.0 x16 接口 ， 每张 Google Titanium IPU 网卡对外可提供2*200Gbps的上行链路接入到每个机柜上TOR交换机上。

（二） 联合 Broadcom和ODM厂家自研电交换机

Google采用液冷高密机柜的部署策略，每个机柜可以容纳16个托盘合计64颗TPUv7芯片+16颗CPU，采用双ToR冗余设计接入Jupiter DCN网络中，依托交换芯片巨头Broadcom Tomahawk 3（单芯片容量 12.8 Tbps）和ODM厂家代工生产的自研交换机作为TOR层，严格遵循32×200GE 下行 + 32×200GE 上行的1:1收敛比实现机柜内无拥塞、冗余网络，全网合计部署了 4,608 台此类 ToR 交换机。

Google Jupiter的Leaf-spine依据采用与Broadcom和ODM厂家代工的自研电交换机，采用模块化设计，每144个机柜及其上行接入的288台ToR交换机组成一个Pod单元模块，Pod与Pod之间的通信通过Group模块交换网络实现东西向流量通信，而每个Group内部有4台Leaf + 4台Spine组成，288个Group电交换网络模块为4个Pod提供东西向流量清洗以及向上的 OCS 连接，有点让人诡异所思的是Leaf和Spine居然采用的是Broadcom Tomahawk 4 ASIC（单芯片容量 仅25.6Tbps，而不是采用BAT等互联网大厂尤其是Spine层普遍采用的51.2T的Broadcom Tomahawk 5 ASIC），全网共计部署了 2,304 台 Leaf 与 2,304 台 Spine。

（三） 基于MEMS 的 Apollo OCS 全光交换矩阵

Google Jupiter DCN 物理 全景拓扑图最顶端的4组合计256台 Apollo OCS（内部代号 Palomar 演进版）是前端网络设计核心亮点之一，也是Google Jupiter DCN网络自从2012年CLOS 架构全面转向以 Apollo OCS 为核心的 Direct Mesh 架构的一脉相承。基于 3D MEMS 镜片阵列 与高精度 2D 光纤准直器技术配合环形器 实现单光纤的双向传输，能够实现 300×300 端口的全光动态调度，256台OCS组成光交换矩阵实现了4个超大 Aggregation Blocks 合计36,864 CPU计算节点和9216台交换机（TOR/Leaf/Spine）的通信，

扁平化的光交换核心层极大的简化了网络架构还能够实现极低的插入 极低的插入损耗与协议无关的透明传输 ，更为关键的是波长与端口速率无关的黑科技创新，即使Spine层交换机 从 400G 升级到 800G 乃至 1.6T， 无需更换核心 OCS 设备 。

3.2 超大规模组网背后架构设计亮点揭秘

（一） 边缘计算单元：Titanium IPU 与 Host 协同

Google Cloud 与 Intel 在基础设施处理器（IPU）领域的合作，是“软件定义基础设施”在异构计算时代最成功的注脚 ， 双方的战略合作始于2022年联合发布的 首款ASIC 架构 IPU E2000（代号 Mount Evans）， 全面支撑从通用计算 C3、A3 GPU 实例到 TPU v5p/v7 集群的前端网络 ， 而在14万TPUv7的Jupiter DCN前端网络组网中采用的是最新一代的 基于 Intel E2200 (Mount Morgan) 定制Titanium IPU网卡，解锁了 400Gbps 单芯片吞吐 实现双口2*200Gbps上行带宽接入能力，同时将Google私有 Falcon 协议内置于芯片内，利用硬件级流控实现类RDMA 的高性能与以太网的弹性，集成线速加密引擎支持 PSP 安全协议，在不占用 Host CPU 算力的前提下构建零信任通信；并内嵌 P4 可编程流水线 将虚拟交换数据平面下沉，让每一台 TPU 主机进化为具备边缘交换能力的高性能节点。

（二） 交换网络：基于商用芯片的TCO 优化策略

作为Broadcom 最大的数据中心客户之一，根据 Broadcom 2024 财年报告，以 Google 为首的超大规模客户贡献了 120 亿美元 AI 网络芯片收入的绝大部分。双方这种长达十年的战略协同，确保了 Google 始终享有最新一代 Tomahawk 芯片的优先供应权与深度定制能力，但在 Jupiter DCN 网络的芯片选型上，Google并未盲目追逐最新制程，而是基于200GE网络颗粒度的适配性与成本考量务实选择工艺成熟的TH3/TH4芯片以获取“代差红利”。

与国内阿里巴巴、腾讯等 互联网 头部云厂商的底层网络构建逻辑 一样 ， Google 采用 定制设计 Broadcom Tomahawk ASIC 和 交由Celestica（天弘）、Quanta（广达）和 Edgecore（智邦） 等ODM 厂商代工 策略 彻底剔除品牌溢价 和加速软硬协同迭代周期， 确保了在万卡集群规模下的设备一致性与交付效率。

（三） 核心交换：OCS 光交换技术与架构重构

早期的 Jupiter 网络（Jupiter Rising 阶段）采用标准的 5 级 Clos 架构，依赖商用电子交换芯片构建分层网络。虽然解决了由 1G 向 10G/40G 的带宽扩展问题，但随着节点规模突破 10 万级，电子交换层级过多带来的 SerDes 功耗墙、光电转换（O-E-O）成本飙升以及布线复杂性逐渐成为不可承受之重。

面对上述物理瓶颈， 2022年 Google 实施了数据中心 DCN 网络历史上最激进的一次重构，即从 CLOS 架构全面转向以 Apollo OCS 为核心的 Direct Mesh 架构 ， 核心在于 基于 MEMS 技术的全光交换矩阵 替代庞大的Super-Spine 电交换层，得益于 MEMS OCS 对波长和速率的天然透明性，即使Spine层交换机从 400G 升级到 800G 乃至 1.6T，无需更换核心 OCS 设备，克服了摩尔定律失效带来的硬件迭代压力。

OCS 的引入不仅是传输介质的物理变革，更赋予了网络架构无与伦比的动态重构能力与增量扩展弹性。在面对新旧 TPU v4 和TPUv7 集群混合部署场景时， SDN控制器和OCS协同调整微镜角度，即可在毫秒级时间内完成光路重组，无需任何人工介入插拔光纤，实现了对在运业务的 无感扩容，另外也支持从标准的3D Torus 动态切换至 Twisted 3D Torus 拓扑。

从能效与成本维度 考量OCS 方案 相比于同等带宽规模的InfiniBand 组网方案整体功耗降低了 30% 至 40%，且其在总系统拥有成本（TCO）中的占比不到 5%，功耗占比仅为 3% ，构筑了极具竞争力的工程护城河。

面对光路切换带来的拓扑动态变化、数万条链路的拥塞控制以及微秒级的容错需求， 接下来我们将深入解读Google如何通过Jupiter DCN Overlay层的感知（CSIG）、传输 (Falcon) 、接口（ SAI ）到调度（Orion）的组合拳解决方案开启上帝视角的。

4、DCN Overlay 控制体系与全栈闭环

4.1 传输层 (Falcon)：面向硬件卸载的协议设计

Falcon 是 Google 专门为配合 Titanium IPU 和 OCS 网络设计的传输协议，旨在彻底替代 TCP 和传统 RDMA ， 提前集成到ASIC上提供硬件级传输卸载解决方案。

Falcon 原生支持细粒度 的逐包级 多路径传输 、 数据包喷洒技术（ Packet Spraying ）等黑科技，彻底消除了传统ECMP哈希不均、长尾延迟的问题。另外，为了解决逐包级别的多路径导致的乱序问题， Titanium 网卡内置了高性能的乱序重排引擎 ： Falcon 协议头中包含高精度的序列号，接收端硬件能够以线速重组数据包。一旦发现丢包，Titanium 立即 主动 触发微秒级的快速重传请求，而不是被动等待 TCP 的超时。

4.2 感知层 (CSIG)：高精度拥塞信号机制

标准ECN (RFC 3168) 的拥塞控制机制只能 通过一个比特（CE bit）告诉发送端网络出现了拥塞， 却无法准确告知拥塞定位点，Google引入了 CSIG (Congestion Signaling) 机制 ： 创新性在以太网头和IP头之间插入一个 L2.5 Shim Header ， 在Jupiter DCN网络沿途ToR/Leaf/Spine交换机都会执行交换机端口当前的指标（如当前队列深度的反压值、瞬时可用带宽）与 CSIG TAG包头中的 Value 进行比较、按需重写和更新Value以及对应的 Locator Metadata （ 如ToR ID ）。

当数据包到达接收端Titanium 网卡时，CSIG 信息被提取并通过 ACK 包带回发送端 ， 发送端 Titanium 网卡不仅知道网络拥塞状况，还精确知道拥塞发生在哪个 ToR 的上行口。 发送端的拥塞控制算法（如Swift 或 UEC 的 NSCC）利用这些精确的数值（而不仅仅是 0/1 信号）计算发送窗口。例如，如果 Min_ABW 显示只有 50Gbps 可用，发送端可以直接将速率调整至 50Gbps，而不是通过试探性增减来逼近极限。

图5：CSIG 端到端拥塞感知流程与数据包格式

4.3 调度与接口层 (Orion & SAI)：全域 SDN 控制平面

为了屏蔽底层 ASIC（Broadcom TH3/TH4）的差异，Google 深度参与了OCP SAI (Switch Abstraction Interface) 标准定义，所有 的控制指令都通过标准化的SAI 接口下发，使得上层 Orion 控制器可以无缝管理底层来自不同厂商（Broadcom, Marvell）的交换机芯片，实现了真正的 意义上的可编程确定性网络和网络自动化 。

Orion 作为 Google 的第二代 SDN 控制器 ， 分布式部署于集群之上。它通过二分图匹配算法进行全局资源调度，实现了“光电交换”层面的深度协同。一方面，Orion 通过专有控制通道向 OCS 下发微镜偏转指令，物理级重构 Aggregation Block 间的互联拓扑以动态分配带宽；另一方面， Origin 同步通知Falcon 协议栈更新路由表以实时适配新的网络架构。

针对AI 训练流量“长周期、高可预测”的特性，Orion 采用了 Rail-Aligned 路由策略，将同一训练任务的流量静态绑定至特定物理路径，大幅减少动态冲突；同时结合 Hedging（对冲）算法智能规避哈希冲突，确保全网 13 Pb/s 的对分带宽得到高效利用。

依托对L2.5 层 Shim Header 中 CSIG 遥测数据的深度解析，Orion 实现了纳秒级的全网负载感知，并将网络抖动精准压制在微秒级 。在运维场景中系统利用 OCS 的光电路交换能力，将指定区域流量无损迁移至备用路径，达成了业务零感知的在线热维护 。Orion 深度统筹了主机侧 Falcon 的拥塞控制、交换侧 Shared Buffer 的动态分配以及核心层 OCS 的光路重构，成功构建起一套端到端协同的流量治理闭环 。

5、展望

本文系统剖析了Google Jupiter DCN 的演进逻辑，阐述了其如何以 OCS 光交换矩阵取代传统 CLOS 架构中的 Super-Spine 层，并协同 Titanium IPU 实现 Falcon 协议的硬件级卸载，融合 CSIG 的纳秒级拥塞感知机制，从而成功构建了一套物理拓扑与逻辑控制高度解耦、却在调度层面（Orion）深度协同的智算网络。这一架构变革不仅从根本上突破了超大规模集群面临的布线复杂度与散热瓶颈，更为全球 AI 基础设施确立了一套从芯片互联到数据中心架构的标准化工程范本。

在产业生态层面，Morgan Stanley（摩根士丹利）的最新供应链调研数据显示，Google TPU 产能正处于指数级爬坡期，预计 2027 年产量将突破 500 万颗，标志着 TPU 正从“内部自用”加速走向“对外规模化商用” 的战略转型 。近期Meta 与 Google 确立了基于 TPU 的“先租后买”混合部署战略——即 2026 年先行通过 Google Cloud 租赁算力，2027 年依托 GDC (Google Distributed Cloud) 方案实现本地化集群部署。更为关键的是双方联合启动 了 TorchTPU 项目，致力于通过 PyTorch/XLA 在 TPU 上的深度优化，一举打破 AI 框架与特定硬件强耦合的行业惯例，为全球开发者提供了更具灵活性的算力选择。

面向未来百万卡超大规模集群互联挑战，Jupiter DCN 的 OCS 光交换架构展现了极具前瞻性的技术韧性。面对下一代 TPU v8/v9 对 I/O 带宽的爆发式需求，尽管边缘侧的 ToR、Leaf 与 Spine 交换层势必向 Broadcom Tomahawk 5 (51.2T) 乃至 Tomahawk 6 迭代演进，但核心层凭借 MEMS OCS 对波长与速率的天然透明性，无需物理更替即可实现无感升级。

在后摩尔时代，面对百万卡集群的极限互联挑战，Google "TPU+OCS" 的垂直光电融合架构、NVIDIA "GPU+Spectrum-X" 的AI 专用高性能以太网、UEC（超以太网联盟）与光合组织的通用开放标准与多元异构生态，谁才是解决 IO 墙的终极答案？欢迎在评论区留下您的判断。