从 CLOS 到 ZCube：智算集群网络拓扑演进

从 CLOS 到 ZCube：智算集群网络拓扑演进

从 Charles Clos 1953 年的无阻塞电话交换网络，到字节跳动 2025 年 SIGCOMM 最佳论文的 ZCube——拓扑设计从专家直觉走向自动搜索。ZCube 用非对称结构在 16K GPU 规模上省掉 60% 交换机、训练速度提升 5%，而智谱 AI 的生产验证证明它不只适用于训练。

本文是「AI 训练网络技术全景」的姊妹篇之一，聚焦网络拓扑的物理层设计。姊妹篇之二「从 RoCE 到 MRC：AI 集群传输协议与芯片重构」深入分析传输协议与芯片实现。全景综述篇见「AI 训练网络技术全景：从 CLOS 到 ZCube，从 RoCE 到 MRC」。

一个反直觉的发现：对称性不是最优的

2025 年 SIGCOMM 最佳论文的评审意见里有一句话值得注意：所有传统拓扑设计都假设交换机是同构的——同一个端口数、同一个规格。这个假设看起来理所当然：相同交换机更容易采购、更容易备件、更容易运维。

但 ATOP（Automated Topology Optimization Pipeline）的自动搜索发现，在 AI 训练流量模式下，非对称结构在性能-成本 trade-off 上始终优于对称结构。不是"差不多"，是在每个 GPU 规模的搜索中，Pareto 前沿拐点处的最优解都呈现相同的非对称特征。

这个发现的深层含义是：人类专家对"对称性"的偏好，在 AI 训练场景下是一种认知偏差。ATOP 通过消除这种偏差，发现了 ZCube。

从 Clos（1953）到 Fat-Tree（2008）到 BCube（2009）到 Rail-Optimized（2020s）到 ZCube（2025），拓扑设计的目标从"通用无阻塞"转向"AI 训练专用"，设计方法从"人工设计"转向"自动搜索"。这条演进路径值得完整梳理。

---

起点：Clos 拓扑的三个假设

1953 年，Charles Clos 发表了无阻塞多级交换网络的理论。现代数据中心的 Fat-Tree 就是 Clos 拓扑的直接应用。Clos 拓扑有三个隐含假设，在 AI 训练场景下逐个崩塌：

假设一：流量模式不可预测。 Clos 设计为"任意输入可以连到任意输出"提供全二分带宽。但 AI 训练的集合通信模式高度规律——每个训练 step 重复相同的 AllReduce/All-to-All 模式。不需要"任意到任意"，需要的是"特定模式下的最优"。

假设二：大量独立小流。 ECMP 哈希在大量独立小流下统计均匀。但 AI 训练产生少量大象流，两个大流被哈希到同一条链路的概率不低。流碰撞导致尾延迟——同步训练中，最慢的一次传输决定整个 step 的耗时。

假设三：三层交换足够。 三级 64 端口 Clos 最多连 ~32K 端点。10 万 GPU 需要四层或收敛比，但每多一层交换机就多一跳延迟，成本和功耗也急剧上升。

---

Rail-Optimized：从"通用连接"到"匹配通信模式"

核心思想

一台 GPU 服务器内部有 8 个 GPU（如 DGX H100），每个 GPU 有自己的 NIC。Rail-Optimized 的思路是：与其将 8 个 NIC 连到同一台 ToR 交换机，不如将所有服务器中相同位置的 GPU 连到同一台交换机，形成 8 条独立的"Rail"。

为什么对 AI 有效

数据并行中，相同 rank 的 GPU 跨服务器通信最频繁。Rail 拓扑让同 rank GPU 间通信只需单跳，大部分流量被吸收在 Leaf 层，不经过 Spine。

Rail-Only vs Rail+Global（ROFT）

NVIDIA DGX SuperPOD 参考架构采用 ROFT 设计。但 ROFT 的问题在于：三层结构意味着 PP 流量需要 3-5 跳（Leaf→Spine→Aggregation→Spine→Leaf），延迟叠加严重。交换机数量也多——16K GPU 的 ROFT 需要 640 台交换机。

