MegaScale：超过 10,000 GPU 的生产级 LLM 训练系统

1. 摘要与一句话判断

3 分钟速读

1. 问题：万卡 LLM 训练有两大挑战——效率（模型切分后 GPU 间重度通信，MFU 直接决定训练速度）与稳定性（作业长达数周，失败与掉队是常态而非例外，且很多稳定性问题只在大规模出现）P（第 1 页 §1）。
2. 方案：全栈协同设计：算法层（并行 transformer block、滑窗注意力、LAMB 批量 4×）+ 3D 并行通信-计算重叠（DP/PP/TP-SP）+ 高效算子（FlashAttention-2、融合 LayerNorm/GeLU）+ 数据管道（共享内存树状加载）+ 通信组初始化加速 + 定制网络（Tomahawk 4、multi-rail、Swift+DCQCN）+ 稳健训练框架与深度可观测 P（第 3-9 页 §3-§5）。
3. 论文声称的主要结果：175B 模型、12,288 GPU：55.2% MFU、1.34× 于 Megatron-LM（迭代 6.34s、1,984k tokens/s、300B tokens 训练时间 1.75 天）；消融显示各项叠加共 +17.6% MFU（256 GPU 口径）；生产运行数周重启逾 100 次、>90% 故障自动修复、有效训练时间率 >90% P（第 1、10-12 页；条件见 #experiments）。
4. 云上含义：I 吞吐来自「通信躲进计算」（TP/SP 融合、PP 解耦收发、DP 预取+优先级），可用性来自「心跳 → 诊断 → 驱逐补位 → 断点恢复」的自动化闭环；前者决定 GPU 租用成本，后者决定万卡集群的有效训练时间占比。
5. 主要限制：系统本体与数据集未开源、专有模型细节未披露；GPU 仅称「NVIDIA Ampere」未给型号，部分结论（网络、容错）依赖自控集群前提；MFU 依赖峰值 FLOPs 假设口径；仓库侧仅论文脚注指向的 veScale 组件库 P（第 2、9 页）+ R（2026-09-15 核验）+ I。

2. 问题背景

效率挑战：LLM 训练不是易并行的——模型切分到多卡后 GPU 间重度通信，通信之外的算子优化、数据预处理与显存占用同样显著影响 MFU（观测吞吐 ÷ 100% 峰值 FLOPs 假设下的理论吞吐）P（第 1 页 §1）。I 对架构师而言，MFU 是万卡集群「每元算力产出」的第一决定项，1 个百分点的 MFU 差异在数周作业里就是数万美元级。

稳定性挑战：LLM 训练周期以周计，失败与掉队是常态；失败恢复代价高、掉队拖慢整个作业；许多硬稳定性问题只在大规模出现，必须靠「深度可观测性」而非人工逐例排查 P（第 1-2 页 §1）。

并行策略底座（论文 §2 的背景知识）：P（第 2-3 页 §2）

1. 数据并行 + ZeRO：复制模型、均分数据；ZeRO 把优化器状态/梯度分片（第 2 阶段常用：分片两者且无额外通信开销），把 all-reduce 分解为 reduce-scatter + all-gather（图 1）。
2. 流水线并行：按层切 stage、批切微批流水执行；Megatron-LM 的交错 1F1B 把每个 stage 细分为多个虚拟 stage（model chunk），warm-up → steady（1F1B）→ cool-down（图 2）。
3. 张量/序列并行：TP 拆分计算密集算子（GEMM 需通信），LayerNorm/Dropout 等沿序列维 SP 分片省激活内存。
4. 3D 组合规则：TP 通信最好限制在单节点内；DP 与 PP 更适合跨节点；优先把 DP 组建在 PP 之上，缓解跨 minipod 的 DP 通信。

相关工作站位：既有 LLM 技术报告（GPT-3/GPT-4/GShard/PaLM 与 OPT/BLOOM/Llama/Llama-2 等）多聚焦模型性能对比、略去系统基础设施细节，本文从系统视角补足超过 10,000 GPU 端到端预训练经验 P（第 12 页 §7）。

3. 核心机制

3.1 算法层优化（不损收敛前提下换效率）

