1. 为什么需要“计数、排序、Prefix Sum、Permute”在做 Dispatch 通信之前显存里的向量是按原始 Token 顺序t0,t1,t2...t_0, t_1, t_2...t0,t1,t2...乱序排列的。GPU 无法高效传输这种不连续的数据所以必须做内存重排Local Sort计数Histogram / Count统计当前卡上发往各个目标 Expert/Rank 的 Token 数量。Prefix Sum前缀和/累加和计算出每个 Expert 数据在连续内存块里的起始偏移量Offsets。例如Expert 0 占前 3 个位置Expert 1 占接下来的 2 个位置……Permute重排根据 Prefix Sum 算出的 Offsets把分散的 Token 向量打包Gather复制到一片连续的 Send Buffer 中为随后的Dispatch A2A 通信做准备。2. “Padding 和 Grouped GEMM”解决动态形状跨卡 Dispatch 结束后本地 Rank 拿到了发给它的所有 Token。此时每个专家收到的mem_eme都不一样方案 APadding如果用传统的 GEMM标准矩阵乘法必须把所有专家的mem_eme用 0 补齐Padding到固定的最大容量Capacity但这会浪费大量算力。方案 BGrouped GEMM现代 MoE 的标配如 CUTLASS Grouped GEMM 或 Triton 实现。不填补 0利用 Prefix Sum 记录的偏移量用一个 CUDA Kernel并发处理多个不同mem_eme尺寸的矩阵乘法做到零算力浪费。3. 最绝的终局“等待最热 Expert/rank”木桶效应你最后写的这一句“等待最热 Expert/rank”直接点破了 MoE 分布式训练与推理中最痛的瓶颈——负载不均导致的拖后腿Straggler EffectRank 0 (算完 2 个 Token): 早就算完了进入 Combine A2A 阻塞等待 ──┐ Rank 1 (算完 2 个 Token): 早就算完了进入 Combine A2A 阻塞等待 ──┼─ [所有人必须等它] Rank 2 (热门专家分到 16 个 Token): 还在拼命跑 GEMM ... ───────┘为什么会等因为 Combine 阶段是一个全局同步的All-to-All 通信。后置影响哪怕 99% 的 GPU 都闲着只要有 1 个热门专家Hotspot Expert被分到了太多的 Token整组 32 张/64 张 GPU 就必须全部暂停等待它算完。这也是为什么大模型训练必须加Auxiliary Load Balancing Loss负载均衡损失函数的根本原因。总结你的 MoE 数据流全景图[ 输入 Token ] │ ▼ (Router / Top-K) [ 选出 Expert ID 权重 ] │ ▼ (计数 - Prefix Sum 算 Offset - Local Permute 拼连续 Buffer) [ 内存连续的 Send Buffer ] │ ▼ (Dispatch All-to-All 跨卡通信) [ 目标 GPU 收到数据 ] │ ▼ (Grouped GEMM 算矩阵乘法) [ 得到 Expert 输出 ] │ ▼ (Combine All-to-All 反向通信) [ 阻塞等待最慢/最热的 Rank 算完并返回数据 ] -- 性能瓶颈点 │ ▼ (Inverse Permute 还原顺序 Top-K 加权求和) [ 恢复为 [T, H] 传入下一层 ]