Lins: Reducing Communication Overhead of ZeRO for Efficient LLM Training

Lins 改了 ZeRO 的哪项约束

参数、梯度和优化器状态不再共用同一个 ZeRO 分片组。Lins 分别为三类状态选择全复制、全分片或部分分片，以及对应的机内或跨机 device mesh，再在显存约束下搜索通信时间最低的组合。

要解决的问题：ZeRO 省下显存后，通信为什么反而成为主角

混合精度 Adam 训练中，每个参数大致对应 2 字节参数、2 字节梯度和 12 字节优化器状态，LLaMA-7B 的模型状态合计约 112 GB，单张 80 GB A100/A800 放不下。ZeRO-1/2/3 逐步切分优化器状态、梯度和参数，但分得越彻底，越依赖 AllGather、ReduceScatter 和 AllReduce。

问题在大规模时被放大：机内 NVLink 与跨机网络带宽不同，collective 参与者越多延迟越高，固定 global batch 下每 GPU micro-batch 越来越小。论文测得 ZeRO-1 训练 LLaMA-7B 从 8 GPU 扩到 1024 GPU 时，MFU 从 63% 降到 36%；ZeRO-3 训练 LLaMA-13B 则从 47% 降到 4%（PDF 第 3 页，§III-A）。

MiCS 和 ZeRO++ 用更多副本换更小通信组，但它们仍要求 s_p = s_g = s_os。Lins 的判断是，参数 P、梯度 G、优化器状态 OS 的大小、访问时机和 collective 并不相同，不该绑定成同一个分片因子。

核心设计与数据流

Lins 的离线规划和在线执行是一条清晰链路：

1. 用户输入模型结构与训练超参数，包括层数、序列长度、micro-batch 大小和数量，以及 GPU 数量、节点数和显存容量。
2. Communication Profiler 在目标集群上测量 AllGather、ReduceScatter、AllReduce、Broadcast 在不同消息大小和 机内 GPU 数 × 节点数 mesh 下的有效带宽；未测点用插值估算。
3. Pre-Filter 用依赖规则去掉明显产生冗余存储或跨机通信的方案。
4. Solver 在显存约束下最小化 T_p + T_g + T_os^0 + T_os^1，得到 P/G/OS 各自的机内和跨机分片因子。
5. Executor 通过 PyTorch hook 执行选定计划。参数按 module 粒度 AllGather，反向后 ReduceScatter；梯度按 bucket AllReduce 后 select-and-drop；持有不同 optimizer shard 的 GPU 更新各自参数，再 Broadcast 给同参数副本组。
6. 这些 collective 尽量与相邻 module 的前反向计算重叠，并优先把通信限制在节点内。

这里 s_i = s_i^0 × s_i^1，s_i^0 是节点内参与 GPU 数，s_i^1 是参与节点数。Lins 强制 s_p ≤ s_g ≤ s_os ≤ s_dp，分别在机内和跨机维度成立，避免某张卡维护与本地参数无关的梯度或优化器状态（PDF 第 5 页，§IV-B）。

关键机制：把 ZeRO stage 展开成状态级搜索

1. P/G/OS 独立分片空间

分片因子为 1 是 Full-Replica，等于 data parallel size 是 Full-Sharding，中间值是 Partial-Sharding。三个状态可独立选择。例如 LLaMA-7B 的实验计划是 P 全复制、G 全复制、OS 在节点内 8 卡分片；LLaMA-13B 是 P/G 在机内 4 卡分片、OS 在机内 8 卡分片；LLaMA-30B 则让 P/G 在机内 8 卡分片，OS 跨 4 个节点继续分片（PDF 第 7 页，表 III）。

2. 面向真实 collective 的 profile-based cost model

论文没有只用 ring collective 的 α-β 理论式，因为 NCCL 还会选 Tree、CollNet 等算法，集群也可能有 in-network aggregation。Lins 用实测有效带宽 w(op, volume, mesh) 估算 t=volume/w，同时区分消息量和机内/跨机 mesh（PDF 第 4-5 页，§IV-A）。这使搜索结果能反映目标集群，而代价是换集群需要重新 profile。

