标签：科普-AI

协同防御：利用DCQCN和PFC构建无拥塞、零丢包的数据中心网络

近期文章

DCQCN （ Data Center Quantized Congestion Notification），数据中心量化拥塞通知。它是一种专门为数据中心网络设计的端到端拥塞控制协议。其核心目的是在使用RDMA(RoCEv2) 的网络中，高效地管理网络拥塞，从而保证高吞吐、低延迟和零丢包（或极低丢包）。
简单来说，DCQCN就是RDMA在以太网（RoCE）环境中的“交通警察”，它确保高速数据流不会造成网络堵塞。
本文参阅文献：Congestion Control for Large-Scale RDMA Deployments.pdf

在现代RDMA数据中心网络中，PFC和DCQCN必须同时部署。PFC为RDMA提供了一个安全的、无损的链路层保障，而DCQCN则在更上层智能地管理流量，防止PFC的负面效应出现并优化全局网络效率。它们一快一慢，一局部一全局，共同构成了RoCE网络的拥塞管理基石。

DCQCN的运行条件

DCQCN依赖于PFC（Priority-based Flow Control）来构建无损链路层，防止因为缓冲区过载导致的丢包。首先，在交换机端口上为承载RoCEv2流量的优先级（例如Priority 3）启用PFC。必须为每个端口预留足够的“空中”缓存（t_flight），以容纳在PFC PAUSE消息生效过程中，对端可能继续发送的数据包。（此值通常与端口速率和链路延迟有关）

数据中心交换机需要支持ECN和RED功能，这是CP（交换机）算法运行的基础。（大多数现代数据中心交换机都支持此功能。）

终端主机必须使用支持RoCEv2和DCQCN的智能网卡（如NVIDIA ConnectX系列），并安装相应的驱动程序和管理工具（如dcbtool）。

PFC – 优先级流量控制

工作机制：接收端交换机端口上的某个优先级队列（如RoCE流量队列）的缓冲区即将被填满。接收端会向发送端发送一个 Pause Frame，告诉它“暂停发送”这个特定优先级的流量。发送端收到后，立即停止发送该优先级的流量，直到接收端发送“解除暂停”的信号或等待一段时间后超时恢复。PFC可以实现无损网络，确保在拥塞时也不会丢包。这对于RDMA的可靠性和性能至关重要。

DCQCN – 数据中心量化拥塞通知

工作机制：交换机检测到拥塞，给数据包打上标记。接收端收到标记包后，向发送端发送拥塞通知包。发送端收到通知后，主动降低自己的发送速率，从源头上减少注入网络的数据量。DCQCN主动管理拥塞，通过降低发送速率来缓解网络中的拥塞点，同时保证不同数据流之间的公平性。

DCQCN与PFC的协同配置

在实际的RoCE网络中，PFC和DCQCN是同时启用、协同工作的。它们的交互流程完美呈现了“治标”与“治本”的结合：

瞬时微突发：当网络中出现短暂的流量突发时，交换机缓冲区可能瞬间被填满。此时，PFC会迅速介入，触发暂停机制，防止了丢包。这是“治标”，解决了瞬时问题。

持续拥塞：如果拥塞是持续性的（例如多个服务器同时向一个目标发送大量数据），PFC会反复被触发。虽然它防止了丢包，但并没有解决根本问题。拥塞还在持续，缓冲区始终很高，最终导致延迟增加。

DCQCN根除拥塞：就在PFC工作的同时，交换机也检测到了持续的拥塞（高队列深度）。它开始给数据包打ECN标记。接收端生成CNP，CNP通知发送端降低速，DCQCN机制随后被激活，交换机队列深度开始下降，拥塞根源得到缓解。随着DCQCN发挥作用，网络中的拥塞被消除，交换机缓冲区水位下降。PFC检测到队列低于阈值，便会发送“解除暂停”的信号，链路恢复正常传输。

特性	PFC	DCQCN
层级	数据链路层	网络层/传输层
范围	逐跳	端到端
机制	发送暂停帧，强制停止发送	发送通知，建议发送端降速
目标	治标：实现无损，避免丢包	治本：管理拥塞源，消除拥塞
比喻	交警在路口临时封路	交通中心让所有车辆慢行
协作角色	应急刹车，应对瞬时突发	巡航控制，进行长期流量调节

DCQN与PFC的协同工作，构成了现代RDMA数据中心网络拥塞管理的黄金标准。它们并非简单的替代关系，而是相辅相成、各司其职的完美搭档：PFC在链路层提供毫秒级的无损保障，果断处置瞬时突发，为高性能应用守住“零丢包”的生命线；而DCQCN在端到端层面实施精细化的速率调控，从源头化解持续拥塞，确保了网络整体的高效与公平。

正是这种“局部快速制动”与“全局智能调速”的深度融合，才共同铸就了高速、稳定、可扩展的新一代数据中心网络的坚实根基，使得RDMA技术得以在以太网上释放其全部潜能。

DCQCN的应用与部署

DCQCN由Mellanox（现NVIDIA的一部分）在其网卡中实现，并广泛应用于微软等大型数据中心，以支持其云存储、分布式缓存等需要高吞吐量和低延迟的服务。由于其重要性和影响力，DCQCN在2025年获得了SIGCOMM“经典之作奖”。

AI与大模型训练：在数据并行、流水线并行和张量并行等分布式训练模式中，节点间需要频繁同步海量参数（通常达百GB级别）。DCQCN能有效减少网络拥塞，避免因PFC“刹停”或丢包导致的计算长尾延迟，保障训练任务高效运行。
高性能计算（HPC）：用于需要极高网络带宽和极低延迟的科学计算、模拟等场景，DCQCN帮助RDMA实现接近线速的传输。
云存储与分布式系统：如微软的云存储服务，DCQCN保障了后端存储节点间大数据块传输的效率和稳定性，同时极大降低了CPU开销。

要想实现DCQCN，你的数据中心网络需要满足一些特定条件，并理解其三个核心组件（对应下图）的职责：

组件	角色与职责	硬件要求
交换机 (CP)	监控出口队列长度，超过阈值时根据RED算法对数据包进行ECN标记。	支持ECN和RED功能的标准数据中心交换机。
接收端网卡 (NP)	检测带有ECN标记的数据包，生成CNP拥塞通知包并返回给发送端。	支持RoCEv2的智能网卡
发送端网卡 (RP)	根据收到的CNP包降低发送速率；在未收到CNP时逐步提升速率。	支持RoCEv2的智能网卡

智算中心的硬件核心在于为 RoCEv2提供稳定、高性能的无损网络环境。这不仅需要网卡支持，更需要交换机的深度配合。CX-N系列数据中心交换机通过其超低时延、无损网络技术、对大容量缓存的优化、高级遥测功能以及对自动化运维的支持，为DCQCN协议在AI计算、高性能计算等场景中的高效、稳定运行提供了坚实的硬件基础。

【参考文献】

返回资源中心

近期文章

为什么需要DCQCN？

现代数据中心应用需要高吞吐量和超低延迟网络，具有低 CPU 开销。标准 TCP/IP 堆栈不能满足这些要求，但RDMA可以。在 IP 路由的数据中心网络上，RDMA 使用 RoCEv2 协议部署，该协议依赖于基于优先级的流量控制 (PFC) 可实现无中断网络。

但是，由于队头阻塞和带宽分配不均等问题，PFC 会导致应用程序性能不佳。为了缓解这些问题，DCQCN诞生了。

DCQCN是如何工作的？

