智算中心网络架构设计

高性能智算网络作为“AI 大底座”基础设施层的关键组成部分，在智算节点间的高速互联，提升智算业务的训练和推理效率， 缩短上层应用发布和上线时间方面起着重要的作用。本文详细介绍了智算中心的网络架构设计，非常具有价值。

智算中心网络架构设计

• 引言
  • ChatGPT、文心一言等生成式人工智能应用的出现，使大模型的发展成为 AI 领域最重要的热点 趋势，越来越多的科技巨头竞相推出千亿、万亿参数的大模型。而训练超大参数规模的大模型也给智能计算基础设施带来了前所未有的挑战。大模型的训练过程需要数千张 GPU 卡协同计算数周或数月，这就要求智能计算网络能够提供更强大 的性能和更高的稳定性与可靠性。因此，提供一种高速、低延迟且可扩展的网络互联方案成为了智能计算领域的重要课题。
  • 智算网络的选型和建设阶段的典型问题包括:
    • 1. 智算网络是复用当前的 TCP/IP 通用网络的基础设施，还是新建一张专用的高性能网络?
    • 2. 智算网络技术方案采用 InfiniBand 还是 RoCE ?
    • 3. 智算网络如何进行运维和管理?
    • 4. 智算网络是否具备多租户隔离能力以实现对内和对外的运营?
  • 本设计将分析智算业务对网络的核心需求，深入介绍智算网络的架构设计以及智算中心高性能网络的运维和运营管理方 案，并结合典型实践，提供智算网络选型建议，为客户建设面向大模型的智算中心提供网络建设、运维和运营参考。
• 智算业务对网络的核心需求
  • 智算业务关键应用场景和案例
    • 在金融行业:智能计算应用于风险管理和控制，辅助量化交易、信用评估以及趋势预测，帮助金融机构做出更明智的 业务决策。
    • 在汽车行业:智能计算为自动驾驶提供高效精准的感知与识别、行驶决策与规划、车辆控制与执行，并不断进行算法 优化以提高自动驾驶的安全和可靠性。
    • 度小满将大型语言模型(LLM)应用于海量互联网文本数据、行为数据、 征信报告的解读，将小微企业主的信贷违约风险降低了 25%。而且随着模型的迭代，大模型在智能风控上的潜力还会进一 步释放。
    • 除了智能风控领域，度小满基于生成式大模型自主生成新的数据、图像、语音、文本等信息，成为理财师、保险经纪人等 金融行业从业人员的得力助手，帮助他们为客户个性化推荐理财、保险产品，大幅提升服务效率和服务体验。
  • 智算业务对网络的关键要求
    • 在 AI 系统中，一个模型从生产到应用，一般包括离线训练和推理部署两大阶段。
  • 大模型训练集群的网络要求
    • 低时延
      • 分布式全局速度计算公式
      • 降低多机多卡间端到端通信时延的关键技术是 RDMA 技术
      • 实现 RDMA 的方式有 InfiniBand、RoCEv1、RoCEv2、iWARP 四种。其中 RoCEv1 技术当前已经被淘汰， iWARP 使用较少。当前 RDMA 技术主要采用的方案为 InfiniBand 和 RoCEv2 两种。
    • 大带宽
      • 在完成计算任务后，智算集群内部的计算节点需要将计算结果快速地同步给其他节点，以便进行下一轮计算。在结果同步 完成前，计算任务处于等待状态，不会进入下一轮计算。如果带宽不够大，梯度传输就会变慢，造成卡间通信时长变长， 进而影响加速比。
    • 稳定运行
      • 由于计算量比较大，分布式训练任务有可能需要数天或数周。在训练期间如果出现网络不稳定的问题，会影响整个训练任 务的进度。因为网络故障导致的故障域通常会比较大，轻则需要回退到上一个分布式训练的断点进行重训，重则可能要将 整个任务从 0 开始重训。因此，网络稳定性对分布式训练任务十分重要。
    • 大规模
      • 随着数据并行和模型并行技术的不断完善和提升，分布式训练中可以使用千卡或万卡规模的 GPU 来缩短整体训练时长。 这就需要智算网络能够具备支持大规模 GPU 服务器集群的能力，并且能具备较强的扩展性，以应对未来更大规模 GPU 集群的业务需求。
    • 可运维
      • 在成百上千张GPU卡的智算集群中，集群的可运维性、可管理性是需要重点考虑的维度。整个智算集群的运行状态的可视 化，配置变更的白屏化，异常状态和故障的快速感知，是对高智算集群进行高效运维管理的基础。
