一、从一次诡异的网络抖动说起

上个月排查一个AI训练集群的问题，现象很典型：模型训练到一定规模后，每几个epoch总会出现一次明显的梯度同步延迟，波动曲线像心电图一样突兀。硬件看起来没问题——IB网卡指示灯闪得挺欢，拓扑也没环路，MPI带宽测试数据也好看。但实际训练就是会卡顿。

这种时候，靠“猜”已经没用了。你得看见数据在芯片里、在网卡里、在协议栈里到底是怎么流动的。今天要聊的这三个工具，就是我们工程师在性能迷宫里的“透视镜”。

---

二、Perf：盯紧Linux内核的每一口呼吸

Perf这东西，很多人只用来做CPU热点分析，其实它在网络跟踪上能挖得很深。尤其是当你怀疑协议栈或者驱动有鬼的时候。

先看个实际用过的命令：

perf record -e cycles -g -p <pid> -- sleep 30

这命令老生常谈了，抓CPU热点。但网络问题往往不在CPU高，而在等。这时候得换事件：

perf record -e sched:sched_stat_wait -g -p <pid>

看调度等待，有时候网络线程等DMA或者等锁，就在这里现形。

更狠的是跟踪内核网络栈：

perf trace -e net:* -T -p <pid>

TCP重传、丢包、缓冲区变化，内核网络子系统的事件都能抓出来。我遇到过一种情况，表面看带宽够，但perf trace里看到大量的tcp_retransmit_skb事件，最后发现是交换机某个端口缓存太小，微突发就丢包。

注意点：Perf采样会影响性能，生产环境慎用。而且数据量巨大，记得限制时间或者事件数。

---

三、Nsight Systems：把GPU和网络一起端详

AI集群里，网络经常和GPU绑定在一起——GPU算完了才发数据，网络慢了GPU就发呆。Nsight Systems（以前叫nvprof）的好处是能把GPU时间线和CPU、网络活动画在同一张图上。

采集命令很简单：

nsys profile -t cuda,osrt,nvtx -o report.qdrep --capture-range=cudaProfilerApi <your_command>

关键是要打开osrt（操作系统运行时）跟踪，这样才能看到MPI、NCCL的调用。

报告里重点看两个地方：

1. GPU流之间的间隙：如果GPU计算流中间出现大片空白，而空白处对应CPU在搞内存拷贝或者同步，那网络可能就不是主因。
2. NCCL操作的时间分布：看ncclAllReduce这样的调用，是均匀耗时还是偶尔飙高。偶尔飙高往往是网络拥塞或者对端延迟。

这里踩过坑：Nsight默认采样频率不高，可能抓不到短时抖动。记得用--sample=cpu提高CPU采样率，代价是文件会很大。

---

四、网络Telemetry：直接听交换机怎么说

前面两个工具都是从主机视角看问题，但网络流量大部分时间不在主机里，而是在交换芯片里。现代高速网络（IB/ROCE）的交换机都支持Telemetry，这是真正的“上帝视角”。

以NVIDIA的Spectrum交换机为例，通过MLNX-OS可以开启流统计：

show interfaces ethernet 1/1 counters

但这只是端口级，要看具体流得用更细的：

show telemetry flows

配置流匹配规则，针对某个源目的IP对、某个协议（比如NCCL用的端口）进行统计，能看到队列深度、拥塞丢包、ECN标记计数。

关键经验：Telemetry数据一定要和时间戳对齐。交换机的时间最好和主机做NTP同步，不然你看到拥塞事件，却不知道对应主机哪个时间点的计算，白搭。

有一次我们就是靠Telemetry发现，所有抖动都对应着交换机上某条链路的ECN标记激增，而那条链路正好是某个TOR的上行链路。后来一查，是TOR的缓存分配策略有问题，突发流量就被标记了。

---

五、三层联动：一个真实排查流程

说个实际案例，展示怎么把这三个工具串起来用。

问题：AI训练时，每30分钟出现一次2秒的延迟。

1. Nsight Systems先宏观定位
   跑一次带profile的训练，发现延迟时刻所有GPU的ncclAllReduce同时拉长，但GPU计算任务在此之前已经完成。说明不是GPU算得慢，是网络等东西。

2. Perf深入主机协议栈
   在下次延迟预期前，开启perf trace抓网络事件。发现TCP重传突然增多，同时sched_stat_wait显示进程在等socket读取。

3. Telemetry盯交换机
   在同样的时间窗口，查看交换机上对应主机端口的流统计。发现该时间段有大量ECN标记，且出口队列缓存持续高水位。

结论：主机TCP栈对ECN反应过度，一遇到标记就降窗，导致吞吐骤降。调整TCP参数（tcpm_ecn和tcp_recovery相关）后问题缓解。

---

六、写给自己人的建议

1. 从外到内，从宏观到微观
   别一上来就扎进perf看汇编。先看Nsight的时间线，确定问题是网络相关还是计算相关，再往下钻。

2. 工具别贪多，一次用一个
   同时开perf和nsys，开销太大，行为也可能干扰。分阶段抓，数据干净才好分析。

3. 网络问题，时间同步是命根子
   主机之间、主机和交换机之间，时间差超过毫秒，很多关联分析就废了。上PTP或者至少NTP调准。

4. Telemetry配置是个细致活
   流匹配规则别写太宽，不然数据海量。瞄准关键业务流（比如NCCL的端口范围），精准抓取。

5. 怀疑驱动或固件时，升级试试
   网络栈太深，硬件、驱动、内核、用户态层层都可能背锅。遇到诡异问题，升级驱动和固件往往有奇效，虽然这招听起来不高级，但管用。

性能调优像破案，工具就是你的勘察箱。每个工具看到的世界都只是真相的一个切面，拼起来，才能还原数据在芯片和线缆里流动的本来模样。