Skip to main content
开放网络的先行者与推动者—星融元
加入我们 | 技术支持(Support)  TEL:(+86)4000989811

标签： 技术实现

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

近期文章

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

拥塞控制

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

RoCEv2 的拥塞控制机制

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

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

PFC在RoCEv2中被用于创建无损的以太网环境，确保RDMA流量不因链路层拥塞而丢失。核心原理是下游控制上游某个通道开启和停止发送数据包，控制方式是发送PFC Pause和Resume帧，触发时机是根据下游SW的ingress的队列数量是否达到某个阈值。
而PFC允许在一条以太网链路上创建8个虚拟通道，并为每条虚拟通道指定一个优先等级，允许单独暂停和重启其中任意一条虚拟通道，同时允许其它虚拟通道的流量无中断通过。这一方法使网络能够为单个虚拟链路创建无丢包类别的服务，使其能够与同一接口上的其它流量类型共存。
图1 PFC工作机制
图1 PFC工作机制
如图1所示，DeviceA发送接口分成了8个优先级队列，DeviceB接收接口有8个接收缓存（buffer），两者一一对应（报文优先级和接口队列存在着一一对应的映射关系），形成了网络中 8 个虚拟化通道，缓存大小不同使得各队列有不同的数据缓存能力。
当DeviceB的接口上某个接收缓存产生拥塞时，超过一定阈值（可设定为端口队列缓存的 1/2、3/4 等比例），DeviceB即向数据进入的方向（上游设备DeviceA）发送反压信号“STOP”，如图中第7个队列。
DeviceA接收到反压信号，会根据反压信号指示停止发送对应优先级队列的报文，并将数据存储在本地接口缓存。如果DeviceA本地接口缓存消耗超过阈值，则继续向上游反压，如此一级级反压，直到网络终端设备，从而消除网络节点因拥塞造成的丢包。

  1. 显式拥塞通知（ECN）

ECN（Explicit Congestion Notification）是一种IP头部用于的拥塞控制的标记位，允许网络设备在发生拥塞时标记数据包，而不是丢弃它们。
图2 IP头部前4帧示意图
图2 IP头部前4帧示意图
RoCEv2利用ECN位来标记发生拥塞的数据包，接收方在检测到ECN标记后，发送CNP（Congestion Notification Packet）给发送方，后者通过拥塞控制算法（如DCQCN）调整发送速率。

  1. 数据中心量化拥塞通知（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 的拥塞控制机制可分为三个主要部分：

  1. 基于信用的流量控制

IB在链路层实现基于信用的流量控制（Credit-based Flow Control），该机制实现了无损传输，是 InfiniBand 高性能的基础。发送方根据接收方提供的信用（表示可用缓冲区空间）来控制数据包的发送，接收方在处理完数据包后发送信用给发送方，以允许继续发送新的数据包，从而避免网络拥塞和数据包丢失。
如下图所示，发送方当前可用信用值2，通过流水线传输（pipelined transfer）连续向接收方发送数据包，但此时接收方缓冲区已满，发送方会暂停发送新的数据包，直到接收方发送新的信用。
图3 基于信用的流量控制示意图
图3 基于信用的流量控制示意图
  1. ECN机制
当网络中的交换机或其他设备检测到拥塞时，会在数据包的 IP 头中标记 ECN（Explicit Congestion Notification）。接收方的 CA（Channel Adapter）接收到带有 ECN 标记的数据包后，会生成拥塞通知包（CNP），并将其反馈给发送方，通知其网络出现拥塞需要降低传输速率。

  1. 端到端拥塞控制

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

 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网络上更容易实现。
图5 HPCC流控示意图
图5 HPCC流控示意图
图6 CTS流控示意图
图6 CTS流控示意图

QoS

在RDMA网络中，不光RDMA流量要获得优先保证。一些控制报文，如CNP、INT、CTS，也需要特别对待，以便将这些控制信号无损、优先的传输。
  • RoCEv2的QoS
在链路层，RoCEv2采用ETS机制，为不同的流量分配不同的优先级，为每个优先级提供带宽保证。
在网络层，RoCEv2则使用DSCP，结合PQ、WFQ等队列机制，为不同的流量分配不同的优先级和带宽，实现更精细的QoS。
图7 DSCP示意图
图7 DSCP示意图
  • InfiniBand的QoS
在链路层，IB采用SL、VL及它们之间的映射机制，将高优先级的流量分配到专门的VL，优先传输。虽然VL仲裁表 (VL Arbitration Table)能够通过分配不同的权重来影响和控制带宽的分配，但这种方式不能保证每个VL的带宽。
在网络层，IB的GRH支持8个bit的Traffic Class字段，用于在跨子网的时候提供不同的优先级，但同样无法保证带宽。
由此可见，RoCE能够为不同的流量类型提供更精细的QoS 保证和带宽控制，而 InfiniBand 只能提供优先级调度，而非带宽的明确保障。

ECMP

  1.   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。

  1.   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

返回资源中心

最新动态

RoCE与IB对比分析（一）：协议栈层级篇

近期文章

在 AI 算力建设中， RDMA 技术是支持高吞吐、低延迟网络通信的关键。目前，RDMA技术主要通过两种方案实现：Infiniband和RoCE（基于RDMA的以太网技术，以下简称为RoCE）。

RoCE与IB网络架构概述

RoCE和InfiniBand均是InfiniBand Trade Association（IBTA）定义的网络协议栈，其中Infiniband是一种专为RDMA设计的高性能网络，它从硬件层面确保了数据传输的可靠性，为了进一步发挥RDMA的优势，IBTA在2010年定义了RoCE。RoCE则是Infiniband与以太网技术的融合，它在保持Infiniband核心优势的同时，实现了与现有以太网基础设施的兼容性。具体来说，RoCE在链路层和网络层与Infiniband有所不同，但在传输层和RDMA协议方面，RoCE继承了Infiniband的精髓。
从市场应用占比来看，2000年，IB架构规范的1.0版本正式发布，2015年，InfiniBand技术在TOP500榜单中的占比首次超过了50%，但据最新统计，在全球TOP500的超级计算机中，RoCE和IB的占比相当。以计算机数量计算，IB占比为47.8%，RoCE占比为39%；而以端口带宽总量计算，IB占比为39.2%，RoCE为48.5%。
图1 超级计算机 500 强中 RoCE 和 InfiniBand 的利用率
图1 超级计算机 500 强中 RoCE 和 InfiniBand 的利用率
图2 超级计算机 500 强中 RoCE 和 InfiniBand 的利用率
图2 超级计算机 500 强中 RoCE 和 InfiniBand 的利用率

RoCE与IB报文格式对比

  • RoCE报文格式下图所示：
其中，RoCEv1使用了IB的全局路由头（Global Routing Header），IB BTH是IB的基本传输头（Base Transport Header），ICRC是对InfiniBand层不变字段进行校验的循环冗余校验码，FCS是以太网链路层的校验序列码。
RoCEv2中添加了IP Header和UDP Headrer，引入IP解决了扩展性问题。
图3 RoCE数据包格式
图3 RoCE数据包格式
  • IB报文格式如下图所示：
在一个子网（Subnet）内部，只有Local Routing Header（LRH），对应OSI的链路层。在子网之间，还有一个Global Routing Header（GRH），对应OSI的网络层。在Routing Header之上，是Transport Header，提供端到端的传输服务，包括数据的分段、重组、确认和流量控制。接着就是报文的数据部分，包含应用层数据或上层协议信息。最后是不变字段和可变字段的循环冗余校验码（CRC），用于检测报文在传输过程中的错误。
图4 IB数据包格式
图4 IB数据包格式

RoCE与IB网络层级对比

IB与RoCE协议栈在传输层以上是相同的，在链路层与网络层有所区别：
RoCEv1中，以太网替代了IB的链路层(交换机需要支持PFC等流控技术，在物理层保证可靠传输)，然而，由于RoCEv1中使用的是L2 Ethernet网络，依赖于以太网的MAC地址和VLAN标签进行通信，而不涉及网络层（IP层，即OSI模型的第三层）的路由功能，因此，RoCE v1数据包不能实现跨不同的IP子网传输，只能在同一广播域或L2子网内进行传输。
RoCEv2在RoCEv1的基础上，融合以太网网络层，IP又替代了IB的网络层，因此也称为IP routable RoCE，使得RoCE v2协议数据包可以在第3层进行路由，可扩展性更优。
图5 RoCE和IB协议栈对比
图5 RoCE和IB协议栈对比

  1. 物理层

  • RoCE的物理层基于标准以太网，使用PAM4 (Pulse Amplitude Modulation 4)编码方式和64/66b编码。支持铜缆和光纤，接口有 SFP+、QSFP+ 、OSFP等。支持速率从 10GbE到800GbE。
  • IB的物理层则是专有的，采用更传统的NRZ(Non-Return-to-Zero)调制技术和64/66b编码。支持铜缆和光纤，接口通常为 QSFP、OSFP，支持速率从 10Gbps 到 400Gbps，并可以通过多通道的组合实现更高的总带宽（如 800Gbps）。
对比来看，IB采用的NRZ每个符号只有两个电平，而RoCE采用的PAM4使用 4个不同的电压电平来表示数据，也就是说RZ信号中，每个周期传输1bit的逻辑信息，PAM4每个周期可以传输2bit的信息，因此在相同的波特率下，PAM4的数据传输速率是NRZ的两倍，具有更高的带宽效率，在支持更高速率（如1.6T，3.2T）时具有潜在的优势。目前，六进制（PAM6）和八进制（PAM8）调制技术正处于实验和测试阶段，而InfiniBand（IB）也在逐渐从传统的NRZ（非归零）调制技术转型至PAM4，例如，400G光模块现已能够同时支持IB和以太网标准。相比之下，以太网在调制技术的应用上展现出更为迅速的发展势头。
图6 频域中 PAM4 与 NRZ 信号的频率内容
  图6 频域中 PAM4 与 NRZ 信号的频率内容

  1. 链路层

  • RoCE的链路层是标准以太网，为了在传统以太网上实现无损传输，引入了PFC（Priority-based Flow Control），由IEEE 802.1Qbb标准定义，当交换机的某个优先级队列的缓冲区接近满载时，会发送 PFC帧给上游设备，通知其暂停发送该优先级的流量，防止缓冲区溢出，避免数据包在链路层被丢弃。
此外，以太网引入了ETS(Enhanced Transmission Selection) ，它是DCB (Data Center Bridging)标准的一部分，由 IEEE 802.1Qaz 规范定义。ETS 将流量分配到不同的队列，为每个队列分配一个权重，控制每个流量队列能够使用的带宽百分比，保证高优先级的流量，如RDMA等，获得足够的带宽资源。
  • IB的链路层是专有的，包头称为Local Routing Header，如图所示。
