1. 一个反直觉的结论：参数多两倍，推理反而更快

先抛一个可能让不少刚入坑大模型的朋友意外的结论：在同样“干活”的推理成本下，MoE（Mixture of Experts，混合专家模型）这种架构的参数量可以做到同等能力的传统密集模型的两到三倍，但单次前向传播的激活参数量却可能只有后者的三分之一。换句话说，模型“总内存”大了，可每次推理真正动用的部分却更少。这个特性正是 MoE 在大模型时代重新翻红的核心原因。

我们平时说的“大模型”，绝大多数是 Transformer 架构下的密集模型（Dense Model）。密集的意思是：无论输入什么 token，模型每一层所有参数都会参与计算。一个 7B 的密集模型，前向传播就要把 7B 参数全部算一遍。这带来一个很直接的矛盾——想提升模型能力，最朴素的路径是加参数量，但参数量一旦加上去，训练和推理的算力开销是线性甚至超线性上涨的。大模型训练成本天文数字，推理成本也高居不下，于是大家开始琢磨：有没有可能让参数变多，但计算量不跟着变多？

MoE 的思路说白了很“社会”：与其让一个全能的通才处理所有事，不如养一群各有专长的专家，每来一个请求，先由一个“调度员”判断该找谁，然后只让少数几个专家干活。对应到模型里，这个“调度员”就是门控网络（Router / Gating Network），“专家”就是若干结构相同但参数独立的 FFN（前馈网络）子层。Transformer 的 FFN 层被替换成一组专家，每个 token 只激活其中 Top-K 个，这就是混合专家模型最朴素的形态。

我第一次真正理解 MoE 的价值，是在对比同代际 Dense 和 MoE 模型的推理表现时。同样跑在单张 A100 上，一个 8 专家的 MoE 模型，虽然总参数比同层宽的 Dense 模型多了一截，但因为每个 token 只激活 Top-2 专家，K 个专家加门控的激活参数反而只是全量参数的一小部分。这就实现了“花小钱办大事”。当然，魔鬼藏在细节里，比如专家变多以后显存怎么放、通信怎么压、负载怎么均衡，这些后面慢慢展开。

这篇东西适合谁看？我默认读者已经了解 Transformer 的基本结构，知道 QKV、FFN 这些概念大概是干什么的。如果你只是听说过 MoE 这个词，想搞清楚它和大模型能力、DeepSeek-V3、Mixtral 这类模型到底是什么关系，那本文也能给你一个相对完整的图景：从门控网络的数学原理，到训练时的负载均衡与专家坍缩，再到工程部署和微调中的注意点，一次讲透。

2. 最小工作单元：门控网络 + 专家组的协同逻辑

2.1 FFN 被替换成专家列表后发生了什么

回顾一下 Transformer 中一个标准 Transformer Block 是怎么工作的：输入向量先过 Attention 层，让 token 之间交换信息，然后过一个 FFN 层，逐位置对每个 token 独立做非线性变换。FFN 通常由两层线性变换加一个激活函数组成，公式大致是：

[ \text{FFN}(x) = \text{GeLU}(xW_{in})W_{out} ]

这个 FFN 层的特点是：它不关心 token 之间的交互，只对单个 token 的表示做“加工”。这个“加工”过程有没有必要让所有参数都参与？MoE 的回答是：没必要。我们可以准备 N 个结构相同的 FFN，每个 FFN 叫一个“专家”，输入 token 经过门控网络打分，选 Top-K 个专家，让这些专家分别加工，再把结果加权合起来。

这个替换的直接后果是：Transformer Block 从“一个全能的 FFN”变成“一组专业分化的 FFN”。理论上这些专家可以各自学到不同的知识模式，比如有的专家擅长处理代码 token、有的擅长处理自然语言，有的可能对数学公式敏感。注意，这种“分工”不是我们显式指定的，而是训练过程中自动涌现的。你不去定义专家 A 专门处理代码，但负载均衡约束和数据的统计特性会让不同专家自然分化。

2.2 稀疏激活是 MoE 的灵魂

