RDMA Telemetry技术白皮书

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

目  录

1 概述·· 1

1.1 产生背景·· 1

1.1.1 RDMA技术的发展历程：从InfiniBand到RoCEv2· 1

1.1.2 RDMA与智算中心的融合：构建高性能计算的基石·· 2

1.1.3 RDMA网络质量监控的需求与挑战·· 3

1.1.4 RDMA Telemetry技术的诞生·· 3

1.2 技术优点·· 4

2 RDMA Telemetry技术实现·· 4

2.1 I/O质量可视功能·· 4

2.1.1 功能简介·· 4

2.1.2 系统架构·· 4

2.1.3 网络分段测量·· 5

2.1.4 测量策略·· 5

2.1.5 测量指标·· 6

2.1.6 读操作交互流程·· 7

2.1.7 写操作交互流程·· 9

2.2 吞吐量可视功能·· 11

2.2.1 功能简介·· 11

2.2.2 测量策略·· 12

2.2.3 测量指标·· 12

2.2.4 运行机制·· 13

2.3 RDMA Telemetry可视化·· 14

3 典型组网应用·· 16

3.1 AI训练存储网络I/O质量监测·· 16

3.2 AI训练计算平面梯度同步性能优化·· 16

 

1 概述

1.1  产生背景

1.1.1  RDMA技术的发展历程：从InfiniBand到RoCEv2

RDMA（Remote Direct Memory Access，远程直接内存访问）是一种高速网络互联技术，该技术主要设计目的是减少在数据传输过程中收发端的处理延迟以及CPU资源消耗。该技术允许计算机能够直接访问远程计算机的内存，在内存层面完成数据传输而无需本地CPU频繁介入，从而显著提升网络通信性能。

1. InfiniBand时代：高性能网络的起源

RDMA技术最初由IBTA（InfiniBand Trade Association，InfiniBand贸易协会）提出，旨在解决传统TCP/IP协议栈在HPC（High Performance Computing，高性能计算）环境中存在的高延迟和高CPU开销问题。InfiniBand通过专用硬件实现RDMA，具备以下核心特征：

·     极低延迟：InfiniBand能够提供极低的通信延迟，通常可以控制在1微秒（μs）以内。

·     高吞吐：它支持非常高的数据传输速率，可以达到40Gbps、56Gbps甚至100Gbps以上的带宽。

·     无损网络：InfiniBand还采用了基于信用（Credit-Based）的流量控制机制，确保网络传输过程中不会出现数据丢失的情况，实现了所谓的“无损网络”。

然而，InfiniBand依赖专用的交换机和网卡设备，形成了相对封闭的技术生态，导致其在通用数据中心环境中难以大规模部署。

2. RoCEv2的出现：RDMA与以太网的结合

为降低RDMA的部署成本，业界提出了RoCE（RDMA over Converged Ethernet）技术，实现在通用以太网上运行RDMA。RoCE技术有两个主要版本：

·     RoCEv1：于2010年推出。这个版本是在以太网的第二层（数据链路层）实现的RDMA技术，它依赖于PFC（Priority Flow Control，优先级流量控制）机制来保证网络传输的无损特性。但是，这种设计存在一个潜在的问题，就是可能会导致网络死锁情况的发生。

·     RoCEv2：于2014年发布。这个版本做了重要改进，将协议提升到了以太网的第三层（网络层），使用UDP/IP协议进行传输。这样的改变使得RoCEv2能够支持跨子网的路由功能。同时，RoCEv2还引入了ECN（Explicit Congestion Notification，显式拥塞通知）等先进机制。正是这些改进使RoCEv2成为了现代数据中心中最主流的RDMA协议。

RoCEv2具有几个关键优势：

·     经济性：兼容现有以太网设备，不需要专门购买InfiniBand交换机。

·     普适性：完美契合了云计算、人工智能和大规模数据存储等现代数据中心的核心需求。

·     高性能：在性能和成本之间取得了很好的平衡，虽然延迟略高于InfiniBand（约5微秒），但远低于传统TCP/IP网络。

图1 传统TCP/IP传输 VS RoCE传输

 