DCQCN 是一种基于速率的拥塞控制协议，它模仿了著名的QCN（Quantized Congestion Notification），但做了适应数据中心的修改，更适合RDMA的高性能、低开销特性。

发送方：速率调节的起点（运行RDMA应用的服务器）
交换机：拥塞的检测和通知者（支持ECN的交换机）
接收方：通知的转发者（运行RDMA应用的服务器）

整个过程可以分为以下四个步骤：

步骤 1: 拥塞检测与标记（在交换机发生）

交换机持续监控其出口端口的队列深度。当某个端口的队列长度超过一个预设的阈值（Kmin）时，交换机判断该端口发生了拥塞。对于经过该拥塞端口的数据包，交换机会以一定概率将其IP头中的ECN（显式拥塞通知）字段标记为“拥塞遭遇”（CE）。这个概率随着队列变长而增加。

步骤 2: 拥塞通知（接收方 -> 发送方）

被标记了ECN的数据包会继续被发送到接收方服务器。接收方的网卡识别到这个ECN标记后，不会像传统TCP一样等待ACK包，而是立即生成并发送一个名为“CNP”（Congestion Notification Packet）的特殊控制包 directly返回给发送方。

CNP包非常小（约64字节），拥有最高优先级，以确保它能最快速度地返回给发送方，几乎无延迟地报告拥塞。

步骤 3: 速率调节（在发送方发生）

发送方收到CNP包后，就知道其发出的数据流在某处造成了网络拥塞。发送方会根据内置的算法立即降低其数据发送速率（Rate）。这个降速过程是多级的：

快速恢复：首先进行一次大幅度的降速（乘以一个小于1的因子，如 0.5），以快速缓解网络压力。
主动减少：之后进入一个阶段，持续地、较小幅度地降低速率。
主动增加：当一段时间内没有收到新的CNP包时，发送方会认为拥塞已经解除，开始缓慢地、逐步地增加发送速率（加法增加），以重新探知可用带宽。

这个“降-增”的循环过程使得DCQCN能够动态、平滑地适应网络状态，既不会过于激进导致带宽浪费，也不会过于保守导致延迟升高。

DCQCN的应用与部署

AI与大模型训练：在数据并行、流水线并行和张量并行等分布式训练模式中，节点间需要频繁同步海量参数（通常达百GB级别）。DCQCN能有效减少网络拥塞，避免因PFC“刹停”或丢包导致的计算长尾延迟，保障训练任务高效运行。
高性能计算（HPC）：用于需要极高网络带宽和极低延迟的科学计算、模拟等场景，DCQCN帮助RDMA实现接近线速的传输。
云存储与分布式系统：如微软的云存储服务，DCQCN保障了后端存储节点间大数据块传输的效率和稳定性，同时极大降低了CPU开销。

要想实现DCQCN，你的数据中心网络需要满足一些特定条件，并理解其三个核心组件（对应上图）的职责：

组件	角色与职责	硬件要求
交换机 (CP)	监控出口队列长度，超过阈值时根据RED算法对数据包进行ECN标记。	支持ECN和RED功能的标准数据中心交换机。
接收端网卡 (NP)	检测带有ECN标记的数据包，生成CNP拥塞通知包并返回给发送端。	支持RoCEv2的智能网卡
发送端网卡 (RP)	根据收到的CNP包降低发送速率；在未收到CNP时逐步提升速率。	支持RoCEv2的智能网卡

返回资源中心

近期文章

在长期服务于用户AI训练/推理生产网络的实践中，我们深刻观察到传统静态或简单度量（如跳数）的选路策略难以满足高性能AI集群网络的严苛要求。AI工作负载，特别是涉及大规模参数同步（如All-Reduce操作）和RDMA（如RoCEv2）流量时，对网络的带宽可用性、低延迟和极低抖动有着近乎极致的需求。

网络路径上的微小波动，如短暂拥塞导致的队列积压或转发延迟增加，都可能显著拖慢整个训练作业的完成时间，造成昂贵的算力资源浪费。

智能选路的路径质量如何判定？

为了从根本上优化AI流量的传输效率并最大化集群利用率，我们设计并实践了基于多维度网络状态感知的动态智能选路技术。该技术的核心创新在于，聚焦关键影响因子，摒弃单一指标，精准识别并引入在AI集群网络环境中对性能影响最为显著的动态参数作为核心计算因子：

实时带宽利用率：精确测量路径上关键链路的当前可用带宽。避免将高吞吐量的AI流量（如梯度同步）引导至已接近饱和的链路，防止拥塞崩溃和PFC反压风暴。
队列深度/使用情况：直接监控网络设备（交换机）出口队列的瞬时和平均深度。队列深度是拥塞的先行指标，深度过大意味着数据包排队等待时间（Bufferbloat）增加，直接导致传输延迟上升和抖动加剧，这对依赖确定性的RDMA和集合通信操作是致命的。
转发时延/延迟变化：不仅测量路径的基础传播延迟，更关键的是持续监测数据包转发处理延迟及其变化（抖动）。这反映了设备本身的处理能力和当前负载状态，高或波动的处理时延会破坏AI流量的同步性。

智能选路中的统计计数：ASIC赋能的高精度数据采集

在动态智能选路系统的实现中，带宽利用率与队列深度这两大关键指标的采集直接依赖于网络设备的ASIC硬件级能力。具体而言：

硬件级实时监测（百毫秒级精度）

ASIC芯片内置的硬件寄存器持续执行线速统计，对每个端口的字节转发计数（Byte Counter）和各优先级队列的缓存占用计数（Queue Depth Counter）进行原子级累加。这种基于硅片级电路的计数机制摆脱了软件轮询的延迟与性能开销，可实现百毫秒级精度的数据捕获，精准反映瞬时网络拥塞状态。

控制面高效采集（亚秒级同步）

运行于设备控制面的SONiC网络操作系统，通过标准化的SAI（Switch Abstraction Interface）接口以亚秒级周期（通常为500ms）主动读取ASIC寄存器的统计快照。此设计确保控制面能够近乎实时地感知转发芯片的状态变化，为动态选路提供高时效性数据输入。

流水线式数据处理与存储

采集的原始计数器数据通过以下高效流水线处理：

① 增量计算：SAI层将本次读数与上次读数做差，计算出时间窗口内的实际流量增量（ΔBytes）与队列深度变化值（ΔQueue-Occupancy）。
② Redis高速缓存：处理后的增量数据被写入内存数据库Redis的时序结构（TSDB）中，形成带时间戳的指标序列。此架构满足高吞吐、低延迟的数据存取需求，为后续分析提供支撑。

BGP宣告的优化设计（秒级间隔）

若按ASIC的亚秒级精度（如每100ms）通过BGP宣告路径质量，会导致控制面压力剧增，频繁生成和传输BGP Update消息，占用CPU和带宽资源。微秒级变化也可能触发不必要的路由更新，影响网络稳定性。所以，采用秒级间隔（例如每秒1次）向邻居发送BGP Update消息，携带加权平均后的路径质量值。路径质量通过BGP扩展社区属性（如Path Bandwidth Extended Community）传递，格式为浮点数（单位Gb/s）

纳秒级时延测量：INT与HDC技术负载均衡中的深度应用

转发时延计算因子基于INT（In-band Network Telemetry）技术，精度可达纳秒级。HDC（High Delay Capture）是一种能捕获ASIC中经历高延迟的数据包信息的INT技术。

INT硬件流水线实现原理