MoE 有一个关键词必须理解透彻：稀疏激活（Sparse Activation）。对比密集模型每个 token 激活全部参数，MoE 模型每个 token 只激活少量专家。这里的“稀疏”不是指数据稀疏，而是指计算路径稀疏——每个 token 走的是整个参数空间里的一条狭窄路径。

为什么稀疏激活有价值？两个层面：

第一，训练效率。同样的 FLOPs（浮点运算量）预算下，稀疏模型可以拥有比密集模型多得多的总参数量。大家都按 FLOPs 来定训练成本，那在相同算力下，MoE 模型总参数更大，理论上能记住更多知识、拟合更复杂的函数，从而获得更好的性能。

第二，推理效率。推理时我们关心的是每个请求实际消耗多少算力，而不是模型占了多少显存。因为每个 token 只激活 Top-K 个专家，实际计算量远小于总参数量对应的计算量。

一个直观类比：一家大型综合医院，“总参数”相当于医院所有科室、所有医生、所有设备加起来的总规模；“激活参数”相当于你来医院看病时实际会接触到的科室数量和检查项目。总医院规模很大，但你一次门诊只需要一个科室的几个医生。MoE 想做到的是：总规模庞大，单次服务的开销却控制在合理范围。

2.3 门控网络的数学结构

门控网络的作用是为每个 token 生成一个专家打分分布。它的输入就是 token 在 Transformer Block 里的隐藏表示 (x)，输出是长度为 N（专家数量）的得分向量。

一般形式是：

[ g(x) = \text{Softmax}(x \cdot W_g) ]

其中 (W_g) 是一个可学习的投影矩阵，形状是 ([d_{model}, N])，也就是把隐藏维度映射到专家维度。Softmax 把得分变成概率分布，表示“这个 token 应该以多少权重找某个专家”。

但这里有一个关键细节：Softmax 之后直接取 Top-K，还是 Softmax 之前取 Top-K？不同实现略有不同。Switch Transformer 的做法是只取得分最高的那个专家（Top-1），且门控值直接用 Softmax 后的概率；Mixtral 那类实现取 Top-2，用 Softmax 后两个概率做归一化加权。DeepSeek-V3 又进了一步，用 sigmoid 替代 softmax，因为 sigmoid 每个专家得到的分值是独立的，互不影响，更适合在细粒度专家选择下做 Top-K 选取。

门控网络本身参数量不大，但它非常关键。它决定每个 token 走哪条路，这个“路由决策”直接决定了模型能否用好它的巨额参数。如果门控网络学砸了，比如所有 token 都只去找同一两个专家，那 MoE 就退化成了一个小密集模型，其余专家全都闲在那儿，白白占显存。

3. 从公式到代码：Top-K 选择与负载均衡的完整推导

3.1 取 Top-K 而非 Top-1 的理由

为什么大多说取 Top-2 而不是只取 Top-1？早期 Shazeer 2017 年的论文就试过多种组合，发现 Top-2 比 Top-1 效果更稳定。原因也不难理解：Top-1 把所有鸡蛋放在一个篮子里，门控网络一旦对某些 token 判断失误，这个 token 就完全没有其他专家的信息可以补充。Top-2 增加了一个冗余通道，即使主专家不合适，次专家还可能补位；同时 Top-2 的梯度信号也更丰富，两个专家可以一起被优化。

更深一层，Top-2 相当于让 token 的表示在两个专家的输出表示之间做一个“软插值”，这比单个专家的刚性变换更有表达力。实验维度上，Switch Transformer 虽然主推 Top-1 以减少路由计算和通信，但那是为了在超大规模下压通信成本，本质上做了权衡。对大多数应用场景，Top-2 是更稳的选择，尤其微调阶段，Top-2 对下游任务的适配也更平滑。

3.2 一个最小示例带你走一遍路由计算

我写一个简化的 PyTorch 风格代码，让你看清从输入到输出的完整路径：