3. 显存约束下的整数搜索与拓扑过滤

目标函数是最小化单 step 通信时间，约束总显存不超过 GPU 容量。模型状态显存写成 2Φ/s_p + 2Φ/s_g + 12Φ/s_os，再加 activation 和临时 buffer。搜索要求分片因子整除 DP mesh，并规定一旦需要跨节点分片，先用满节点内 GPU，避免 (1 GPU × 2 nodes) 这类可改为 (2 GPUs × 1 node) 的高成本布局（PDF 第 6-7 页，式 1-7、图 7）。

4. 与计算重叠的状态流转

module i 计算时可预取下一 module 参数；反向计算当前层时可归约后一层梯度；上一步更新后的参数 Broadcast 可与下一步 forward 重叠（PDF 第 5-6 页，图 5）。不过端到端对比中作者为公平关闭了 Broadcast-forward overlap，因为 baseline 没有这一能力（PDF 第 8 页，实验设置）。因此主结果主要验证分片计划，不包含这项额外重叠的全部潜力。

实验设置与准确数字

• 实现：PyTorch 2.1 hook、FlashAttention-v2、BF16。
• 模型：LLaMA-7B、13B、30B。
• 集群：128 台服务器，每台 8 张 80 GB A800，共 1024 GPU；机内 NVLink，跨机 4 张 Mellanox HDR InfiniBand NIC，不启用 SHARP（PDF 第 8 页）。
• baseline：DeepSpeed ZeRO-1、ZeRO-3、ZeRO++、MiCS。ZeRO++ 关闭量化以保持模型质量一致。
• 所有实验 sequence length 为 4096，micro-batch 为 1 条 4096-token 序列，global batch 固定 4M tokens；8 GPU 时有 128 个 micro-batch，1024 GPU 时每 step 只剩 1 个。实验只保留 data parallelism，不使用 tensor parallelism 或 pipeline parallelism（PDF 第 8 页）。

准确结果与论文中的数字冲突

1. 1024 GPU 的主结果。 LLaMA-7B/13B/30B 上，Lins 的 MFU 分别是 51%/52%/42%（PDF 第 8 页，图 8 及正文；第 2 页也重复这组三个数）。同页图 9 报告对应 TGS，但柱形没有打印精确标签；正文也没有逐项列值，因此这里只引用 MFU，不估读 TGS。
2. 相对 baseline。 论文第 2 页明确列出 MiCS 在三种模型上为 35%/33%/29%，ZeRO++ 为 4%/6%/5%；Lins 对 MiCS 和 ZeRO++ 的吞吐提升范围是 1.4-12.7×（PDF 第 2 页；总结也见第 9 页）。
3. LLaMA-7B 的通信选择很有解释力。 1024 GPU 时 Lins 为 51%，ZeRO-1 为 36%，MiCS 为 35%，ZeRO-3 和 ZeRO++ 约 4%。Lins 只在 8 GPU 内 Broadcast 更新参数，避免全局 Broadcast；MiCS 虽把 AllGather/ReduceScatter 限在节点内，但总流量更大（PDF 第 9 页，图 8 后分析）。
4. 扩展退化较慢。 从 8 GPU 到 1024 GPU，Lins 的 MFU 降幅约 15%，ZeRO-3 最高可降 88%（PDF 第 9 页，图 8 后分析）。这里是相对降幅，不是 15 个百分点。
5. 显存不是最省。 ZeRO-3 最节省模型状态显存；1024 GPU 时 MiCS 约用 ZeRO-3 两倍显存换通信性能。Lins 在可用显存内选择更高复制度，因此目标是最小通信而非最小显存（PDF 第 9 页，图 10）。

论文内部有一处应保留的冲突：第 8 页主结果写 LLaMA-13B/30B 为 52%/42%，第 9 页后续段落却写成 51%/43%。图 8 的柱形更接近 52%/42%，第 2 页也支持 52%/42%，所以本页解释采用主结果 51%/52%/42%，同时不隐藏后文异文。

方法贡献

Lins 把 ZeRO stage 从离散的“1/2/3 级”改写成一个模型状态级别的布局优化问题。参数、梯度、优化器状态有不同容量和生命周期，独立 mesh 让系统能用显存冗余换取恰好需要的通信缩减，而不是统一复制或统一分片。

