如果你曾参与过AI基础设施的运维工作，无论是GPU训练集群、一批推理节点，还是多租户模型服务平台，你很可能会发现一个现象：那些在传统数据中心里表现出色的网络遥测工具，在AI场景下却显得有些格格不入。它们并非毫无用处，只是并非为此类场景量身设计。

流量模式不同，故障模式不同，需要提前发现的问题也不同。如果你正在采集NetFlow或sFlow数据（这本该是标准做法），那么分清这些数据真正能发挥作用的场景，以及哪些只是无效的观测指标，将决定你拥有的是一套实用的监控体系，还是一种虚假的覆盖感。

---

一、人工智能流量为何与众不同

你在职业生涯中建立的绝大多数网络直觉，都源于南北向流量：客户端访问服务、用户访问互联网、工作负载访问存储。即便在存在大量东西向流量的现代微服务环境中，网络流的生命周期也相对较短、数据大小各异，且大多基于 TCP 协议，拥塞行为符合常规规律。

而人工智能训练会同时打破上述绝大多数固有认知。在GPU集群中运行的分布式训练任务，具备绝大多数网络工作负载所没有的同步特性。以集合通信操作为例，当在512个节点间执行AllReduce梯度同步时，每个GPU都必须完成自身的数据处理与传输，所有节点才能进入下一个计算步骤。此时，网络成为了同步屏障。这便催生了截然不同的流量特征：

• 大多数数据流均为大象流

在大型集群中执行梯度同步时，每个节点会以协调突发的方式传输千兆字节的数据，而非零散的小额事务。你的流量采集器能否监测到这类流量，取决于所使用的交换架构。若集群基于TCP/IP协议运行集合通信（在云端训练环境或无专用RDMA硬件的集群中较为常见），则会出现持续的多吉比特数据流，而传统负载只会产生数千条小型数据流。若集群采用RoCEv2或InfiniBand技术，此类流量会绕过IP协议栈，对NetFlow和sFlow采集工具基本不可见。在假设流量数据覆盖计算层之前，需先明确你的交换架构。

• 突发传输在整个集群内同步进行

当AllReduce操作启动时，所有节点会同时发送数据，这会在汇聚交换机上造成“入站汇聚”（incast）现象——大量数据流在同一时刻涌向少量目标节点。这是AI交换架构设计中已知且严重的问题。若集合通信基于TCP/IP运行，在流量数据中会表现为多个源IP地址同时出现关联的突发事件。在RDMA交换架构中，入站汇聚问题同样存在，且同样会降低训练吞吐量，但流量分析工具无法监测到该现象。

• 会话模式具有结构性与重复性

在全局归约（AllReduce）过程中，GPU 间通信遵循严格的拓扑模式。在环形全局归约中，每个节点仅与其两个相邻节点通信；在树形全局归约中，通信则遵循固定的层级结构。这些模式在每一轮训练步骤中都会重复出现。在基于 TCP/IP 的训练网络中，这种结构会在流数据中体现出来：一组固定的源‑目的 IP 地址对会以固定间隔传输大量数据，这使得基线偏差相对容易被检测。而在 RDMA 网络中，这种结构存在于硬件层，但不会在流记录中显现。

• 流量在不同阶段之间交替切换

训练任务会在计算阶段与 I/O 阶段之间循环。计算阶段以 GPU 间梯度交换为主，通常基于 RDMA（RoCEv2 或 InfiniBand）传输：这类流量对 NetFlow 和 sFlow 采集基本不可见。I/O 阶段（从分布式存储加载数据集、写入检查点）则使用不同的源/目的 IP 段、不同的时间规律，且可能采用不同协议。I/O 阶段流量是否会以 TCP 形式出现在流数据中，取决于你的存储后端：NFS、iSCSI 以及兼容 S3 的对象存储均使用 TCP；而基于 RDMA 的并行文件系统（如支持 RDMA 的 Lustre、GPFS、DAOS 或 NVMe‑oF）则不会。在判定流数据是否覆盖存储层之前，需先明确你所使用的存储类型。

---

二、数据流价值的真正体现

• 定位性能瓶颈节点

这是最能说服质疑者的应用场景。分布式训练的速度，取决于最慢的参与节点——掉队节点问题真实存在，且代价高昂。当训练任务的吞吐量持续低于预期时，人们首先会关注计算指标：GPU利用率、内存带宽、CUDA错误。这些指标固然重要，但问题往往出在网络上，而网络问题最先会在数据流中显现。