import torch import torch.nn.functional as F # 假设隐藏维度 128，8 个专家，每个专家 FFN 内部维度 256 D_MODEL = 128 N_EXPERTS = 8 TOP_K = 2 FFN_DIM = 256 # 模拟一个 batch 里 4 个 token，每个 token 的隐藏表示 x = torch.randn(4, D_MODEL) # 门控投影矩阵 W_gate = torch.randn(D_MODEL, N_EXPERTS, dtype=torch.float64) # step1: 计算路由得分 raw_scores = x @ W_gate # [4, 8] # step2: 取 Top-K 索引和得分 top_k_scores, top_k_indices = torch.topk(raw_scores, TOP_K, dim=-1) # step3: 对得分做 softmax，得到组合权重 weights = F.softmax(top_k_scores, dim=-1) # [4, 2] # 专家的 FFN 参数（演示简化版） # experts_ffn[i] 表示第 i 个专家的两层线性变换 expert_outputs = torch.stack([ torch.tanh(x @ torch.randn(D_MODEL, FFN_DIM)) @ torch.randn(FFN_DIM, D_MODEL) for _ in range(N_EXPERTS) ]) # [8, 4, 128]，注意我为了演示把所有专家都算了一遍，实际工程中只会计算被选中的专家 # step4: 按 Top-K 索引聚合输出 out = torch.zeros_like(x) for b in range(4): for j in range(TOP_K): expert_idx = top_k_indices[b, j] out[b] += weights[b, j] * expert_outputs[expert_idx, b]

这段代码流程拆开看就四步：投影打点、取 Top-K、Softmax 归一化、按权聚合。实际工程里专家 FFN 不会像上面这样无差别全算，而是通过索引拿到被选中的专家 ID，只用那几个专家的参数做计算，否则稀疏激活就名存实亡了。

3.3 辅助负载均衡损失：让专家都有饭吃

只靠路由打分，训练时极易出现“富者愈富、贫者愈贫”的马太效应：少数几个专家得到的 token 多、梯度大，学得越好，门控网络就越倾向于选它们；那些一开始没被选中的专家梯度稀疏，学得差，更不会被选。最后模型容量被浪费，专家群体退化。所以必须给训练目标加一个辅助损失（Auxiliary Loss），惩罚路由分布的不均匀程度。

最经典的做法来自 Shazeer 2017，后来 GShard 和 Switch Transformer 陆续简化，脑感一个比较通用的形式是：

[ L_{balance} = N \cdot \sum_{i=1}^{N} f_i \cdot P_i ]

其中 (f_i) 是专家 i 实际被选中的 token 比例（分数），(P_i) 是门控网络分配给专家 i 的平均路由概率（平均分数）。这个损失的直觉是：如果每个专家的选中比例 (f_i) 都接近 (1/N)，且平均路由概率也接近 (1/N)，那么损失最小；如果某个专家被过度选中，(f_i) 远高于平均，损失就会大，反向传播会推着门控网络降低对它的路由概率。

计算方式举个例子：一个 batch 有 1000 个 token，8 个专家，Top-2。统计每个专家被选中的次数，除以总 token 数，得到 (f)。同时把所有 token 路由给该专家的平均概率算出来，得到 (P)。两个向量逐元素相乘再求和，乘以 N，这就是该 batch 的负载均衡损失。把这个损失乘以一个系数加到总损失上，系数通常很小（比如 0.01），但足以让路由分布趋于均匀。

还有一个细节：辅助损失加在哪个层面？早期做法加在每层。DeepSeek-MoE 后来分了两级负载均衡损失，一个作用于专家层面，一个作用于“专家组”层面，因为细粒度专家切分后需要保证不同组之间的使用率也均衡，否则即便专家整体使用率均衡，也可能出现某个组的专家被集中使用而其他组闲置的情况。

4. 从 Shazeer 到 DeepSeek：MoE 这条技术线的演进逻辑

4.1 起点：2017 年的 Sparsely-Gated MoE

MoE 不是新东西，1990 年代就有混合专家模型的研究，但现代大模型语境下的稀疏 MoE 起点普遍追溯到 2017 年 Google Brain 的 Shazeer 等人发表的《Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer》。

这篇文章做了件在当时很“炸裂”的事：把 LSTM 的隐层替换成 MoE 层，专家数量搞到上千个，总参数达到 1370 亿，但每次前向传播只激活少数专家，计算量控制在了合理范围。论文里验证了稀疏激活在大规模下的收益，也把负载均衡问题摆上了台面。

