建设网站遇到问题的解决方案优秀网站推荐

建设网站遇到问题的解决方案,优秀网站推荐,wordpress 菜单消失,蚌埠本地网站目录 文章目录目录AI 高性能网络三大目标超大规模#xff1a;网络拓扑超高带宽#xff1a;流量控制超长稳定#xff1a;故障探测与恢复超低延时#xff1a;调参优化运维支撑可视化工具故障诊断工具AI 高性能存储业务与数据流程分析基于对象存储的数据湖作为统一的底层数据平…目录文章目录目录AI 高性能网络三大目标超大规模网络拓扑超高带宽流量控制超长稳定故障探测与恢复超低延时调参优化运维支撑可视化工具故障诊断工具AI 高性能存储业务与数据流程分析基于对象存储的数据湖作为统一的底层数据平台对象存储加速层支撑训练场景优化 Shuffle 和 Read优化 Checkpoint数据湖加速层AI 训练平台参考文档AI 高性能网络三大目标超大规模规模的大小直接决定了模型训练的快慢。对于一个 1750 亿的模型如果采用 2 千张 GPU仍然需要训练 100 天以上。采用 8 千卡则可以把时间压缩到 30 天左右。这对于今天快速迭代的大模型而言是非常重要的。超高带宽Allreduce 的带宽直接决定了大规模分布式下的整体效率。平均单 GPU 的 Allreduce 带宽有 5GB/s 的时候大规模分布式的整体加速比只有 70%。想要获得 90% 的加速比单 GPU 的 AllReduce 带宽则需要做到 20GB/s相当于单 GPU 跑满 400G 网卡。超长稳定由于训练时长至少是几个星期长时间下的稳定性显得非常重要。假定单 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 个主要环节数据存储和处理包括采集导入、清洗、转换、标注、共享和长期归档是后面各环节的基础。模型开发包括实验管理、交互式开发和效果评估等。模型训练一是训练数据的读取二是为了容错做的 checkpoint 的保存和加载。数据集的部分就是要尽量读得快减少计算对 I/O 的等待而 checkpoint 主要要求高吞吐、减少训练中断的时间。模型推理需要把训练完的模型快速分发部署到线上这个过程会高频、反复发生要求高并发、高吞吐。从业务流程的角度可以将上述 4 个环节整合为 3 个主要部分大模型应用数据系统AI 系统基于对象存储的数据湖作为统一的底层数据平台把数据系统中的数据流入、数据处理和数据流出的具体操作方式展开后就会发现大模型场景中的数据处理需要依赖广泛的行业应用生态和解决方案进行频繁交互所以传统存储不具备这种能力需要使用数据湖存储。而数据湖存储有 2 中具体的实现方式一是以 HDFS 为代表的分布式文件系统另一个是对象存储。但在云原生时代基于对象存储的数据湖具有更好的数据行业生态融合优势。基于此可以使用基于对象存储的数据湖作为统一支撑数据系统、AI 系统和大模型应用的底层数据平台。最下面是数据湖上面承接从数据系统到 AI 系统所有环节的需求数据流动会被大大简化各环节的衔接运转效率也会得到很大的提升。对象存储加速层支撑训练场景一个典型的训练过程会迭代多轮 Epoch而每轮 Epoch 内会执行以下动作首先将 Dataset 进行 Shuffle随机打散然后将打散后的数据切分若干个 Batch。Shuffle 机制用于防止模型在训练中记住数据顺序例如样本总是按 “先猫后狗” 排列使得模型可能学到错误关联。Shuffle 确保每个 Batch 的样本分布随机且均匀以提升模型的泛化能力对新数据的适应力。然后Read读取一个 Batch 的数据到 GPU 开始一个 Step 的 Training。最后会周期性保存 Checkpoint检查点/存档点用于故障快速恢复。定期保存模型的权重参数、优化器状态、训练配置当前 Epoch、学习率等信息到持久化存储用于训练中断恢复和模型部署与评估。可见每一轮 Epoch 的耗时都由 Data Shuffle、Data Read、Checkpoint 和真正的 Training 训练时间相加得到。从数据的角度出发优化训练效率的方向主要是前面 3 个优化 Shuffle 过程优化前都是要 Shuffle 完成之后才能开始 Read 数据到 GPU。优化 Read 过程优化前都是要 Read 完成之后才能开始 Training 训练。优化 Checkpoint 过程优化前都是要 Checkpoint 完成后才能开始下一轮迭代。所以它们 3 个都是要做得越快越好和 Training 的 Overlap 越多越好。优化 Shuffle 和 ReadShuffle 只有单纯的元数据操作主要依赖大量文件的 LIST而 Read 既有元数据操作也有实际数据操作。这意味着训练过程中用到的 KB 级别小文件越多元数据操作的耗时占比也就越高。而对于小文件延时和 QPS 是提升性能的关键。对象存储对 Shuffle 和 Read 小文件的性能情况分析元数据方面对象存储采用分布式 KV 存储维护元数据目录具有规模扩展优势时间复杂度一致但 LIST 操作延时偏高。对象存储传输协议的整个 I/O 处理路径较长对于大文件可以忽略但对于小文件的频繁读取则具有较高的延时开销。可见对象存储对小文件的 Shuffle 和 Read 不具有性能优势。而优化的思路就是格式打包减少小文件的数量。比如 TFRecord、HDF5 等格式已经被大量应用。硬件上使用 SSD 高性能硬件。软件上采用 PFS并行文件系统缩短 I/O 路径。利用 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/638769976https://zhuanlan.zhihu.com/p/642685545https://zhuanlan.zhihu.com/p/650122785https://zhuanlan.zhihu.com/p/645801780https://zhuanlan.zhihu.com/p/648694366https://zhuanlan.zhihu.com/p/647051599