1.1.2  RDMA与智算中心的融合：构建高性能计算的基石

以人工智能训练为代表的智能计算（智算）飞速发展，其训练任务需调动成千上万的GPU芯片协同工作数周甚至数月，由此催生了面向高性能、低延迟、无损化需求的智算中心。

智算中心作为数据中心服务于极致算力需求的专用子系统，其典型架构包含三层：

·     计算层（GPU服务器集群）：由海量GPU/NPU服务器构成，承担核心计算任务。

·     网络层（高速交换网络）：由高性能以太网交换机组成，负责高速互联与数据交换。

·     存储层（分布式存储系统）：由高性能存储服务器构成，提供训练数据与模型检查点的持久化存储。

在智算中心，基于以太网的RDMA技术——RoCEv2，凭借其优异性能与良好兼容性，成为各层间数据通信的核心标准，如图2所示。它主要加速以下两个关键流程：

·     计算平面通信（GPU间同步）：GPU服务器之间通过纯RoCEv2实现微秒级的数据同步（梯度、参数交换），保障万卡集群的扩展效率。

·     存储平面访问（数据供给与持久化）：GPU服务器与存储服务器之间通过NVMe over Fabrics over RoCEv2（NVMe-oF over RoCEv2）实现高带宽、低延迟的数据读写，确保训练数据持续供给与检查点快速保存。

 

图2 智算中心网络架构图

 

RoCEv2为GPU服务器间及GPU服务器与存储服务器间的数据通信提供了一条高性能的“数据高速公路”。RoCEv2网络的质量直接决定了智算中心的计算效率与数据处理能力。在这条高性能“数据高速公路”上，即使是微秒级的延迟抖动、微量丢包或瞬时拥塞，都可能导致昂贵的GPU算力空转，造成巨大的资源浪费与业务延迟。

1.1.3  RDMA网络质量监控的需求与挑战

随着RoCEv2在智算中心关键业务中的普及，其网络性能的稳定性已成为业务连续性的基石。然而，传统网络监控技术（如SNMP、NetAnalysis等）无法满足RoCEv2网络的极端性能监测需求，主要体现在：

·     精度不足：传统工具采样间隔通常在数百毫秒级，无法捕捉微秒级的延迟突增（延迟尖刺）。

·     检测粗糙：丢包检测多基于软件计数器估算，无法精确定位万分之一的微量丢包，而此类丢包在RoCEv2网络中会触发重传，导致延迟急剧上升。

·     实时性差：被动轮询模式存在监控盲区，难以实时感知瞬时拥塞，往往在业务已受影响后才能发现异常。

1.1.4  RDMA Telemetry技术的诞生

为解决传统监控手段的固有缺陷，RDMA Telemetry技术应运而生。该技术专为RoCEv2网络设计，提供两大核心功能：

·     I/O质量可视：测量GPU服务器与存储服务器之间（基于NVMe over Fabrics over RoCEv2）的I/O读写操作时延。

·     吞吐量可视：测量GPU服务器之间（基于纯RoCEv2）的写操作吞吐量与丢包情况。

通过端到端、分段式的实时性能监测，RDMA Telemetry为高性能数据中心网络提供了全面的可视化解决方案。

1.2  技术优点

与传统网络监控技术相比，RDMA Telemetry具有以下显著优势：

·     精准的故障定位能力

¡     通过I/O质量可视功能的三段式测量，它将整个存储网络划分为三个独立的区段进行监控：计算节点到网络设备之间的连接、网络设备之间的传输路径、以及网络设备到存储设备之间的连接。每个区段都根据专门的性能指标进行监控，可以将网络问题精确定位到具体区段。

¡     结合吞吐量可视功能的多维度指标分析，能准确判断问题根源是硬件故障、配置错误还是流量拥塞。

·     实时的性能监控

¡     采用硬件级计数器数据采集，监控精度达到微秒级。

¡     带内遥测技术确保监控数据与业务流量同步更新，无采样延迟。

·     智能化的运维支持

¡     可视报告自动标注异常事件和性能瓶颈。

¡     支持设置自定义告警阈值，及时发现潜在问题。

