大模型多芯片网络拓扑设计调研

背景与需求

LLM 推理对网络的核心诉求

大模型推理部署中，张量并行（TP）、流水线并行（PP）、专家并行（EP）等策略使得多芯片间通信成为性能瓶颈之一。网络拓扑直接决定了以下关键指标：

AllReduce 延迟：TP 组内每层 Attention/FFN 计算结束后需要执行 AllReduce，其延迟直接叠加在每个 token 的解码时间（TPOT）上。
AllToAll 吞吐：MoE 模型的专家路由依赖 AllToAll，带宽决定了 token dispatch 的吞吐上限。
P2P 延迟：PP 流水线的 stage 间激活传输对点对点延迟敏感，影响流水线气泡率。
扩展性：支持从 8 芯到 64 芯甚至更大规模，不同规模下拓扑效率差异显著。

典型部署规模

规模	典型场景	主要通信类型
8 芯	单服务器 TP=8	AllReduce, intra-board
16 芯	双服务器 TP=8 + PP=2	AllReduce + P2P
32 芯	4 服务器，TP×EP 混合	AllToAll, AllReduce
64 芯	8 服务器，跨机架，DP/EP 大规模	AllReduce, AllToAll

当前平台的局限

Tier6+ 当前采用 4 级层次路由（c2c / b2b / r2r / p2p），每级用固定带宽和延迟参数描述，没有真正的拓扑图结构和交换机建模。这导致：

无法表达同一层级内不同路径的带宽差异（如 fat-tree 多路径）
无法建模交换机端口竞争与拥塞
AllReduce/AllToAll 的流量模型过于简化，无法反映真实集群行为

主流拓扑类型调研

Ring 拓扑

原理

每个节点（芯片/GPU）连接到左右两个邻居，构成一个首尾相接的环形。通信沿环传播，典型实现为 NVLink Ring（NVIDIA DGX 系列）。

AllReduce 在 Ring 拓扑上执行 Ring-AllReduce 算法：分为 Reduce-Scatter 和 AllGather 两阶段，每阶段各 N-1 步，总带宽利用率为 2(N-1)/N，趋近于 100%。

优点

带宽最优：Ring-AllReduce 的带宽利用率接近 100%，是 AllReduce 的理论最优实现之一。
成本低：每节点仅需 2 条链路，线缆和交换机成本极低。
实现简单：物理布线规整，管理简单；NVLink 板内 ring 是业界最成熟方案。

缺点

延迟随规模线性增长：AllReduce 步数为 O(N)，64 节点时延迟是 8 节点的 8 倍，对小 message 的 latency-bound 场景尤为不利。
容错性差：单链路故障即导致环断裂，路由无法绕行。
跨机架难以维持 ring 连续性：物理布线受限，跨机架 ring 通常需要额外交换机辅助。

适用场景

单服务器内 8 芯 TP 组（NVLink ring）
message size 较大（> 1 MB）的 AllReduce
成本敏感、节点数 <= 16 的小规模部署

Fat-Tree 拓扑

原理

Fat-Tree（又称 Clos 网络）是数据中心最主流的网络拓扑。标准 k-ary fat-tree 由三层交换机构成（Edge / Aggregation / Core），共 k³/4 个节点和 5k²/4 台交换机。

关键特性：

全等分带宽（Full Bisection Bandwidth）：任意两节点间可用带宽与直接相连相同，无带宽瓶颈。
多路径（ECMP）：同一源-目的对之间存在多条等价路径，可负载均衡。
任意全局通信：AllReduce、AllToAll 均可高效执行，无需绕行。

Fat-Tree 与 LLM AllReduce 的关系

在 Fat-Tree 拓扑上，AllReduce 通常使用 Recursive Halving-Doubling 或 Ring-AllReduce 变体。由于存在多路径，流量可并行走不同路径，理论上 N 个节点的 AllReduce 带宽利用率不因节点数增加而下降（假设流量调度理想）。

对 MoE 模型的 AllToAll，Fat-Tree 的全等分带宽使得 N×N 的全对全通信可在同一轮内完成，不存在 Ring 拓扑的序列化瓶颈。

优点

扩展性极强：k=32 可支持 8192 节点，LLM 集群标准拓扑之一。
全等分带宽：AllReduce、AllToAll 效率高，不因规模增大而退化。
容错性好：多路径使得单链路/交换机故障影响局限。

缺点

成本高：交换机数量为 O(N)，光模块、交换芯片成本显著。
跳数多：两个节点间最多经过 4-6 跳，对 latency-bound 小 message 不友好。
拥塞敏感：AllToAll 等全局通信在非理想流量分布下仍会产生 incast 拥塞。

适用场景

32 芯以上的大规模 LLM 训练/推理集群
需要支持 DP/EP 大规模扩展的场景
InfiniBand HDR/NDR 集群（NVIDIA DGX SuperPOD 的机架间部分）

