我们走完了前 30 篇——从认知到训练到部署到应用。从这一篇开始进入前沿与思考篇（第 31-35 篇），把视野推到 LLM 工程的最前线。

第一站：MoE。

MoE（Mixture of Experts，混合专家）是 2024-2026 年大模型架构上最重要的创新。它解释了三个看似矛盾的现象：

• DeepSeek V3 用 557 万美元做出顶级模型

• Mixtral 8x22B 推理成本接近 39B 模型

• 671B 模型推理速度比 70B Dense 还快

这些"反直觉"的事实背后，全是 MoE 的功劳。

如果你做过相关工作，下面这些问题应该不陌生：

• MoE 模型参数那么大，推理为什么反而快？

• 「671B 总参数 / 37B 激活」这个数字到底是什么意思？

• 为什么 Mixtral 用 8 个专家，DeepSeek 用 256 个？

• MoE 部署比 Dense 难在哪？

• 我自己业务该不该上 MoE？

读完本文你将能：

1. 理解 MoE 的数学原理和稀疏激活机制

2. 区分 Mixtral / DeepSeek / Qwen MoE 的架构差异

3. 评估 MoE 在你业务的工程成本与收益

4. 部署 MoE 模型的关键技巧

5. 判断未来 MoE 的方向

我们开始。

一、MoE 的核心思想：稀疏激活

1.1 Dense 模型的「浪费」

传统 Dense 模型每生成一个 token，所有参数都参与计算。

Llama-3-70B：每个 token → 70B 参数全过一遍 推理算力：~140 GFLOPS / token（2N）

但 LLM 的能力分布是极不均匀的——某些参数处理"数学"、某些处理"代码"、某些处理"诗歌"。对一个具体问题来说，大部分参数其实是闲置的。

1.2 MoE 的简单想法

能不能让模型按需激活部分参数？

MoE 的核心：把 FFN 层拆成多个"专家"（每个专家是一个小 FFN），每个 token 只选 K 个专家激活。

Dense FFN： input → [W1: d × 4d] → [activation] → [W2: 4d × d] → output ↑ 70% 的参数都在这里 MoE FFN： input → Router 决策 → 选 K 个专家 ├─ Expert 1: 小 FFN ├─ Expert 2: 小 FFN ├─ ... └─ Expert N: 小 FFN ↓ 加权合并 output

关键数学：

• 总参数：N 个专家 × 每专家参数

• 激活参数：K × 每专家参数（K << N）

• 计算量：约等于激活参数 × 2

1.3 直观例子

DeepSeek V3 的配置：

总专家数：256（每层）+ 1 个共享专家 每 token 激活：8 个 + 1 个共享 = 9 个 激活比例：9/256 ≈ 3.5% 总参数：671B 激活参数：37B 推理计算：约 37B 模型水平 推理质量：接近 671B 水平

这就是 MoE 的魔法——用 671B 的容量，跑 37B 的速度。

1.4 为什么 MoE 这么强

核心权衡：

• 算力省（训练 + 推理）

• 显存贵（要装所有专家）

• 复杂度高

这就是为什么 MoE 在大规模场景（大集群训练 + 服务端推理）有压倒性优势，但单机部署受限。

二、MoE 的核心机制

2.1 路由（Router / Gate）

每个 token 怎么决定用哪 K 个专家？靠一个小的Router 网络：

# 简化版伪代码 classMoELayer(nn.Module): def__init__(self, d, num_experts, top_k): self.router = nn.Linear(d, num_experts) # 路由网络 self.experts = nn.ModuleList([FFN(d) for _ inrange(num_experts)]) self.top_k = top_k defforward(self, x): # x: [batch, seq, d] # 1. 路由打分 logits = self.router(x) # [batch, seq, num_experts] scores = softmax(logits, dim=-1) # 2. 选 top-K topk_scores, topk_idx = scores.topk(self.top_k, dim=-1) topk_scores = topk_scores / topk_scores.sum(-1, keepdim=True) # 重新归一化 # 3. 计算每个专家的输出 output = torch.zeros_like(x) for k inrange(self.top_k): expert_idx = topk_idx[..., k] # 这个 token 选的第 k 个专家 weight = topk_scores[..., k] # 把 token 分发给对应专家 for i inrange(self.num_experts): mask = (expert_idx == i) if mask.any(): output[mask] += weight[mask].unsqueeze(-1) * self.experts[i](x[mask]) return output

2.2 负载均衡问题

朴素 MoE 训练会出现专家不均衡：