另一个实用创新是把通信算法和网络拓扑的不确定性留给 profiler，而不是假设理论带宽。这样搜索问题仍然简单，集群特性却能进入决策。

局限/适用边界

• 评估刻意不使用 tensor/pipeline parallelism，尚未证明独立状态分片与完整 3D parallelism 联合搜索时仍能得到同样收益。
• 固定 4M-token global batch 使 1024 GPU 时每 step 仅 1 个 micro-batch，通信/计算比非常不利。它能突出问题，但不代表所有生产训练的 batch 与扩展策略。
• 只测 7B-30B LLaMA 架构、4096 长度和 A800 集群；更大模型、MoE、长上下文或异构网络需要重新 profile 并验证内存模型。
• profiler 依赖目标集群的 NCCL 和网络状态。拓扑变化、拥塞或 SHARP 等 in-network aggregation 会让旧 profile 失准。
• ZeRO++ 为保持质量关闭量化，Lins 又为公平关闭 Broadcast-forward overlap。比较回答的是“独立分片策略”而不是各系统开启全部功能后的绝对最优值。
• 主实验没有给训练 loss/下游精度，因为各方案在同一 BF16 计算路径下主要改变状态布局；这支持语义等价预期，但不能替代长时间训练收敛验证。

与其他绿色论文的技术关系

• 与 UniTG 互补：Lins 优化 LM 阶段的模型状态，UniTG 摘要描述 LM-GNN 联合流水线。能否把 Lins 作为 UniTG 的 LM runtime 仍是组合设想，不是论文证据。
• 与 TorchGT 都做 device mesh 和通信优化，但数据依赖不同。TorchGT 沿 sequence/head 做 all-to-all，Lins 沿 P/G/OS 副本组做 AllGather、ReduceScatter、AllReduce 和 Broadcast。
• 与 SYLVIE 都以“多占一点显存/副本换更少通信”为核心权衡。SYLVIE 压缩边界 embedding，Lins 不近似数据而是改变精确模型状态的放置，因此 Lins 不引入量化误差。
• 与绿色论文 Di-PS、SPPO 同属训练并行层；与 Ymir/Titan/ICEFROG 等调度器不同，Lins 决定单个作业内模型状态放在哪些 GPU，调度器决定多个作业怎样获得 GPU。

前置背景与 ZeRO 通信推导

混合精度 Adam 训练中，每个参数通常对应二字节 BF16 参数、二字节梯度，以及 FP32 master weight、动量和方差等合计十二字节优化器状态，总模型状态约十六字节乘参数量。七十亿参数约一百一十二吉字节，单张八十吉字节 A800 放不下，还未计算 activation。传统 data parallel 在每卡复制全部状态，只对梯度做 AllReduce；ZeRO-1 分片优化器状态，ZeRO-2 再分梯度，ZeRO-3 连参数也分，从而逐级省显存，但每层计算前后必须用更多 AllGather、ReduceScatter 或参数广播恢复所需状态。

扩展到更多 GPU 后，固定 global batch 被切成更少的每卡 micro-batch，计算量下降，collective 却不能同比消失；跨节点带宽又远低于机内 NVLink。论文测得 ZeRO-1 训练 LLaMA-7B 从八卡扩到一千零二十四卡时，模型浮点利用率从百分之六十三降到三十六；ZeRO-3 训练十三亿模型从百分之四十七降到四。MiCS 和 ZeRO++ 通过复制状态缩小通信组，但仍让参数 P、梯度 G、优化器状态 OS 共用同一分片因子。Lins 的出发点是三种状态大小、访问时机和 collective 类型不同，不应被一个 ZeRO stage 绑定。

设数据并行规模为 s_dp，状态 i 的总分片因子为 s_i=s_i^0×s_i^1，上标零表示每节点内参与 GPU 数，上标一表示参与节点数。分片因子一代表每卡完整复制，等于数据并行规模代表全分片，中间值代表部分分片。系统约束 s_p≤s_g≤s_os≤s_dp，并在机内、跨机两个维度分别保持：若本卡不持有某份参数，就不应为它保留更大范围的梯度或优化器状态。模型状态显存近似为 2Φ/s_p+2Φ/s_g+12Φ/s_os，Φ 是参数个数，还要加 activation、通信与临时 buffer。

