单机多卡时，GPU 之间走 NVLink 或 PCIe Switch，速度快、延迟低，几乎不用操心。一旦模型大到单机放不下，或者要扩到多机多卡，通信就要「过网线」——问题随之而来：

• vLLM 张量并行（TP）：一层矩阵切到多张卡，每步计算都要做跨卡通信
• 流水线并行（PP）：相邻阶段之间持续传递中间结果
• 专家并行（EP）：DeepSeek 这类 MoE 模型，token 要在不同专家所在的卡之间路由
• SGLang PD 分离：prefill 节点算完要把 KV Cache 传给 decode 节点，网络吞吐直接决定这套架构的收益

很多人搭集群时把精力全花在驱动和 CUDA 上，直到第一次跑多机分布式才发现：训练损失在降，但每个 batch 的耗时比单机还慢，GPU 利用率不到 20%。罪魁祸首就是跨节点通信。

本文把 vLLM/SGLang 在 Kubernetes 里的网络配置拆成五个组件一次讲清：Calico（打底）、Multus-CNI（多网卡）、MacVlan（低延迟网卡）、NCCL（通信总开关）、RoCE/RDMA（跨机终极形态）。

一、网络分层全景：三类流量分开走

生产环境的正确做法是「流量分流」，一张网卡干一件事：

流量类型	承载网络	说明
管理 / 控制流量	Calico（默认 CNI）	API Server、健康检查、监控、镜像拉取
业务 / 服务流量	Calico + Service / Ingress	对外的推理请求入口
高性能通信流量	MacVlan / SR-IOV / RoCE	GPU 间 all-reduce、KV Cache 传输、参数同步

核心原则：把 GPU 通信流量从 Overlay 网络里「捞出来」，走一条低延迟、高吞吐、尽量无损的专用链路。

二、Calico：默认 CNI 打底

Calico 的角色是「地基」——负责 Pod 的基础网络、IP 分配（IPAM）和网络策略（NetworkPolicy）。

• Calico 默认走 BGP 或 IPIP/VXLAN Overlay，配置简单、生态成熟
• 但对 NCCL 这种「微秒级敏感、GB 级吞吐」的通信，Overlay 的封装/解封装开销和不稳定抖动就是性能杀手
• 所以 Calico 通常只承载管理面和业务面，高性能通信面要另起炉灶——这正是引入 Multus 的原因

一句话：Calico 管「通」，RoCE/MacVlan 管「快」，两者通过 Multus 共存于同一个 Pod。

三、Multus-CNI：给 Pod 挂第二张网卡

Kubernetes 原生不支持多网卡，Multus-CNI 是事实标准。

原理

Multus 是一个 meta-plugin（元插件），通过 CRD NetworkAttachmentDefinition 定义「附加网络」，在 Pod 启动时把多个 CNI 插件串起来执行：先调主 CNI（Calico）建默认网卡，再调附加 CNI 建第二、第三张网卡。

安装前提

• Kubernetes ≥ 1.16（推荐 1.20+）
• 已配置默认 CNI（Calico / Flannel）
• 节点至少两个可用网络接口

创建附加网络

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: macvlan-conf
spec:
  config: '{
    "cniVersion": "0.3.1",
    "type": "macvlan",
    "master": "eth1",
    "mode": "bridge",
    "ipam": {
      "type": "host-local",
      "subnet": "192.168.1.0/24",
      "rangeStart": "192.168.1.200",
      "rangeEnd": "192.168.1.250",
      "gateway": "192.168.1.1"
    }
  }'

Pod 侧挂载

metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-conf

Pod 启动后就会多出一张挂在 eth1 上的网卡，与默认 Calico 网络互不干扰。

四、MacVlan：接近裸机的低延迟网卡

MacVlan 把 Pod 的虚拟网卡「直接钉」到物理网卡上，Pod 拥有独立的 MAC 地址，直接接入物理二层网络：

• 性能接近裸机，没有 Overlay 封装开销
• 配置简单，不需要交换机特殊支持
• 但没有 RDMA 能力——适合「对延迟敏感、但吞吐要求没那么极端」的场景，或作为 RoCE 的前置过渡方案

MacVlan 的局限也很明确：bridge 模式下同一张物理网卡上的容器之间默认无法直接互通（需要 macvlan 模式或交换机 hairpin）；多租户隔离弱；无法提供无损网络保障。所以真正的高性能通信，还是要落到 RoCE。

五、NCCL：分布式通信的「总开关」

NCCL（NVIDIA Collective Communications Library）是 vLLM/SGLang 底层跨卡、跨机通信的默认库，Tensor 并行、流水线并行最终都走它。

transport 层三类物理链路

• NVLink / PCIe：单机卡间通信，最快，无需配置
• IB / RoCE：跨机通信首选，走 RDMA
• TCP Socket：兜底方案，性能最差

关键环境变量

# 指定通信使用的网卡（多网卡环境必配，选延迟最低那条）
export NCCL_SOCKET_IFNAME=eth1
export GLOO_SOCKET_IFNAME=eth1

# 启用 / 禁用 IB、RoCE（环境不支持 RDMA 时置 1 强制走 TCP）
export NCCL_IB_DISABLE=0

# RoCEv2 通常需要指定 GID Index（常见值为 3，需按环境确认）
export NCCL_IB_GID_INDEX=3

# 排障时打开调试日志
export NCCL_DEBUG=INFO

三个高频坑

1. 网卡名不一致：容器内网卡名可能与宿主机不同，NCCL_SOCKET_IFNAME 要写容器内实际看到的名字
2. 端口不通：NCCL 默认使用 20000～60000 端口段，云环境安全组、集群 NetworkPolicy 必须放行
3. 多网卡选错路径：机器上同时有管理网和 RDMA 网时，不显式指定 NCCL_SOCKET_IFNAME 可能自动选到慢链路