¡     历史数据分析功能帮助预测网络性能趋势。

·     广泛的场景适应性

¡     完美适配RoCEv2网络的各种应用场景。

¡     无论是分布式存储、AI训练还是金融交易系统，都能提供针对性的监控方案。

2 RDMA Telemetry技术实现

2.1  I/O质量可视功能

2.1.1  功能简介

I/O质量可视功能的核心是对存储网络（GPU服务器访问存储服务器）的端到端传输时延进行分段测量。作为RDMA Telemetry技术的重要创新，该功能将复杂的存储路径划分为三个逻辑区段（GPU服务器到交换机、交换机之间、交换机到存储服务器），并分别对每个区段的读写操作时延进行实时毫秒/微秒级监测。

这种精细化的分段测量机制，使运维人员能够直观识别性能瓶颈的具体位置。例如，当应用响应延迟上升时，通过该功能提供的信息，可立即定位问题是源自GPU服务器侧连接异常、核心网络拥塞，还是存储服务器处理缓慢，从而大大缩短了故障定位时间。

2.1.2  系统架构

RDMA Telemetry采用分布式监控架构，由以下两部分组成：

·     控制器+分析器

¡     控制器通过NETCONF接口向设备下发测量配置。

¡     设备通过gRPC功能将测量数据上报给分析器，从而在分析器上可视化展示I/O性能指标——时延。

·     测量设备（Device）

支持RDMA Telemetry功能的网络设备。

¡     计算侧端口：设备上连接GPU服务器的端口。它识别NVMe/RDMA特征报文，测量计算侧时延，并将测量数据上报至分析器。

¡     存储侧端口：设备上连接存储服务器的端口。它识别NVMe/RDMA特征报文，测量存储侧时延，并将测量数据上报至分析器。

2.1.3  网络分段测量

RDMA Telemetry将数据中心存储网络分为三段：

·     计算侧：网络设备与GPU服务器之间的部分。

·     存储侧：网络设备与存储服务器之间的部分。

·     网络路径：网络设备之间的部分。

图3 RDMA Telemetry测量模型

 

2.1.4  测量策略

当设备在全局和接口层面同时启用I/O质量可视功能后，RDMA Telemetry将对接口接收的所有RoCEv2流量进行监控测量。为适应不同用户的组网需求并降低网络负载，该技术支持根据用户配置将RoCEv2流量划分为重点保障流量（重保流量）和非重点保障流量（非重保流量），并实施差异化的测量策略。

1. 重点保障流量：持续监控

重点保障流量是指需要优先监控的关键业务流量。用户可通过源IP地址、目的IP地址或其组合来定义一条或多条重点保障流量规则。当接口检测到匹配重点保障流量规则的流量时，RDMA Telemetry将按照预设周期持续进行测量，并上报测量数据。

2. 非重点保障流量：轮询监控

非重点保障流量则指除重点保障流量之外的其他RoCEv2流量。对于此类流量：

·     若设备未启用轮询功能，则不会对其进行测量和上报。缺省情况下，未启用轮询功能。

·     若设备启用了轮询功能，系统将采用轮询机制选择性地测量和上报非重点保障流量。具体而言，设备会根据设定的轮询端口数，按周期轮流对不同接口的非重点保障流量进行测量和上报。

例如，假设在接口1至10上启用了I/O质量可视功能，开启轮询功能并设置轮询端口数为4时：

¡     第一周期：测量并上报接口1～4的非重点保障流量数据。

¡     第二周期：测量并上报接口5～8的非重点保障流量数据。

¡     第三周期：测量并上报接口9、10、1、2的非重点保障流量数据。

后续周期将依此规则循环执行。这种设计既确保了关键流量的实时监控，又有效降低了非关键流量的测量开销。

2.1.5  测量指标

基于I/O交互流程，RDMA Telemetry按周期测量并计算以下三类对象的平均值：

·     DPL（Data Preparation Latency，数据准备时延）：仅存在于写操作，用于评估计算侧准备数据的效率。

DPL升高可能指示存在计算侧CPU/内存瓶颈或线程阻塞等情况。

