目录

AI 高性能网络

三大目标

1. 超大规模：规模的大小直接决定了模型训练的快慢。对于一个 1750 亿的模型，如果采用 2 千张 GPU，仍然需要训练 100 天以上。采用 8 千卡则可以把时间压缩到 30 天左右。这对于今天快速迭代的大模型而言是非常重要的。
2. 超高带宽：Allreduce 的带宽直接决定了大规模分布式下的整体效率。平均单 GPU 的 Allreduce 带宽有 5GB/s 的时候，大规模分布式的整体加速比只有 70%。想要获得 90% 的加速比，单 GPU 的 AllReduce 带宽则需要做到 20GB/s，相当于单 GPU 跑满 400G 网卡。
3. 超长稳定：由于训练时长至少是几个星期，长时间下的稳定性显得非常重要。假定单 GPU 的月可用性是 99.9%，那么在千卡规模下模型训练一月内遇到故障发生中断的概率是 60%，而如果采用 8 千卡中断概率就有 99%。即使 GPU 的可用性提升到 99.99%，8 千卡下的中断概率仍然在 50% 左右。这里以 GPU 可用性举例，是因为大模型训练中碰到的主要可用性问题来自于 GPU。当然网络必须保证更高的可用性，才能尽可能减少模型的训练中断，降低模型做 checkpoint 的频率以及开销。

超大规模：网络拓扑

AI 高性能网络采用 3 层无收敛的 CLOS 组网结构。服务器在最下面，连接到 Leaf 层交换机，然后 Leaf 交换再通过 Spine 交换机连接起来，最后 Spine 交换机再通过 SuperSpine。

大模型训练的时候，主要的通信来自于同号 GPU 卡之间，也就是一台服务器的 1 号卡和另一台服务器的 1 号卡之间通信，一台服务器的 2 号卡和另一台服务器的 2 号卡之间通信，以此类推。较少的情况下才会发生跨卡号通信，比方说一台服务器的 1 号卡和另一台服务器的 2 号卡通信。

所以，AIPod 网络在设计的时候，采用了 8 通道的架构。每个服务器上的 8 个网口，对应 8 个 GPU，分别连接 8 个不同的 Leaf 交换机。这 8 个 Leaf 交换机一组，构成了一个汇聚组 Group。这样的一个汇聚组下最大可以有 512 张 GPU。进一步，8 个 Leaf 交换机再往上连入不同的 8 个通道，每个通道内 Spine 交换机和 Leaf 交换机之间做 fullmesh 全互联。这样的一个集群最大可以支持超过 16K GPU。

虽然主要的通信发生在同一个通道内，但总还是会存在跨通道的通信。所以我们通过 SuperSpine 再把不同的通道的 Spine 交换机连接起来，打通各个通道。

超高带宽：流量控制

单机采用 8x400G 的接入规格，网络采用收敛比 1:1 的 CLOS 架构，交换机的上联带宽等于下联带宽，确保集群内互通带宽充足。为了尽可能支撑更大的规模，采用了单芯片 51.2T 容量的交换机。同时也支持 RDMA 和 GDR，理论上带宽可以做到很高的水平。

但是当规模一大，就会产生很多的问题。其中一个最主要的问题，就是跨交换机的选路冲突。

从技术上说，几乎所有的网络传输都有一个固有的问题，就是同一条连接在网络内要避免乱序，因为一旦发生乱序，在接收端就会触发重传逻辑导致降速。所以网络内交换机转发报文的时候，会把同一条连接的报文会向一条路径转发，而这条路径的选择就依赖哈希算法。

哈希算法总是会有冲突的，像是左边这个图里展示的，2 个跨交换机的连接如果同时选择了左边这个链路，那么就会导致左边链路拥挤而右边的链路空闲，这样两个连接的带宽都会减半。这种问题在大规模训练中太常见了。

为了缓解这类问题的影响，我们通常会在 NCCL 通信库里面设置两个 GPU 间采用多个连接的方式，比方说右边这个图，连接数一多，出现严重不均衡的概率也就越小。这种方法可以增加网络内的路由熵，减小哈希选路冲突所带来的影响，但是问题并没有彻底解决。