---

ZCube：把拓扑设计变成超参数搜索

论文背景

ZCube 来自 SIGCOMM 2025 最佳论文 "From ATOP to ZCube"。第一作者 Zihan Yan（清华大学），通讯作者 Dan Li（李丹）——正是 2009 年 SIGCOMM BCube 论文的作者。核心工业验证来自字节跳动，Haibin Lin 同时也是 MegaScale（NSDI'24）和 ByteScale（SIGCOMM'25）的核心作者。

ZCube 的命名传承自 BCube——B 是 Byte/Cube，Z 是"the last letter, the ultimate Cube"。从 BCube 到 ZCube 的 16 年，拓扑设计从"人工"走向"自动"。

ATOP 方法论

ATOP 的核心洞察：不需要从零搜索拓扑，而是将专家设计直觉提炼为结构化的超参数空间，然后自动搜索。

直觉地理解 ATOP 在做什么：想象你在设计一个多居室的楼层平面图。传统方法是建筑师凭经验画图——几个卧室、几个卫生间、客厅多大、走道多宽。ATOP 的方法是：先定义一组可调参数（“卧室数量 1-8”、“走廊宽度 1-3m”、“客厅朝向南或东”...），然后在所有参数组合中搜索“采光最好 + 面积利用率最高 + 动线最短”的最优解。

ATOP 对网络拓扑做的事情完全一样：把“多少层交换机”、“每层多少个”、“层间怎么连”、“层内怎么连”这些设计决策参数化，然后在参数空间中搜索 14 个目标（训练速度、成本、容错...）的最优平衡点。

研究几乎所有主流拓扑（CLOS、Fat-Tree、ROFT、Rail-only、HPN、BCube、DCell、HyperX、Torus、Dragonfly 等），从中提炼出 11 类可搜索超参数：

• 层间连接：GPU 数量、最大层数、每层节点数、分块参数、连接数、带宽因子（1-4 对应 200G-800G）
• 层内连接：维度数、每维节点数、外向连接数、坐标计算因子

将搜索空间从邻接矩阵的 O(2^N²) 压缩到可在单台 CPU 服务器上 3 天内搜索完毕。

NSGA-II 进化算法：14 个优化目标（9 个 DP/PP/Mixed JCT + 2 个 MoE JCT + ForestColl all-gather + APS 容错 + 成本），non-dominated sorting 确保多目标公平性。

流级仿真器：max-min fairness + SimGrid 拥塞建模，与 NS-3 包级仿真器对比平均误差仅 1.5%。两阶段评估将 10 万次完整评估减到 ~5000 次，20 倍加速。

搜索效率（单台 256 核 AMD EPYC）：

ZCube 递归定义

ATOP 在 256、1024、4096、16384 四个规模的搜索中，Pareto 前沿拐点处的架构都惊人地相似——论文将其形式化定义为 ZCube。

• ZCube(n, 1) = 1 个交换机 + n 个 GPU
• ZCube(n, k+1) = n × ZCube(n, k) + n^k switches

ZCube(n, k) 包含：GPU 数量 n^(k+1)，k+1 层交换机，每层 n^k 个交换机，总交换机 (k+1) × n^k。每个 GPU 有 (k+1) 个 NIC 端口。

实际规模：

• ZCube(128,2)：16,384 GPU，256 个交换机，每个 GPU 2 个 NIC 端口（1 个 400G NIC 分为 2×200G）
• ZCube(84,3)-partial：592,704 GPU，84 个 pod 以 CLOS 互联，网络直径 4

---

非对称性：为什么 ZCube 打破了"同构交换机"的假设

这是 ZCube 最核心的创新。在 ZCube(n, k) 中：

• 首尾层（level-0 和 level-(k-1)）交换机需要 2n 个端口
• 中间层（level-1 到 level-(k-2)）交换机需要 3n 个端口

以 ZCube(128,2) 为例：level-0 和 level-1 交换机都是 256 端口（128×200G），但流量模式完全不同。边缘层直接连 GPU，主要承载集合通信（AllReduce/AllGather）；核心层主要承载跨 pod 的 PP 流量。