·     RTT（Round-Trip Time，双向时延）：报文在交换机中传输的往返时延，用于衡量网络性能，通过分解计算侧总时延IOL1（Input/Output Latency，输入/输出延迟）和存储侧总时延IOL2计算得出。

如果RTT突增，则表示存在网络拥塞、BGP路由震荡或NIC队列积压等情况。

·     DAL（Data Access Latency，数据访问时延）：衡量存储设备处理I/O请求的耗时，分为读操作DAL和写操作DAL，读操作DAL和写操作DAL独立测量，分别反映存储侧的不同处理阶段。

DAL升高，则可能存在SSD延迟高、RAID卡瓶颈或存储软件栈过载等情况。

图4 RDMA Telemetry测量指标

 

2.1.6  读操作交互流程

1. 关键报文以及测量指标

在智算中心场景中，当GPU服务器从存储服务器读取数据时，NVMe-oF over RoCEv2协议规定由存储服务器采用RDMA Write语义，直接将数据写入GPU服务器的内存。此设计的核心优势在于：将需要CPU参与发起和管理的RDMA操作置于存储侧，从而确保GPU服务器CPU在数据传输全程无干预。这不仅实现了仅1次网络往返的理论最低时延，更彻底解放了主机算力，完美契合“算力全用于计算”的核心诉求。

读操作报文交互核心步骤如下：

(1)     发起请求：GPU应用发出读指令，GPU服务器驱动构建NVMe读命令，其中包含GPU服务器内存的目标地址与访问密钥，并通过一次RDMA Send发送至存储服务器。

(2)     执行与回传：存储服务器解析命令，从NVMe SSD读取数据后，由存储服务器CPU发起一次RDMA Write，利用获取的地址与密钥，将数据直接写入GPU服务器的指定内存缓冲区。此过程GPU服务器CPU全程无干预。

(3)     完成确认：存储服务器通过另一条RDMA Send消息发送完成通知，结束本次I/O。

读操作交互流程中，流经设备上计算侧端口、存储侧端口的关键报文以及设备记录的测量指标如图5所示。

图5 读操作交互流程关键报文及测量指标

 

计算侧从存储侧读取数据过程中涉及的关键报文以及设备记录的测量指标如表1所示。

表1 读操作交互流程关键报文与测量指标

步骤	方向	报文类型	RDMA操作	交换机记录的数据
1	计算侧→存储侧	NVMe CMND（读请求）	RDMA Send Only	·     时间戳T1：计算侧端口从GPU服务器收到报文①的时间戳 ·     时间戳T2：存储侧端口向存储服务器发送报文①的时间戳
2	存储侧→计算侧	NVMe_DATA（首数据包）	RDMA Write First	时间戳T3：存储侧端口收到来自存储服务器的报文②的时间戳
3	存储侧→计算侧	NVMe_DATA（末数据包）	RDMA Write Last	不记录数据
4	存储侧→计算侧	NVMe RSP（完成响应）	RDMA Send Only Invalidate	·     时间戳T4：存储侧端口收到来自存储服务器的报文④的时间戳 ·     时间戳T5：计算侧端口向GPU服务器发送报文④的时间戳

 

2. 读操作中测量指标的计算

·     DALread=T3−T2

·     IOL1（计算侧总时延）=T5−T1

·     IOL2（存储侧总时延）=T4−T2

·     RTT=IOL1−IOL2=(T5−T1) − (T4−T2)

3. 数据读取全流程

下面以训练数据集的存储与读取这一典型场景为例，讲解读操作中RDMA Telemetry测量的全流程。在该场景中，海量的训练数据（如图片、文本）存储在基于NVMe SSD的分布式存储池中。训练集群通过NVMe over Fabrics over RoCEv2协议，以RDMA方式高速读取数据，并直接输送至GPU进行计算。

(1)     训练任务发起请求，计算侧处理

训练任务需要读取下一批训练数据，向存储系统发起读请求。计算侧GPU服务器将请求封装为NVMe-oF命令，并最终由RDMA网卡转换为一个或多个RDMA Send报文，提交给接入交换机。

(2)     请求穿越网络设备（RTT测量点）

