Expert Parallel 和 Tensor Parallel 在 MoE 推理里有什么本质区别？

Tensor Parallel 会切分每个专家的权重，而 Expert Parallel 更强调把完整专家分布到不同设备上，再通过 token dispatch/combine 完成跨卡路由。两者也可以组合使用。

什么时候应该开启 EPLB？

先观察真实流量下的专家负载分布、最热 rank、All-to-All 延迟和 GPU 利用率。只有持续存在明显专家倾斜且尾延迟受其影响时，再评估 EPLB 和冗余专家。

DeepEP 能直接解决专家负载不均吗？

不能。DeepEP 主要优化 MoE 的 dispatch/combine 通信；专家负载不均仍需要路由策略、EPLB 或冗余专家处理。通信优化和负载均衡是两个不同层次的问题。

MoE 推理部署生产实战：用 Expert Parallel、EPLB 与 DeepEP 治理专家倾斜与跨卡通信

MoE（Mixture-of-Experts）上线后，很多人发现瓶颈并不在计算量本身，而转向两类更隐蔽的问题：专家倾斜与 All-to-All 通信。本文结合 vLLM、TensorRT-LLM 和 DeepEP，梳理 Expert Parallel、EPLB 与冗余专家在生产环境的落地方法，并给出一套可执行的分阶段部署与监控思路。

背景：参数稀疏，不代表推理链路天然轻量

MoE 把传统 Dense FFN 替换为多个专家，由 Router 为每个 token 选择 Top-K 专家。它的优势是总参数量可以很大，但单个 token 只激活部分专家。

问题在于，生产系统并不只计算“激活参数量”。当专家被分散到多块 GPU 甚至多个节点后，每一层 MoE 都会发生两类关键动作：

Dispatch：按照 Router 结果，把 token hidden states 发送到承载目标专家的 rank。
Combine：专家计算完成后，再把结果送回原来的 token 流。

这会把 MoE 推理从单纯的 GEMM 问题，变成 计算 + 专家路由 + All-to-All 通信 + 负载均衡 的联合问题。

更棘手的是，训练阶段“总体均衡”并不意味着生产流量一定均衡。真实请求可能集中在某些语言、领域或任务类型上，使部分专家持续变热。此时即便平均 GPU 利用率不低，最热 rank 仍可能成为同步路径上的 straggler，最终体现为 TPOT 抖动和尾延迟上升。

核心原理一：Expert Parallel 解决的是专家如何摆放

Tensor Parallel 与 Expert Parallel 的差异

在 MoE 层中，TP 与 EP 处理权重的方式不同：

Tensor Parallel：把每个专家的权重继续切到多个 GPU，因此每个 GPU 都持有所有专家的一部分权重。
Expert Parallel：更接近“按专家切分”，一个 rank 持有部分完整专家，token 根据 Router 决策被发送到对应 rank。TensorRT-LLM 当前支持 TP、EP 以及混合 ETP 三种 MoE 执行方式。

vLLM 的 Expert Parallel Deployment 把 EP 与 Data Parallel 结合起来。当启用 --enable-expert-parallel 后，MoE Expert Layers 会跨 EP ranks 分片，而 Attention Layers 仍根据 TP/DP 配置采用复制或切分策略。

一个重要的工程判断是：EP 的收益来自更好的专家 locality，但代价是 token dispatch/combine 对跨 GPU 通信更加敏感。

一个基础部署示例

vllm serve deepseek-ai/DeepSeek-V3-0324 \
  --tensor-parallel-size 1 \
  --data-parallel-size 8 \
  --enable-expert-parallel

这类配置不应直接照抄到生产。上线前至少需要验证：模型是否能放入目标显存、Attention 层采用什么并行方式、EP group 是否跨节点，以及网络路径是否具备稳定的低时延和高带宽。

核心原理二：专家倾斜真正拖慢的是最热 rank

MoE Router 是数据相关的。不同请求会产生不同的专家命中分布，因此系统需要关注的不是“平均每个专家收到多少 token”，而是 负载分布的尾部。

可以把一个 MoE step 的风险粗略理解为：

step_time ≈ max(rank_compute_time + dispatch_time + combine_time)

只要一个 rank 长期承载多个热门专家，它就可能成为全局慢点。此时继续增加平均算力，未必能降低尾延迟。