数据包进入交换机ASIC时，入口流水线在包头插入INT Shim头部，并记录精确入端口时间戳（基于芯片级高精度时钟，分辨率达纳秒级）。转发过程中，每个流水线阶段（如Ingress/Egress队列）实时追加时延元数据。包离开出口队列时，ASIC计算，此设计消除了交换机基础转发延迟的影响，仅保留队列排队时延这一关键变量。

HDC（高延迟捕获）技术深度解析

HDC是INT的功能扩展，专为捕捉网络中的尾延迟（Tail Latency）事件设计。只捕获超过用户预设阈值（如10μs）的异常延迟报文，实现靶向抓包而非全量监控。ASIC硬件实时比对报文时延与阈值——当报文在队列/缓存中的滞留时间超过阈值，立即触发抓取动作。并将原始数据包的前150字节连同INT元数据（包含出入端口、时延等关键信息）作为HDC数据包发送到收集器。

动态阈值触发机制

用户可基于业务需求设置多级延迟阈值（如：关键RDMA流：>5μs、普通TCP流：>50μs）
ASIC硬件实时比对每个包的实际队列时延与阈值，触发零拷贝抓包。

元数据结构化封装

HDC告警包包含两类关键信息：

原始包摘要：截取L2-L4层头部（150字节），保留五元组、TCP标志位等特征
INT元数据：

落地实践：AI RoCE交换机上的智能选路

动态智能选路技术在星融元交换机上开启HDC功能，并将CPU作为HDC的收集分析器，通过分析HDC报文实现高精度测量交换机转发时延，并将时延信息作为路径质量评价因子，提高路径质量评价精度。

命令行配置HDC功能控制INT进程运行，之后通过socket连接进行收包循环，将收取到的报文进行解析并将关键信息（出入端口、转发时延等）写入数据库。

返回资源中心

近期文章

在人工智能迅速发展的今天，大模型训练已成为推动技术进步的核心动力。然而，随着大模型规模的不断扩大和训练需求的增加，智算网络面临的挑战也日益严峻。网络作为连接计算集群的重要基础设施，其性能直接影响着AI训练的效率和效果。

智算网络的主流架构

目前智算网络的领域的两大主流架构：InfiniBand 和RoCEv2 在性能、成本、通用性等多个关键维度上展现出各自的优势，相互竞争。我们将细致分析这两种架构的技术特性、它们在 AI 智算网络中的应用场景，以及各自的优势和局限性。

InfiniBand

InfiniBand 网络主要通过子网管理器（Subnet Manager，简称 SM）来进行集中管理。SM 通常部署在子网内的某台服务器上，充当网络核心控制器。通过 SM 的集中控制，InfiniBand网络实现了拓扑发现、路径优化、故障恢复等功能的自动化，保障高性能与高可靠性。

InfiniBand网络架构示意图（来源：2023智算中心网络架构白皮书）

RoCEv2

RoCE（RDMA over Converged Ethernet）协议是一种能在以太网上进行 RDMA（Remote Direct Memory Access 远程内存直接访问）的集群网络通信协议。RoCEv1作为链路协议层，要求通信双方位于同一二层网络内。而RoCEv2 则为网络层协议，它采用以太网网络层和 UDP 传输层，取代了 InfiniBand 的网络层，从而提供了更为优秀的可扩展性。与 InfiniBand 网络的集中管理方式不同，RoCEv2 采用的是纯分布式架构，通常由两层构成，在扩展性和部署灵活性方面具有显著优势。

RoCEv2网络架构示意图（来源：2023智算中心网络架构白皮书）

智算网络中的负载均衡与流量控制

AI大模型时代下，数据中心与智算网络，如Spine-Leaf架构，拓扑规整，选路简易。就网络流量模式而言，GPU服务器间常存在多条并行路径，如Fat tree网络中会有数十条。

如何在这些路径中实现负载均衡路由，成为智算中心路由设计的核心挑战。

InfiniBand网络的负载均衡和流控机制

InfiniBand网络通过多层次技术协同，实现了高效的数据传输与资源管理。在负载均衡方面，子网管理器（SM）作为核心调度者，首先基于最短路径算法构建初始路由表，为流量分布奠定基础。尽管SM的动态路径优化能根据链路负载实时调整路径，但其对控制带宽和计算资源的消耗不容忽视。为进一步提升灵活性，自适应路由（AR）技术应运而生，允许交换机基于队列深度、拥塞情况等实时状态独立选择路径，既降低了延迟，又增强了网络可靠性。

然而，AR的动态特性可能导致数据包乱序，这需要上层协议或应用进行额外处理。为弥补单一路径的局限性，应用程序还可通过创建多个队列对（QP），利用硬件队列的并行传输能力分散流量，例如MPI库或Lustre存储中间件通过任务分配避免路径瓶颈，形成应用层与网络层的双重负载均衡。

负载均衡机制的高效运行，离不开底层流控机制的强力支撑。InfiniBand采用信用令牌（credit）系统，在每条链路上预设缓冲区，确保发送端仅在确认接收端资源充足时传输数据，从根本上避免了缓冲区溢出或丢包问题。与此同时，网络还结合逐包自适应路由技术，为每个数据包独立选择传输路径，实时响应拥塞、延迟等状态变化。这种细粒度的动态调整能力，不仅与信用令牌机制形成互补，更在超大规模网络中实现了资源的实时优化配置，使负载均衡从局部扩展到全局。

由此可见，InfiniBand通过负载均衡与流控机制的深度耦合，构建了一个兼具敏捷性、可靠性与扩展性的高性能网络架构。

RoCE网络的负载均衡和流控机制

图片引用自：公众号西北吹风

负载均衡技术

1、基于流（Flow-based）ECMP（Equal Cost Multi Path）是一种路由技术，用于在IP交换网络中实现负载均衡。即等价多路径路由，当存在多条到达同一个目的地址的相同开销的路径，网络设备按照自有的Hash根据流量N元组计算多路径下一跳。由于通用计算以“多流”、“小流”为主，能够实现较好的负载均衡效果。

当AIDC中的大象流连续到达交换机，传统Hash通常会将大象流集中在少数链路上传输，庞大的数据流占用相当大的带宽资源，导致传输链路发生拥塞，而其他链路上则处于空闲。这种Hash不均导致了链路负载不均，进而出现拥塞和时延加剧。

2、基于包（Packet based）随机包喷洒（Random Packet Spraying，RPS）是一种基于包级别的负载均衡策略。当交换机发现有多条等价路径指向同一目的地址时，RPS会将数据包以单个包为单位分散到这些路径上。与ECMP不同，RPS以数据包为单位进行操作，将同一流中的不同数据包转发到不同的等价路径上。

RPS的优点在于简单易实施，通过细粒度的负载均衡，可以在多条并行路径之间实现较为均衡的路由选择，提升端到端的网络吞吐率，可以将并行链路利用率提高到90%以上。缺点在于可能会造成同一个流的包乱序问题，所以这种方式必须要解决乱序问题。

3、基于流片（Flowlet）Flowlet是根据流中的“空闲”时间间隔将一个流划分为若干片段。在一个flowlet内，数据包在时间上紧密连续；而两个flowlet之间，存在较大的时间间隔。这一间隔远大于同一流分片内数据包之间的时间间隔，足以使两个流分片通过不同的网络路径传输而不发生乱序。