• 并行 transformer block（PTB）：把标准串行块 y = x + MLP(LN(x + Attention(LN(x)))) 改写为并行形式，attention 与 MLP 两支并行执行以缩短计算时间；引前人工作称对千亿参数模型质量无退化 P（第 3 页 §3.1 式 1-2）。
• 滑窗注意力（SWA）：固定窗口稀疏注意力，复杂度 O(s×w) 优于全注意力 O(s×s)（w ≪ s）；前人工作与本文微基准表明堆叠窗口层可保留全域信息 P（第 3-4 页 §3.1）。
• LAMB 优化器：把批量扩至 4× 而无损精度（LLM 实验口径）；交错流水线下，4 步 1× 批量的气泡为 (4/v)·(p−1)/m、1 步 4× 批量为 (1/v)·(p−1)/(4m)，论文据此称流水线气泡减少 87.5% P（第 4 页 §3.1；分数式经 300dpi 放大核对）。

3.2 3D 并行的通信-计算重叠

3.3 高效算子、数据管道与初始化

• 算子：attention 用 FlashAttention-2（改进 thread block/warp 工作划分）；LayerNorm/GeLU 由细粒度 kernel 融合为单 kernel，减少启动开销、优化内存访问 P（第 5 页 §3.3）。
• 数据管道：预处理不在关键路径、与步末梯度同步重叠；同机 GPU worker 属同一 TP 组、每步输入相同 → 两层树状加载：每机单一专用 dataloader 读入共享内存，各 worker 拷贝到显存，消除冗余磁盘读 P（第 5 页 §3.4）。
• 通信组初始化：Megatron-LM 在 2,048 NVIDIA Ampere GPU 初始化约 1047 秒，阻碍例行测试与快恢复；TCPStore（单线程阻塞读写）→ Redis（非阻塞异步）降至 361 秒；再以通信组初始化顺序设计消除全局 barrier（O(n²)→O(n)），2,048 GPU 降到 5 秒内、>10,000 GPU 降到 30 秒内 P（第 5-6 页 §3.5）。

3.4 网络性能调优

• 拓扑：交换机基于 Broadcom Tomahawk 4（单芯片 25.6 Tbps、64×400Gbps 端口）；三层 CLOS 连接 >10,000 GPU；每层下行:上行＝1:1（32+32 口），小直径高带宽 P（第 6 页 §3.6）。
• ECMP 冲突抑制：ToR 级把一个 400G 下行以特定 AOC 线缆分裂为两个 200G 下行（上行带宽双倍于下行、降低冲突概率）；服务器 8×200G NIC 以 multi-rail 接 8 台不同交换机；同组 ToR 最多连接 64 台 GPU 服务器，并把数据密集节点调度到同一 ToR 下、减少交换跳数 P（第 6 页 §3.6）。
• 拥塞控制：all-to-all 在默认 DCQCN 下引发 PFC 与队头阻塞；自研算法融合 Swift（RTT 精确测量）与 DCQCN（ECN 快速响应），显著提升吞吐、降低 PFC 拥塞 P（第 6 页 §3.6）。
• 重传超时：调 NCCL 重传计时/重试参数，并启用 NIC adap_retrans 缩短重传间隔，加快链路闪断恢复 P（第 6 页 §3.6）。

4. GPU/系统数据路径

端到端文字序列（①–⑨；与图中编号一致）