完整规划算法与代价模型

离线输入包括层数、参数量、序列长度、micro-batch 数与大小、GPU/节点数、每卡显存和拓扑。Communication Profiler 在目标集群测量 AllGather、ReduceScatter、AllReduce、Broadcast 针对不同消息体积与“机内 GPU 数×节点数”mesh 的有效带宽，未测点插值。论文不用单一 alpha-beta ring 公式，因为 NCCL 会选择 Ring、Tree、CollNet，网络还可能支持聚合。对 collective op、体积 v、mesh m，时间估计为 t(op,v,m)=v/w(op,v,m)；w 是实测有效带宽，已吸收协议与拓扑差异。

Pre-Filter 先删除明显劣势方案：分片因子必须整除数据并行 mesh；需要跨节点时先用满节点内 GPU，避免一张卡乘两个节点这种可改为两张卡乘一个节点的慢布局；还用 P、G、OS 依赖序去掉持有无关状态的组合。Solver 在剩余整数布局中满足显存约束，最小化单 step 的参数通信、梯度通信与优化器更新通信之和，写作 T_p+T_g+T_os^0+T_os^1。目标不是最少显存，而是用未占满的显存复制恰当状态，换取更小或完全节点内的 collective。

例如八卡节点、总一千零二十四 GPU。七十亿模型的最佳计划让 P、G 全复制，OS 只在节点内八卡分片；前向无需全局参数 AllGather，更新后只在八卡内 Broadcast。十三亿模型的 P/G 在机内四卡分片，OS 在八卡分片；三十亿模型更大，P/G 在机内八卡分片，OS 还要跨四节点分片。这个例子来自论文 Table III，说明模型越大，显存约束迫使状态逐步跨节点；但各状态仍不必同因子。若统一取最大分片，通信过多；统一取最小分片，显存放不下。

在线执行数据流与手算

Executor 通过 PyTorch hook 按 module 粒度运行。前向某 module 前，对参数 shard 做 AllGather；计算当前 module 时可预取下一 module 参数。反向时，当前层计算可与后一层梯度 ReduceScatter 重叠。梯度按照 bucket 先在相应副本组 AllReduce，再 select-and-drop，只保留本地负责的 shard。持有 optimizer shard 的 GPU 执行 Adam 更新，随后用 Broadcast 把新参数发送给同一参数副本组；更新后 Broadcast 还可与下一 step forward 重叠。主端到端比较为公平关闭了这项 Broadcast-forward overlap，因此报告主要反映布局搜索，不含全部潜在重叠收益。

以 Φ=七十亿做显存手算：若 P/G 全复制、OS 八卡分片，模型状态约为二Φ加二Φ加十二Φ/8，即五点五Φ 字节，约三十八点五吉字节；再为 activation 和 buffer 留空间，可装入八十吉字节卡。若全部复制则十六Φ，约一百一十二吉字节，无法运行；若全部在一千零二十四卡分片，显存极小，却每层在巨大全局组 AllGather 参数。Lins 选择前者，因为它刚好用显存余量避免最昂贵的跨机参数恢复。算例忽略框架碎片和 activation，真实判定使用完整内存模型。

通信量也按状态分别计算。参数在计算前需要让使用该 module 的副本得到完整片段，梯度在反向后需要合并相同参数贡献，优化器更新后需要让参数副本同步。P、G、OS 的最佳 mesh 由消息大小和时机共同决定：十二字节 OS 最大但只在负责更新的卡上持有，二字节参数访问频繁，二字节梯度适合 bucket 化重叠。统一 mesh 无法表达“参数复制、梯度复制、OS 节点内分片”这种有效组合。

实验逐表与扩展结论