某些专家"红"——每个 batch 都被选 1000 次 某些专家"死"——一个 batch 都没人选 → 永远训不动 → 浪费参数

经典解法：Auxiliary Loss

def aux_loss(routing_probs, num_experts): # 鼓励每个专家被均匀使用 avg_prob = routing_probs.mean(dim=[0, 1]) # 每个专家的平均概率 # 与均匀分布的差异 loss = num_experts * (avg_prob ** 2).sum() return loss total_loss = main_loss + 0.01 * aux_loss(...)

通过这个 loss，路由会主动均衡专家使用。

DeepSeek V3 的创新：Auxiliary-loss-free 负载均衡

DeepSeek V3 发现传统 auxiliary loss 会伤害主任务。他们用一种带 bias 的路由替代：

# 每个专家有个 bias，根据使用情况动态调整 # 用得多的专家 bias 降低（被选概率降低） # 用得少的专家 bias 提升 router_logits = self.router(x) + self.bias # 关键 # 不需要在 loss 里加 aux # 训练循环外异步更新 bias def update_bias(expert_usage_counts): for i, count in enumerate(expert_usage_counts): if count > avg + threshold: self.bias[i] -= step elif count < avg - threshold: self.bias[i] += step

效果：主任务质量更好，专家仍然均衡。这是 V3 的关键创新之一。

2.3 训练 vs 推理的视角差异

训练时：

• 不同 token 路由到不同专家

• 用 all-to-all 通信跨卡聚合

• 关注负载均衡

推理时：

• batch 内不同 token 可能选不同专家

• KV Cache 与专家路由要协同

• 关注专家亲和性（同样的 prompt 经过相同路径 → 缓存命中）

三、MoE 的演进史

3.1 早期：Switch Transformer / GShard（2020-2021）

Google 在 2020-2021 提出了大规模 MoE 训练框架：

• Switch Transformer：每 token 只选 1 个专家

• GShard：通用 MoE 训练框架

特点：

• 专家数：几十到几百

• 用 TPU 训练

• 主要在 Google 内部用

局限：训练不稳、效果一般，没在开源社区流行。

3.2 Mixtral 8x7B（2023.12 Mistral）

第一个被广泛采用的开源 MoE。

配置：

8 个专家 × 每个 7B 参数 = 47B 总参数 每 token 激活：2 个专家 = 13B 激活参数

贡献：

• 证明 MoE 在开源社区可用

• 推理效率类似 13B 模型，质量接近 70B

• 引发 MoE 开源浪潮

局限：

• 专家粒度太粗（每个专家 7B）

• 路由简单（无负载均衡损失）

3.3 DeepSeek MoE（2024.01）

DeepSeek 推出了细粒度 MoE理念：

传统 MoE：少量大专家（如 Mixtral 8 × 7B） DeepSeek：大量小专家（如 64 × 较小的 FFN）

两大创新：

3.3.1. 细粒度专家

原 Mixtral：8 个大专家，每次选 2 个 DeepSeek：64 个小专家（参数总量相同），每次选 8 个

好处：

• 更细致的能力分配

• 不同 token 组合可能性更多

• 专家利用率更均衡

3.3.2. 共享专家（Shared Expert）

引入 1-2 个永远激活的"共享专家"：

每 token = K 个动态选的专家 + 1 个固定共享专家

好处：

• 共享专家负责通用能力

• 动态专家专攻特化能力

• 知识分配更合理

3.4 DeepSeek V2 / V3（2024.05 / 12）

V2 引入MLA（Multi-head Latent Attention）——大幅压缩 KV Cache。
V3 把这些技术做到极致：

DeepSeek V3 配置： - 61 层 Transformer - 每层 256 个路由专家 + 1 个共享专家 - 每 token 激活 8 个 + 1 个共享 = 37.5B 参数 - 总参数 671B - 上下文 128K

V3 的工程创新汇总：

1. MLA：KV Cache 压缩

2. 细粒度 MoE：256 个专家

3. Auxiliary-loss-free 负载均衡：不伤害主任务

4. DualPipe：双向流水并行，bubble ~0%

5. FP8 训练：业界首次大规模成功

6. MTP（Multi-Token Prediction）：训练时每次预测多个 token

这一组合让 V3 用 557 万美元达到顶级开源效果，重新定义了"性价比"。

3.5 其他 MoE 玩家

关键趋势：

2026 年，几乎所有顶级大模型都是 MoE 或 MoE 变体。