配图5
其中，VL是虚拟通道 (Virtual Lanes)，SL是服务等级 (Service Level)，Source/Destination Local Identifier则是链路层地址。
它内建了对无损传输的支持，这是因为它实现了基于信用的流量控制（Credit-based Flow Control）。接收方在每个链路上提供一个信用值，表示其缓冲区能够接收的数据量。发送方根据此信用值发送数据，确保不会超过接收方的处理能力，从而避免缓冲区溢出和数据丢失。
IB链路层结合SL和VL实现QoS，SL共有16个业务等级，用于标识流量优先级，每个数据包可以根据业务需求被分配到不同的服务等级，通过SL-VL映射，将不同优先级的流量分配到不同的VL上，从而确保高优先级流量（如RDMA）不会因低优先级流量的拥塞而受到影响。
对比而言，IB的链路层由专用硬件实现，效率较高，具有超低时延的特点，而RoCE基于标准以太网硬件，时延稍长。但由于两者都达到了100ns级别，而根据UEC的最新定义，在传输RDMA时，端到端性能要求通常为10μs左右，它们的差别不大。

  1. 网络层

  • RoCE的网络层使用IP，可以是IPv4或IPv6。它采用成熟的BGP/OSPF等路由协议，适应任何网络拓扑并具有快速自愈能力；支持ECN（EXPLICIT CONGESTION NOTIFICATION ），用于端到端的拥塞控制；支持DSCP，替代IB的TRAFFIC CLASS，用于实现QoS。
  • IB的网络层借鉴了IPv6。Global Routing Header的格式与IPv6完全相同，具有128bit地址，只是字段命名不同。但它没有定义路由协议，而是采用子网管理器（Subnet Manager）来处理路由问题，这是一种集中式的服务器，每个网卡端口和交换芯片都通过由SM分配的唯一身份标识（Local ID，LID）进行识别，不具备互操作性，因此很难快速响应网络的变化。
显然，IB网络层是专有的、集中管理的，而RoCE的网络层基于标准以太网和UDP，在互联网数以十亿计算的设备上使用，技术成熟，并在持续发展中；引入SRv6等技术后，IP进一步增强了流量工程、业务链、灵活性和可扩展性等能力，非常适合组建超大规模可自愈的RDMA网络。

  1. 传输层

  1. RoCE

RoCE采用了IB的传输层。RoCEv2协议栈虽然包含UDP，但它仅借用了UDP的封装格式，传输层的连接、重传、拥塞控制等功能由IB传输层完成。UDP层的目的端口固定分配给RDMA协议，源端口则是动态分配的，但在一个连接过程中保持固定。这样可以让网络设备通过源端口区分不同的RDMA数据流。

  1. InfiniBand

IB的传输层采用了模块化的灵活设计，通常包含一个基本传输头BTH（Base Transport Header）和若干个（0到多个）扩展的传输头（Extended Transport Header）。
BTH（Base Transport Header）是InfiniBand传输层头部的一部分。它是InfiniBand网络协议中L4传输层的基本头部，用于描述数据包传输的控制信息。格式如下，
配图6
关键信息有：
  • OpCode，操作码。由8个bit组成。前3个bit代表传输服务类型，如可靠连接/不可靠连接/可靠数据报/不可靠数据报/RAW数据报等。后5个bit代表操作类型，如SEND/READ/WRITE/ACK等。
  • Destination QP，目的QP号（Queue Pair Number）。与TCP端口号类似，代表了RDMA连接（称为Channel）的目的端。但与TCP端口不同的是，QP由Send/Recv两个队列组成，但用同一个号码标识。
  • Packet Sequence Number，包序列号，简称PSN。与TCP序列号类似，用于检查数据包的传输顺序。
  • Partition Key，分区键。可以将一个RDMA网络分为多个逻辑分区。在RoCE中可采用新一代的VxLAN等技术替代。
  • ECN，显示拥塞通知。用于拥塞控制，包含Forward和Backward两个bit，分别表示在发送和返回路径上遇到了拥塞，在RoCE中被IP头部的ECN替代。
BTH帮助接收方理解该包属于哪个连接以及如何处理接收到的包，包括验证包的顺序、识别操作类型等。
在BTH之后，还有RDMA Extended Transport Header，它包含远端的虚拟地址、密钥和数据长度等信息。格式如下，
配图7
其中：
  • VirtualAddress，虚拟地址，代表目的端内存地址。
  • DMA Length，直接内存访问长度，是要读写的数据长度，以字节为单位。
  • Remote Key，用于访问远端内存的密钥。
IB传输层通常由RDMA网卡硬件实现，在IB中称为Channel Adapter（CA），在RoCE中称为RoCE网卡，从而提升RDMA传输的性能。在一些高级的RoCE交换机中，还可以感知IB传输层信息并对RDMA数据流做加速处理。

  1. RDMA操作

借助RDMA扩展头，RoCE和IB的传输层对远程主机的地址进行直接的读写操作（Operation）。
  • RDMA写操作 (RDMA Write)
在 QP（Queue Pair） 建立后可以直接进行，允许发送方直接写入接收方的内存，不需要接收方的CPU参与，并且无需请求。这种操作方式是 RDMA 高性能和低延迟的核心特性之一。
RDMA Write 是一种单向操作。写入方在写入数据后不需要等待接收方的响应，这种操作与常规的 Send/Receive 模式不同，不需要接收方预先准备接收队列。
  • RDMA读操作 (RDMA Read)
允许发送方从接收方的内存中读取数据，不需要接收方CPU参与。目标地址和数据大小在发送方指定。如下图所示，在一次请求后，可以通过多次响应返回数据,提高了数据传输效率。
图7 RDMA 读操作
图7 RDMA 读操作
  • 发送/接收操作 (Send/Receive)
这是传统的消息传递操作，数据从发送方传递到接收方的接收队列中，需要接收方预先准备接收队列。
在RoCE中，RDMA跳过操作系统的TCP/IP协议栈，直接与RoCE网卡上的传输层连接，借助DMA机制，直接访问本地和远端内存，实现了零拷贝传输，大幅度提升了性能。
配图9
同样，IB网卡在硬件上实现RDMA操作，零拷贝传输，两者的性能相当。
当然，无论在RoCE还是IB中，RDMA 连接的初始化、资源分配、队列对 (QP) 管理、以及一些控制路径上的操作（如连接建立、内存注册等）仍然依赖于软件栈。

  1. 应用层

RDMA在数据中心、HPC集群、超级计算机中获得了广泛的应用，用于承载AI训练、推理、分布式存储等数据中心内部的关键业务。
例如，在AI训练/推理时， xCCL或者MPI使用RDMA实现点对点和集合通信；在分布式存储时，NVMEoF, Ceph使用RDMA对网络存储器进行读写操作。

  1. 网络层级对比小结

  • 在物理层，RoCE和IB都支持800G，但PAM4相比NRZ具有更强的升级潜力，以太网成本也低于IB，RoCE更胜一筹。
  • 在链路层，两者均实现了无损传输，RoCE的ETS能够为不同优先的流量提供带宽保证，且RoCE和IB的时延均达到了100ns级别，在实际应用中差不大。
  • 在网络层，RoCE借助IP的成熟的持续发展，更能适应大规模网络。
  • 传输层及以上，RoCE和IB使用同样的协议，没有区别。

RoCE与IB的较量，究竟谁更胜一筹

总的来说，RoCE和InfiniBand都由IBTA定义，没有本质的不同。RoCE实际上是将成熟的IB传输层和RDMA移植到了同样成熟的以太网和IP网络上，是一种强强联合，在保持高性能的同时，降低了RDMA网络的成本，能够适应更大规模的网络。
根据亚马逊的高级首席工程师Brian Barrett，AWS之所以放弃IB方案，主要是因为：“云数据中心很多时候是要满足资源调度和共享等一系列弹性部署的需求，专用的IB网络构建的集群如同在汪洋大海中的孤岛”。
出于AI算力建设对于成本和开放性的考量，越来越多的公司已经在使用以太网交换机用于大规模AI算力中心，例如当前全球最大的AI超级集群（xAI Colossus，造价数亿美元、配备十万片NVIDIA H100 GPU），便是采用64 x 800G，51.2T以太网方案构建集群网络。
CX864E-N是星融元专为AI训练、推理、高性能计算（HPC）等场景设计的一款行业内顶尖规格的RoCE交换机，拥有51.2T的超大交换容量，助力客户用更优的投入成本，实现与IB网络相当的性能。
CX864E-N
CX864E-N
  • 8 x CX864E 支持 512 个 GPU 互连，每个端口速度为 400G
  • 192 x CX864E 支持 8192 GPU 互连，每个端口速度为 400G
  • 192 x CX864E 支持 128k ML/AI 节点互连，每端口速度为 100G

参考文献

https://mp.weixin.qq.com/s/PZ_Q5rS5a5YJlczao9SMXw
https://support.huawei.com/enterprise/zh/doc/EDOC1100203347
https://community.fs.com/cn/article/roce-technology-in-high-performance-computing.html
https://ascentoptics.com/blog/cn/understanding-infiniband-a-comprehensive-guide/
https://blog.csdn.net/jkh920184196/article/details/141461235
https://www.servethehome.com/inside-100000-nvidia-gpu-xai-colossus-cluster-supermicro-helped-build-for-elon-musk/

返回资源中心

最新动态

AI算力租赁

一文梳理：如何构建并优化AI智算中心？

关注星融元

目前最常见的AI算力中心部署的GPU集群大小为 2048、1024、512 和 256，且部署成本随 GPU 数量线性增长。本文将以相对折中的1024 GPU卡（H100）的规模为例展开分析。

01 计算节点的选型

计算节点是AI算力中心的建设报价中最昂贵的部分，一开始拿到的 HGX H100 默认物料清单（BoM）往往使用的是顶级配置。不同于 DGX 是 NVIDIA 的系统品牌，HGX 作为 NVIDIA 授权平台允许合作伙伴构建定制的GPU系统。那么，根据业务实际所需，我们可从以下几个方面尝试优化成本。
组件和服务数量
接近顶级性能的英特尔 Emerald Rapids 处理器2
8 H100 +4 NVSwitch HGX Baseboard + 8 SXM5 Heatsinks1
CPU RAM (per Gbyte)2048
Storage (per TByte)30
后端 ConnectX-7 NIC80
Bluefield-3 DPU2
主板1
机箱（机箱、布线等）1
冷却（CPU 散热器 + 风扇）1
电源8
组装&测试1
OEM 增值/附加费用1
合计费用（$)270000+

1、选择中端CPU

LLM 训练是一项 GPU 高度密集型工作负载，对 CPU 工作负载要求低。CPU 运行是一些简单任务，例如 PyTorch ，控制 GPU 的其他进程、初始化网络和存储调用，或者运行虚拟机管理程序等。Intel CPU 相对更容易实现正确的 NCCL 性能和虚拟化，而且整体错误更少。如果是采用AMD CPU ，则要用 NCCL_IB_PCI_RELAXED_ORDERING 并尝试不同的 NUMA NPS 设置来调优。

2、 RAM 降级到 1 TB

