生产环境中的 MoE 模型：稠密模型基准测试所掩盖的服务特性

基准测试告诉过你，运行 Mixtral 8x7B 的成本只有 46B 稠密模型的一半。但它们没告诉你的是，它需要的 GPU 显存大约是同等稠密模型的 8.6 倍，其响应延迟会因令牌命中哪个专家而产生剧烈波动，并且在中等批处理大小下会以难以诊断的方式崩溃。专家混合（MoE）架构已成为几乎所有前沿模型——DeepSeek-V3、Llama 4、Gemini 1.5、Grok、Mistral Large——的中流抵柱，但适用于稠密模型的推理假设在 MoE 上会以微妙且昂贵的方式失效。

如果你打算私有化部署或将流量路由到这些模型，以下是稠密模型直觉可能出错的地方。

内存悖论：为什么“高效”的 MoE 模型反而消耗更多显存

MoE 的核心承诺是计算效率：在推理时，每个令牌仅激活模型参数的一小部分。Mixtral 8x7B 总共有 46.7B 参数，但每个令牌仅激活约 12.9B。DeepSeek-V3 总共有 671B 参数，但每次前向传播仅激活约 37B。这听起来很划算。

问题在于，GPU 显存并不关心哪些专家是激活的。所有的专家权重都必须保留在显存中，以便路由网络可以将任何令牌发送给任何专家，而不会因为加载权重而产生延迟峰值。你需要在显存中支付全部参数量的成本，而计算上只需支付一小部分。在实践中测算，MoE 模型所需的 GPU 显存大约是具有同等计算需求的稠密模型的 8.6 倍。

对于 DeepSeek-V3 来说，这意味着在为激活或 KV 缓存分配任何空间之前，你面临的是大约 671B × 2 字节 (BF16) ≈ 1.34TB 的权重存储。这就是为什么在许多生产配置中，推理一个 37B 激活参数的模型仍然需要 32 路 H100 GPU 集群。营销材料中的“激活参数”数量并不是决定你硬件预算的数字——总参数量才是。

路由器网络本身也会增加容易被忽视的开销。在每个 Transformer 层，门控网络都会对所有专家运行线性投影和 softmax，以计算路由概率。对于像 DeepSeek-V3 这样拥有 256 个专家的模型，这种路由计算是不容忽视的，与同等的稠密前向传播相比，每个令牌大约增加 5-8% 的延迟。

延迟波动：稠密基准测试忽略的行为

稠密模型的延迟是可预测的。对于给定的序列长度和批处理大小，计算图是固定的。但 MoE 的延迟则不然，因为每个请求激活的专家集合是输入令牌分布的函数，而不是批处理配置的函数。

在 32 个请求的批处理中，每个请求都可能激活不同的专家子集。某些请求会触发负载较重的专家；另一些请求则可能被路由到使用较少的专家。这种离散的路由决策会导致同一批次中不同请求的计算时间产生真实差异，并且在深度 MoE 堆栈中，这种差异会层层累加。等待批次中最慢专家的请求会成为你的尾部延迟。

这产生了一种在离线基准测试中不会出现的故障模式：即使在负载稳定的情况下，你的 P99 延迟也明显差于平均值，而且它与序列长度的相关性也不像稠密模型延迟那样清晰。除非你正在跟踪延迟分布而非仅仅是平均值，否则为稠密模型调优的生产监控将完全忽略这一点。

具体到 Mixtral 8x7B，测得的单请求延迟约为 6.45ms/token，在单个并发请求时的首字延迟为 643ms。这对于交互式使用来说处于合理范围内，但分布情况比平均值更重要。

批处理大小敏感度：反转的优化曲线

对于稠密模型，批处理（Batching）几乎总是有益的。批次中的每个额外请求都会分摊加载模型权重的固定成本。标准的运维经验是：在显存允许的范围内运行最大的批次。

MoE 模型以一种特定的方式反转了这一点。小批次（1-16 个请求）才是 MoE 真正兑现其计算效率承诺的地方。当批次较小时，批次中的请求很可能会路由到重叠的专家子集，因此你实际上是在重复使用完整模型的一小部分。这种稀疏激活是名副其实的稀疏。