有意思的是，这篇论文提出的辅助损失包含一个“重要性”项和一个“损失”项，用于同时优化路由分布和专家使用的均衡。虽然原始实现和后来主流简化版本略有差异，但它奠定了 MoE 的基本框架：门控 + 专家 + 负载均衡约束。

4.2 GShard 与 Switch Transformer：规模化工程的应用

2018 年到 2020 年之间，Google 把 MoE 引入了机器翻译任务。GShard 这篇工作第一次在 Transformer 上做了大规模 MoE 的工程化尝试：通过切分模型（sharding）在不同设备上放置不同专家，并实现了 All-to-All 通信来把 token 路由到正确的设备。在 6000 亿参数量级别上跑机器翻译，效果超过了当时同规模密集模型。

Switch Transformer 则做了大胆的简化：只取 Top-1 专家，而不是 Top-2。这样每个 token 只走一个专家的 FFN，路由计算和 All-to-All 通信量直接减半。论文里展示了一个很有意思的实验：同样的训练算力下，Switch Transformer 的稀疏版本比同规模的密集 Transformer 训练速度快 4 到 7 倍，因为稀疏版本实际 FLOPs 更少。这是 MoE 第一次在纯工程和效率维度上给了社区很强的说服力。

这些工作的意义在于把 MoE 从“可以这样设计”推进到“工业级可以用”。GShard 引入了专家并行（Expert Parallelism）的实施范式，Switch 则把训练技巧稳定化：比如专家容量（expert capacity）的概念——每个专家在一个 batch 中最多处理多少个 token，超出的 token 被丢弃或旁路走残差连接。这个机制直接控制了显存上界，避免了路由不均衡导致某些专家 batch 内处理不过来。

4.3 新一代 MoE：Mixtral、DeepSeek-MoE 的精细化改进

到了 2023 到 2024 年，MoE 的演进进入精细化阶段。Mistral 发布的 Mixtral 8x7B 是最广为人知的代表作之一：8 个专家，每个专家参数量约 7B，但推理时只激活 Top-2，实际激活参数量约 13B。名字里的“8x7B”很容易让人误以为总参数是 56B，其实这是被反复误解的点——确切说总参数量大约是 47B（有些参数是共享的），关键是实际计算的活跃参数只有约 13B。

DeepSeek-MoE 则带来了两个非常有意思的创新点：

一是细粒度专家切分（Fine-Grained Expert Segmentation）。不再用少数几个大专家，而是把专家切得更小、数量更多。比如把 FFN 中间维度从 4096 拆成 16 个维度为 256 的小专家，然后从里面选 6 到 8 个激活。好处是每个 token 的组合路径数量指数级增加，模型表示能力更强，而且每个专家的参数规模小了，单个专家的利用率更高。

二是共享专家隔离。DeepSeek-MoE 额外设置了一个始终激活的共享专家（Shared Expert），不参与 Top-K 选择，每来一个 token 它都要过一遍。共享专家负责处理那些所有 token 都需要的通用知识，选中的专家专注处理差异化知识。这个设计很巧妙：通用知识如果分散在各个专家里，每个专家都得花参数去存一遍，很浪费；单独拎出来共享，则专家们可以把容量全部留给专门化知识。

从 Shazeer 到 DeepSeek 的演进，你可以看到一个清晰的趋势：MoE 不再是“换一个 FFN 层”这么简单，而是从门控设计、专家粒度、负载均衡、并行通信到训练技巧全面推进的系统工程。

5. 专家分化与专家坍缩：训练 MoE 最容易翻车的两个环节

5.1 负载不均衡为什么是大问题

前面提到的辅助损失如果系数没调好，或者干脆忘了加，会发生什么？我见过的一个真实场景是：训练日志里 Loss 一直正常下降，但某个专家处理了 batch 里 40% 的 token，而另外两个专家几乎零 token。最初一两百步内看不出问题，但越往后越严重——每当你以为模型在学会处理新的数据模式时，真正学到东西的可能只是那 40% 的“热门专家”，其余专家的参数在梯度空间中几乎原地踏步。