1. ① 数据管道（卸出关键路径）：预处理异步执行、与步末梯度同步重叠；每机单一专用 dataloader 读入共享内存，各 GPU worker 拷贝所需数据到显存（两层树状、消除冗余磁盘读）P（第 5 页 §3.4）。
2. ② 启动期（一次性）：建立 NCCL 通信组——TCPStore 换 Redis（2,048 GPU 初始化 1047s→361s），再以组初始化顺序设计消除全局 barrier（O(n²)→O(n)），2,048 GPU <5s、>10,000 GPU <30s，为例行测试与快恢复扫清障碍 P（第 5-6 页 §3.5）。
3. ③ 微批前向/反向计算（关键路径主干）：PTB 并行块（y = x + MLP(LN(x)) + Attention(LN(x))）+ SWA 滑窗注意力 + FlashAttention-2 + 融合 LayerNorm/GeLU；微批按交错 1F1B 流经各 PP stage；激活驻留 HBM，通信操作交由 ④⑤⑥ 与计算重叠 P（第 3-5 页 §3.1/§3.3、第 3 页图 2）。
4. ④ TP/SP 重叠：all-gather/reduce-scatter 与 FFN 并行 Linear 融合，GEMM 切小块与通信流水执行（backward 同法）；按 model chunk 粒度；首个 all-gather 预取与数据加载重叠，通信时间按 1/(2·vpp_size) 因子缩短 P（第 4-5 页 §3.2 与图 3）。
5. ⑤ PP 重叠 + 气泡压缩：交错 1F1B 的 send/receive 解耦异步发起，warm-up 只依赖前一 receive、steady 收发与计算全重叠、cool-down 反向应用同法；LAMB 把批量扩至 4×，流水线气泡减少 87.5% P（第 4 页 §3.1/§3.2）。
6. ⑥ DP 梯度同步重叠：ZeRO-2 语义下梯度 reduce-scatter 聚合、参数 all-gather 取回；高优先级通信先行（优先级＝依赖该通信结果的计算顺序）；这些集合通信由底部「通信基座」承载（Tomahawk 4 三层 CLOS、1:1 无收敛、multi-rail、Swift+DCQCN）P（第 4 页 §3.2、第 6 页 §3.6、第 2-3 页图 1）。
7. ⑦ 优化器更新：LAMB 以 4× 批量更新（微基准：13B 模型、约 250B tokens 后与 ADAM 1× 批量损失一致，随后在生产开启）P（第 4 页 §3.1、第 11 页图 10b）。
8. ⑧ 两阶段快速检查点：阶段一 GPU 片上状态写主机内存（优化序列化 + pinned memory，数秒、训练不停）；阶段二后台进程异步转存 HDFS；恢复时利用 DP 组共享分区：组内单 worker 读取后广播，线性缓解 HDFS 带宽瓶颈 P（第 7-8 页 §4.4）。
9. ⑨ 控制面（旁路常驻）：Driver + 定制 Kubernetes 按节点起 Executor（Pod）；训练守护进程周期发心跳（携带状态、日志、RDMA 指标）；异常/心跳超时 → 暂停全集群 → 轻量自检诊断（主机内 RNIC 回环/全互联、节点内 all-to-all、同 ToR 跨机 all-reduce）→ 屏蔽 IP、驱逐并等量补位 → 自最新检查点恢复；可观测旁路提供 CUDA event 热力图（约 0.5% 慢机）、分布式 trace 与 3D 并行可视化（超时定位故障节点）P（第 6-9 页 §4-§5 与图 5-图 8）。

5. 架构权衡

• 专用特化 ↔ 通用性

  P MegaScale 是「为 LLM 训练特化的专用系统」，全栈协同设计（第 2 页 §1）。I 代价是迁移面：换模型形态（如非 Transformer、多模态）、换硬件代际或换集群环境时，特化假设（TP 同机、multi-rail、HDFS）逐一失效；系统本体未开源，复刻成本高。

• 批量上限 ↔ 收敛风险（LAMB）

  P LAMB 批量 4× 使气泡 −87.5%，微基准在约 250B tokens 后与 ADAM 损失一致（第 4、11 页）。I 「损失最终一致」不等于「任意步数下逐点一致」：早期训练动力学有差异，对下游评测敏感的团队应在自有数据上复跑收敛对照后再全量启用。

• 通信重叠收益 ↔ 结构性暴露段

  P 首个 all-gather 与最后 reduce-scatter 无法被隐藏，只能预取/优先级调度压缩（第 4 页 §3.2）。I 1/(2·vpp_size) 的收益与虚拟 stage 数耦合：加深 vpp 换通信隐藏，但增加调度与内存压力；这是吞吐调参的权衡点而非免费午餐。

• 算法改块（PTB/SWA）↔ 生态兼容

  P PTB 改写注意力与 MLP 的执行结构、SWA 改注意力稀疏模式，均有收敛验证支撑（第 3-4 页；第 10-11 页图 10a）。I 两者都会影响下游生态（微调、推理引擎对标准块结构的假设）；论文验证到预训练损失与生产运行，未给下游任务评测数据。