如果你已在网络流量分析工具中将GPU节点定义为自定义分组，并在训练过程中监控各节点的流量数据，那么数据发送量明显低于其他节点的设备会立刻凸显出来。这并非因为该工具能直接判断GPU性能低下——它无法做到这一点——而是因为网络流量是节点在集体运算中未能发挥应有作用的直观表现。

• 范围边界

1. 此处流量数据所展示的内容：每个源IP在各时间窗口内的字节数与数据包数量。
2. 未展示的内容：节点运行缓慢的原因——驱动问题、硬件故障、NCCL配置错误、网卡端线缆故障。

流量数据可帮你定位到问题机器，而具体诊断需在其他环节完成。

---

三、排查检查点与数据集I/O问题

训练任务的I/O阶段产生的流量与GPU间通信流量截然不同：

• 二者的源IP与目的IP网段不同、
• 时序不同，
• 且在基于TCP的存储后端上，所使用的协议也不同。

若你的存储架构采用NFS、iSCSI或兼容S3的对象存储，检查点写入与数据集读取操作会以TCP流的形式呈现在网络流量分析（NFA）中，从而让你有效观测I/O操作是否以预期的频率和数据量执行。

若你的存储网络采用基于RDMA的传输方式：如搭载RDMA的Lustre、GPFS、DAOS或NVMe-oF，这类流量不会在NetFlow或sFlow记录中有效呈现，原因与集群内GPU流量大多不可见一致。在将网络流量分析中无存储流量判定为异常、或将有流量视为完整覆盖之前，请先确认你的存储协议类型。

对于基于TCP的存储，流量数据可帮你判断检查点写入是否按预期间隔执行、数据集加载是否在下一计算阶段开始前完成、存储流量是否渗入计算网络——这类配置错误会引发不必要的资源争用。只要传输协议假设成立，无需额外监测工具，仅通过流量采集即可获取这些真实有效的问题发现。

---

四、验证网络分段是否真正生效

人工智能基础设施几乎总是采用逻辑分段构建：

• 训练节点位于一个虚拟局域网或子网，
• 管理流量在另一个，
• 存储流量则在第三个。

其目的是隔离管理访问、防止任务干扰，并控制设备间的通信权限。

预期分段与实际分段之间的差距往往令人堪忧。流量数据可以消除这一差距。使用网络流量分析器的自定义组功能定义基础设施层级，然后查询组间通信情况，就能获得真实的通信视图，而不受防火墙规则所规定的理论通信限制影响。

配置错误、超出预期范围建立连接的训练容器，会在该查询中显示出来。有人启动却忘记注册的隐蔽图形处理器节点，会以异常源IP地址的形式出现。未被记录的、对外部模型中心的依赖，会表现为向内容分发网络IP地址段的周期性出站流量。这一切都无需深度数据包检测，全部能在流量元数据中清晰呈现。

---

五、安全场景：模型具有极高的窃取价值

基于专有数据训练、经过精心设计的指令集调校与人类反馈强化学习（RLHF）流程的微调大语言模型，意味着巨额的资本投入。这类模型通常存储在某台存储服务器上，拥有可在企业内部网络访问的IP地址。基于流量的监控并非数据防泄漏解决方案，但却是监测大规模数据窃取的优质预警系统——因为大规模窃取需要传输海量数据，而网络流量（NetFlow）恰好用于衡量数据传输量。

在网络流量分析器（NFA）中为此配置告警的方法十分简单：

1. 将模型存储服务器定义为自定义组，将授权的外部目标（如云备份端点、指定内容分发网络网段、可信合作方IP）定义为另一组，对从模型存储组发往非授权目标的任何大规模出站流量进行告警。
2. 再添加一条时段规则，标记非工作时间内的大流量传输。

只需几分钟配置，即可覆盖最常见的数据窃取模式。

告警触发后可获取的信息包括：源IP、目标IP、协议、传输字节数、持续时间。无法获取的信息则是数据具体内容，这一判定需要主机级日志或数据包捕获。流量数据仅作为触发信号，后续调查需借助其他工具完成。

---

核心结论

流量分析数十年来一直是标准的网络运维工具。在人工智能环境中，它依然具备实用价值，但主要适用于基于常规TCP/IP网络运行的基础设施部分。流量数据能够展示流量大小、传输方向、时间规律以及通信模式，却无法反映图形处理器性能，也不能诊断远程直接内存访问架构的问题。

流量分析最能发挥作用的场景主要包括：

• 识别大规模向外传输的数据、
• 验证网络分段是否合理、
• 观测基于TCP协议的存储上的数据集加载或检查点流量，
• 以及借助真实流量数据支撑容量规划工作。