RDMA Send报文经过接入交换机和核心交换机转发至存储侧。网络设备（如接入交换机）在入端口记录请求报文的时间戳（T1），并生成流标识，用于关联后续的响应报文（如报文④），从而计算网络往返时延（RTT）。

(3)     存储侧处理与数据返回（DAL测量点）

存储服务器收到请求报文（如报文①）后，解析命令并从本地NVMe SSD读取数据，随后指示网卡将数据封装为一个或多个RDMA Write报文（如报文②，含数据载荷）发送回计算侧。

DAL即为存储侧从接收请求（报文①）到发出第一个数据报文（报文②）的总处理耗时。

(4)     数据交付训练任务（端到端闭环）

计算侧RDMA网卡收到RDMA Write数据报文后，利用RDMA操作将数据直接写入GPU显存或主机内存的预定缓冲区，并通知训练任务数据就绪。

4. 测量价值

当训练任务出现数据供给延迟时，运维人员可通过RDMA Telemetry提供的测试数据快速定位瓶颈：

·     若DAL（存储处理段）显著升高，可推断瓶颈在存储侧，原因可能为磁盘性能降低、存储服务过载等。

·     若RTT（网络传输延迟）突增，可推断瓶颈在网络，原因可能为网络拥塞、丢包导致重传、链路故障等。在网络设备上部署iFIT（In-situ Flow Information Telemetry，带内流信息测量）功能，可以定位出具体的故障链路和故障设备。

·     若端到端延迟均匀增加，需综合排查计算侧、网络、存储负载。

该精细化测量使得智算中心能够保障数据供给流水线的稳定，确保高价GPU算力持续饱和工作。

2.1.7  写操作交互流程

1. 关键报文以及测量指标

在智算中心场景中，当GPU服务器向存储服务器写入数据时，NVMe-oF over RoCEv2协议规定由存储服务器采用RDMA Read语义，主动从GPU服务器内存拉取数据。发起和管理RDMA Read的开销同样由存储服务器CPU承担，确保了GPU服务器CPU的“零打扰”。

写操作报文交互核心步骤如下：

(1)     发起请求：GPU应用发出写指令，GPU服务器驱动构建NVMe写命令，其中包含主机内存源地址、访问密钥，并通过一次RDMA Send发送至存储服务器。

(2)     执行与获取：存储服务器解析命令后，由存储服务器CPU发起一次RDMA Read，利用获取的源地址与密钥，直接从GPU服务器的内存缓冲区中读取数据。此过程GPU服务器CPU全程无干预。

(3)     完成确认：存储服务器将数据持久化至NVMe SSD后，通过另一条RDMA Send消息发送完成通知，结束本次I/O。

写操作交互流程中，流经设备上计算侧端口、存储侧端口的关键报文以及设备记录的测量指标如图6所示。

图6 写操作交互流程关键报文及测量指标

 

计算侧向存储侧写数据过程中涉及的关键报文以及设备记录的测量指标如表2所示。

表2 写操作交互流程中关键报文与测量指标

步骤	方向	报文类型	RDMA操作	Telemetry测量数据
1	计算侧→存储侧	NVMe CMND（写请求）	RDMA Send Only	·     时间戳T1：计算侧端口从GPU服务器收到报文①的时间戳 ·     时间戳T2：存储侧端口向存储服务器发送报文①的时间戳
2	存储侧→计算侧	NVMe Read Request（数据拉取请求）	RDMA Read Request	·     时间戳T3：存储侧端口收到来自存储服务器的报文②的时间戳 ·     时间戳T4：计算侧端口向GPU服务器发送报文②的时间戳
3	计算侧→存储侧	NVMe_DATA（第1个数据包）	RDMA Read Resp First	时间戳T5：计算侧端口从GPU服务器收到报文③的时间戳
4	计算侧→存储侧	NVMe_DATA（最后数据包）	RDMA Read Resp Last	不记录数据
5	存储侧→计算侧	NVMe RS（写入确认）	RDMA Send Only Invalidate	·     时间戳T6：存储侧端口从存储服务器收到报文⑤的时间戳 ·     时间戳T7：计算侧端口向GPU服务器发送报文⑤的时间戳

 

