关键词：多网卡、multi-NIC、RoCE、NCCL、PXN、PCI×NVLink、Rail-aligned、NUMA 亲和、策略路由、bonding、多轨并行、Mooncake Transfer Engine、多网卡聚合、GPUDirect RDMA、400G、800G、向量云

先给结论

上一篇文章讲清了 RoCE 网络的「道路」——无损以太网与组网拓扑；这一篇讲「车道」——一台服务器里的多张网卡如何组队，把通信带宽榨干。

一台 8 卡 GPU 服务器的网络出口是它的生死线：单张 400G 网卡看似很宽，但对 8 卡聚合通信需求来说远远不够。于是主流方案是每 GPU 对应一张网卡，一台 8 卡机插满 8×400G 网卡，单机网络带宽 3.2Tbps（腾讯星脉同款配置）。

但多网卡绝不是「插上去就完事」，三个容易被忽略的事实：

1. NCCL 不会自动聚合多网卡——不加干预，可能大部分流量都挤在一张网卡上，其余 7 张闲置
2. 网卡插错位置等于白插——跨 NUMA 走 QPI/UPI 转发会吃掉大量带宽，必须做好 GPU-NIC 亲和规划
3. 正确的姿势是「多轨独立」而非「链路聚合」——8 张网卡各自独立 IP、各自挂一个 Rail，配合策略路由与 PXN 机制才能线性叠加带宽

搞对之后的效果也很直接：Mooncake Transfer Engine 借助多网卡聚合（最高 8×400Gbps），在 RoCE 网络下实测 KV Cache 传输速度达 190GB/s，驱动了 Kimi K2（1T 参数）在 128 张 H200 上的 PD 分离部署。

一、为什么一张网卡不够用

AllReduce 的带宽账

数据并行的梯度同步时间可以近似为：通信时间 ≈ 数据量 / 有效带宽。8 张卡做一次 AllReduce，每个 step 要搬运的梯度数据动辄 GB 级；模型越大、卡越多，单次同步的数据量越大。

单张 400G 网卡的理论带宽约 50GB/s（单向），扣掉协议开销后更少。当 8 卡聚合通信需求达到数百 GB/s 量级时，单网卡直接成为全机瓶颈——通信占比冲上 40%（训练 profiling 的典型案例）也就不奇怪了。

推理侧的带宽账

PD 分离场景更夸张：一次长上下文的 KV Cache 搬运就是几 GB 到几十 GB，还要满足「不拖慢 TTFT」的低延迟要求。单网卡既吃不下带宽，也扛不住突发。

结论很朴素：网卡数量要和 GPU 数量对齐，1 GPU : 1 NIC 是对等设计的基准线。

二、先看服务器内部拓扑：GPU、网卡、PCIe 与 NUMA

多网卡方案的第一步，是看懂 8 卡服务器的内部骨架（以 DGX/HGX 基板为例）：

三个关键约束

1. PCIe 根复杂度（Root Complex）：每颗 CPU 管理的 PCIe 根下挂哪些 GPU 和网卡，是固定的物理事实。GPU 与它通信的网卡如果不挂同一 PCIe 根，数据就要跨 CPU 走 QPI/UPI，带宽打折、延迟上升
2. NUMA 亲和：GPU 直连内存与网卡直连内存应落在同一 NUMA 域，避免远程内存访问
3. PCIe 带宽匹配：400G 网卡通常需要 PCIe 5.0 x16 插槽，插到低带宽槽位等于自废武功——网卡带宽超过插槽带宽的部分全是浪费

一句话总结：多网卡不是「插得满」，而是「插得对」——每张网卡必须站在自己 GPU 的 PCIe 根与 NUMA 域内。

三、多网卡的三种方案模式

为什么大模型场景普遍放弃 bonding？

LACP 的本质是「把多条链路伪装成一条」，靠哈希把不同流摊到不同成员口。但 AllReduce/KV Cache 大块传输往往是数量少、单流极大的流型：一条流只会被哈希到一张网卡上，永远吃不到第二张卡的带宽。加上哈希不均带来的极化问题，bonding 在 RDMA 集合通信里是典型的「负优化」。

正确姿势：每张网卡独立 IP、独立路由表项，让上层通信库（NCCL / Transfer Engine）显式地把不同的通信对分配到不同的网卡上。

四、NCCL 多网卡通信机制：从「插满」到「用满」

1. NCCL 不会自动聚合——要显式对齐

实践中最常见的坑：8 张网卡都通了，跑 AllReduce 却只跑满一两张。排查顺序应该是 Rail、HCA、拓扑三对齐：

• Rail 对齐：同卡号 GPU 的网卡接同一组交换机（同轨），跨机同类通信一跳直达
• HCA 对齐：用 NCCL_IB_HCA 显式指定参与通信的网卡列表，防止 NCCL 误选
• 拓扑对齐：确认 NCCL 感知到的 GPU-NIC 邻接关系与实际布线一致