• 智算网络方案选型
  • 要满足智算网络的低时延、大带宽、稳定运行、大规模以及可运维的需求，目前业界比较常用的网络方案是 InfiniBand 方案和 RoCEv2 方案。
  • InfiniBand 网络介绍
    • InfiniBand网络的关键组成包括Subnet Manager(SM)、InfiniBand 网卡、InfiniBand交换机和InfiniBand连接线缆。
      • InfiniBand 网卡
        • 支持 InfiniBand 网卡的厂家以 NVIDIA 为主。下图是当前常见的 InfiniBand 网卡。
      • InfiniBand 交换机
        • 在 2021 年，NVIDIA 推出了 400Gbps 的 Quantum-2 系列交换机(64*400G)。交换机上有 32 个 800G OSFP (Octal Small Form Factor Pluggable)口，需要通过线缆转接出 64 个 400G QSFP(Quad Small Form-factor Pluggable)。
      • Subnet Manager
        • InfiniBand 交换机上不运行任何路由协议。整个网络的转发表是由集中式的子网管理器(Subnet Manager，简称 SM) 进行计算并统一下发的。除了转发表以外，SM 还负责管理 InfiniBand 子网的 Partition、QoS 等配置。
        • SM 有 OpenSM(开源)和 UFM(收费)两种模式。SM 通常部署在接入 InfiniBand 子网的一台服务器上，可以把 子网管理器理解为 InfiniBand 网络的控制器。一个子网内同时只能有一个 SM 工作，如有多个设备配置成为 SM，则 只有一个 SM 能成为主 SM。SM 可以控制整个子网内所有的 InfiniBand 交换机和 InfiniBand 网卡，控制信令也通过 InfiniBand 网络带内下发和上传(统称 MAD，Management Datagram)。所有 InfiniBand 网卡端口和交换芯片都 有一个子网内唯一的身份标识 LID(Local ID)，由 SM 赋予。SM 会计算每个交换芯片的路由表并下发。这里需要特别 指出的是，SM 控制 InfiniBand 网卡，并不需要 InfiniBand 网卡所在服务器的协助。InfiniBand 网卡内部有一个称为 SMA(SM Agent)的功能，会直接处理 SM 发来的 MAD 报文。
      • 连接件
        • InfiniBand 网络需要专用的线缆和光模块做交换机间的互联以及交换机和网卡的互联。
    • InfiniBand 网络方案特点
      • 原生无损网络
        • InfiniBand 网络采用基于 credit 信令机制来从根本上避免缓冲区溢出丢包。只有在确认对方有额度能接收对应数量的报 文后，发送端才会启动报文发送。InfiniBand 网络中的每一条链路都有一个预置缓冲区。发送端一次性发送数据不会超过 接收端可用的预置缓冲区大小，而接收端完成转发后会腾空缓冲区，并且持续向发送端返回当前可用的预置缓冲区大小。 依靠这一链路级的流控机制，可以确保发送端绝不会发送过量，网络中不会产生缓冲区溢出丢包。
      • 万卡扩展能力
        • InfiniBand 的 Adaptive Routing 基于逐包的动态路由，在超大规模组网的情况下保证网络最优利用。InfiniBand 网络 在业界有较多的万卡规模超大 GPU 集群的案例，包括百度智能云，微软云等。
    • InfiniBand 网络设备供应商
      • 目前市场上主要的 InfiniBand 网络方案及配套设备供应商有以下几家。其中，市场占有率最高的是 NVIDIA，其市场份额 大于 7 成。
        • NVIDIA:NVIDIA是InfiniBand技术的主要供应商之一，提供各种InfiniBand适配器、交换机和其他相关产品。
        • Intel Corporation:Intel是另一个重要的InfiniBand供应商，提供各种InfiniBand网络产品和解决方案。
        • Cisco Systems:Cisco是一家知名的网络设备制造商，也提供InfiniBand交换机和其他相关产品。
        • Hewlett Packard Enterprise:HPE是一家大型IT公司，提供各种InfiniBand网络解决方案和产品，包括适配 器、交换机和服务器等。
  • RoCEv2 网络介绍
    • RoCEv2 网 络则是一个纯分布式的网络，由支持 RoCEv2 的网卡和交换机组成，一般情况下是两层架构。
    • RoCEv2 物理网络设施
      • RoCE 网卡
        • 支持 RoCE 网卡的厂家比较多，主流厂商为 NVIDIA、Intel、Broadcom。数据中心服务器网卡主要以 PCIe 卡为主。 RDMA 网卡的端口 PHY 速率一般是 50Gbps 起，当前商用的网卡单端口速率已达 400Gbps。
        • 除了商用卡之外，以云厂商为代表的自研 DPU 也在蓬勃发展。以百度智能云的太行 DPU 为例，DPU 中集成了多个自 研的硬件引擎进行性能优化，包括:
          • vQPE 硬件引擎:能够提升宿主机单机资源利用率，管理宿主机设备增删改配和数据交互，屏蔽硬件多样性与复杂性， 实现多元算力的云化部署;
          • BDMA 硬件引擎:面向不同业务流量分发定义了一套白盒化的软硬件交互的编程接口，实现高性能、高可用、高扩 展的架构设计，使上层软件可以享受最优的 I/O 体验;
          • BOE 硬件引擎:将网络任务中负责流表匹配的逻辑从 CPU 中分离出来，下沉到 FPGA 去做加速处理，通过快速 路径(Fast-Path)和慢速路径(Slow-Path)进行分离;
          • BDR 协议卸载引擎:将百度自研高性能网络的软件堆栈从 CPU 中分离了出来，下沉到 FPGA 中加速处理。构建 了数管分离的架构，为用户提供了超大带宽、超密连接和超低时延的 RDMA 网络连接能力，能够以更低的成本来支持更大规模 RDMA 组网。
      • RoCE 交换机
        • 当前大部分数据中心交换机都支持 RDMA 流控技术，和 RoCE 网卡配合，实现端到端的 RDMA 通信。国内的主流数据 中心交换机厂商包括华为、新华三等。
        • 高性能交换机的核心是转发芯片。当前市场上的商用转发芯片用的比较多的是博通的 Tomahawk 系列芯片。其中 Tomahawk3 系列的芯片在当前交换机上使用的比较多，市场上支持 Tomahawk4 系列的芯片的交换机也逐渐增多。
      • 连接件
        • RoCEv2 承载在以太网上，所以传统以太网的光纤和光模块都可以用。
      • RoCEv2 流控机制
        • PFC
          • PFC(Priority Flow Control)是 Hop By Hop 的流控策略，其特点就是通过配置水线合理的使用交换机的缓存，在以 太网络中实现完全的无丢包能力。
          • 具体实现步骤是，当下游交换机端口的入队列缓存达到阈值 Xoff 时，该交换机就会向上游设备(交换机或者网卡)发 PFC PAUSE 帧。上游设备收到 PFC Pause 帧后，该端口会停止发包，从而减少下游设备的缓存区压力。而在这个过 程中上游设备已经发送到链路中的报文不会被丢弃，依旧会发送到下游交换机并存储在下游交换机预先分配的 Headroom 缓存中。由于 PAUSE 帧的发送，下游交换机的 buffer 占用开始下降。等到该端口的 buffer 计数器下降到 Xon 这个值 的时候，端口 A 将会向上游发送一个持续时间为 0 的 PAUSE 帧，上游设备开始进行数据包发送。
        • ECN
          • 显式拥塞通知(ECN，Explicit Congestion Notification) 定义了一种基于 IP 层和传输层的流量控制和端到端拥塞通 知机制。ECN 是 IP 层的机制，它主要是用来在拥塞场景下，通过在交换机上标记报文特定向服务器端传递拥塞信息，从 而通知到服务器端发生了拥塞。然后服务器端再通过发送 CNP 报文至客户端通知源端降速从而实现拥塞控制的目的。在 RFC 3168 中定义了 ECN。
          • 需要注意以下两点，第一点是必须在端点上以及端点之间的所有中间设备上启用 ECN。若传输路径中有不支持 ECN 的任 何设备，将中断端到端 ECN 功能。Server 端的网卡收到了存在 ECN 标记的报文，会向 Client 端的网卡发送 CNP 报文， CNP 报文中包含着 QPs(Queue Pairs)等相关信息。第二点是 CNP 报文一般需要和 RDMA 业务报文处在不同的队列中， 并且设置合适的 QoS 策略保证 CNP 报文的发送，要确保 CNP 报文不会被丢弃，进而避免流控失效。
        • DCQCN
          • 数据中心量化拥塞通知 (DCQCN) 是 ECN 和 PFC 的组合，可支持端到端无损以太网。DCQCN 的设计理念是在拥 塞时通过 ECN 让发送端降低传输速率，从而尽量避免触发 PFC，因为 PFC 被触发，发送流量会完全停止，DCQCN 需要考虑如下两个关键点:
            • 确保 PFC 不会太早触发，即先使用 ECN 发送拥塞反馈使流量变慢。
            • 确保 PFC 不会太晚触发，即拥塞较严重产生缓冲区溢出进而出现丢包。
          • 通过合理设置下面三个参数，可以满足上述需求:
            • Headroom Buffers:发送至上游设备的 PAUSE 消息需要一些时间到达并生效。为避免丢包，PAUSE 发送方 必须保留足够的缓冲区，以处理在此期间可能收到的任何数据包。这包括发送 PAUSE 时正在传输的数据包，以及上游设备在处理 PAUSE 消息时发送的数据包。
            • PFC Threshold:这是一个入口阈值。当到达该阈值时，会向上游发送 PFC PAUSE 报文。
            • ECN Threshold:这是一个出口阈值。ECN 阈值等于 WRED 开始填充级别值。一旦出口队列超过此阈值，交换 机将开始为该队列中的数据包进行 ECN 标记。DCQCN 要有效，此阈值必须低于入口 PFC 阈值，以确保 PFC 不 会在交换机有机会使用 ECN 标记数据包之前触发。设置非常低的 WRED 填充级别可提高 ECN 标记概率。例如， 使用默认共享缓冲区设置，WRED 开始填充级别为 10% 可确保标记无丢失数据包。但是，如果填充级别较高，则 ECN 标记的概率降低。
      • RoCEv2 网络方案特点
        • RoCE 方案相对于 InfiniBand 方案的特点是通用性较强和价格相对较低。除用于构建高性能 RDMA 网络外，还可以在 传统的以太网络中使用。但在交换机上的 Headroom、PFC、ECN 相关参数的配置是比较复杂的。在万卡这种超大规 模场景下，整个网络的吞吐性能较 InfiniBand 网络要弱一些。
      • RoCE 网络设备供应商
        • 支持 RoCE 的交换机厂商较多，市场占有率排名靠前的包括新华三、华为等。支持 RoCE 的网卡当前市场占有率比较高 的是 NVIDIA 的 ConnectX 系列的网卡。
  • InfiniBand 和 RoCEv2 网络方案对比
    • 具体到实际业务场景上看，RoCEv2 是足够好的方案，而 InfiniBand 是特别好的方案。
    • 业务性能方面:由于 InfiniBand 的端到端时延小于 RoCEv2，所以基于 InfiniBand 构建的网络在应用层业务性能 方面占优。但 RoCEv2 的性能也能满足绝大部分智算场景的业务性能要求。
    • 业务规模方面: InfiniBand 能支持单集群万卡 GPU 规模，且保证整体性能不下降，并且在业界有比较多的商用实 践案例。RoCEv2 网络能在单集群支持千卡规模且整体网络性能也无太大的降低。
    • 业务运维方面: InfiniBand 较 RoCEv2 更成熟，包括多租户隔离能力，运维诊断能力等。
    • 业务成本方面: InfiniBand 的成本要高于 RoCEv2，主要是 InfiniBand 交换机的成本要比以太交换机高一些。
    • 业务供应商方面: InfiniBand 的供应商主要以 NVIDIA 为主，RoCEv2 的供应商较多。