为什么非对称更优？ 不同层交换机承载的流量模式不同、端口利用率不同。让所有层用相同端口数的交换机，必然有一层是过度配置的。非对称设计精确匹配每层的实际需求。

运维的现实考量：非对称拓扑意味着不同层需要不同规格的交换机（2n vs 3n 端口），增加采购和备件管理复杂度。论文未深入讨论运维问题。这是 ZCube 在生产环境落地的实际障碍之一——但如果节省的硬件成本足够大（60% 交换机），运维复杂度可能值得。

---

直径：2 跳意味着什么

论文 Theorem 1 证明：ZCube(n,k) 的网络直径为 k。

PP 流量在 ROFT 中需要 3-5 跳，在 ZCube(128,2) 中最多 2 跳。少 3 跳 = 少 3 次交换机转发延迟 + 少 3 次 serdes 重定时 + 少 3 次光-电-光转换。对延迟敏感的 PP 流量，这个差距直接体现在训练速度上。

---

甜点规模：1024 GPU 的 ZCube(32,2)

ZCube 论文的核心案例是 16K GPU 的 ZCube(128,2)。但实际部署中，大多数训练集群和推理集群在 128-1024 GPU 规模。ZCube 在这些规模下是否值得？

一个硬约束：ZCube(n, k) 要求每个 GPU 有 k 个 NIC 端口。k=2 意味着每个 GPU 需要 2 个端口（1 张 800G NIC breakout 成 2×400G），这是大多数服务器能支持的。k=3 需要 3 个端口，大多数服务器做不到。所以 ZCube 的实际部署只有 k=2 这一个实用选项。

先看全貌：

下面逐规模展开分析。

128 GPU：Flat 最优

单台 128×400G 交换机直连 128 个 GPU，1 跳、全二分带宽、0 台多余交换机。ZCube(11,2) 需要 22 台交换机，每个只有 22 端口——交换机数量比 GPU 数量的 1/6 还多，完全不经济。

结论：128 GPU 用 Flat，不要用 ZCube。

256 GPU：过渡区间

ZCube(16,2) 需要 32 台 32 口交换机。交换机/GPU = 1:8，太密了。Rail-only（8 台 32 口交换机）更简单，虽然只有同 Rail 的 GPU 是 1 跳，但 256 GPU 的 AllReduce 通信模式通常在 Rail 内就能覆盖大部分。

2-tier Clos 也只要 4 台 128 口交换机。256 GPU 规模下 ZCube 的优势不够显著。

512 GPU：ZCube 开始显现优势

ZCube(23,2) 需要 46 台 46 口交换机，所有 GPU 对之间 2 跳、全二分带宽。Rail-only 用 8 台 64 口交换机，跨 Rail 通信需要走更长的路径。

46 台交换机看起来多，但每台只有 46 端口——在 Tomahawk 5（51.2T）上只用了不到一半端口密度，还有余量。交换机/GPU = 1:11，开始进入合理区间。

1024 GPU：ZCube(32,2) 是甜点

ZCube(32,2) 的参数几乎完美映射到市面标准交换机：

• 64 口交换机 = Tomahawk 5 的标准配置（64×800G 或 128×400G breakout）
• 每 GPU 2 个端口 = 1 张 800G NIC breakout 成 2×400G
• 64 台交换机 = 4 个标准机架（每架 16 台）
• 交换机/GPU = 1:16 = 论文中 ZCube(128,2) 的 1:64 在小规模下的等比缩放

为什么 1024 是甜点而不是 512？ 512 GPU 的 ZCube(23,2) 需要 46 口交换机——不是标准规格，实际部署需要用 64 口交换机浪费 18 个端口，或者定制。1024 GPU 的 ZCube(32,2) 需要 64 口交换机——恰好是 Tomahawk 5 的原生端口配置，零浪费。

智谱 AI 的千卡推理集群正好落在 1024 GPU 区间——ZCube 在这个规模下节省 1/3 光模块和交换机、吞吐提升 15%，不是理论推算，是生产数据。