这种不均衡还会产生工程上的连锁反应。在专家并行的配置下，每个专家所在设备处理 token 数是动态的，热门专家所在设备可能长时间满负载、通信瓶颈集中，而冷门专家设备空闲，整个集群利用率被拉低。更关键的是，热专家设备上的显存 buffer 要预留足够空间，否则超出容量后 token 会被丢弃，而丢 token 的行为会进一步干扰训练分布。

处理手段我按优先级排一下：

第一，确认辅助损失确实加进了总损失，建议在训练初期把系数稍微调大一点（比如 0.01），稳定后可以下调。训练初期路由分布最容易走偏，早干预比晚干预有效得多。

第二，监控每个 expert 的 token 利用率。不要只看 loss curve，要实时看每个 expert 的 token 计数，低于阈值的专家要警惕。很多框架（比如 Megatron-LM、FairScale）有现成的统计工具。

第三，如果发现用户自定义的负载均衡损失太复杂，至少保证用最简单的 N * sum(f_i * P_i) 形式，别在这上面过度设计。

5.2 专家坍缩（Representation Collapse）为什么发生

专家坍缩是比负载不均衡更隐蔽的问题。它描述的现象是：大部分专家的输出趋向于相同或接近，专家们“名存实亡”，没有真正分化。负载不均衡是“有的专家忙死、有的专家闲死”，专家坍缩则是“大家都忙，但干的是同一件事”。

为什么会发生？根本原因在于门控网络和专家的联合训练容易收敛到一种简并解。门控网络可能发现一个超级简单的策略：对所有 token 分配几乎相同的权重，这样一来模型的行为就退化成专家输出的平均，相当于一个大号的密集 FFN。某些情况下，这种退化解在训练初期 loss 下降还不慢，于是模型就赖在里面不肯出来了。

这个问题的难度在于：单纯靠负载均衡损失不能完全解决，因为即使 token 均匀分配，专家之间的输出仍可能趋同。真正有效的办法通常从两方面入手：

一是初始化。专家参数用差异化初始化，避免全部从同一分布采样后变成对称。实践中有人用不同随机种子初始化不同专家，也有人给不同专家设置略微不同的缩放系数，破对称性。

二是辅助损失 + 专家分化的中间监督。不是直接监督专家输出，而是通过辅助损失计算不同专家对不同类型 token 的亲和度矩阵，观察是否形成差异化。如果长期无分化，可以尝试调大辅助损失的系数，或者调整 Top-K 数量，增加竞争压力。

5.3 训练稳定性其它注意点

MoE 训练对学习率很敏感。门控网络通常需要相对较小的学习率，因为它的参数更新直接影响路由分布，变化太大会导致路由震荡。行业内一种常见做法是给门控网络设置一个单独的学习率缩放系数，比如主参数 lr=3e-4，门控 lr=1e-4，或者用 warmup 阶段让路由先稳定下来再开始优化主模型。

还有精度问题需要注意。MoE 训练中路由权重和专家输出经常出现量级差异大，如果开启混合精度训练，要小心 FP16 下门控层梯度下溢。实践中 BF16 是更稳的选择，或者对门控层的梯度做 clip。

6. 工程落地视角：显存、并行策略与推理优化

6.1 显存估算：总参数不等于总占用

很多人看到“Mixtral 8x7B”就想：47B 参数，是不是要上多机才能推理？这个误解需要拆掉。显存占用确实按总参数量算：47B 参数用 FP16 存储，约 94GB，这是模型加载后占用的显存。但推理时的计算量只和激活参数（约 13B）相关。换句话说，MoE 对显存容量要求高，但算力要求相对低一点。

所以“8x7B 能不能在我的 24GB 显卡上跑”？不能直接加载完整 FP16 版本，但可以使用量化：4bit 量化后约 24GB 左右，勉强能放在 24GB 卡上。或者用 MoE 专用的 offload 策略：把不常用的专家参数放在内存或硬盘，按需加载。因为每次只激活两个专家，offload 的成本比密集模型 offload 低很多。

我建议所有想做 MoE 部署的人，先算清楚三个数：总参数（影响显存）、激活参数（影响算力）、专家数量（影响通信）。不要笼统说“这个模型太大”，要具体到“总参数多少、激活多少、我的带宽能不能扛住通信”。