• 检查点频率 ↔ 关键路径开销

  P 高频检查点缩小故障回退窗口，但写入在关键路径上；两阶段法把关键路径压到「数秒写主机内存」，HDFS 转移移出关键路径（第 7-8 页 §4.4）。I 主机内存缓冲占用节点内存、异步窗口内状态未落盘——故障恰在窗口内时回退更多步数；窗口大小论文未明确披露。

• 诊断灵敏度 ↔ 误杀与停机

  P 自检诊断存在「执行时间 vs 准确率」折中：诊断过久侵占有效训练时间、误报会错杀好机器（第 7 页 §4.3）。I 阈值治理（心跳超时、NCCL 超时、诊断通过线）是这套框架运营期的主要调参对象，论文只给了结果值（<10 分钟、15 分钟内追平）未给调参过程。

• 网络定制收益 ↔ 可复刻性

  P 1:1 无收敛 CLOS + multi-rail + 定制拥塞控制是万卡吞吐的网络前提（第 6 页 §3.6）。I 共享云网络难以完整复刻该前提（收敛比、拥塞控制权在厂商）；租用环境下的预期收益应打折并实测。

6. 云上部署映射

以下映射为厂商中立示例；具体产品命名/规格仅作说明并标 E，以厂商当时目录为准，未逐一在线核验。论文事实单独标注 P。

7. 成本 / 性能 / SLO

7.1 训练场景的「SLO」口径

预训练没有在线时延 SLO，平台 SLA 通常转化为：I ①吞吐目标（tokens/s 或 MFU）；②有效训练时间占比；③故障 MTTR；④收敛里程碑。论文对四者均给出参考：P 有效训练时间率 >90%（迭代数×迭代训练时长 ÷ 总训练时长，第 12 页 §6.3）；故障检测+诊断平均 <10 分钟、崩溃后 15 分钟内自最新检查点追平（第 12 页）；吞吐/MFU 见 #experiments；收敛里程碑对应生产运行损失持续收敛（第 11 页图 11）。

7.2 成本公式（参数化，编辑推断）

I 公式中由论文支撑的变量是吞吐与 MFU（带完整条件，见 #experiments）与有效训练时间率（>90%，第 12 页）；单价、能耗与存储价论文未披露，本页不给伪精确数字。

7.3 敏感项排序（论文口径，条件互不可比）

P 256 GPU 消融口径下，各项叠加对 MFU 的贡献：通信重叠（TP/PP/DP）+6.2%（合并披露）＞ 算法（PTB+SWA）+5.6% ＞ LAMB 批量 256→768 +3.0% ＞ 高效算子 +1.7% ＞ 数据管道与问题代码消除 +1.1%；合计 +17.6%（第 10 页 §6.1、第 11 页表 3）。I 成本治理含义：先拿「不改算子实现」的算法与 LAMB 项，通信重叠与网络定制收益更大但工程更深；万卡规模上稳定性项（>90% 自动修复、15 分钟追平）对有效产出的影响可能大于最后一个 MFU 点。

7.4 数据缺口

• 端到端 TCO、云价格、能耗、机柜功率：I 论文未披露，需部署时自测。
• GPU 具体型号/显存/峰值 FLOPs 假设：P 论文未明确披露（仅称 NVIDIA Ampere），MFU 无法跨集群复算。
• 检查点大小/频率/主机内存占用、异步窗口的回退步数：P 论文未明确披露（机制见第 7-8 页 §4.4）。
• 专有生产模型的参数量、数据构成与下游评测：P 论文未明确披露（第 11 页图 11 仅给归一化损失曲线）。

8. 安全与可运维性

8.1 安全