四、DeepSeek 工程创新深拆

DeepSeek V3 是 MoE 工程化的集大成者。我们详细看几个核心创新。

4.1 MLA：KV Cache 的"魔法压缩"

传统 attention 的 KV Cache 公式：

KV_cache = 2 × batch × seq × num_layers × num_kv_heads × head_dim × dtype

MLA 的做法：

把 K 和 V 压缩成一个低维隐变量（latent），用时再"解压"。

class MultiHeadLatentAttention(nn.Module): def__init__(self, d, kv_lora_rank): # 压缩矩阵：d → kv_lora_rank self.W_DKV = nn.Linear(d, kv_lora_rank) # 解压矩阵：kv_lora_rank → d_h * num_heads self.W_UK = nn.Linear(kv_lora_rank, d_h * num_heads) self.W_UV = nn.Linear(kv_lora_rank, d_h * num_heads) defcache(self, x): # 只缓存压缩后的 latent returnself.W_DKV(x) # [batch, seq, kv_lora_rank] defreconstruct(self, latent): k = self.W_UK(latent) v = self.W_UV(latent) return k, v

收益：

• KV Cache 显存压缩4×+

• 几乎无精度损失（甚至略好）

• 长上下文友好

4.2 DualPipe：bubble 接近 0 的流水并行

第 6 篇我们讲过 PP 的 bubble 问题。DeepSeek 提出DualPipe：

传统 1F1B： GPU 0: [F][F][F][F] [B][B][B][B] ← 中间有 bubble GPU 1: [F][F][F][F][B][B][B][B] GPU 2: [F][F][F][F][B][B][B][B] GPU 3: [F][F][F][F][B][B][B][B] DualPipe： GPU 0: [F→][F→][F→][F→][←B][←B][←B][←B] GPU 3: [←B][←B][←B][←B][F→][F→][F→][F→] 前向和反向相向而行

核心思想：前向计算和反向计算同时双向进行，让通信和计算 overlap。

效果：

• bubble 时间 ~0

• 端到端训练效率 +30%

4.3 FP8 训练

DeepSeek V3 是业界第一个大规模成功 FP8 训练 671B 模型。

挑战：

• 数值范围小（FP8 表达精度极限）

• 梯度爆炸 / 消失风险

• 不同层敏感度不同

V3 的解法：

# 不是所有层都 FP8——按敏感度分级 # 高敏感：保 BF16（如 attention、norm） # 中敏感：FP8 + per-tile scaling # 低敏感：纯 FP8 # Per-tile scaling 是关键 def fp8_matmul(A, B): # 把 A、B 切成 tile（如 128×128） # 每个 tile 单独算 scaling factor # 在 FP8 上做乘法 # 累积时用 FP32 ...

收益：训练算力节省 30-50%。

4.4 MTP（Multi-Token Prediction）

传统训练：每个位置只预测下 1 个 token。
MTP：每个位置预测下 N 个 token（如 2-4 个）。

# 标准 Transformer logits = lm_head(hidden) # [batch, seq, vocab] loss = ce(logits, labels[:, 1:]) # 预测下一个 # MTP logits_1 = lm_head_1(hidden) # 下 1 个 logits_2 = lm_head_2(hidden) # 下 2 个 loss_1 = ce(logits_1, labels[:, 1:]) loss_2 = ce(logits_2, labels[:, 2:]) total_loss = loss_1 + 0.3 * loss_2

收益：

• 数据利用率提高

• 训练信号更密集

• 与投机解码协同（V3 推理时可以用 MTP head 做 draft）

五、MoE 部署的工程挑战

第 20 篇我们讲过 EP（Expert Parallel）。这里更深入。

5.1 显存大但激活少

部署 DeepSeek V3：

模型权重 FP8：671 GB KV Cache（MLA 压缩后）：相对较小 激活：基于 37B 计算

关键矛盾：

• 显存压力：必须装下所有专家

• 算力轻松：只激活 37B 算力即可

意味着：

• 不能用消费级 GPU（显存不够）

• 但 H100 集群跑得很轻松（算力够）

5.2 EP（Expert Parallel）

第 20 篇讲过。MoE 的最佳并行策略：

EP=8：256 个专家分到 8 张卡，每张卡 32 个专家 每次推理： Token → Router → 选 8 个专家 → 通过 All-to-All 把 token 发到对应卡 → 各卡跑自己负责的专家 → All-to-All 回收结果

通信特点：

• All-to-All 是最复杂的通信模式