6.2 Expert Parallelism 与 All-to-All 通信

MoE 训练和大模型部署绕不开并行策略。Dense 模型常见的并行是数据并行（Data Parallel）和张量并行（Tensor Parallel），而 MoE 引入了特有的一层：专家并行（Expert Parallelism）。

逻辑很简单：N 个专家分布在 M 个设备上，每个设备放 N/M 个专家。每个 token 经门控网络选出的专家如果不在本设备上，就需要把 token 的 hidden state 发送到目标设备，进行计算后再把结果传回来。这个过程的通信模式是 All-to-All——每个设备都可能向其他任意设备发送数据，而不是像数据并行那样只和相邻设备通信。

All-to-All 通信是 MoE 可扩展性的最大物理瓶颈之一。专家数量越多、分布越分散，通信量越大。通信和计算的比例决定了 MoE 的实际吞吐。几个实践中常用的优化手段：

第一，尽量在同一台机器内的多卡之间做专家并行，用 NVLink 而不是跨机 InfiniBand，通信延迟和带宽完全不同量级。

第二，对 batch 做精心调度。如果一个 batch 内所有 token 恰好大多路由到本机专家，通信就少。这做不到完美，但可以通过调整数据排布、控制 batch 大小来改善。

第三，近年来很多框架引入了“组内共享专家 + 组间稀疏路由”的思路。DeepSeek-V3 的做法是设备受限路由：每个 token 只能路由到有限设备子集上的专家，从根本上限制 All-to-All 通信的范围。这在超大集群中效果显著。

6.3 推理优化：专家缓存、路由批处理与投机解码

部署 MoE 推理有若干专门优化手段：

第一，专家参数缓存。连续推理时，热门专家被反复调用，可以常驻显存；冷门专家参数在硬盘/内存中，需要时换入。因为每次只用到少数专家，这种策略比 Dense 模型 offload 要高效得多。我自己测试过，对一批测试集做统计后把 top 常用专家常驻，可以显著降低推理延迟波动。

第二，路由批处理。普通 Transformer 推理的 batch 可以直接并行；MoE 推理要额外按专家分组：先把一个 batch 中所有 token 的路由结果统计出来，相同专家的 token 拼在一起过 FFN，减少专家 FFN 的调用次数。这个分组过程需要额外的显存 buffer，但整体吞吐提升明显。

第三，投机解码（Speculative Decoding）用于 MoE 也有效，但要注意：草稿模型预测 token 时，后面验证阶段 MoE 的前向计算无法完全复用草稿模型的特征，收益打折。MCSD（Multi-Candidate Speculative Decoding）等方法专门优化了 MoE 中多候选验证的场景。如果业务场景对延迟敏感，建议实测，不要盲目相信所有投机解码在 MoE 上都等效于 Dense 模型的收益。

还有一个容易忽略的点：推理时路由计算的随机性要关闭。门控网络在训练时可能有 dropout，推理时务必关掉，否则同样的输入可能路由到不同专家，导致输出不稳定，这在线上服务是大忌。

7. 微调 MoE 时最容易踩的五个坑

7.1 全量微调 vs LoRA

MoE 模型微调的第一问题是：更新哪些参数？密集模型通常可以全量微调，但 MoE 总参数巨大，全量微调成本高，而且极易破坏门控网络学到的路由分布——微调时若是把全部专家的参数都更新，很可能改变专家之间的相对能力分布，导致路由摆动。

实际项目里我比较推荐两个策略：

策略一：冻结专家参数，只微调门控 + Attention + 共享专家。适用于下游任务和源领域差异不大的场景，成本低，而且不会破坏路由的全局均衡。

策略二：LoRA 微调。给所有专家或部分专家挂了 LoRA 适配器，训练时只训练低秩矩阵。这个方式的好处是灵活，可以在多个下游任务间切换（用完一个任务切换 LoRA 权重），而不需要为每个任务复制全部专家参数。

有一件事要特别提醒：如果 MoE 模型的 LoRA 微调不够稳定，可以先尝试只对共享专家和 Attention 做 LoRA，专家 FFN 不动。许多场景下效果不差，显存和训练时间省一大截。

