1. 课程定位与整体设计思路拆解1.1 为什么传统计算机网络课程必须动刀我教了几年计算机网络也参与过几轮课程大纲的修订最直观的感受就是学生越来越难被“协议分层”这四个字打动。以前讲OSI七层模型学生还会认真记笔记现在他们更关心的是——这些协议跟我用的大模型有什么关系我训练一个模型网络到底在哪个环节拖了我的后腿这个项目标题“面向生成式人工智能的计算机网络课程建设”核心要解决的就是这个断层。传统计算机网络课程的知识体系是围绕“端到端通信”建立的从物理层的信号编码到应用层的HTTP、DNS整条链路非常完整。但生成式AI带来的负载特征完全不一样大模型训练需要的是高带宽、低延迟、无损的RDMA网络推理服务需要的是高并发、弹性伸缩的容器网络分布式训练还涉及集合通信库在底层对网络拓扑的极致压榨。如果课程还是只讲TCP三次握手、滑动窗口、CSMA/CD学生学完之后面对一个真实的GPU集群网络问题根本无从下手。所以这个课程建设的第一个设计决策就是保留经典网络原理的骨架但把血肉换成生成式AI场景下的真实问题。具体来说我做了这样的取舍物理层和数据链路层的内容压缩到原来的60%但增加了“数据中心网络拓扑与布线”的模块网络层保留IP路由的核心逻辑但把重点从“互联网路由协议”转向“集群内路由与拥塞控制”传输层是重头戏TCP要讲但更要讲RDMA over Converged Ethernet和InfiniBand的传输机制应用层则直接对接gRPC、NCCL通信、参数服务器等实际框架。这个取舍背后的逻辑很简单学生毕业后如果去搞AI基础设施他每天面对的不是“为什么我的网页打不开”而是“为什么我的AllReduce操作延迟突然飙升”。课程必须让他有能力回答后一个问题。1.2 课程模块的划分与学时分配整个课程我设计成六个模块总学时48小时其中理论32小时实验16小时。这个比例是经过两轮试讲后调整出来的第一轮理论给了40小时结果学生反馈“听懂了但不会做”所以第二轮大幅增加了实验比重。模块核心内容理论学时实验学时网络基础与AI负载特征分层模型、带宽延迟积、AI训练/推理流量模式62数据中心网络叶脊架构、RDMA、无损网络、拥塞控制84分布式通信与集合操作NCCL、MPI、AllReduce、参数服务器64容器与编排网络CNI、Overlay、Service Mesh、K8s网络62网络性能调优抓包分析、带宽测试、延迟测量、瓶颈定位44前沿专题在网计算、可编程交换机、光互连20这个表格里的学时分配不是拍脑袋定的。数据中心网络给了84是因为这是生成式AI最吃网络的部分也是学生最容易踩坑的地方。分布式通信给了64因为集合操作的性能直接决定训练效率而且这部分内容在传统课程里几乎不涉及。容器网络给了62因为现在推理服务基本都跑在K8s上不懂CNI和Overlay连服务发现都搞不定。注意实验学时的分配要留出至少2小时的“自由排障”时间不要把所有实验都设计成按步骤操作。真实网络问题从来不是按步骤出现的让学生自己面对一个“训练任务卡住了”的场景比让他照着文档配一遍RDMA更有价值。1.3 与生成式AI工作流的对接点课程建设的另一个核心思路是每一个网络知识点都要找到一个生成式AI工作流中的锚点。没有锚点的知识点要么删掉要么压缩成背景阅读材料。举个例子讲TCP拥塞控制的时候传统讲法是慢启动、拥塞避免、快重传、快恢复。我在课上会先放一段真实训练任务的网络监控图让学生看到当多个GPU节点同时进行AllReduce时TCP的拥塞窗口波动会导致集合通信时间抖动进而拖慢整个训练步。然后我再讲为什么RDMA的基于信用的流控能解决这个问题。这样学生就明白了不是TCP不好而是场景变了需求变了。再比如讲DNS传统讲法是递归查询、迭代查询、缓存机制。我会把它接到“推理服务的服务发现”上当一个推理请求到达网关网关需要把请求路由到某个模型实例这个过程中服务注册与发现机制是怎么工作的DNS在容器环境里扮演什么角色CoreDNS的性能瓶颈在哪里。这样DNS就不再是一个孤立的协议而是推理链路的一环。这种对接方式的好处是学生学完之后脑子里有一张“AI系统网络全景图”而不是一堆散落的协议知识点。他遇到一个新问题知道该从哪个层面去排查该用哪个工具去验证。2. 核心细节解析与实操要点2.1 数据中心网络拓扑的讲法与实验设计叶脊架构是数据中心网络的基础但很多教材讲得太抽象。我的做法是先用一个生活化类比叶脊架构就像一个大城市的交通网络叶交换机是各个小区门口的道路脊交换机是城市主干道。小区内部的车流不会直接上主干道而是先汇聚到叶交换机再根据目的地选择走哪条脊交换机。这样任何两个小区之间的通信最多只需要经过三跳。讲完类比之后我会带学生做一个纸面设计练习假设有一个64节点的GPU集群每个节点需要200Gbps的带宽要求任意两个节点之间的通信延迟不超过10微秒请设计一个叶脊拓扑并计算需要多少台叶交换机、多少台脊交换机、多少条上行链路。这个练习的答案不是唯一的但有一个合理的计算过程。假设每台叶交换机有32个200Gbps下行端口和8个400Gbps上行端口那么一台叶交换机可以连接32个节点。64个节点需要2台叶交换机。每台叶交换机有8条400Gbps上行链路总上行带宽是3.2Tbps。如果脊交换机有32个400Gbps端口那么一台脊交换机可以连接4台叶交换机因为每台叶交换机占用8个端口。为了冗余至少需要2台脊交换机。所以最终方案是2台叶交换机、2台脊交换机每台叶交换机用4条上行链路分别连接到2台脊交换机。这个计算过程我会让学生在课上自己推一遍然后我再讲实际部署中还要考虑的问题比如线缆长度限制、光模块兼容性、供电和散热、以及最关键的——收敛比。收敛比是下行总带宽与上行总带宽的比值这个比值决定了网络在突发流量下的表现。对于AI训练集群收敛比通常要做到1:1或者接近1:1因为AllReduce操作会产生大量的突发流量。实验环节我设计了一个基于开源工具的拓扑模拟用容器模拟交换机和主机用Linux的流量控制工具模拟链路带宽和延迟然后让学生用iperf3和ping测试不同拓扑下的吞吐和延迟。这个实验不需要真实的交换机但能让学生直观感受到拓扑对性能的影响。实操心得在模拟实验里一定要让学生手动设置MTU。默认的1500字节MTU在RDMA场景下会导致大量的分片性能直接腰斩。把MTU调到9000巨帧之后同样的流量模式吞吐能提升30%以上。这个对比实验学生做一次就记住了。2.2 RDMA与无损网络的原理拆解RDMA是生成式AI网络里绕不开的技术但也是最难讲清楚的技术之一。我的讲法是先从问题出发为什么TCP在AI训练场景下不够用核心原因是TCP的内核协议栈处理开销太大。每一次数据包的处理都要经过内核态到用户态的拷贝还要经过中断处理、协议解析、拥塞控制等环节。在100Gbps以上的带宽下CPU根本来不及处理这么多包大量的时间花在了协议栈上而不是真正的数据传输上。RDMA的思路是把网络协议栈的处理卸载到网卡上数据直接从一台机器的用户态内存传输到另一台机器的用户态内存完全不经过CPU和内核。这就像从“快递员把包裹送到小区门口你自己下楼去取”变成了“快递员直接把包裹放进你家冰箱”。但RDMA要跑在以太网上就面临一个根本矛盾以太网天生是有损的而RDMA假设网络是无损的。解决这个矛盾的技术就叫RoCERDMA over Converged Ethernet。RoCEv2通过UDP封装RDMA数据包然后在网络层实现基于优先级的流控PFC和显式拥塞通知ECN。PFC的原理是当交换机的一个端口缓冲区快满的时候它向上一跳发送一个暂停帧告诉对方“先别发了等我缓一缓”。这个机制能保证不丢包但有个副作用——队头阻塞。如果暂停帧发得太频繁整个链路都会被拖慢。所以PFC的阈值设置非常关键设得太低会频繁暂停设得太高会丢包。ECN则是另一种思路交换机在缓冲区快满的时候不是暂停发送而是在数据包里打一个标记接收方收到标记后通知发送方降速。这种方式更平滑但需要端侧协议栈的支持。我在课上会用一个表格来对比这两种机制机制触发条件动作优点缺点PFC缓冲区超过阈值发送暂停帧保证不丢包可能队头阻塞ECN缓冲区超过阈值标记数据包平滑降速需要端侧支持实验环节我设计了一个RoCE配置实验用两台服务器各插一张支持RoCE的网卡通过一台支持PFC和ECN的交换机连接。然后让学生分别配置PFC和ECN用perftest工具测试RDMA的带宽和延迟对比两种机制下的性能差异。这个实验的难点在于网卡和交换机的配置。不同厂商的网卡配置命令不一样交换机更是各家有各家的语法。我的建议是实验环境尽量统一用同一品牌的设备减少兼容性问题。如果条件有限可以用软RoCESoft-RoCE来模拟虽然性能差很多但原理和配置流程是一样的。注意配置PFC的时候一定要确认整个链路上的所有设备都支持并正确配置了PFC。只要有一个环节没配PFC就不会生效而且不会报错只是性能上不去。这个坑我踩过好几次排查起来非常费时间。2.3 集合通信与NCCL的实操解析集合通信是分布式训练的核心NCCL是NVIDIA的集合通信库也是目前用得最广泛的。但很多学生只知道NCCL快不知道它为什么快更不知道什么时候会慢。NCCL的核心优化在于它能够根据网络拓扑自动选择最优的通信算法。比如AllReduce操作NCCL会根据节点数量、GPU数量、网络带宽和延迟在Ring、Tree、CollNet等算法之间做选择。Ring算法适合节点数较少、带宽均匀的场景Tree算法适合节点数多、带宽不均匀的场景CollNet则是利用交换机或在网计算能力来加速。我在课上会让学生做一个实验用4台服务器每台4张GPU总共16张GPU跑一个AllReduce操作。然后分别用NCCL的Ring算法和Tree算法测量不同消息大小下的通信时间。学生会发现小消息下Tree更快大消息下Ring更快。这个结论和NCCL的自动选择逻辑是一致的。实验的具体步骤是这样的# 设置NCCL使用的算法 export NCCL_ALGORing # 或者 export NCCL_ALGOTree # 运行AllReduce测试 ./all_reduce_perf -b 8 -e 128M -f 2 -g 4这个命令会从8字节开始每次翻倍一直测到128MB测量不同消息大小下的通信带宽和延迟。学生会看到一条曲线小消息下延迟主导大消息下带宽主导。然后我会让他们把NCCL_ALGO改成Tree再跑一遍对比两条曲线的差异。这个实验的价值在于它让学生直观理解了“算法选择不是拍脑袋而是有数据支撑的”。以后他们在实际工作中遇到通信瓶颈就知道该从哪里入手去调优。实操心得NCCL的日志非常有用。设置NCCL_DEBUGINFO之后NCCL会打印出它选择的算法、使用的通道数、以及每个通道的带宽。这些信息是排查通信问题的第一手资料。我建议学生在跑任何分布式训练任务之前都先开NCCL_DEBUGINFO跑一遍小规模的测试确认通信路径是符合预期的。2.4 容器网络与推理服务的对接生成式AI的推理服务现在基本都跑在Kubernetes上这就涉及容器网络的问题。传统网络课程不讲容器网络但学生如果不懂CNI、Overlay、Service Mesh连一个推理服务都部署不起来。容器网络的核心问题是容器需要有自己的IP地址需要能够跨节点通信需要能够被服务发现机制找到。Kubernetes通过CNI插件来解决第一个问题通过Overlay网络来解决第二个问题通过Service和Ingress来解决第三个问题。我在课上会重点讲三种CNI插件的区别Calico、Flannel、Cilium。Calico基于BGP路由性能好但配置复杂Flannel基于VXLAN Overlay配置简单但有封装开销Cilium基于eBPF性能最好但需要较新的内核版本。CNI插件实现方式性能配置复杂度适用场景CalicoBGP路由高中大规模集群FlannelVXLAN Overlay中低中小规模集群CiliumeBPF最高高性能敏感场景实验环节我设计了一个对比实验在同一个K8s集群里分别用Flannel和Calico部署两个推理服务然后用wrk或者hey工具压测对比两种CNI下的吞吐和延迟。学生会发现Calico的延迟明显低于Flannel因为Flannel的VXLAN封装会增加额外的头部开销而且封包解包会消耗CPU。这个实验的另一个目的是让学生理解网络性能不是孤立的它和CPU、内存、存储都有关系。Flannel的封装开销最终会体现在CPU使用率上如果CPU本身就很紧张网络性能会进一步下降。注意在生产环境里CNI插件的选择往往不是单纯看性能还要考虑运维成本、社区活跃度、与现有监控体系的兼容性。Calico虽然性能好但BGP的运维门槛不低Cilium虽然性能最好但对内核版本有要求老旧的K8s集群可能跑不起来。这些取舍在课上要讲清楚不能只讲技术不讲工程。3. 实操过程与核心环节实现3.1 实验环境搭建的完整流程整个课程的实验环境我设计成两层一层是本地虚拟机环境用于基础实验一层是远程GPU集群环境用于分布式通信实验。本地环境用Vagrant加VirtualBox搭建远程环境用容器化的方式模拟。本地环境的搭建步骤如下# 初始化Vagrant环境 vagrant init ubuntu/focal64 vagrant up # 登录虚拟机 vagrant ssh # 安装基础工具 sudo apt update sudo apt install -y iproute2 tcpdump iperf3 net-tools # 配置网络命名空间模拟多主机 sudo ip netns add host1 sudo ip netns add host2 sudo ip link add veth1 type veth peer name veth2 sudo ip link set veth1 netns host1 sudo ip link set veth2 netns host2这个环境可以模拟两台主机之间的通信学生可以在里面做TCP拥塞控制、路由配置、抓包分析等实验。网络命名空间的好处是隔离性好一台机器上可以模拟出多台主机的效果而且不会影响宿主机的网络配置。远程GPU集群环境我用的是容器化的方案用Docker容器模拟GPU节点用NCCL的容器镜像来跑集合通信测试。这个方案的好处是不需要真实的GPU用CPU也能跑通NCCL的通信逻辑只是性能数据没有参考价值。但对于理解通信算法和排查配置问题来说已经足够了。# 拉取NCCL测试镜像 docker pull nvcr.io/nvidia/pytorch:23.10-py3 # 启动两个容器模拟两个节点 docker run -d --name node1 --network host nvcr.io/nvidia/pytorch:23.10-py3 docker run -d --name node2 --network host nvcr.io/nvidia/pytorch:23.10-py3 # 在容器内运行AllReduce测试 docker exec -it node1 bash # 在容器内执行 ./all_reduce_perf -b 8 -e 128M -f 2 -g 1这个实验的关键是让两个容器能够互相通信。用host网络模式是最简单的但会占用宿主机的端口。如果要做更真实的模拟可以用自定义的Docker网络然后配置静态IP和路由。实操心得在容器里跑NCCL测试的时候一定要设置NCCL_SOCKET_IFNAME环境变量指定使用哪个网络接口。如果不设置NCCL可能会选错接口导致通信失败或者性能极差。这个坑我踩过排查了半天才发现是接口选错了。3.2 网络性能测试与瓶颈定位网络性能测试是课程里最实用的部分。我教学生用三个工具iperf3测带宽ping和hping3测延迟tcpdump和Wireshark抓包分析。iperf3的用法很简单但参数选择有讲究# 服务端 iperf3 -s # 客户端测试TCP带宽 iperf3 -c 192.168.1.100 -t 30 -P 4 # 客户端测试UDP带宽和丢包 iperf3 -c 192.168.1.100 -u -b 1G -t 30这里的-P 4表示用4个并行连接。为什么要用并行连接因为单个TCP连接的带宽往往受限于拥塞窗口和往返延迟达不到链路的物理带宽。用多个连接可以绕过这个限制更准确地测量链路的最大吞吐。UDP测试则用来测量丢包率。在RDMA场景下丢包是致命的因为RDMA假设网络是无损的。如果UDP测试发现丢包就要去排查是链路问题、交换机缓冲区问题还是PFC配置问题。延迟测试用ping就够了但要注意ping的默认间隔是1秒测不出微突发。如果要测微突发可以用hping3# 每秒发送1000个包测量延迟分布 hping3 -c 10000 -i u1000 192.168.1.100这个命令会每1000微秒发送一个包总共发送10000个包。然后看延迟的分布如果延迟抖动很大说明网络存在拥塞或者缓冲区不足的问题。抓包分析是排查网络问题的终极手段。我教学生用tcpdump抓包然后用Wireshark分析。重点看几个东西TCP的重传率、乱序率、零窗口通告、以及RDMA的PFC暂停帧。# 抓取RDMA相关的包 tcpdump -i eth0 -w rdma.pcap udp port 4791 # 抓取TCP重传 tcpdump -i eth0 -w tcp.pcap tcp[tcpflags] tcp-retransmit ! 0注意抓包会消耗大量的CPU和磁盘IO在生产环境里要谨慎使用。如果一定要抓建议用环形缓冲区限制抓包文件的大小和数量。另外抓包的时间点很关键最好在问题复现的时候抓而不是事后抓。3.3 分布式训练通信的调优实操分布式训练的通信调优是课程的高阶内容。我设计了一个完整的调优流程先测量基线性能然后逐步调整参数观察性能变化最后找到最优配置。基线测量用NCCL的all_reduce_perf工具测量不同消息大小下的带宽和延迟。然后调整以下参数NCCL_ALGO选择Ring、Tree或CollNetNCCL_PROTO选择LL、LL128或SimpleNCCL_NTHREADS每个GPU的通信线程数NCCL_MIN_NCHANNELS最小通道数NCCL_MAX_NCHANNELS最大通道数这些参数的组合非常多不可能全部穷举。我的做法是先用默认配置跑一遍然后根据瓶颈类型来调整。如果瓶颈是延迟就尝试Tree算法和LL协议如果瓶颈是带宽就尝试Ring算法和Simple协议并增加通道数。# 基线测试 ./all_reduce_perf -b 8 -e 128M -f 2 -g 8 # 调整算法和协议 export NCCL_ALGOTree export NCCL_PROTOLL ./all_reduce_perf -b 8 -e 128M -f 2 -g 8 # 增加通道数 export NCCL_MIN_NCHANNELS8 export NCCL_MAX_NCHANNELS16 ./all_reduce_perf -b 8 -e 128M -f 2 -g 8这个调优过程学生会发现没有一组参数是万能的。小消息下最优的参数大消息下可能不是最优的。所以实际训练中往往需要根据消息大小的分布来折中。如果训练任务里小消息多就偏向延迟优化如果大消息多就偏向带宽优化。实操心得NCCL的调优不要一次改太多参数否则你根本不知道是哪个参数起了作用。我的习惯是一次只改一个参数记录性能变化然后再改下一个。虽然慢一点但能积累出可靠的调优经验。3.4 推理服务的网络配置实操推理服务的网络配置和训练不一样训练关注的是高带宽和低延迟推理关注的是高并发和弹性伸缩。我设计了一个基于K8s的推理服务部署实验让学生从零搭建一个推理服务并配置网络。实验步骤大致如下# 部署一个简单的推理服务 kubectl create deployment inference --imagenginx --replicas3 # 暴露服务 kubectl expose deployment inference --port80 --target-port80 --typeClusterIP # 查看服务 kubectl get svc inference # 测试服务发现 kubectl run test --imagebusybox --rm -it -- wget -qO- http://inference这个实验看起来简单但里面涉及了K8s网络的核心概念Pod网络、Service网络、DNS解析、kube-proxy的负载均衡。学生会发现从test Pod访问inference Service请求会被kube-proxy转发到后端的某个Pod上。这个转发过程在iptables模式下是通过iptables规则实现的在IPVS模式下是通过IPVS实现的。然后我会让学生把Service类型改成NodePort再从集群外部访问观察网络路径的变化。再改成LoadBalancer如果有云环境的话观察云厂商的负载均衡器是怎么工作的。这个实验的延伸是配置Ingress和Service Mesh。Ingress负责七层路由可以根据URL路径把请求转发到不同的后端服务。Service Mesh则提供了更细粒度的流量控制、熔断、限流等功能。这些内容在传统网络课程里不讲但在实际的推理服务部署中非常常见。注意K8s的网络模型有一个核心原则每个Pod都有自己的IP地址Pod之间可以直接通信不需要NAT。这个原则和传统的虚拟机网络模型不一样学生在理解的时候容易混淆。我在课上会反复强调这一点并用实际的抓包数据来验证。4. 常见问题与排查技巧实录4.1 网络性能不达标的排查思路网络性能不达标是最常见的问题但排查起来往往没有头绪。我总结了一个排查顺序先看物理层再看链路层再看网络层最后看传输层和应用层。物理层的问题包括光模块不兼容、线缆质量差、接口协商速率不对。排查方法是看网卡的统计信息# 查看网卡统计 ethtool -S eth0 | grep -i error ethtool eth0 | grep -i speed如果看到大量的CRC错误或者丢包基本可以确定是物理层的问题。这时候要检查光模块的型号是否匹配线缆是否插紧接口的协商速率是否和预期一致。链路层的问题包括MTU不匹配、VLAN配置错误、STP环路。MTU不匹配是常见问题尤其是在RDMA场景下。如果一端配了9000的MTU另一端还是1500大包就会被丢弃。排查方法是ping大包# 测试MTU ping -M do -s 8972 192.168.1.100如果这个命令失败说明路径上的MTU小于9000。需要逐跳排查找到MTU最小的那一跳。网络层的问题包括路由配置错误、ARP表项过期、ACL拦截。排查方法是看路由表和ARP表ip route show ip neigh show传输层的问题包括TCP拥塞窗口太小、重传率太高、零窗口通告。排查方法是看TCP的统计信息ss -ti netstat -s | grep -i retrans应用层的问题包括应用配置错误、线程池太小、序列化开销太大。排查方法是看应用的日志和性能指标。这个排查顺序的逻辑是从底层到上层从简单到复杂。物理层和链路层的问题往往最容易排查也最容易解决。如果底层没问题再往上查。实操心得排查网络问题的时候一定要先确认“问题是不是网络引起的”。我见过很多次应用性能差大家第一反应是网络问题结果查了半天发现是数据库慢查询。所以第一步应该是看应用的性能指标确认瓶颈确实在网络层。4.2 RDMA配置的常见坑与解决方法RDMA配置的坑特别多我整理了一个速查表问题现象可能原因排查方法解决方法RDMA连接建立失败网卡不支持RoCEibv_devinfo换支持RoCE的网卡带宽远低于预期PFC未配置检查交换机PFC配置配置PFC延迟抖动大ECN未配置检查交换机ECN配置配置ECN间歇性丢包MTU不匹配ping大包统一MTU性能突然下降网卡固件bug查看网卡日志升级固件这个表里的每一个问题我都实际遇到过。最坑的是“带宽远低于预期”这一条因为PFC没配的时候RDMA不会报错只是性能上不去。你去看网卡状态一切正常你去看交换机状态也一切正常。但就是跑不满带宽。后来用抓包工具看发现大量的PFC暂停帧没有被正确处理才知道是PFC配置的问题。另一个坑是MTU不匹配。RDMA默认用巨帧但如果路径上有一台设备的MTU没改大包就会被分片或者丢弃。分片会严重降低性能丢弃则会导致重传。排查方法是逐跳ping大包找到MTU最小的那一跳。注意RDMA的配置一定要在实验环境里先验证再上生产。生产环境里改RDMA配置的风险很高一旦配错可能导致整个集群的网络中断。我建议在变更之前先准备好回滚方案并且选择业务低峰期操作。4.3 分布式训练通信超时的排查分布式训练通信超时是另一个常见问题。现象是训练任务卡住日志里出现NCCL timeout或者socket timeout。排查思路如下首先看NCCL的日志。设置NCCL_DEBUGINFO之后NCCL会打印出详细的通信过程。如果看到某个rank一直卡在某个操作上说明那个rank可能有问题。export NCCL_DEBUGINFO export NCCL_DEBUG_SUBSYSALL然后看网络连通性。用ping和iperf3测试所有节点之间的连通性和带宽。如果某个节点之间的带宽异常低说明那个节点的网络有问题。再看GPU的状态。用nvidia-smi查看GPU的使用率和显存占用。如果某个GPU的使用率一直是0说明那个GPU可能没有被正确初始化。最后看系统日志。用dmesg查看内核日志看有没有网卡或者GPU的报错。dmesg | grep -i error dmesg | grep -i eth dmesg | grep -i nvidia这个排查流程的关键是先确认是哪个节点的问题再确认是哪个组件的问题。分布式训练涉及多个节点、多个GPU、多个网络接口问题可能出现在任何一个环节。缩小范围是排查的第一步。实操心得分布式训练的超时问题很多时候不是网络本身的问题而是某个节点的GPU出了问题导致整个集合通信卡住。所以排查的时候不要只盯着网络看也要看GPU和CPU的状态。我遇到过好几次最后发现是某张GPU的显存坏了导致NCCL操作无法完成。4.4 容器网络的典型故障与修复容器网络的故障往往比较隐蔽因为容器网络是叠加在宿主机网络之上的问题可能出现在任何一层。我整理了几个典型故障故障一Pod无法访问Service。排查方法是先看Pod的DNS解析是否正常再看kube-proxy的规则是否正确。# 在Pod内测试DNS nslookup kubernetes.default # 查看kube-proxy的iptables规则 iptables -t nat -L KUBE-SERVICES -n故障二Pod之间跨节点通信失败。排查方法是看CNI插件的日志以及节点的路由表。# 查看CNI插件日志 journalctl -u kubelet | grep -i cni # 查看路由表 ip route show故障三Service的负载均衡不生效。排查方法是看Endpoints是否正确以及kube-proxy的模式是iptables还是IPVS。# 查看Endpoints kubectl get endpoints # 查看kube-proxy模式 kubectl logs -n kube-system kube-proxy-xxx | grep -i mode这些故障的修复方法各不相同但排查思路是一致的先确认问题出在哪一层再针对那一层去排查。容器网络的问题往往需要结合宿主机网络和容器网络一起看不能只看一边。注意在K8s集群里排查网络问题一定要用“最小复现”的原则。先创建一个最简单的Pod测试最基本的连通性然后逐步增加复杂度。不要一上来就在复杂的应用里排查那样变量太多很难定位问题。5. 课程建设的经验总结与迭代方向5.1 两轮试讲后的反馈与调整这个课程我试讲了两轮第一轮偏理论学生反馈“听懂了但不会做”第二轮增加了实验比重学生反馈“实验太多理论没讲透”。第三轮我做了折中理论部分用真实案例驱动每个知识点都配一个实际场景实验部分分层次基础实验必做进阶实验选做。具体调整包括把TCP拥塞控制的理论课时从4小时压缩到2小时但增加了一个“用Wireshark分析真实训练任务的TCP重传”的实验把RDMA的理论课时从2小时增加到4小时因为学生反馈这部分最难理解把容器网络从选修改为必修因为推理服务部署的需求太普遍了。这个调整过程让我意识到课程建设不是一锤子买卖需要根据学生的反馈持续迭代。而且不同背景的学生需求不一样有的偏研究有的偏工程课程设计要尽量兼顾。5.2 后续可以扩展的方向这个课程目前覆盖了生成式AI网络的主要方面但还有一些方向可以扩展。比如在网计算利用可编程交换机在网络上直接做聚合操作可以进一步降低集合通信的延迟。再比如光互连用光交换代替电交换可以大幅提升带宽和降低功耗。这些方向目前还在研究中但已经有一些初步的成果。我打算在下一轮课程里增加一个前沿专题邀请做相关研究的同行来做一个讲座让学生了解最新的技术动态。另外我还在考虑把课程内容开源出去让更多的学生和从业者能够受益。开源的难点在于实验环境的搭建因为不同的硬件和软件环境差异很大。我打算先开源理论部分的讲义和实验指导书实验环境则提供容器化的方案降低复现的门槛。这个课程建设的过程让我深刻体会到网络技术正在从“连接互联网”转向“连接算力”而生成式AI是推动这个转变的核心力量。作为网络课程的教师我们需要跟上这个变化把最新的技术和最真实的问题带进课堂。 面向生成式AI的计算机网络课程建设：从协议分层到RDMA与NCCL实战
1. 课程定位与整体设计思路拆解1.1 为什么传统计算机网络课程必须动刀我教了几年计算机网络也参与过几轮课程大纲的修订最直观的感受就是学生越来越难被“协议分层”这四个字打动。以前讲OSI七层模型学生还会认真记笔记现在他们更关心的是——这些协议跟我用的大模型有什么关系我训练一个模型网络到底在哪个环节拖了我的后腿这个项目标题“面向生成式人工智能的计算机网络课程建设”核心要解决的就是这个断层。传统计算机网络课程的知识体系是围绕“端到端通信”建立的从物理层的信号编码到应用层的HTTP、DNS整条链路非常完整。但生成式AI带来的负载特征完全不一样大模型训练需要的是高带宽、低延迟、无损的RDMA网络推理服务需要的是高并发、弹性伸缩的容器网络分布式训练还涉及集合通信库在底层对网络拓扑的极致压榨。如果课程还是只讲TCP三次握手、滑动窗口、CSMA/CD学生学完之后面对一个真实的GPU集群网络问题根本无从下手。所以这个课程建设的第一个设计决策就是保留经典网络原理的骨架但把血肉换成生成式AI场景下的真实问题。具体来说我做了这样的取舍物理层和数据链路层的内容压缩到原来的60%但增加了“数据中心网络拓扑与布线”的模块网络层保留IP路由的核心逻辑但把重点从“互联网路由协议”转向“集群内路由与拥塞控制”传输层是重头戏TCP要讲但更要讲RDMA over Converged Ethernet和InfiniBand的传输机制应用层则直接对接gRPC、NCCL通信、参数服务器等实际框架。这个取舍背后的逻辑很简单学生毕业后如果去搞AI基础设施他每天面对的不是“为什么我的网页打不开”而是“为什么我的AllReduce操作延迟突然飙升”。课程必须让他有能力回答后一个问题。1.2 课程模块的划分与学时分配整个课程我设计成六个模块总学时48小时其中理论32小时实验16小时。这个比例是经过两轮试讲后调整出来的第一轮理论给了40小时结果学生反馈“听懂了但不会做”所以第二轮大幅增加了实验比重。模块核心内容理论学时实验学时网络基础与AI负载特征分层模型、带宽延迟积、AI训练/推理流量模式62数据中心网络叶脊架构、RDMA、无损网络、拥塞控制84分布式通信与集合操作NCCL、MPI、AllReduce、参数服务器64容器与编排网络CNI、Overlay、Service Mesh、K8s网络62网络性能调优抓包分析、带宽测试、延迟测量、瓶颈定位44前沿专题在网计算、可编程交换机、光互连20这个表格里的学时分配不是拍脑袋定的。数据中心网络给了84是因为这是生成式AI最吃网络的部分也是学生最容易踩坑的地方。分布式通信给了64因为集合操作的性能直接决定训练效率而且这部分内容在传统课程里几乎不涉及。容器网络给了62因为现在推理服务基本都跑在K8s上不懂CNI和Overlay连服务发现都搞不定。注意实验学时的分配要留出至少2小时的“自由排障”时间不要把所有实验都设计成按步骤操作。真实网络问题从来不是按步骤出现的让学生自己面对一个“训练任务卡住了”的场景比让他照着文档配一遍RDMA更有价值。1.3 与生成式AI工作流的对接点课程建设的另一个核心思路是每一个网络知识点都要找到一个生成式AI工作流中的锚点。没有锚点的知识点要么删掉要么压缩成背景阅读材料。举个例子讲TCP拥塞控制的时候传统讲法是慢启动、拥塞避免、快重传、快恢复。我在课上会先放一段真实训练任务的网络监控图让学生看到当多个GPU节点同时进行AllReduce时TCP的拥塞窗口波动会导致集合通信时间抖动进而拖慢整个训练步。然后我再讲为什么RDMA的基于信用的流控能解决这个问题。这样学生就明白了不是TCP不好而是场景变了需求变了。再比如讲DNS传统讲法是递归查询、迭代查询、缓存机制。我会把它接到“推理服务的服务发现”上当一个推理请求到达网关网关需要把请求路由到某个模型实例这个过程中服务注册与发现机制是怎么工作的DNS在容器环境里扮演什么角色CoreDNS的性能瓶颈在哪里。这样DNS就不再是一个孤立的协议而是推理链路的一环。这种对接方式的好处是学生学完之后脑子里有一张“AI系统网络全景图”而不是一堆散落的协议知识点。他遇到一个新问题知道该从哪个层面去排查该用哪个工具去验证。2. 核心细节解析与实操要点2.1 数据中心网络拓扑的讲法与实验设计叶脊架构是数据中心网络的基础但很多教材讲得太抽象。我的做法是先用一个生活化类比叶脊架构就像一个大城市的交通网络叶交换机是各个小区门口的道路脊交换机是城市主干道。小区内部的车流不会直接上主干道而是先汇聚到叶交换机再根据目的地选择走哪条脊交换机。这样任何两个小区之间的通信最多只需要经过三跳。讲完类比之后我会带学生做一个纸面设计练习假设有一个64节点的GPU集群每个节点需要200Gbps的带宽要求任意两个节点之间的通信延迟不超过10微秒请设计一个叶脊拓扑并计算需要多少台叶交换机、多少台脊交换机、多少条上行链路。这个练习的答案不是唯一的但有一个合理的计算过程。假设每台叶交换机有32个200Gbps下行端口和8个400Gbps上行端口那么一台叶交换机可以连接32个节点。64个节点需要2台叶交换机。每台叶交换机有8条400Gbps上行链路总上行带宽是3.2Tbps。如果脊交换机有32个400Gbps端口那么一台脊交换机可以连接4台叶交换机因为每台叶交换机占用8个端口。为了冗余至少需要2台脊交换机。所以最终方案是2台叶交换机、2台脊交换机每台叶交换机用4条上行链路分别连接到2台脊交换机。这个计算过程我会让学生在课上自己推一遍然后我再讲实际部署中还要考虑的问题比如线缆长度限制、光模块兼容性、供电和散热、以及最关键的——收敛比。收敛比是下行总带宽与上行总带宽的比值这个比值决定了网络在突发流量下的表现。对于AI训练集群收敛比通常要做到1:1或者接近1:1因为AllReduce操作会产生大量的突发流量。实验环节我设计了一个基于开源工具的拓扑模拟用容器模拟交换机和主机用Linux的流量控制工具模拟链路带宽和延迟然后让学生用iperf3和ping测试不同拓扑下的吞吐和延迟。这个实验不需要真实的交换机但能让学生直观感受到拓扑对性能的影响。实操心得在模拟实验里一定要让学生手动设置MTU。默认的1500字节MTU在RDMA场景下会导致大量的分片性能直接腰斩。把MTU调到9000巨帧之后同样的流量模式吞吐能提升30%以上。这个对比实验学生做一次就记住了。2.2 RDMA与无损网络的原理拆解RDMA是生成式AI网络里绕不开的技术但也是最难讲清楚的技术之一。我的讲法是先从问题出发为什么TCP在AI训练场景下不够用核心原因是TCP的内核协议栈处理开销太大。每一次数据包的处理都要经过内核态到用户态的拷贝还要经过中断处理、协议解析、拥塞控制等环节。在100Gbps以上的带宽下CPU根本来不及处理这么多包大量的时间花在了协议栈上而不是真正的数据传输上。RDMA的思路是把网络协议栈的处理卸载到网卡上数据直接从一台机器的用户态内存传输到另一台机器的用户态内存完全不经过CPU和内核。这就像从“快递员把包裹送到小区门口你自己下楼去取”变成了“快递员直接把包裹放进你家冰箱”。但RDMA要跑在以太网上就面临一个根本矛盾以太网天生是有损的而RDMA假设网络是无损的。解决这个矛盾的技术就叫RoCERDMA over Converged Ethernet。RoCEv2通过UDP封装RDMA数据包然后在网络层实现基于优先级的流控PFC和显式拥塞通知ECN。PFC的原理是当交换机的一个端口缓冲区快满的时候它向上一跳发送一个暂停帧告诉对方“先别发了等我缓一缓”。这个机制能保证不丢包但有个副作用——队头阻塞。如果暂停帧发得太频繁整个链路都会被拖慢。所以PFC的阈值设置非常关键设得太低会频繁暂停设得太高会丢包。ECN则是另一种思路交换机在缓冲区快满的时候不是暂停发送而是在数据包里打一个标记接收方收到标记后通知发送方降速。这种方式更平滑但需要端侧协议栈的支持。我在课上会用一个表格来对比这两种机制机制触发条件动作优点缺点PFC缓冲区超过阈值发送暂停帧保证不丢包可能队头阻塞ECN缓冲区超过阈值标记数据包平滑降速需要端侧支持实验环节我设计了一个RoCE配置实验用两台服务器各插一张支持RoCE的网卡通过一台支持PFC和ECN的交换机连接。然后让学生分别配置PFC和ECN用perftest工具测试RDMA的带宽和延迟对比两种机制下的性能差异。这个实验的难点在于网卡和交换机的配置。不同厂商的网卡配置命令不一样交换机更是各家有各家的语法。我的建议是实验环境尽量统一用同一品牌的设备减少兼容性问题。如果条件有限可以用软RoCESoft-RoCE来模拟虽然性能差很多但原理和配置流程是一样的。注意配置PFC的时候一定要确认整个链路上的所有设备都支持并正确配置了PFC。只要有一个环节没配PFC就不会生效而且不会报错只是性能上不去。这个坑我踩过好几次排查起来非常费时间。2.3 集合通信与NCCL的实操解析集合通信是分布式训练的核心NCCL是NVIDIA的集合通信库也是目前用得最广泛的。但很多学生只知道NCCL快不知道它为什么快更不知道什么时候会慢。NCCL的核心优化在于它能够根据网络拓扑自动选择最优的通信算法。比如AllReduce操作NCCL会根据节点数量、GPU数量、网络带宽和延迟在Ring、Tree、CollNet等算法之间做选择。Ring算法适合节点数较少、带宽均匀的场景Tree算法适合节点数多、带宽不均匀的场景CollNet则是利用交换机或在网计算能力来加速。我在课上会让学生做一个实验用4台服务器每台4张GPU总共16张GPU跑一个AllReduce操作。然后分别用NCCL的Ring算法和Tree算法测量不同消息大小下的通信时间。学生会发现小消息下Tree更快大消息下Ring更快。这个结论和NCCL的自动选择逻辑是一致的。实验的具体步骤是这样的# 设置NCCL使用的算法 export NCCL_ALGORing # 或者 export NCCL_ALGOTree # 运行AllReduce测试 ./all_reduce_perf -b 8 -e 128M -f 2 -g 4这个命令会从8字节开始每次翻倍一直测到128MB测量不同消息大小下的通信带宽和延迟。学生会看到一条曲线小消息下延迟主导大消息下带宽主导。然后我会让他们把NCCL_ALGO改成Tree再跑一遍对比两条曲线的差异。这个实验的价值在于它让学生直观理解了“算法选择不是拍脑袋而是有数据支撑的”。以后他们在实际工作中遇到通信瓶颈就知道该从哪里入手去调优。实操心得NCCL的日志非常有用。设置NCCL_DEBUGINFO之后NCCL会打印出它选择的算法、使用的通道数、以及每个通道的带宽。这些信息是排查通信问题的第一手资料。我建议学生在跑任何分布式训练任务之前都先开NCCL_DEBUGINFO跑一遍小规模的测试确认通信路径是符合预期的。2.4 容器网络与推理服务的对接生成式AI的推理服务现在基本都跑在Kubernetes上这就涉及容器网络的问题。传统网络课程不讲容器网络但学生如果不懂CNI、Overlay、Service Mesh连一个推理服务都部署不起来。容器网络的核心问题是容器需要有自己的IP地址需要能够跨节点通信需要能够被服务发现机制找到。Kubernetes通过CNI插件来解决第一个问题通过Overlay网络来解决第二个问题通过Service和Ingress来解决第三个问题。我在课上会重点讲三种CNI插件的区别Calico、Flannel、Cilium。Calico基于BGP路由性能好但配置复杂Flannel基于VXLAN Overlay配置简单但有封装开销Cilium基于eBPF性能最好但需要较新的内核版本。CNI插件实现方式性能配置复杂度适用场景CalicoBGP路由高中大规模集群FlannelVXLAN Overlay中低中小规模集群CiliumeBPF最高高性能敏感场景实验环节我设计了一个对比实验在同一个K8s集群里分别用Flannel和Calico部署两个推理服务然后用wrk或者hey工具压测对比两种CNI下的吞吐和延迟。学生会发现Calico的延迟明显低于Flannel因为Flannel的VXLAN封装会增加额外的头部开销而且封包解包会消耗CPU。这个实验的另一个目的是让学生理解网络性能不是孤立的它和CPU、内存、存储都有关系。Flannel的封装开销最终会体现在CPU使用率上如果CPU本身就很紧张网络性能会进一步下降。注意在生产环境里CNI插件的选择往往不是单纯看性能还要考虑运维成本、社区活跃度、与现有监控体系的兼容性。Calico虽然性能好但BGP的运维门槛不低Cilium虽然性能最好但对内核版本有要求老旧的K8s集群可能跑不起来。这些取舍在课上要讲清楚不能只讲技术不讲工程。3. 实操过程与核心环节实现3.1 实验环境搭建的完整流程整个课程的实验环境我设计成两层一层是本地虚拟机环境用于基础实验一层是远程GPU集群环境用于分布式通信实验。本地环境用Vagrant加VirtualBox搭建远程环境用容器化的方式模拟。本地环境的搭建步骤如下# 初始化Vagrant环境 vagrant init ubuntu/focal64 vagrant up # 登录虚拟机 vagrant ssh # 安装基础工具 sudo apt update sudo apt install -y iproute2 tcpdump iperf3 net-tools # 配置网络命名空间模拟多主机 sudo ip netns add host1 sudo ip netns add host2 sudo ip link add veth1 type veth peer name veth2 sudo ip link set veth1 netns host1 sudo ip link set veth2 netns host2这个环境可以模拟两台主机之间的通信学生可以在里面做TCP拥塞控制、路由配置、抓包分析等实验。网络命名空间的好处是隔离性好一台机器上可以模拟出多台主机的效果而且不会影响宿主机的网络配置。远程GPU集群环境我用的是容器化的方案用Docker容器模拟GPU节点用NCCL的容器镜像来跑集合通信测试。这个方案的好处是不需要真实的GPU用CPU也能跑通NCCL的通信逻辑只是性能数据没有参考价值。但对于理解通信算法和排查配置问题来说已经足够了。# 拉取NCCL测试镜像 docker pull nvcr.io/nvidia/pytorch:23.10-py3 # 启动两个容器模拟两个节点 docker run -d --name node1 --network host nvcr.io/nvidia/pytorch:23.10-py3 docker run -d --name node2 --network host nvcr.io/nvidia/pytorch:23.10-py3 # 在容器内运行AllReduce测试 docker exec -it node1 bash # 在容器内执行 ./all_reduce_perf -b 8 -e 128M -f 2 -g 1这个实验的关键是让两个容器能够互相通信。用host网络模式是最简单的但会占用宿主机的端口。如果要做更真实的模拟可以用自定义的Docker网络然后配置静态IP和路由。实操心得在容器里跑NCCL测试的时候一定要设置NCCL_SOCKET_IFNAME环境变量指定使用哪个网络接口。如果不设置NCCL可能会选错接口导致通信失败或者性能极差。这个坑我踩过排查了半天才发现是接口选错了。3.2 网络性能测试与瓶颈定位网络性能测试是课程里最实用的部分。我教学生用三个工具iperf3测带宽ping和hping3测延迟tcpdump和Wireshark抓包分析。iperf3的用法很简单但参数选择有讲究# 服务端 iperf3 -s # 客户端测试TCP带宽 iperf3 -c 192.168.1.100 -t 30 -P 4 # 客户端测试UDP带宽和丢包 iperf3 -c 192.168.1.100 -u -b 1G -t 30这里的-P 4表示用4个并行连接。为什么要用并行连接因为单个TCP连接的带宽往往受限于拥塞窗口和往返延迟达不到链路的物理带宽。用多个连接可以绕过这个限制更准确地测量链路的最大吞吐。UDP测试则用来测量丢包率。在RDMA场景下丢包是致命的因为RDMA假设网络是无损的。如果UDP测试发现丢包就要去排查是链路问题、交换机缓冲区问题还是PFC配置问题。延迟测试用ping就够了但要注意ping的默认间隔是1秒测不出微突发。如果要测微突发可以用hping3# 每秒发送1000个包测量延迟分布 hping3 -c 10000 -i u1000 192.168.1.100这个命令会每1000微秒发送一个包总共发送10000个包。然后看延迟的分布如果延迟抖动很大说明网络存在拥塞或者缓冲区不足的问题。抓包分析是排查网络问题的终极手段。我教学生用tcpdump抓包然后用Wireshark分析。重点看几个东西TCP的重传率、乱序率、零窗口通告、以及RDMA的PFC暂停帧。# 抓取RDMA相关的包 tcpdump -i eth0 -w rdma.pcap udp port 4791 # 抓取TCP重传 tcpdump -i eth0 -w tcp.pcap tcp[tcpflags] tcp-retransmit ! 0注意抓包会消耗大量的CPU和磁盘IO在生产环境里要谨慎使用。如果一定要抓建议用环形缓冲区限制抓包文件的大小和数量。另外抓包的时间点很关键最好在问题复现的时候抓而不是事后抓。3.3 分布式训练通信的调优实操分布式训练的通信调优是课程的高阶内容。我设计了一个完整的调优流程先测量基线性能然后逐步调整参数观察性能变化最后找到最优配置。基线测量用NCCL的all_reduce_perf工具测量不同消息大小下的带宽和延迟。然后调整以下参数NCCL_ALGO选择Ring、Tree或CollNetNCCL_PROTO选择LL、LL128或SimpleNCCL_NTHREADS每个GPU的通信线程数NCCL_MIN_NCHANNELS最小通道数NCCL_MAX_NCHANNELS最大通道数这些参数的组合非常多不可能全部穷举。我的做法是先用默认配置跑一遍然后根据瓶颈类型来调整。如果瓶颈是延迟就尝试Tree算法和LL协议如果瓶颈是带宽就尝试Ring算法和Simple协议并增加通道数。# 基线测试 ./all_reduce_perf -b 8 -e 128M -f 2 -g 8 # 调整算法和协议 export NCCL_ALGOTree export NCCL_PROTOLL ./all_reduce_perf -b 8 -e 128M -f 2 -g 8 # 增加通道数 export NCCL_MIN_NCHANNELS8 export NCCL_MAX_NCHANNELS16 ./all_reduce_perf -b 8 -e 128M -f 2 -g 8这个调优过程学生会发现没有一组参数是万能的。小消息下最优的参数大消息下可能不是最优的。所以实际训练中往往需要根据消息大小的分布来折中。如果训练任务里小消息多就偏向延迟优化如果大消息多就偏向带宽优化。实操心得NCCL的调优不要一次改太多参数否则你根本不知道是哪个参数起了作用。我的习惯是一次只改一个参数记录性能变化然后再改下一个。虽然慢一点但能积累出可靠的调优经验。3.4 推理服务的网络配置实操推理服务的网络配置和训练不一样训练关注的是高带宽和低延迟推理关注的是高并发和弹性伸缩。我设计了一个基于K8s的推理服务部署实验让学生从零搭建一个推理服务并配置网络。实验步骤大致如下# 部署一个简单的推理服务 kubectl create deployment inference --imagenginx --replicas3 # 暴露服务 kubectl expose deployment inference --port80 --target-port80 --typeClusterIP # 查看服务 kubectl get svc inference # 测试服务发现 kubectl run test --imagebusybox --rm -it -- wget -qO- http://inference这个实验看起来简单但里面涉及了K8s网络的核心概念Pod网络、Service网络、DNS解析、kube-proxy的负载均衡。学生会发现从test Pod访问inference Service请求会被kube-proxy转发到后端的某个Pod上。这个转发过程在iptables模式下是通过iptables规则实现的在IPVS模式下是通过IPVS实现的。然后我会让学生把Service类型改成NodePort再从集群外部访问观察网络路径的变化。再改成LoadBalancer如果有云环境的话观察云厂商的负载均衡器是怎么工作的。这个实验的延伸是配置Ingress和Service Mesh。Ingress负责七层路由可以根据URL路径把请求转发到不同的后端服务。Service Mesh则提供了更细粒度的流量控制、熔断、限流等功能。这些内容在传统网络课程里不讲但在实际的推理服务部署中非常常见。注意K8s的网络模型有一个核心原则每个Pod都有自己的IP地址Pod之间可以直接通信不需要NAT。这个原则和传统的虚拟机网络模型不一样学生在理解的时候容易混淆。我在课上会反复强调这一点并用实际的抓包数据来验证。4. 常见问题与排查技巧实录4.1 网络性能不达标的排查思路网络性能不达标是最常见的问题但排查起来往往没有头绪。我总结了一个排查顺序先看物理层再看链路层再看网络层最后看传输层和应用层。物理层的问题包括光模块不兼容、线缆质量差、接口协商速率不对。排查方法是看网卡的统计信息# 查看网卡统计 ethtool -S eth0 | grep -i error ethtool eth0 | grep -i speed如果看到大量的CRC错误或者丢包基本可以确定是物理层的问题。这时候要检查光模块的型号是否匹配线缆是否插紧接口的协商速率是否和预期一致。链路层的问题包括MTU不匹配、VLAN配置错误、STP环路。MTU不匹配是常见问题尤其是在RDMA场景下。如果一端配了9000的MTU另一端还是1500大包就会被丢弃。排查方法是ping大包# 测试MTU ping -M do -s 8972 192.168.1.100如果这个命令失败说明路径上的MTU小于9000。需要逐跳排查找到MTU最小的那一跳。网络层的问题包括路由配置错误、ARP表项过期、ACL拦截。排查方法是看路由表和ARP表ip route show ip neigh show传输层的问题包括TCP拥塞窗口太小、重传率太高、零窗口通告。排查方法是看TCP的统计信息ss -ti netstat -s | grep -i retrans应用层的问题包括应用配置错误、线程池太小、序列化开销太大。排查方法是看应用的日志和性能指标。这个排查顺序的逻辑是从底层到上层从简单到复杂。物理层和链路层的问题往往最容易排查也最容易解决。如果底层没问题再往上查。实操心得排查网络问题的时候一定要先确认“问题是不是网络引起的”。我见过很多次应用性能差大家第一反应是网络问题结果查了半天发现是数据库慢查询。所以第一步应该是看应用的性能指标确认瓶颈确实在网络层。4.2 RDMA配置的常见坑与解决方法RDMA配置的坑特别多我整理了一个速查表问题现象可能原因排查方法解决方法RDMA连接建立失败网卡不支持RoCEibv_devinfo换支持RoCE的网卡带宽远低于预期PFC未配置检查交换机PFC配置配置PFC延迟抖动大ECN未配置检查交换机ECN配置配置ECN间歇性丢包MTU不匹配ping大包统一MTU性能突然下降网卡固件bug查看网卡日志升级固件这个表里的每一个问题我都实际遇到过。最坑的是“带宽远低于预期”这一条因为PFC没配的时候RDMA不会报错只是性能上不去。你去看网卡状态一切正常你去看交换机状态也一切正常。但就是跑不满带宽。后来用抓包工具看发现大量的PFC暂停帧没有被正确处理才知道是PFC配置的问题。另一个坑是MTU不匹配。RDMA默认用巨帧但如果路径上有一台设备的MTU没改大包就会被分片或者丢弃。分片会严重降低性能丢弃则会导致重传。排查方法是逐跳ping大包找到MTU最小的那一跳。注意RDMA的配置一定要在实验环境里先验证再上生产。生产环境里改RDMA配置的风险很高一旦配错可能导致整个集群的网络中断。我建议在变更之前先准备好回滚方案并且选择业务低峰期操作。4.3 分布式训练通信超时的排查分布式训练通信超时是另一个常见问题。现象是训练任务卡住日志里出现NCCL timeout或者socket timeout。排查思路如下首先看NCCL的日志。设置NCCL_DEBUGINFO之后NCCL会打印出详细的通信过程。如果看到某个rank一直卡在某个操作上说明那个rank可能有问题。export NCCL_DEBUGINFO export NCCL_DEBUG_SUBSYSALL然后看网络连通性。用ping和iperf3测试所有节点之间的连通性和带宽。如果某个节点之间的带宽异常低说明那个节点的网络有问题。再看GPU的状态。用nvidia-smi查看GPU的使用率和显存占用。如果某个GPU的使用率一直是0说明那个GPU可能没有被正确初始化。最后看系统日志。用dmesg查看内核日志看有没有网卡或者GPU的报错。dmesg | grep -i error dmesg | grep -i eth dmesg | grep -i nvidia这个排查流程的关键是先确认是哪个节点的问题再确认是哪个组件的问题。分布式训练涉及多个节点、多个GPU、多个网络接口问题可能出现在任何一个环节。缩小范围是排查的第一步。实操心得分布式训练的超时问题很多时候不是网络本身的问题而是某个节点的GPU出了问题导致整个集合通信卡住。所以排查的时候不要只盯着网络看也要看GPU和CPU的状态。我遇到过好几次最后发现是某张GPU的显存坏了导致NCCL操作无法完成。4.4 容器网络的典型故障与修复容器网络的故障往往比较隐蔽因为容器网络是叠加在宿主机网络之上的问题可能出现在任何一层。我整理了几个典型故障故障一Pod无法访问Service。排查方法是先看Pod的DNS解析是否正常再看kube-proxy的规则是否正确。# 在Pod内测试DNS nslookup kubernetes.default # 查看kube-proxy的iptables规则 iptables -t nat -L KUBE-SERVICES -n故障二Pod之间跨节点通信失败。排查方法是看CNI插件的日志以及节点的路由表。# 查看CNI插件日志 journalctl -u kubelet | grep -i cni # 查看路由表 ip route show故障三Service的负载均衡不生效。排查方法是看Endpoints是否正确以及kube-proxy的模式是iptables还是IPVS。# 查看Endpoints kubectl get endpoints # 查看kube-proxy模式 kubectl logs -n kube-system kube-proxy-xxx | grep -i mode这些故障的修复方法各不相同但排查思路是一致的先确认问题出在哪一层再针对那一层去排查。容器网络的问题往往需要结合宿主机网络和容器网络一起看不能只看一边。注意在K8s集群里排查网络问题一定要用“最小复现”的原则。先创建一个最简单的Pod测试最基本的连通性然后逐步增加复杂度。不要一上来就在复杂的应用里排查那样变量太多很难定位问题。5. 课程建设的经验总结与迭代方向5.1 两轮试讲后的反馈与调整这个课程我试讲了两轮第一轮偏理论学生反馈“听懂了但不会做”第二轮增加了实验比重学生反馈“实验太多理论没讲透”。第三轮我做了折中理论部分用真实案例驱动每个知识点都配一个实际场景实验部分分层次基础实验必做进阶实验选做。具体调整包括把TCP拥塞控制的理论课时从4小时压缩到2小时但增加了一个“用Wireshark分析真实训练任务的TCP重传”的实验把RDMA的理论课时从2小时增加到4小时因为学生反馈这部分最难理解把容器网络从选修改为必修因为推理服务部署的需求太普遍了。这个调整过程让我意识到课程建设不是一锤子买卖需要根据学生的反馈持续迭代。而且不同背景的学生需求不一样有的偏研究有的偏工程课程设计要尽量兼顾。5.2 后续可以扩展的方向这个课程目前覆盖了生成式AI网络的主要方面但还有一些方向可以扩展。比如在网计算利用可编程交换机在网络上直接做聚合操作可以进一步降低集合通信的延迟。再比如光互连用光交换代替电交换可以大幅提升带宽和降低功耗。这些方向目前还在研究中但已经有一些初步的成果。我打算在下一轮课程里增加一个前沿专题邀请做相关研究的同行来做一个讲座让学生了解最新的技术动态。另外我还在考虑把课程内容开源出去让更多的学生和从业者能够受益。开源的难点在于实验环境的搭建因为不同的硬件和软件环境差异很大。我打算先开源理论部分的讲义和实验指导书实验环境则提供容器化的方案降低复现的门槛。这个课程建设的过程让我深刻体会到网络技术正在从“连接互联网”转向“连接算力”而生成式AI是推动这个转变的核心力量。作为网络课程的教师我们需要跟上这个变化把最新的技术和最真实的问题带进课堂。