2. 写操作测量指标的计算

·     DALwrite=T3−T2

·     DPL=T5−T4

·     IOL1（计算侧总时延）=T7−T1

·     IOL2（存储侧总时延）=T6−T2

·     RTT=IOL1−IOL2=(T7−T1) − (T6−T2)

3. 数据写入全流程

下面以检查点存储这一典型场景为例，讲解写操作的RDMA Telemetry测量全流程。在该场景中，训练任务产生的模型检查点（规模常达数百GB）需被快速保存，其实现方式是：GPU服务器通过拉取式写操作，将数据高速推送至远端的NVMe存储目标。

(1)     训练任务发起写入，计算侧处理

训练任务（如完成一个迭代后）需要写入梯度或检查点，向存储系统发起写请求。计算侧GPU服务器将请求封装为RDMA Send Only报文，提交给接入交换机。

(2)     请求报文穿越网络（数据传输测量点）

RDMA Send Only报文从计算侧网卡发出，经过网络设备转发至存储侧。网络设备在入端口记录RDMA Send Only报文的到达时间戳（T1），并生成流标识，用于关联此次传输事务（如报文①和报文⑤）。

(3)     存储侧接收处理（DAL测量点）

存储侧RDMA网卡收到请求报文（如报文①）后，准备本地存储资源，并返回RDMA Read Request报文（如报文②），请求计算侧发送数据。

DAL即为存储侧从收到请求（报文①）到发出读请求（报文②）的耗时。

(4)     数据传输

计算侧GPU服务器收到RDMA Read Request报文后，向存储侧服务器发送需要写入的数据。

DPL即为计算侧从收到读请求（报文②）到发出第一个数据报文（报文③）的耗时。

(5)     写入完成确认（端到端闭环）

存储侧服务器收到RDMA Read Resp Last报文后，知道数据写入完毕，返回RDMA Send Only Invalidate报文。

计算侧RDMA网卡收到RDMA Send Only Invalidate报文后，确认写入操作完成，并通知训练任务写操作成功。

4. 测量价值

当训练任务出现检查点写入缓慢或梯度同步延迟时，运维人员可通过RDMA Telemetry提供的测试数据快速定位瓶颈：

·     若DAL（存储处理段）显著升高，可推断瓶颈在存储侧，原因可能为写入带宽饱和、持久化慢等。

·     若DPL（计算处理段）显著升高，可推断瓶颈在计算侧，原因可能为GPU繁忙等。

·     若RTT（网络传输延迟）突增，可推断瓶颈在网络，原因可能为网络拥塞、丢包导致重传、链路故障等。在网络设备上部署iFIT（In-situ Flow Information Telemetry，带内流信息测量）功能，可以定位出具体的故障链路和故障设备。

·     若端到端延迟均匀增加，需综合排查计算侧、网络、存储负载。

该精细化测量使得智算中心能够保障参数同步与数据持久化流水线的稳定，确保分布式训练的一致性和容灾能力。

2.2  吞吐量可视功能

2.2.1  功能简介

在智算中心的计算平面中，GPU集群间的通信效率直接决定了AI大模型训练的成败。以典型的分布式训练场景为例：当一次反向传播计算完成后，数千张GPU需要通过高效的RDMA Write操作完成梯度同步（如Ring All-Reduce算法）。在这个过程中，任何微秒级的网络波动都会导致GPU等待，形成“通信墙”瓶颈——据测算，万卡集群中每节省1%的训练时间，即可节约数百万美元的计算成本。

然而，传统的网络监控手段如同“盲人摸象”：运维团队能看到端口流量，却看不到业务层的有效吞吐；能发现链路中断，却捕捉不到瞬时的微突发丢包。这导致了一个普遍困境：同一算法两次实验性能差异高达30%，却无法定位是算法问题还是网络问题，研发效率严重受损。

吞吐量可视功能正是为此而生。吞吐量可视功能是针对智算中心计算平面通信性能瓶颈而设计的核心监控能力。它专门监控GPU服务器间基于纯RoCEv2协议的RDMA Write操作流——这正是梯度同步、参数交换等关键训练通信的承载形式。与传统的网络监控不同，我们不仅关注链路层的带宽利用率，更关注应用层的有效数据传输效率。