RAM 同样是计算节点中相对昂贵的部分。许多标准产品都具有 2TB 的 CPU DDR 5 RAM，但常规的AI工作负载根本不受 CPU RAM 限制，可以考虑减配。

3、删除 Bluefield-3 或选择平替

Bluefield-3 DPU最初是为传统 CPU 云开发的，卖点在于卸载CPU负载，让CPU用于业务出租，而不是运行网络虚拟化。结合实际，奔着GPU算力而来的客户无论如何都不会需要太多 CPU 算力，使用部分 CPU 核心进行网络虚拟化是可以接受的。此外Bluefield-3 DPU 相当昂贵，使用标准 ConnectX 作为前端或采用平替的DPU智能网卡完全可满足所需。
综合考虑前述几项成本优化，我们已经可为单个服务器降低约5%的成本。在拥有 128 个计算节点的 1024 H100 集群中，这个比率背后的金额已经相当可观。

4、减少单节点网卡数量（谨慎选择）

标准物料清单中，每台 H100 计算服务器配备八个 400G CX-7() NIC，单服务器的总带宽达到 3,200Gb/s。如果只使用四块网卡，后端计算网的带宽将会减少 50%。 这种调整显而易见可以节约资金，但多少会也对部分AI工作负载性能造成不利影响。

02 集群网络的选型

集群网络是继计算节点之后的第二大成本来源。本文举例的 NVIDIA H100 集群有三种不同的网络：
  • 后端网络（计算网，InfiniBand 或 RoCEv2） 用于将 GPU 之间的通信从数十个机架扩展到数千个机架。该网络可以使 InfiniBand() 或 Spectrum-X 以太网，也可以使用其他供应商的以太网。
  • 前端网络（业务管理和存储网络） 用于连接互联网、SLURM/Kubernetes() 和网络存储以加载训练数据和Checkpoint。该网络通常以每 GPU 25-50Gb/s 的速度运行，满配八卡的情况每台GPU服务器的带宽将达到 200-400Gb/s。
  • 带外管理网络 用于重新映像操作系统、监控节点健康状况（如风扇速度、温度、功耗等）。服务器上的BMC、机柜电源、交换机、液冷装置等通常连接到此网络以监控和控制服务器和各种其他 IT 设备。
组件和服务数量
InfiniBand 计算网
Quantum-2 IB 交换机（MQM9700）48
Nvidia LinkX IB 400G 单端口 SR4 收发器 (MMA4Z00-NS4400)1024
Nvidia LinkX 800G 双端口 SR8 收发器 (MMA4Z00-NS)1536
Nvidia LinkX 400G 多模光纤3072
前端光纤架构成本
Spectrum Ethernet Switch (SN4600)6
Nvidia LinkX 200G QSFP56 AOC 收发器384
Nvidia LinkX 200G 收发器256
Nvidia LinkX 100G 多模光纤512
带外管理网
1GbE Spectrum Ethernet Switch (SN2201)4
RJ45 Cables232
合计($)490000+

1、计算网络：RoCEv2替代IB

与量大管饱的以太网解决方案相比，NVIDIA 提供的InfiniBand无疑更昂贵，但一些客户依旧笃定认为以太网性能要低得多，这主要是因为以太网需要进行必要的无损网络参数配置并且针对性调优才能发挥集合通信库的性能。
不过从对业务性能的影响角度看，目前技术背景下使用IB或是RoCEv2作为后端计算网没有并太多差异。毕竟 RoCE 实际上只是将成熟的IB传输层和RDMA移植到了同样成熟的以太网和IP网络上，这一点我们将在往后的另一篇文章来分析阐述。
计算网络：RoCEv2替代IB
计算网络：RoCEv2替代IB
大规模算力场景中用以太网替代IB组成高性能无损网络已形成业内共识，行业热点早已转向了如何更好地薅“以太网羊毛”：例如从以太网标准入手，推出下一代面向AI场景的新协议，以及一些厂商立足于现有协议标准在简化RoCE网络配置和提高可视化能力上做的创新尝试。
参阅： Easy RoCE：在SONiC交换机上一键启用无损以太网
无论是在AI训推的测试场景，还是头部云厂商已有的工程实践里，AI以太网都有了大量案例可供参考。
据统计，在全球 TOP500 的超级计算机中，RoCE和IB的占比相当。以计算机数量计算，IB 占比为 47.8%, RoCE 占比为 39%; 而以端口带宽总量计算，IB占比为 39.2%,RoCE 为 48.5%。与IB相比，我们相信有着开放生态的以太网将会得到加速发展。
目前市场上提供适用于AI场景的高性能以太网交换芯片平台主要有Broadcom Tomahawk、Marvell Teralynx和Cisco Silicon One 等，NVIDIA Spectrum 芯片仅用于Spectrum-X平台，不单独销售。以上平台都推出了51.2T，800GbE/s的尖端型号，综合来看部署数量上 Tomahawk 明显占优，转发时延性能表现 Teralynx 更胜一筹。
各家厂商芯片规格对比
各家厂商芯片规格对比

2、前端网络：合理降低带宽速率

NVIDIA 和一些OEM/系统集成商通常会在服务器提供 2x200GbE 前端网络连接，并使用 Spectrum Ethernet SN4600 交换机部署网络。
我们知道，这张网络仅用于进行存储和互联网调用以及传输基于 SLURM，Kubernetes 等管理调度平台的带内管理流量，并不会用于时延敏感和带宽密集型的梯度同步。每台服务器 400G 的网络连接在常规情况下将远超实际所需，其中存在一些成本压缩空间。

3、带外管理网络：选用通用的以太网交换机

NVIDIA 默认物料清单一般包括 Spectrum 1GbE 交换机，价格昂贵。带外管理网络用到的技术比较通用，选择市场上成本更优的 1G 以太网交换机完全够用。

03 计算网络的架构优化

GPU集群计算网将承载并行计算过程中产生的各类集合通信（all-reduce，all-gather 等），流量规模和性能要求与传统云网络完全不同。
参阅：揭秘AI智算中心网络流量 – 大模型训练篇
NVIDIA 推荐的网络拓扑是一个具有无阻塞连接的两层胖树网络，理论上任意节点对都应该能同时进行线速通信。但由于存在链路拥塞、不完善的自适应路由和额外跳数的带来的通信延迟，真实场景中无法达到理论最优状态，需要对其进行性能优化。

轨道优化（Rail-optimized）架构

轨道优化架构下，4台服务器的32张 GPU 卡不再是连接到 TOR 交换机，而是来自32台服务器的同卡号 GPU 连接各自的轨道交换机——即32台服务器的所有 GPU#0 都连接到 Leaf 交换机#0，所有 GPU#1 都连接到 Leaf 交换机#1，依此类推。
轨道优化（Rail-optimized）架构
轨道优化（Rail-optimized）架构
轨道优化网络的主要优势是减少网络拥塞。因为用于 AI 训练的 GPU 会定期并行底发送数据，通过集合通信来在不同GPU之间交换梯度并更新参数。如果来自同一服务器的所有 GPU 都连接到同一个 ToR 交换机，当它们将并行流量发送到网络，使用相同链路造成拥塞的可能性会非常高。
星融元（Asterfusion）给出的1024卡，128计算节点 Scale-out 网络方案正是基于轨道优化后的架构，其中采用了24台 CX864E-N（51.2T的单芯片盒式交换机，8台作为Spine，16台作为Leaf），产生跨节点通信的同卡号GPU之间只会相距一跳。
参阅：星融元发布 51.2T 800G 以太网交换机，赋能AI开放生态
星融元（Asterfusion）CX864E-N交换机
星融元（Asterfusion）CX864E-N交换机
Scale-out网络
Scale-out网络
如果追求极致的成本优化，对于一个32到128个节点的计算集群甚至可以设计只有单层轨道交换机的Rail-only网络，理论上建网成本可以节约高达75%。
来源：星融元（Asterfusion）星智AI网络解决方案
来源：星融元（Asterfusion）星智AI网络解决方案

确定合适的超额订阅率

轨道优化拓扑的另一个好处可以超额订阅（Oversubscription）。在网络架构设计的语境下，超额订阅指的是提供更多的下行容量；超额订阅率即下行容量（到服务器/存储）和上行带宽（到上层Spine交换机）的比值，在 Meta 的 24k H100 集群里这个比率甚至已经来到夸张的7:1。
通过设计超额订阅，我们可以通过突破无阻塞网络的限制进一步优化成本。这点之所以可行是因为 8 轨的轨道优化拓扑里，大多数流量传输发生在 pod 内部，跨 pod 流量的带宽要求相对较低。结合足够好的自适应路由能力和具备较大缓冲空间的交换机，我们可以规划一个合适的超额订阅率以减少上层Spine交换机的数量。
但值得注意的是，无论是IB还是RoCEv2，当前还没有一个完美的方案规避拥塞风险，两者应对大规模集合通信流量时均有所不足，故超额订阅不宜过于激进。（而且最好给Leaf交换机留有足够端口，以便未来 pod 间流量较大时增加spine交换机）
现阶段如果是选用基于以太网的AI网络方案我们仍推荐1：1的无阻塞网络设计。

04 NVMe 存储

物理服务器数量

为了实现高可用性，大多数存储厂商都会建议部署至少 8 台存储服务器。8 台存储服务器每台可提供 250GB/s 到 400GB/s 的存储带宽，足以满足在 1024 台 H100 上运行的 AI 工作负载。我们可以从最小可用数量开始，但需要注意在存储系统上留出足够的端口、NVMe 驱动器托架、电源和机架空间，以便后续按需扩展。

存储网络

常见的方案是构建专门的200G无损以太网作为存储网络以确保性能，存储前后端网络在物理上合一。
存储网络
来源：星融元（Asterfusion）
存储服务器也可以在后端计算网上运行——通常是将IB网卡绑定到 GPU 0来充当存储网卡。虽然存储基准测试的延迟和带宽表现很好，但在实际AI工作负载中将影响 GPU 0 的性能（IB网卡同时作为存储网卡会有流量冲突）。当存储集群中的磁盘发生故障将触发重建，会在计算网上造成大量的流量，形成更严重的拥塞。

05 带内管理

为了运行高可用的 UFM 和 CPU 管理节点，我们建议部署至少两个通用 x86 服务器，使用25GE/10GE以太网链路连接所有计算节点和管理节点，并接入外部网络。
带内管理
业务管理网络
来源：星融元（Asterfusion）
默认的NVIDIA Superpod 架构中包含了“NVIDIA AI Enterprise”或“Base Command Manager (BCM)”，其建议零售价为4,500 美元/GPU。BCM 是一个提供 AI 工作流和集群管理的软件包，这一部分软件费用可以考虑剔除后选择其他平替方案，或交由用户自定义。
此外带内管理系统还涉及到其他 IT 设备，例如防火墙、机架、PDU 等，这部分价格不会显著增加集群建设支出。

06 带外管理