7.2 路由崩塌在微调阶段的特殊性

微调数据分布和预训练往往差异大。比如预训练数据是通用网页文本，微调数据是法律文书，那么大量 token 的路由行为可能集中在部分专家上。没有辅助损失或者微调时优化器只优化部分参数，路由分布漂移会更剧烈。

处理方式：微调阶段也要维护负载均衡监控，尤其前几个 step 要看路由分布是否急剧偏向某几个专家。如果出现偏移，可以考虑调高辅助损失权重，或者把学习率调低。还有一招：微调初期可以暂时固定门控网络参数，等专家参数适应了新数据分布再解开，这样路由能维持一个相对稳定的基础。

7.3 量化专家的精度陷阱

MoE 部署基本绕不开量化。AWQ、GPTQ 这类方法在 Dense 模型上已经很成熟，但在 MoE 上要小心两个点：

第一，专家之间重要性不同。有些专家承担了远多于其他专家的 token，量化误差对它们影响更大。实际做法是：按专家被路由的频率做敏感度加权，高流行命中的专家用更小量化粒度或保持 FP16，冷门专家可以压到 4bit。

第二，门控层千万别过度量化。门控网络参数量不大，但它的输出精度直接影响路由决策。如果门控层在量化后出现两个相近专家的打分翻转，模型输出可能突变。我见过部署踩坑：FP16 模型推理正常，4bit 量化后有个别 token 的路由结果变化，导致输出质量断崖下降。排查下来就是门控层量化粒度太粗。建议门控层用 FP16 或 8bit，专家层可以 4bit。

7.4 上下文长度的耦合问题

MoE 模型对长上下文的支持，经常有人误以为和 Dense 模型完全一样。实际上，长上下文意味着每个 token 都要做路由计算，路由本身是小开销，但长上下文下 Attention 的计算量增长占了主导，MoE 省 FFN 的优势会被掩盖。所以 MoE 模型处理超长上下文时，速度优势可能不如短 contextual 下明显。这是选型时容易忽略的一个事实。

7.5 如何用单卡试水 MoE

如果你只有一两张 GPU，想跑通 MoE 实验，可以考虑类似 Mixtral 8x7B 但做量化 + offload 的方案，或者选择更小的 MoE 模型，比如 Qwen 系列中的 MoE 变体。实在不行，自己实现一个迷你 MoE（用上面的简化代码）在单卡上做 toy task 实验，体会门控调整和负载均衡的手感，这比硬啃大模型的部署文档更能建立直觉。

8. 评估一个 MoE 模型值不值得用：三个关键指标

讨论 MoE 不能只看“参数量”这个单一数字。我总结了一套自己的评估框架，按重要性排序：

特别提醒：MoE 的 benchmark 分数（比如 MMLU、CEval）只能反映世代能力，不能反映工程部署的成本。业界经常看到某些 MoE 模型跑 benchmark 很漂亮，但实际推理时通信瓶颈拖累延迟，单卡根本跑不动，还不如一个 7B 密集模型来得爽快。所以评估一个 MoE 模型“值不值得用”，要把基准测试分数、显存规模、通信成本、推理延迟一起放进天平，而不是只看参数量或单项分数。

另外，同一个模型在不同硬件环境下的表现差异很大。比如在 8 卡 NVLink 互联的机器上，MoE 通信优势可以充分发挥；如果在多机千兆以太网的配置下，跨机 All-to-All 通信可能直接把收益吃光。我建议无论纸上评估做得再好，都要花一个下午跑一次真实的 batch 压测，观察吞吐和延迟曲线，再决定是否上生产环境。

根据我个人经验，把 MoE 用好，一半靠理解它的数学和训练机制，另一半靠对通信、显存调度、量化细节的工程手感。这两个部分缺一不可。如果你刚接触这个方向，我强烈建议从小规模 MoE 做起——哪怕只是一个把 FFN 换成 8 个专家的 toy Transformer，跑一个简单的语言建模任务，亲眼看看路由分布如何演化、不同专家怎么分化、负载均衡损失如何纠偏。把这个迷你实验玩熟了，再看 Mixtral 和 DeepSeek-V3 的实现，会轻松很多。