网络与集群

单机多卡解决的是一台服务器里的 GPU 协作问题；多机集群解决的是很多台 GPU 服务器如何像一个整体一样工作。
当模型训练、MoE、跨节点并行或大规模在线推理进入生产环境以后，网络就不再只是“能不能连通”，而是会直接决定吞吐、延迟、稳定性和故障恢复成本。

核心判断

多机集群的网络选型要从通信模式反推。
如果只是多副本推理，普通 Ethernet 加稳定的负载均衡通常可以起步；如果是多机训练、跨节点 tensor parallel 或 MoE all-to-all，就要重点看 RDMA、InfiniBand / RoCE、交换机拓扑、拥塞控制和 NCCL 实测。

1. 为什么大模型集群需要关注网络

大模型任务常见的网络压力来自三类数据：

数据类型	典型来源	网络影响
训练通信	梯度同步、参数分片、优化器状态同步。	决定多机训练扩展效率，节点越多越敏感。
模型并行通信	tensor parallel、pipeline parallel、expert parallel。	影响每一步计算是否被跨节点通信拖慢。
服务通信	请求转发、负载均衡、模型分发、日志监控、RAG 检索。	影响线上延迟、冷启动、扩缩容和稳定性。

网络瓶颈常见表现：

GPU 利用率上不去，但显存和算力看起来都够。
多机训练从 1 台扩到 2 台、4 台后吞吐没有线性增长。
MoE 模型在小规模测试正常，节点数变多后延迟抖动明显。
推理服务首 token 延迟不稳定，或者跨节点请求偶发超时。
NCCL 报错、训练 hang 住、某些节点反复掉队。

简单说：单机内主要看 GPU 互联，多机以后要一起看网卡、交换机、协议、调度和框架通信实现。

2. 带宽、延迟和拥塞

网络性能不能只看标称带宽。大模型集群至少要同时看三个指标：

指标	含义	常见影响
带宽	单位时间能传多少数据。	影响大规模 all-reduce、all-gather、模型分发。
延迟	一次通信从发起到收到响应的时间。	影响频繁小包通信、跨节点 TP、pipeline stage 传递。
拥塞	多条通信流同时竞争链路和交换机缓存。	影响尾延迟、训练稳定性和 all-to-all 性能。

对于训练，平均带宽很重要，但尾部延迟和拥塞同样关键。一个节点慢一点，可能让整轮同步都在等待。
对于在线推理，平均延迟好看还不够，还要关注 P95 / P99，因为用户感受到的是最慢的那部分请求。

常见判断：

大块连续同步更吃带宽。
频繁小规模同步更吃延迟。
all-to-all 更容易暴露拥塞和拓扑不均衡。
跨机柜、跨交换机、跨可用区通信通常比同机架通信更不稳定。

3. Ethernet、InfiniBand 和 RDMA

3.1 Ethernet

Ethernet 是最通用的数据中心网络。它生态成熟、成本相对低、运维经验多，适合大多数普通服务通信和推理集群起步。

适合：

多副本推理服务。
API 网关、负载均衡、日志、监控、RAG 检索。
对跨节点 GPU 集合通信不敏感的业务。
成本和通用性优先的中小规模集群。

需要注意：

普通 TCP 网络可以跑分布式任务，但跨节点 GPU 通信效率通常不如 RDMA。
标称 100G / 200G / 400G 不等于端到端实际吞吐。
交换机 oversubscription、队列拥塞和跨机架路径都会影响稳定性。

3.2 InfiniBand

InfiniBand 是高性能计算和大规模 AI 训练中常见的低延迟、高带宽网络。
它通常和 RDMA、NCCL、GPU Direct RDMA 一起用于多机多卡训练。

适合：

大规模预训练。
多机 FSDP / ZeRO / Megatron 类训练。
对低延迟和高带宽都敏感的跨节点通信。
希望获得更确定网络性能的高价值训练集群。