带外管理系统主要是通过智慧平台管理接口（IPMI）去监视、控制和自动回报大量服务器的运作状况。IPMI可独立于操作系统外自行运作，并允许管理者在受监控的系统未开机但有接电源的情况下进行远程管理，但这种监控功能主要集中在硬件级别。
不同于带内管理，带外管理构建了单独的网络承载物理设备管理流量，不会承载业务流量。我们一般是每GPU计算节点和存储节点配置1条1 GE 链路连接IPMI和后端管理平台。
带外管理
07 驱动和业务调度程序

GPU驱动程序

必要的 GPU 驱动程序有 cuda-drivers-5xx 和 fabricmanager-5xx 以及 cuda-toolkit-12-x。
  • Cuda-drivers-5xx 是 ubuntu/Linux 与 GPU 交互所需的内核空间驱动程序
  • fabricmanager-5xx 是一个负责配置节点内 NV 链路结构
  • Cuda-toolkit-12-x 包含所有用户空间工具和 API

网络驱动程序

MLNX_OFED

每个 GPU 服务器上都需要安装 Mellanox OpenFabrics Enterprise Distribution (MLNX_OFED) 驱动程序。此软件包是 ConnectX-7 InfiniBand NIC 的驱动程序，用于执行 RDMA（远程直接内存访问）和 OS 内核旁路。

GPU Direct RDMA

这是一个包含在 cuda-drivers-5xx 中的附加内核驱动程序，默认情况下未启用。如果没有此驱动程序，GPU 将需要先在 CPU RAM 中缓冲消息后才能发送到 NIC。
启用 GPUDirect RDMA 的命令是 sudo modprobe nvidia-peermem。

NVIDIA HPC-X

主要用于进一步优化 GPU 与 NIC 的通信。
如果没有上述软件包，GPU 只能以 80Gbit/s 的速度收发流量，启用这些软件包后点对点收发速率应可达到 391Gb/s左右。

业务调度和启动程序

绝大部分的最终用户会希望拥有一个开箱即用的调度程序，可以基于SLURM 、K8s 或者其他供应商的软件平台。从0到1手动安装并调试以上平台，对于不是专精于此的工程师至少需要花费1-2天时间，因此闲置的 GPU 资源对于客户都是实打实的支出。

08 多租户隔离

参考传统CPU云的经验，除非客户长期租用整个GPU集群，否则每个物理集群可能都会有多个并发用户，所以GPU云算力中心同样需要隔离前端以太网和计算网络，并在客户之间隔离存储。
基于以太网实现的多租户隔离和借助云管平台的自动化部署已经有大量成熟的方案。如采用InfiniBand方案，多租户网络隔离是使用分区密钥 (pKeys) 实现的：客户通过 pKeys 来获得独立的网络，相同 pKeys 的节点才能相互通信。

09 GPU的虚拟化

与传统CPU云不同的是，AI用途的GPU云租户通常会将每个 GPU 计算节点作为一个整体来租用，深入到节点内部的更细粒度的虚拟化并无绝对必要。但为了进一步提高GPU资源利用率，很多人还是会选择GPU虚拟化，目前，GPU虚拟化技术一般分为三种：软件模拟、直通独占(pGPU)、直通共享（如vGPU、MIG）。
AI算力租赁场景的虚拟化程度一般是到单卡层次，即直通独占（pGPU）——利用 PCIe 直通技术，将物理主机上的整块GPU显卡直通挂载到虚拟机上使用，原理与网卡直通类似，但这种方式需要主机支持IOMMU()。（一种内存管理单元，它将具有直接存储器访问能力的I/O总线连接至主内存。如传统的MMU一样，IOMMU将设备可见的虚拟地址映射到物理地址）
pGPU直通方式相当于虚拟机独享GPU，硬件驱动无需修改。因为没有对可支持的GPU数量做限制，也没有阉割GPU功能性，大多数功能可以在该直通模式下无修改支持。
GPU虚拟化
值得一提的是，NCCL 和 NVIDIA 驱动程序在 GPU 虚拟机内运行时无法自动检测 NUMA 区域和 PCIe 拓扑，需要通过 NCCL_TOPO_FILE 变量手动传递 /etc/nccl.conf中的 NUMA 区域和 PCIe 拓扑文件，否则 NCCL 性能将仅以应有带宽的 50% 运行。

10 监控方案

监控面板

在监控方面，我们至少建议通过 Prometheus + Grafana 构建一个集中的监控面板，以便用户跟踪 GPU 温度、电源使用情况等BMC指标，XID错误，甚至将业务和网络统一监测。
计算节点的监控包括在每个 GPU 节点上安装一个 IPMI 和 DCGM Exporter，然后在管理节点上部署 Prometheus 与 GPU 上的 Exporter 通信，并将数据存储在数据库中。Grafana 连接到 Prometheus 对收集来的数据进行可视化呈现。
网络侧的监控类似，在这种场景下采用SONiC交换机的优势明显，因其软件环境本身就是开放的容器化架构，我们能以 docker 形式在交换机运行 exporter 取得所需设备状态数据，还可借助RESTful API调用网络能力集成进上层管理平台。
监控面板
另外，结合带内网络遥测（INT）能力还可对RoCE网络实现亚秒级的精细监控，用以辅助网络拥塞控制。
星融元提供的Prometheus+ Grafana监控工具
来源：星融元提供的Prometheus + Grafana 毫秒级 RoCE 监控方案

常见错误

  • 诊断消息（dmesg）两个常见 dmesg 消息是电缆被拔出以及 NIC 或者光收发器过热。
  • 静默数据损坏 （SDC）没有收到诊断消息等错误报告，但却输出错误的矩阵乘法结果。这些错误称为静默数据损坏 (SDC)。确定 GPU 上是否有该问题的最简单方法是使用 Nvidia DCGMI 诊断级别 4 工具 sudo dcgmi diag -r 4。该工具将捕获 95% 的最常见静默数据损坏问题。
  • NCCL故障 常见NCCL故障包括死锁和停滞，可能会导致训练作业暂停 30-35 分钟， 而后 PyTorch 的 NCCL watchdog 会终止整个训练作业。对此可以考虑添加电力消耗监控来检查AI作业是否正常运行。更多NCCL排障请参考：https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting.html
  • Infiniband UFM 的错误代码 常见如 110（符号错误）、112（链接中断）、329（链接中断）、702（端口被视为不健康）和 918（符号位错误警告）。遇到上述任何错误代码，应立即联系网络技术工程师进一步调查。

11 部署验收和日常维护

集群规模的验收测试应持续至少 3-4 周，尽可能排除早期失效期出现的节点组件故障。AI训练非常依赖网络、HBM() 和 BF16/FP16/FP8 张量核心，而目前常用的高性能计算测试工具，例如LINPACK（国际上使用最广泛的测试浮点性能的基准测试）不会大量使用网络，也不会占用太多 GPU 的 HBM 内存，而是仅使用和测试 GPU 的 FP64 核心。稳妥起见，我们建议验收测试尽量以模拟真实业务的方式展开。

NCCL-TEST

nccl-test 工具是 NVIDIA 开源的一项用于测试 NCCL 集合通信的工具，我们建议在正式运行业务之前先使用nccl-test来检测集合通信是否正常、压测集合通信速率等，看看否存在任何性能不足或下降。关于nccl-test日志的分析我们将在接下来的主题中展开。

日常维护

集群中最常见的问题包括收发器抖动、GPU掉线、GPU HBM 错误和 SDC等。大多数情况下，这些问题只需简单地启动物理服务器的硬重启，或者断电后重启即可解决。重新插拔收发器或清除光纤电缆上的灰尘也可以解决一些意外故障。更复杂的情况请交给厂商技术服务团队处理。

星融元CX102S-DPU开放智能网关-下载页面

留资下载

Mellanox网卡驱动封-面图

Mellanox网卡驱动安装

Mellanox网卡驱动安装

1 目标

本文档以CentOS7.6为例，详细介绍了Mellanox网卡MLNX_OFED的驱动安装和固件升级方法。

2 下载驱动

该方法适用于CentOS、RHEL、SLES、Ubuntu、EulerOS等操作系统，在安装不同操作系统的驱动时，请下载对应操作系统版本的驱动。

首先根据系统发行版本下载对应的驱动，下载地址如下：https://www.mellanox.com/page/products_dyn?product_family=26&mtag=linux_sw_drivers&ssn=q80crdrodvb8ce021n94ep58f1

注意选择download，根据相应的版本选择相应的驱动，点击后要同意协议再下载。

根据不同操作系统，选择相对应的安装驱动
图1
选好安装驱动后，同意协议
图2

本次下载的驱动版本为：MLNX_OFED_LINUX-4.7-3.2.9.0-rhel7.6-x86_64.tgz

3 安装步骤

3.1 把下载好的Mellanox驱动解压缩

[root@localhost ~]# tar –zxvf MLNX_OFED_LINUX-4.7-3.2.9.0-rhel7.6-x86_64.tgz
[root@localhost ~]# cd MLNX_OFED_LINUX-4.7-3.2.9.0-rhel7.6-x86_64

3.2 查看当前系统的内核版本

[root@localhost MLNX_OFED_LINUX-4.7-3.2.9.0-rhel7.6-x86_64]# uname -r
3.10.0-957.el7.x86_64

3.3 查看当前驱动所支持的内核版本

[root@localhost MLNX_OFED_LINUX-4.7-3.2.9.0-rhel7.6-x86_64]# cat .supported_kernels 
3.10.0-957.el7.x86_64

注：由以上可知下载的默认驱动支持当前的内核版本

3.4 如果当前内核与支持内核不匹配

手动编译适合内核的驱动，在编译之前首先安装gcc编译环境和kernel开发包

[root@localhost MLNX_OFED_LINUX-4.7-3.2.9.0-rhel7.6-x86_64]#yum  install gcc gcc-c++
libstdc++-devel kernel-default-devel

添加针对当前内核版本的驱动

[root@localhost MLNX_OFED_LINUX-4.7-3.2.9.0-rhel7.6-x86_64]#./mlnx_add_kernel_support.sh -m /root/MLNX_OFED_LINUX-4.7-3.2.9.0-rhel7.6-x86_64  -v

注：完成后生成的驱动文件在/tmp目录下

[root@localhost MLNX_OFED_LINUX-4.7-3.2.9.0-rhel7.6-x86_64]# ls -l /tmp/MLNX_OFED_LINUX-4.7-3.2.9.0-rhel7.6-x86_64-ext.tgz
-rw-r--r-- 1 root root 282193833 Dec 23 09:49 /tmp/MLNX_OFED_LINUX-4.7-3.2.9.0-rhel7.6-x86_64-ext.tgz

3.5 安装驱动

[root@localhost tmp]# tar xzvf MLNX_OFED_LINUX-4.7-3.2.9.0-rhel7.6-x86_64-ext.tgz
[root@localhost tmp]# cd MLNX_OFED_LINUX-4.7-3.2.9.0-rhel7.6-x86_64-ext
[root@localhost tmp]# ./mlnxofedinstall