我们可以看到，这类问题只发生在跨交换机通信的场景。所以为了进一步减小这个问题的影响，我们应该尽可能让通信发生在一个交换机内。而同一个汇聚组内的同号 GPU 通信，是不会跨交换机的，也就没有哈希选路冲突问题。这也是为什么我们尽可能扩大一个汇聚组规模的原因。

为了减少跨交换机的通信，在 AIPod 里我们提供了网络架构感知的方法。网络架构感知，就是允许上层感知到当前 GPU 在网络架构的什么位置，归属于哪一个汇聚组，它的 GroupID 是多少。

AIPod 可以把这个信息透给上层的任务调度系统，让训练任务调度的时候，把同一个任务尽可能调度在同一个汇聚组下，这样通信肯定也就只在一个汇聚组内了。

但是大模型的任务通常很大，不可能全在一个汇聚组下。这时我们就需要通过汇聚组信息对全局 GPU 做有序化处理，让通信库在构建 Allreduce 拓扑图的时候，减少跨交换机的互通流量。我们用右下角这个图来说明，4 个 GPU 做 AllReduce，采用 ring 算法，两种不同的 ring 的构建顺序，会使得跨交换机的带宽有很大的差别。显然左边的这种建 ring 的方法是更高效的，而右边则是低效的。这就是 AIPod 里面网络架构感知所带来的收益。

网络架构感知可以明显缓解跨交换机通信的数量，从而减少哈希选路冲突的影响。但是问题并没有彻底解决，冲突仍然存在。

如果想彻底解决这个问题，就需要用到网络的多路径转发能力。也就是允许报文的乱序接收，从而打破单连接报文只能选择一个路径这种假设。Infiniband 网络里面引入了这种多路径转发能力，叫做自适应路由。

而在 AIPod 里面，我们依托百度的自研交换机，在以太网上通过动态负载均衡 DLB 技术也实现了类似的能力。

就以下图为例，首先在发送端，网卡要通过标记允许报文被乱序处理，而在交换机上会根据当前各个路径上的队列深度、利用率等信息，计算出每个报文当前的最佳路径进行转发。这样肯定会引入同连接报文的乱序问题，所以需要在接收端对乱序的报文做重排处理。

经过这一系列的组合机制，就可以彻底解决跨交换机通信的哈希选路冲突问题。我们相信这种底层的技术能力增强，才是解决大规模训练的终极方案。

超长稳定：故障探测与恢复

保持任务长时间不中断对于大模型训练是很重要的，但是硬件终究会有故障。举个例子，对于一个可以承载 16000 卡的集群而言，里面会有将近 10 万个光模块。考虑到真实硬件的质量水平，假定一个模块的 MTBF 是 1 千万小时。这里 MTBF 指的是一个硬件设备在故障前的平均使用时长。因为模块基数太大，哪怕是 1000 万小时的 MTBF，也会导致平均下来 4 天左右就会发生一个故障发生。在这么大的基数下，单体的小概率事件也会演变成总体的大概率事件。

所以，AIPod 网络着重构建快速从硬件故障中恢复的能力。比如网络里面的某条链路发生了故障，通过这个链路的报文都会发生丢包。我们必须让这个丢包的时长低于通信库通常设置的超时时间，这样任务才不会中断。

在 AIPod 里面，对于上行方向的这一类丢包，通过动态负载均衡技术，可以在毫秒级的时间尺度上面得到修复，也就是选择新的可用链路。而对于下行方向的这一类丢包，需要触发网络内的路由更新和路由收敛，通过优化路由更新策略以及路由下发效率，来把下行方向的丢包时长控制在秒级水平。这样我们就可以做到网络内硬件故障对训练业务基本透明。

当然网络的复杂度在于，有一些硬件故障是不能被显式直接感知到的。比如某些交换机芯片缺陷所带来的比特翻转问题，会导致报文在传输过程中某个比特位被修改从而丢包。这种问题不像设备故障那样可以被直接发现，非常难以排查。