甜点总结

---

NVLink 域扩展：当原子单位从 GPU 变成机架

ZCube 的所有计算都以单个 GPU 为原子单位。但 2025-2026 年，Scale-Up 域正在从 8 GPU（单服务器）扩展到 72 GPU（NVL72），未来可能到 256-576 GPU。当 NVLink 域 = 72 GPU 时，Scale-Out 网络的“原子单位”从 GPU 变成了 NVLink 域。

对 ZCube 参数的影响：

核心变化：NVLink 域越大，Scale-Out 网络的节点数越少，ZCube 的 n 值越小，交换机数量也越少。但每个 NVLink 域对外只有有限的 NIC 端口——NVL72 通常配置 8-18 个外部 NIC 端口——这限制了 k 值的上限。

开放问题：当 NVLink 域扩展到 576 GPU（NVSwitch），一个 16K GPU 集群只有 ~28 个 Scale-Out 节点。此时 ZCube(5,2) 只需要 10 台交换机——但 5 口交换机太小了，可能不如直接用 1-hop Flat 拓扑。Scale-Up 域的扩展可能让 ZCube 的优势区间向上移动——从 512-16K GPU 变成 4K-64K GPU。

这个分析还没有论文支撑，是基于 ZCube 递归定义的简单推算。当 NVLink 5 + Vera Rubin 的具体 NVLink 域规格公布后，值得重新用 ATOP 搜索。

---

16,384 GPU 定量对比

使用 Broadcom Tomahawk 5（51.2T）交换机，每台服务器 8 GPU + 8×400G NIC：

核心发现：

• 交换机少 60%（256 vs 640），比 Rail-only/HPN 少 33%
• 光模块成本减 25%-50%：ZCube 用 200G 线缆（vs ROFT 的 400G）
• 训练快 3%-7%，成本低 26%-46%——同时赢在性能和成本
• MoE-GPT：ZCube 6.06s vs ROFT 6.41s；BCube(128,2) 因无全二分带宽退化至 13.79s
• ForestColl all-gather：所有拓扑理论最优性能相同

这个结果的关键启示：ZCube 不是在性能和成本之间做 trade-off——它在 Pareto 前沿上同时优化了两者。用更少的交换机、更便宜的线缆，跑出更快的训练速度。

---

容错：交换机越少越可靠

单 ToR 故障（4K GPU，GPT-3 175B）：

ZCube 的容错优势来自两个因素：一是交换机少（故障概率更低），二是每个 GPU 有多个 NIC 端口连到不同交换机（故障后可快速切换）。

无故障概率（16384 GPU，单交换机故障率 0.03%）：

链路故障退化曲线（1%-15% 随机链路故障）：ZCube 退化最平缓，标准差最小。交换机少不只是省钱，也是更高可靠性的来源。

---

生产验证

16 GPU 物理测试床

论文搭建 16 GPU 物理测试床（4 台服务器 × 4 H800 GPU，8 个 Mellanox QM9790 IB 交换机），对比 ZCube(4,2) 与 ROFT：

• All-reduce：所有数据量（1M-16G）性能完全相同
• All-to-all：性能完全相同
• 成本：ZCube 用 48×200G 链路 vs ROFT 32×400G——成本降低 25%

智谱 AI 推理集群

智谱 AI（z.ai）将千卡 GLM-5.1 推理集群从 ROFT 升级为 ZCube，在 GPU 硬件不变、不修改应用的前提下：

• 节省 1/3 光模块和交换机
• 推理吞吐量提升 15%

ZCube 在推理场景的优势尤为突出：MoE expert all-to-all、PD 分离场景的 KV Cache 迁移等流量模式与 ZCube 的非对称拓扑高度契合。这是 ZCube 不限于训练场景的直接证据。

---

ZCube 与 MRC 的协同：为什么两场革命必须一起看

ZCube 和 MRC 目前是独立演进的，但组合起来有天然的结构性优势。理解这些协同效应，才能理解为什么两者互为前提。

