Megatron 面试题（四）：DDP 与 Distributed Optimizer

本文是Megatron 专家面试题系列的 Level 4，覆盖 M055-M068。重点是Main grad、contiguous buffer、通信 overlap、状态分片、norm 与 overflow。

上一篇：PP 调度与负载均衡 · 系列总索引 · 下一篇：CP、重计算与长序列

---

6. Level 4：Megatron DDP、Distributed Optimizer 与 FSDP（M055-M068）

M055. Megatron DDP 与 PyTorch DDP 的核心实现差异是什么？

高分回答要点

• Megatron DDP 围绕 contiguous param/main-grad buffers、bucket groups 和 MCore optimizer/layout 深度集成。
• 支持 gradient AllReduce 或 distributed optimizer 的 ReduceScatter，并提供 grad-reduce/param-gather overlap。
• 还要处理 expert/dense 参数不同 group、PP tied embedding 和模型并行 gradient finalization。

追问：本机 TP 教学脚本用了 TorchDDP，因此不能声称测过 MCore DDP overlap/distributed optimizer。

前置知识与分析过程：先比较parameter/grad存储模型、reducer触发方式和optimizer集成，再列MCore额外处理的并行域。最后把本机代码实际wrapper作为证据边界。

主问题得分点（10分）：contiguous buffer 2 分；bucket/RS/AR 2 分；optimizer overlap 2 分；特殊group finalization 2 分；本机边界 2 分。

追问分析与参考回答：查看脚本可见TorchDDP(model, process_group=data_parallel_group)和Apex FusedAdam，没有构造MCore DDP config、DistributedOptimizer或调用其start/finish sync。因此实测只说明MCore模型与TorchDDP组合可跑，MCore buffer/overlap需另做实验。

追问得分点（5分）：指出实际类 1 分；缺失MCore对象 2 分；可陈述范围 1 分；建议补实验 1 分。

M056. param.main_grad 和 contiguous grad buffer 为什么重要？

高分回答要点

• 参数 backward hook 把 gradient 累积到预分配连续 buffer 的 view，减少大量小 allocation/copy。
• 连续 bucket 便于发起大 collective、按 dtype/group 切分，并与 optimizer shard 对齐。
• view/storage lifetime 与 zero_grad/offload/restore 紧耦合，不能随意替换 .grad 或 resize buffer。

追问：如何检查一个参数的 main_grad offset、bucket ownership 和通信完成状态？

前置知识与分析过程：先区分Parameter对象、.grad和.main_grad view；再从参数到dtype buffer、bucket group和通信handle建立映射。

主问题得分点（10分）：main_grad目的 3 分；view/storage语义 2 分；bucket对齐 2 分；lifetime/调试 3 分。

追问分析与参考回答：读取param到buffer index/offset metadata，确认main_grad.storage与目标grad buffer共享；打印bucket参数列表、range和ready计数。backward后检查该range checksum，start_grad_sync后保存Work状态，finish_grad_sync后与reference归约结果比较。不要访问已offload/resize storage。

追问得分点（5分）：offset/共享storage 2 分；bucket metadata 1 分；ready/Work 1 分；reference checksum 1 分。

M057. overlap_grad_reduce 如何工作？

高分回答要点

• backward hook 标记 bucket 中参数 gradient ready；当最后一个所需 grad 就绪时异步发 AllReduce/ReduceScatter。
• 后面更早层的 backward compute 可与已 ready bucket 通信重叠，iteration 末 finish_grad_sync() 等待。
• bucket 太大推迟启动，太小增加 launch/协议开销；执行顺序和 unused/conditional parameter 必须正确。

追问：需要看 bucket ready timestamp、NCCL union/overlap/exposed time和 step wall，而不是只数 collective。

前置知识与分析过程：画backward参数ready顺序，将参数映射到buckets；计算首个/每个bucket何时满足ready，再与通信stream和compute区间相交。

主问题得分点（10分）：hook/ready机制 3 分；bucket trade-off 2 分；finish wait 2 分；正确overlap指标 3 分。

追问分析与参考回答：记录每bucket最后grad ready时刻和NCCL开始/结束，先对NCCL区间做union，再与非NCCL compute union求intersection；exposed=NCCL union-overlap。最终用max-rank step wall验证exposed下降是否转成端到端收益。

追问得分点（5分）：ready timestamp 1 分；union 1 分；intersection/exposed 2 分；step wall 1 分。

M058. gradient accumulation 时何时应该同步 DP gradient？

高分回答要点