4、基于遥测的路由 为了将包、flowlet或整个流调度到不同的路径上，需要路由协议的控制。传统的路由协议，基于静态的网络信息来计算最优路径，如OSPF基于网络带宽计算最短路径，BGP根据AS-PATH长度计算ECMP等。这种控制与网络实际负载脱节，需要加以改进，星融元提出的基于遥测的路由（Int-based Routing）技术结合OSPF、BGP和在网遥测（INT）技术，为网络中任意一对节点之间计算多条路径，每个路径的开销是动态测量的延迟，从而能够根据实时的网络负载进行路由，从而充分利用每个路径的带宽。

流控机制

1、优先流控制（PFC）是一种逐跳流控策略，通过合理配置水位标记来充分利用交换机的缓存，以实现以太网络中的无丢包传输。当下游交换机端口的缓存过载时，该交换机就会向上游设备请求停止传输。已发送的数据则会存储在下游交换机的缓存中，等到缓存恢复正常，端口将会请求恢复数据包的发送，从而维持网络的流畅运行。

【参考白皮书：https://asterfusion.com/priority-based_flow_control_pfc/ 】

2、显式拥塞通知（ECN）定义了一种基于 IP 层和传输层的流量控制和端到端拥塞通知机制。通过在交换机上向服务器端传递特定拥塞信息，然后服务器端再发送至客户端通知源端降速从而实现拥塞控制的目的。

【参考技术手册：https://asterfusion.com/t20250416-ecn/ 】

3、数据中心量化拥塞通知（DCQCN）是显式拥塞通知（ECN）和优先流控制（PFC）两种机制的结合，旨在支持端到端的无损以太网通信。

对比项	InfiniBand	RoCEv2
流控机制	基于Credit的流控机制	PFC/ECN，DCQCN等
转发模式	基于Local ID转发	基于IP转发
负载均衡模式	逐包的自适应路由	ECMP方式路由、基于包（Packet based）、基于流片（Flowlet）、基于遥测的路由
故障恢复	Self-Healing Interconnect Enhancement for Intelligent Datacenters	路由收敛
网络配置	通过UFM实现零配置（按端口收费）	手工配置、或基于开放网络技术实现的 EasyRoCE

技术选型

根据前文我们了解到，InfiniBand和RoCEv2是两种支持RDMA的高性能网络协议，但其负载均衡机制在实现方式、性能和应用场景上存在显著差异：

InfiniBand依赖专用硬件和动态自适应路由，通过子网管理器实时优化路径，实现超低延迟和高吞吐，但成本高且扩展受限，适合HPC/AI等极致性能场景

RoCEv2基于以太网，采用静态ECMP哈希多路径分发，成本低、扩展性强，但依赖无损网络配置（如PFC/ECN），易受哈希不均影响，适合云数据中心等性价比优先场景。虽然RoCE还是很难应对大象流/老鼠流分布不均的影响，但是各厂家也在做各种努力尝试：

WCMP

结合前文，ECMP技术将包、Flowlet或整个流均匀的分布到多个路径上，很大程度上忽略了不同路径上的实际负载。为了进一步提升网络利用率。星融元采用加权代价多路径（Weighted Cost Multiple Path）算法，基于遥测获取的时延等信息，在时延更低的路径上调度更多的流量，在时延更高的路径上调度更少的流量，从而实现所有路径的公平利用。在理想情况下，流量经过不同路径的总时延是相等的，可充分利用所有可用带宽。

星融元CX864E等超级以太网交换机通过支持Flowlet、基于遥测的路由以及WCMP（加权代价多路径）三大创新技术，将AI训练和推理网络的利用率提升至90%以上，从而加速AI训练和推理过程，为AI数据中心进一步节省建设成本和运营成本。

【参考文档】

返回资源中心

最新动态

DeepSeek优化徒劳？揭秘99%的AI推理集群都适用的组网设计

关注星融元

DeepSeek的优化，精细但门槛极高

作为开源周的“彩蛋”，DeepSeek于上周六展示了采用混合专家模型（MoE）DeepSeek-V3 / R1 所使用的推理架构的整体方法——从增大吞吐和降低时延的目标出发，再次优化了PD分离架构，不过暂时没有开源代码。

（MoE）DeepSeek-V3 / R1

与Llama等采用张量并行（TP）的Dense（稠密）模型不同，混合专家（MoE）模型通过组合多个专家模型来处理复杂任务，每个专家模型专注于输入数据的不同部分，每次计算任务只需激活特定专家（而非整个神经网络）。

DeepSeek-V3 / R1 的推理系统架构一方面引入了更复杂的跨节点和多节点的传输提升计算效率和改善内存墙，同时也通过异步通信和流水线调度设计，确保由此增加的通信开销被计算任务掩盖。

值得注意的是，根据官方公布的信息，若要充分发挥DeepSeek MoE 模型的能力，起步资源是320卡，且不论在未开源的情况下面临的技术挑战。

综合成本和需求考量，上述面向专家并行的推理系统优化仅在部分toC云计算场景具备一定研究意义。现阶段toB行业大模型以及边缘计算场景仍以Dense模型为主，需要高并发的大集群平台部署可延续现有主流的算力网络设计思路，面向本地低并发需求则可采用大内存单机部署方案。

回顾：AI推理集群的PD分离和流量特征

大模型的推理任务一般分为两个阶段，一是Prefill，处理所有输入的 Token，生成第一个输出 token 和 KV cache，是算力密集型；二是Decode，利用 KV Cache 进行多轮迭代，每轮生成一个 token，需要反复读取前面所有token的 Key 和 Value，瓶颈在于内存访问。

从用户实际体验层面看，推理过程中最关键的指标是 “第一个Token的延迟” （Time To First Token, TTFT）和后续token输出的延迟（Time Per output Token, TPOT）。

如果 Prefill 和 Decode 两个阶段在同一张GPU卡上运行，则容易发生资源争抢影响到 TTFT 和 TPOT 表现，尤其是当用户输入一段长 prompt 时，不光需要较多算力来支撑prefill运算, 也需要大内存来存储 KV Cache。

Prefill-Decode

因此，业界通常采用 Prefill-Decode 分离的架构：用高算力卡做 Prefill（prefill server）, 低算力卡做 Decode（decode server）, Prefill节点在完成计算传输 KV cache 后即可释放本地显存。

参阅：一文揭秘AI智算中心网络流量 —AI推理

AI推理系统的 Scale-out 组网设计

推理集群的工程部署方面，由于 Prefill 和 Decode 采用的GPU并行方式不一样，Prefill和Decode集群是相互独立的，但两个集群间需要互联以同步KV cache。从两个阶段的输入输出来看，Prefill 流量的特征是低频大流量，要求大带宽；Decode 阶段流量的特征是高频小流量，要求低时延。

1、分离网络架构

分为Prefill网络和Decode网络，分别负责本集群内流量，两个集群之间的流量通过互联网络实现
两个网络分别运维管理，但Prefill和Decode GPU之间的流量至少需要3跳

2、统一网络架构

单个网络同时负责集群内和集群间流量
网络统一运维管理，Prefill和Decode GPU之间流量可一跳直达

统一网络架构

我们推荐采用统一网络架构，借助 QoS、自适应路由技术对 Prefill 和 Decode 流量分别处理。

Rail-only 拓扑

Rail-Only

GPU服务器内部：每四个GPU作为一组，共享一个并行推理网卡，连接到同一个PCI Switch,两组GPU之间的通信通过两个PCI Switch之间的直连通道完成；
GPU服务器之间：同一组号的GPU之间的通信通过交换机直接完成；不同组号的GPU之间的通信，先通过PCI Swtitch将流量路由到另一组的网卡，然后通过交换机完成

小规模并行推理网络拓扑