2 跳直径简化了协议层的故障管理

ZCube 的 2 跳直径是它最重要的拓扑属性之一——不只是降低了延迟，还直接简化了传输协议的复杂度。

MRC 的 EV 四状态机（active → congested → suspected_failed → confirmed_failed）需要在每个 RTT 内判断路径是否存活。在 5-7 跳的三层 Clos 中，一个 RTT 可能是数十微秒，而路径上任何一个中间节点都可能成为故障点。在 ZCube 的 2 跳拓扑中，路径短、中间节点少——EV 状态机的收敛速度更快，故障判断的置信度更高。

SRv6 编码也受益于短路径：2 跳只需要 2-3 个 uSID 段，包头开销几乎可以忽略。5-7 跳的 Clos 需要 5-7 个 uSID 段，即使有 C-SID 压缩也有累积开销，挤占有效载荷空间。

非对称拓扑需要源路由

传统网络依赖 ECMP 做负载均衡，而 ECMP 要求多条等价路径——这隐含了对称拓扑假设。ZCube 的非对称结构（首尾层 2n 端口 vs 中间层 3n 端口）在 ECMP 下会产生路径数量不等的问题：某些链路可能因为端口数不同而被过度使用或闲置。

MRC 的 SRv6 静态源路由绕开了这个问题：NIC 在发包时就编码了完整路径，交换机按 SRv6 头转发，不需要理解拓扑结构。这意味着非对称拓扑的路径管理从"交换机需要复杂的路由协议"变成"NIC 端预计算 + 静态编码"。

每个 GPU 的 k 端口 = 天然的多路径基础

ZCube 要求每个 GPU 有 k 个 NIC 端口（k=2 时，每个 GPU 连 2 个不同交换机），每个端口提供一条独立路径。这恰好是 MRC 多路径传输的物理基础——128-256 条路径的包喷射，需要 GPU 有足够多的物理出口。ZCube 的 k=2 配置（2 条独立路径）是最小可工作配置，k=3 或更高时 MRC 的路径多样性更充分。

一个未验证的关键问题

ZCube + MRC 的协同目前没有被论文或生产数据验证。核心未知数：ZCube 的非对称拓扑是否需要 MRC 的源路由做特殊适配？标准 ECMP 在 ZCube 上的实际表现如何（论文只验证了全二分带宽，没有深入分析 ECMP 在非对称拓扑上的哈希分布）？这些问题的答案可能决定 ZCube 在大规模部署中是"必须搭配 MRC"还是"ECMP 也够用"。

→ 深度分析见姊妹篇之二「从 RoCE 到 MRC：AI 集群传输协议与芯片重构」。

---

ATOP 的通用性：不只是新建数据中心

论文展示了 ATOP 在五种场景下的适用性：

1. 新建（256-16K GPU）：每个规模的最性价比拓扑都是 ZCube
2. 改造现有 DC（4K GPU ROFT 重新布线）：仅换光模块和线缆，ZCube 仍最优
3. 扩容（1K→4K GPU）：保留原有设备，ZCube 在 Pareto 前沿
4. 多租户（16K 分 4 家各 4K）：ZCube 仍是拐点
5. 异构（H100+A100 混合）：严格约束下 ZCube 不在搜索空间内，但 ATOP 仍找到比 ROFT 性能高 6%、成本低 11% 的拓扑

ATOP 的价值不只是找到 ZCube——它是一个可重复使用的拓扑优化工具。当新硬件、新模型、新约束出现时，重新运行 ATOP 即可。

---

OCS：拓扑演进的另一个方向

ZCube 是"在电交换框架内优化拓扑"。拓扑演进还有一条路线：用光路交换（OCS）替代 Spine 层电交换机。

Google Apollo

Google 从 2022 年起大规模部署 OCS（代号 Apollo），用 3D MEMS 微镜阵列替代 Spine 层。SemiAnalysis 估计 Apollo 为 Google 节省超过 30 亿美元的网络设备采购。

InfiniteHBD（SIGCOMM 2025）