生产监控建议至少加入以下维度：

每层、每专家的 token 命中数；
每个 EP rank 的 token 数与最大/平均比；
expert balancedness；
dispatch / combine latency；
All-to-All 带宽和跨节点 RDMA 利用率；
每个 rank 的 GPU SM 利用率与等待时间；
TPOT P95/P99 与专家热度变化的相关性。

只看整机 GPU Utilization 很容易掩盖问题，因为“某一块卡打满、另外几块卡等待”在平均值上可能仍然看起来正常。

核心原理三：EPLB 用冗余专家换负载均衡

vLLM 提供 Expert Parallel Load Balancer（EPLB）。它会持续收集专家负载统计，并周期性调整物理专家在 EP ranks 上的映射。

对于长期热门的逻辑专家，还可以增加 Redundant Experts。同一个逻辑专家拥有多个物理副本后，热门 token 可以被分摊到不同设备，从而降低单 rank 热点。

vllm serve deepseek-ai/DeepSeek-V3-0324 \
  --tensor-parallel-size 1 \
  --data-parallel-size 8 \
  --enable-expert-parallel \
  --enable-eplb \
  --eplb-config '{"window_size":1000,"step_interval":3000,"num_redundant_experts":2,"log_balancedness":true}'

这里最容易出现的错误是把 EPLB 当成“开启即提速”的开关。EPLB 的冗余专家需要额外显存。vLLM 文档明确提醒：如果环境本身显存紧张，或者 KV Cache 空间已经是核心约束，冗余专家可能得不偿失。换句话说，EPLB 实际上是在做 显存换热点缓解。

生产上更合理的顺序是：

先确认存在持续的专家倾斜；
评估倾斜对 TPOT、All-to-All 和最热 rank 的影响；
再逐步增加冗余专家；
每次调整都同时观察负载均衡收益和 KV Cache/显存损失。

核心原理四：DeepEP 优化的是 dispatch/combine，不是 Router

DeepEP 是面向 Expert Parallel 的高性能通信库，重点提供 MoE dispatch/combine 的 All-to-All GPU kernels。

它把不同阶段的通信需求区分开来：高吞吐路径更适合大 token batch 的场景；低延迟路径则面向 latency-sensitive inference。当前 DeepEP V2 还对 Expert Parallel 实现进行了重构，并转向更轻量的 NCCL Gin backend。

必须区分两个问题：

问题层次	决定因素	解决手段
专家负载不均	流量、Router、专家放置和副本策略	路由策略、EPLB、冗余专家
跨卡通信成本高	All-to-All 实现、NVLink/RDMA、拓扑、计算通信重叠	DeepEP 等通信优化

DeepEP 主要解决后者。即便通信 kernel 很快，如果 30% 的 token 长期都被打到某几个专家上，最热 rank 依然会拖慢系统。

工程落地：按五个阶段推进

第一阶段：先做无 EPLB 的基线

建立 TP、DP、EP 的基础拓扑，固定模型、输入长度分布、并发和请求集。至少记录：TTFT P50/P95/P99、TPOT P50/P95/P99、requests/s、output tokens/s、dispatch latency、combine latency、expert max/avg load、per-rank GPU utilization。

如果没有基线，后面无法判断性能变化来自 EPLB、通信 backend，还是 workload 本身变化。

第二阶段：单独压测 All-to-All 通信路径

对多节点 EP，网络不是普通依赖，而是模型执行路径的一部分。DeepEP 官方仓库特别讨论了 InfiniBand、RDMA、流量隔离和 adaptive routing。生产环境应把 EP 通信和其他大流量任务区分开观察，避免存储同步、checkpoint、其他 NCCL collective 抢占同一网络路径。

如果单节点表现正常、多节点 TPOT 突然恶化，优先排查 dispatch/combine 和网络，而不是先怀疑模型算子。

第三阶段：用真实请求观察 Expert Heatmap

不要只用随机 token 或均匀 synthetic workload 判断专家是否均衡。专家热度通常与真实语料分布相关。

建议按业务切片输出 Expert Heatmap：

中文 / 英文；
代码 / 通用问答；
长输入 / 短输入；
高并发 / 低并发；
高价值租户 / 普通租户。

如果不同业务流量对应完全不同的热门专家，那么 EPLB 的统计窗口就不能设置得过长，否则它只能追踪“历史热点”。