2. Channel 分配：不同 GPU 对走不同网卡

NCCL 内部把通信拆成多个 channel，不同 GPU 对之间的流量分配到不同 NIC 上。拓扑对齐后，每张网卡各司其职，总带宽随网卡数量线性增长。

3. PXN（PCI×NVLink）：让数据「借道 NVLink」出网

跨 NUMA 是 NCCL 多网卡场景的头号性能杀手。PXN 机制的核心思路：数据先通过 NVSwitch 全互联转发到目标网卡同轨的 GPU，再从那张 GPU 对应的网卡出去。全程 GPU 直连转发，规避 CPU 内存拷贝与跨 NUMA 的 QPI/UPI 转发瓶颈，最大化每张网卡的满带宽利用率。

4. 多出口的策略路由

8 张网卡意味着 8 个独立网络出口。为避免回包走错出口导致通信失败，服务器需要配置 Linux 多路由表 + 策略路由：按源 IP/网卡把流量锁定在各自 Rail 平面内——这与传统云网的配置方式完全不同，是智算网络运维的基本功。

五、推理侧的多网卡：Transfer Engine 的多网卡聚合

训练看 NCCL，推理看传输引擎。PD 分离的 KV Cache 搬运是推理网络最大的流量，Mooncake Transfer Engine 把多网卡用到了极致：

真实案例：MooncakeConnector 基于 Transfer Engine 的多网卡 RDMA 聚合带宽，驱动了 Kimi K2（1T 参数）在 128 张 H200 上的 PD 分离部署——这是多网卡方案在超大规模推理上的实战背书。

六、业界实践与带宽演进

1. 业界的多网卡共识

• 腾讯星脉：8 卡服务器插 8 块 400G 网卡，单机带宽 3.2Tbps，配合多轨道组网
• DeepSeek 私有化部署经验：以 GPU 卡（而非服务器）为单位的通信模式下，服务器 8 张网卡各自位于轨道平面，必须用 Linux 多路由表和策略路由规划出口，否则回包通信失败
• NVIDIA 生态：NCCL 的 PXN 优化、NVIDIA Dynamo/NIXL 的多 NIC 传输，都在把「每 GPU 一 NIC」的对等设计推向标准化

2. 带宽演进路线

演进的核心约束始终是那句老话：网卡带宽、PCIe 带宽、交换机端口速率三者必须同步升级，任何一环掉队都会卡住整机通信。

七、多网卡部署设计要点（八条）

1. 1 GPU : 1 NIC 对等映射：网卡数量与 GPU 数量对齐，每张网卡绑定专属 GPU，基准线不妥协
2. NUMA 与 PCIe 根亲和：GPU 与对应网卡同 NUMA、同 PCIe 根，杜绝跨 CPU 的 QPI/UPI 转发
3. 插槽带宽匹配：400G 网卡用足 PCIe 5.0 x16，验收时用 lspci/拓扑工具核对每张网卡的实测带宽
4. 放弃 bonding，走多轨独立：每 NIC 独立 IP + 独立 Rail，上层库显式分配通信对
5. Rail 对齐 + HCA 显式指定：同卡号同轨布线，NCCL_IB_HCA 锁定网卡列表，杜绝「插满跑不满」
6. 策略路由规划出口：Linux 多路由表 + 策略路由，回包锁定各自 Rail 平面，防止串轨
7. 开启 PXN 等转发优化：用 NVSwitch 直连转发规避跨 NUMA 瓶颈，最大化每卡带宽利用率
8. 每网卡独立监控 + 容错：逐 NIC 监控利用率、ECN 标记率与错误计数，识别负载不均衡；推理侧启用 Transfer Engine 的多网卡路径切换，单卡故障不中断服务

八、写在最后

多网卡架构的真相是：带宽是物理的，利用率是设计的。插满 8 张 400G 网卡只是开始，把 3.2Tbps 的每一分带宽都变成通信能力，靠的是拓扑对齐、NUMA 亲和、多轨独立与 PXN 这一整套组合拳——差一步，钱就白花了。

关于向量云：不必亲手调 8 张网卡，也能拿到高效推理

多网卡的隐性成本极高：PCIe 根规划、NUMA 亲和、策略路由、HCA 对齐、逐卡调优，每一项都是资深 Infra 工程师的活。对绝大多数应用团队来说，自己攒 8×400G 的推理节点既不经济也不必要。向量云（向量云南京科技有限公司）依托字节跳动火山方舟官方授权，把「多网卡 + RoCE 网络 + GPU 算力 + 调度」全部打包成开箱即用的推理服务：

接入方式：注册后获取官方 API Key，把 base_url 指向向量云接入点即可直接调用火山方舟官方模型——网卡拓扑的复杂性交给平台，稳定性和成本优势留给你的业务。

获取 API Key：https://ark.tokenrize.cn/