• 训练数据合规：P 生产运行训练「专有模型」（第 11 页），数据构成未披露。I 自建平台需完成语料许可/隐私/版权审查；本文不提供数据面合规方案。
• 检查点即核心资产：I 检查点含全部模型/优化器状态（P 第 7 页 §4.4），且会集中写入分布式文件系统——应按最高敏资产分级：静态加密、最小权限、副本策略与删除审计；HDFS 类集中存储是横向移动的高价值目标。
• 监控/日志敏感性：I 心跳与 CUDA event 数据含 rank 拓扑、主机 IP、Pod 名、代码段耗时（P 第 7-8 页），可间接暴露模型结构与集群布局；监控栈（Kafka/分析库）应与训练网络隔离并设保留期。
• 控制面权限：I Driver 可暂停全集群、驱逐节点并改写 Kubernetes 资源（P 第 6 页 §4.1）——该权限被滥用即等于集群级拒绝服务；需最小化授权、操作审计与手动驱逐入口的双人复核。
• 供应链：P 论文基线为 Megatron-LM commit 285068c8 时点（第 9 页 §6.1）；R 论文脚注指向的 veScale 为 Apache-2.0（2026-09-15 核验）。I 复刻时应 pin commit + 镜像 digest + CVE 扫描；veScale 是组件库而非 MegaScale 本体，引入前按组件做安全评估。

8.2 可运维性

• 故障自动化闭环：P 心跳异常 → 全集群暂停 → 自检诊断 → 驱逐/补位 → 检查点恢复；>90% 软硬件故障自动识别修复，检测+诊断 <10 分钟、15 分钟内追平进度（第 6-8 页 §4、第 11-12 页 §6.3）。I 平台化时应把「自动恢复率、MTTR、有效训练时间率」作为一线运营指标持续跟踪，而不是当作论文静态数字。
• 掉队治理：P 约 0.5% 机器显著慢（热力图识别），效率由最慢机器决定，剔除后峰值 MFU 稳定；特定慢主机（前向多约 10% 耗时）移除后 MFU +0.7%（第 8 页 §5.1、第 12 页 §6.3）。I 「慢机驱逐」应固化为常态化流程：基线画像 → 热力图定位 → 灰度隔离 → 复检归档。
• 性能退化排查：P MFU 随时间下降案例：步时增长集中于 DP reduce-scatter 发起时差，根因是 GC 与部分 PyTorch 算子等代码段，修改后不再显著下降（第 12 页 §6.3、图 12）；网卡 link flapping 案例要求显式调大 NCCL 超时并做底层信号质量控制（第 12 页）。I 建议写入 runbook：MFU 周环比告警 → CUDA event 热力图 → trace 定位 → 代码段归因。
• 升级与回滚：P 检查点/恢复路径是升级的高风险面（序列化机制被优化过，第 7 页）。I 框架/驱动升级须演练「旧版本写检查点 → 新版本读取」；诊断套件与监控栈随之回归；保留「上一可用镜像 + 兼容检查点 + 配置」回滚组合。
• 已知陷阱速查：P ①默认 NCCL 超时在网卡闪断时过快报错——显式调大（第 12 页）；②TCPStore 阻塞初始化是万卡启动与快恢复的隐性瓶颈（第 5-6 页）；③掉队主机的单 GPU GEMM 微基准可能测不出异常（第 8 页 §5.1）——单卡基准正常 ≠ 集群正常。

9. 适用 / 不适用场景

适用（触发条件 + 理由）

1. 数千至数万卡自建/专有集群上的 LLM 预训练。触发：作业以周计、MFU 与稳定性同时是主要矛盾。理由：论文全部机制与数字均在该场景验证（175B/12,288 GPU 55.2% MFU；生产运行 >90% 有效训练时间率）P（第 1、10-12 页）。
2. 可自控网络与编排的环境（自建数据中心或专属托管）。触发：能定制 CLOS 组网、拥塞控制与 Kubernetes 控制器。理由：通信重叠收益与容错闭环都建立在自控前提上 P（第 6 页 §3.6、第 6-8 页 §4）。
3. 以 3D 并行为底座、基于 Megatron-LM 生态演进的平台。触发：已在用 Megatron-LM（论文用其 commit 285068c8 做基线）。理由：MegaScale 构建于 Megatron-LM 之上，各优化项可直接对照消融表排优先级 P（第 9-11 页）。
4. 万卡作业的故障/掉队治理体系建设。触发：失败与掉队频发、人工排障不可扩展。理由：心跳→诊断→驱逐→恢复闭环 + 热力图/trace/3D 可视化是成套方法论 P（第 6-9 页 §4-§5）。
5. 研究「生产级 LLM 训练系统该怎么设计」的团队。触发：需要系统视角的参考架构与踩坑清单。理由：论文价值正在于公开了常规技术报告省略的系统细节 P（第 12 页 §7）+ I。