实现使用 PyTorch 2.1 hook、FlashAttention-v2 与 BF16。集群有一百二十八台服务器，每台八张八十吉字节 A800，共一千零二十四卡；机内 NVLink，跨机四张 Mellanox HDR InfiniBand 网卡，不启用 SHARP。模型为 LLaMA-7B、13B、30B，序列长度四千零九十六，每 micro-batch 一条序列，global batch 固定四百万 token。八卡时每 step 一百二十八个 micro-batch，一千零二十四卡时每卡只剩一个，因此通信计算比非常不利。只用 data parallel，不含 tensor 或 pipeline parallel。

一千零二十四 GPU 时，Lins 在 7B、13B、30B 上 MFU 为百分之五十一、五十二、四十二；MiCS 为三十五、三十三、二十九，ZeRO++ 为四、六、五，吞吐相对 MiCS/ZeRO++ 提升一点四到十二点七倍。7B 的细项为 Lins 五十一、ZeRO-1 三十六、MiCS 三十五、ZeRO-3 与 ZeRO++ 约四。Lins 只在八卡内 Broadcast 更新参数；MiCS 虽把 AllGather/ReduceScatter 限在节点内，却因统一分片产生更大总流量。

从八到一千零二十四卡，Lins MFU 相对降幅约百分之十五，ZeRO-3 最高百分之八十八；这里是相对下降，不是十五个百分点。显存图显示 ZeRO-3 最省模型状态，一千零二十四卡时 MiCS 约用其两倍显存。Lins 更接近“在容量内主动花显存换通信”，不能同时宣称显存最省。论文正文还有一处数字异文：主结果与前文为 51/52/42，后段写成 51/51/43；图柱与多处文字支持前者，解释页应保留冲突而非偷偷统一。

局限、失败模式与复现

复现先在目标集群枚举消息大小、四类 collective 和所有候选 mesh，记录有效带宽、方差、NCCL 算法与拓扑；网络或 NCCL 版本变化后必须重测。然后实现整数枚举与 pre-filter，对小规模所有方案暴力搜索，确认过滤未删全局最优；逐方案核对 s_p≤s_g≤s_os、整除、节点内优先和显存公式。Executor 需用 checksum 验证 AllGather 后参数、ReduceScatter/AllReduce 后梯度、Broadcast 后副本完全一致，再做多 step loss 对照。

实验至少报告三模型在八到一千零二十四卡的 MFU、tokens/GPU/s、每种 collective 时间、overlap 比例、峰值显存与 solver 计划。global batch、序列长度、micro-batch、FlashAttention、BF16 必须相同；ZeRO++ 按论文关闭量化，Lins 为公平关闭 Broadcast-forward overlap。主文没有长期 loss/下游精度，复现应补相同初始化的收敛曲线，验证状态布局不改变语义。

边界很明确：论文未联合 tensor/pipeline parallel，不能把收益直接外推到完整三维并行；固定四百万 token batch 使大规模每卡计算极少，突出通信但未必代表生产配置；只测七十亿到三百亿 dense LLaMA、四千长度和 A800，MoE、超长上下文与异构网络要重新建模。Profiler 也是静态快照，作业共用网络、SHARP 或拥塞变化会使 w 失准。在线系统应周期抽测带宽，预测与实测偏差过大时回退保守 ZeRO 布局。

最终验收应证明四条链路：独立 P/G/OS 因子满足内存，profile cost 能预测真实 collective，计划相对统一分片减少跨机通信，执行结果与标准 ZeRO 数值一致。若只看到 MFU 提升，可能来自不同 batch 或 overlap；若显存下降却通信没降，solver 可能退化成 ZeRO-3；若 profile 准确但端到端慢，需检查 hook 粒度、bucket、预取和 stream 同步。Lins 的贡献是把 ZeRO stage 变成可测量、可搜索的状态布局问题。

三种状态的 collective 生命周期不同。参数 P 在每个 module 前必须可读，分片时用 AllGather 拼出当前层，用完可释放非本地 shard；梯度 G 在反向产生，需要对数据副本贡献求和，Lins 可先按 bucket AllReduce，再只保留负责 shard；OS 只在 step 边界由 owner 读取并更新，更新后的参数通过 Broadcast 到持有副本的组。AllGather 的输出量、ReduceScatter 的输入输出量、AllReduce 的全量流量、Broadcast 的根节点拓扑不同，不能仅用“分片因子越大通信越多”一条规则近似。