• 前 M-1 microbatches 只本地累积，最后一个 microbatch 完成后才触发 DP sync，避免每次重复整套通信。
• MCore schedule/DDP 通过 no_sync 或 grad sync enable/disable 协调；loss 要除 accumulation 或统一 scale。
• TP/SP/CP 的某些通信是层计算所必需，不能因 DP accumulation 全部关闭。

追问：区分 data-parallel gradient sync 与 tensor-parallel layer collective，否则会错误延迟必要的 dX/activation 汇合。

前置知识与分析过程：按通信是否属于“当前layer数学正确性”分类。TP/PP/CP许多通信必须每microbatch发生；DP只在累积完成后同步复制模型grad。

主问题得分点（10分）：最后microbatch同步 3 分；loss scaling 2 分；不同并行通信分类 3 分；实现控制点 2 分。

追问分析与参考回答：DP no_sync只阻止DP bucket AR/RS，TP的row output归约、column dX归约和PP P2P仍是完成该microbatch F/B所必需。把这些也延迟会让后续算子读到分片contribution而非逻辑tensor，结果错误或hang。

追问得分点（5分）：DP可延迟 1 分；列两个TP必需通信 2 分；PP/CP例子 1 分；错误后果 1 分。

M059. finalize_model_grads() 为什么存在？

高分回答要点

• 普通 DP bucket sync 后，仍可能有 SP LayerNorm 复制参数、PP tied embedding、CP duplication、expert 参数等特殊 gradient。
• finalize 按各自 process group 完成这些同步，并做必要 token/loss scale，确保 optimizer 前状态完整。
• 新并行功能若忘记接入 finalization，常表现为 finite 但不同 rank 参数逐步漂移。

追问：要求列出一个 dense GPT 开 SP/PP 后普通 DP reducer 覆盖不到的 gradient。

前置知识与分析过程：逐类判断参数是DP复制、TP复制、PP首尾共享还是expert专属。普通DP reducer只覆盖相同model-parallel坐标的复制参数。

主问题得分点（10分）：finalize存在原因 3 分；至少三类特殊grad 3 分；正确group 2 分；静默漂移风险 2 分。

追问分析与参考回答：SP LayerNorm参数在TP ranks复制但各看不同sequence shard，需TP group归约；PP tied embedding首尾两份需embedding group归约。这两者都不由普通DP group连接。可再举CP复制weights或MoE expert-DP。

追问得分点（5分）：SP例子2分；PP例子2分；明确DP为何不覆盖1分。

M060. Distributed Optimizer 的数据流是什么？

高分回答要点

• backward 生成连续 main-grad，DP group ReduceScatter 后每 rank 只持自己的 gradient shard。
• 每 rank 只更新对应 FP32 main params 与 optimizer moments shard。
• 更新后 Parameter AllGather 恢复各 DP rank 下一轮 forward 所需的低精度完整模型参数。

追问：它接近 ZeRO-1 的状态分片并结合 gradient RS/param AG；要按实际 MCore版本和配置描述，不只贴阶段标签。

前置知识与分析过程：从完整DP Adam状态出发，按时间顺序追grad产生、RS ownership、local update和AG。对每个阶段标哪类状态常驻/临时。

主问题得分点（10分）：RS 2 分；optimizer shard 2 分；AG 2 分；buffer/state ownership 2 分；版本/ZeRO标签边界 2 分。

追问分析与参考回答：回答应说实际数据流而非只说ZeRO-1：MCore contiguous main grads按DP range做ReduceScatter，rank只更新对应FP32 master/m/v，更新后AllGather低精度模型参数。不同版本对grad常驻、overlap和checkpoint格式细节有变化，因此以目标commit源码为准。

追问得分点（5分）：RS->update->AG顺序 3 分；状态owner 1 分；版本边界 1 分。

M061. 如何推导 distributed optimizer 每参数显存？

高分回答要点

• 先列低精度 model param、main grad、FP32 main param、Adam m/v 和可能的 model grad，而后识别哪些复制/按 DP=d 分片。
• 当前官方示例中 FP16 param+grad 从非分布式约 20 B/param 变为 4+16/d；BF16 param+FP32 grad 为 6+12/d。
• 理论公式不含 fragmentation、bucket padding、activation、临时 AG 和 communication buffers。

追问：d 增大后为何下界不是 0？低精度 model param/部分 grad 仍需复制或常驻。

前置知识与分析过程：逐项列bytes并写replicated + sharded/d，不要直接背总公式；再说明公式外状态。

主问题得分点（10分）：状态拆分 3 分；官方三种dtype公式任一正确 2 分；d极限解释 2 分；额外显存边界 3 分。

追问分析与参考回答：以FP16 param/grad为例，官方理论为4+16/d B/param；d趋无穷时分片main param/m/v等趋零，但forward需要的低精度model param及相关常驻项仍约4B，所以不为零。真实peak还含padding、bucket、AG、activation和allocator。