3.6 最后启动openibd服务

[root@localhost ~]#/etc/init.d/openibd start
[root@localhost ~]#chkconfig openibd on

4 结论

Mellanox网卡驱动安装主要根据内核是否匹配分为下载后直接安装和编译安装两部分。

5 参考资料

  1. Mellanox官网：https://www.mellanox.com

点击了解Asterfusion CX-N数据中心交换机

如有其它问题，请填写右侧需求表单联系我们。

AI/ML

0成本5分钟！利用开源大模型搭建本地专属AI知识库

关注星融元

你一定经历过各种通用大模型一本正经胡说八道的时候吧，AI一通丝滑输出让人真假难辨，防不胜防。这种情况被称为AI幻觉。

大模型产生幻觉不幸“翻车”的原因很大程度上是“先天不足”，例如训练时来自特定领域的训练数据就比较缺失或存在偏差等。对于企业，AI的幻觉已经成为阻碍其落地应用的严重缺陷。

我们自然想让一些企业内部私有数据也进入到大模型推理分析的过程，让其更好服务于日常业务，但出于信息安全等考量，私有数据显然不可随意上传到第三方平台。针对这种情况，将企业内部知识库和大模型连接起来构建一个本地私有化的专属的AI知识库不失为一种简易的解决方案。

构建本地私有知识库的基本步骤

1. 整理出需要模型分析的私有数据，比如文本数据（doc、csv、ppt…），音视频数据，甚至一些网址链接。

2. 通过一个嵌入模型将这些信息转换成模型能够看得懂的向量信息，即信息的向量化。

3. 将向量化的信息存储到专属的向量数据库中，构建本地知识库。

这个时候当用户提问时，我们引入的通用大模型将会结合本地知识库中所存在的信息有针对性的回答，甚至也可以专门分析本地知识库中的信息来输出。

本地私有知识库构建

本地AI知识库的安装和配置

AnythingLLM 是一款构建本地知识库的工具，能够直接读取文档并处理大量信息资源，包括文档上传、自动抓取在线文档，然后进行文本的自动分割、向量化处理，以及实现本地检索增强生成（RAG）等功能。

AnythingLLM支持几乎所有的主流大模型和多种文档类型，可定制化程度高，安装设置简单，适用于MacOS、Linux和Windows平台，也可以使用Docker安装。AnythingLLM默认通过Ollama来使用LLama2 7B、Mistral 7B、Gemma 2B等模型，也可以调用OpenAI、Gemini、Mistral等大模型的API服务。除AnythingLLM以外，近期较为热门的知识库工具还有MaxKB、RAGFlow、FastGPT、Dify 、Open WebUI 等。

01、下载并安装Ollama（用于下载各类通用大模型）

访问 https://ollama.com/download 选择所需版本

下载安装Ollama

02、安装大模型和嵌入模型

我们示例中选择的是通义千问大模型和M3e嵌入模型，大家也可以根据自己的需要选择其他模型下载。Ollama支持的模型列表及资源占用情况可从官网查阅：https://ollama.com/library

安装大模型

嵌入大模型

03、下载并安装AnythingLLM

访问 https://anythingllm.com/download 选择对应版本

下载AnythingLLM

04、配置AnythingLLM

配置参数选择Ollama

配置Ollama

Embedder选择M3e

Embedder选择M3e

向量数据库选择LanceDB（默认）

向量数据库选择LanceDB（默认）

上传私有数据并验证AI问答效果

至此，一个AI驱动的本地私有知识库的基本架构已经搭建完成。接下来我们需要创建工作区，上传各种文档格式的企业私有数据，验证是否能正常工作。

上传

上传

上传

01、csv表格

随意生成一份原始数据如下：

对话结果（对数据进行排序和筛选）：

02、docx文档

原始数据是星融元AsterNOS网络操作系统的文档，其中涉及到高可靠特性的部分如下。

文档

对话结果：

结果

03、网址

星融元CX-N超低时延交换机在官网的产品详情页，涉及到产品特性的片段如下。

特性

对话结果：

检验结果

可以看到，这个本地AI知识库已经在利用我们上传的私有文本数据回答问题了，下一步您需要持续不断地丰富私有内容，让其更加智能、可靠；大型企业则更需要对其“悉心调教”，例如充分考虑本地AI推理系统的并发接入性能，在网络基础设施上进行相应调整和升级，也要关注和其他内部工具的集成。

AP-banner

一文读懂：企业园区无线网技术及部署指南

关注星融元

前言：无线网络直接影响整体网络性能，在当今企业网环境中，已有超过一半的数据流量通过无线信道传输，随着物联网技术的普及，无线网将承载更多的关键业务流量。企业/园区场景的无线网络值得考虑的关键因素有很多，例如终端移动性，AP 漫游能力和覆盖范围、带宽和吞吐量、延迟、信道、射频干扰等。当然，还有网络安全配置和用户认证等等。

无论是新建还是升级无线网络，在采取行动之前回顾并更新有关无线网的关键知识是绝对必要的，我们将从以下几个方面入手，希望这篇文章帮助您做出更好的选择。

  • 无线网络基础概念和参数速查
  • 无线标准/协议的演进
  • 不同无线组网模式和适用场景
    ○ 常见的园区无线组网
    ○ 新一代云化网络
  • 无线AP部署要点

无线网基础概念和参数速查

在无线通信系统中，信息可以是图像、文字、声音等。信息需要先经过信源编码转换为便于电路计算和处理的数字信号，再经过信道编码和调制，转换为无线电波发射出去。其中，发送设备和接收设备使用接口和信道连接，对于有线通信很容易理解，设备上的接口是可见的，连接可见的线缆；而对于无线通信，接口是不可见的，连接着不可见的空间，称为空口(空间接口)

无线网络分类

无线网络根据应用范围可分为个人网络、局域网、城域网和广域网。

 个人网络 局域网 城域网 广域网
协议标准 BluetoothIEEE802.11b,IEEE802.11a,IEEE802.11g, IEEE802.11nIEEE 802.16，MMDS，LMDSGSM, GPRS, CDMA, 2.5-3G-4G
传输速度 小于1Mbps1Mbps~600Mbps22+ Mbps1-7Mbps-100Mbps
覆盖范围 10m100~300m十几公里几十到几百公里
应用场景 点对点、设备对设备企业、园区、学校、酒店等网络最后一公里接入移动电话

无线射频

无线电波是由振荡电路的交变电流产生的电磁波（日常使用中也被称为射频或无线电等），它能够通过天线发射和接收，无线电波的频率范围称为频段。所有的射频设备都有灵敏度等级，即无线终端在某个信号强度之上可以正确地解释和接收无线电信号。灵敏度单位是dBm。接收灵敏度值越小，说明接收性能越好。

常见无线频段
手机 GSM:900/1800MHz,CDMA:800MHz
5G方案 移动(2.6G 160MHz)/3.3G 100MHz室内共建，电信、联通3.5G 3400-3600MHz移动：4800-4900MHz，广电4900-5000MHz
调频87.5MHz-108.0MHz（民用广播）
70MHz-87.5MHz（校园广播）
108-160MHz（业余无线电通讯）
160MHz以上是对讲机和电视伴音通信频率，对讲机常集中在400~470MHz和136-174MHz
无绳电话 45~48MHz
无线网络 2.4GHz和5GHz( Wi-Fi 7还有6GHz )
蓝牙 2.4GHz

天线传播覆盖

天线是一种变换器，是在无线设备中用来发射或接受电磁波的部件，它可以将传输线上传播的导行波和在空间中传播的电磁波相互转换。天线一般有全向和定向两种信号覆盖模式（如下图所示）。

天线传播覆盖

空间流和MIMO

无线电在同一时间发送多个信号，每一份信号都是一个空间流。通常情况下一组收发天线间可以建立一个空间流。

MIMO指多输入多输出技术，也称多天线技术，分别使用多个发射天线和接收天线，实现多发多收，成倍地提高信道容量。空间流数是决定最高物理传输速率的参数。我们常用(AxB:C)数据格式表示多天线技术支持的最大发射天线数量(A)、最大接收天线数量(B)和最大空间数据流数量(C)。当前主流的802.11ac和802.11ax协议规定一个射频最大8个空间流；大多数智能终端使用 2×2:2 或 3×3:3 MIMO 无线电。

MIMO

MIMO系统中，发射端的多个天线可以各自独立发送信号（引入发射波束成形技术使多个天线的发射信号在接收机达到相同相位，从而增强信号强度），同时在接收端用多个天线接收信号并重组原始信息。

MIMO技术让1x1的客户端也能间接从中受益

MIMO技术让1×1的客户端也能间接从中受益

传播衰减

⑴ 自由空间路径损耗

自由空间路径损耗(FSPL)是指无线电波因自然扩展导致信号强度下降，这是波传播的自然属性。我们可以通过以下近似公式算出。

FSPL=32.44+(20log 10 (f))+(20log 10 (D))

FSDL=路径损耗(dB) ；f =频率(MHz)；D=天线之间的距离(km)

实际部署时我们通常使用6dB法则进行估算，即：传输距离加倍将导致信号衰减6dB。

⑵ 穿透损耗（吸收）

电磁波穿过墙体、车体、树木等障碍物，被不同材质的吸收，导致信号衰减。下表总结了常见障碍物对无线信号的影响

典型障碍物厚度(毫米)2.4G信号衰减(dB) 5G信号衰减(dB)
普通砖墙 120 1020
加厚砖墙2401525
混凝土2402530
石棉834
泡沫板834
空心木2023
普通木门40 34
实木门40 1015
普通玻璃 847
加厚玻璃 12810
防弹玻璃302535
承重柱5002530
卷帘门101520
钢板803035
电梯803035

⑶ 反射损耗

当波撞击到一个比波自身更大的光滑物体时，波可能会往另一个方向传递。当无线发射信号与接收位置需要经过多次反射才可触达，我们可以通过尝试调整信号源位置并辅以定向天线来改善通信。

⑷ 衍射损耗

由于射频信号被局部阻碍，射频信号在物体周边发生的弯曲。位于障碍物正后方的区域称为射频阴影，它可能成为覆盖死角，一般是可以通过另一个AP的无线信号去消除。

无线标准/协议的演进

WiFi与 IEEE 802.11

WiFi 通常是指基于 IEEE 802.11 标准的无线网络。“Wi-Fi”一词由Wi-Fi 联盟（WFA）创造，该联盟是一个全球性联盟，致力于促进和认证无线设备的互操作性。简单来说，Wi-Fi 是描述无线网络技术的流行术语，而 IEEE 802.11 是定义无线通信底层协议和规范的技术标准。

技术标准

WiFi6 的核心技术

根据Wi-Fi联盟的报告，Wi-Fi 6 自2019年推出以来仅用3年就在全球市场份额超过了50%，而Wi-Fi 5用了4年时间。WiFi 6 为每个用户提供更大的总带宽，总频谱和信道，能够在高并发接入的环境下为每个用户较前代技术高 4 倍的吞吐量，其高带宽、高并发、低时延、低耗电的特点为未来的智能基础设施奠定基础。