机内与跨机维度的分解让拓扑进入搜索。例如总分片十六可以是八张机内卡乘两个节点，也可以是四卡乘四节点。两者存储量相同，但前者把更多阶段留在 NVLink，跨机参与节点少；pre-filter 因而要求跨节点前先填满节点内设备。若目标机器每节点不是八卡，或存在双轨网络、分层 NVSwitch，合法因子与带宽表都要改变。计划文件应保存每个状态的二维 mesh，而不是只保存总数十六。

Profiler 需要覆盖实际 message volume。小层参数可能落在延迟主导区，大层落在带宽主导区，简单用峰值网卡带宽会低估小消息。NCCL 还可能随参与者和体积从 Tree 切到 Ring；未测点插值只能在相邻稳定区间使用。建议逐层把预测 collective 时间与运行 trace 比较，分别报告中位和尾部。若共享集群出现拥塞，静态表的平均带宽可能过乐观，solver 会选择跨机分片而实际更慢。

内存约束也不止模型状态。Activation 随 micro-batch、序列长度、checkpoint policy 和层数变化，参数 AllGather 需要临时完整 layer buffer，bucketed gradient 与预取下一层可能同时存在。若 solver 只代入 2Φ/s_p+2Φ/s_g+12Φ/s_os，可能选出纸面可行却运行时溢出的方案。论文输入包含训练超参数并计入 activation 与临时 buffer；复现应留 allocator 碎片安全余量，并用峰值实测反馈修正。

七十亿布局的关键是复制 P/G 并只分 OS，它与 ZeRO-1 相似但 mesh 更精细；十三亿开始对 P/G 做四卡节点内 partial sharding；三十亿把 OS 扩到四节点。三行计划揭示 Lins 的决策规律：优先让最频繁读取的参数留在更小高速组，把最大的十二字节优化器状态分得更广来满足容量。统一 s_p=s_g=s_os 会迫使参数跟着 OS 跨机，正是 MiCS/ZeRO++ 仍有剩余开销的来源。

MFU 是实际吞吐相对硬件理论峰值的比例，受 kernel、通信、bubble 和数据准备共同影响。Lins 在一千零二十四卡的百分之五十一、五十二、四十二不等于通信完全消失；模型越大、可复制空间越少，三十亿仍只有四十二。TGS 图柱没有打印精确标签，正文也未列逐项数值，所以不应从图片估读 token/GPU/s 后作为准确表格。可复现报告应直接由全局 token、step time 和 GPU 数计算 TGS，并注明 warmup 排除规则。

与 baseline 的公平设置也决定结论。ZeRO++ 量化可减少通信却可能改变训练质量，论文关闭量化以保持同一数值路径；Lins 的 Broadcast-forward overlap 本可再提速，却也关闭，因为 baseline 没有对应能力。MiCS 用更多状态副本换节点内通信，显存约为 ZeRO-3 两倍；Lins 在容量约束内做更细复制。比较回答的是独立状态分片计划的价值，不是各系统所有可选优化全开的产品排名。

扩展实验固定四百万 token global batch，从八卡的一百二十八 micro-batch 变成一千零二十四卡每卡一个。强扩展中每卡计算随规模急降，通信占比自然放大，Lins 的百分之十五相对 MFU 降幅因而有意义，但不能外推到随 GPU 增加 global batch 的弱扩展。复现应同时给 strong-scaling 和可选 weak-scaling；若后者保持每卡 micro-batch，方案差距可能缩小，却更接近某些生产训练。

运行时容错和动态性也是未覆盖边界。节点故障改变数据并行 mesh，旧 P/G/OS shard 组不再合法；弹性扩缩同样需要重分片状态并重新搜索。论文针对固定作业与固定集群离线规划，没有量化重配置成本。生产系统应缓存常见规模计划、保存状态到稳定 checkpoint，在拓扑变化时先回退标准 ZeRO，再异步 profile 与求解，避免使用失配 mesh 造成死锁。