第四阶段：再打开 EPLB，并控制重平衡频率

EPLB 需要两个时间尺度：统计窗口和重平衡周期。窗口过短，热点统计容易被瞬时流量噪声污染；窗口过长，系统跟不上工作负载变化。重平衡过于频繁同样会产生专家重映射成本。

生产调参不要追求 balancedness 指标本身最好看，而应验证：

最热 rank 是否降温；
TPOT P99 是否下降；
dispatch/combine 是否变稳定；
重平衡事件是否引入新的 latency spike；
额外专家副本是否挤压有效 KV Cache。

第五阶段：把拓扑与 EPLB 配置作为发布物版本化

MoE 服务的发布物不应只有 model name 和 image tag，还应至少记录：

model: deepseek-v3-0324
tp_size: 1
dp_size: 8
expert_parallel: true
all2all_backend: deepep_low_latency
eplb:
  enabled: true
  window_size: 1000
  step_interval: 3000
  redundant_experts: 2
network_profile: ib-ep-v2

这样发生回退时，才能判断问题究竟来自模型版本、EP 拓扑、通信 backend、EPLB 参数还是网络环境。

适用场景

这套方法适合以下情况：

DeepSeek-V3/R1、Qwen MoE、Mixtral 等 MoE 模型的多 GPU 部署；
单机表现正常，但跨节点后 TPOT 或吞吐明显恶化；
GPU 平均利用率不低，却存在明显 rank 间不均衡；
线上工作负载具有明显领域倾斜，热门专家长期集中；
希望从纯 TP 部署转向 EP 或混合 ETP，并需要建立可观测基线。

如果模型本身是 Dense 架构，则 Expert Parallel 和 EPLB 没有适用对象。

常见误区

误区一：MoE 每个 token 只激活少量参数，所以一定比 Dense 更容易服务。 激活参数减少不等于通信成本减少。MoE 会额外引入 Router、dispatch 和 combine，跨节点 EP 尤其依赖网络。

误区二：训练时负载均衡，线上就不需要 EPLB。 训练数据分布、在线请求分布和时间窗口都可能不同。DeepSeek-V3 的训练阶段采用辅助损失无关的负载均衡策略，但生产系统仍需要针对真实流量观察专家热度。

误区三：冗余专家越多越好。 冗余专家占用真实显存。复制过多会压缩 KV Cache 和 batch 空间，最终可能抵消负载均衡收益。

误区四：换成 DeepEP 就能解决专家倾斜。 DeepEP 优化通信效率，EPLB 处理专家布局和热点复制。两者解决的是不同层次的问题。

误区五：只看平均 GPU 利用率。 MoE 更应该看 rank 间分布。平均 70% 可能意味着一块卡接近满载、另一块卡大量等待。

上线检查

上线前建议逐项确认：

FAQ

Expert Parallel 和 Tensor Parallel 应该二选一吗？ 不需要。TensorRT-LLM 支持 TP、EP 和混合 ETP。实际选择取决于专家大小、GPU 数量、通信拓扑和目标 workload。对于大 MoE，常见思路是让专家层采用 EP，同时 Attention 层仍使用适合自己的 TP/DP 方式。

EPLB 的判断标准应该是什么？ 不是“balancedness 越高越好”，而是专家热点是否真正造成尾延迟或吞吐问题。如果 expert max/avg load 很高，但 TPOT 和 dispatch/combine 仍稳定，就不应为了指标漂亮而盲目增加冗余专家。

DeepEP 的低延迟模式一定适合所有阶段吗？ 不一定。MoE Prefill 和 Decode 的 token 规模与延迟目标不同。应根据目标 workload 压测不同通信 backend，而不是只依据名称选择“low latency”。

参考资料

vLLM — Expert Parallel Deployment：https://docs.vllm.ai/en/latest/serving/expert_parallel_deployment/
vLLM — EPLB State：https://docs.vllm.ai/en/v0.25.0/api/vllm/distributed/eplb/eplb_state/
NVIDIA TensorRT-LLM — Expert Parallelism：https://nvidia.github.io/TensorRT-LLM/1.3.0rc8/legacy/advanced/expert-parallelism.html
DeepSeek — DeepEP：https://github.com/deepseek-ai/DeepEP
DeepSeek-V3 Technical Report：https://arxiv.org/abs/2412.19437