⑴ 提升吞吐量：1024-QAM调制

802.11ax采用1024-QAM正交幅度调制，每个符号位传输10bit数据（2^(10)=1024）；相对于802.11ac（采用256-QAM正交幅度调制，每个符号传输8bit数据）来说，802.11ax的单条空间流数据吞吐量提高了25%。使用1024-QAM调制对信道条件有较高要求。

⑵ 改善多用户并发接入：OFDMA 和上行+下行的MU-MIMO

MU-MIMO 代表多用户的多输入多输出，它允许单个 AP 设备同时通过多个通道与多个用户进行通信，802.11ax（WiFi 6）在原有基础上进行了增强，提高了并发上行用户数量，理论上能够在上行和下行链路上为最多 8 个用户提供服务，并向单个客户端同时提供 4 个流。MU-MIMO生效需要通信双方都支持MU-MIMO。

OFDMA（正交频分多址）将信道进一步细分为可单独分配的“资源单元”，这是实现性能优势的关键。它允许多达 30 个用户同时共享一个信道，从而减少延迟、提高容量并提高效率。

OFDMA

OFDMA 和 MU-MIMO 的技术作为先进无线网络中的互补技术，可以基于所服务的应用类型来改善用户体验。

对于流媒体电影或游戏等高带宽应用，MU-MIMO 允许多个终端并发传输数据，建立高带宽网络以达到每个客户端的的最大速率。此外，MU-MIMO 使访问无线网络的队列从一个变为多个，多个设备可同时访问而无需等待。

对于即时消息、电子邮件或网页浏览等低带宽应用，分配给每个客户端的资源单元数量取决于数据包大小、终端设备限制以及流量服务质量（QoS）配置等因素，而OFDMA使用单个频段可以为多个用户提供这类低流量传输服务，起到类似“拼车”的效果，大大提高了网络资源利用率。

⑶ 降低信道间干扰：空分复用技术（SR） & BSS Coloring

当相同或相邻信道上的AP和终端检测到单个信道资源利用率偏高，噪声强度超过阈值时，则会需要排队等待（CCA功率调节机制）。

WiFi6协议里采用了空间复用和着色机制以提升信道利用率，减少排队。它可以类比为在客户端和AP之间建立起了虚拟的“高架桥”，根据不同目的地在空间上划分为互相独立不干扰的通路。不同的AP会各自给下连的终端着色（例如下图左，同为信道6的3个AP分别着色），只要信道资源没有完全占满，就依然会传输数据。

⑷ 降低能耗调度：目标唤醒时间 TWT

TWT（目标唤醒时间）最早出现在 802.11ah “Wi-Fi HaLow” 标准中，用于支持大规模物联网环境中的能效，并随着 IEEE 802.11ax 的发展而得到扩展。它使用计划机制来告诉客户端何时唤醒和睡眠，而不是让它们一直在某个频道上监听。

在 TWT 中，客户端和 AP 之间会商定一个时间表，该时间表由时间段组成。它通常包含一个或多个信标（例如几分钟、几小时，甚至长达几天）。当时间到了，客户端被唤醒，等待 AP 发送的触发帧并交换数据，然后重新进入休眠状态。AP 和终端设备会独立协商特定时间，或者 AP 可以将终端进行分组，一次连接到多个设备。

Wi-Fi 6E 及其他

在 Wi-Fi 6 标准发布一年后，由于频谱短缺，Wi-Fi 6e 应运而生，将现有技术扩展到 6GHz 频段。Wi-Fi 6E 使用 WPA3 代替传统的 WPA2 来增强安全性，但它仍然使用 802.11ax，因此它算作 WiFi 6 的附加增强功能，而不是下一代标准。

此外，Wi-Fi 的演进还包括几个小众项目。例如，毫米波 Wi-Fi (802.11ad/ay) 以极低的覆盖范围为代价，支持高达 275 Gbps 的标称数据速率。大量用户无线访问的新兴交互式应用和新服务，例如8K 流媒体、AR/VR、游戏、远程办公、工业物联网、云计算等等，正在推动行业支持更高吞吐量的无线网络。

WiFi 7 还有多远？

Wi-Fi 7在Wi-Fi 6的基础上引入了320MHz带宽、4096-QAM、Multi-RU、多链路操作、增强MU-MIMO、多AP协作等技术，使得Wi-Fi 7相较于Wi-Fi 6将提供更高的数据传输速率和更低的时延。

由于国内暂未开放6G频段给Wi-Fi使用，Wi-Fi 7特性未能完整发挥。目前Wi-Fi7实际生效的有以下几项：

  • 4096QAM：每个符号位传输 12bit 数据，相比Wi-Fi 6 提升20%
  • 16x16MIMO：由8×8提升到16×16空间流，增强高并发能力
  • 多链路传输：AP 和 客户端之间同时建立多个链路进行数据通信，可以利用多条链路进行负载分担，提升单用户峰值吞吐量；利用多条链路进行多发选收，提高链路可靠性。
  • Multi-RU：Wi-Fi 6 标准下同一周期单用户只能分配到 1 个 RU ，必然有部分 RU 资源被闲置。Wi-Fi 7 突破了限制，允许单用户同时占用多 RU，且不同大小的 RU 之间可以进行组合，使得业务延时降低25%。

  • 前导码打孔：支持把受干扰的20M信道打孔、屏蔽，然后剩余的140MHz信道继续捆绑在一起传输信息，极大提高了信道利用率；Wi-Fi 6中的做法一般是将工作信道限制在20M内传输，剩余信道受阻。

前导码打孔

常见的无线组网模式

自治AP（胖AP）

此类AP设备是最早进入无线网络市场的类型，因其可以近乎“即插即用”的方式工作且无需额外的控制器，建网成本极低，非常适合例如家庭、小型商户和办公室等小型无线网场景，正如其名，每个自治AP都可独立工作并且内置了基础的网络配置、流量控制、认证等功能的完整逻辑，所以每个 AP 都需要单独手动配置。

自治AP

瘦AP+ AC（无线AP控制器）

这种集中式方法涉及 2 个无线产品，包括 AP 和无线 AP 控制器 (AC)。AC在该解决方案中扮演着最重要的角色，AP 仅提供基本的无线电频率，在物理层传输 802.11 数据包，并通过无线接入点控制和配置协议（CAPWAP）与控制器建立通信。

AC 可处理多种功能，例如访问控制、AP 配置和监控、数据包转发、漫游、安全控制。它的工作原理就像无线网络的大脑一样，允许在一个地方配置和管理整个无线网络。这些使其适用于具有许多接入点的大型企业网络。

⑴ AC部署模式

  • 串联模式：AC 串接进网络，现在比较少见。
  • 旁路模式：AC只管理AP，旁路连接到汇聚交换机，让据包经由AC集中转发再传输到上层网络，适合在不改变现有网络的情况下对无线网络进行改造。

⑵ 数据转发模式：直接转发和隧道转发

并不是所有的数据包都需要经过集中式AC的封装和处理。某些情况下，数据包可以直接转发到网络的上层，但这仅适用于二层网络。隧道转发模式下，数据包被封装在CAPWAP隧道中，然后由AC转发到上层网络。如下图所示，CAPWAP隧道可能是控制数据隧道，也可能是业务数据隧道。

AP+AC

⑶ VLAN 规划和 AC 备份

VLAN规划主要包括两个方面，一是划分管理VLAN和业务VLAN，二是根据需要映射业务VLAN和SSID。由于是集中式部署，需要考虑冗余的设备、链路、交换策略，确保单点故障不影响整个系统功能，所以AP+AC架构中往往还需要多个AC互为备份。如果要为大量无线接入用户实现AP漫游，这对网络工程师来说可能是一个巨大的挑战。

  • 方案一：尽量在二层网络中规划漫游区域，但二层网络越大，安全性越差。
  • 方案二：建立连接两个WAC的隧道，将漫游流量传回原AC，但这会导致网络配置复杂，流量绕行，影响漫游性能。

除了配置相对复杂之外，多家供应商都有自己的专有协议，并在自己的产品中不断更改这些协议以改善通信。一般来说不同供应商的产品无法实现通信和交互。

属性胖AP瘦AP
技术模式 传统 新型，管理加强
安全性 单点安全，无整网统一安全能力统一的安全防护体系，无线入侵检测
网络管理能力 单台管理统一管理
配置管理 每个AP需要单独配置，管理复杂配置统一下发，AP零配置
自动RF调节 没有射频自动调节能力自动优化无线网络配置
漫游能力 支持2层漫游功能，适合小规模组网 支持2层、3层快速安全漫游
可扩展性 无扩展能力方便扩展，对于新增AP无需任何配置管理
高级功能 对于基于WiFi的高级功能，如安全、语音等支持能力很差可针对用户提供安全、语音、位置业务、个性化页面推送、基于用户的业务/完全/服务质量控制等等

无线Mesh网络（WMN）

无线mesh网络最初是为军事应用而开发的，它是一种由无需连接到有线端口的无线电设备组成的架构。无线Mesh网络中的每个设备都像路由器一样工作，其中各个节点不仅可以增强信号，还可以计算网络拓扑并进行路由，将长距离数据传输划分为多个短跳。当配置好主节点信息后，配置将⾃动同步给整个网络中其他的节点。

Mesh组网在难以或无法布线的情况下特别有用，例如临时的室内或室外区域、老旧历史建筑内等。目前已有不少厂商提供了面向企业和家庭的Mesh网络解决方案，不过一般来说无线 Mesh AP 不兼容多供应商。

无线Mech网络

在为较小的区域设计无线Mesh网络时，我们可能只需要将一两个Mesh AP连接到有线网络，如果范围扩大，我们仍然需要将多个Mesh AP 插入有线网络以确保网络可用性。部署Mesh AP 时，应综合考虑数量、传输距离和电源位置，并且应将它们放置得更近以获得更好的信号，因此往往需要更多的 AP 来覆盖给定的区域，成本随之上升（甚至会抵消其他方面节省的费用）。

值得注意的是该种组网方式最大的问题：带宽损耗。因为无线mesh组网会占用一半的带宽（还有无线传输本身的损耗），经过中继后的AP的吞吐量一般会下降约50%。

新一代云化园区无线组网模式

分布式网关转发

云网络很早就开始采用分布式的网关架构，将网关部署到更靠近终端的接入/边缘层。这种架构在转发路径、网络运维、表项空间、安全性等方面都有着显著的优势，也为企业网络的创新提供了一种很好的思路。

在这样的 IP Fabric 中，分布式网关意味着所有子网都存在于每个接入交换机上，它们会自动同步整个网络的端点 IP/MAC 和安全策略。这样，每个接入交换机都得到充分利用，所有跨子网流量的转发/漫游都由最近的交换机处理，而无需经过很长的路径到达集中式 AC。