六、RoCE + RDMA：跨机通信的终极形态

RoCEv2 是什么

RoCEv2（RDMA over Converged Ethernet v2）把 RDMA 的低时延、低 CPU 开销搬到了标准以太网 + IP 之上，配合 PFC、ECN、DCQCN 三大机制构建「无损网络」，是千卡乃至万卡级集群的主流互联方案。

性能排序：IB > RoCE > 普通以太网。RoCE 性能可非常接近 IB，且能复用现有以太网设施，性价比更高——但它的高性能是「调」出来的，对配置一致性要求严苛。

为什么 RoCE 这么「脆弱」

RoCE 依赖底层无损以太网，一旦发生哪怕微小的丢包，就会触发重传风暴、RDMA 连接断开（QP Error）。所以要做三件事：

• PFC（优先级流控）：给 RDMA 流量划定优先级队列，拥塞时「按优先级暂停」而非整链路暂停
• ECN（显式拥塞通知）：让端点提前感知拥塞、主动降速
• DCQCN：端到端的拥塞控制算法，把 PFC 和 ECN 协同起来

在 Kubernetes 里暴露 RDMA 给 Pod

容器默认拿不到 RDMA 设备，需要 device plugin 或专用 CNI：

• NVIDIA Network Operator（原 Mellanox network-operator）：一键部署 OFED 驱动、RDMA shared device plugin、SR-IOV device plugin、nv-ipam-cni，是把 RoCE 搬进 K8s 最省心的方案
• RDMA shared device plugin：把节点的 RDMA 设备共享给 Pod
• SR-IOV device plugin：把物理网卡虚拟成多个 VF 分给 Pod，隔离性更好

配合 GPUDirect RDMA，GPU 可以直接通过网卡访问对端 GPU 显存，彻底绕过 CPU 和主机内存，是高性能推理网络的最后一块拼图。

七、vLLM/SGLang 落地清单

vLLM 多机多卡

vllm serve /models/Qwen-72B \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 2

--tensor-parallel-size 决定模型切到几张卡，vLLM 会自动用 NCCL 处理跨卡通信。多机部署时，把上面的 NCCL 环境变量注入容器即可。

SGLang PD 分离的网络要求

SGLang 的 prefill 与 decode 分离后，两者之间的 KV Cache 传输是实打实的网络吞吐需求，建议：

• 让 P 实例和 D 实例走同一张高速网卡（MacVlan 或 RoCE）
• 显式指定 NCCL_SOCKET_IFNAME 到 RDMA 网卡
• 监控 P → D 之间的带宽，避免它成为比 GPU 计算更早到的瓶颈

一个多网卡 vLLM Deployment 骨架

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-server
spec:
  replicas: 1
  selector:
    matchLabels: { app: vllm-server }
  template:
    metadata:
      labels: { app: vllm-server }
      annotations:
        k8s.v1.cni.cncf.io/networks: macvlan-conf
    spec:
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args: ["--model", "/models/Qwen-72B", "--tensor-parallel-size", "4"]
          env:
            - name: NCCL_SOCKET_IFNAME
              value: "net1"           # Multus 附加网卡在容器内的名字
            - name: NCCL_IB_DISABLE
              value: "0"
          resources:
            limits:
              nvidia.com/gpu: 4

八、踩坑清单与排障

1. GPU 利用率长期低于 60%，网络收发打在高位：典型的通信瓶颈，先查网卡和 NCCL 配置
2. NCCL_IB_GID_INDEX 配错：RoCEv2 环境通信建立失败，用 ibv_devices、show_gids 确认正确 GID
3. Multus 附加网卡没起来：kubectl describe pod 看 events，多数是 master 网卡名写错或 IPAM 段耗尽
4. MacVlan 同机互 ping 不通：bridge 模式的已知限制，改用 SR-IOV 或 RoCE，或开启 hairpin
5. 端口被安全组拦截：云环境务必放行 NCCL 的 20000～60000 端口段

九、总结

大模型推理的网络配置，本质是一道「分流 + 提速」的组合题：

1. Calico 打底：管理面和业务面流量走默认 CNI，够用且稳定
2. Multus 开多网卡：让一个 Pod 同时拥有普通网卡和高速网卡
3. MacVlan / RoCE 提速：高性能通信流量绕开 Overlay，走低延迟专用链路
4. NCCL 是总开关：NCCL_SOCKET_IFNAME、NCCL_IB_DISABLE、NCCL_IB_GID_INDEX 三个变量基本决定通信成败
5. RoCE 要配无损网络：PFC + ECN + DCQCN 缺一不可，否则丢包即断连

最后补一句大实话：如果你的业务还在犹豫「要不要为网络投入这么重」，先问问自己是不是一定要自建多机集群。对于绝大多数应用团队，把模型服务交给云厂商托管（如火山方舟官方 API），网络、RDMA、NCCL 这些脏活累活都由平台消化——你只需要关心 base_url 和业务逻辑。

关于向量云：网络脏活，平台消化

向量云（南京）科技有限公司依托字节跳动火山方舟官方授权，专注大模型应用落地：

向量云能力	说明
官方 API 免部署	火山方舟官方 API 与官方 Key 直连，网络、RDMA、NCCL 由平台消化
独享接入点	缓存与配额不被公共池挤占，高峰不排队
低折扣 Token	专属折扣价，用量越大越划算
缓存隔离降本	上下文缓存红利稳定落袋
计费灵活	按量计费、即用即扣、注册充值 10 元起
协议兼容	OpenAI 兼容协议，业务代码几乎零改动

接入方式：注册后获取官方 API Key，把 base_url 指向向量云接入点即可直接调用火山方舟官方模型。