为了充分发现这些隐藏的问题，我们基于百度自研交换机设计了 AIPod 网络的黑盒探测机制，确保每条链路上每秒都有黑盒探测报文。探测一旦发现连通性问题就会触发自动的定位和隔离机制，把问题链路、问题设备隔离掉，并且触发告警，让运维人员快速介入进行修复。

AIPod 里面的黑盒探测机制，是保障各种网络问题被第一时间感知到的关键。

对于 AIPod 高性能网络而言，除了连通性故障以外，还有一类故障与连通性无关，而是与无损网络有关。

AIPod 高性能网络是无损网络，也就是说网络内不会产生拥塞丢包。这是依赖网络内的 PFC 技术实现的。但是无损网络也可能会有异常。

常见的一个异常是 PFC 死锁，这个技术上比较复杂，原理我们就不展开了，从效果上看会导致网络永久性挂死。因此我们在网络内一定会启用死锁检测。但问题在于，来自于交换芯片的死锁检测总是有假阳性判断的存在，从而导致瞬时误丢包。第二个常见异常通常是来自于芯片故障，尤其是网卡芯片故障所带来的持续性 PFC 风暴，这会导致集群整体的传输效率下降。

这两类与无损网络相关的异常是固有问题，我们目前还不能完全消除。但是，通过基于百度自研交换机的 Telemetry 遥测技术，我们搭建了无损网络的性能透视平台，确保网络内的任一丢包信息和 PFC、缓存的异常变化都能被迅速感知到。通过这样的性能透视平台，这类问题可以被第一时间发现并解决掉，最终并不会影响到大模型的稳定训练。

超低延时：调参优化

对于大模型训练而言，延迟并不是一个核心考虑，带宽才是核心。只要能做到微秒级别的网络延迟，在网络上进一步降低几个微秒的延迟在端到端的性能上几乎看不出任何的影响。但是从技术上说，仍然存在一些特定的 AI 业务是延迟敏感的。AIPod 网络也一样能满足低延迟的诉求。

先来拆解一下网络延迟的构成，除了总线、网卡、光模块、交换机的硬件延迟以外，我们真正有机会优化的只有两个延迟，一个是光纤延迟，另一个是交换机排队时延。

光纤时延之所以重要，是因为光速是有限的。光在玻璃里的传输速度是每秒 20 万公里，换句话说，两个 GPU 间每增加 200m 光纤，就会增加 1 微秒的时延。为了让集群内任意两个 GPU 之间的延迟尽可能低，AIPod 里我们优化了整个集群在机房内的布局，使得服务器和交换机以及交换机和交换机之间的距离尽可能近，从而能够采用更短的光纤连接。

另一方面，交换机排队延迟与交换机的缓存占用有关。一个交换机端口上每有 1MB 的缓存，就会导致 25us 延迟的增加。AIPod 内部我们优化了的拥塞控制参数，尽可能保证在不影响带宽的前提下，降低交换机的缓存占用，以此实现更低的延迟。

运维支撑

可视化工具

任务维度的高精度可视化工具对于判断任务是否正常训练非常的重要。这里有两个重点，一个是任务维度，另一个是高精度。

• 任务维度，指的是我们要能够把归属于一个任务的几百上千个实例的监控数据合并到一起来看。因为并行训练的特点，这些实例理论上展现出来的网络流量信息是高度一致的。一旦有不一致的存在，我们就很容易发现异常。

• 高精度，指我们的监控采集必须是秒级甚至是亚秒级的。我们前面提到，一次迭代的 Allreduce 通信量是 10GB 级别的，听上去很大，但是放到一个 100G 网卡上也不过只需要 2 秒的时间就传完了，如果是 400G 网卡只需要半秒的时间。所以，如果还是采用传统的 10 秒采集甚至是分钟级采集，那么我们对网络流量的观测一定是扭曲的，会干扰我们对于任务状态的判断。比如上面这个图展示的就是早期我们做的 10 秒采集，看到的峰值带宽只有 20G，这显然是不对的。等到我们做了 1 秒采集后，就可以精确的看到脉冲式的流量图，流量峰值也达到了 100G。