更多信息请参阅：下一代园区网络，“分布式网关”实现更高效的无线漫游！

 集中式网关（隧道转发）分布式网关
转发路径业务报文经过隧道封装，经由集中式网关统一转发业务报文在本地接入交换机上转发
运维部署部署时需要大量手动配置（例如AP分组规划，单独的SSID/VLAN等）较为复杂，日后维护起来难度大开局一次性配置分布式网关信息即可，无需其他额外操作
可靠性过于集中的网关功能有压垮设备的风险，一旦出现故障，影响面大网关功能分散到所有接入交换机上；但设备发生故障对业务影响小
扩展性承载着关键性的网关业务，需要高性能大容量的设备，也容易成为限制网络规模迅速扩展的瓶颈接入层交换机仅需存储本地表项，对设备容量要求不高，更容易扩展接入规模

去CAPWAP的集中式转发

这种新型WLAN的设计同样基于云网络技术，相比上文的“分布式网关”其最大的优势在于无需改变现有的有线网络架构，只需部署一台可编程交换机接入核心交换机作为集中式网关，然后将旧AP替换为新AP即可完成无线网络的升级。

VXLAN

每台网关交换机拥有 3.2Tbps 吞吐量，轻松支持 10K+ 接入点 100K+ 无线终端。接入点通过 VXLAN 隧道与网关通信，接入点上运行多个 VTEP 以实现网络隔离。此外，接入点可以是完全基于开源技术的白盒硬件，而且相对于CAPWAP，VXLAN 技术也更加开放和标准化。

至于惯常思路里的无线AC，在新一代云化园区的无线网络中已经不存在了，取而代之的是使用云原生控制器（Cloud SDK）来统一管理园区内的有线和无线网络设备并下发配置——它既可以融合部署在网关交换机或其他本地设备上，也可以灵活部署在云端，从手机、电脑随时随地通过加密域名访问。

更多信息请参阅：园区无线网新架构：无CAPWAP的集中式转发

无线接入点（AP）部署要点

影响AP覆盖范围的因素

  • 无线电发射功率：室内AP不超过100mW/20dBm，室外AP不超过500mW/27dBm
  • 天线增益：室内天线增益一般在3-5dBi，室外天线增益一般大于10dBi
  • 部署环境：周围环境是否有强电磁场、障碍物遮挡、同类型Wi-Fi干扰、相似类型无线干扰，金属或者电子设备等干扰，相同信道频谱干扰
  • 天线和终端接收灵敏度：与终端设备有关

影响AP接入量的因素

芯片性能：同等无线速率下，如果是不同的芯片等级，能同时并发的用户数也不一样

射频：

  • 单射频AP最大接入128/512
  • 双射频AP最大接入256/1024
  • 三射频AP最大接入384/1536

用户流量模型：不同的用户流量也直接影响了能同时并发多少用户。

比如办公场景每人4M，推荐人数在30人；公共上网场景每人1M，推荐人数在60-100人

所需无线带宽估算

估算带宽时可以根据人数模糊概论（尤其适用高密场景），假如要求有1000人同时接入，实际使用时同时接入的人数在600人；接入的600人并非所有终端同时并发，算下来约会在200左右。

并发用户数=估算接入人数 * 并发比率

根据用户数与单用户速率需求分析可以得到总带宽需求：

总带宽＝并发用户数 * 单用户速率

下表仅供参考（单用户速率参考）

场景 终端类型 并发比率（按100人算） 最低标准 推荐标准 良好体验标准
办公室 笔记本 20%—50% 100KB/S下行
20KB/S上行		200KB/S下行
40KB/S 上行		300KB/S下行
100KB/S 上行
酒店
会议室
商超 手机 5%—30% 20KB/S下行
20KB/S 上行		50KB/S 下行
20KB/S 上行		80KB/S 下行
40KB/S 上行
室外

应用速率要求时延要求
网页浏览 160-512Kbps 200KB 的页面需要3~10s
P2P 流媒体1Mbps 实时
IM(如微信等)32-64Kbps 2KB/Session，0.5s
Email400Kbps 100KB/Session，2s
SNS(如微博等)200Kbps 50KB/Session，2s
VoIP512Kbps 实时
游戏 1Mbps 125KB，100ms
视频服务(标清) 2Mbps实时
视频服务(高清) 4Mbps 实时