追问得分点（5分）：公式 2 分；极限 1 分；常驻项 1 分；现实额外项 1 分。

M062. 为什么 Distributed Optimizer 要 ReduceScatter + AllGather，而不是 AllReduce？

高分回答要点

• AllReduce 后每 rank 得完整 gradient，无法直接省 optimizer state；RS 同时归约并把 ownership 分给 ranks。
• optimizer step 只更新 shard，随后 AG 新参数以供复制模型 forward。
• 算法 bytes 可与 AllReduce 同量级，但通信位置、buffer lifetime和可 overlap 窗口不同。

追问：RS 能与 backward overlap，AG 能与下一 iteration forward overlap，但会扩大 in-flight memory。

前置知识与分析过程：先从AllReduce=RS+AG理解数学等价，再把AG移到optimizer后参数同步路径。分别找RS和AG可隐藏的compute窗口。

主问题得分点（10分）：为何不用AR 3 分；RS ownership 2 分；AG恢复参数 2 分；overlap/peak权衡 3 分。

追问分析与参考回答：grad bucket ready后异步RS可与剩余backward重叠；local optimizer完成某param shard后可提前AG，和其他optimizer工作或下一轮较早module compute重叠。多bucket同时full params会提高allocated/reserved，first-use hook仍可能暴露等待。

追问得分点（5分）：RS窗口1分；AG窗口1分；first-use wait1分；in-flight peak1分；需trace验证1分。

M063. overlap_param_gather 如何工作，风险是什么？

高分回答要点

• optimizer 更新 shard 后提前异步 AllGather后续 module/bucket 参数，forward pre-hook 在真正使用前等待。
• 可把 param sync 隐藏在 optimizer/forward compute 后，但需要 deterministic module order和足够计算窗口。
• 过度预取会增加 full-param buffer峰值；条件执行/多 model chunks 会使 hook/order 更复杂。

追问：profile 要看 AG 发起、first-use wait、exposed AG、allocated/reserved peak，而不只看 flag 开启。

前置知识与分析过程：对每param bucket画local update完成、AG发起、module first-use和AG完成四个时刻。收益由first-use前完成程度决定。

主问题得分点（10分）：pre-hook机制 3 分；deterministic order 2 分；峰值风险 2 分；四类指标 3 分。

追问分析与参考回答：记录AG start/end与对应module pre-hook wait；若AG早结束则隐藏成功，若first-use阻塞则该段是exposed。同步采allocator peak和in-flight bucket数，比较limit/prefetch深度。tok/s改善但OOM风险上升也要报告。

追问得分点（5分）：四时间点2分；exposed判断1分；显存1分；端到端trade-off1分。

M064. overlap_grad_reduce 与 overlap_param_gather 有哪些配置依赖？

高分回答要点

• 前者需要 bucket 和异步 grad sync；后者通常依赖 distributed optimizer/参数 shard与 forward pre-hook。
• gradient accumulation、PP rank、bucket size、FP8 post-gather work和 CUDA Graph 可能改变合法组合。
• 开 flag 前先核对版本 config validation；错误组合可能退化为同步路径或改变内存峰值。

追问：专家回答应给“如何证明确实 overlap”，而不是复述参数名。

前置知识与分析过程：先列每个flag所需的数据结构/异步API，再检查组合是否由config允许。最后用消融与timeline证明，而非看日志显示True。

主问题得分点（10分）：两flag依赖 3 分；accum/PP/FP8等约束 2 分；退化/峰值风险 2 分；验证矩阵 3 分。

追问分析与参考回答：做baseline、只grad overlap、只param overlap、全开四组，固定GBS/shape；trace bucket ready、RS/AG与compute交集，报告exposed和peak。若全开比单开慢，再看链路/SM争用和in-flight buffers。目标commit的config validation是合法性来源。

追问得分点（5分）：四组消融2分；trace指标1分；争用/峰值1分；版本校验1分。

M065. Distributed Optimizer 与 Megatron-FSDP 的边界是什么？

高分回答要点

• distributed optimizer 传统路径主要分片 optimizer/grad ownership，同时 forward 常使用复制的 model params。
• Megatron-FSDP 可按策略进一步分片 parameters、gradients、optimizer states，接近 ZeRO-3，并与 MCore模型/并行集成。
• FSDP 参数按需 AllGather/reshard，容量更强但 communication frequency、prefetch和临时峰值不同。

追问：当前官方支持 optim、optim_grads、optim_grads_params 等 sharding strategy；本机没有实测 Megatron-FSDP。

