拆解 MoE：单个 Token 如何经过专家层

671B 参数的模型，每个 token 只激活约 37B，省下的究竟是什么？原文沿着一个 token 穿过 Mixture of Experts（MoE，混合专家）层的路径，拆开了路由、专家计算、结果合并，以及背后的通信和负载均衡。

它最有用的结论是：MoE 能把总参数容量和单次计算量部分分开，但活跃参数少，不代表显存需求低、响应速度快。理解这点，才能看懂模型名字里的数字，也能识别原文几处过度简化的说法。

一个 token 进来，究竟走了哪条路

原文讨论的 MoE，替换的是 Transformer 中的前馈网络 FFN，而 Attention、归一化、残差连接和输出头仍然共享。标准模块可以简写为：

Attention → Add & Norm → FFN → Add & Norm

原来每个 token 都经过同一个 FFN，现在改成经过路由器挑中的几个专家。这里的「专家」依然是 FFN，不是独立对话模型，也没有人工分配的岗位。

第一步，路由器对所有专家打分。它通常是一个线性投影，把长度为 d_model 的 token 向量，变成 num_experts 个分数：

router_logits = x @ W_router^T

以原文给出的 Mixtral 8x7B 为例，d_model=4096、num_experts=8，路由权重约 32K 参数。它的任务只是决定计算交给谁，参数量很小，并且与专家一起训练。

第二步，经过 softmax 得到概率，再取 top-k。原文用下面这行表示选择两个专家：

topk_probs, topk_indices = topk(probs, k=2)   # e.g., [0.62, 0.38], [3, 7]

需要看清这一行的边界：topk 只负责选取，并不会自动完成原文前面提到的重新归一化。如果要让选中权重之和为 1，还需要对应处理。

第三步，选中的专家各自计算，输出按路由权重加权求和，再回到残差路径。对这个 token 来说，没被选中的专家不执行 FFN 计算。

MoE 的稀疏，发生在专家计算这一步，路由器仍然要对候选专家打分。

原文最后用「每次选 1–2 个专家」概括整个架构，也不够严谨。它自己的 DeepSeek-V3 例子就是 256 个路由专家中选 top-8，另有 1 个始终工作的共享专家。

省了计算，为什么显存和延迟还会吃紧

MoE 节约的是每个 token 经过全部专家时本来需要的计算量，全部专家的权重却依然存在。

Mixtral 8x7B 不能直接算成 56B，因为 Attention 等部分共享。原文给出的总参数约 47B，bf16 权重约占 90 GB；降到 4-bit，纯权重规模约 24 GB。这些数字可以帮助估算容量，却不能直接当作完整服务的显存预算，还要算量化元数据、运行时缓冲区和 KV cache。

原文列出「两张 H100 或四张 A100-80GB」作为部署配置，但没有交代 H100 显存规格、上下文长度、并行方式和吞吐目标，因此不能据此推导最低配置。

「所有专家必须同时驻留显存」也说得太绝对。追求性能时通常希望如此，但从架构上看，可以使用卸载或分层存储，代价是额外的数据搬运和等待。

计算之外还有调度。

真实系统一般会按专家整理 token，让同一专家的输入形成连续批次，集中执行矩阵乘法，再把结果放回原位置。专家分布在不同 GPU 上时，这会涉及 all-to-all 通信，所以 NVLink、InfiniBand 和批量大小都会影响效率。原文提到 Megablocks、DeepSpeed-MoE、vLLM，强调的就是这部分工程工作。

不过，张量并行本身不等于跨卡专家分发；是否需要这种通信，要看专家具体放在哪里。

DeepSeek-V3 的 671B-A37B、原文所列 Nemotron 3 Ultra 的 550B-A55B，分别描述总参数与活跃参数规模。活跃参数并不是完整延迟模型：通信、权重读取、调度和缓存开销，都不能从这个数字直接读出来。共享 Attention 也不能简单理解为被排除在活跃参数之外。

选模型时，总参数看容量，活跃参数看计算规模，实际延迟仍要测。

专家会不会各司其职，先看路由有没有失衡

如果 90% 的 token 都被送到专家 0，这个专家会成为瓶颈，其他专家则难以获得充分训练。于是，MoE 不仅需要「选对专家」，还需要避免计算长期挤在少数专家上。

原文介绍了两种做法。

一种是在训练目标里加入辅助损失：

L_aux = α * N * Σ (f_i * p_i)

其中，f_i 是分配给专家 i 的 token 比例，p_i 是这个专家在批次中的平均路由概率，α 通常取 0.01–0.1。它鼓励分配更均衡，但不应理解成每个批次都会达到严格的 1/N。

另一种是动态调整专家偏置：过载专家的偏置下降，后续更难入选。原文把这条路线关联到 DeepSeek-V3，并与 Expert Choice 放在一起讲，但两者不能直接视为同一种机制；偏置究竟影响选择分数还是最终合并权重，也需要看具体实现。

分配均衡之后，专家会不会自然变成「代码专家」「数学专家」？原文的回答比较克制：可能出现聚类，但职责大量重叠，同一专家在不同层也可能处理不同模式，token 位置同样会影响路由。

因此，不能靠提示词稳定「唤醒代码专家」。

共享专家则提供了一条始终执行的公共路径：每个 token 都经过它，再叠加路由专家的输出。原文用下面的表达式说明这一点：

output = shared_expert(x) + Σ routed_expert_i(x)

要看的是 shared_expert(x)：它不参与「选中才算」的稀疏过程。原文将 DeepSeek-V3、Nemotron 3 Ultra 和 OLMoE 并列为例，但没有提供结构出处，这份名单不能直接当作已核实的模型配置表。

我的判断

这篇最值得保留的是计算路径：共享 Attention、路由评分、top-k、专家分发、加权合并。它能解释为什么模型容量可以很大，而每个 token 的专家计算仍然有限。

但原文的数字推导不能照单全收。它用 Llama-3-70B 的 8192 → 28672 → 8192、80 层说明 FFN 很重，并写出每层约 186M 参数；这个数字与给出的结构对不上。按其 SwiGLU 代码中的三个投影计算，应为 3 × 8192 × 28672，约 705M 参数。文中的 2 × d_model × d_hidden 也不能直接代表这段三投影实现。

同样，专家隐藏维度缩为四分之一、每次选两个，并不足以单独推出「相同计算获得约四倍总参数」，还需要明确专家数量和比较口径。

应用建议也要保留条件。「dense 32B 经常胜过 100B-A12B MoE」没有给任务、量化方式和对照数据，只能看作经验判断。微调部分推荐给所有线性层包括 router 加 LoRA，也没有提供验证；把 MoRA 直接解释成 Mixture of LoRAs，则存在术语混淆，不能直接据此选方案。

原文没有展示一组自己的部署实验。它更适合作为架构入门，而不是硬件采购表或微调操作手册。

能拿来做什么

• 做本地 AI 编程助手选型时，同时记录总参数、活跃参数、量化格式和实际显存占用，再用相同代码任务比较首 token 延迟、生成速度与结果质量。
• 用 Node 接入自托管推理服务时，把并发和上下文长度带进压测。短请求的交互延迟，与批量请求的吞吐量，应分别观察。
• 准备部署 MoE 时，检查 vLLM、SGLang 或 TensorRT-LLM 对目标模型的具体支持，再决定并行方式和硬件配置，不能只看框架是否宣称支持 MoE。
• 微调前先明确要训练哪些专家和路由层，并检查训练 token 的专家分布。把全量线性层 LoRA 当作候选方案，通过验证集判断收益。