01 · 不是每张卡上的专家都会同样忙
MoE层的router为每个token选择一个或多个专家，专家处理后按路由权重组合结果。Expert Parallelism把专家分布到不同设备，token要送到拥有相应专家的设备。若热门专家集中在一张卡，其余卡即使先算完，也可能等最慢一方返回结果。
专家数量均分不等于工作均分。一个专家接到80个token，另一个只接10个；各卡两名专家看似整齐，却可能很不均衡。布局优化关注物理分工；Grouped GEMM关注一张卡上的专家计算；二者不是同一个优化。
依据：DeepSeek · EPLB原作者专家复制与放置算法 ↗ · vLLM · Expert Parallel部署与EPLB ↗
02 · router到dispatch，再到combine
隐藏输入X
→ router给每token选 logical expert id 与 gate weight
→ 将逻辑专家映射到可用 physical replica / rank
→ 按目的rank与专家打包，dispatch传token表示及还原索引
→ 各专家执行MLP（可用Grouped GEMM等）
→ combine把贡献传回token归属并按gate加权
→ 得到原token顺序的输出top-k时，一个token可能生成k份专家调用；统计“专家调用数”不能直接当成独立token数。通信通常搬隐藏向量和元数据，不是为每个token传整份专家权重。权重迁移发生在布局调整或副本准备时，是另一笔开销。
AlltoAll表达多目的交换语义；真实MoE常用变长计数与专门dispatch/combine实现，不要求每对设备发送相同长度。还原索引和gate必须随布局保留，否则结果会错位。
依据：DeepSeek · DeepEP dispatch/combine通信实现 ↗ · NCCL 2.32 · 集合通信操作与rank语义 ↗
03 · 逻辑专家与物理副本，先分清身份
逻辑专家E0是一组确定权重和计算功能；物理副本是这组权重在某设备上的存储。将E0放到另一卡，或新增兼容副本E0′，不应把router原来选E0的token改成E1。路由给哪个逻辑专家与由哪个物理副本执行，是两次不同选择。
| 策略 | 改变什么 | 是否需要重新评估模型语义 |
|---|---|---|
| 移动专家 | 同逻辑专家换物理位置 | 内容/版本/算子兼容时保持数学任务，注意数值与还原。 |
| 复制热门专家并分流 | 一个逻辑专家由多个兼容副本承接 | 推理可保留原路由与gate；权重必须一致。 |
| 改router或强制换专家 | token所选逻辑专家变了 | 模型计算改变，需要质量与训练验证。 |
| 容量溢出时丢token | 部分专家贡献没有执行 | 不能当成等价的纯系统提速。 |
本篇先用推理且专家独立确定计算的情况解释副本分流。训练还需合并同一逻辑专家各副本的梯度，并一致更新状态；有Dropout等随机操作时还要保持指定的随机语义。
依据：DeepSeek · EPLB原作者专家复制与放置算法 ↗ · DeepSeek-V3 Technical Report · MoE路由与训练 ↗
04 · 四专家、两卡：100/20怎样变为60/60
自设top-1批次共120个token，专家负载E0/E1/E2/E3=[80,20,10,10]。假设每次专家调用成本相同，卡内顺序执行，无通信和固定开销。原布局r0有E0/E1，负载100；r1有E2/E3，负载20。完成时间受最大负载100支配。
| 方案 | r0工作 | r1工作 | 最大负载 |
|---|---|---|---|
| 原布局 | E0:80 + E1:20 = 100 | E2:10 + E3:10 = 20 | 100 |
| 只调整放置 | E0:80 + E2:10 = 90 | E1:20 + E3:10 = 30 | 90 |
| 复制E0并分流 | E0:40 + E1:20 = 60 | E0′:40 + E2:10 + E3:10 = 60 | 60 |
第三种方案新增一份E0权重，分流后总调用数仍120。最大负载100→60不是实测1.67倍加速：搬运、重排、不同矩阵效率、布局更新与内存压力都未计。真实引擎可能要求每rank相同专家槽数，需额外槽或填充；本例允许两侧物理专家数不同。
保留逻辑专家，改变物理分工
E1/E2/E3固定20/10/10次；top-1、每次相同成本、各卡内顺序执行。新增E0副本自设256 MiB，无网络/迁移/填充开销；本例允许各rank专家数不同。05 · 负载平衡之后，网络可能成为新瓶颈
token要从输入归属rank送到专家rank，再把结果送回。把专家移近常见来源可能少跨机，但让所有热点聚到同一张卡又会增加计算等待。布局要在设备负载、机间流量和副本容量之间取舍。
如果一个token选择两个远端专家，输入可能发送两份；是否合并同目的rank、是否有本地专家或共享专家、输出如何归并，都影响真实字节。不能简单用“token数×隐藏维度”代表全部MoE网络成本。
分层布局可以先把有共同路由约束的专家组放到同一节点，再在节点内分配副本与负载；是否适用取决于模型原有group-limited路由和网络。DeepSeek的EPLB提供分层与全局策略入口，不能直接套到任意router。
依据：DeepSeek · EPLB原作者专家复制与放置算法 ↗ · DeepSeek · DeepEP dispatch/combine通信实现 ↗
06 · 动态均衡为什么不宜每轮都搬专家
- 统计每层各逻辑专家的调用数和实际耗时，必要时区分Prefill/Decode与业务类型。
- 按历史窗口估计近期负载，并结合每卡内存、互联与专家槽约束生成新映射。
- 预先装好新副本和必要元数据，在安全边界让后续批次使用新映射。
- 保留旧映射/权重直到旧批次和通信结束，再回收；避免新旧结果混在同一代映射。
热门专家会随请求分布变化。重配过勤可能把时间花在权重传输，历史窗口过长又反应慢。可设置更新间隔、收益门槛与稳定策略，但这些是调度选择，不是算法保证。
一份专家权重若为256MiB，复制10份就是额外2.5GiB；多层累计还可能挤占Decode的KV预算。降低热点等待和可承载并发的变化必须一起评估。
依据：vLLM · Expert Parallel部署与EPLB ↗ · DeepSeek · EPLB原作者专家复制与放置算法 ↗
07 · 最小正确性模型与现成实现入口
logical_ids, gates = router(X)
physical_jobs = assign_compatible_replicas(logical_ids, map_version)
packed, restore_index = dispatch(X, physical_jobs)
contributions = run_experts(packed)
Y = combine(contributions, restore_index, gates)
# 每个(token, logical expert)贡献应恰好出现一次。下方标准库脚本用小专家函数和top-2加权输出，比较原布局、移动专家和复制分流。另做错gate与漏贡献的反例；它验证输出身份和还原，不模拟网络或设备性能。
阅读vLLM时可从EP部署、EPLB配置和专家映射进入；enable_eplb与冗余专家数需要匹配版本和内存约束。DeepEP提供高吞吐/低延迟dispatch与combine通路，优化通信；仅启用更快通信不自动决定最佳专家放置。
依据：vLLM · Expert Parallel部署与EPLB ↗ · DeepSeek · EPLB原作者专家复制与放置算法 ↗ · DeepSeek · DeepEP dispatch/combine通信实现 ↗
08 · 训练副本需要梯度和更新的一致性
如果同逻辑专家副本分别处理不同token，它们产生的是该专家梯度的不同贡献。训练要按既定Loss归一化合并这些贡献，确保参数更新及优化器状态一致；不能各副本独立optimizer.step后仍声称是同一专家。
训练router的负载均衡Loss、偏置调整等会改变训练规则，与运行时重放置是不同维度。冻结router做布局对照，才能分清省下的是物理等待，还是改变了路由目标或训练质量。不同训练框架是否支持专家副本需单独核对。
09 · 不只看平均均衡率
| 层面 | 观察什么 |
|---|---|
| 语义 | 逻辑专家/权重版本、token索引、gate、贡献次数；训练再比梯度和更新。 |
| 计算 | 各rank真实专家时间、最大等待、Grouped GEMM形状与填充。 |
| 网络 | 每对rank/节点的字节、dispatch/combine时间、共同链路拥塞。 |
| 容量 | 副本权重、暂存、旧映射驻留与剩余KV预算。 |
| 服务/训练 | 相同资源下吞吐、TTFT/TPOT/step及质量，而非只比平均专家调用数。 |
各卡调用数相同也可能耗时不同：dtype、专家形状、批量与设备能力影响效率。跨节点布局还要记录网络距离；单层均衡指标不能代替端到端评估。
10 · 平台对照与自查
专家放置与副本逻辑可用于不同平台，但实际token分发、Grouped GEMM、映射切换与通信后端各自实现。NVIDIA路径可读vLLM EP、DeepEP；昇腾先查引擎专家并行支持，再核对HCCL变长交换及配套MoE算子。不能把CUDA通信库直接当作NPU可运行代码。
依据：vLLM Ascend · 支持功能矩阵（main） ↗ · CANN 8.2.RC1 · HCCL通信域与分层算法 ↗ · DeepSeek · DeepEP dispatch/combine通信实现 ↗
- 复制E0后，router所选逻辑专家和gate需要改变吗？
- 若E0两份副本权重版本不同，负载60/60能否说明优化成功？
- 新增副本让KV容量少了2.5GiB，服务吞吐为什么可能下降？
流程位置与关联方法
这个方法可能出现在多个位置；计算线包含模型计算与算子实现，执行线包含运行时、内存和通信。
资料与核查范围
原理依据以原始论文和官方文档为主；算例与时间线是教学推导。文档核查日期：2026-10-10。引用 main / latest 文档时，实际接口以安装版本为准。
- DeepSeek · EPLB原作者专家复制与放置算法 ↗
- DeepSeek · DeepEP dispatch/combine通信实现 ↗
- vLLM · Expert Parallel部署与EPLB ↗
- DeepSeek-V3 Technical Report · MoE路由与训练 ↗
- CANN 8.2.RC1 · HCCL通信域与分层算法 ↗
- NCCL 2.32 · 集合通信操作与rank语义 ↗
- vLLM Ascend · 支持功能矩阵（main） ↗
代码为接入片段或教学伪代码；本页没有声称完成 NVIDIA / 昇腾硬件实测。