每台推理服务器有8张GPU，2张400G网卡，双归连接到两台CX732Q-N
16个推理服务器（128张GPU）和2个CX732Q-N组成一个PoD。Prefill和Decode服务器可能属于不同PoD
可横向扩展至64个PoD

中大规模并行推理网络拓扑

每台推理服务器有8张GPU，2张400G网卡，双归连接到两台CX864E-N
64个推理服务器（512张GPU）和2个CX864E-N组成一个PoD，Prefill和Decode服务器在同一个PoD，服务器间一跳可达
可横向扩展至64个PoD

拓扑设计仅供预览参考，方案均采用星融元（Asterfusion）提供的CX-N系列 AI智算网络产品：基于SONiC的开放NOS（AsterNOS）+ 100G/200G/400G/800G 超低时延以太网交换机硬件，全端口支持 RoCEv2 & EasyRoCE Toolkit。了解产品详情或项目定制方案请与我们联系。

尝试私有化部署DeepSeek？至少九成工程师会忽略这一点

关注星融元

当你尝试在私有集群上部署各类LLM应用，除了关注作为成本中心的算力资源，也一定不要忽视网络侧的配置！未经优化的网络连接，会给你的集群通信性能带来将近80%的损耗，哪怕仅有双机8卡规模。

参考：分析NCCL-Tests运行日志优化Scale-Out网络拓扑

一言以蔽之，上述性能瓶颈来自于网络连接方式与集合通信模式的不匹配。当前智算集群内采用的组网是“轨道优化”或“多轨道网络架构”，连接方式与一般云计算场景差别巨大。

以适用性最高的 Fat-tree CLOS 组网架构为例（这也是各大智算公有云的首选方法，具有非阻塞的 all-to-all 连接，不依赖于正在训练的模型），下方拓扑中的Leaf/TOR交换机被称为轨道交换机（Rail Switches），它们与所有集群单元内的GPU节点都建立了直接连接。

Fat-tree CLOS

为什么要有轨道优化？

这个问题可能需要从通信库说起。当我们要利用分布式的GPU集群实现并行计算，集合通信库是关键环节之一。集合通信库向上提供API供训练框架调用，向下连接GPU卡（机内和机间）以完成模型参数的高效传输。目前业界应用最为广泛的是NVIDIA 提供的 NCCL 开源通信库，各个大厂基本都基于 NCCL 或 NCCL 的改造版本作为底座。

NCCL自2.12版本起引入了 PXN 功能，即 PCI × NVLink。PXN 利用节点内 GPU 之间的 NVIDIA NVSwitch 连接，首先将数据移动到与目的地位于同一轨道上的 GPU 上，然后将其发送到目的地而无需跨轨道传输，从而实现消息聚合和网络流量优化。

NVIDIA NVSwitch

轨道优化拓扑即是适应这一通信特征，将不同服务器上位于相同位置（轨道）的NIC连接到同一台交换机上。

由于每个服务器有8张连接计算平面的网卡，整个计算网络被从物理上划分为8个独立并行的轨道（Rail）。由此，智算业务产生的并行通信需求（All Reduce、All-to-All 等）可以用多个轨道并行地传输，并且其中大部分流量都聚合在轨道内（只经过一跳），只有小部分流量才会跨轨道（经过两跳），大幅减轻了大规模集合网络通信压力。

轨道优化聚合了同一对 NIC 之间传递的消息，得以最大限度地提高有效消息速率和网络带宽。反观NCCL 2.12 之前，同样的端到端通信将经过三跳交换机（上图的L0、S1 和 L3），这可能会导致链路争用并被其他流量拖慢。

如何配置多轨架构的智算网络？

首先是需要明确GPU卡的连接方式。如果是N卡，你可以使用nvidia-smi topo -m的命令直接查看。但综合考虑成本因素，要想在更为通用的智算环境下达到GPU通信最优，最好的办法还是在采购和建设初期就根据业务模型特点和通信方式预先规划好机内互联（GPU-GPU、GPU-NIC）和机间互联（GPU-NIC-GPU），避免过早出现通信瓶颈，导致昂贵算力资源的浪费。

下面我们以星融元智算网络方案具体举例，使用CX-N系列RoCE交换机组网。

CX-N系列产品

100G/200G/400G/800G RoCE 端口，运行企业级SONiC/AsterNOS，转发时延约450~560ns，全面支持 EasyRoCE Toolkit

主机侧的路由配置

智算环境下以GPU卡（而非服务器）为单位的通信模式形成了服务器多网卡多出口环境的路由策略，通常会有8张网卡用于接入参数/计算网，每张网卡位于各自的轨道平面上。为避免回包通信失败，服务器上的网卡配置需要利用Linux多路由表和策略路由机制进行路由规划，这与传统云网的配置方式完全不同。

第一步是按照组网规划和网段规划，进行IP地址规划和Rail平面划分。在我们的EasyRoCE Toolkit 下的AID工具（AI Infrastructure Descriptor，AI基础设施蓝图规划）中，Notes字段用于标注Rail编号，即0代表Rail平面0、1代表Rail平面1，以此类推。

确认好了上述信息，到这里其实可以开始手动配置了，但你也可以使用另一个EasyRoCE的IRM工具（In-node Route Map，GPU内部路由规划器）。IRM 从AID 生成的配置文件中获取适合当前集群环境的路由规划信息，并且自动化地对集群中的所有GPU服务器进行IP和策略路由配置。

In-node Route Map，GPU内部路由规划器

交换机侧的主动路径规划

CLos架构下，各交换节点分布式运行和自我决策转发路径容易导致无法完全感知全局信息，在多层组网下流量若发生Hash极化（经过2次或2次以上Hash后出现的负载分担不均）将拖慢集群性能。

为解决满足AI集群规模化部署的通信需求，一般来说我们会通过规范流量路径来解决性能和规模方面的痛点（例如负载均衡、租户隔离等），按照如下转发逻辑去配置RoCE交换机：

跨 Spine上行流量进入Leaf后根据源IP和是否为跨Spine远端流量，执行策略路由转发给Spine，每网卡对应一个接口：

在上下行流量1：1无收敛的情况下，Leaf的每个下行端口绑定一个上行端口；
在n：1的情况下，上下行端口以倍数关系(向上取整)形成n:1映射。

跨Spine上行流量在Spine上按照标准L3逻辑转发，在轨道组网中多数流量仅在轨道内传输，跨轨道传输流量较小，网络方案暂不考虑Spine上拥塞的情况（由GPU Server集合通信处理）。
跨 Spine下行流量进入Leaf后根据 default 路由表指导转发。

当然，这里也可以使用EasyRoCE Toolkit 下的PPD工具（主动路径规划，Proactive Path Definer）自动生成以上配置。以下为PPD工具运行过程。

