面向 DeepSeek 及其他 MoE 模型的 vLLM 专家并行部署
vLLM 专家并行是在 MoE 模型的专家层应拆分到多个 GPU 上、而非作为一个大型张量并行组处理时使用的部署模式。在当前 vLLM 中，开关为 --enable-expert-parallel。专家并行度通过张量并行 (TP) 和数据并行 (DP) 设置间接确定：vLLM 文档说明 EP_SIZE = TP_SIZE × DP_SIZE。
这一细节很重要。许多运行手册会寻找单独的“vLLM 专家并行大小标志”，然后尝试强制使用其固定版本中并不存在的标志。请先使用受支持的开关，在将要部署的确切镜像中检查 vllm serve --help，并根据经过测量的容量规划选择 TP/DP。
本操作手册涵盖从单节点 DeepSeek MoE 部署到多节点 vLLM 专家并行的安全路径，包括后端选择、专家负载均衡、验收测试和故障隔离。它面向 ML 和 AI 基础设施工程师，而非一键式演示。
版本说明：vLLM 的 MoE 内核、依赖项和 CLI 界面变化很快。以下文档化行为和命令已根据 2026 年 10 月 16 日的官方 vLLM 文档进行核查。请固定 vLLM 镜像，并在生产发布前针对该固定版本验证标志。
简要回答
| 问题 | 实用答案 |
|---|---|
| 什么启用了 vLLM 专家并行？ | 为受支持的 MoE 部署添加 --enable-expert-parallel。 |
| 如何选择 EP 大小？ | 在当前 vLLM 专家并行文档中，它计算为 TP × DP；请设置 --tensor-parallel-size 和 --data-parallel-size，而不是猜测 EP 大小标志。 |
| 会发生什么变化？ | MoE 专家层会在 EP rank 之间分片；注意力层仍遵循文档化的 TP/DP 行为。 |
| 何时应使用它？ | 当 MoE 模型、GPU 拓扑、通信互连和请求量足以证明分布式专家工作合理时。它不是适用于稠密模型的通用加速开关。 |
| 应从哪里开始？ | 从单节点、固定模型修订版本、固定流量追踪，以及不使用 EP 的基线开始。 |
官方 vLLM 专家并行部署指南是该功能的权威来源。它将专家并行描述为在 GPU 上分布 MoE 专家，通常与数据并行一起使用。
vLLM 专家并行实际改变了什么
MoE 模型会将每个 token 路由到众多专家网络中的一小部分。没有专家并行时，vLLM 文档化的 MoE 行为会跨 DP × TP 组成一个张量并行组。使用 --enable-expert-parallel 后，专家层改为使用专家并行，而注意力层保持其自身的 TP/DP 行为。
以一个具体拓扑为例，设 TP=2 且 DP=4：
| 组件 | 启用 EP 后的并行行为 |
|---|---|
| 专家层 | 一个跨越 8 个 rank 的 EP 组；专家分布在这些 GPU 上。 |
| 注意力层 | 4 个 DP 组中的每一个内部都有由 2 个 GPU 组成的张量并行组。 |
| 有效 EP 大小 | 2 × 4 = 8。 |
这就是为什么 vLLM 专家并行不能替代对注意力层、KV 缓存容量、请求并发性和网络拓扑如何协同配合的决策。它只是分布式服务设计的一部分。
有关哪种多 GPU 模式适合特定工作负载的更全面介绍，请参阅 vLLM 多 GPU 推理：张量并行与流水线并行设置。
vLLM 专家并行标志与“大小标志”问题
当前公开文档给出了规范的启用标志：
--enable-expert-parallel
文档还指出，专家并行大小由张量并行和数据并行大小计算得出：
EP_SIZE = TP_SIZE × DP_SIZE
因此，vLLM 专家并行部署文档中的模式是：
vllm serve <MODEL> --tensor-parallel-size <TP> --data-parallel-size <DP> --enable-expert-parallel
不要从旧 issue、内部封装器或其他服务栈中复制单独的 --expert-parallel-size 选项，并假定它适用于你的 vLLM 构建版本。应将“我的 EP 大小是多少？”视为一个拓扑问题：
- 选择可供一个服务组使用的 GPU 和节点数量。
- 为注意力层分片和本地模型行为选择 TP。
- 为独立引擎容量和请求分发选择 DP。
- 为 MoE 层启用 EP。
- 在启动日志中确认计算出的进程拓扑，并运行负载测试。
vLLM serve CLI 参考是特定版本中各标志的最终权威。
部署前：就绪检查关卡
在将启动或吞吐量问题归咎于专家并行之前，请先完成这些检查。
| 检查项 | 验证内容 | 重要原因 |
|---|---|---|
| 版本 | 在每个工作节点上固定 vLLM 容器、CUDA 软件栈和模型修订版本。 | 混用镜像或 wheel 版本不匹配，可能会将拓扑问题变成难以诊断的内核错误。 |
| 模型适配 | 在选择 GPU 数量前，计算模型权重、KV 缓存、运行时工作区以及任何冗余专家所需的容量。 | EP 并不能免除内存规划。 |
| 依赖项 | 遵循当前 vLLM EP 内核的前置条件，包括文档要求的 DeepEP 和 DeepGEMM。 | 专家并行文档将这些明确列为前置条件。 |
| 网络互连 | 在单个节点上验证 GPU 拓扑，并在首次生产请求前验证跨节点 GPU 通信。 | EP 会为每次 MoE 前向传播增加通信。 |
| 控制网络 | 明确指定主节点地址、端口可达性和 NIC 选择。 | 如果控制平面发现机制指向了错误的接口，即使数据平面正常也无济于事。 |
| 基线 | 在不使用 EP 的情况下记录延迟、吞吐量、错误率和 GPU 内存余量。 | 你需要能够对“EP 是否有帮助？”作出可比较的回答。 |
对于此检查项的内存部分，请使用 LLM GPU 内存需求指南，在预留更大规模的集群之前创建容量规划表。
让第一次实验保持简单
使用一个模型修订版本、一个已知分词器、一种请求组合、一个并发范围，以及一组固定的启动标志。避免在同一次测试中同时更改量化、缓存设置、硬件和 all-to-all 后端。干净的基线可以帮助你判断 vLLM 专家并行是否提升了有效吞吐量，还是仅仅转移了瓶颈。
单节点 DeepSeek MoE 部署
当前 vLLM 指南以 DeepSeek-V3-0324 作为单节点示例，采用单路 TP、八路 DP，并启用 EP：
vllm serve deepseek-ai/DeepSeek-V3-0324 --tensor-parallel-size 1 --data-parallel-size 8 --enable-expert-parallel
文档解释了其预期效果：注意力权重会在 DP rank 间复制，而专家权重会拆分到各个 GPU 上。它以配备八块 GPU 的 H200 或 H20 节点作为示例拓扑，并建议使用不同硬件的团队验证自身配置是否适配，而不要将该示例视为通用的容量承诺。
将该命令作为拓扑起点，而非直接复制粘贴的生产配置。在暴露端点之前：
- 确认服务器进入健康的就绪状态，且没有悄然回退到不同的内核路径。
- 使用已知提示词以及预期的 schema 或工具调用行为运行正确性测试。
- 先施加小规模稳定负载，再施加突发负载和长上下文样本。
- 将 p50 和 p99 首 token 时间、token 间延迟、输出吞吐量、内存余量和错误情况与非 EP 基线进行比较。
- 将启动命令、镜像摘要、模型修订版本、驱动版本和指标快照与基准测试结果一同保存。
如果你仍在构建周边 API 层，这份 vLLM 部署指南会单独介绍 OpenAI 兼容服务器路径，而不涉及 MoE 并行化决策。
根据工作负载而非习惯选择 all-to-all 后端
vLLM 通过 --all2all-backend 提供专家并行通信支持。官方指南目前描述了一个通用默认选项以及专用的 DeepEP 模式。应使后端与实际测得的流量相匹配。
| 后端 | 文档说明的适用场景 | 部署影响 |
|---|---|---|
allgather_reducescatter |
通用 EP + DP 部署 | 在进行专门调优之前，这是合理的对照配置。 |
deepep_high_throughput |
多节点、以预填充为主的工作负载 | 当长提示词和聚合吞吐量主导服务目标时，应进行评估。 |
deepep_low_latency |
多节点、以解码为主的工作负载 | 当生成 token 的延迟比最大预填充吞吐量更重要时，应进行评估。 |
| FlashInfer NVLink 模式 | MNNVL / NVLink 专用系统 | 仅当硬件和当前 vLLM 文档均符合该后端的要求时使用。 |
重点不是选择看起来最快的标签，而是针对你的提示词长度组合、并发量、网络互连和 SLO，一次测试一个后端。除了每秒 token 数，也要衡量其对尾延迟的影响。
多节点 vLLM 专家并行：双节点模式
对于多节点部署，vLLM 文档使用一个处理 API 流量的主节点，以及一个 --headless 辅助工作节点。以下是该文档模式的参数化形式。请将地址和数量替换为与你实际测试过的集群相匹配的值。
在主节点上：
export GLOO_SOCKET_IFNAME=eth0
vllm serve deepseek-ai/DeepSeek-V3-0324 --all2all-backend deepep_low_latency --tensor-parallel-size 1 --enable-expert-parallel --data-parallel-size 16 --data-parallel-size-local 8 --data-parallel-address <PRIMARY_NODE_IP> --data-parallel-rpc-port 13345 --api-server-count 8
在第二个节点上：
export GLOO_SOCKET_IFNAME=eth0
vllm serve deepseek-ai/DeepSeek-V3-0324 --all2all-backend deepep_low_latency --tensor-parallel-size 1 --enable-expert-parallel --data-parallel-size 16 --data-parallel-size-local 8 --data-parallel-start-rank 8 --data-parallel-address <PRIMARY_NODE_IP> --data-parallel-rpc-port 13345 --headless
这些数值至关重要：
--data-parallel-size是服务组中的总 DP 大小。--data-parallel-size-local是该节点上启动的 DP rank 数量。--data-parallel-start-rank是此前节点的本地 DP 大小累计值。- 次节点以无头模式运行，因为主节点负责处理客户端请求。
对于 InfiniBand 集群，当前 vLLM 指南特别指出应使用 GLOO_SOCKET_IFNAME=eth0，以便在选定的以太网控制接口上进行分布式组发现。这不能替代对跨节点 NCCL 和 GPU 间通信的验证。
多节点验收检查清单
在将客户流量发送到多节点 vLLM 专家并行组之前，请验证以下所有事项：
- 每个工作节点都解析到相同的模型版本，并以预期的 rank 启动。
- 主节点可以从每个对等节点访问已配置的 RPC 地址和端口。
- 在干净重启后，分布式组能够反复成功初始化。
- 请求可在低并发下完成，随后也能在持续负载轨迹下完成。
- 刻意倾斜的请求组合不会导致静默挂起或尾延迟断崖式恶化。
- 重启一个测试工作节点会产生可观测、可操作的故障信号，而不是请求无限期排队。
vLLM 分布式故障排查指南建议验证节点间 GPU 通信，并确保每个节点都具备通信环境变量。如果使用 Ray，该指南还说明了应保持 vLLM 和 Ray 的主机 IP 配置一致。
仅在观察到不均衡后再添加专家并行负载均衡
生产环境中的 MoE 路由并不总是均匀分布。vLLM 的专家并行负载均衡器（EPLB）会收集负载数据，并定期在 EP rank 之间重新分配专家映射。该功能通过 --enable-eplb 启用。
vllm serve Qwen/Qwen3-30B-A3B --enable-expert-parallel --enable-eplb --eplb-config '{"window_size":1000,"step_interval":3000,"num_redundant_experts":2,"log_balancedness":true}'
除非有热专家、每个 rank 工作负载不均，或与路由倾斜相关的持续性尾延迟等证据，否则请不要启用 EPLB。EPLB 可以使用冗余专家，而这些额外的专家副本会消耗 GPU 内存。应将其视为带有容量成本的优化措施，而非强制性的 vLLM 专家并行标志。
对于初始实验：
- 在不使用 EPLB 的情况下记录每个 rank 的利用率和请求延迟。
- 在受控时间窗口内启用均衡度日志记录。
- 添加符合内存预算的最小冗余设置。
- 在相同负载轨迹下比较尾延迟、吞吐量、内存余量和重平衡干扰。
- 准备好回滚命令和非 EPLB 部署配置。
能够回答正确问题的基准测试计划
不要因为进程能够启动就认为 EP 推出成功。每次比较都应使用相同的模型版本、提示词、输出上限、并发度、量化方式、缓存设置和硬件预留。
| 测试 | 揭示的问题 | 决策信号 |
|---|---|---|
| 短提示词、高并发解码 | 解码侧集合通信和队列行为 | p99 token 间延迟和生成 token 吞吐量 |
| 长提示词预填充 | 预填充和全互连通信开销 | p99 首 token 时间和聚合预填充吞吐量 |
| 专家倾斜负载轨迹 | 少数专家是否会造成热 rank | rank 不均衡、队列增长，以及是否需要 EPLB |
| 长上下文容量测试 | 在真实缓存压力下的内存余量 | OOM 率、准入失败和安全并发度 |
| 重启 / 分区演练 | 对等节点故障或端口被阻塞时的运行行为 | 检测时间、错误可见性和恢复路径 |
记录的不应只有平均吞吐量。若部署提升了平均值，却破坏了 p99 延迟或使恢复过程变得不透明，那么这并不是一次良好的生产环境收益。
排查 vLLM 专家并行部署问题
| 症状 | 可能的原因类别 | 第一步 |
|---|---|---|
未知的 --expert-parallel-size 参数 |
运行手册与已安装的 vLLM 不匹配 | 运行 vllm serve --help，固定构建版本，并使用该构建文档中说明的 TP/DP 配置。 |
| 启动时在 EP 内核或 all-to-all 后端附近失败 | 缺少或不兼容的 EP 依赖项 / 容器栈 | 重新检查当前的 EP 前置条件和容器镜像，而不是一次更改多个启动标志。 |
| 多节点工作进程在初始化期间挂起 | 控制平面地址、端口、NIC 或进程组配置 | 在调优内核之前，验证连通性、所选接口、rank 计算和分布式通信。 |
| 工作进程显示就绪后，第一个请求挂起 | 节点间 GPU 通信不正常 | 运行供应商/vLLM 通信检查，然后检查 NCCL 和接口配置。 |
| 吞吐量没有提升 | 流量混合、网络互连、批处理行为或注意力侧配置仍是瓶颈 | 按提示词长度和并发度与基线比较；每次只更改一个拓扑变量。 |
| 启用 EPLB 后内存不足 | 冗余专家内存消耗了安全余量 | 降低冗余度或预留更多内存余量；重复容量测试。 |
| 某个 rank 持续较慢 | 专家路由偏斜或主机/网络互连性能不均衡 | 先测量 rank 级负载；仅当证据支持时才考虑 EPLB。 |
重要的习惯是进行聚焦诊断。在每次只改变一个因素时，保持模型、镜像、流量轨迹和拓扑不变。这样可以将模糊的“EP 很慢”报告转化为可执行的观察结果。
生产环境发布顺序
- 建立基线。在不使用 EP 的情况下运行目标 MoE 模型，并保留指标、日志和启动清单。
- 在单个节点上启用 EP。使用
--enable-expert-parallel，并明确选择 TP/DP 拓扑。 - 验证质量和容量。检查输出行为、内存余量、p50/p99 延迟和持续吞吐量。
- 根据流量形态选择后端。仅使用相同的流量轨迹，将通用后端与相关的专用后端进行比较。
- 仅在有证据时添加 EPLB。使用均衡性数据和内存余量来证明使用冗余专家的合理性。
- 扩展到多节点。在提高流量之前，验证 rank 分配、控制网络和节点间 GPU 通信。
- 进行故障演练。在生产流量发现问题之前，测试重启、端口丢失和工作进程不健康的情况。
- 固定并记录。在部署旁保存版本、启动标志、拓扑、指标和回滚步骤。
何时不应自托管 MoE 服务层
当对模型放置、数据路径、硬件预留和服务行为的控制是产品需求的一部分时，vLLM expert parallel 是正确的投入。当团队主要需要模型访问能力，且无法负责 GPU 利用率、分布式网络、升级测试和随叫随到的故障恢复时，它并不适合。
在预留更大的集群之前，请在GPU 云与模型 API：自托管何时真正节省成本中，将运营模式与托管 API 路径进行比较。正确的答案可能是混合模式：自托管需要基础设施控制的工作负载，其余部分使用 API 层。
常见问题
--enable-expert-parallel 会启用 vLLM expert parallel 吗？
是的。当前 vLLM CLI 文档说明，--enable-expert-parallel 会针对 MoE 层使用专家并行，而非张量并行。
vLLM expert parallel 的大小标志是什么？
对于当前文档说明的部署流程，EP 大小由 --tensor-parallel-size 和 --data-parallel-size 推导得出：EP_SIZE = TP × DP。请在固定的 vLLM 发布版本中验证确切的 CLI 接口，而不要假定存在单独的大小标志。
专家并行会在所有地方取代张量并行吗？
不会。EP 会改变 MoE 专家层策略。注意力层行为仍取决于你选择的 TP 和 DP 值。
每个 DeepSeek 部署都应启用 EPLB 吗？
不应。首先应证明在代表性流量下存在专家负载不均衡，并确认冗余专家的内存成本适合该集群。EPLB 是一种优化，而不是默认要求。
我应使用哪个 all-to-all 后端？
从当前 vLLM 指引开始，然后测试与工作负载形态相匹配的后端：适用于广泛兼容性的通用选项、适用于以预填充为主流量的高吞吐量 DeepEP 模式，或适用于以解码为主流量的低延迟 DeepEP 模式。
参考资料
下一步：将单节点命令用作受控验证环境，采集基线，并且仅推广能够改善你实际关心的 SLO 的拓扑。这样，vLLM 专家并行才能成为一项生产决策，而不是一个你希望能更快的标志。