不适用（触发条件 + 理由）

1. 期望「引入即用」的开源训练框架。触发：想 pip install 一个 MegaScale。理由：系统本体未开源，论文脚注指向的 veScale 是组件库（Apache-2.0，进行中），不是 MegaScale 官方完整实现 P（第 2 页脚注 3）+ R（2026-09-15 核验）。
2. 数百卡以下的小规模训练。触发：单机或数机作业。理由：万卡特化机制（通信组初始化、multi-rail、稳健训练框架）的收益在小规模不成比例；论文最小实验口径也是 256 GPU P（第 10 页）+ I。
3. 共享/托管环境想完整复刻网络前提。触发：无法控制收敛比、拥塞控制与机架放置。理由：1:1 无收敛 CLOS、multi-rail、自研拥塞控制是吞吐与稳定性的前提，租用环境不可复制 P（第 6 页 §3.6）+ I。
4. 推理服务或微调为主的工作负载。触发：拿本文数字预估 serving/微调收益。理由：论文范畴是预训练系统，不含服务化组件与微调实验 P（第 1 页 §1）+ I。
5. 要求全部组件可复现审计的合规环境。触发：需要逐组件源码审计。理由：专有模型、数据集与部分自研组件（Driver、诊断、拥塞控制算法）细节未公开 P（第 6-11 页）+ I。

10. 实验与指标

10.1 实验设置与口径 P（第 9 页 §6.1）

10.2 强扩展主结果（论文表 2 全量转录）

P 正文口径（第 10 页 §6.1）：全部设置加速 1.19×–1.34×；GPU 增多时 MegaScale MFU 从 59.1% 降至 55.2%（批量固定、计算通信比下降）；12,288 GPU 处原文表述为领先 Megatron-LM「by 14% MFU」。I 编辑注：55.2% − 41.2% ＝ 14.0 个百分点，与 1.34× 一致；「14%」应按百分点差理解，不应再乘算。

10.3 弱扩展与消融

10.4 稳定性与生产运行

10.5 建议复现/验证步骤（编辑推断）

1. I 以 Megatron-LM 为底座复现基线：pin 论文同源 commit 谱系 + 同代 GPU，先在 256 GPU 验证 47.7% MFU 量级（表 3 基线口径，含网络优化）。
2. I 按消融表顺序逐项叠加（PTB → SWA → TP/PP/DP 重叠 → 算子 → 数据管道 → LAMB），每项跑 13B 级收敛对照后再上大规模（对齐论文微基准口径，第 10-11 页）。
3. I 专项验证通信组初始化：>2,000 卡集群测启动时间，确认 Redis 替换与初始化顺序收益（目标 5 秒/30 秒量级，第 5-6 页）。
4. I 演练容错闭环：注入进程级故障与慢机，验证心跳检出、诊断定位、驱逐补位与 15 分钟内追平（对齐第 12 页口径，验收阈值自定）。
5. I 固化有效训练时间率与 MTTR 到平台报表；把热力图/trace 工具常开并验证开销可忽略（对齐第 8-9 页口径）。

11. 论文 / 代码 / 延伸链接

12. 给架构师的决策清单

I 以下为落地前的勾选项；标注（P）的条目对应论文证据，（R）对应仓库核验，其余为工程判断。

• 需求与规模
  • 目标规模 ≥ 数千卡且作业以周计——低于该规模时本文机制的性价比需要重新论证（P：第 1、10 页；I：规模判断）
  • 明确目标是预训练系统参考而非可引入组件：MegaScale 本体不开源（P：第 2 页脚注 3；R：veScale 2026-09-15）
  • 估出 token 预算并用表 2 口径反推 GPU 时与日历时间（P：第 10 页；I：§7.2 公式）