2.2.2  测量策略

当设备在全局和接口层面同时启用吞吐量可视功能后，RDMA Telemetry将对接口接收的RoCEv2流量进行监控测量。与I/O质量可视功能不同，吞吐量可视功能不会区分重点保障流量（重保流量）和非重点保障流量（非重保流量），而是采用统一的处理策略。

为了平衡监控精度和系统资源消耗，该功能提供了两种工作模式：全量监控模式和轮询监控模式。通过这两种模式的灵活配置，用户可以根据实际网络规模和资源情况，选择最适合的监控策略，既保证关键数据的采集，又避免对系统性能造成过大影响。

1. 全量监控模式

当设备未启用轮询功能时，系统会采用全量监控模式（缺省情况下，设备未启用轮询功能）：

·     设备会对所有接口接收的RoCEv2流量进行持续地全量监控，实时测量并上报数据。

·     这种模式适用于需要全面掌握网络性能的场景，能够提供最完整的监控数据。

·     由于需要对所有流量进行处理，可能会增加设备的系统负载，建议在资源充足的环境中使用。

2. 轮询监控模式

当设备启用轮询功能时，系统会采用轮询监控模式：

·     设备会根据用户配置的轮询端口数，按周期轮流对不同接口的RoCEv2流量进行采样监控。

·     每个监控周期内，系统仅对当前轮询到的接口进行测量和上报，其他接口的数据暂不处理。

·     轮询采用循环机制，确保所有接口都能被均匀覆盖，避免长期遗漏某些接口的监控数据。

这种模式通过减少同时监控的接口数量，有效降低了系统资源消耗，适合大规模部署环境。

轮询机制示例如下，假设在接口1至10上启用了吞吐量可视功能，开启轮询功能并设置轮询端口数为4：

·     第一周期：测量并上报接口1～4的所有RoCEv2流量数据。

·     第二周期：测量并上报接口5～8的所有RoCEv2流量数据。

·     第三周期：测量并上报接口9、10、1、2的所有RoCEv2流量数据。

·     后续周期继续按此规则循环执行，确保所有接口的流量都能被定期监控。

2.2.3  测量指标

图7 吞吐量可视功能测量指标示意图

 

如图7所示，以GPU服务器1将数据推送给GPU服务器2为例。吞吐量可视功能定义了三个核心指标来全面评估通信健康度，如表3所示。

·     FCT（Flow Completion Time，流完成时间）指的是接入交换机Device A收到首个数据报文与收到最后一个数据报文的时间差。

·     FET（Flow Effective Throughput，流有效吞吐率）指的是数据入接口的实际有效数据传输速率。

·     FNR（Flow NAK Rate，流重传率）用于衡量GPU服务器1侧接入交换机到GPU服务器2之间这段网络的丢包情况。

表3 吞吐量可视功能测量指标描述表

指标	定义	计算公式	意义
FCT	完成单次RDMA写操作的总耗时	FCT = 末包到达时间 - 首包到达时间	直接反映训练迭代中的通信延迟。值越高，GPU等待时间越长，训练速度越慢
FET	RDMA流的实际有效数据传输速率（单位为bps）	FET = （总数据量 - 重传数据量）(bit) / FCT(μs) ×10⁶	衡量网络的实际可用带宽。低FET表明带宽未被充分利用，存在隐性瓶颈
FNR	因丢包导致的重传报文占比	FNR = NAK报文数 / 原始报文数（不含重传）	评估网络可靠性。高FNR直接导致有效吞吐下降，并可能引发PFC反压，影响全局

 

2.2.4  运行机制

在RoCEv2网络场景，一次RDMA可靠性传输读操作报文交互过程如图8所示。吞吐量可视功能基于以下核心机制实现：

(1)     流量识别与采样

发送端（Sender）通过设备（Device）向接收端（Receiver）发送RoCEv2报文，设备上的接口识别RoCEv2报文，将所有RoCEv2报文作为监控对象。

(2)     关键指标测量