需要注意：

成本、设备选型和运维复杂度通常高于普通 Ethernet。
需要关注 HCA、交换机、线缆、Subnet Manager、驱动和 NCCL 版本。
性能仍然要实测，不能只看网络型号。

3.3 RDMA

RDMA 允许一台机器直接访问另一台机器的内存区域，减少 CPU 参与和内核协议栈开销。
在 AI 集群里，RDMA 的价值通常体现在 GPU 节点之间的大规模数据搬运，尤其是结合 GPUDirect RDMA 时，可以减少 CPU 内存中转。

常见收益：

降低通信延迟。
减少 CPU 占用。
提高大规模集合通信吞吐。
改善多机训练扩展效率。

RDMA 不是一个单独设备，而是一组能力组合：网卡、驱动、协议、交换机、系统配置和框架都要配合。

3.4 RoCE

RoCE 是在 Ethernet 上承载 RDMA 的方案，常见的是 RoCEv2。
它的优势是可以复用以太网生态，成本和通用性更好；难点是要把以太网调成适合 RDMA 的低丢包、低拥塞环境。

RoCE 需要重点关注：

PFC：优先级流控，用于减少特定流量类别丢包。
ECN：显式拥塞通知，用于拥塞反馈。
MTU：端到端 jumbo frame 是否一致。
QoS：训练流量、存储流量、业务流量是否隔离。
交换机 buffer：突发流量是否会导致丢包或尾延迟上升。

RoCE 最常见的问题不是“跑不通”，而是“能跑但性能不稳定”。所以一定要做 NCCL tests 和真实任务压测。

4. 训练通信看什么

分布式训练通常通过 PyTorch Distributed、NCCL、MPI、DeepSpeed、Megatron、FSDP 等框架完成通信。底层网络差异会直接反映到训练 step time。

通信模式	典型场景	网络关注点
all-reduce	数据并行梯度同步。	总带宽、拓扑对称性、慢节点影响。
reduce-scatter	ZeRO、FSDP、分片优化器。	分片粒度、带宽、NCCL 算法选择。
all-gather	参数分片还原、TP 中间结果聚合。	带宽和延迟都重要。
all-to-all	MoE expert dispatch。	拥塞、交换机拓扑、跨节点流量分布。
point-to-point	pipeline parallel stage 传递。	相邻 stage 的网络距离和尾延迟。

扩展效率可以粗略理解为：

多机收益 = 增加的计算能力 - 增加的通信和调度开销

如果通信开销增长太快，加更多 GPU 反而可能不划算。

实践建议：

数据并行优先保证 all-reduce / reduce-scatter 稳定。
FSDP / ZeRO 要关注参数 all-gather 和 optimizer state 分片通信。
TP 尽量放在单机高速互联内，跨节点 TP 要谨慎。
PP 可以跨节点，但要让相邻 stage 的网络路径尽量短。
MoE 要专门压测 all-to-all，不能只看 dense 模型指标。

5. MoE 为什么特别吃网络

MoE 模型的特点是每个 token 只激活部分 expert，但 token 会被路由到不同 expert。
当 expert 分布在不同 GPU 或不同节点时，就会产生 token dispatch 和 combine，常见通信模式是 all-to-all。

MoE 网络压力来自：

token 路由不均衡，某些 expert 或节点成为热点。
all-to-all 让很多节点同时互发数据，容易打满交换机。
小 batch 下通信开销占比高，稀疏计算收益不明显。
跨机架部署时，东西向流量变大，尾延迟更难控制。

部署建议：

尽量把频繁互相通信的 expert 放在网络距离近的 GPU / 节点内。
关注 expert load balance，不只看平均吞吐。
单独测试 all-to-all，而不是只跑 all-reduce。
在线推理时同时看 TTFT、TPOT、P95 / P99 和 GPU 利用率。

6. 推理集群的网络重点