• 兼容性
  • 硬件为同代 NVIDIA GPU 大池，且能说明所用峰值 FLOPs 假设（论文未披露型号，MFU 需自行对齐口径）（P：第 1、9 页；I：口径治理）
  • 网络前提可满足或可近似：节点内高速互联（TP 同机）、跨节点高带宽低收敛、拥塞控制可控（P：第 3、6 页；I：云上近似）
  • 编排面可承载自定义控制器（心跳、诊断、驱逐、补位）与集中式日志/指标栈（P：第 6-8 页；E/I：云上实现）
  • 检查点存储吞吐可支撑「两阶段写 + 组内单读多播」的恢复目标（P：第 7-8 页；I：容量核算）
• PoC（2-4 周量级）
  • 256 GPU 基线复现（Megatron-LM + 网络优化），MFU 与 47.7% 同数量级（P：第 10-11 页表 3；I：验收阈值自定）
  • 按消融顺序叠加 1-2 项（建议先 PTB/SWA 或 LAMB），每项配 13B 级收敛对照（P：第 4、10-11 页；I：流程设计）
  • 容错演练：杀进程 + 慢机注入，测心跳检出、诊断定位与检查点恢复时长（P：第 6-8、12 页；I：验收阈值自定）
• 容量与拓扑
  • 并行规划：TP 限节点内、DP 组优先于 PP 组跨 minipod、数据密集节点同置 ToR 域（P：第 3、6 页；I：放置执行）
  • 虚拟 stage 数（vpp）与首个 AG 预取的权衡纳入调参清单（通信隐藏 ↔ 调度/内存压力）（P：第 4 页；I：权衡归档）
  • 检查点：主机内存缓冲占用、异步窗口回退步数、HDFS/对象存储吞吐三项自测补齐（P：机制第 7-8 页；数值论文未明确披露）
• SLO 与恢复
  • 定义有效训练时间率目标并按论文口径统计（迭代数×迭代训练时长 ÷ 总时长）（P：第 12 页；I：平台化）
  • 定义 MTTR 分解目标（检出/诊断/恢复），对齐「<10 分钟、15 分钟追平」量级（P：第 12 页；I：阈值自定）
  • NCCL 超时显式调大并纳入配置基线（网卡闪断陷阱）（P：第 12 页；I：配置管理）
  • 收敛里程碑与判废标准：生产开启全部算法优化前完成 LAMB/PTB/SWA 收敛对照（P：第 10-11 页；I：流程）
• 成本
  • 按 §7.2 公式以「当时单价 + 查询日期」估算；不用本页数字报价（I）
  • 把消融各档增益写入成本敏感项分析，标注 256 GPU 口径与不可加总性（P：第 10-11 页；I：解读）
  • 把稳定性项（自动修复率、有效训练时间率）计入产出模型，而非只看 MFU（P：第 11-12 页；I：模型设计）
• 安全
  • 检查点集中存储按最高敏资产治理：加密、最小权限、副本与删除审计（I；机制 P：第 7 页）
  • Driver 控制面权限最小化 + 操作审计 + 手动驱逐双人复核（I；能力 P：第 6 页）
  • 监控/日志（心跳、CUDA event、trace）网络隔离与保留期策略（I；形态 P：第 7-9 页）
  • 供应链 pin：Megatron-LM 时点 commit + 镜像 digest；veScale 按 Apache-2.0 组件引入评估（P：第 9 页；R：2026-09-15）
• 运维与回滚
  • 慢机治理流程化：基线画像 → 热力图定位 → 灰度隔离 → 复检归档（P：第 8、12 页；I：流程化）
  • MFU 周环比告警 + CUDA event 热力图 + trace 定位的排障 runbook（P：第 8-9、12 页；I：runbook）
  • 升级演练覆盖「旧检查点 → 新版本读取」；回滚三件套（镜像/检查点/配置）（I；机制 P：第 7 页）
• 退出策略
  • 评估回到 Megatron-LM 原生/社区栈的迁移面：算法项可平移、通信与网络项随环境失效（I；基线 P：第 9 页）
  • 跟踪 veScale 组件路线是否覆盖所需能力，再评估引入（R：2026-09-15；I：跟踪策略）
  • 归档全部配置、口径（MFU 假设）、演练证据与容量档案，保证可重建可审计（I）

13. 证据台账

下表为核心结论的证据映射；逐条引文与在线核验记录见构建文件 sources/megascale.evidence.json。核验日期均为 2026-09-15。