Dragonfly 拓扑

原理

Dragonfly 由多个 group 组成，每个 group 内部为全互联（all-to-all），group 之间通过全局链路（global links）连接。典型参数：每个 group 有 a 个路由器，每个路由器有 p 个终端端口，group 间链路数为 h。

NVIDIA SuperPOD 风格的网络在机架间采用类 Dragonfly 结构：每个 pod 内部 fat-tree，pod 之间 all-to-all 全局链路，实现"两跳"达到任意节点。

优点

极低直径：group 内 1 跳，跨 group 最多 3 跳（src_router -> global_link -> dst_router -> dst_node），延迟远低于 fat-tree。
全局链路高效：适合 DP 等跨 pod 通信，带宽利用率高。
成本介于 Ring 和 Fat-Tree 之间：减少了交换机层级，总成本低于全 fat-tree。

缺点

自适应路由复杂：需要拥塞感知路由（如 UGAL），否则易产生 global link 拥塞。
AllToAll 不对称：同 group 内通信与跨 group 通信带宽差异大，MoE AllToAll 效率依赖专家分布。
扩展单位粗粒度：扩展必须以 group 为单位，灵活性不如 fat-tree。

适用场景

超大规模（1000+ 节点）LLM 训练集群
跨机架 DP 通信为主的场景
需要控制成本同时维持低延迟的高端集群

Rail-Optimized 拓扑

原理

Rail-Optimized（也称 Rail 拓扑）专为 GPU 服务器设计，其核心思想是：将同一服务器内相同"轨道编号"的 GPU（如所有服务器的 GPU 0、所有服务器的 GPU 1...）分别连接到同一台顶层交换机（ToR 或 Spine），形成 "rail"。

具体而言，N 个服务器、每服务器 k 个 GPU，则有 k 台交换机（每台交换机负责 1 条 rail），每台交换机连接所有服务器的同号 GPU。

为何适合 TP 并行

TP 组通常要求组内所有 GPU 做 AllReduce。如果 TP=8 且恰好对应 8 条 rail，则每次 AllReduce 只走一台交换机，不产生跨 rail 流量，带宽利用率最大化。这种布局被称为 "TP-aligned rail"，是 NVIDIA Quantum-2 InfiniBand 集群的推荐配置。

优点

TP AllReduce 最优：TP 组内通信不经过 spine，延迟最低、带宽最高。
可预测性强：流量模式固定，无拥塞热点。
成本可控：交换机数量等于每服务器 GPU 数，通常为 8 或 16 台。

缺点

DP/EP 跨 rail 通信退化：跨 rail 的 AllToAll 需要 rail 间路由，引入额外跳数和带宽竞争。
灵活性受限：TP 组大小必须与 rail 数对齐，否则失去优势。
不支持任意 AllToAll：MoE 大规模 EP 场景下 rail 拓扑的优势消失。

适用场景

TP=8 或 TP=16 的稠密模型推理（Llama、Qwen 等）
服务器数量适中（16~64 台），每台 8 GPU 的标准配置
对 TP AllReduce 延迟极度敏感的在线推理场景

拓扑对比分析

维度	Ring	Fat-Tree	Dragonfly	Rail-Optimized
典型规模	2~16 节点	8~8192 节点	64~10000+ 节点	8~512 节点
AllReduce 效率	小规模优，大规模差	全规模稳定高效	跨 group 有开销	TP 对齐时最优
AllToAll 效率	差（序列化严重）	好（全等分带宽）	group 内优，跨差	跨 rail 差
点对点延迟	O(N) 跳	O(log N) 跳	最多 3 跳，极低	1~2 跳（rail内）
成本	最低	最高	中等	低~中
容错性	差（单点故障）	优（多路径）	中（group 间单路）	中
实现复杂度	低	中	高（自适应路由）	低~中
代表产品	NVLink DGX A100	IB HDR/NDR 集群	Cray Slingshot	IB Quantum-2 Rail
Tier6+ 适配性	已支持（c2c ring）	需要交换机建模	超出当前目标规模	中期目标

Tier6+ 平台设计建议

拓扑配置格式扩展

当前 Tier6+ 的拓扑配置使用层次化参数（c2c/b2b/r2r/p2p），建议在此基础上增加显式的拓扑类型声明和交换机节点支持，同时保持与现有层次格式的兼容接口。

推荐的配置格式扩展方向（YAML 伪代码示例）：

# 拓扑声明
name: "B4-C32-FatTree"
topology_type: fat_tree        # ring | fat_tree | rail_optimized | custom

# 节点定义（芯片）
nodes:
  - id_range: "chip_0..chip_31"
    type: SG2262
    count: 32