在线推理集群和训练集群的网络重点不同。很多推理服务并不需要把单个请求跨节点切分，而是用多副本承载并发。

典型架构：

Client
  -> API Gateway / Load Balancer
  -> Router / Scheduler
  -> Model Workers
  -> Logs / Metrics / Storage

推理集群关注：

环节	网络影响
请求入口	API 网关、鉴权、限流、负载均衡会影响排队延迟。
调度层	是否把请求发到有足够 KV Cache 和空闲 batch slot 的 worker。
Worker 间通信	跨节点 TP / PP / disaggregated serving 会引入额外延迟。
模型分发	权重从对象存储、镜像仓库或共享盘加载会影响冷启动。
观测链路	日志和 metrics 过重可能反向影响业务网络。

常见建议：

单卡或单机能放下模型时，优先用多副本扩展吞吐。
跨节点切分模型前，先确认收益大于网络开销。
大模型冷启动要规划模型缓存、镜像分层和本地 NVMe。
负载均衡不要只看请求数，还要看当前 batch、KV Cache、上下文长度和输出长度。
推理网络要关注 P95 / P99，而不是只看平均延迟。

7. 集群拓扑和调度

同样数量的 GPU，放在不同拓扑下，性能可能差很多。

常见层次：

GPU
  -> 单机 PCIe / NVLink / NVSwitch
  -> 网卡
  -> ToR 交换机
  -> Spine / Core 交换机
  -> 其他机架或其他集群区域

调度系统需要尽量理解这些距离：

同一台机器内的 GPU 通信最快。
同一机架通常比跨机架更稳定。
同一叶子交换机下通常比跨 spine 更近。
跨可用区或跨数据中心不适合做紧耦合训练通信。

实践建议：

训练任务尽量整组调度到网络距离近的节点。
同一个 TP / EP group 尽量不要跨远距离链路。
对多租户集群，要限制嘈杂邻居对训练流量的影响。
记录每个任务使用的节点、机架、交换机路径和性能指标，便于复盘。

8. 存储、镜像和网络不要分开看

很多“网络慢”的问题其实来自存储和分发链路。

常见场景：

数十台 worker 同时从对象存储拉取几百 GB 权重。
容器镜像过大，扩容时镜像仓库被打满。
网络盘带宽不足，导致模型加载慢或推理抖动。
日志、checkpoint、训练数据和业务请求共用同一网络。

建议：

热模型放本地 NVMe 或节点级缓存。
大模型镜像避免频繁整体重拉。
checkpoint 写入和训练通信尽量做流量隔离。
对象存储、共享文件系统和业务网络都要有带宽预算。
扩容压测要模拟同时拉模型，而不是只测单节点启动。

9. 排障与压测

多机网络问题要靠分层排查，不能只看应用日志。

9.1 基础连通性

ping <peer-host>
ip addr
ip route
ethtool <nic>

关注：

网卡是否协商到预期速率。
MTU 是否端到端一致。
路由是否走了预期网卡。
是否有错误包、丢包、重传。

9.2 GPU 与网卡拓扑

nvidia-smi topo -m
nvidia-smi topo -p2p r
lspci -tv
numactl --hardware

关注：

网卡是否靠近参与通信的 GPU。
GPU 到网卡是否跨 CPU socket。
是否支持 GPUDirect RDMA。
任务是否被调度到了拓扑不合理的节点组合。

9.3 NCCL 压测

all_reduce_perf -b 8 -e 8G -f 2 -g 8
all_gather_perf -b 8 -e 8G -f 2 -g 8
alltoall_perf -b 8 -e 8G -f 2 -g 8

建议记录：

GPU 型号、数量和拓扑。
网卡型号、端口速率和协议。
驱动、CUDA、NCCL、框架版本。
单机 / 多机节点数。
all-reduce、all-gather、all-to-all 的实测结果。
交换机配置、PFC / ECN / MTU。
训练 step time、GPU 利用率和错误日志。