故障诊断工具

大模型训练经常会碰到各种各样的异常，很多异常会表现为通信库通信异常。但是这些异常的根本原因多数情况下并不是网络问题。举个例子，左边这个是我们一个客户的 case，在框架日志里面看到了 NCCL 相关的 Timeout。但是该 case 的真实原因其实是 GPU 的故障。针对这类问题，我们需要故障的一键定位，从各个节点的相关日志里提取信息并且自动分析，让故障的根因更快的被找到。

有些软硬件的问题并不一定导致任务完全卡死，而是会有慢节点的存在。大模型的训练会因为一个慢节点而拖累全局速度，也就是一点慢，全局慢，所以有的时候并不能直接通过任务维度的可视化工具找到问题所在。针对这个问题，我们也研发了对应的慢节点搜索工具，能够在一个集群内自动以二分的方式测试集合通信带宽，从而找到或者排除掉慢节点的存在。这对于真实问题的定位也是有很大帮助的。

AI 高性能存储

业务与数据流程分析

从数据的角度，可以将大模型的全生命周期拆分为 4 个主要环节：

1. 数据存储和处理：包括采集导入、清洗、转换、标注、共享和长期归档，是后面各环节的基础。
2. 模型开发：包括实验管理、交互式开发和效果评估等。
3. 模型训练：一是训练数据的读取，二是为了容错做的 checkpoint 的保存和加载。数据集的部分就是要尽量读得快，减少计算对 I/O 的等待，而 checkpoint 主要要求高吞吐、减少训练中断的时间。
4. 模型推理：需要把训练完的模型快速分发部署到线上，这个过程会高频、反复发生，要求高并发、高吞吐。

从业务流程的角度可以将上述 4 个环节整合为 3 个主要部分：

1. 大模型应用
2. 数据系统
3. AI 系统

基于对象存储的数据湖作为统一的底层数据平台

把数据系统中的数据流入、数据处理和数据流出的具体操作方式展开后，就会发现大模型场景中的数据处理需要依赖广泛的行业应用生态和解决方案进行频繁交互，所以传统存储不具备这种能力，需要使用数据湖存储。

而数据湖存储有 2 中具体的实现方式，一是以 HDFS 为代表的分布式文件系统，另一个是对象存储。但在云原生时代，基于对象存储的数据湖具有更好的数据行业生态融合优势。

基于此，可以使用基于对象存储的数据湖作为统一支撑数据系统、AI 系统和大模型应用的底层数据平台。最下面是数据湖，上面承接从数据系统到 AI 系统所有环节的需求，数据流动会被大大简化，各环节的衔接运转效率也会得到很大的提升。

对象存储加速层支撑训练场景

一个典型的训练过程会迭代多轮 Epoch，而每轮 Epoch 内会执行以下动作：

1. 首先，将 Dataset 进行 Shuffle（随机打散），然后将打散后的数据切分若干个 Batch。Shuffle 机制用于防止模型在训练中记住数据顺序，例如：样本总是按 “先猫后狗” 排列，使得模型可能学到错误关联。Shuffle 确保每个 Batch 的样本分布随机且均匀，以提升模型的泛化能力（对新数据的适应力）。
2. 然后，Read（读取）一个 Batch 的数据到 GPU 开始一个 Step 的 Training。
3. 最后，会周期性保存 Checkpoint（检查点/存档点）用于故障快速恢复。定期保存模型的权重参数、优化器状态、训练配置（当前 Epoch、学习率）等信息到持久化存储，用于训练中断恢复和模型部署与评估。

可见，每一轮 Epoch 的耗时都由 Data Shuffle、Data Read、Checkpoint 和真正的 Training 训练时间相加得到。从数据的角度出发，优化训练效率的方向主要是前面 3 个：

1. 优化 Shuffle 过程：优化前都是要 Shuffle 完成之后才能开始 Read 数据到 GPU。
2. 优化 Read 过程：优化前都是要 Read 完成之后才能开始 Training 训练。
3. 优化 Checkpoint 过程：优化前都是要 Checkpoint 完成后才能开始下一轮迭代。
   所以，它们 3 个都是要做得越快越好，和 Training 的 Overlap 越多越好。
   