• 跨节点 All-to-All 是性能杀手

• DeepEP（DeepSeek 开源的 All-to-All 库）专门优化这个

5.3 专家负载实时监控

部署 MoE 必须监控：

每个专家的激活频次 是否有"热"专家（被频繁调用 → 卡热） 是否有"冷"专家（几乎不用 → 浪费显存） 专家亲和性（相似 prompt 是否路由一致）

如果某个专家被严重过载，整个集群就被这一个专家拖累。

5.4 推理框架的 MoE 支持

SGLang 对 DeepSeek MoE 优化最好——团队和 DeepSeek 紧密合作。

5.5 部署 DeepSeek V3

# SGLang 部署 DeepSeek V3（32 卡） python -m sglang.launch_server \ --model-path deepseek-ai/DeepSeek-V3 \ --tp 8 \ --ep 4 \ --dist-init-addr master:50000 \ --nnodes 4 \ --node-rank 0 \ --enable-deepep \ # 启用 DeepEP All-to-All --quantization fp8 \ --enable-mtp \ # MTP 加速解码 --port 30000

关键参数：

• --ep 4：专家并行 4 路

• --enable-deepep：DeepEP 专用通信

• --enable-mtp：MTP 投机解码

六、MoE vs Dense：业务决策

6.1 什么场景用 MoE

✅ 推荐：

• 大模型 + 服务端推理：MoE 算力优势明显

• 极致性价比训练：DeepSeek 路线

• 能力上限要求高：MoE 容量大

• 有大集群：能跑 EP

❌ 不推荐：

• 单机部署 / 端侧：显存装不下

• 极简运维：MoE 工程化复杂

• 业务低并发：MoE 在并发场景才划算

• 快速迭代验证：Dense 训练更稳定

6.2 不同规模团队的选择

6.3 MoE 模型选型

主流 MoE 模型对照（2026 中）：

七、MoE 的未来方向

7.1 更细粒度

Mixtral：8 专家 DeepSeek V3：256 专家 未来：1024+ 专家？

更细粒度的趋势继续——但工程挑战陡增。

7.2 动态专家数

不同 token 用不同数量的专家——简单 token 用少专家、复杂 token 用多专家。正在研究。

7.3 MoE + 推理模型

推理模型 + MoE 是 2026 年的热门组合：

• DeepSeek R1：基于 V3 的 MoE 做 RL 推理

• 未来：thinking tokens 路由到推理专用专家

7.4 异构 MoE

不同专家有不同的架构——某些是 attention 专家、某些是 MLP 专家、某些是检索专家……目前在研究。

7.5 端侧 MoE

把"用得少的专家"放到 CPU/SSD，只 GPU 装"热"专家。潜力巨大但工程挑战大。

八、避坑

8.1 坑 1：以为 MoE 自动更好

症状：换成 MoE 后效果反而下降。

对策：MoE 训练复杂度高，没有足够算力 / 数据，MoE 可能不如 Dense。

8.2 坑 2：专家负载严重不均

症状：80% 流量打到 20% 的专家。

对策：

• 训练时用 DeepSeek 的无 aux loss 方案

• 推理时监控并做 expert affinity

8.3 坑 3：跨机 All-to-All 慢

症状：跨机部署 MoE 性能暴跌。

对策：

• 用 InfiniBand

• 启用 DeepEP / SGLang 优化

• 节点内 EP 优先

8.4 坑 4：忘了显存代价

症状："37B 激活我用 1 张 H100 应该够吧"——结果根本装不下。

对策：MoE 显存按总参数算，不是激活参数。

8.5 坑 5：迷信"必须用 DeepSeek"

症状：业务很简单，但非要上 DeepSeek V3。

对策：

• 简单业务：Qwen3-32B Dense 就够

• 中等业务：Mixtral 或 Qwen3-MoE-A22B

• 极致场景：DeepSeek V3

九、结语：MoE 是大模型工程的「分水岭」

读完本文你应该明白：

• MoE 用稀疏激活打破"参数=算力"的束缚

• DeepSeek V3 是 MoE 工程化的集大成者：MLA + 细粒度 MoE + DualPipe + FP8 + MTP

• MoE 显存大但算力省——显存是部署唯一难点

• EP（专家并行）+ DeepEP是 MoE 部署标配

• 2026 年所有顶级模型几乎都是 MoE

• 端侧 / 单机仍是 Dense 主场

参考文献：

MoE 架构深度解析：DeepSeek、Mixtral 背后的稀疏化魔法