• 物理网络架构设计
  • 传统云网络架构承载智算业务存在的挑战
    • 传统的云数据中心网络一般是基于对外提供服务的流量模型而设计的，流量主要是从数据中心到最终客户，即以南北向流 量为主，云内部东西向流量为辅。
    • 承载 VPC 网络的底层物理网络架构，对于承载智算业务存在如下挑战。
      • 有阻塞网络:考虑到并非所有服务器都会同时对外产生流量，为了控制网络建设成本， Leaf 交换机的下联带宽和上 联带宽并非按照 1:1 设计，而是存在收敛比。一般上联带宽仅有下联带宽的三分之一。
      • 云内部流量时延相对较高:跨 Leaf 交换机的两台服务器互访需要经过 Spine 交换机，转发路径有 3 跳。
      • 带宽不够大:一般情况下单物理机只有一张网卡接入 VPC 网络，单张网卡的带宽比较有限，当前较大范围商用的网 卡带宽一般都不大于 200Gbps。
  • 智算网络架构
    • 对于智算场景，当前比较好的实践是独立建一张高性能网络来承载智算业务，满足大带宽，低时延，无损的需求。
    • 大带宽的设计 智算服务器可以满配 8 张 GPU 卡，并预留 8 个 PCIe 网卡插槽。在多机组建 GPU 集群时，两个 GPU 跨机互通的突发 带宽有可能会大于 50Gbps。因此，一般会给每个 GPU 关联一个至少 100Gbps 的网络端口。在这种场景下可以配置 4 张 2*100Gbps 的网卡，也可以配置 8 张 1*100Gbps 的网卡，当然也可以配置 8 张单端口 200/400Gbps 的网卡。
    • 无阻塞设计
      • 无阻塞网络设计的关键是采用 Fat-Tree(胖树)网络架构。交换机下联和上联带宽采用 1:1 无收敛设计，即如果下联有 64 个 100Gbps 的端口，那么上联也有 64 个 100Gbps 的端口。
      • 此外交换机要采用无阻塞转发的数据中心级交换机。当前市场上主流的数据中心交换机一般都能提供全端口无阻塞的转发 能力。
    • 低时延设计 AI-Pool
      • 在低时延网络架构设计方面，百度智能云实践和落地了基于导轨(Rail)优化的 AI-Pool 网络方案。在这个网络方案中， 8 个接入交换机为一组，构成一个 AI-Pool。以两层交换机组网架构为例，这种网络架构能做到同 AI-Pool 的不同智算节点的 GPU 互访仅需一跳。
      • 在 AI-Pool 网络架构中，不同智算节点间相同编号的网口需要连接到同一台交换机。如智算节点 1 的 1 号 RDMA 网口， 智算节点 2 的 1 号 RDMA 网口直到智算节点 P/2 的 1 号 RDMA 网口都连到 1 号交换机。
      • 在智算节点内部，上层通信库基于机内网络拓扑进行网络匹配，让相同编号的 GPU 卡和相同编号的网口关联。这样相同 GPU 编号的两台智算节点间仅一跳就可互通。
      • 不同GPU编号的智算节点间，借助NCCL通信库中的Rail Local技术，可以充分利用主机内GPU间的NVSwitch的带宽， 将多机间的跨卡号互通转换为跨机间的同GPU卡号的互通。
    • 对于跨 AI-Pool 的两台物理机的互通，需要过汇聚交换机，此时会有 3 跳。
  • 智算网络可容纳的 GPU 卡的规模
    • 网络可承载的 GPU 卡的规模和所采用交换机的端口密度、网络架构相关。网络的层次多，承载的 GPU 卡的规模会变大， 但转发的跳数和时延也会变大，需要结合实际业务情况进行权衡。
    • 两层胖树架构
      • 8 台接入交换机组成一个智算资源池 AI-Pool。图中 P 代表单台交换机的端口数。单台交换机最大可下联和上联的端口为 P/2 个，即单台交换机最多可以下联 P/2 台服务器和 P/2 台交换机。两层胖树网络可以接入 P*P/2 张 GPU 卡。
    • 三层胖树架构
      • 三层网络架构中会新增汇聚交换机组和核心交换机组。每个组里面的最大交换机数量为 P/2。汇聚交换机组最大数量为 8， 核心交换机组的最大数量为 P/2。三层胖树网络可以接入 P*(P/2)*(P/2)=P*P*P/4 张 GPU 卡。 在三层胖树组网中，InfiniBand 的 40 端口的 200Gbps HDR 交换机能容纳的最多 GPU 数量是 16000。这个 16000 GPU 卡的规模也是目前 InfiniBand 当前在国内实际应用的 GPU 集群的最大规模网络，当前这个记录被百度保持。
    • 两层和三层胖树网络架构的对比
      • 可容纳的 GPU 卡的规模
        • 两层胖树和三层胖树最重要的区别是可以容纳的 GPU 卡的规模不同。在下图中 N 代表 GPU 卡的规模，P 代表单台交换 机的端口数量。比如对于端口数为 40 的交换机，两层胖树架构可容纳的 GPU 卡的数量是 800 卡，三层胖树架构可容纳 的 GPU 卡的数量是 16000 卡。
      • 转发路径
        • 两层胖树和三层胖树网络架构另外一个区别是任意两个节点的网络转发路径的跳数不同。 对于同智算资源池 AI-Pool 的两层胖树架构，智算节点间同 GPU 卡号转发跳数为 1 跳。智算节点间不同 GPU 卡号在 没有做智算节点内部 Rail Local 优化的情况下转发跳数为 3 跳。 对于同智算资源池 AI-Pool 的三层胖树架构，智算节点间同 GPU 卡号转发跳数为 3 跳。智算节点间不同 GPU 卡号在 没有做智算节点内部 Rail Local 优化的情况下转发跳数为 5 跳。
  • 典型实践
    • 不同型号的 InfiniBand/RoCE 交换机和不同的网络架构下所支持的 GPU 的规模不同。结合当前已成熟商用的交换机， 我们推荐几种物理网络架构的规格供客户选择。
      • 1. Regular: InfiniBand 两层胖树网络架构，基于 InfiniBand HDR 交换机，单集群最大支持 800 张 GPU 卡。
      • 2. Large: RoCE 两层胖树网络架构，基于 128 端口 100G 数据中心以太交换机，单集群最大支持 8192 张 GPU 卡。
      • 3. XLarge: InfiniBand 三层胖树网络架构，基于 InfiniBand HDR 交换机，单集群最大支持 16000 张 GPU 卡。
      • 4. XXLarge: 基于 InfiniBand Quantum-2 交换机或同等性能的以太网数据中心交换机，采用三层胖树网络架构， 单集群最大支持 100000 张 GPU 卡。
    • 度小满案例
      • 支撑上层创新应用和算法落地的关键环节之一是底层的算力，而支撑智算集群的算力发挥其最大效用的关键之一是高性能 网络。度小满的单个智算集群的规模可达 8192 张 GPU 卡，在每个智算集群内部的智算资源池 AI-Pool 中可支持 512 张 GPU 卡。通过无阻塞、低时延、高可靠的网络设计，高效的支撑了上层智算应用的快速迭代和发展。
    • XLarge 智算物理网络架构实践
      • 为了实现更高的集群运行性能，百度智能云专门设计了适用于超大规模集群的 InfiniBand 网络架构。该网络已稳定运 行多年，2021 年建设之初就直接采用了 200Gbps 的 InfiniBand HDR 交换机，单台 GPU 服务器的对外通信带宽为 1.6Tbps。 这个架构优化了网络收敛比，提升了网络吞吐能力，并结合容错、交换机亲和，拓扑映射等手段，将 EFLOPS 级算力的 计算集群性能发挥到极致。经过内部 NLP 研究团队的验证，在这个网络环境下的超大规模集群上提交千亿模型训练作业时， 同等机器规模下，整体训练效率是普通 GPU 集群的 3.87 倍。