AP通用部署原则

  • 尽量保证 AP 与终端之间可视无障碍物;
  • 优先考虑 AP 面积覆盖与间距合理，后考虑接入人数要求。
  • AP 以正六边形方式呈蜂窝状部署(同楼层平面，上下楼层同样）

AP通用部署原则

AP的覆盖部署

  1. 尽量减少信号穿过障碍物数量，一般建议最多穿透单层墙体(典型120mm砖墙)设计，部分特殊场景(如石膏墙、玻璃墙体等) 可考虑穿过2层墙体
  2. 240mm厚砖墙、混凝土墙体和金属材质墙体不建议穿透覆盖，如在不满足约束条件时仍采用AP穿透覆盖方案，则会导致穿墙后 弱信号和漫游不连续问题，针对此种情况，如需保障良好覆盖和漫游，网络规划时需要基于客户墙体结构新增部署AP点位
  3. 重点区域、VIP区域尽量保证单独部署AP以保障用户体验。
  4. 路口或拐角单独部署AP，保证信号覆盖连续性(大于-65dBm )，相邻AP可建立邻居关系表，保障良好漫游体验。
  5. AP安装位置远离承重柱3米以上

几条重要规则

  1. 不要采取在走廊部署吸顶AP去覆盖房间，除非拿设备验证过。像学校宿舍这种场景，如果有运营收费更不能放走廊。
  2. 任何场景 AP 间距不少于 8 米。同信道 AP 间距不少于 15 米。
  3. AP 吸顶安装时，需考虑吊顶材质，若为无机复合板、石膏板，衰减较小，可安装于吊顶内，若为铝制板，衰减较大，建议安装在吸顶安装于天花上，或用美化天线。
  4. 空旷的空间工勘时，一定要考虑后期放什么东西。比如宿舍，前期是空的，但之后可能放了金属桌子;空旷的仓库，之后可能放了很多金属货架。这些都会导致信号覆盖风险。
  5. 部署前务必先去现场工勘测试。不要“看图说话”。
  6. 室外项目中，为了保证使用效果，需使用定向天线，少用全向天线。不确定的情况找当地客服咨询。
  7. 室外项目务必要求施工方做好防水防雷，否则容易造成故障。
本文部分内容摘录整理自互联网公开知识，仅供各位读者参考，如有错漏和理解不当之处，敬请谅解、指正。
用于解决方案的背景图

一文揭秘AI智算中心网络流量 – 数据存储篇

关注星融元

本篇为“揭秘AI智算中心网络流量“系列的第三篇，前篇请参阅：

01、生成式AI对数据存储有哪些需求？

对于较小规模的AI模型，本地连接的磁盘存储可能就足够；进入大模型时代，则通常需要基于对象存储或并行文件系统的共享存储。一个完整的生成式AI的工作流的各阶段对存储有不同需求，具体可拆解如下：

  • 数据挖掘：需要从多个来源收集非结构化的数据，一般与混合云集成，用数据湖作为存储平台；
  • 数据准备：进行数据汇总、标准化和版本控制，关注存储的效率和灵活的数据管理能力，多采用统一存储平台；
  • 模型训练和微调：在智算中心内部，结合GPU服务器本地内存和远端的并行/分布式存储系统。因为GPU的投入巨大，需要高性能存储来高效地提供数据，并在整个过程中保持高利用率；
  • 推理阶段：该阶段旨在利用已训练好的模型实时生成输出，需要将输入模型和推理生成的文字/图片/视频流存储下来作为备份。

02、智算中心的存储网络

我们大致可将AI智算中心内部的数据存储系统进行简单的层次分类，主要包括GPU内存、存储网和存储设备。

| 图片引自 NVIDIA技术博客

| 图片引自 NVIDIA技术博客

一般来说，在存储层次结构中位置越高，其存储性能（尤其是延迟）就越快。因为本文的定位在分析网络流量，我们将聚焦于存储网络（data fabric）层次，即智算中心内部GPU服务器内存与远端存储服务器之间传输的数据。

在一个计算和存储分离的部署场景中，一般推荐部署2张Spine-Leaf架构的物理网：前端网和后端网。其中，存储前端网和业务网共用一张物理网。

存储后端网则单独使用一张物理网，以保证分布式存储集群能够快速无阻塞地完成多副本同步、故障后数据重建等任务。存储节点对网络接入侧的可靠性要求相对较高，因此推荐使用双归（MC-LAG）或者多归（EVPN-Multihoming）接入。

存储网络流量主要发生在模型训练的场景，它是一种单播流量，逻辑上仅需要以存储服务器为中心的星型连接。

  • 一是从存储服务器中分批加载训练数据集到GPU内存。
  • 二是训练的中间结果（定期保存的参数和优化器状态，即Check Point）要在存储服务器共享，并通过网络读写。

⑴ 数据集加载流量分析

在一个epoch中，整个训练集被遍历一次，如果进行评估，验证集也将被遍历一次。以下假设在每个epoch中进行评估，整个数据集的存储大小为D。

  • 数据并行时，整个数据集从网络存储读取，通过scatter操作分别加载到不同的GPU上，总网络流量为D。
  • 张量并行时，整个数据集从网络存储读取，通过broadcast操作发送给所有GPU，总的网络流量为 D x G。
  • 流水线并行时，整个数据集从网络存储读取，喂给流水线上第一个GPU，总网络流量为D。
  • 3D并行时，整个数据集从网络存储读取，在数据并行维度上分配，在张量并行维度上广播，总网络流量为D x G（tp） 。

以C4数据集为例，数据集的大小约38.5 TB，假设张量并行GPU数量为8，3D并行时每个epoch中加载数据集产生的网络流量为308TB。

⑵ Checkpoint存储流量分析

Checkpoint中存储了模型参数、优化器状态和其它训练状态（包括模型配置、训练的超参数、日志信息等）。优化器包含了梯度、动量和二阶矩估计等，每一种数据大小都等于模型参数。其它训练状态的大小可以忽略不计。假设模型参数为P，数据格式为BFLOAT16，优化器为Adam/AdamW，则checkpoint总大小为：

2 x P + 2 x P x 3 = 8 x P

这个checkpoint要保存在存储服务器中，虽然在张量并行、流水线并行和3D并行时，这些数据从多个GPU上通过gather操作汇聚到存储服务器，但无论如何，数据总量是一个checkpoint大小。假设每个epoch存储一次。这样，每个epoch产生的流量为：

8 x P

以Llama3-70B模型为例，假设每个epoch均存储，则产生的网络存储流量为560GB。

03、存储网设备选型：RoCE还是InfiniBand

相比训练场景，在智算中心存储网传输的流量与并行计算完全不在一个量级——虽然对链路带宽要求不那么高，但仍需满足高速分布式存储业务中所需的高吞吐、低时延、无损传输特性，并灵活满足存储集群规模调整所需的高可扩展性。

NVIDIA DGX SuperPOD™ 的方案在存储网采用的是200G的InfiniBand交换机。而事实上，随着近年来AI以太网技术的进步，RoCE与IB在转发时延上的细微差异，对分布式存储业务性能几乎没有影响。结合科学的网络参数调优，我们已在多个客户现场稳定测得了运行RoCEv2协议的交换机端到端性能全面优于IB交换机的结果。RoCE交换机作为IB平替已是不争的事实。

星融元 CX664P-N 是一款专为智算/超算中心设计的超低时延RoCE交换机，凭借以下特性在存储场景中脱颖而出。

型号为CX564P-664D-N数据中心交换机产品图

CX664D-N— 业务接口：64 x 200GE QSFP56, 2 x 10GE SFP+

  • CX-N系列一贯的超低延迟特性，端到端性能可媲美IB*（*测试数据详见方案手册）
  • 12.8Tbps 的线速 L2/L3 交换性能，提供高密度 200G/100G 以太网接口，满足主流存储网络需求并兼顾未来升级空间；另有两个 10G 端口用于管理网接入
  • 支持基于 RDMA 的 NVMe-oF (全端口标配RoCEv2)和EVPN-Multihoming → 什么是EVPN多归属，和MC-LAG的区别？
  • 搭载持续进化的企业级SONiC——AsterNOS网络操作系统，其开放的软件架构通过REST API开放全部网络功能给AI智算中心管理系统，实现无损以太网的自动化极简部署 → Easy RoCE：一键启用无损以太网

除存储网之外，基于通用、解耦、高性能的以太网硬件和开放软件框架，星融元可为大模型算力中心提供10G-800G的全场景互联能力。

一文揭秘AI智算中心网络流量 – AI推理篇

关注星融元

本篇为“揭秘AI智算中心网络流量“系列的第二篇，前篇请参阅：一文揭秘AI智算中心网络流量 – 大模型训练篇 。有关数据存储流量的分析将于下篇呈现，敬请关注。

AI推理是指从经过训练的大模型中获取用户查询或提示的响应的过程。

为了生成对用户查询的完整响应，AI推理服务器从一次推理迭代中获取输出token，将其连接到用户输入序列，并将其作为新的输入序列反馈到模型中以预测下一个token。这个过程被称为“自回归”计算，此过程重复进行，直到达到预定义的停止标准。

自回归

AI推理系统如何生成一次完整的响应？

⑴ 预填充/提示（Prefill）：模型从用户那里获得输入序列。基于此输入，模型预测第一个输出token。

⑵ 解码（Decode）：将生成的输出token连接到输入序列。更新后的输入序列被反馈到经过训练的模型中，然后生成下一个token。

⑶ 循环：解码继续进行，每个新token都是基于所有先前token的累积序列生成的。这种将输出token自回归地馈送到输入的过程确保模型在每个步骤的输出都受到所有先前token的影响，从而使其能够保持上下文和连贯性。

⑷ 终止：当模型达到停止标准时，它会终止该过程。停止标准可以是以下之一。

  • 最大序列长度：一旦达到总token（输入和输出）数量的定义限制
  • 序列结束 (EOS) ：模型生成一个特殊token，表示文本生成的结束。
  • 上下文完成：当模型确定生成的文本已根据提供的上下文得出自然且合乎逻辑的结论

AI并行推理网络流量分析

由于在预填充阶段已知整个token输入序列，因此推理加速器可以并行计算所有输入token的信息，并执行模型来预测下一个输出token。

在大模型推理时，虽然模型经过了压缩（比如4bit量化），但模型尺寸仍可能超过单个GPU的内存，这时候就需要张量并行，即使单个GPU可以容纳整个模型，张量并行可以加速推理过程。如果并发用户数较大，单个GPU来不及及时响应，就需要数据并行。

让我们再次回顾AI推理的两个关键阶段：

  1. 预填充（Prefill）阶段根据用户输入的prompt，生成输入token序列，并进行批处理，计算KV（Key, Value）缓存，并生成第一个输出token。这个阶段可以认为是大模型在理解用户输入，KV缓存存储了输入序列的上下文信息（为下面的Decode阶段缓存），其特点是需要大量的计算。
  2. 解码（Decode）阶段是一个循环过程，根据之前生成的token序列和KV缓存，计算下一个token，直到生成完整的输出。这个阶段可以认为是大模型在一个字一个字的说话。由于KV缓存的密集型计算已在 Prefill 阶段完成，因此此阶段仅处理上一阶段新生成的 token。因此，计算密集程度较低；但这一步需要从 KV缓存中读取前面所有token的Key,Value，所以需要高速的内存访问。

由于以上两个阶段对GPU的需求不同，我们可以采用Prefill-Decode解耦的方式，由2个不同类型的GPU分别承担Prefill和Decode阶段的计算任务，顺序执行。这时候就需要在两个阶段间传输KV缓存。

在生产部署时，通常结合上述几种方式。相比AI训练，AI推理只有前向传播过程，计算量相对较低，但需要快速的生成下一个token。流量产生有两个来源：

  1. 每次推理在Prefill GPU和Decode GPU之间传递KV缓存；
  2. Prefill GPU集群和Decode GPU集群分别实施张量并行，产生的中间激活的传递。不会有巨量的梯度同步流量。

假设并发用户数为U，数据并行维度为G(dp)，张量并行维度为G(tp)，用户输入序列的平均长度为S(in)个token，模型产生输出的平均长度为S(out)个token。

在张量并行时，前向传播产生了GPU间的网络流量，各个GPU计算出的中间激活值需要合并，由all-reduce操作进行求和。

假设模型有L层，在一次推理过程中，S(in)个输入token在模型的每一layer进行2次批量合并，共2L次，而对于每个输出Token，在模型的每个layer的中均进行2次合并，共 2xS(out) x L 次。此外，在Prefill阶段和Decode阶段之间有一次KV缓存的传递。AI并行推理网络流量如下图所示：

假设模型的隐藏状态大小为H，GPU数量为G，计算激活使用的数据格式为FLOAT16（2个字节表示一个数），每次all-reduce操作的通信量为

2 x H x （Gtp-1）x Gtp

在Prefill阶段，所有输入Token，在模型的每个layer的中均进行2次批量合并，共2xS(in)xL次。在Decode阶段，对于每个Token，在模型的每个layer的中均进行2次合并，共2xS(out)xL次。因此，U个用户的并发推理，中间激活值的总网络流量为

4 x U x（Sin+Sout）x L x H x （Gtp-1）x Gtp

另外，在一次推理中，KV缓存的大小为

4 x Sin x L x H

因此，U个用户的并发推理，KV缓存传递的网络流量为

4 x U x Sin x L x H

以Llama3-120B模型为例，模型层数140， 隐藏状态大小8192，张量并行度为4，用户prompt的平均长度S(in)为256个token，产生的输出的平均长度S(out)为4096个token。则要支持100个并发用户请求所需要的推理流量为：

4 x 100 x （256 + 4096）x 140 x 8192 x （4-1）x 4 + 4 x 100 x 256 x 140 x 8192 = 21.896TB

其中，KV缓存传递的流量虽然不大，每个用户约1.17GB，但需要在10ms左右的时间内一次传递完成。如果用1个800G端口传递，最快需要11.7ms。

AI推理对网络的需求

超高频率

AI推理流量虽然远小于训练时的网络流量，但值得注意的是，推理需要在很短的时间内完成，每个token在每一层产生2次流量，并要求在极短时间内传输完毕。假设至少要达到100token/s的推理速度，并行加速比为90%，那么每个token的推理速度要小于1ms，KV缓存需要在10ms左右完成。整个网络吞吐量应大于

4 x 100 x 140 x 8192 x （4-1）x 4/0.001 + 4 x 100 x 140 x 8192/0.01 = 5551GB/s ≈ 44.4Tbps

严格时间同步

无论是训练还是推理流量，都具有非常严格的周期性规律。基于木桶原理，如果GPU的时钟不同步，将造成同样的计算量花费不同的时间，计算快的GPU不得不等待计算慢的GPU。

开放与兼容性

AI推理进程涉及应用已训练好的AI模型进行决策或识别。对比AI训练，AI推理芯片门槛相对更低，我们的确也看到推理领域萌生出了开放生态的雏形，不少新兴初创企业加入竞争，涌现出基于不同算力架构的技术方案。

另一方面，在实际生产部署中的AI推理业务往往会与前端的业务/应用网络形成紧密配合，经由现有数据中心和云网络基础设施对外提供服务。

这便要求基础设施具备相当的开放性——网络不但要连接底层的异构算力（GPU、CPU、NPU）系统，还需要实现与上层管理系统的对接集成，例如与基于K8s的算力调度平台、已有的云管平台等等。

随着大模型的应用不断深化，AI算力部署将从训练场景逐步转向推理，推理需求也逐渐从云端迁移至边缘/终端，并呈现出垂直行业定制化的趋势。在云-边-端之间，我们需要构建一个更为均衡、通用化的网络基础设施体系。

在已被用户场景充分验证的数据中心开放云网能力之上（BGP、VXLAN、Calico容器路由、RoCE、NVMe-oF等），星融元推出的 星智AI 网络解决方案基于通用、解耦、高性能的以太网硬件和开放的SONiC软件框架，为AI智算中心提供10G-800G速率的以太网交换机，灵活支持单一速率或混合速率交换机组网，在保持极致性能的同时可编程、可升级，帮助客户构建高性能的AI智算中心网络，提供用于AI训练、推理、分布式存储、带内外管理等场景的互联能力。

  • 最大支持64个800G以太网接口，共51.2T交换容量
  • 超低时延，在800G端口上实现业界最强的560ns cut-through时延
  • 全端口标配支持RoCEv2
    200+MB大容量高速片上包缓存，显著减小集体通信时RoCE流量的存储转发时延
  • Intel至强CPU + 大容量可扩展内存，运行持续进化的企业级SONiC——AsterNOS网络操作系统，并通过DMA直接访问包缓存，对网络流量进行实时加工
  • INNOFLEX可编程转发引擎：可以根据业务需求和网络状态实时调整转发流程，最大程度避免网络拥塞和故障而造成的丢包
  • FLASHLIGHT精细化流量分析引擎：实时测量每个包的延迟和往返时间等，经过CPU的智能分析，实现自适应路由和拥塞控制
  • 10纳秒级别的PTP/SyncE时间同步，保证所有GPU同步计算
  • 开放的软件架构（生产就绪的SONiC，AsterNOS）通过REST API开放全部网络功能给AI智算中心管理系统，与计算设备相互协同，实现AI算力集群的自动化部署

AI Open Ecology

对星融元产品感兴趣？

立即联系！

电话咨询
联系表单
返回顶部

如何联系我们？

产品中心

快速导航

订阅我们获取最新资讯。

订阅邮件

关注星融元

企业二维码

© 星融元数据技术（苏州）有限公司 苏ICP备17070048号-2