随着批处理大小增长，不同的请求会激活不同的专家。如果有 8 个专家和 32 个请求，整个批次的组合激活模式开始覆盖大部分专家池。当你达到大批处理大小时，你实际上已经加载了几乎整个模型——重现了稠密模型的内存访问模式——但还增加了路由计算和专家分发的额外开销。计算效率优势消失了，而内存效率低下的问题依然存在。

这意味着 MoE 的最佳批处理策略与稠密模型不同。像 vLLM 这样的框架建议为 MoE 工作负载设置更高的最大批次令牌数（MoE 为 32,768，稠密为 16,384），但批处理大小与吞吐量之间的关系是非单调的，你必须根据你的流量模式进行经验性测量。成本效益的批处理大小平衡点通常比你根据稠密模型经验预期的要低。

专家负载不均衡：沉默的 GPU 杀手

训练时的负载均衡和生产环境中的负载均衡是不同的问题。在训练过程中，辅助损失（auxiliary losses）会防止 token 路由坍缩到单个专家。但在生产环境中，实际的流量分布会产生持续的“热点专家”——这些专家由于专注于你工作负载领域中频繁出现的模式，从而接收了不成比例的 token。

当专家并行将专家分散到不同的 GPU 上时，热点专家会导致托管它们的节点出现 GPU 资源超限。这些 GPU 在峰值负载下会运行过热并导致显存溢出。而其他 GPU 上的冷门专家则处于空闲状态，等待热点专家所在的 GPU 完成计算。由于在前向传播完成之前，每个 GPU 都必须完成其专家计算，因此同步停顿（synchronization stall）会传播到整个 batch。

这种失效模式的扩展性极差。更大规模的专家并行配置会让更多的 GPU 暴露在这种不均衡中。特定领域（如客户支持、代码生成、医疗问答）的生产工作负载比通用基准测试更加倾斜，这意味着基于基准测试得出的推理配置会低估专用部署中的峰值显存需求。

缓解方案确实存在，但增加了操作复杂度：

• 静态专家放置 (EPLB)： 预先计算哪些专家在历史上是热点，然后将热点专家和冷门专家放置在同一个 GPU 上，使每个节点处理均衡的组合。
• 在线 EPLB： 根据运行时监控持续将专家重新分配到 GPU，以适应流量模式的变化。
• 专家复制 (Expert Replication)： 将热点专家广播到多个 GPU。这增加了显存使用，但消除了热门专家的路由瓶颈。

这些方案都不是预配置好的。在调整它们之前，你需要根据专家激活模式对流量进行性能分析（profile）。

KV 缓存：大小相同，行为各异

MoE 模型不会带来意外的一个领域是原始 KV 缓存存储。缓存大小的计算公式与稠密模型相同——它取决于 batch size、序列长度、注意力头数和每个头的维度，这些在 MoE 和稠密架构之间都没有变化。对于使用多头潜变量注意力（如 DeepSeek-V3）的模型，KV 缓存实际上比标准 MHA 小得多。

行为的分歧点在于 KV 缓存压力与专家显存压力之间的相互作用。由于所有专家权重必须保持常驻，在分配 KV 缓存之前，你的 GPU 显存预算就已经很紧张了。在显存耗尽之前的有效最大 batch size 会比运行具有相似激活参数量的稠密模型时所暗示的总显存量要低。

激活内存（Activation memory）又增加了一层复杂性。对于 MoE 来说，激活内存随着 token 数量、Transformer 层数以及每个 token 对应的专家数量而增长——而不仅仅是稠密模型中的前两项。在高并发环境下，这会导致显存扩展变得难以从基本原理进行建模，并且往往会让那些使用稠密模型思维模型进行容量规划的团队感到意外。

并行策略的差异

稠密模型默认使用张量并行（TP）：将每个权重矩阵拆分到多个 GPU 上，每个 GPU 都参与每一次前向传播计算。这非常有效，因为计算图是同构的。

MoE 模型需要不同的分解方式。主要有两种选择：