• 智算高性能网络运维管理
  • RDMA 的通信方式和传统的 TCP/IP 不同，因此，智算高性能网络的运维管理也和之前的 IP 网络的运维管理方式有所不 同。具体来讲，RDMA 网络有如下特点:
    • 需要高精度的流量采集能力:RDMA 的流量一般呈现较强的突发性。通过 SNMP，以 30 秒的采样精度来采集流 量数据已经无法呈现网络的关键带宽业务指标。
    • 更精细化的流量统计能力:RDMA的流量是通过端口的某个队列发送的，流量统计的维度要从端口级别细化到队列 级别。
    • 全面的 RDMA 流控指标的采集和统计:RoCE 网络是通过发送 PFC 和 ECN 报文进行流量控制的，运维管理系统 相应地也需要提供对 PFC 和 ECN 等关键指标的采集和统计。
    • 只有具备了上述基础的 RDMA 网络业务可视化能力，才能更好地使用 RDMA 网络，快速的发现和定位问题。
  • 可视化网管系统
    • 要求
      • 1. 提供高精度秒级端口级和队列级监控能力，流量 TOP 大盘展示能力;
      • 2. 提供完善的 RDMA 流量监控指标，包括 PFC，ECN 等关键指标;
      • 3. 提供自定义告警规则能力并提供告警大盘展示功能;
      • 4. 提供网络诊断工具，方便用户快速进行问题排查和故障定位。
    • 集群网络可视化
      • 智算集群内，多机之间存在的频繁和高速的 RDMA 流量交互。RDMA 流量可视化能帮助运维人员实时地查看高性能 RDMA 网络的实际运行状态，并具备快速发现和定位网络问题的技术手段和能力。为了满足 RDMA 网络高精度流量监控的需求，需要在交换机上开启 Telemetry 采样能力。开启后交换机会以 1 秒的间隔 上报流量数据。后端服务器收集到流量监控数据后，发送给前端进行展示。用户最终可以在前端实时的看到秒级精度的监控数据。
    • 智算节点内部网络可视化
      • 在智算节点内部，多个 GPU、网卡、CPU 之间是通过主机内部的 PCIe Switch 和 NVSwitch 互联的。
        • PCIe Switch:通过 16 组 PCIe4.0 或 PCIe5.0 总线将 CPU、网卡、GPU 互联。其中 PCIe 4.0X16 的单向带 宽为 256Gbps，PCIe 5.0X16 的单向带宽为 512Gbps。
        • NVSwitch:通过 NVLink 将 GPU 进行全互联，且 GPU 间的互通优先走 NVLink。NVLink2.0 单向带宽为 200Gbps，其中 A100 每个 GPU 使用了 12 个 NVLink，H800 使用了 18 个 NVLink，单向带宽分别达到了 2.4Tbps 和 3.6Tbps。
        • CPU 之间通过 UPI 总线互联。UPI 总线的单线带宽为 166Gbps。两路 CPU 的服务器 CPU 间通过 2 条 UPI 总线互联， 单向带宽为 332Gbps。
        • 从上述描述可知，智算节点内部不同的通信链路的带宽并不相同。如果上层应用没有充分利用好主机内的带宽，也会影 响上层智算业务的训练和推理效率。尤其在调优场景，对主机内部的 NVLINK，PCIe 的带宽的监控也很关键。这需要 RDMA 网管平台具备对主机内 NVLINK，PCIe 带宽的实时监控。实现对智算集群网络和主机内部网络的可视化监控， 对于提升智算业务的训练和推理效率有较大的帮助。
    • 高精度流量采集
      • 对于高精度的流量监控需求，当前主要通过在交换机设备上开启 Telemetry 流量和设备状态采集和统计功能实现。 Telemetry 具备如下特点:
        • 采样精度高: Telemetry 可以做到秒级精度的流量统计和采集。
        • 性能高:Telemetry 在交换机设备上通过硬件方式实现，不消耗设备的 CPU 资源。
        • 按需订阅:在订阅具体的统计项后，Telemetry 基于订阅结果将数据推送订阅方。
      • Telemetry 会结合 gRPC 实现高精度的流量和设备状态信息的采集，将采集到的数据存放到时序数据库中供前端做可视 化展示。
    • 数据可视化展示
    • 智能化
      • 故障归因
        • 对于异常情况，RDMA 网络可视化管理系统 AI-NETOP 具备智能化故障归因的能力。通过内置的算法和规则判断具体 的丢包原因，例如，可以判断是因为 ACL 丢包还是因为缓存不足丢包。
      • 自动修复
        • 在一些异常场景下，可能会存在配置丢失的问题。例如在服务器重启后，由于配置恢复的时序问题，网卡上的某一条关键 配置没有正确的恢复。在这种情况下，RDMA 网络可视化管理系统 AI-NETOP 可以识别出配置是否完成恢复。如未完 整恢复，会重新下发配置命令，让关键配置能被自动修复。整个修复过程，完全由 RDMA 网管系统处理，运维人员无需 感知和介入。
      • 可编程的告警规则
        • 自定义和可编程的告警规则有助于将用户在运维过程中沉淀和积累下来的经验进行代码化。在一些场景下，一些告警是无 需处理的，例如变更和升级窗口期间的设备端口 up/down 告警;而有些告警的等级需要提升，例如在重大运营活动中的 网络的丢包告警。
        • 百度智能云专有云 ABC Stack 提供的 RDMA 网络可视化管理系统 AI-NETOP 支持让用户通过脚本的方式灵活定义告 警规则，更好的匹配用户的运维管理需求。
      • 可感知和可量化的网络质量
        • 通过在计算节点内部安装 RDMA Agent，从应用层进行质量探测，并将探测数据上报到网管平台。RDMA 网管平台基 于收集到的数据并以可视化的方式呈现应用层的网络质量信息。
      • 实时告警
        • 对于网管平台来讲，一个关键的能力是实时的感知并通告异常和故障，让运维人员可以及时地感知和处理。RDMA 网络 可视化管理系统 AI-NETOP 支持实时的通知告警事件给运维人员。
