Nodeox E1 研究分布式训练中 GPU 之外的耗时

训练轮次可能把大量时间花在GPU计算之外的工作上。在Nodeox E1中，我们利用一次16×A40、ViT-B/16实验的阶段级记录，一次双A40、ViT-H/14试运行，以及随后在一块AMD MI300X上的功能检查，对这些时间进行了考察。记录区分了缓慢的CPU侧更新编码与上传过程，暴露出不必要的全模型持久化，并推动了对协调器保留对象的修改。这些观察支持有针对性的工程结论。它们并不足以确立大模型多GPU扩展能力，也不构成受控的端到端加速。

从GPU计算结束到下一轮训练开始之间，究竟发生了什么？我们的基准测试文章描述了E1的扩展性和准确率结果。本文则考察这些结果背后的工作：准备更新、收集并合并更新、发回新模型，以及保留或保存全模型对象。

范围限于10月16–17日的观察以及10月29日的工程检查。后续实验另行讨论。这是一项基于已记录运行的探索性研究，而非与标准分布式训练框架的对比。

E1第6次运行在瑞典的16块NVIDIA A40上训练ViT-B/16，协调器位于德国，或位于GPU所在的数据中心。10月17日的试运行在1块和2块A40上跑通了ViT-H/14。10月29日的后续检查在亚特兰大使用共享同一块物理MI300X的两个软件主机；这不是双GPU扩展性测试。

两个模型都使用Oxford-IIIT Pet数据。ViT-B/16约有8600万参数；ViT-H/14约有6.32亿参数，模型文件为2.5 GB。双A40的ViT-H探测采用fp32全量微调，batch为32，q4增量，每主机每轮20个本地步。

我们检查了训练、增量准备、聚合和同步前后的主机与协调器事件。在ViT-H试运行中，还每两秒对协调器内存采样一次。事件区间包含其命名边界之间的工作；它们不是纯网络延迟测量。各主机并行运行，因此其各组件区间不能简单相加为新的整轮统计量。

在经由德国的16×A40运行中，两个主机开始上传的时间远晚于其他主机。会话记录中的主机日志观察将延迟定位在上传之前：在第4轮，这些主机上的编码耗时17.8秒和18.0秒，而其他主机为1.5–2.3秒。上传本身约耗时1秒。

ViT-B/16，第6次运行，第4轮：两个主机的编码耗时分别为17.8秒和18.0秒，其他主机为1.5–2.3秒。上传约耗时1秒。来源：第6次运行会话记录。

两个慢主机共享同一台物理机。它们的软件能看到比pod配额更多的CPU线程，而编码使用CPU工作。超售是一个合理的解释，但无法在租用的pod上直接验证。编码延迟是观察到的；底层调度原因仍属假设。更多网络带宽不会直接消除这一本地准备时间。

在16块A40下，协调器位于GPU旁时，从同步开始到最后一块主机完成同步约耗时3秒；在第2和第3轮经由德国时约耗时13秒。该区间包括更新的接收和应用。迁移协调器改善了该阶段；它并未把先前的CPU编码延迟变成网络距离效应。

ViT-H/14在2块A40上端到端跑通，包括最终评估。这次短运行检查的是执行路径，而非目标准确率或扩展性。在前两轮中，约48秒的训练伴随约60秒的交换工作。

主机更新准备与交付耗时17.8–22.3秒，其中上传约0.7秒。聚合耗时2.9–3.4秒。从记录的聚合事件到同步开始约为22.6–23.4秒。主机同步应用耗时9.8–14.5秒，尽管下载仅约0.5–0.7秒。

ViT-H/14在2块A40上，前两轮。组件区间不能相加为整轮测量。回退保存本身耗时约14–15秒。

保存完整回退模型占用了聚合到同步区间中的约14–15秒：序列化加上上传到存储。它每轮都被保存，尽管主机只有在无法应用更新时才需要它。哈希和同步增量准备增加了其他工作。把整个区间称为“模型保存”会高估保存操作的成本。

协调器在试运行中的峰值内存还达到34.4 GiB，并在完成后仍保留大量内存。这是端到端功能运行不能作为可扩展就绪证明的另一个原因。

第一项改动使完整轮次模型按需可用，而不是每轮无条件保存。在10月29日的会话中，记录报告聚合到同步区间低于检查的10秒标准，轮次模型处于按需模式，没有回退保存，且增量应用成功。

那是在不同配置上的本地验收检查：一块MI300X上的两个软件主机，其CPU和存储资源与A40试运行不同。我们不会把它转化为完整训练时间的百分比改进。

该会话还调查了协调器保留内存。其代码调查在聚合执行命名空间中发现了一个引用环，它使全模型对象一直存活到循环垃圾回收。清除该命名空间后，后续检查中报告的峰值更低，轮次间内存更平稳。

这些是报告的工程观察，不是重复的独立试验。

观察到编码延迟。CPU超售未确认。

阶段计时改善；其他延迟仍然存在。

每轮保存完整模型约14–15秒。

10月29日记录报告同步<10秒。不同硬件。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）