翻译自“From bare metal to a 70B model: infrastructure set-up and scripts”
原文地址：https://imbue.com/research/70b-infrastructure/
先容在几个月的韶光里，我们与一小群研究职员和工程师一起，在我们自己的根本举动步伐上从头开始演习了一个 70B 参数模型，该模型在推理干系任务上的表现优于零样本 GPT-4o。
本日，我们将分享一个用于设置所需根本举动步伐的端到端指南：从启动初始集群和安装操作系统，到自动从演习期间碰着的缺点中规复。在每个步骤中，我们都会详细解释我们碰着的寻衅以及我们如何办理这些寻衅。除了我们的履历之外，我们还发布了许多为确保主机康健而开拓的根本举动步伐脚本，以便其他团队可以更轻松地为自己的模型演习创建稳定的根本举动步伐。
除了我们的详细流程之外，我们还发布了：
主机级康健检讨：确保给定主机不存在已知缺点的脚本 （https://github.com/imbue-ai/cluster-health/tree/master/health_checks）NVIDIA Collective Communication Library (NCCL) 补丁，可改进缺点和停顿的日志记录 压力测试，确认 GPU 能够分配大张量并实行标准操作 https://github.com/imbue-ai/cluster-health/tree/master/gpu_stress_test网络测试，检讨给定机器上的 GPU 是否能够相互通信（通过 NVLink）以及与其他机器上的 GPU 通信（通过 InfiniBand）https://github.com/imbue-ai/cluster-health/tree/master/host_validation解析 Unified Fabric Manager (UFM) 事宜日志、检讨干系事宜并确定应禁用哪些网络端口的脚本 https://github.com/imbue-ai/cluster-health/tree/master/ufm_events为 InfiniBand 构造天生全面的老化事情负载的脚本，旨在测试每个可用链接 https://github.com/imbue-ai/cluster-health/tree/master/ib_burn在全体过程中，我们的工程团队成员与Voltage Park 的互助伙伴互助，准备集群以供生产利用。完全流程涉及：
配置单独的机器配置 InfiniBand确保机器完备康健诊断常见培训问题改进根本举动步伐工具下面更详细地描述每个步骤。
背景：这该当如何运作我们打算的目的是实现大规模措辞模型的快速实验。为此，我们须要大量能够高速相互通信的快速 GPU。
本文重点先容一个集群，该集群拥有分布在 511 台打算机上的 4,088 个 H100 GPU，个中一台打算机有 8 个 GPU。有 511 台打算机配备 GPU，由于须要为管理 InfiniBand 网络的 Unified Fabric Manager 节点保留一些连接。在配备 GPU 的 511 主机上，每个 GPU 直接连接到 ConnectX-7 卡，该卡可以通过自己的 ConnectX-7 卡以 400 Gbps 的速率同时向 InfiniBand 网络上的任何其他 GPU 进行传输和吸收。
我们的 InfiniBand 网络拓扑被称为“完备无壅塞（fully non-blocking）”，由于理论上每个 GPU 都可以以最大速率同时与另一个 GPU 通信。这是通过三层 InfiniBand 网络架构实现的：三层 InfiniBand 交流机在精确连接时，可以在全体网络上实现这种高水平的吞吐量。请参阅下文理解 InfiniBand 网络的概述：
请把稳，演习网络的通信是通过 InfiniBand 进行的，而不是通过以太网进行的。虽然这些机器也连接到以太网，但该网络用于传输数据集、检讨点和其他数据。通过以太网发送数据的速率会慢得多，由于数据首先从 GPU 传输到 CPU，然后从个中一张 100 Gbps 以太网卡发出。虽然可以利用名为RDMA over Converged Ethernet (RoCE) 的技能通过以太网进行演习，但这须要在硬件和软件方面进行大量额外事情，并且常日不如 InfiniBand 可靠（请参阅此概述了广泛过程的论文）。
还有一个纯粹用于配置和管理的赞助以太网，支持访问基本输入/输出系统 (BIOS) 的掌握器接口、电源和其他低级机器接口。如果没有这个管理网络，我们将不得不该用 USB 驱动器、键盘和显示器手动设置节点，这对付数百台机器来说并不是不可持续的方法。
利用我们的集群进行高性能演习意味着每个组件（InfiniBand、以太网、GPU 和节点本身）都必须近乎完美地事情。如果 12,000 多个连接中哪怕只有一个连接有点不稳定，都可能会减慢全体演习运行的速率。
这篇文章的别的部分详细先容了实际达到统统完美状态并确保保持这种状态的过程。
流程：如何从裸机过渡到完备运行的集群配置单独的机器通过管理网络与集群建立初始以太网连接后，我们得到了基板管理掌握器 (BMC) 的访问凭据。BMC 是一种专门的做事处理器，用于远程监控主机系统，常日连接到单独的网络。它使我们能够与每台机器进行交互，就彷佛我们亲清闲场一样，并为硬件康健状况、BIOS 设置和电源管理供应了额外的 API。
这些组件就位后，我们就卷起袖子开始设置集群。
第 0 步：配置一台机器我们首先利用 iDRAC（戴尔的底板管理掌握器）在一台做事器上安装 Ubuntu 22.04，该做事器将用于设置其他所有内容。除此之外，iDRAC 许可我们通过浏览器中供应的虚拟掌握台从本地打算机安装和启动 ISO 映像。空想情形下，这是此过程中唯一的手动安装。
第 1 步：在每台机器上安装操作系统在处理了零号病人后，我们连续安装了 Ubuntu 的 Metal-as-a-Service (MAAS) 软件来帮助配置别的的做事器。利用预启动实行环境协议 (PXE) 勾引和自动化的 iDRAC 工具，我们指示每台机器从网络勾引，并配置 MAAS 以相应 PXE 勾引要求。在实行初始网络勾引时，做事器通过动态 IP 分配协议 (DHCP) 从 MAAS 吸收 IP 和初始内核，而不须要在本地驱动器上安装任何东西。这种精简环境被自动用于实行持久的操作系统安装。理论上，我们只需等待第一次勾引，统统都会被处理好。然而，实际上，MAAS 与 BMC 的集成并不可靠，因此我们利用 iDRAC API 预先网络每台机器的 MAC 地址（唯一的物理硬件标识符）。
在全体培训过程中，MAAS 常日是堆栈中可靠的组件。然而，我们在开始时碰着了一些特定于我们设置的困难。例如，在最初的几次配置中，时钟偏差如此之大，以至于 HTTPS 证书验证问题阻挡了通过 apt 安装任何东西。同样，由于 MAAS 做事器必须卖力许多职责（DHCP 做事器、主机名到 IP 解析的 DNS 做事器、主机和官方 Ubuntu 经办事器之间的 HTTP 代理、NTP 做事器、cloud-init 配置管理以及连接 MAC 地址到 IP 到主机名到自定义元数据的基准数据库），我们难以追踪问题的根本缘故原由。此外，还有 MAAS 配置生命周期的学习曲线，由于它被设计用于处理管理全新支配以及节点的逐步迁移和各种调试/不康健的中间状态的繁芜性。
第 2 步：诊断破坏的机器在设置大型 GPU 集群时，我们创造大约 10% 的机器无法启动，紧张是由于做事器的物理问题。我们碰着的一些问题包括：未连接或接线缺点的以太网电缆、iDRAC 的硬件问题、破坏的电源单元、坏的 NVME（非易失落性内存快车）驱动器、短缺的内部电缆以及无法显示的网络卡或 GPU。我们自动检讨这些问题，将一些机器返还给戴尔进行重新测试，并为数据中央事情职员提交了适当的工单。自己动手设置集群的一个好处是，我们能够立即利用康健的机器，同时等待其他机器的掩护。
第 3 步：最小（可行）可不雅观测金属我们在每台做事器上设置了以下内容：
Docker（用于更轻松地运行做事和演习作业）数据中央 GPU 驱动程序Prometheus 节点导出器（用于导出稳定的硬件/操作系统指标流）DCGM 导出器（来自 NVIDIA 的额外指标，用于 GPU 状态/时钟/利用率）所有非操作系统驱动器上的 RAIDZ ZFS 池（这使得机器能够在一个驱动器故障时连续运行，还供应透明压缩功能，对付纯文本数据集和重复日志特殊有用，常日使我们能够利用比平时多约 10 倍的空间）然后我们运行基本的 GPU 诊断，以确定 GPU 是否大部分功能正常——那些不正常的常日会在几个小时内涌现硬件问题。
在此期间，当我们考试测验并行安装所有 400 个节点的软件包时，碰着了一些带宽瓶颈。这也是我们第一次在数据中央支配的各个组件上收到高温警报。第一批热量问题紧张通过固件更新得到了缓解。
第四步：单节点GPU演习下一步是确保每台机器都能独立处理真实的 GPU 事情负载。由于一些问题，许多人无法做到：
与 GPU 干系的缺点，大多是通过将卡重新插入插槽来修复的：将 200 磅重的做事器从机架中物理滑出，拆下盖子和 GPU 之间的所有电缆，然后取出 GPU 并将其放入在改换所有电缆并重新安装做事器机架之前再次实行此操作。根据 Ubuntu 做事器日志，GPU 和外围组件互连 Express (PCIe) 总线或网卡之间的许多电线报告“limited width: x4 < x16” 。更新 PCIe 交流机总线固件后，我们创造集群中大约四分之一的主机须要重新安装内部 PCIe 电缆 - 可能是由于相称薄弱的电缆位于外壳和 GPU 之间，这意味着它们会破坏每当有人想要对 GPU 进行掩护时，就会被推挤或拔掉插头。许多杂项故障影响了个位数的主机。戴尔通过固件升级帮助我们修复了这些问题：NVMe 驱动器没有显示故障，但在被触碰时锁住了整台机器。硬盘在 Linux 下随机显示顺序，这使得 MAAS 产生混乱，并导致操作系统安装在缺点的驱动器上。缺点的温度读取导致风扇一贯以 100% 的速率旋转。这部分是由于 NVIDIA 驱动程序问题，我们通过降级到以前的驱动程序版本办理了这个问题。CPU 的动态频率缩放失落控，将活动核心限定在 2 GHz。直接 GPU-GPU 通信（GDR 或 GPUDirect RDMA Peer Memory Client）无法成功运用。配置 InfiniBand
第0步：安装UFM
InfiniBand的一个上风是其集中式设计，它为全体网络供应了一个大脑。因此，我们只须要处理织物中的320个网络交流机中的一个实体。我们的第一项任务是找出哪个交流机连接到哪些机器，然后将其与布线图进行关联，并按其物理位置重命名交流机。
第1步：重新布线
最初，UFM无法检测到320个网络交流机，更不用说织物中估量存在的所有主机了。与数据中央的互助伙伴协商后，我们确认交流机已通电并接线，但仍无法检测到。检讨网络布线列表后，我们创造织物的顶层设计有误：我们有八个不相连的网络，而不是一个统一的织物，没有共同的路由路径。重新布线后，我们添加了检讨，以验证所有物理连接是否与新设计同等。
第2步：一万个温度警报
办理物理布线问题后，UFM成功与织物中的所有InfiniBand交流机建立了联系。然而，险些每个交流机端口都开始报告温度过高，有时乃至超过70摄氏度，只管它们还没有传输数据。我们创造问题在于同一网络机架内的交流机之间存在空隙，导致热空气回流到前面。我们的数据中央互助伙伴帮助我们迅速诊断并制订了得当的办理方案。
第3步：1800个警报
许多端口还显示出高缺点率或在事情和故障状态之间颠簸，称为“flapping”。这些问题仅在端口被积极利用时才会涌现，因此预先检测非常困难，由于全体织物由10000个链接组成，并且具有高度冗余性。我们的数据中央互助伙伴帮助清洁并重新插入警报端口，同时我们禁用了别的的警报收发器，并等待改换。
只管InfiniBand对硬件故障具有很高的弹性，但一旦约10%的织物开始涌现问题，自适应路由等功能就无法可靠地事情，以应对随意丢失的链接。
在此期间，我们设法进行了100到200台机器的多节点演习运行。我们的过程基本上是即兴的：有时我们会在一组随机节点上启动，不雅观察它们的性能，并只管即便在尽可能多的这些节点上连续运行。这种方法使我们能够找到InfiniBand织物中可靠的子集，但很棘手，由于每次我们变动用于演习的节点集时，默认的InfiniBand链接集也会变动。
第4步：燃烧吧InfiniBand，迪斯科地狱
为了更有效地诊断InfiniBand问题，我们为全体集群设计了一种专门的事情负载，重点是在全体织物的每个端口同时推动尽可能多的数据。这与在全体集群上运行一个大型all-reduce事情负载不同，后者将利用NCCL在单个节点内优化通信，使GPU通过Server PCIe Module (SXM)插槽利用NVLink进行通信。
相反，我们选择了一种蛮力方法，并取得了显著成功。UFM开始发送警报，指出大多数端口的数据传输超过理论容量的97%，有些交流机暂时崩溃。终极所有端口都被认为足够强大，可以连续操作，而别的的端口则被禁用或交给后续维修。
第5步：GPUDirect RDMA
为了使GPU能够进行通信而不产生CPU开销，我们启用了名为GPUDirect RDMA的功能，许可直接与InfiniBand网卡通信。这涉及两个关键步骤：
启用额外的内核模块确保禁用PCIe访问掌握做事（ACS）以防止立即挂起第6步：扩大黄金做事器集
对付利用最新硬件的GPU集群，有一个履历法则：每周大约有3%的机器会涌现故障。
然而，有一个关键的细微差别常常被忽略：并不是每台机器都有均匀的3%故障概率，而是少数几台问题机器以不同的办法反复涌现故障，直到它们被精确修复。这突显了在同一织物上拥有大量机器的上风。与其在大型演习运行中对随机机器进行打地鼠游戏，不如专注于扩大已知可靠的或“黄金”机器集。
第7步：掩护
InfiniBand的掩护紧张涉及相应UFM警报、改换故障电缆和收发器，有时还须要诊断更难办理的缺点，如故障交流机。大规模回归常日由两个成分引起：
固件升级，特殊是仅运用于集群的一半时，可能会毁坏UFM状态，导致须要在所有InfiniBand交流机上重启UFM。同时大规模重启GPU主机，可能会用更新淹没UFM状态，类似地须要重启UFM做事。确保完备康健的机器
在这个过程中，我们创造了许多单独的机器可能失落败或减慢演习运行的办法。许多这些故障模式并不立即显现，因此我们编写了许多康健检讨来确定哪些主机足够康健以用于演习。我们在此发布了这些代码。
请把稳，许多这些康健检讨是特定于我们的运行时环境的，不一定与根本硬件有关，或者是极其噜苏的修复或自动化。这是故意为之的：为了使我们的机器准备好进行演习的总体目标，我们希望有一个单一的入口点来回答“是”或“否”，并且可以抽象掉任何数量的“噜苏”细节。
GPU康健检讨
我们检讨是否有精确数量的GPU，是否启用了ECC（缺点校正码）检讨，并且没有ECC缺点。我们还检讨了连接GPU之间的NVLink拓扑是否正常且无缺点。
磁盘空间康健检讨
我们检讨主机的磁盘空间利用率不超过95%。
Docker康健检讨
我们检讨Docker是否能够运行附有GPU的容器（即NVIDIA容器运行时是否正常事情），并且所有与监控/剖析干系的Docker容器是否都处于活动状态并具有精确的主机权限。
Dmesg康健检讨
我们检讨dmesg中是否有硬件Xid或SXid缺点（由NVIDIA GPU或GPU之间的NVIDIA交流机抛出的故障）。我们还读取所有dmesg日志行，以验证它们是否都可以分类为“常见/预期的日志行”。
iDRAC康健检讨
我们检讨主机上的iDRAC缺点，忽略非致命的缺点。这是我们戴尔机器特有的，不是我们开源的康健检讨的一部分。
磁盘康健检讨
我们检讨zpool是否已挂载，Docker是否精确连接到它，并且可以实际利用而不会导致CPU锁定。
InfiniBand康健检讨
我们检讨是否存在增加的InfiniBand缺点率和/或过期的驱动程序固件。
Nvlink康健检讨
我们检讨主机上的NVLink缺点。根据履历，这彷佛不会导致演习失落败，但可能会导致速率变慢。
GDR康健检讨
我们检讨主机是否启用了GDR。
VBIOS康健检讨
我们检讨GPU的VBIOS版本以及H100基板固件是否为最新。
Flint康健检讨
我们利用flint和hca_self_test检讨是否拥有精确版本的Mellanox OFED驱动程序、卡固件和收发器固件，并且它们是否精确地与NVIDIA驱动程序编译。
PSB康健检讨
我们查询PCIe设备，检讨连接速率和宽度是否符合我们在GPU、PSB（PCIe交流总线）和网络卡之间的预期。我们还检讨交流机固件是否为当前版本。此脚本由戴尔开拓，而非Imbue，因此我们目前无法共享。
除了这些快速康健检讨外，我们还有一些更繁芜的康健检讨，包括：
通过PyTorch初始化矩阵打算并丈量NVLink带宽、GPU打算速率和内存。我们设置了适当的GDR标志，以测试InfiniBand和NVLink。利用ib_write_bw和–use_cuda通过IB卡发送数据，并丈量PCIe和InfiniBand卡带宽。我们运行了较永劫光（约15分钟），以确保捕获到不稳定的InfiniBand链接。运行多节点诊断运行，以检讨NCCL初始化能力及其是否会随机停滞。如果停滞，我们的NCCL代码分支会添加额外的日志记录。检测问题可能须要12到24小时，因此我们常日仅对新节点或疑惑有问题时运行此程序。检讨DCGM导出的任何GPU时钟节流事宜（不包括预期的gpu_idle和power_cap）。同时磨炼所有GPU、InfiniBand卡、CPU和磁盘的多节点演习是磨炼这些功率事宜的最佳办法。诊断常见演习问题
硬件问题导致的范例NCCL缺点包括：
由于某些节点的GPU间通信无法进行NCCL初始化，因此缺点可能会提到卡上的某些GPU超时。办理此问题的最常见方法是改换问题节点，并重启NCCL会话。如果GDR硬件有问题，可能会涌现NCCL hanging（停息）或性能低落。由于NCCL利用GPU内存进行通信，因此任何内存硬件问题都会导致NCCL缺点或性能低落。调试这些问题的方法之一是运行带有适当日志记录的NCCL测试事情负载，并查找缺点或挂出发点。
启动时崩溃在某些方面，这是最随意马虎处理的缺点，由于理论上它是随意马虎重现和迭代的。
我们首先检讨是否在精确的版本、配置和环境变量下运行代码。虽然这很根本，但我们创造确保启动演习是可重现且易于检讨的至关主要，尤其是像Docker镜像缓存或不透明的秘密配置这样的中间抽象可能会让问题繁芜化。
我们进行的另一个基本检讨是确保所有机器都在线，并且可以轻松聚合和检讨天生的堆栈跟踪或日志。我们利用了Loki、Prometheus和Grafana栈，但任何得当的日志聚合或跟踪SaaS都是适用的。由于这些运行是同步和分布式的，常日第一个触发的缺点会导致持续串不干系的缺点。在这里，康健检讨也有助于即时检测明显的问题，例如硬盘破坏或GPU缺失落或无效。
我们构建了一个在失落败时自动重新启动的系统，这使得日志和缺点聚合更加主要，以避免稠浊来自不同重启的缺点。我们碰着的一些常见缺点包括：
缺点如“各个等级的前向顺序不同：等级0正在全聚合43个参数，而等级1228正在全聚合1个参数”。我们创造这是PyTorch全分片数据并行（FSDP）实现的一个怪癖，可以通过重新启动办理。GPU内存不敷（OOM）缺点，看起来像“CUDA内存不敷。考试测验分配...”。我们通过仔细检讨配置和代码，并撤销任何可能导致GPU#0额外利用的不当PyTorch设备指定的最近代码变动来修复这些缺点。CPU/RAM内存不敷（OOM）缺点，这些缺点从缺点日志中不随意马虎创造，常日最好通过Docker容器外的主机的dmesg日志检测。我们紧张通过dmesg日志中的CalledProcessError或ConnectionError来看到这些缺点，当一个派生进程或网络对等体被OOM Killer调用收割时。我们更方向于在检测到dmesg中的OOM Killer调用时仅失落败康健检讨并重新启动主机。我们还检讨了代码路径是否有足够的手动垃圾网络量（拜会以下关于如何禁用它的部分），并且不会意外地考试测验在CPU上进行打算或移动张量。演习中途崩溃首先要做的是自动化系统以重新运行所有诊断康健检讨（拜会前几部分），然后在没有不康健主机的情形下自动重启运行。我们碰着了一些随机硬件故障，包括Xid和SXid缺点，这些缺点可能会在不发出故意义的Python堆栈跟踪的情形下使运行崩溃。有些实例（如行重映射）可以通过重启规复。其他实例（如不可纠正的ECC缺点）常日须要硬件掩护或改换部件。
此外，我们不雅观察到由特殊畸形的演习数据引起的崩溃。例如，语料库中的单个非常大的文档可能会在GPU或CPU中引起OOM缺点。为防止这些缺点，我们有一个完备确定性的数据加载器，这使得每次崩溃都可以通过与epoch或步骤编号的干系性轻松重现。我们创造禁用数据加载或更换假数据（如全零）来确认数据是否确实是根本缘故原由是有帮助的。
末了，通过任何首选的指标聚合方法记录网络和一样平常节点康健统计信息也是有帮助的。像以太网短暂中断或磁盘空间不敷等问题可能不会显示为有用的缺点，但可以通过网络的数据轻松关联。
没有堆栈跟踪信息的挂起（可能会在超时后涌现）这类缺点由于缺少有用的信息并且常日难以可靠重现，调试起来非常令人沮丧。
最令人印象深刻的类型以如下缺点为特色：
css
复制代码
Watchdog caught collective operation timeout: WorkNCCL(SeqNum=408951, OpType=_ALLGATHER_BASE, ... , Timeout(ms)=600000) ran for 600351 milliseconds before timing out
这些缺点会同时涌如今演习运行中的所有GPU事情节点上。
这意味着一个或多个主机未能完成NCCL操作，乃至从NCCL和InfiniBand连接中崩溃，导致所有其他主机在特定张量操作上同步壅塞，直到达到NCCL_TIMEOUT。不幸的是，NCCL库的性子使得很难找到哪个特定主机是罪魁罪魁。
我们对NCCL库进行了日志记录变动（拜会我们的分支）以更好地显示崩溃时正在进行的或操作，从而识别出彷佛阻挡运行的主机或GPU。
请把稳，为了识别行为不当的主机，我们常日须要找出哪些主机没有天生某些日志。短缺这些表明该主机上的事情节点是滞后的或已崩溃。
其他没有有用缺点的不相应实例常日与硬件干系问题有关，例如上述Xid/SXid/ECC缺点导致NVIDIA驱动程序或NVIDIA docker通信驱动程序锁定。为了区分NCCL挂起和驱动程序挂起以及Python代码中的竞争条件或去世锁，我们利用了包括Py-Spy和GNU Project Debugger (GDB)在内的工具来实时调试碰着的结束进程。通过这种方法，我们捉住了一个特定问题，由于Python线程设置中的配置缺点，我们无法在某些主机上精确启动八个多线程NCCL GPU进程，这些主机在PyTorch初始化代码之前的某个阶段碰着了竞争条件。
演习速率减慢（以 MFU 衡量）缺少仪器可能会使这些类型的问题比前一类问题更加令人沮丧。除了打破 Py-Spy、堆栈跟踪检讨和 GDB 之外，我们还推出了 NVIDIA Nsight 和剖析工具来供应帮助，个中一些工具在高度分布式设置中很难利用。
遗憾的是，普遍的速率低落或低于之前演示的模型失落败率利用率 (MFU) 可能是由多种缘故原由引起的。
首先，事实证明，仔细检讨配置、代码和环境变量很有帮助。我们经历过运行缺点的模型、缺点的批量大小、缺点的 UFM 或 NCCL 设置、缺点的CUDA_DEVICE_MAX_CONNECTIONS，所有这些都会导致性能不佳。
我们还创造丈量瞬时（即每批次）MFU 而不是平滑或窗口均匀值很有用，由于 MFU 曲线的预平滑形状常日可以帮助我们诊断问题种别。问题包括：
演习立即以极低的 MFU（低于预期的 1/10）开始并保持稳定这常日是 InfiniBand 网络的硬件问题，例如 T2 或 T3 层的去世交流机。它也可能是由 GPU 和 NIC 之间的硬件问题引起的，在 dmesg 中显示为PCIe x16 lanes limited by …
演习立即以预期 MFU 的 30% 开始并保持稳定这可能是由于一台主机的 GDR（NVIDIA 对等内存）设置禁绝确或 GDR 环境变量禁绝确造成的。
演习立即开始，约为预期 MFU 的 60-80%，并保持稳定最常见的是，这是由 InfiniBand 链路降级或故障引起的，特殊是如果单个特定 GPU 的关联 InfiniBand NIC 涌现故障，导致 NCCL 考试测验通过本地 NVLink 路由流量并利用同一主机上另一个 GPU 上的 NIC。它还可能是由 CPU 节流引起的，这须要针对特定主机调度一些 BIOS 设置。
定期发生的单批次溘然大幅低落（10 倍）这险些肯定与检讨点或评估有关——可以通过检讨纪元或步数来验证。令人烦恼的是，如果设置自动警报只是为了触发 MFU 非常，这会导致许多误报。
单批次溘然急剧低落（10 倍），这种情形随机发生且相称罕见（大约每 15 分钟一次），但随后立即完备规复到良好的 MFU这彷佛最常见是由运行中的一台主机上安排的其他 CPU 密集型事情负载引起的。我们创造通过 PID 粗略地监控 CPU 利用情形更随意马虎，而不是构建剖析工具来识别特定主机。这也可能是由于网络偶尔较差造成的，例如数据加载器瓶颈。我们利用了指标监控，并为数据加载、检讨点和任何非 NCCL 代码添加了 Python 代码计时日志，事实证明这非常可靠。
MFU 图在运行过程中逐渐低落，但在重新启动后规复到 100%从理论上讲，这可能是由开关上的热量积聚引起的，但我们从未见过这种情形。相反，我们利用 Python 和 NVIDIA 剖析器来确定性能低落彷佛是自动垃圾网络的结果。
在调试这些减速过程时，我们把稳到吞吐量周期性低落的模式险些是确定性的。随着演习的进行，低落对分布式操作的影响逐渐增大。这导致了一个假设，即低落可能与自动垃圾网络有关，我们通过剖析和测试验证了这一点。一旦我们禁用自动垃圾网络并在所有主机上按特定时间间隔进行操持垃圾网络，这些吞吐量“低落”就消逝了。
我们利用了基于ZeRO-3的同步分布式演习算法 FSDP 。在壅塞操作期间，运行垃圾网络的单个事情进程可能会减慢所有其他事情进程的速率。对付数百个事情进程，这可能会导致速率显著低落。
开始时性能良好，然后溘然低落（达到预期的 70%），并且持续高频率（每 15 秒）我们不雅观察到这与 NVIDIA GPU“时钟节流缘故原由”干系，我们通过对 NVIDIA DCGM 运用精确的设置来网络这些缘故原由。热量问题（GPU 温度或主机冷却风扇破坏/性能低落）或电源故障导致了这种情形。此外，当我们同时最大化所有 8 个 GPU 利用率和 8 个 NIC InfiniBand 利用率以及 CPU/RAM/磁盘时，我们的一些具有特定电源硬件的主机会涌现电压问题，但仅当所有这些都被利用时 - 常日仅在实际演习运行。
性能良好，但比平时“噪音更大”（高频白噪声方差在预期 MFU 的 90% 到 100% 之间）这也与 InfiniBand 硬件干系，但常日是由于网络中较高层而不是冗余度较低的主机到 T2 层的链路适度降级或抖动所致。
不幸的是，个中许多问题并不随意马虎确定到特定主机，而且由于 InfiniBand 交流机技能具有拓扑感知特性，与 InfiniBand 干系的问题尤其难以确定。InfiniBand 彷佛更喜好 InfiniBand 胖树设计中的相邻主机，并且 UFM 可能会以导致不对称链路速率的办法路由数据包。
以下是用于调试吞吐量回归的快速择要/流程图/健全性检讨表：
它曾经有效吗？您最近是否更改过某些内容（例如合并代码、更新驱动程序）？您是否在康健的主机上运行？您的所有依赖做事是否都在运行，包括第三方 SaaS，例如 Docker Hub、GitHub 或您的堆栈依赖的任何其他做事？您确定您利用了与上次完备相同的代码、环境、配置、版本、主机列表、排名顺序、随机种子（如果可能）吗？它可以重现吗？它与其他什么干系吗？其他流程？逐日定时任务？主机、DCGM 或 UFM 指标？您衡量指标的工具精确吗？运行减少的代码（较小的模型、假造的数据、没有检讨点保存或加载）时，问题是否仍旧涌现？改进根本举动步伐工具完成上述步骤后，人们在演习模型时可以得到良好的性能……至少在涌现不可避免的故障之前是这样。
在本节中，我们将先容一些不同的工具和系统，这些工具和系统是为了确保演习连续顺利进行，空想情形下须要最少的人为干预。由于我们是一个小团队，以是我们根本没有足够的职员来不断进行手动修复，因此我们考试测验尽可能多地实现流程自动化。
我们险些所有的演习运行问题都可以追溯到有故障的机器或网络组件。这些故障在大型集群中常常发生，因此必须自动化禁用故障机器和网络组件并要求修复的过程。
机器故障我们开拓了一个别系，可以从最近的检讨点自动重新启动崩溃的运行。重新启动过程将首先在每台可用机器上运走运行状况检讨，并根据每台机器通过的运行状况检讨对机器的运行状况进行分类；然后它会考试测验在最康健的机器上重新启动演习事情。
网络组件故障我们不雅观察到的所有网络组件故障均由 UFM 检测到并注册在 UFM 事宜日志中，因此相应网络组件故障只需解析 UFM 日志并针对每个事宜采纳适当的操作即可。
UFM事宜系统相称繁芜，包含数十种事宜类型。然而，在实践中，我们创造只有少数事宜存在问题，大部分与链接断开或符号缺点计数较高有关。识别这些事宜后，我们能够编写脚本来解析 UFM 事宜日志、禁用最近事宜中涉及的链接和端口、在这些网络组件上归档掩护票据，并在掩护完成后重新启用这些组件。
本地镜像文件系统早期很明显，大型分布式演习运行的瓶颈之一是进出集群的以太网速率。如果数百名事情职员试图同时下载数据集和模型检讨点，则带宽约为 10Gbit/s 的共享以太网连接很快就会饱和。
因此，我们决定在集群内构建一个本地文件系统来镜像云存储，并实质上充当缓存以减少我们须要从 S3 获取的文件数量。为了处理集群流失落（机器常日会因掩护缘故原由而被禁用或改换），我们对每个文件进行了三倍复制，利用同等的散列以最小化流失落期间文件移动的办法均匀分配负载。集群上有限的磁盘空间意味着我们还必须开拓各种工具来跟踪文件生命周期并打消不再干系的文件。
本地分布式 Docker 注册表我们还利用了Kraken，这是一款出色的开源软件，可以实现 Docker 镜像的点对点传输。我们险些没有碰着任何问题，考虑到任务和履行的繁芜性，这有点令人惊异。
各种性能监控工具我们设置了默认的 Torch 剖析器以及 NVIDIA 的 Nsight 系统。后者有助于准确理解前向/后向通报和 NCCL 通信须要多永劫光，以及确定我们是否因给定模型大小和事情职员数量的通信或打算而碰着瓶颈。然而，Nsight Systems 有点难以利用，由于它须要在特权模式下运行 Docker，禁用与性能监控事宜干系的安全检讨，并且保存配置文件常日须要停滞全体演习过程。
此外，我们创造编写工具来检测缓慢的演习批次并理解缓慢的潜在缘故原由很有帮助。个中最有用的是一个工具，它可以监视每个批次花费的韶光，并在批次非常缓慢时转储每个事情职员的堆栈跟踪 - 这使得更随意马虎识别具有细微硬件或软件问题的特定主机。
细分机器组以查明故障主机在我们利用集群的最初几个月（当时我们的康健检讨不像现在那么彻底），我们常常碰着这样的情形：在一组特定机器上运行的演习失落败，但不清楚哪台机器是失落败的有差错。为了查明有故障的主机，我们开拓了一些工具，可以轻松地将一组机器划分为子集，并在每个机器子集上启动较小的作业。
例如，如果 48 台机器上的作业失落败，我们将在 6 组（每组 8 台机器）上启动较小的运行，然后在 8 组（每组 6 台机器）上启动较小的运行。常日情形下，这两个阶段中的每一个阶段只有一次运行会失落败，这使我们能够高度自傲地得出结论，在两个阶段中都涌现故障运行的机器是有问题的。
反思和学习在建立和掩护根本举动步伐的过程中，我们网络了一些关于全体过程的有用知识：
能够互相交换机器是非常有用的。对付任何给定的演习运行，我们创造比运行所需的机器多 10-20% 会很有帮助，这样我们就可以在机器故障时轻松重新启动。以每台机器都与其他机器紧密连接的办法设置集群网络意味着我们基本上可以利用机器的任何事情子集。值得为您碰着的每种硬件或软件故障编写测试和自动化办理方案，由于演习期间碰着的每个问题都会再次涌现。同样，对付每个不透明的缺点，值得编写工具以使缺点更易于阐明。可重复性是良好科学的关键。我们很快采取的一条规则是“一次只改变一件事”，纵然是最大略的事情。信赖但要验证。每当我们在流程中引入外部工具或聘任新职员时，无论是外部还是内部，我们都会确保仔细检讨他们的声明，特殊是如果后续步骤取决于这些结果。结论演习大型措辞模型须要繁芜的根本举动步伐才能开始。我们选择深入参与根本举动步伐设置的细节，不仅由于我们相信充分理解我们利用的系统很主要，而且由于我们疑惑它终极会变得更加高效。现在，在完成了全体过程后，我们很高兴采取了这种方法 - 完备掌握我们的根本举动步伐并能够轻松调试每个抽象级别的问题至关主要。虽然这个过程须要大量的监督和迭代，但它使我们能够深入理解底层流程，构建一系列工具来确保主机康健，学习如何自动化系统以确保持续顺利的演习，
这个根本举动步伐流程表示了我们研究和为人工智能代理构建坚实根本的方法：探究实质细节，不断改进现有流程，并构建有用的工具和系统，使我们斗志兴旺的团队能够应对更大的寻衅。