正在生成配置文件
100%[#########################]
Configuring leaf1's port 
leaf1的端口配置完成 
Generating leaf1's ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
Configuring leaf2's port 
leaf2的端口配置完成 
Generating leaf2's ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
Configuring leaf3's port 
leaf3的端口配置完成 
Generating leaf3's ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
Configuring leaf4's port 
leaf4的端口配置完成 
Generating leaf4's ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
show running config
是否需要查看生成的配置(Y|N):

PPD可以独立运行在服务器上，也可以代码形式被集成到第三方管理软件中，利用AID工具来生成最终配置脚本，将配置呈现在统一监控面板（例如Prometheus+Grafana）进行浏览和核对。

PPD

揭秘超以太网联盟（UEC）1.0 规范最新进展（2024Q4）

关注星融元

近期，由博通、思科、Arista、微软、Meta等国际顶级半导体、设备和云厂商牵头成立的超以太网联盟（UEC）在OCP Global Summit上对外公布其最新进展——UEC规范1.0的预览版本。让我们一睹为快吧！

UEC 1

UEC 旨在提出一种“升级版”的以太网通信协议栈用以应对AI智算、HPC等领域对RDMA网络的性能挑战——当前大规模计算节点互联场景下主要有InfiniBand和基于以太网协议的RoCE两大技术路线。有关IB和RoCE协议栈的详尽对比可参阅：

高性能网络传输：RoCE与IB协议栈对比解析

相比较为封闭的IB架构，以太网在互操作性和带宽成本上的优势已在市场层面得到了广泛认可，尤其是大规模的AI算力中心场景。当前全球TOP500的超级计算机中RoCE和IB的占比相当，以端口带宽总量计算，IB占比为39.2%，RoCE已达48.5%。

尽管IB和RoCE在高性能传输的拥塞控制、QoS皆有应对设计，但也暴露出一些缺陷。例如乱序需要重传、不够完美的负载分担、Go-back-N问题，DCQCN 部署调优复杂等等。

面向GPU Scale-out网络的UEC 1.0 规范从软件API、运输层到链路层以及网络安全和拥塞控制皆有涉及，较传统RDMA网络有了大量改进，我们将挑出重点介绍。 UEC2

什么是超级以太网系统

一个超级以太网系统的组成如下。一个集群（Cluster）由节点（Node）和网络（Fabric）组成，节点通过网卡（Fabric Interface）连接到网卡，一个网卡中可以有多个逻辑的网络端点（Fabric End Point，FEP）。网络由若干平面（Plane）组成，每个平面是多个FEP的集合，通常通过交换机互联。

UEC 3

超以太网协议栈概览

UEC4

▣ 物理层与传统以太网完全兼容，可选支持FEC（前向纠错）统计功能

▣ 链路层可选支持链路层重传（LLR），并支持包头压缩，为此扩展了LLDP的协商能力

▣ 网络层依然是IP协议，没有变化

▣ 传输层是全新的，作为UEC协议栈的核心数据包传输子层（Packet Delivery）和消息语义子层（Message Semantics）。包传输子层实现新一代拥塞控制、灵活的包顺序等功能，消息语义子层支持xCCL和MPI等消息。可选支持安全传输。另外，在网集合通信（In Network Collective，INC）也在这一层实现

▣ 软件API层。提供UEC扩展的Libfabrics 2.0

物理层

UEC 1.0规范下的物理层与传统以太网（符合IEEE802.3标准）完全兼容，支持每通道100Gbps和200Gbps速率，在此基础上实现800Gbps和更高的端口速率。

另外可选支持物理层性能指标统计功能（PHY metrics）。这些指标基于 FEC 码字进行计算，不受流量模式和链路利用率的影响。估计算法基于FEC错误计数器的数据，从而得出不可纠正错误率（UCR ）和数据包错误平均间隔（MTBPE）。这些指标衡量了物理层的传输性能和可靠性，用于上层的遥测和拥塞控制等。为了支持新的 UEC 链路层功能，UEC规范中也对协调子层（RS）进行了相应的修改。

链路层

UEC链路层最大的变化是引入了LLR（Link Level Retry）协议。它可以让以太网不依赖PFC，实现无损传输。

LLR 机制是基于帧的。每个帧都分配了一个序列号，接收端成功接收这一帧后，检查帧的序列号是否符合预期，如果正确，发送确认消息（ACK），如果发现帧乱序或者丢失，则发送否定确认消息（NACK）。发送端具有超时机制，用于保证在 NACK 丢失时重传。

传输层：UET，新一代协议栈的核心

前文提过，传统的RDMA网络传输层（包括IB和RoCE）在多路径传输、负载分担、拥塞控制以及参数调优等方面存在着不足之处。随着AI/HPC集群规模增长，网络的确定性和可预测性越来越困难，需要全新的方法来解决。

UEC传输层（UEC Transport Layer，简称UET）运行在IP和UDP协议之上, 支持实现以下几大技术目标：

▣ 支持高达 100 万个 GPU/TPU 的算力集群

▣ 往返时间低于 10μs

▣ 单接口带宽800Gbps及以上

▣ 网络利用率超过85%

选择性重传（Selective Retransmit）

传统传输协议，如TCP需要严格的传输顺序，并采用了Go-Back-N机制。而一个RDMA消息通常包含多个数据包，只要有一个数据包错误，则从这个数据包起的所有数据包都要重传。这让偶尔的传输错误被放大，加剧了网络拥塞。UEC采用选择性重传机制，仅传输错误的数据包。

乱序交付（Out-of-Order Delivery）

UET不仅支持有序传输，也支持无序传输。这是因为现代网络中通常有多路径存在，同一个流的数据包经过不同路径传输，就可能造成乱序。如果还要求严格的顺序传输，就无法利用多路径来实现负载分担。此外，选择性重传也需要无序传输的支持。为了实现无序传输，需要接收方有更大的数据包缓冲区，从而将乱序的数据包组成一个完整的RDMA消息。

UET支持四种传输方式：

▣ ROD (Reliable Ordered Delivery)

– 需要拥塞控制、有序、可靠、无重传（依旧采用Go-Back-N）

▣ RUD (Reliable Unordered Delivery)

– 需要拥塞控制、无序、可靠、无重传

▣ RUDI (RUD for Idempotent Operations)

– 可选拥塞控制、无序、可靠、重传

▣ UUD (Unreliable Unordered Delivery)

– 可选拥塞控制、无序、不可靠、重传

包喷洒（Packet Spraying）

包喷洒是一种基于包的多路径传输。由于传统传输协议不支持无序传输，同一个数据流必须按照同一个路径传输，否则就会造成乱序，引发重传。而在AI/HPC应用中，存在大量的“大象流”，它们数据量大、持续时间长，如果能使用多路径传输一个流，将显著提高整个网络的利用率。

由于支持了RUD，UET就可以将同一个流的不同包分散到多个路径上同时传输，实现包喷洒功能。这让交换机可以充分发挥ECMP甚至WCMP（Weighted Cost Multi- Pathing）路由能力，将去往同一目的地的数据包通过多条路径发送，大幅度提高网络利用率。

拥塞控制（Congestion Control）

UET 拥塞控制包含以下重要特性，由端侧硬件和交换机配合完成，有效减小了尾部延迟。

▣ Incast管理。它用于解决集合通信（Collective）中下行链路上的扇入问题。AI和HPC应用经常采用集合通信在多个节点之间同步信息，当多个发送者同时向一个接收者发送流量，就会产生Incast拥塞。

▣ 速率调整加速。现有的拥塞控制算法，在发生网络拥塞后调整速率的过程较长，而 UET 可以快速上升到线速。方法是测量端到端延迟来调节发送速率，以及根据接收方的能力通知发送方调整速率。

▣ 基于遥测。源自网络的拥塞信息可以通告拥塞的位置和原因，缩短拥塞信令路径并向终端节点提供更多信息，从而实现响应速度更快的拥塞控制。

▣ 基于包喷洒的自适应路由。当拥塞发生时，通过包喷洒技术将流量重新路由到其它路径上，绕过拥塞点。

端到端的安全

UEC在传输层内置安全。它是基于作业（Job）的，可以对整个作业的流量进行端到端的AES加密，充分利用 IPSec 和PSP（Packet Security Protocol）的能力，减小安全加密的开销，提供可扩展安全域，并且可以由硬件卸载。

在网计算（In Network Collectives）

在网计算最早应用在HPC集群，业界主要有两个思路，一是基于网卡的，二是基于交换机。

UEC V1.0 的目标是后者，即将集合操作卸载到各级交换机上完成，避免过多的收发次数，降低节点交互频率和处理时延开销，减少约一半数据传输量，从而加速All-Reduce操作。

在部署实现上，目前AI智算领域唯一大规模商用的案例仅有英伟达的SHARP（在ASIC层面实现的硬件加速），以太网设备厂家仍处在探索阶段，例如将算力内置于交换机或外接，甚至P4可编程都是可能的思路方向。

软件层：Extended Libfabrics 2.0

硬件升级：支持UEC的交换机和网卡

UEC在规范中定义了支持超级以太网交换机的架构，可以看到大体是继承了SONiC的架构。这部分的主要关注在于控制平面上支持INC和SDN控制器；数据平面升级了SAI（Switch Abstraction Interface）API调用硬件提供的INC等能力。

UEC 6

UEC同样定义了网络端点（Fabric End Point）的软硬件架构。在硬件层，网卡升级支持UEC功能。在操作系统内核态，实现网卡驱动。在用户态，基于libfabric扩展实现INC管理等功能，支持上层的xCCL/MPI/SHMEM等应用。

UEC 7

总的来说，UEC v1.0规范重构了数据中心以太网以完全替代传统的RDMA网络，用更高的性能、更低的成本实现稳定可靠、具有百万节点的AI/HPC集群。

星融元RoCE交换机与UEC

作为UEC成员单位，星融元提供的超低时延RoCE交换机（CX-N系列）全系采用高性能的标准白盒网络硬件，搭载为生产环境深度调优的企业级SONiC发行版——多项 Easy RoCE 特性，全面兼容现有规范并提供灵活、广大的升级空间，未来将平滑演进与新一代以太网标准保持同步。

RoCE与IB对比分析（二）：功能应用篇

近期文章

在上一篇中，我们对RoCE、IB的协议栈层级进行了详细的对比分析，二者本质没有不同，但基于实际应用的考量，RoCE在开放性、成本方面更胜一筹。本文我们将继续分析RoCE和IB在拥塞控制、QoS、ECMP三个关键功能中的性能表现。

拥塞控制

拥塞控制即用来减少丢包或者拥塞传播，是传输层的主要功能，但需要借助链路层和网络层的帮助。

RoCEv2 的拥塞控制机制

RoCEv2通过链路层PFC、网络层ECN、传输层DCQCN三者协同配合，实现更高效的拥塞管理，可见，RoCEv2虽然使用了IB的传输层协议，但在拥塞控制方面有所不同。

基于优先级的流量控制（PFC）

PFC在RoCEv2中被用于创建无损的以太网环境，确保RDMA流量不因链路层拥塞而丢失。核心原理是下游控制上游某个通道开启和停止发送数据包，控制方式是发送PFC Pause和Resume帧，触发时机是根据下游SW的ingress的队列数量是否达到某个阈值。

而PFC允许在一条以太网链路上创建8个虚拟通道，并为每条虚拟通道指定一个优先等级，允许单独暂停和重启其中任意一条虚拟通道，同时允许其它虚拟通道的流量无中断通过。这一方法使网络能够为单个虚拟链路创建无丢包类别的服务，使其能够与同一接口上的其它流量类型共存。

如图1所示，DeviceA发送接口分成了8个优先级队列，DeviceB接收接口有8个接收缓存（buffer），两者一一对应（报文优先级和接口队列存在着一一对应的映射关系），形成了网络中 8 个虚拟化通道，缓存大小不同使得各队列有不同的数据缓存能力。

当DeviceB的接口上某个接收缓存产生拥塞时，超过一定阈值（可设定为端口队列缓存的 1/2、3/4 等比例），DeviceB即向数据进入的方向（上游设备DeviceA）发送反压信号“STOP”，如图中第7个队列。

DeviceA接收到反压信号，会根据反压信号指示停止发送对应优先级队列的报文，并将数据存储在本地接口缓存。如果DeviceA本地接口缓存消耗超过阈值，则继续向上游反压，如此一级级反压，直到网络终端设备，从而消除网络节点因拥塞造成的丢包。

显式拥塞通知（ECN）

ECN（Explicit Congestion Notification）是一种IP头部用于的拥塞控制的标记位，允许网络设备在发生拥塞时标记数据包，而不是丢弃它们。

RoCEv2利用ECN位来标记发生拥塞的数据包，接收方在检测到ECN标记后，发送CNP（Congestion Notification Packet）给发送方，后者通过拥塞控制算法（如DCQCN）调整发送速率。

数据中心量化拥塞通知（DCQCN）

DCQCN（Data Center Quantized Congestion Notification）是一种适用于RoCEv2的拥塞控制算法，是数据中心TCP(DCTCP)和量化通知算法的结合，最初在SIGCOMM’15论文”Congestion control for large scale RDMA deployments”中提出。DC-QCN算法依赖于交换机端的ECN标记。结合了ECN和速率限制机制，工作在传输层。当接收方检测到ECN标记时，触发CNP发送给发送方，发送方根据反馈调整发送速率，从而缓解拥塞。

综上，PFC、ECN、DCQCN分别工作在链路层、网络层和传输层。在RoCEv2中，它们被组合使用，以实现更高效的拥塞管理。

PFC：防止数据包在链路层被丢弃，提供无损传输，解决一段链路的问题。
ECN/DCQCN：发送方根据拥塞标记主动调整发送速率，减轻网络负载。解决端到端网络的问题。

InfiniBand 的拥塞控制机制

InfiniBand 的拥塞控制机制可分为三个主要部分：

基于信用的流量控制

IB在链路层实现基于信用的流量控制（Credit-based Flow Control），该机制实现了无损传输，是 InfiniBand 高性能的基础。发送方根据接收方提供的信用（表示可用缓冲区空间）来控制数据包的发送，接收方在处理完数据包后发送信用给发送方，以允许继续发送新的数据包，从而避免网络拥塞和数据包丢失。

如下图所示，发送方当前可用信用值2，通过流水线传输（pipelined transfer）连续向接收方发送数据包，但此时接收方缓冲区已满，发送方会暂停发送新的数据包，直到接收方发送新的信用。

ECN机制

当网络中的交换机或其他设备检测到拥塞时，会在数据包的 IP 头中标记 ECN（Explicit Congestion Notification）。接收方的 CA（Channel Adapter）接收到带有 ECN 标记的数据包后，会生成拥塞通知包（CNP），并将其反馈给发送方，通知其网络出现拥塞需要降低传输速率。

端到端拥塞控制

发送方的 CA 在收到 CNP 后，根据 InfiniBand 拥塞控制算法调整发送速率。发送方首先降低数据发送速率以缓解拥塞，之后逐步恢复发送速率，直到再次检测到拥塞信号。这个动态调整过程帮助维持网络的稳定性和高效性。IBA没有具体定义特定的拥塞控制算法，通常由厂商定制实现。（HCA，Host Channel Adapters，or IB NIC）

RoCEv2与IB拥塞控制机制比较

两者的拥塞控制机制比较如下：

可见，RoCE与IB的拥塞控制机制基本相同，区别在于IB的拥塞控制机制集成度较高，通常由单个厂家提供从网卡到交换机的全套产品，由于厂商锁定，价格高昂。而RoCE的拥塞控制机制基于开放协议，可以由不同厂家的网卡和交换机来配合完成。

随着大规模AI训练和推理集群的扩展，集合通信流量导致了日益严重的拥塞控制问题，由此出现了一些新的拥塞控制技术，如基于In-band Network Telemetry (INT)的HPCC（High Precision Congestion Control），即通过精确的网络遥测来控制流量，以及基于Clear-to-Send (CTS)的Receiver-driven traffic admission，即通过接收方的流量准入控制来管理网络拥塞等。这些新技术在开放的以太网/IP网络上更容易实现。

QoS

在RDMA网络中，不光RDMA流量要获得优先保证。一些控制报文，如CNP、INT、CTS，也需要特别对待，以便将这些控制信号无损、优先的传输。

RoCEv2的QoS

在链路层，RoCEv2采用ETS机制，为不同的流量分配不同的优先级，为每个优先级提供带宽保证。

在网络层，RoCEv2则使用DSCP，结合PQ、WFQ等队列机制，为不同的流量分配不同的优先级和带宽，实现更精细的QoS。

InfiniBand的QoS

在链路层，IB采用SL、VL及它们之间的映射机制，将高优先级的流量分配到专门的VL，优先传输。虽然VL仲裁表 (VL Arbitration Table)能够通过分配不同的权重来影响和控制带宽的分配，但这种方式不能保证每个VL的带宽。

在网络层，IB的GRH支持8个bit的Traffic Class字段，用于在跨子网的时候提供不同的优先级，但同样无法保证带宽。

由此可见，RoCE能够为不同的流量类型提供更精细的QoS 保证和带宽控制，而 InfiniBand 只能提供优先级调度，而非带宽的明确保障。

ECMP

RoCE的ECMP

数据中心IP网络为了高可靠和可扩展性，通常采用Spine-Leaf等网络架构。它们通常在一对RoCE网卡之间提供了多条等价路径，为了实现负载平衡和提高网络拓扑的利用率，采用ECMP（Equal Cost Multiple Paths）技术。对于给定的数据包，RoCE交换机使用某些数据包字段上的哈希（Hash）值在可能的多条等价路径中进行选择。由于可靠传输的要求，同一个RDMA操作应当保持在同一个路径中，以避免由于不同路径造成的乱序问题。

在IP网络中，BGP/OSPF等协议均可以在任意拓扑上计算出等价路径，然后由交换机数据平面基于IP/UDP/TCP等头部字段（如五元组）计算哈希值并轮流转发到不同路径上。在RoCE网络中，为了进一步细分RDMA操作，可以进一步识别BTH头部中的目的QP信息，从而实施更细粒度的ECMP。

InfiniBand的ECMP

在控制平面，IB的路由基于子网管理器，在拓扑发现的基础上实现ECMP，但由于集中式的子网管理器与网络设备分离，可能无法及时感知网络拓扑的变化，进而实现动态的负载均衡。

在数据平面，IB的ECMP同样基于哈希计算和轮转机制。

总结

在拥塞控制方面，RoCE结合了PFC, ECN和DCQCN提供了一套开放的方案，IB则拥有基于Credit的一套高度集成的方案，但在应对大规模集合通信流量时均有所不足。
在QoS方面，RoCE可以实现每个优先级的带宽保证，而IB仅能实现高等级的优先转发。
在ECMP方面，两者均实现了基于Hash的负载分担。

总结来看，IB具备已验证的高性能和低延时优势，RoCEv2则在互操作性、开放性、成本效益方面更胜一筹，且从市场占比及认可度来看，RoCEv2逐渐比肩IB；但不得不承认的是，RoCE和IB在应对大规模AI训练和推理中高带宽、突发式和广播型的集合通信流量时，均有所不足，而RoCE基于其广泛的以太网生态系统，能够更快速地拥抱新技术新协议，其潜力和可塑性更胜一筹，未来有望在网络格局中扮演更重要的角色。

星融元提供一系列基于RoCE的开放网络产品与解决方案：

10G-800G的全场景互联：星融元CX-N数据中心交换机的单机转发时延（400ns）低至业界平均水平的1/4~1/5；采用BGP-EVPN、VXLAN、MC-LAG等技术构建可靠的大二层网络满足生产网络稳定性需求。
搭载开放网络操作系统：星融元AsterNOS以SONiC为内核、依托容器化的系统架构，并提供RESTful API支持第三方应用快速集成，或对接上层管理调度平台，例如OpenStack，K8s等。
EasyRoCE极简运维：支持无损网络一键部署，Prometheus + Grafana 可视化监控大屏配合专用命令行，问题快速定位解决。

参考文档：

https://zhuanlan.zhihu.com/p/643007675

https://blog.csdn.net/essencelite/article/details/135492115

https://support.huawei.com/enterprise/zh/doc/EDOC1100075566/d1e17776

https://www.researchgate.net/publication/4195833_Congestion_Control_in_InfiniBand_Networks

返回资源中心

云化园区

网络操作系统（SONiC）

可视交换机

开放硬件平台

标签： 科普-AI

近期文章

DCQCN的运行条件

DCQCN与PFC的协同配置

DCQCN的应用与部署

最新动态

近期文章

为什么需要DCQCN？

DCQCN是如何工作的？

步骤 1: 拥塞检测与标记（在交换机发生）

步骤 2: 拥塞通知（接收方 -> 发送方）

步骤 3: 速率调节（在发送方发生）

DCQCN的应用与部署

最新动态

近期文章

路径综合质量评估

路径的动态WCMP调度

路径恢复与重新引入

最新动态

近期文章

智能选路的路径质量如何判定？

智能选路中的统计计数：ASIC赋能的高精度数据采集

硬件级实时监测（百毫秒级精度）

控制面高效采集（亚秒级同步）

流水线式数据处理与存储

BGP宣告的优化设计（秒级间隔）​

纳秒级时延测量：INT与HDC技术负载均衡中的深度应用

INT硬件流水线实现原理

HDC（高延迟捕获）技术深度解析

动态阈值触发机制

元数据结构化封装

落地实践：AI RoCE交换机上的智能选路

最新动态

近期文章

算力基础设施—AI 智算RoCE网络交换机

外观展示

内部架构

AI RoCE 交换机操作系统（AsterNOS）

基于企业级SONiC的增强特性

企业版 SONiC vs 社区版

800G 数据中心交换机（TL10平台）实测数据

DeepSeek模型推理指标对比：IB vs RoCE

最新动态

近期文章

智算网络的主流架构

InfiniBand

InfiniBand网络架构示意图（来源：2023智算中心网络架构白皮书）

RoCEv2

RoCEv2网络架构示意图（来源：2023智算中心网络架构白皮书）

智算网络中的负载均衡与流量控制

InfiniBand网络的负载均衡和流控机制

RoCE网络的负载均衡和流控机制

图片引用自：公众号西北吹风

负载均衡技术

流控机制

技术选型

WCMP

最新动态

关注星融元

DeepSeek的优化，精细但门槛极高

回顾：AI推理集群的PD分离和流量特征

AI推理系统的 Scale-out 组网设计

Rail-only 拓扑

小规模并行推理网络拓扑

中大规模并行推理网络拓扑

关注星融元

为什么要有轨道优化？

如何配置多轨架构的智算网络？

主机侧的路由配置

交换机侧的主动路径规划

关注星融元

什么是超级以太网系统

超以太网协议栈概览

物理层

链路层

传输层：UET，新一代协议栈的核心

标签：科普-AI

BGP宣告的优化设计（秒级间隔）