张量并行 (TP)： 将每个专家的权重矩阵拆分到多个 GPU 上。每个 GPU 持有每个专家的一部分，并接收所有专家的所有 token。通信开销较低，但你没有利用稀疏激活结构。

专家并行 (EP)： 将完整的专家分配给单个 GPU。每个 GPU 持有专家的一套完整子集，并且只接收路由到其专家的 token。显存局部性更好，且利用了稀疏性，但负载不均衡成为了首要问题。

大多数大型 MoE 模型的生产配置采用混合模式：专家内部使用张量并行（以提高计算效率），结合跨 GPU 组的专家并行（以实现显存分布）。针对你的硬件和流量特征正确配置这种混合模式，比配置稠密模型的并行策略要复杂得多，而且它需要基于性能分析进行调整，而不是靠经验法则。

框架支持：现状与差距

好消息是，在 2024 至 2025 年间，框架对 MoE 的支持有了显著提升。

vLLM 为 Mixtral 及类似架构增加了 FP8 推理支持，与 BF16 相比，token 间延迟（inter-token latency）提升了多达 1.6 倍。DeepSeek-V2 和 V3 的支持在 2025 年落地，并针对共享专家架构进行了优化。FP8 MoE 需要 Triton 2.3.1+，这意味着这不仅是一个配置项，还需要升级依赖项。

TensorRT-LLM 增加了专家并行负载均衡器 (EPLB)，用于动态专家到 GPU 的重分配，并改进了混合并行配置。针对高 EP 配置的高级内核（kernel）工作仍在不断演进中。

SGLang 已成为大规模提供 DeepSeek 系列模型服务的首选框架。它支持多种专家并行后端（DeepEP、Mooncake、Ascend FuseEP），支持全面的量化（FP8、FP4、INT8、MXFP4），并证明了投机性 MoE 优化可带来 1.68–1.97 倍的吞吐量提升。

不太好的消息是：投机性专家选择——即在路由决策做出之前预测 token 将路由到哪些专家，然后预取权重——在大多数部署中仍处于研究阶段。论文显示，根据上下文预测 token 到专家的路由准确率可达 89%，在投机解码过程中通过专家预算分配可提升 10-30% 的吞吐量，但这些尚未进入主流服务框架。

MoE 推理服务的实用清单

如果你正在生产环境中部署基于 MoE 的模型，在开始前你需要调整心理预期：

• 内存预算基于总参数量，而非激活参数量。 无论激活率如何，每个专家都必须驻留在 VRAM 中。请据此进行规划。
• 预期 P99 延迟波动不会与 P50 同步。 要监测延迟分布，而不仅仅是平均值。沿用稠密模型的告警阈值会导致告警疲劳或遗漏真实问题。
• 在选择 TP 和 EP 或确定 EPLB 配置之前，先针对你的实际流量进行专家激活模式分析。 基于基准测试的配置通常假设路由分布是均匀的。
• 通过实测验证批大小（batch size）与吞吐量的关系。 MoE 的成本最优批大小通常比你预期的稠密模型要小。两者的关系是非线性的。
• 在为全部专家权重预留空间后，再分配 30-40% 的 GPU 显存用于 KV 缓存 + 激活值。 显存计算很快就会变得非常吃紧。
• 在框架支持的情况下使用 FP8 量化。 对于 Mixtral 级别的模型，FP8 已经具备生产可用性，1.6 倍的延迟提升（1.6×）足以抵消依赖升级的成本。

核心问题在于 MoE 是为训练经济性而优化的 —— 即在给定的质量目标下，每个 token 的 FLOPs 更少。推理服务的经济性则需要另一套分析体系，涵盖总内存、路由开销、批处理行为和负载分布。稠密模型的基准测试无法体现这些推理特性，这就是为什么团队往往在部署后而非规划阶段才遇到意外情况。

---

MoE 架构不会消失。主流实验室正致力于将其用于前沿模型的开发，社区也在积极推动其托管。正确配置推理服务需要将 MoE 视为一个完全不同的推理问题，而不仅仅是一个“参数量高效版”的稠密模型问题。