前置知识与分析过程：对参数、gradient、optimizer三类状态逐一问是否分片、何时materialize。用数据流而非ZeRO阶段名比较两条runtime。

主问题得分点（10分）：Distributed Optimizer边界 3 分；FSDP按需AG/reshard 3 分；容量/通信权衡 2 分；本机证据边界 2 分。

追问分析与参考回答：optim只切optimizer，optim_grads再切grad，optim_grads_params连params都切。后者forward前按unit/布局AG参数、之后reshard，通信频率和full-param峰值与传统dist optimizer的step级param同步不同。本机仅跑PyTorch FSDP和MCore0.9模型，未跑Megatron-FSDP。

追问得分点（5分）：三策略2分；按需参数AG1分；与dist optim区别1分；边界1分。

M066. 在 TP/PP/CP/EP 已存在时，DP shard 的“参数”是什么？

高分回答要点

• DP 复制的是每个 model-parallel rank 对应的本地模型 shard，不是完整全局模型。
• 同一 TP/PP/CP 坐标、不同 DP rank 的参数逻辑对应，才能做 DP reduce/shard。
• expert 参数可能使用 expert-DP group，dense 参数使用普通 DP group，ownership 不同。

追问：画 TP2/PP2/DP2 中 rank0 与哪个 rank 做 DP gradient sync，而不是与任意其他 rank。

前置知识与分析过程：先选rank线性化公式并写坐标，再固定TP/PP/CP等model坐标，只变化DP维构成对应组。

主问题得分点（10分）：DP复制local shard概念 3 分；坐标/group推导 3 分；expert例外 2 分；拓扑/owner 2 分。

追问分析与参考回答：若layout为rank=((dp*PP)+pp)*TP+tp，rank0坐标(dp0,pp0,tp0)，对应DP伙伴为rank4(dp1,pp0,tp0)，所以组(0,4)。rank1与5、2与6、3与7分别同步；rank0不应与rank1做DP，因为后者是不同TP shard。

追问得分点（5分）：声明layout1分；rank0坐标1分；组(0,4)2分；解释非rank1 1分。

M067. Megatron 如何计算 global grad norm 和 clipping？

高分回答要点

• 每 rank 对自己拥有且不重复计数的 parameter grad 求局部 norm，再按 TP/PP/DP/expert ownership做正确归约。
• shared/tied/复制参数必须避免重复计入；distributed optimizer shard只持部分 grad。
• unscale/overflow 检查应在 clip 前，clip factor 必须对所有相关 ranks 一致。

追问：若每 rank 独立 clip 本地 shard，会改变全局优化方向。

前置知识与分析过程：先定义全局norm平方和，识别哪些parameter shard唯一、哪些副本应只计一次，再按相应group做SUM。

主问题得分点（10分）：global norm公式 2 分；ownership去重 3 分；归约/clip顺序 3 分；mixed precision位置 2 分。

追问分析与参考回答：各rank算owned grads的sumsq，跨覆盖完整模型的必要groups SUM后开方得到同一global norm，clip系数min(1,max_norm/(norm+eps))广播/一致应用。若各rank用local norm，不同shard系数不同，不再等价对全局gradient向量缩放。

追问得分点（5分）：sumsq公式1分；去重1分；global reduce1分；统一系数1分；错误后果1分。

M068. mixed precision overflow 如何跨并行 ranks 保持一致？

高分回答要点

• 任一相关 rank 出现 inf/nan，都必须让整个逻辑 optimizer step 跳过并统一更新 loss scale。
• overflow flag 需跨 model/data/expert parallel 域归约；只在 rank0 检查会造成参数版本分叉。
• optimizer step、scheduler、consumed samples 和 checkpoint step 都要与 skip 决策一致。

追问：如何构造单 rank 注入 inf 的测试，验证所有 ranks 参数 hash 和 step counter都未推进？

前置知识与分析过程：沿unscale->found_inf归约->clip->step->scale update列状态机，定义原子step应推进的所有计数。

主问题得分点（10分）：全局overflow语义 3 分；归约域 2 分；step/scheduler/data一致性 3 分；故障测试 2 分。

追问分析与参考回答：固定step在一个TP/DP rank的某grad写inf；所有rank做found_inf MAX/SUM后应共同skip optimizer，LR scheduler/iteration consumed samples按框架语义不误推进，loss scale统一下降。比较注入前后每ranklogical parameter checksum及optimizer state hash。

追问得分点（5分）：单rank注入1分；全局flag1分；共同skip1分；计数/scale1分；hash oracle1分。

---

---

上一篇：PP 调度与负载均衡 · 系列总索引 · 下一篇：CP、重计算与长序列