# 交换机定义（可选，默认全互联）
switches:
  - id: "sw_edge_0"
    tier: edge
    ports: 16
    bandwidth_per_port_gbps: 400
    latency_us: 0.5
  - id: "sw_core_0"
    tier: core
    ports: 16
    bandwidth_per_port_gbps: 400
    latency_us: 0.5

# 连接关系（可选，支持自动生成或手动指定）
links:
  # 自动生成模式
  auto_generate:
    type: fat_tree
    k: 8                         # k-ary fat-tree
    uplink_bandwidth_gbps: 400
    downlink_bandwidth_gbps: 400

建议支持的拓扑优先级

考虑到 32~64 芯的目标规模和工程实现复杂度，建议分阶段支持：

阶段一（近期，当前目标）：

Ring 拓扑：已有基础，完善交换机节点建模，支持环形拓扑的 hop-count 路由
全互联（All-to-All）：同一 board 内 chip 间全互联，作为 c2c 的精确建模

阶段二（中期）：

Rail-Optimized：支持 ToR 交换机节点，建模 rail 内/跨 rail 带宽差异
2-level Fat-Tree：Edge + Spine 两层交换机，支持 8~64 芯规模

阶段三（远期）：

3-level Fat-Tree：Edge + Aggregation + Core，支持 64~512 芯
Dragonfly：group 结构，适用于超大规模训练集群仿真

核心建模要素

无论采用哪种拓扑，Tier6+ 平台都需要建模以下要素：

交换机端口竞争：多个流共享同一端口时的带宽分摊
多路径路由：Fat-Tree/Rail 中存在多条等价路径，需建模 ECMP 负载均衡
Hop Count 延迟累计：每经过一跳交换机增加固定延迟（~~0.1~~0.5 μs/hop）
集合通信流量展开：AllReduce/AllToAll 在给定拓扑上的实际流量矩阵

与现有层次结构的关系

现有的 c2c/b2b/r2r/p2p 层次结构可视为对不同拓扑的带宽-延迟参数化抽象。建议保留其作为快速估算路径，新增显式拓扑图模型作为精确仿真路径：

快速路径（数学模型）：沿用 c2c/b2b/r2r/p2p 参数，适用于 sweep 大量配置
精确路径（G5 事件仿真）：使用显式拓扑图 + 交换机节点，适用于精细 profiling

参考资料

Besta, M., & Hoefler, T. (2014). Slim Fly: A Cost Effective Low-Diameter Network Topology. SC '14.
Al-Fares, M., Loukissas, A., & Vahdat, A. (2008). A Scalable, Commodity Data Center Network Architecture. SIGCOMM '08. — Fat-Tree 原始论文
Kim, J., Dally, W., Scott, S., & Abts, D. (2008). Technology-Driven, Highly-Scalable Dragonfly Topology. ISCA '08.
NVIDIA. (2022). NVIDIA DGX SuperPOD: Next Generation Scalable Infrastructure for AI Leadership. Whitepaper.
NVIDIA. (2023). Quantum-2 InfiniBand Architecture. Technical Overview.
Shoeybi, M., et al. (2019). Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism. arXiv:1909.08053. — TP 通信模式分析
DeepSeek-AI. (2024). DeepSeek-V3 Technical Report. arXiv:2412.19437. — MoE AllToAll 通信分析
Lepikhin, D., et al. (2021). GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding. ICLR 2021. — EP 路由通信分析

目录​

背景与需求​

LLM 推理对网络的核心诉求​

典型部署规模​

当前平台的局限​

主流拓扑类型调研​

Ring 拓扑​

原理​

优点​

缺点​

适用场景​

Fat-Tree 拓扑​

原理​

Fat-Tree 与 LLM AllReduce 的关系​

优点​

缺点​

适用场景​

Dragonfly 拓扑​

原理​

优点​

缺点​

适用场景​

Rail-Optimized 拓扑​

原理​

为何适合 TP 并行​

优点​

缺点​

适用场景​

拓扑对比分析​

Tier6+ 平台设计建议​

拓扑配置格式扩展​

建议支持的拓扑优先级​

核心建模要素​

与现有层次结构的关系​

参考资料​

目录

背景与需求

LLM 推理对网络的核心诉求

典型部署规模

当前平台的局限

主流拓扑类型调研

Ring 拓扑

原理

优点

缺点

适用场景

Fat-Tree 拓扑

原理

Fat-Tree 与 LLM AllReduce 的关系

优点

缺点

适用场景

Dragonfly 拓扑

原理

优点

缺点

适用场景

Rail-Optimized 拓扑

原理

为何适合 TP 并行

优点

缺点

适用场景

拓扑对比分析

Tier6+ 平台设计建议

拓扑配置格式扩展

建议支持的拓扑优先级

核心建模要素

与现有层次结构的关系

参考资料