9.4 推理压测

推理压测不要只看 QPS，还要记录：

TTFT：首 token 延迟。
TPOT：每输出 token 延迟。
P50 / P95 / P99。
输入 token 长度和输出 token 长度分布。
并发数、batch 策略和队列等待时间。
worker 的 GPU 利用率、显存占用和 KV Cache 使用情况。
是否发生跨节点模型切分或远程调度。

10. 选型建议

场景	网络建议
本地实验 / 小规模推理	普通 Ethernet 即可，重点是稳定和易运维。
多副本在线推理	Ethernet + 负载均衡 + 本地模型缓存，优先控制 P95 / P99。
单机多卡推理	重点仍是 PCIe / NVLink / NVSwitch，网络主要负责入口和分发。
多机数据并行训练	关注 RDMA、all-reduce / reduce-scatter 和 NCCL 实测。
跨节点 tensor parallel	需要非常谨慎，优先低延迟高带宽网络并严格压测。
MoE 训练 / 推理	重点压测 all-to-all，关注拥塞和 expert 负载均衡。
自建大规模集群	网络、存储、调度、监控要一起设计，不要只采购 GPU。

采购或租用集群前，可以问这些问题：

任务主要是训练、推理，还是混合负载？
通信主要是 all-reduce、all-gather、all-to-all，还是普通请求转发？
单个请求是否需要跨节点模型并行？
网络是普通 Ethernet、RoCE 还是 InfiniBand？
是否支持 RDMA 和 GPUDirect RDMA？
网卡和 GPU 的 PCIe / NUMA 拓扑是否合理？
交换机是否支持并正确配置 PFC、ECN、MTU 和 QoS？
是否用 NCCL tests 和真实模型做过多节点压测？
模型权重、checkpoint、日志和业务请求是否会互相抢带宽？
调度系统是否能感知机架、节点、GPU 和网卡拓扑？

11. 常见误区

只看网卡速率：400G 网卡不代表端到端就有 400G 有效吞吐。
能 ping 通就认为网络没问题：训练通信需要低延迟、高带宽和低拥塞，普通连通性测试远远不够。
把训练、存储、日志混在一张网里：高峰期容易互相影响，导致训练抖动或推理尾延迟升高。
跨节点 TP 随便开：TP 每层都通信，网络不够强时可能比少卡更慢。
RoCE 只配网卡不配交换机：PFC、ECN、MTU、QoS 不一致时，性能会非常不稳定。
只测 all-reduce：MoE 和 expert parallel 还必须看 all-to-all。
忽略调度距离：同样 8 台机器，放在同机架和跨多机架，训练表现可能完全不同。

12. 总结

多机集群网络的核心不是“带宽越大越好”，而是网络能力要匹配任务通信模式。

训练 / 推理目标
  -> 并行策略
  -> 通信模式
  -> 网络协议和拓扑
  -> 压测结果
  -> 集群调度和运维策略

对大模型工程来说，网络、GPU、存储和调度必须一起看。
真正可靠的判断方式是：先明确通信模式，再用 NCCL tests 和真实模型压测，最后结合 P95 / P99、GPU 利用率、错误日志和扩缩容表现决定方案。

1. 为什么大模型集群需要关注网络​

2. 带宽、延迟和拥塞​

3. Ethernet、InfiniBand 和 RDMA​

3.1 Ethernet​

3.2 InfiniBand​

3.3 RDMA​

3.4 RoCE​

4. 训练通信看什么​

5. MoE 为什么特别吃网络​

6. 推理集群的网络重点​

7. 集群拓扑和调度​

8. 存储、镜像和网络不要分开看​

9. 排障与压测​

9.1 基础连通性​

9.2 GPU 与网卡拓扑​

9.3 NCCL 压测​

9.4 推理压测​

10. 选型建议​

11. 常见误区​

12. 总结​

13. 参考​