搜索空间可用一个小例子验收。两节点、每节点四卡时，合法总分片因子来自一、二、四、八；二维 mesh 可是一乘一、二乘一、四乘一、四乘二。为 P、G、OS 各选一个本可有大量笛卡尔积，依赖序与节点内优先会删去 P 比 G 更分散、G 比 OS 更分散以及一乘二这类劣布局。对剩余项逐一计算状态内存和四类 collective，最小者应与暴力枚举一致。这个单元测试能发现 pre-filter 方向写反。

Select-and-drop 的正确性也需解释。梯度 bucket 在副本组完成归约后，每卡只保留自己 optimizer shard 对应部分，其他部分丢弃；若 G 的复制范围小于 OS，某 owner 可能拿不到更新所需梯度，所以必须有 s_g≤s_os。参数更新后，P 的复制范围又要求 owner 将新值广播到所有持有副本；若 s_p≤s_g，每个参数副本都能从覆盖它的梯度组获得一致结果。约束不仅为过滤性能方案，也保护状态依赖。

通信重叠要用独立 CUDA stream 和事件保证生命周期。预取下一 module 参数过早会与当前 activation、bucket 同时占显存，过晚则不能隐藏 AllGather；反向归约必须等梯度产生，又要在 optimizer step 前完成；Broadcast 与下一 forward 重叠时，读取该参数的 module 必须等待更新事件。主实验关闭最后一种重叠，但代码路径仍应做数值测试，不能用异步竞态换取表面速度。

模型浮点利用率计算需统一理论峰值、有效训练 FLOPs 与 step time。FlashAttention、checkpoint 和 BF16 会改变实际操作，但各 baseline 应用同一公式。建议同时报告硬件计数器、通信 timeline 与 bubble；当 ZeRO++ 只有百分之四到六时，要确认不是异常 NCCL 配置或 OOM fallback。论文在同一千卡集群对比提供相对证据，复现跨集群时先验证 baseline 达到合理水平。

最终计划还可由“通信字节从哪里消失”审计。P 全复制意味着不再每层跨全局 AllGather，却增加常驻显存；OS 八卡分片意味着更新只在节点内汇合；三十亿 OS 跨四节点则保留必要跨机流量。对每个模型画 P/G/OS 三条 timeline，并将预测 T_p、T_g、T_os^0、T_os^1 与实测叠加。只有减少项与布局选择一致，才能确信 solver 不是碰巧选到快配置。

Checkpoint 格式也应与布局解耦。运行时 P/G/OS 可分布在不同 mesh，但保存时需要聚合为可由其他 GPU 数恢复的标准状态，加载后再按新计划 scatter。若 checkpoint 直接序列化本地 shard 而不记录二维 mesh、参数 owner 和版本，换规模恢复会错位。论文没有量化 checkpoint 开销，长训练部署应把周期保存对网络和 MFU 的影响单独报告。

从资源经济性看，Lins 选择更高复制会减少可在同一集群并发的其他作业数量。单作业 MFU 提高不等于集群总吞吐一定最大；论文评测专注一个大规模训练作业。多租户 scheduler 若给作业严格显存配额，solver 应把配额而非物理卡容量作为约束，并比较复制带来的 step 加速是否值得少放一个作业。这是 Lins 作业内布局与集群调度器之间的明确边界。

调优完成后应生成可读计划摘要：每种状态的机内/跨机因子、每卡字节、主要 collective、预测时间和显存余量。Operator 可据此判断为何七十亿复制参数、三十亿跨四节点分优化器。若输出只有 solver 的整数变量，出现性能退化时无法区分 profile 漂移、错误 mesh 和内存估计偏差。计划摘要还应绑定模型哈希、GPU 拓扑、NCCL 版本和训练超参数，任一变化就重新验证。

完整结果不能把百分之五十二与后文百分之五十一的异文隐藏。以图八和多处正文支持的 51/52/42 为主，同时在报告注明冲突；TGS 没有精确标签就不估读。对系统论文保留证据不确定性，比给出看似精确却来自像素的数字更重要。

复现产物还应包含 solver 输入、带宽表、最终 mesh 和通信 trace，使每个性能结论都能从原始配置追溯，而不是只留下汇总柱状图。

同时保留显存峰值与数值一致性日志，验证速度没有以溢出风险或训练偏差为代价。