别只比较 Top-k：同一个数字，可能对应完全不同的专家工作量
稀疏 Mixture of Experts（MoE，混合专家）让每个 token 只执行少量 FFN 专家，却没有让其余专家权重消失。要比较两个 MoE，必须同时核对专家有多宽、怎样选与合并、是否存在常开共享路径、过载 token 怎样处理，以及专家究竟放在哪些设备上。
MoE 不是“专家数 + Top-k”两个字段
常见 Transformer MoE 用多个 Feed-Forward Network（FFN，前馈网络）专家替换部分 Dense FFN。稀疏只表示每个 token 不执行全部路由专家；Attention、Embedding、归一化、Dense 层、共享专家和 Router 仍有自己的参数与计算。横向比较前，先把五份合同逐项对齐。
| 合同 | 必须问什么 | 混淆后的典型误判 |
|---|---|---|
| 专家粒度 | 每个 routed/shared expert 的 FFN 宽度是多少？哪些层是 MoE？ | 把 Top-8 直接当成 Top-2 的 4 倍专家计算 |
| 评分、选择、合并 | Softmax 还是 Sigmoid？bias 是否只影响 Top-k？入选输出怎样归一化？ | 以为“选中分数”必然就是最终 merge weight |
| 共享路径 | 是否有 always-on shared experts？每 token 执行几个、宽度多大？ | 把 DeepSeek 的共享专家画成所有 MoE 的固定组件 |
| 平衡与溢出 | 辅助损失、动态 bias、capacity、drop/reroute/dropless 分别怎样定义？ | 把训练目标、选择校正和执行容量当成同一机制 |
| 放置与通信 | 专家在哪些 rank/node？dispatcher 是 All-to-All、AllGather 还是 Flex？ | 看到 Expert Parallel 就断言每个 assignment 都跨卡 |
总参数：模型拥有多少权重
它影响 checkpoint、加载与集群总驻留。即使某 token 没选到 E17，部署仍要在某处保存 E17，除非采用 offload、裁剪或按需加载等另一个系统方案。
激活参数：一条前向路径经过多少参数
不同报告是否计入 Embedding、Attention、共享层与输出头并不总一致。“A3B”是模型口径，不自动等于每 token 3B 次乘加。
实测成本：硬件真正付了多少
FLOPs、权重读取、Router、permute、padding、collective、kernel 形状与并发共同决定延迟和吞吐，不能从 active parameters 单独推出。
MoE 稀疏激活节省的是“相对执行全部同形专家”的专家 FFN 工作量；它不保证比任意更小的 Dense checkpoint 更快，也不把整个 block 的计算按总参/激活参比例缩小。比较必须固定模型质量目标、序列形状、batch、精度、硬件拓扑与 runtime。
评分、Top-k、合并权重和实际执行是四个连续但不同的步骤
Router（路由器）通常把每个 token 的 hidden state 映射为专家 affinity。选出专家 ID 后，runtime 还要 permute/dispatch，把同一专家的 assignments 聚成 batch；专家算完，再 unpermute 并合并。共享专家只有在架构明确声明时才是额外的常开分支。
Score · 为每个 token 计算各专家 affinity
Switch 与 Mixtral 的公开公式使用 Softmax 路由；DeepSeek-V3 使用 Sigmoid affinity。这个投影参数相对专家通常很小，但其输出控制后续选择、训练信号和数据移动。
Select · Top-k 决定 routed assignments
Top-1 表示每 token 选择一个路由专家，Top-2 产生两个 assignments。DeepSeek-V3 在 affinity 上加入按负载更新的 expert bias 来选择 Top-8；该 bias 不进入最终合并权重。
Merge · 入选专家输出按模型规则合并
Mixtral 对选中的两个专家做加权和。DeepSeek-V3 用原始 affinity（不含 selection bias）生成入选专家的归一化权重。不能看到 Router score 就假设所有实现都按同一种重归一化。
Execute · dispatcher 与容量策略决定谁真正计算
运行时要按专家聚合 assignments，再用 Grouped General Matrix Multiplication（Grouped GEMM，分组矩阵乘）等方式执行。是否采用固定 capacity 并 padding 空槽、overflow 是 drop/reroute 还是 dropless 完整执行，以及 assignment 是否跨卡，都是执行合同。
DeepSeekMoE 的设计意图是让共享专家承载共通知识、减少 routed experts 的冗余；其消融证据来自特定规模与数据设置，不能外推成“所有模型都更好”。Mixtral 与 Qwen3 MoE 没有共享专家，仍是完整的 MoE 架构。
先数 assignments，再把专家宽度放回公式
设本层有 T 个 token、每 token 选择 k_r 个 routed experts；若另有 k_s 个常开 shared experts，且单个 routed/shared expert 的近似 FFN 工作分别为 F_r、F_s，要先把名义分配、真实执行与 kernel 槽位拆开：
A_nominal 是 Router 选出的 routed assignments；capacity drop 会产生 A_drop。A_slots 是 kernel 真正计算的槽位：dropless 且不补齐时等于 A_exec，固定 capacity 的 padded kernel 则可能更大，因为空槽也占工作。式子仍不含 Attention、Router、重排、通信与利用率；跨模型专家宽度不同，原始 k 不能直接代表 FLOPs。
16 次 routed assignments，理想平均是每专家 4 次
若计数为 [9,4,2,1]，总和仍是 16；E0 的负载/理想均值为 9/4=2.25。这里数的是 assignments，不是 16 个独立 token：同一个 token 在 Top-2 下会出现两次。2.25 只是失衡比，不是精确延迟倍数，因为通信、并行执行和 GEMM 效率尚未计入。
“2 shared + Top-6 routed”不能按 8 个标准 FFN 来算
该模型每个 fine-grained expert 的中间维度是原 Dense FFN 的 1/4。每 token 执行 2 个共享专家和 6 个路由专家，共 8 个细专家，粗略专家工作量相当于 8×1/4=2 条标准 FFN 路径。这个等价只比较论文里的 FFN 宽度，不等于整层或整模型 FLOPs 恰好翻倍。
DeepSeekMoE 16B
论文报告约 16.4B 总参数、约 2.8B 激活参数；2 shared + 64 routed，每 token 走 2 shared + 6 routed。
Mixtral 8×7B
论文报告约 47B 总参数、约 13B active parameters；“8×7B”不是每 token 执行 56B 参数。
Active 不是统一测量协议
Qwen1.5 官方还同时给出 2.7B activated 与 2.0B non-embedding activated。比较表必须保留原报告口径，不能悄悄拼成同一列。
辅助损失、选择 bias、capacity 与 dropless 分别回答不同问题
平衡机制试图避免少数专家吞掉大多数 assignments；容量合同则说明是否使用固定槽位并 padding 欠填部分，溢出策略回答“真实 assignments 超过容量后怎么办”。前者可能影响 Router 学习或选择；overflow 才涉及跳过、重路由或 dropless 完整执行。
| 机制 | 作用位置 | 准确边界 | 代表实例 |
|---|---|---|---|
| Auxiliary balance loss | 训练目标 / Router 梯度 | 鼓励更均衡；系数过大会与语义路由竞争 | Switch；Qwen3 global-batch loss |
| Dynamic expert bias | Top-k 选择 | DeepSeek-V3 的 bias 只参与选择，不参与 merge weight | DeepSeek-V3 |
| Capacity + overflow | 执行队列 | padding 可补固定 capacity 的空槽；Switch 的 overflow token 跳过该专家计算，并经残差把表示传到下一层 | Switch Transformer |
| Dropless | kernel / 调度 | 不丢 assignment；过载仍可能造成不规则形状与尾延迟 | MegaBlocks；DeepSeek-V3 no-token-drop |
| Group/node limited | 候选专家集合 | 缩小跨设备域，也缩小可选专家集合；V2 是 device-limited，V3 是 node-limited | DeepSeek-V2 / V3 |
Switch 的“dropped token”不是把整条 token 从网络删除
在论文描述的 capacity overflow 中，该 token 跳过溢出专家的 FFN 计算，表示经残差路径继续到下一层。论文还试过 No-Token-Left-Behind（NTLB，重路由到后续专家），但在其设置中没有观察到收益；不能把 reroute 写成通用默认。
DeepSeek-V3 不是字面意义上的“零辅助损失”
其 expert-level balance 主要通过动态 selection bias 实现，因此报告称 auxiliary-loss-free balancing；最终训练仍保留系数 0.0001 的极小 sequence-wise auxiliary loss。准确说法是“专家级主要平衡不靠辅助损失”，不是“训练目标完全没有平衡项”。
DeepSeek-V3 的 node-limited routing 限制通信域
报告中 256 个 routed experts 均匀放在 64 张 GPU、8 个节点；每 token 的 Top-8 routed assignments 最多涉及 4 个节点，并且不丢 token。该数字属于 V3 的训练布局，不是任意部署的固有属性。
监控至少要覆盖分布、容量与网络
逐层记录每专家 assignment 数、max/mean 与 P95/P99、overflow/drop/padding、Router entropy、每目的节点字节、Grouped GEMM 形状和端到端等待。只看全局平均会掩盖最慢专家。
两次 All-to-All 是常见 dispatcher 的前向合同，不是 Expert Parallel 的定义
Expert Parallelism（EP，专家并行）定义的是专家权重怎样分到 ranks。若 assignment 的目标专家在远端，典型 token-choice All-to-All dispatcher 会先 dispatch 激活、专家计算后再 combine 回原 rank；若专家本地或复制，则该 assignment 可没有远端载荷。Megatron Core 还提供 AllGather 与 Flex dispatcher，交换算法并不唯一。
T 是本次计量范围内的 token 数，k_r 是 routed Top-k，H 是 hidden size，s_bytes 是激活每元素字节，r_remote 是需要远端发送的 assignment 比例；系数 2 表示前向 dispatch + combine。它是逻辑 payload 估算，不含 metadata、padding、collective 算法的链路放大、反向通信与并发重叠。
8 tokens × Top-2 × hidden 4096 × BF16
单次 dispatch 为 8×2×4096×2 = 131,072 bytes = 128 KiB；combine 返回同样大小，因此前向逻辑 payload 约 256 KiB。若只有一半 assignments 需要跨 rank，按这个简化口径约为 128 KiB。这不是交换机端口的实测 wire bytes，也没有计反向。
按目标专家发送
常见 token-choice dispatcher：只把 assignment 发往拥有目标专家的 rank，再把结果送回。适合较大 EP，但对拓扑和负载敏感。
聚合 token 后，按既有 routing map 筛本地项
Router 已经完成选择；dispatcher 在 TP×EP 域聚合 token，各 rank 按 routing map 取出本地 experts 的 assignments，结果再经 Reduce-Scatter 合并返回。Megatron Core 将其列为适合 TP-only、较小 EP 或较大 Top-k 等场景的另一合同。
融合与拓扑感知传输
当前文档提供 FlexDispatcher，并可配 DeepEP/HybridEP。是否更快取决于安装、硬件、并行布局与 workload，必须用 trace 与 SLO 验收。
专家放置、Tensor/Pipeline/Data/Context Parallel、共享专家复制、Sequence Parallel、通信重叠与 batch 共同改变瓶颈。原则不是“EP 越小越好”或“越大越省”，而是在能驻留权重的约束下，用真实拓扑最小化关键路径并保证每专家有足够大的 GEMM。
同样叫 MoE，六个家族给出了不同答案
下表只还原公开架构合同，不做质量或速度排行。训练数据、层数、MoE 层频率、专家宽度、精度、硬件与 runtime 均不相同；total/active 是各报告的模型级口径，不是统一 benchmark。
| 模型 / 家族 | 每个 MoE 层的专家合同 | 每 token 路径 | 选择 / 合并 | 平衡、容量与通信边界 | 报告参数口径 |
|---|---|---|---|---|---|
| Switch Transformer | 路由专家；基础架构无 always-on shared expert | Top-1 routed | Softmax router，选 1 个专家 | aux loss + capacity；overflow 跳过专家，经残差继续；典型实现两次 A2A | 家族多种规模，不用一个数字概括 |
| Mixtral 8×7B | 8 routed，0 shared | Top-2 routed | Softmax(TopK) 后加权合并 | 短报告未完整公开生产平衡/溢出合同；不能补写成 DeepSeek 机制 | 约 47B total / 13B active |
| DeepSeekMoE 16B | 64 routed + 2 shared；每专家约 1/4 标准 FFN 宽度 | Top-6 routed + 2 shared | routed gate + shared direct path | 16B 实验中整层专家同设备、无 token drop；有 expert-level balance，未用 device-level loss | 16.4B total / 约 2.8B active |
| DeepSeek-V3 | 256 routed + 1 shared；前 3 层 Dense，后 58 层 MoE | Top-8 routed + 1 shared | Sigmoid affinity；bias 只选 expert，原 affinity 归一化合并 | 动态 bias + 极小 seq aux 0.0001；最多 4 nodes；no token drop | 671B total / 37B active |
| Qwen1.5-MoE-A2.7B | 60 routed + 4 shared | Top-4 routed + 4 shared | 官方博客给出细粒度/共享结构 | 博客未完整公开可横向复刻的平衡、容量与 dispatcher 合同 | 14.3B total / 2.7B activated；2.0B non-embedding activated |
| Qwen3 MoE | 128 routed，0 shared | Top-8 routed | 细粒度 routed experts | global-batch load-balancing loss；系统实现需结合 checkpoint/runtime | 30B-A3B；235B-A22B |
Qwen3 主动不设 shared experts
Qwen1.5 与 DeepSeek 使用共享路径，Qwen3 技术报告明确不使用。架构取舍来自训练与系统整体，不是新模型必然累加旧零件。
细专家允许更大的组合数
DeepSeekMoE 通过切细专家，让 Top-6 routed + 2 shared 的单专家矩阵远小于标准 FFN。比较必须同时写 k 与 expert intermediate size。
未说明就标“未完整公开”
短论文或博客没有给出 capacity、drop policy、dispatcher 时，应把它留作未知项，不能拿另一个模型或框架的默认值代填。
MoE 是模型容量与集群系统的联合设计，不是单独的省算开关
模型能力账 · 固定质量目标再比较
确认 Dense 与 MoE 是否使用相近训练 token、数据、后训练与评测协议。论文里“相近表现、较少 FLOPs”只在其对照实验范围内成立，不能直接外推到你的领域和 SLO。
参数驻留账 · 总权重必须在某处可用
记录 checkpoint、量化后权重、单 rank 分片、共享/复制参数、临时 workspace 与加载时间。active parameters 不能替代容量规划。
专家工作账 · 用 assignments × 专家宽度
按层复算 T×k、shared paths、capacity/padding 和实际 GEMM 形状。Decode 的小 token batch 可能让专家矩阵过小；连续批处理能改善，但幅度要实测。
通信账 · 只数真正远端的 assignments
按 hidden、dtype、remote fraction、节点边界和 dispatcher 估逻辑 payload，再用 profiler 看 wire bytes、重叠和尾延迟。不要把“2×A2A”无条件乘到所有 EP 配置。
SLO 账 · 同时看 P50/P95 与 Goodput
低并发时 Dense 可能更规则，MoE 也可能因较少激活计算获益；没有通用胜负。固定输入/输出长度分布、并发、TTFT/TPOT 门槛和成本后做端到端对照。
可解释性账 · 专家 ID 不是人工科室标签
专家可能呈现领域、语法或位置偏好，也可能只是分布式特征组合。要把 E17 命名为“数学专家”，至少需要跨数据统计、干预、替换与消融证据。
一次 MoE 横评至少交付八个字段
MoE 层位置、routed/shared 专家数与宽度、Top-k 与 merge 规则、balance/overflow 合同、total/active 口径、专家放置、dispatcher 与 remote fraction、端到端质量/吞吐/尾延迟。缺一项就把它标成未知，不用营销名称替代。
一手来源与证据边界
优先使用论文、官方文档、官方模型卡和代码仓库。页面中的数字只代表来源所述设置，不自动外推到其他模型与数据。
稀疏门控 MoE、专家容量与负载均衡的早期系统化定义。
Top-1 路由、capacity、token overflow、辅助平衡损失与两次 All-to-All 的典型实现。
8 个路由专家、Top-2 加权合并，以及总参数、激活参数与部署内存边界。
细粒度专家、共享专家隔离、专家/设备级平衡，以及 16B 配置与实验范围。
device-limited routing 与共享/路由专家的系统协同背景。
选择 bias、原始 affinity 合并、极小序列级辅助损失、node-limited routing 与 no-token-drop。
Qwen1.5-MoE-A2.7B 的总/激活参数、细粒度路由专家与共享专家。
128 个路由专家、Top-8、无共享专家与 global-batch balance loss。
用 block-sparse kernels 实现 dropless MoE，区分 token dropping 与 padding 浪费。
All-to-All、AllGather、Flex dispatcher、Grouped GEMM、DeepEP/HybridEP 与通信重叠的当前实现边界。