设备对每条RDMA流（以PSN序列号标识）进行全生命周期跟踪，主要记录以下数据：

¡     首包到达时间戳（Write First报文）

¡     末包到达时间戳（Write Last报文）

¡     所有NAK重传报文的计数

¡     有效数据量统计（Device收到的总字节数 - 重传字节数）

¡     无效数据量统计（Device收到的重传字节数）

当接收端检测到PSN不连续（如PSN=2丢失）时，会发送NAK请求重传。设备通过识别这些NAK报文，精确统计重传情况，区分有效与无效吞吐。

(3)     数据分析与上报

设备按配置周期（如1秒）计算FCT、FET、FNR等指标。对于这些测量指标，用户可进行以下操作：

¡     在设备上查看这些指标。

¡     通过gRPC协议将这些指标上报至分析器，分析器可对数据进行分析、加工，生成可视化报表。

图8 RDMA可靠性传输写操作报文交互过程

 

2.3  RDMA Telemetry可视化

RDMA Telemetry和gRPC功能配合，可以将测量数据通过gRPC协议上送给AD-DC分析器（SeerAnalyzer-DC）。在分析器上图形化展示RDMA Telemetry测量结果。

如图9所示，SeerAnalyzer-DC支持按照主机IP维度或存储IP维度可视化呈现I/O时延、数据准备时延、数据访问时延、网络RTT等指标。支持查看选中的I/O详情，拓扑图形式呈现主机和存储的交互关系。点击查看详情按钮可查看该主机及存储下I/O时延趋势（如图10所示）。

图9 RDMA Telemetry可视化数据

 

图10 RDMA Telemetry可视化趋势图

 

3 典型组网应用

3.1  AI训练存储网络I/O质量监测

随着AI训练规模的指数级增长，训练数据的访问性能已成为制约模型训练效率的关键瓶颈。据统计，在千卡级GPU集群训练万亿参数模型时，数据加载阶段的I/O延迟波动会直接导致GPU利用率下降40%以上。传统存储网络监控仅能提供聚合带宽和端口级统计，无法对I/O操作的全链路时延进行分解分析，当出现I/O性能抖动时，运维团队难以快速区分是计算侧数据准备问题、网络传输问题还是存储侧处理瓶颈。

如图11所示，通过在连接GPU计算节点与全闪存存储阵列的AI训练存储网络中，在关键路径的交换设备上启用I/O质量可视功能，可以实现对每个训练作业I/O操作的全链路时延分解。该方案基于NVMe-oF over RoCEv2读写操作的完整事务周期进行测量，并可视化呈现“计算侧处理时延”、“网络传输时延”、“存储侧时延”三层指标。

AI训练存储网络中应用I/O质量可视功能可以带来如下价值：

·     对于训练作业性能诊断：实现I/O性能问题的精准定界，快速区分计算、网络、存储各环节的责任归属。

·     对于跨团队协作效率：为计算团队、网络团队、存储团队提供统一的性能视图和量化数据，缩短跨域故障协同定位时间。

·     对于基础设施优化：基于长期的时延分量趋势分析，科学指导硬件升级（如CPU/内存扩容）、网络优化（如QoS策略调整）和存储调优（如缓存策略改进）。

图11 AI训练存储网络I/O质量监测示意图

 

3.2  AI训练计算平面梯度同步性能优化

据研究，在万卡级GPU集群中进行大语言模型训练时，梯度同步通信开销占训练总时间的比例可达40%-60%。基于RoCEv2的RDMA写操作承载了All-Reduce等关键集合通信操作，其有效吞吐率和丢包重传情况直接决定了每次训练迭代的速度。传统网络监控工具（如SNMP）无法捕捉微秒级的时延变化，难以为AI训练提供有效的网络质量保障。

如图12所示，通过在AI训练计算平面中部署RDMA Telemetry吞吐量可视功能，可以实现：

·     精准时延监控：实时测量GPU服务器间RDMA流量的端到端时延（FCT），精度达微秒级。

·     拥塞快速定位：通过NAK报文统计和路径时延分析，快速区分是网络拥塞还是GPU计算瓶颈。

图12 AI训练计算平面梯度同步性能优化示意图