本文是Megatron 专家面试题系列的 Level 6，覆盖 M081-M096。重点是Router、容量、token dispatch、All-to-All、GroupedGEMM 与负载均衡。
上一篇：CP、重计算与长序列 · 系列总索引 · 下一篇：性能、精度与 overlap
8. Level 6：MoE、Expert Parallel 与负载均衡（M081-M096）
M081. Dense FFN 与 MoE layer 的核心差异是什么？
高分回答要点
- Dense FFN 每个 token 经过同一组参数；MoE router 为 token 选择 top-k experts，只激活总参数的一部分。
- 总参数/optimizer memory可很大，但每 token FLOPs由active experts决定；系统新增routing、permutation、dispatch/combine和负载不均衡。
- MoE扩容量不自动提高吞吐，expert GEMM变小、All-to-All和tail expert都可能成为瓶颈。
追问：区分total parameters、active parameters、每token FLOPs和每rank local expert parameters。
前置知识与分析过程：从dense FFN参数/FLOPs出发，引入E experts与top-k，分别计算总容量和每token激活计算，再映射EP local experts。
主问题得分点（10分）：dense/MoE定义 2 分；四种参数/FLOPs口径 3 分；新增数据路径 3 分；性能非自动提升 2 分。
追问分析与参考回答：总参数包含全部E个experts；active参数/FLOPs每token只含top-k experts及shared/dense部分；EP=e时每rank通常只持E/e个local experts（还受expert TP影响）。系统成本另加router、permute、A2A和不均衡，不能用active FLOPs单独预测tok/s。
追问得分点（5分）：总/active区别2分；local expert公式1分；top-k影响1分；系统额外成本1分。
M082. Top-k router 的前向数据流是什么？
高分回答要点
- 对每个token hidden计算expert logits/scores，应用softmax或指定scoring，再选择top-k expert及routing probability。
- 构造routing map/counts，按目标rank/local expert排列tokens；expert输出再按probability加权并恢复原token顺序。
- router precision、noise/bias、capacity和load-balancing策略会改变数值与通信分布。
追问：top-2中同一token的两个expert位于不同ranks时，token会有两个实例，combine必须按原token id聚合。
前置知识与分析过程：给每token保留token_id, expert_id, probability, source_rank，按router->instance expansion->dispatch->combine跟踪。
主问题得分点（10分）：router计算 2 分；top-k选择/实例 2 分；routing metadata 2 分；dispatch/combine 3 分；数值配置 1 分。
追问分析与参考回答：token x选e1/e2后生成两个instances (x,e1,p1)和(x,e2,p2)，分别送到owner；expert输出返回source后按token_id恢复并算p1*y1+p2*y2。若只按接收顺序拼回或遗漏prob，会错位/改变函数。
追问得分点（5分）：两个实例1分；metadata1分；返回owner1分；加权聚合1分；错误反例1分。
M083. router auxiliary loss、z-loss 和无辅助损失平衡分别解决什么？
高分回答要点
- auxiliary load-balancing loss鼓励token/概率在experts间均匀，但系数过大可能损害主任务或改变路由。
- z-loss约束router logits规模，改善数值稳定；它不直接保证expert负载均匀。
- aux-loss-free方法可用动态bias等机制调整选择，避免aux梯度干扰，但需要稳定更新和独立监控。
追问：不能只看aux loss值；至少看tokens/expert分布、prob mass、drop、top-k overlap和训练质量。
前置知识与分析过程：将“训练目标稳定性”和“系统负载均衡”分开。每种loss说明直接约束对象和可能副作用，再列观测。
主问题得分点（10分）：三类方法定义 4 分；作用对象 2 分；副作用 2 分；监控/质量 2 分。
追问分析与参考回答：aux值低可能因为系数/scale而非负载好；需按layer/step看token counts的CV/max-mean、prob mass、entropy、drop/padding及validation loss。z-loss主要控logit幅度，不能替代负载指标；aux-free bias也需看动态稳定性。
追问得分点（5分）：至少三类负载指标2分；概率指标1分；质量1分；指出z-loss边界1分。
M084. capacity factor、token drop 和 dropless MoE 的trade-off是什么？
高分回答要点
- 固定capacity为每expert预留上限，便于静态buffer/GEMM，但热点token可能drop或padding浪费。
- dropless保留全部token，训练语义更完整，但variable splits、最慢expert和峰值buffer更难控制。
- capacity越大不等于更好；显存、通信、padding FLOPs和tail latency都变化。
追问：若drop rate均值很低但某些层/step突增，可能造成质量和性能长尾，需按layer/time监控。
前置知识与分析过程：写理论平均tokens/expert与capacity，再比较padding、drop和dropless variable-size三种执行。
主问题得分点（10分）：capacity定义 2 分；drop/padding 2 分；dropless 2 分；显存/质量/tail trade-off 3 分；监控 1 分。
追问分析与参考回答：全局均值会稀释热点层。应记录每层每stepcapacity usage、dropped token ids/比例、max receive和下游loss；按p99告警。性能上热点会扩大recv buffer和最慢expert，质量上特定token系统性drop可能产生偏差。
追问得分点（5分）：layer-step切分1分；capacity usage1分；质量后果1分；性能后果1分；p99/告警1分。
M085. token permutation/unpermutation 为什么是实际热点？
高分回答要点
- router输出按token顺序，GroupedGEMM需要按expert连续排列；需要计算offset、gather/scatter和inverse mapping。
- top-k会扩张token instances，probability乘法可放在不同阶段，影响额外访存和临时buffer。
- 小expert或高EP时，permutation kernel可能比GEMM更显著，因此需要fusion和memory-efficient实现。
追问：正确性oracle应携带全局token id做dispatch->expert identity->combine roundtrip。
前置知识与分析过程：把permutation视为一一/一对多索引变换，先构造forward map再构造inverse map。性能分析再看访存、launch和buffer。
主问题得分点（10分）：为何需要permute 2 分；offset/inverse 2 分；top-k/prob位置 2 分；性能热点 2 分；oracle 2 分。
追问分析与参考回答：每instance携带唯一(global_token_id, topk_slot)，expert函数可暂设为加expert id；dispatch/combine后应恢复原token顺序并得到解析和。这样可发现split、排序、inverse或prob乘法错误，远强于只检查shape/finite。
追问得分点（5分）：唯一id1分；可解析expert函数1分；top-k slot1分；逐元素oracle1分；能定位错误阶段1分。
M086. All-to-All token dispatcher 的完整数据流是什么？
高分回答要点
- 先统计每个目标EP rank的send counts，交换counts得到recv splits，再按rank/expert排列hidden和probs。
all_to_all_singlevariable splits把token instances送到expert owner，接收后再按local expert排序执行GEMM。- combine时执行逆permutation和反向All-to-All，把结果返回原owner并按top-k probabilities累加。
追问：为什么combine splits与dispatch方向相反？当前rank收到多少就需按来源发回多少。
前置知识与分析过程：构造send-count矩阵C[src,dst]，dispatch时src按行发送，dst按列接收；combine对同一矩阵转置方向返回。
主问题得分点（10分）：count交换 2 分；variable split 2 分；local expert排序 2 分；inverse A2A/permute 3 分；metadata 1 分。
追问分析与参考回答：dispatch rank i的send splits是C[i,*]，recv splits是C[*,i]；expert完成后rank i要把收到的每个source段发回，所以combine send splits等于dispatch recv splits，combine recv splits等于dispatch send splits。顺序还需与source segment metadata一致。
追问得分点（5分）：矩阵定义1分；dispatch行/列1分；combine交换2分；顺序metadata1分。
M087. AllGather dispatcher 与 All-to-All dispatcher 如何选择？
高分回答要点
- AllGather让各EP rank看到更广token集合并本地选所需部分，逻辑简单但复制/带宽随EP放大。
- All-to-All只把token送到owner，对大EP更省冗余，但variable split、permute和跨节点all-to-all复杂。
- 选择取决于EP、top-k、token数、expert粒度、拓扑和实现kernel；要以端到端profile而非名称决定。
追问：官方文档把alltoall作为标准EP>1路径，allgather可用于TP-only、小EP或较大top-k等场景。
前置知识与分析过程：分别计算每rank发送的有效token bytes和复制冗余，加入permute/variable split复杂度，再按EP/top-k/拓扑选择。
主问题得分点（10分）：两dispatcher数据流 4 分；通信/内存复杂度 2 分；选择条件 2 分；需实测/版本边界 2 分。
追问分析与参考回答：AllGather把所有rank token复制到每rank，再筛本地experts，EP大时bytes/peak高但免复杂A2A路由；A2A只发送目标instances，更适合大EP，却需要counts、permute和variable splits。用token规模、EP、top-k和链路做break-even benchmark。
追问得分点（5分）：复制与定向发送2分；复杂度1分；适用场景1分；break-even实验1分。
M088. Flex/DeepEP/HybridEP 等新 dispatcher 优化的是什么？
高分回答要点
- 目标是减少跨节点冗余、融合节点内/间dispatch、降低占用SM并利用特定硬件通信能力。
- DeepEP面向Hopper/B200等跨节点fine-grained MoE；HybridEP面向更新NVLink/MNNVL平台，依赖特定TMA/IBGDA/symmetric memory能力。
- 这是当前官方新版能力，本机V100未实测，不能声称相同backend可用或有同等收益。
追问：面试时先说硬件和版本前提，再比较NCCL A2A baseline；不要只报热门backend名。
前置知识与分析过程：先问GPU架构、NVLink/MNNVL、跨节点网络和MCore/backend版本，再列新dispatcher减少的冗余/SM占用。
主问题得分点（10分）：优化目标 3 分；DeepEP/HybridEP定位 2 分；硬件依赖 2 分；baseline/证据边界 3 分。
追问分析与参考回答：回答应先说V100不满足这些新backend要求；在H100/B200/GB200目标平台，用同router/token counts对比NCCL alltoall与Flex backend，测A2A exposed、SM占用、tok/s、peak和correctness。若硬件/软件gate不满足就fallback而非强开。
追问得分点（5分）：硬件gate1分；V100边界1分；公平baseline1分；五类指标1分；fallback1分。
M089. EP group、expert-DP group 和expert-TP group如何理解？
高分回答要点
- EP group把不同experts放到ranks；同一expert shard在其他复制域上的对应ranks构成expert-DP，用于其gradient同步。
- expert-TP可进一步切单个expert MLP；它可与dense TP不同，fine-grained expert常倾向较小expert-TP保护GEMM shape。
- dense参数和expert参数可能使用不同DP group/optimizer bucket，不能用一个global DP group处理全部参数。
追问：给定rank mesh要求分别画dense attention参数和expert参数的同步伙伴。
前置知识与分析过程：先为每类参数写owner坐标：dense参数忽略EP expert id，expert参数包含expert id/expert-TP shard。固定所有model坐标只变化复制维得到各自DP组。
主问题得分点（10分）：EP/EDP/ETP定义 4 分；dense/expert组差异 3 分；optimizer bucket影响 2 分；避免机械公式 1 分。
追问分析与参考回答：dense attention在所有model replicas复制，按普通DP/CP合并域同步；某expert只在持有同一expert id和同一expert-TP shard的replicas间同步，形成expert-DP。先标具体mesh坐标再连线；不能让不同experts互相AllReduce。
追问得分点（5分）：dense owner1分；expert id/shard2分；两类group1分；错误归约后果1分。
M090. TP+EP为什么容易制造复杂的token ownership？
高分回答要点
- dense TP ranks可能复制sequence tokens但分片hidden/heads，router通常需要明确每个token实例由谁dispatch。
- SP可按sequence提供token ownership；expert-TP又要求同一expert输入按hidden/layout分发。
- 错误组合会重复dispatch、重复计算或漏grad，必须沿tensor layout逐边验证。
追问：官方parallel guide明确提示TP与EP组合时启用SP；高分答案要解释机制而非只背约束。
前置知识与分析过程：沿dense TP边界确定token是否复制，再沿router看调用者数量；之后区分token并行和expert hidden TP。
主问题得分点（10分）：重复token问题 3 分；SP ownership 2 分；expert-TP 2 分；组合验证 3 分。
追问分析与参考回答：若同一logical token在多个dense TP ranks复制且都调用router，会形成多份routing instances和重复A2A。SP在进入MoE前按sequence分配唯一token owner；若expert本身用TP，则owner token可再按expert计算layout分发，这与重复路由不同。
追问得分点（5分）：重复路由2分；SP owner1分；expert-TP区别1分；画完整路径1分。
M091. GroupedGEMM 为什么适合 MoE？
高分回答要点
- 每个local expert收到不同token数，形成多个不同M、共享相似K/N的小GEMM；逐expert launch开销和低利用率高。
- GroupedGEMM在一次/少量kernel中调度多个expert matmul，提高launch与SM利用率，并支持不同token counts。
- 收益依赖token分布、expert数、hidden/FFN shape、dtype和硬件；极端热点仍会被单大expert拖尾。
追问：应报告每expert M分布、GroupedGEMM kernel时间、padding/有效FLOPs和最慢rank，而非只报总tok/s。
前置知识与分析过程：把local experts看成一组M_i x K x N GEMMs，先分析M_i分布，再比较逐expert launch与grouped调度。
主问题得分点（10分）：GroupedGEMM问题定义 3 分；收益机制 2 分；负载/shape条件 2 分；完整指标 3 分。
追问分析与参考回答：收集每step每expert token count即M_i，报告分位数/CV；profile grouped kernel执行时间与实际有效FLOPs，若实现padding则算padding ratio。总tok/s相同也要看最慢EP rank和空/小expert，因为它们决定扩展与浪费。
追问得分点（5分）：M_i分布1分；kernel1分；有效/padding FLOPs1分；最慢rank1分；端到端1分。
M092. shared expert 的作用与系统代价是什么？
高分回答要点
- shared expert对所有tokens执行，提供稳定dense capacity，与routed experts输出组合。
- 它增加固定FLOPs和参数，也创造可与EP dispatch/A2A重叠的计算窗口。
- overlap需要独立stream和正确依赖；shared expert过大也会成为新的critical path。
追问：如何证明重叠？对shared compute与dispatch/combine做interval union/intersection，并比较exposed A2A和step wall。
前置知识与分析过程：画routed与shared两条依赖支路，找到合并点。只有合并前独立部分可并发，之后必须wait。
主问题得分点（10分）：shared expert语义 2 分；额外成本 2 分；可重叠窗口 3 分；trace/峰值 3 分。
追问分析与参考回答：用不同CUDA streams发A2A和shared MLP，event保证输入ready并在输出combine前汇合。trace对A2A interval与shared GEMM求intersection，exposed A2A下降且step wall下降才算收益；同时检查并发争SM和双分支activation peak。
追问得分点（5分）：依赖图1分；stream/event1分；intersection/exposed1分；step wall1分；资源争用/peak1分。
M093. MoE load imbalance 应观测哪些指标？
高分回答要点
- 每layer/step的tokens per expert：max/mean、CV、p95/p99、空expert、top-k pair和跨rank send/recv counts。
- router概率/entropy、aux/z loss、drop/padding、expert GEMM时间、dispatch/combine和rank idle。
- 聚合均值会掩盖动态热点；要按layer、DP replica、sequence类型和时间窗口切分。
追问：本机toy的hot expert receive max/mean=6，吞吐下降66.4%，但它没有真实router/quality指标。
前置知识与分析过程：将路由质量、计算负载、通信分布和训练质量分四层指标。按layer/step/rank保留分布而非全局平均。
主问题得分点（10分）：负载统计 3 分；router/通信/compute关联 3 分；时间维度 2 分；本机数字与边界 2 分。
追问分析与参考回答：toy手工构造send splits，证实max/mean=6时最慢expert及combine peer wait使tok/s降66.4%；但没有router logits、aux loss、drop或收敛，不能推生产质量。真实实验需把这些指标与token counts和A2A时间关联。
追问得分点（5分）：两个准确数字1分；机制2分；缺失指标1分；不夸大1分。
M094. 为什么非热点rank的collective kernel也可能很长？
高分回答要点
- collective duration包含等待peer到达；热点rank先做更大expert GEMM，其他rank在combine A2A内等待。
- profiler可能把straggler等待归到NCCL kernel，看起来像“网络慢”，实际根因是上游compute imbalance。
- 需对齐rank timeline，把router counts、expert GEMM结束和collective进入时间关联。
追问：优化NCCL算法无法修复上游expert负载，必须先区分transport与peer wait。
前置知识与分析过程：对齐各rank expert compute结束和collective enter/exit，collective kernel总时长拆为arrival skew与传输/同步。
主问题得分点（10分）：peer wait机制 3 分；多rank timeline 3 分；transport指标 2 分；正确优化方向 2 分。
追问分析与参考回答：若非热点rank早进入combine而热点rank晚到，前者NCCL kernel长主要是在等待；查看enter-time spread、热点GEMM/token counts。只有所有rank近同时进入而通信仍慢，才进一步查algbw/NIC/algorithm。前一种应优化routing/capacity/expert balance。
追问得分点（5分）：enter skew2分；token/GEMM关联1分；网络判据1分；优化归因1分。
M095. 如何 overlap EP All-to-All 与计算？
高分回答要点
- 可把tokens/chunks分批，在一批dispatch/combine时执行另一批expert/shared compute，或做batch-level overlap。
- 需要足够chunk计算隐藏通信，且不能让更多in-flight token buffer造成OOM。
- stream/event、permutation依赖、wgrad延后和PP schedule需共同设计，错误顺序会静默损坏。
追问：评价exposed A2A、expert SM utilization、buffer peak、tokens/s和数值一致性，不只看NCCL累计时长。
前置知识与分析过程：先按token chunks构造pipeline依赖，再计算每chunk通信与compute是否足够隐藏。评估更多in-flight chunks的内存。
主问题得分点（10分）：chunk/batch overlap 3 分；依赖/stream 2 分；计算通信比 2 分；五类指标 3 分。
追问分析与参考回答：做no-overlap与不同chunk数对照，固定routing；trace计算A2A union和与expert/shared compute交集，报告exposed。检查SM争用、permute依赖和buffer peak；用token-id oracle与baseline loss/grad确保延后wgrad等调度未改变数学结果。
追问得分点（5分）：消融1分；interval指标1分；SM/peak1分；dependency1分；correctness1分。
M096. 本机MoE实验能证明什么，不能证明什么？
高分回答要点
- 证明variable-split All-to-All、token-id roundtrip、简单expert GEMM、hotspot和peer wait的数据路径机制。
- 不能证明MCore真实router、aux loss、capacity/drop、GroupedGEMM、shared expert、DeepEP或训练收敛。
- 面试可称“MoE通信/不均衡原理实验”，不可称“优化了生产Megatron MoE”。
追问：扩展顺序应为真实router correctness -> dispatcher对照 -> GroupedGEMM -> overlap -> quality/长时间负载。
前置知识与分析过程：用证据成熟度分级：数据路径、完整MCore模块、性能优化、训练质量。每层前一层correctness是后一层前提。
主问题得分点（10分）：已证明内容 3 分；六类未证明内容 3 分；准确表述 2 分；扩展路线 2 分。
追问分析与参考回答：先将toy替换为MCore router并用token-id/prob oracle；再比较allgather/A2A；启用GroupedGEMM和fusion；最后做overlap与多小时真实数据训练，观察aux/drop/quality。任何阶段性能结论都保留前一阶段reference和feature-off回退。
追问得分点（5分）：顺序完整2分；每步oracle1分；性能消融1分；质量/soak1分。