更进一步——在光收发器级别集成连接和动态交换能力。每个光收发器本身可以动态改变连接目标，构建数据中心规模的高带宽域。

OCS 的适用条件

OCS 不适合包级交换（切换速度毫秒级），但 AI 训练流量是粗粒度的——集合通信持续数毫秒至数百毫秒。OCS 的胜利条件是大流量、可预测模式、规模足够大使得 Spine 层成为瓶颈。

---

拓扑演进的趋势判断

四个方向

1. 从对称到非对称：ZCube 证明非对称在 AI 负载下更优
2. 从三层到两层：OpenAI 多平面 Clos（MRC）和 Microsoft Fairwater 都压缩到两层
3. 从电交换到光电混合：Google Apollo 证明 OCS 在 Spine 层可行
4. 从交换机智能到端点智能：MRC 把路由决策权从交换机转移到 NIC

按规模选拓扑

开放问题

1. ZCube 在 64K+ 规模的表现未知——论文只验证到 16K。ATOP 搜索在更大规模下的计算成本和仿真准确性都是挑战。
2. 非对称拓扑的运维成本——不同层需要不同规格交换机，备件管理复杂度上升。生产环境是否愿意为性能/成本收益承受运维成本？
3. OCS 与 ZCube 的竞争/互补——ZCube 省掉了 60% 电交换机，OCS 则试图用光交换机替代 Spine 层。两条路线是否会在某个规模点收敛？

物理约束：拓扑选择的真实天花板

以上讨论都在拓扑结构的理论空间中。但实际部署面临三重物理约束，可能限制拓扑选择的自由度。

光模块成本与功耗。 ZCube 的甜点在于用 200G 光模块替代 400G——单端口成本更低。但光模块本身仍是网络中最大的成本项之一。以 1024 GPU 的 ZCube(32,2) 为例，49,152 条 200G 链路 × 单价 $50-100 = $250-500 万，占总网络成本的 40-60%。1.6T 时代光模块成本可能翻倍，这将压缩拓扑优化的成本节省空间。

机柜功率限制。 每台 GPU 服务器（8×H100/H200）功耗约 10-12kW。标准 42U 机柜通常限制在 20-30kW（空调制冷），最多放 2-3 台服务器。这意味着 ToR 交换机的 GPU 端口密度天然有限——即使拓扑设计允许更密集的连接，物理空间和功耗不允许。800V 直流配电可以提升机柜功率上限到 120kW+，但需要全新的供电基础设施。

铜缆 vs 光缆的距离约束。 GPU 服务器到 ToR 交换机的连线通常在 1-3 米（铜缆）或 3-10 米（有源光缆 AOC/直连铜缆 DAC）。ZCube 的非对称结构意味着不同层可能在不同物理位置，层间连线距离可能超出铜缆有效范围，迫使使用光模块——增加成本。ATOP 的搜索空间目前假设所有连线等价，但实际部署中物理距离是硬约束。

这三个约束意味着：ATOP 搜索出的"最优拓扑"需要在物理约束下重新验证。理论上的 Pareto 前沿可能因为物理限制而收缩。

---

ATOP 的真正贡献：方法论 > 具体拓扑

如果 ZCube 论文只给了 ZCube 拓扑，它的价值是有限的——硬件会换代，模型会变化，最优拓扑也会变。

但 ATOP 的贡献是方法论层面的：

• 将拓扑设计从"专家凭直觉"转变为"在形式化搜索空间中自动优化"
• 消除人类认知偏差（对称性偏好、同构偏好）
• 多目标优化（性能、成本、容错同时考虑）
• 可重复使用——新硬件、新模型、新约束出现时，重新运行即可

从 BCube（2009）到 ZCube（2025），李丹团队 16 年的拓扑研究画出了一条清晰的线：拓扑设计正在从"艺术"走向"工程"。

---

声明： 本文基于 SIGCOMM 2025 最佳论文 "From ATOP to ZCube"、字节跳动与智谱 AI 的公开技术资料、Google Apollo 的公开报道进行交叉验证后撰写。不构成投资建议。文中数据截至 2026 年 6 月 1 日。