ChatGPT狂飙160天，世界已经不是之前的样子。
新建了人工智能中文站https://ai.weoknow.com
每天给大家更新可用的国内可用chatGPT资源
读完可以成为半个智算中心网络架构专家！
全文比较长，精读完全文 ，估计需要2小时，建议先收藏，再慢慢品读！
** 引言**
随着 AI 技术的逐步成熟和应用场景的不断丰富，人工智能产业正在迅速发展，AI 相关的产品与服务也在各行业中落地和普及。企业通过人工智能技术提高生产力，进行数字智能化新范式转型的需求也更加迫切。人工智能技术目前已被广泛应用于智慧金融、智能家居、智能医疗、智能交通、智能制造等领域。
大模型技术因其良好的通用性与泛化性，显著降低了人工智能应用的门槛，其溢出效应正在加速推进新一轮的科技革命和社会产业的变革。近期，ChatGPT、文心一言等生成式人工智能应用的出现，使大模型的发展成为 AI 领域最重要的热点趋势，越来越多的科技巨头竞相推出千亿、万亿参数的大模型。而训练超大参数规模的大模型也给智能计算基础设施带来了前所未有的挑战。大模型的训练过程需要数千张 GPU 卡协同计算数周或数月，这就要求智能计算网络能够提供更强大的性能和更高的稳定性与可靠性。因此，提供一种高速、低延迟且可扩展的网络互联方案成为了智能计算领域的重要课题。
通常，大中型政务、金融及企业客户对网络安全与数据隐私保护有着更严格的要求，需要通过私有云建设模式在自有数据中心中构建自主可控的智能计算资源池，为人工智能的创新服务提供底层算力支持。智算网络作为智算中心基础设施的重要组成部分，其选型、设计和建设方案是非常关键的环节，网络架构设计的合理性直接影响智算集群的性能、可靠性与稳定性。智算网络的选型和建设阶段的典型问题包括：
智算网络是复用当前的 TCP/IP 通用网络的基础设施，还是新建一张专用的高性能网络？
智算网络技术方案采用 InfiniBand 还是 RoCE ？
智算网络如何进行运维和管理？
智算网络是否具备多租户隔离能力以实现对内和对外的运营？
本白皮书将分析智算业务对网络的核心需求，深入介绍智算网络的架构设计以及智算中心高性能网络的运维和运营管理方案，并结合典型实践，提供智算网络选型建议，为客户建设面向大模型的智算中心提供网络建设、运维和运营参考。
01
智算业务对网络的核心需求
1.1 智算业务关键应用场景和案例
智能计算是指利用人工智能技术和算法，对海量数据进行分析、处理和挖掘。智能计算已广泛应用于自然语言处理、图像识别、预测分析、金融科技和自动驾驶等场景。基于大模型在自然语言处理领域的出色能力，智能计算为机器翻译、文本分类、文本总结、文本创作、搜索助手、辅助编程、图像视频创作等应用场景提供强有力的技术支持。
智能计算已成为帮助企业提高效率、降低成本、打造核心竞争力所不可或缺的技术能力，其在金融和汽车行业的应用已经非常成熟。例如：
·在金融行业：智能计算应用于风险管理和控制，辅助量化交易、信用评估以及趋势预测，帮助金融机构做出更明智的业务决策。
·在汽车行业：智能计算为自动驾驶提供高效精准的感知与识别、行驶决策与规划、车辆控制与执行，并不断进行算法优化以提高自动驾驶的安全和可靠性。
1.1.1 金融风控与智能推荐
金融行业历来是数字化与智能化的先驱者，已经将人工智能技术广泛应用于各项业务中，包括智能风控、交易欺诈检测、智能客服、投资决策、信用评估、量化交易等。
金融风控是人工智能技术在金融行业中最典型的应用场景。通过大数据分析、机器学习等技术对金融交易、投资、借贷等活动进行风险识别、评估、控制和监测，对金融风险进行有效识别和预警，以保障金融机构和客户的资产安全，满足监管要求。
在金融风控领域，度小满拥有非常丰富的实践经验。度小满将大型语言模型（LLM）应用于海量互联网文本数据、行为数据、征信报告的解读，将小微企业主的信贷违约风险降低了 25%。而且随着模型的迭代，大模型在智能风控上的潜力还会进一步释放。
除了智能风控领域，度小满基于生成式大模型自主生成新的数据、图像、语音、文本等信息，成为理财师、保险经纪人等金融行业从业人员的得力助手，帮助他们为客户个性化推荐理财、保险产品，大幅提升服务效率和服务体验。
1.1.2 自动驾驶
得益于人工智能技术，自动驾驶技术越来越成熟。自动驾驶的渗透率呈现逐步上涨的趋势。全球知名 IT 市场研究机构IDC 发布的《中国自动驾驶汽车市场数据追踪报告》显示，2022 年第一季度 L2 级自动驾驶在乘用车市场的新车渗透率达 23.2%，L3 和 L4 级自动驾驶的能力也越来越成熟。
在自动驾驶场景中，每车每日会产生 T 级别数据，每次训练的数据达到 PB 级别。大规模数据处理和大规模仿真任务的特点十分显著，需要使用智算集群来提升数据处理与模型训练的效率。
重庆长安汽车股份有限公司在智算领域进行了规模化实践，建设了全新的智能车云平台和专用智算中心。当前计算能力突
破 100 亿亿次，支撑自动驾驶的算法自研、虚拟仿真、智能网联等数字服务。智能车云平台提供统一的基础网联、数字产
品、AI 决策分析、智能汽车大数据四大平台能力，为用户提供智能化、远程化、个性化的车辆服务，打造更加便捷、高效、
安全的车辆使用体验。
1.2 智算业务对网络的关键要求
1.2.1 AI 模型训练和推理的核心是数据计算
在 AI 系统中，一个模型从生产到应用，一般包括离线训练和推理部署两大阶段。
离线训练，就是产生模型的过程。用户需要根据自己的任务场景，准备好训练模型所需要的数据集以及神经网络算法。模型训练开始后，先读取数据，然后送入模型进行前向计算，并计算与真实值的误差。然后执行反向计算得到参数梯度，最后更新参数。训练过程会进行多轮的数据迭代。训练完成之后，保存训练好的模型，然后将模型做上线部署，接受用户的真实输入，通过前向计算，完成推理。因此，无论是训练还是推理，核心都是数据计算。为了加速计算效率，一般都是通过 GPU 等异构加速芯片来进行训练和推理。
1.2.2 AI 模型参数规模不断扩大
随着以 GPT3.0 为代表的大模型展现出令人惊艳的能力后，智算业务往海量参数的大模型方向发展已经成为一个主流技术演进路径。以自然语言处理（NLP）为例，模型参数已经达到了千亿级别。计算机视觉（CV） 、广告推荐、智能风控等领域的模型参数规模也在不断的扩大，正在往百亿和千亿规模参数的方向发展。
1.2.3 大模型训练集群的网络要求
大模型训练中大规模的参数对算力和显存都提出了更高的要求。以GPT3为例，千亿参数需要2TB显存，当前的单卡显存容量不够。即便出现了大容量的显存，如果用单卡训练的话也需要32年。为了缩短训练时间，通常采用分布式训练技术，
对模型和数据进行切分，采用多机多卡的方式将训练时长缩短到周或天的级别。
分布式训练就是通过多台节点构建出一个计算能力和显存能力超大的集群，来应对大模型训练中算力墙和存储墙这两个主要挑战。而联接这个超级集群的高性能网络直接决定了智算节点间的通信效率，进而影响整个智算集群的吞吐量和性能。
要让整个智算集群获得高的吞吐量，高性能网络需要具备低时延、大带宽、长期稳定性、大规模扩展性和可运维几个关键能力。
（1）低时延
分布式训练系统的整体算力并不是简单的随着智算节点的增加而线性增长，而是存在加速比，且加速比小于 1。存在加速比的主要原因是：在分布式场景下，单次的计算时间包含了单卡的计算时间叠加卡间通信时间。因此，降低卡间通信时间，是分布式训练中提升加速比的关键，需要重点考虑和设计。
降低多机多卡间端到端通信时延的关键技术是 RDMA 技术。RDMA 可以绕过操作系统内核，让一台主机可以直接访问另外一台主机的内存。
实 现 RDMA 的 方 式 有 InfiniBand、RoCEv1、RoCEv2、i WARP 四 种。 其 中 RoCEv1 技 术 当 前 已 经 被 淘 汰，iWARP 使用较少。当前 RDMA 技术主要采用的方案为 InfiniBand 和 RoCEv2 两种。
在 InfiniBand 和 RoCEv2 方案中，因为绕过了内核协议栈，相较于传统 TCP/IP 网络，时延性能会有数十倍的改善。在同集群内部一跳可达的场景下，InfiniBand 和 RoCEv2 与传统 IP 网络的端到端时延在实验室的测试数据显示，绕过内核协议栈后，应用层的端到端时延可以从 50us（TCP/IP），降低到 5us（RoCE）或 2us（InfiniBand）。
（2）大带宽
在完成计算任务后，智算集群内部的计算节点需要将计算结果快速地同步给其他节点，以便进行下一轮计算。在结果同步完成前，计算任务处于等待状态，不会进入下一轮计算。如果带宽不够大，梯度传输就会变慢，造成卡间通信时长变长，进而影响加速比。
（3）稳定运行
由于计算量比较大，分布式训练任务有可能需要数天或数周。在训练期间如果出现网络不稳定的问题，会影响整个训练任务的进度。因为网络故障导致的故障域通常会比较大，轻则需要回退到上一个分布式训练的断点进行重训，重则可能要将整个任务从 0 开始重训。因此，网络稳定性对分布式训练任务十分重要。
（4）大规模
随着数据并行和模型并行技术的不断完善和提升，分布式训练中可以使用千卡或万卡规模的 GPU 来缩短整体训练时长。
这就需要智算网络能够具备支持大规模 GPU 服务器集群的能力，并且能具备较强的扩展性，以应对未来更大规模 GPU集群的业务需求。
（5）可运维
在成百上千张GPU卡的智算集群中，集群的可运维性、可管理性是需要重点考虑的维度。整个智算集群的运行状态的可视化，配置变更的白屏化，异常状态和故障的快速感知，是对高智算集群进行高效运维管理的基础。
02
智算网络方案选型
要满足智算网络的低时延、大带宽、稳定运行、大规模以及可运维的需求，目前业界比较常用的网络方案是 InfiniBand方案和 RoCEv2 方案。
2.1 InfiniBand 网络介绍
2.1.1 InfiniBand 物理网络设施
InfiniBand网络的关键组成包括Subnet Manager（SM）、InfiniBand 网卡、InfiniBand交换机和InfiniBand连接线缆。
（1） InfiniBand 网卡
支持 InfiniBand 网卡的厂家以 NVIDIA 为主。下图是当前常见的 InfiniBand 网卡。
InfiniBand 网卡在速率方面保持着快速的发展。200Gbps 的 HDR 已经实现了规模化的商用部署，400Gbps 的 NDR的网卡也已经开始商用部署。
（2）InfiniBand 交换机
SB7800 为 100Gbps 端口交换机（36*100G），属于 NVIDIA 比较早的一代产品。
Quantum-1 系列为 200Gbps 端口交换机（40*200G），是当前市场采用较多的产品。
在 2021 年，NVIDIA 推出了 400Gbps 的 Quantum-2 系列交换机（64*400G）。交换机上有 32 个 800G OSFP（Octal Small Form Factor Pluggable）口，需要通过线缆转接出 64 个 400G QSFP（Quad Small Form-factor Pluggable）。
（3）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 报文。
（4）连接件
InfiniBand 网络需要专用的线缆和光模块做交换机间的互联以及交换机和网卡的互联。
2.1.2 InfiniBand 网络方案特点
（1）原生无损网络
InfiniBand 网络采用基于 credit 信令机制来从根本上避免缓冲区溢出丢包。只有在确认对方有额度能接收对应数量的报文后，发送端才会启动报文发送。InfiniBand 网络中的每一条链路都有一个预置缓冲区。发送端一次性发送数据不会超过接收端可用的预置缓冲区大小，而接收端完成转发后会腾空缓冲区，并且持续向发送端返回当前可用的预置缓冲区大小。
依靠这一链路级的流控机制，可以确保发送端绝不会发送过量，网络中不会产生缓冲区溢出丢包。
（2）万卡扩展能力
InfiniBand 的 Adaptive Routing 基于逐包的动态路由，在超大规模组网的情况下保证网络最优利用。InfiniBand 网络在业界有较多的万卡规模超大 GPU 集群的案例，包括百度智能云，微软云等。
2.1.3 InfiniBand 网络设备供应商
目前市场上主要的 InfiniBand 网络方案及配套设备供应商有以下几家。其中，市场占有率最高的是 NVIDIA，其市场份额大于 7 成。
·NVIDIA：NVIDIA是InfiniBand技术的主要供应商之一，提供各种InfiniBand适配器、交换机和其他相关产品。
·Intel Corporation：Intel是另一个重要的InfiniBand供应商，提供各种InfiniBand网络产品和解决方案。
·Cisco Systems：Cisco是一家知名的网络设备制造商，也提供InfiniBand交换机和其他相关产品。
·Hewlett Packard Enterprise：HPE是一家大型IT公司，提供各种InfiniBand网络解决方案和产品，包括适配器、交换机和服务器等。
2.2 RoCEv2 网络介绍
InfiniBand 网络在一定程度上是一个由 SM（Subnet Manager，子网管理器）进行集中管理的网络。而 RoCEv2 网络则是一个纯分布式的网络，由支持 RoCEv2 的网卡和交换机组成，一般情况下是两层架构。
2.2.1 RoCEv2 物理网络设施
（1）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 组网。
（2）RoCE 交换机
当前大部分数据中心交换机都支持 RDMA 流控技术，和 RoCE 网卡配合，实现端到端的 RDMA 通信。国内的主流数据中心交换机厂商包括华为、新华三等。
高性 能 交 换 机的核心 是 转发 芯片。当前 市场上的商用转发 芯片用的比 较 多的是博通的 Tomahawk 系列芯片。其中Tomahawk3 系列的芯片在当前交换机上使用的比较多，市场上支持 Tomahawk4 系列的芯片的交换机也逐渐增多。
下 图 是 H3C 数 据 中 心 交 换 机 基 于 Tomahawk 系 列 芯 片 的 演 进 和 发 展 路 线 图。 交 换 机 的 端 口 从 100Gbps-->200Gbps->400Gbps 演进，整体转发能力在不断提升。
（3）连接件
RoCEv2 承载在以太网上，所以传统以太网的光纤和光模块都可以用。
（4）RoCEv2 流控机制
PFCPFC（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） 是 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 标记的概率降低。
2.2.2 RoCEv2 网络方案特点
RoCE 方案相对于 InfiniBand 方案的特点是通用性较强和价格相对较低。除用于构建高性能 RDMA 网络外，还可以在传统的以太网络中使用。但在交换机上的 Headroom、PFC、ECN 相关参数的配置是比较复杂的。在万卡这种超大规模场景下，整个网络的吞吐性能较 InfiniBand 网络要弱一些。
2.2.3 RoCE 网络设备供应商
支持 RoCE 的交换机厂商较多，市场占有率排名靠前的包括新华三、华为等。支持 RoCE 的网卡当前市场占有率比较高的是 NVIDIA 的 ConnectX 系列的网卡。
2.3 InfiniBand 和 RoCEv2 网络方案对比
从技术角度看，InfiniBand 使用了较多的技术来提升网络转发性能，降低故障恢复时间，提升扩展能力，降低运维复杂度。
具体到实际业务场景上看，RoCEv2 是足够好的方案，而 InfiniBand 是特别好的方案。
·业务性能方面：由于 InfiniBand 的端到端时延小于 RoCEv2，所以基于 InfiniBand 构建的网络在应用层业务性能 方面占优。但 RoCEv2 的性能也能满足绝大部分智算场景的业务性能要求。
·业务规模方面： InfiniBand 能支持单集群万卡 GPU 规模，且保证整体性能不下降，并且在业界有比较多的商用实践案例。RoCEv2 网络能在单集群支持千卡规模且整体网络性能也无太大的降低。
·业务运维方面： InfiniBand 较 RoCEv2 更成熟，包括多租户隔离能力，运维诊断能力等。
·业务成本方面： InfiniBand 的成本要高于 RoCEv2，主要是 InfiniBand 交换机的成本要比以太交换机高一些。
·业务供应商方面： InfiniBand 的供应商主要以 NVIDIA 为主，RoCEv2 的供应商较多。
03
物理网络架构设计
3.1 传统云网络架构承载智算业务存在的挑战
传统的云数据中心网络一般是基于对外提供服务的流量模型而设计的，流量主要是从数据中心到最终客户，即以南北向流量为主，云内部东西向流量为辅。
承载 VPC 网络的底层物理网络架构，对于承载智算业务存在如下挑战。
·有阻塞网络：考虑到并非所有服务器都会同时对外产生流量，为了控制网络建设成本， Leaf 交换机的下联带宽和上联带宽并非按照 1：1 设计，而是存在收敛比。一般上联带宽仅有下联带宽的三分之一。
·云内部流量时延相对较高：跨 Leaf 交换机的两台服务器互访需要经过 Spine 交换机，转发路径有 3 跳。
·带宽不够大：一般情况下单物理机只有一张网卡接入 VPC 网络，单张网卡的带宽比较有限，当前较大范围商用的网卡带宽一般都不大于 200Gbps。
3.2 智算网络架构
对于智算场景，当前比较好的实践是独立建一张高性能网络来承载智算业务，满足大带宽，低时延，无损的需求。
大带宽的设计
智算服务器可以满配 8 张 GPU 卡，并预留 8 个 PCIe 网卡插槽。在多机组建 GPU 集群时，两个 GPU 跨机互通的突发带宽有可能会大于 50Gbps。因此，一般会给每个 GPU 关联一个至少 100Gbps 的网络端口。在这种场景下可以配置 4张 2100Gbps 的网卡，也可以配置 8 张 1100Gbps 的网卡，当然也可以配置 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 跳。
3.3 智算网络可容纳的 GPU 卡的规模
网络可承载的 GPU 卡的规模和所采用交换机的端口密度、网络架构相关。网络的层次多，承载的 GPU 卡的规模会变大，但转发的跳数和时延也会变大，需要结合实际业务情况进行权衡。
3.3.1 两层胖树架构
8 台接入交换机组成一个智算资源池 AI-Pool。图中 P 代表单台交换机的端口数。单台交换机最大可下联和上联的端口为P/2 个，即单台交换机最多可以下联 P/2 台服务器和 P/2 台交换机。两层胖树网络可以接入 P*P/2 张 GPU 卡。
3.3.2 三层胖树架构
三层网络架构中会新增汇聚交换机组和核心交换机组。每个组里面的最大交换机数量为 P/2。汇聚交换机组最大数量为 8，核心交换机组的最大数量为 P/2。三层胖树网络可以接入 P（P/2）（P/2）=PPP/4 张 GPU 卡。
在三层胖树组网中，InfiniBand 的 40 端口的 200Gbps HDR 交换机能容纳的最多 GPU 数量是 16000。这个 16000 GPU 卡的规模也是目前 InfiniBand 当前在国内实际应用的 GPU 集群的最大规模网络，当前这个记录被百度保持。
3.3.3 两层和三层胖树网络架构的对比
可容纳的 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 跳。
3.4 典型实践
不同型号的 InfiniBand/RoCE 交换机和不同的网络架构下所支持的 GPU 的规模不同。结合当前已成熟商用的交换机，
我们推荐几种物理网络架构的规格供客户选择。
•Regular： InfiniBand 两层胖树网络架构，基于 InfiniBand HDR 交换机，单集群最大支持 800 张 GPU 卡。
•Large： RoCE 两层胖树网络架构，基于 128 端口 100G 数据中心以太交换机，单集群最大支持 8192 张 GPU 卡。
•XLarge： InfiniBand 三层胖树网络架构，基于 InfiniBand HDR 交换机，单集群最大支持 16000 张 GPU 卡。
•XXLarge： 基于 InfiniBand Quantum-2 交换机或同等性能的以太网数据中心交换机，采用三层胖树网络架构，单集群最大支持 100000 张 GPU 卡。
3.4.1 Large 智算物理网络架构实践
由度小满建设的“智能化征信解读中台”工程，将大型语言模型 LLM、图算法应用在征信报告的解读上，荣获了 “吴文俊人工智能科学技术奖”。度小满也凭借该工程成为唯一入选的金融科技公司。
支撑上层创新应用和算法落地的关键环节之一是底层的算力，而支撑智算集群的算力发挥其最大效用的关键之一是高性能网络。度小满的单个智算集群的规模可达 8192 张 GPU 卡，在每个智算集群内部的智算资源池 AI-Pool 中可支持 512张 GPU 卡。通过无阻塞、低时延、高可靠的网络设计，高效的支撑了上层智算应用的快速迭代和发展。
3.4.2 XLarge 智算物理网络架构实践
为了实现更高的集群运行性能，百度智能云专门设计了适用于超大规模集群的 InfiniBand 网络架构。该网络已稳定运行多年，2021 年建设之初就直接采用了 200Gbps 的 InfiniBand HDR 交换机，单台 GPU 服务器的对外通信带宽为1.6Tbps。
这个架构优化了网络收敛比，提升了网络吞吐能力，并结合容错、交换机亲和，拓扑映射等手段，将 EFLOPS 级算力的计算集群性能发挥到极致。经过内部 NLP 研究团队的验证，在这个网络环境下的超大规模集群上提交千亿模型训练作业时，同等机器规模下，整体训练效率是普通 GPU 集群的 3.87 倍。
04
智算高性能网络运维管理
RDMA 的通信方式和传统的 TCP/IP 不同，因此，智算高性能网络的运维管理也和之前的 IP 网络的运维管理方式有所不同。具体来讲，RDMA 网络有如下特点：
·需要高精度的流量采集能力：RDMA 的流量一般呈现较强的突发性。通过 SNMP，以 30 秒的采样精度来采集流量数据已经无法呈现网络的关键带宽业务指标。
·更精细化的流量统计能力：RDMA的流量是通过端口的某个队列发送的，流量统计的维度要从端口级别细化到队列级别。
·全面的 RDMA 流控指标的采集和统计：RoCE 网络是通过发送 PFC 和 ECN 报文进行流量控制的，运维管理系统相应地也需要提供对 PFC 和 ECN 等关键指标的采集和统计。
只有具备了上述基础的 RDMA 网络业务可视化能力，才能更好地使用 RDMA 网络，快速的发现和定位问题。
4.1 可视化网管系统
当前 RDMA 网络的可视化网管系统主要是由设备厂商支持。云厂商中，提供私有化部署的云原生 RDMA 网络可视化管理系统的厂家比较少。百度智能云在这方面具备领先性，已经支持了私有化输出的 RDMA 网络可视化管理系统 AINETOP，并在度小满等客户中完成了部署与实际使用。
云原生的 RDMA 网管系统最大的优势在于可以和云平台的告警策略，告警规则无缝对接，真正成为用户云平台运维管理体系中的一部分。非云原生的 RDMA 网管系统最大的问题在于没有真正的融入到用户云平台的运维体系中，游离在云平台之外，无法做到及时和有效的运维管理。
云平台对 InfiniBand 网络的管理主要是实现和 UFM（Unified Fabric Manager）的对接和数据的打通。目前看百度智能云的 RDMA 网络可视化管理系统 AI-NETOP 在和 UFM 进行深入打通和深度融合方面也走在了业界前列。
百度智能云私有化输出的 RDMA 可视化运维管理平台，可提供如下能力：
提供高精度秒级端口级和队列级监控能力，流量 TOP 大盘展示能力；
提供完善的 RDMA 流量监控指标，包括 PFC，ECN 等关键指标；
提供自定义告警规则能力并提供告警大盘展示功能；
提供网络诊断工具，方便用户快速进行问题排查和故障定位。
4.1.1 集群网络可视化
智算集群内，多机之间存在的频繁和高速的 RDMA 流量交互。RDMA 流量可视化能帮助运维人员实时地查看高性能RDMA 网络的实际运行状态，并具备快速发现和定位网络问题的技术手段和能力。
为了满足 RDMA 网络高精度流量监控的需求，需要在交换机上开启 Telemetry 采样能力。开启后交换机会以 1 秒的间隔上报流量数据。后端服务器收集到流量监控数据后，发送给前端进行展示。用户最终可以在前端实时的看到秒级精度的监控数据。
4.1.2 智算节点内部网络可视化
在智算节点内部，多个 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 带宽的实时监控。实现对智算集群网络和主机内部网络的可视化监控，对于提升智算业务的训练和推理效率有较大的帮助。
4.2 高精度流量采集
对于高精度的流量监控需求，当前主要通过在交换机设备上开启 Telemetry 流量和设备状态采集和统计功能实现。
Telemetry 具备如下特点：
·采样精度高： Telemetry 可以做到秒级精度的流量统计和采集。
·性能高：Telemetry 在交换机设备上通过硬件方式实现，不消耗设备的 CPU 资源。
·按需订阅：在订阅具体的统计项后，Telemetry 基于订阅结果将数据推送订阅方。
Telemetry 会结合 gRPC 实现高精度的流量和设备状态信息的采集，将采集到的数据存放到时序数据库中供前端做可视化展示。
4.3 数据可视化展示
百度智能云专有云 ABC Stack 提供的 RDMA 网络可视化管理系统 AI-NETOP 具备让用户在前端自定义 RDMA 网络相关的监控指标和自定义监控大盘的能力。通过 Telemetry 协议采集上来的各项指标，用户可以有选择地在前端进行展示，并且可以设置如 TOPN 之类的大盘。
4.4 智能化
故障归因
对于异常情况，RDMA 网络可视化管理系统 AI-NETOP 具备智能化故障归因的能力。通过内置的算法和规则判断具体的丢包原因，例如，可以判断是因为 ACL 丢包还是因为缓存不足丢包。
自动修复
在一些异常场景下，可能会存在配置丢失的问题。例如在服务器重启后，由于配置恢复的时序问题，网卡上的某一条关键配置没有正确的恢复。在这种情况下，RDMA 网络可视化管理系统 AI-NETOP 可以识别出配置是否完成恢复。如未完整恢复，会重新下发配置命令，让关键配置能被自动修复。整个修复过程，完全由 RDMA 网管系统处理，运维人员无需感知和介入。
可编程的告警规则
自定义和可编程的告警规则有助于将用户在运维过程中沉淀和积累下来的经验进行代码化。在一些场景下，一些告警是无需处理的，例如变更和升级窗口期间的设备端口 up/down 告警；而有些告警的等级需要提升，例如在重大运营活动中的网络的丢包告警。
百度智能云专有云 ABC Stack 提供的 RDMA 网络可视化管理系统 AI-NETOP 支持让用户通过脚本的方式灵活定义告警规则，更好的匹配用户的运维管理需求。
可感知和可量化的网络质量
通过在计算节点内部安装 RDMA Agent，从应用层进行质量探测，并将探测数据上报到网管平台。RDMA 网管平台基于收集到的数据并以可视化的方式呈现应用层的网络质量信息。
实时告警
对于网管平台来讲，一个关键的能力是实时的感知并通告异常和故障，让运维人员可以及时地感知和处理。RDMA 网络可视化管理系统 AI-NETOP 支持实时的通知告警事件给运维人员。
4.5 典型实践
百度智能云专有云 ABC Stack 为度小满构建了支撑大模型业务的 AI 底座，包括 GPU 集群和 RDMA 网络，为度小满的金融科技创新做好了基础支撑。
度小满的运维团队一直在坚持“用技术重新定义服务保障，让服务保障更简单”的愿景，在金融行业的运维领域做出了很多创新和优秀实践。由于当前其 GPU 规模已经达到千卡规模，且未来有可能会演进到万卡规模，度小满对 GPU 集群和高性能网络的自动化运维工作和自助式服务能力建设十分重视。通过使用 RDMA 网络可视化管理系统 AI-NETOP 实现了故障快速发现，故障快速定位和智能化运维，帮助其支撑智算相关的大模型业务快速落地，形成了先进的生产力，支撑业务更好的发展。
首先是以服务化的方式重定义运维工作。制定对应的服务级别协议 SLA（Service-Level Agreement）和 SLO（Service Level Objective），在响应时间、可靠性、性能、成本等维度达成可量化的标准，并和应用方达成共识。
其次是以具体的量化目标为牵引提升运维能力。比如对于重要业务承诺 1-5-10（1 分钟发现，5 分钟响应，10 分钟处置）稳定性指标和 99.95% 可用性的服务目标。在这个目标的牵引下通过提升可观测能力构建问题快速发现能力，通过制定故障处理预案和不同场景的演练方案来提升问题的响应和处理能力。
最后是对运维工作进行规范化、标准化、白屏化和自动化的四化建设，从而更加高效的管理和维护基础设施，减少黑屏人工操作导致的人为失误，通过白屏化和自动化提高运维效率和效能。
05
智算高性能网络运营管理
智算资源池建好之后，需要重点考虑的是如何将资源充分的使用起来，最大化的发挥算力资源的效用。客户构建出一个PFlops 规模的算力资源池后，通常会给多个租户使用，包括多个内部使用团队等场景。
5.1 云平台产品化的多租户能力 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 实现多租户隔离。
5.2 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，代表无隔离可以全互通。
5.3 RoCE 网络的多租户方案
RoCE 网络的多租户隔离目前主要通过给不同租户划分不同网段，再结合 ACL，实现租户间隔离和租户内全互通。具体的实现方案是，给不同租户分配不同 IP 地址段，通过网络 ACL 实现仅允许同网段 IP 互访。
整个过程是通过云平台和 RoCE SDN 控制器配合实现的。在服务器启动后，服务器会上报租户 ID 和对应的 RDMA 交换机上联端口给云平台。云平台根据租户 ID 信息给服务器分配对应的子网和 IP 地址。之后云平台会调用 RoCE SDN 的接口，把租户的网段的 ACL 规则配置到上联口对应的 RDMA 交换机上。
5.4 通过 RDMA 网络提供公共服务
在一些场景下，GPU 集群需要通过 RDMA 网络访问一些公共服务，如并行文件存储 PFS（Parallel File System）系统。
可以把这种类型的服务也看做是一个 RDMA 网络的租户，通过 RDMA 网络控制器设置该租户的访问控制策略。以 RoCE 网络为例，把 PFS 服务也作为一个租户，在云平台中进行统一管理，并对应的调整网络访问控制策略，实现不同租户都可以访问 PFS 服务。
5.5 典型实践
智算中心一般由政府 / 园区 / 大型企业集中建设，并以云服务模式给政府相关部门 / 园区企业 / 大型企业子公司提供算力服务。
使用算力服务的租户有不同的算力需求场景，如 AI 推理、AI 训练（小规模单机单卡、中规模单机多卡、大规模的多机多卡）、模型评估和推理等。数据和算力（CPU、GPU）作为 AI 的两大要素，针对这些场景，智算中心建设方需解决好如下问题：
租户间的数据和算力的安全隔离；
租户内算力和数据之间通信效率，训练速度。特别是在多机多卡和单机多卡的场景下，对训练时的热数据快速拉取和存放，提高 GPU 的利用率；
数据和算力之间高速网络的可管、可控和可视化。
在某智算中心案例中，部署了高速 RoCEv2 网络用来解决算力和数据之间的通信，并实现多租户安全隔离。部署了并行存储，用来存放训练热数据，以及部分推理场景下对数据有实时 / 准实时要求的数据。
06
总结和展望
百度在人工智能方面一直保持着高强度的投入，在 AI 领域的芯片层、框架层、模型层、应用层有深厚的积累和沉淀，这也使得百度智能云成为国内率先训练出生成式大语言模型的云。基于这些积累，百度智能云在“AI 大底座”的私有化方面也有丰富的创新和商业化落地实践。
高性能智算网络作为“AI 大底座”基础设施层的关键组成部分，在智算节点间的高速互联，提升智算业务的训练和推理效率，缩短上层应用发布和上线时间方面起着重要的作用。
在百度智能云专有云 ABC Stack 智算版的高性能智算网络方案中，基于导轨优化的大带宽高吞吐的 AI-POOL 智算网络架构、智算网络的多租户方案 AI-VPC、智算网络可视化网管系统 AI-NETOP 都已形成了成熟的产品化能力和解决方案，并在金融行业、汽车行业和政府机构落地了商业化的用户案例，帮助客户高效地运行智算应用，让人工智能战略得以快速落地。同时也助力智算业务从可运维向可运营方向发展，让客户在在智算领域的创新和突破变得简单和方便。
百度智能云专有云 ABC Stack 一直秉持开放和创新的心态，致力于为客户打造持续开放、不断创新的私有云。在高性能智算网络领域，百度智能云一方面会持续投入研发资源，打造先进的产品和解决方案，快速满足客户的新需求，解决客户的痛点；另外一方面，也会继续加强和业界优秀供应商的深度合作，通过强强联合的方式打造用户满意的产品和方案。
智算业务当前像一个冉冉升起的朝阳，在蓬勃发展的同时，智算网络的新需求和新技术在持续涌现，百度智能云愿意与更多的客户和伙伴一起携手并进，努力创新，为智算业务的发展贡献力量。
ChatGPT狂飙160天，世界已经不是之前的样子。
新建了人工智能中文站https://ai.weoknow.com
每天给大家更新可用的国内可用chatGPT资源
版权归原作者 mydear麦田 所有， 如有侵权，请联系我们删除。