优化 Shuffle 和 Read

Shuffle 只有单纯的元数据操作，主要依赖大量文件的 LIST；而 Read 既有元数据操作也有实际数据操作。
这意味着训练过程中用到的 KB 级别小文件越多，元数据操作的耗时占比也就越高。而对于小文件，延时和 QPS 是提升性能的关键。

对象存储对 Shuffle 和 Read 小文件的性能情况分析：

1. 元数据方面，对象存储采用分布式 KV 存储维护元数据目录，具有规模扩展优势（时间复杂度一致），但 LIST 操作延时偏高。
2. 对象存储传输协议的整个 I/O 处理路径较长，对于大文件可以忽略，但对于小文件的频繁读取则具有较高的延时开销。

可见，对象存储对小文件的 Shuffle 和 Read 不具有性能优势。而优化的思路就是：

1. 格式打包，减少小文件的数量。比如 TFRecord、HDF5 等格式已经被大量应用。
2. 硬件上使用 SSD 高性能硬件。软件上采用 PFS（并行文件系统），缩短 I/O 路径。
3. 利用 Dataset 只读的特点，将元数据和数据 Cache 到计算节点。

如下图，基于 PFS 和 Cache 的数据加速层来弥补对象存储的短板。

优化 Checkpoint

大模型单个节点的 Checkpoint 通常就能达到几十上百 GB。而多个训练节点同时写，需要恢复时又同时读，对存储提出了很高的吞吐要求。而且 checkpoint 期间整个训练是中断的。因此通过提高吞吐，将 checkpoint 耗时控制在尽量小的占比，对于减少训练等待、提高计算资源利用率同样非常重要。

优化前的同步 Checkpoint 方式，训练程序先将 checkpoint 写到性能相对容易保证的本地存储，然后再通过外围工具向远端对象存储上传。要保证每个 checkpoint 都成功写入，那么总耗时就等于写本地耗时加上传对象存储的耗时，总体等待时间较长。

基于数据湖存储加速以后，训练程序直接将 checkpoint 写入加速层的 Memory 或 NVME SSD，加速层采用流式上传的方式，不必等待 checkpoint 数据全部写完就开始向对象存储上传。此外，加速层也会采用分块上传的办法，充分利用对象存储的后端并发能力。

更进一步的，可以对 checkpoint 文件的 close 操作变成了异步，训练程序不用等待数据上传完成，即可恢复训练，剩下的工作全部交给加速层透明完成。此时耗时主要取决于加速层的 Memory 和 NVME SSD 写入能力，可以大大缩短 checkpoint 写入时间。加速层的存在使得可以通过 Overlap 的方式来突破上传对象存储的带宽限制。

同时，Checkpoint 采用异步写的同时，将让它驻留在加速层的缓存内。当训练需要恢复的时候就能直接从加速层读取，解决了 checkpoint 的快速加载问题。

数据湖+加速层

数据湖+加速层这套统一的存储方案，既能获得如同过去使用本地盘的便捷体验，又能充分享受背后数据湖存储带来的扩展性、高性能和繁荣的生态。

• 底层是对象存储 BOS，提供了大规模、可扩展、低成本的云原生数据湖存储产品，支持丰富的周边生态和便捷的数据流动。
• 中间是加速层，有 2 类产品可供选择。一是 PFS（并行文件系统），通过独立部署、高性能硬件和网络、全并行软件架构满足极致性能需求；二是数据湖存储加速 RapidFS，通过近计算部署提供更具性价比的分布式缓存加速能力。
• 最上面是的 AI 计算，包括异构算力、高速网络、云原生 AI 平台等。

AI 训练平台

TBD

参考文档

https://zhuanlan.zhihu.com/p/638769976
https://zhuanlan.zhihu.com/p/642685545
https://zhuanlan.zhihu.com/p/650122785
https://zhuanlan.zhihu.com/p/645801780
https://zhuanlan.zhihu.com/p/648694366
https://zhuanlan.zhihu.com/p/647051599