• 智算高性能网络运营管理
  • 云平台产品化的多租户能力 AI-VPC
    • AI 大底座的智算网络是一张独立的高性能网络。云平台在实现对这张网络的运维和管理之后的下一个目标就是提供产品化 的多租户隔离能力，进而实现提升 GPU 和高性能网络资源利用率的目的。类似于 IP 网络通过 VPC(Virtual Private Cloud)实现 IP 业务的多租户隔离的原理，智算网络通过 AI-VPC 实现智 算 AI 类业务的多租户隔离。AI-VPC 中包含多个智算节点，在同 AI-VPC 中的智算节点可以互相访问。不同租户之间 的智算节点处于隔离状态，不能互访。部分智算节点会同时和 IP 网络和智算网络互联，此时智算节点会同时归属于 IP 网 络的某个 VPC 和智算网络的某个 AI-VPC。
    • 具备多租户能力后，就可以将整个智算节点资源池从逻辑上划分出多个智算集群，供不同的内部租户或外部租户使用。IP 网络的 VPC 采用 MAC in UDP 的 VXLAN 技术在 Overlay 层面实现多租户隔离。智算网络的 AI-VPC 考虑到高性能， 采用 Partition-Key 或网络 ACL 实现多租户隔离。
  • InfiniBand 网络的多租户方案
    • InfiniBand 网络原生支持多租户组网，主要通过 Partition-Key(P-Key)机制实现多租户之间的业务隔离和有条件的 互访。如下图所示，同租户内的资源可以互相访问，不同租户的资源互相隔离。P-Key 是一个 16-bit 的数字，最高位 为 Full(bit=1)或 Limited(bit= 0)，代表全互通能力或受限互通。其余 15 位表示租户 ID，最多可以容纳 32768 个 租户。Key 可以关联到交换机的端口或网卡的端口，甚至可以关联到应用层的 Queue-Pair(QP)上。P-Key 需要 云平台进行统一设置和管理，默认情况下 P-Key 的值为 0XFFFF，代表无隔离可以全互通。
  • RoCE 网络的多租户方案
    • RoCE 网络的多租户隔离目前主要通过给不同租户划分不同网段，再结合 ACL，实现租户间隔离和租户内全互通。具体 的实现方案是，给不同租户分配不同 IP 地址段，通过网络 ACL 实现仅允许同网段 IP 互访。
    • 整个过程是通过云平台和 RoCE SDN 控制器配合实现的。在服务器启动后，服务器会上报租户 ID 和对应的 RDMA 交 换机上联端口给云平台。云平台根据租户 ID 信息给服务器分配对应的子网和 IP 地址。之后云平台会调用 RoCE SDN 的 接口，把租户的网段的 ACL 规则配置到上联口对应的 RDMA 交换机上。
  • 通过 RDMA 网络提供公共服务
    • 在一些场景下，GPU 集群需要通过 RDMA 网络访问一些公共服务，如并行文件存储 PFS(Parallel File System)系统。 可以把这种类型的服务也看做是一个 RDMA 网络的租户，通过 RDMA 网络控制器设置该租户的访问控制策略。以 RoCE 网络为例，把 PFS 服务也作为一个租户，在云平台中进行统一管理，并对应的调整网络访问控制策略，实现不 同租户都可以访问 PFS 服务。