什么是专家并行（Expert Parallelism）？
专家并行是一种面向混合专家（MoE）模型的模型并行策略：把每个专家的前馈层放到不同的硬件加速器上，由路由器把 token 分派给相应专家并汇总结果。它让模型参数量可以继续扩大，而每个 token 只激活少数专家，因此不按比例增加计算开销。
专家并行（Expert Parallelism，EP）是一种面向混合专家（mixture-of-experts，MoE）模型的并行策略：每个专家的前馈层（feedforward layer）存放在不同的硬件加速器上，由路由器（router）把 token 分派给相应的专家，再收集各专家的计算结果。它要解决的问题是：MoE 模型的参数总量可以做得很大，但单个 token 只激活其中少数专家，如果把专家分散到多张卡上，就能在不按比例抬高计算成本的前提下继续扩大模型规模。
为什么重要
在专家并行出现之前，扩大模型规模主要依赖数据并行与张量并行。数据并行把同一份模型复制到多个设备上、各自处理不同的数据，模型本身并没有被拆开，因此单卡显存仍然要装下全部权重；张量并行则把单个矩阵运算切分到多张卡上，通信频繁、切分粒度细，适合的是层内并行，而不是「模型里有很多个结构相同、彼此独立的子网络」这种情形。
MoE 架构恰好带来了后一种情形。按照 NVIDIA 开发者博客的说法，MoE 模型每个 token 只激活一部分已训练参数，因此比稠密模型更省算力，但代价是引入了更复杂的并行、通信与调度需求。当模型长到 DeepSeek-R1 这样拥有 256 个专家、6710 亿参数的规模时，专家数量本身就构成了新的问题：权重加载压力、专家之间的负载不均、以及跨设备通信都会成为瓶颈。专家并行正是针对这一层结构做切分的方案——把专家本身当作划分单位，而不是把矩阵切碎。
Hugging Face 官方文档给出的定位是：专家并行让模型扩展到远大于以往的参数量，同时不增加计算成本，因为每个 token 只激活少数几个专家。NVIDIA 则把「大规模专家并行」（large-scale EP）定义为把专家分布到八张或更多 GPU 上，认为这样可以提高聚合带宽以加快权重加载，并支持更大的有效批大小，从而改善整体 GPU 利用率。
工作机制
专家并行的核心动作可以拆成几步。
- 专家分片。每个专家的前馈层被放到不同的加速器上，每张卡只持有自己负责的那部分专家权重。Hugging Face 文档提到，在 EP 计划中，GroupedGemmParallel 风格会沿专家维度切分专家权重，使每个 rank 只加载本地专家。
- 路由分派。路由器根据 token 的内容决定它应该交给哪些专家处理，然后把 token 发送到持有这些专家的设备上。这一步是跨设备通信的主要来源。
- 本地计算。各设备用本地专家处理收到的 token。
- 结果汇总。把分散在各设备上的专家输出收集回来，合并成该层的结果。
在 Hugging Face 的实现里，专家并行通过 DistributedConfig 类和 ep_size 参数开启。文档指出，多数 MoE 模型默认采用 token dispatch（token 分派）方式，因此 ep_size 可以独立于 tp_size 设置；而 Llama 4、Gemma 4 等少数模型仍默认使用 masking 加 all-reduce 的方式（对应 model.ep_plan 中的 "ep_router" 与 "moe_tp_experts"）。Masking 方式也可以在任何提供 ep_plan 覆盖的模型上使用，但要求 ep_size=tp_size，这样专家组内的每个 rank 才能收到相同的 token。
每个 MoE 模型在配置中定义两套计划：base_model_tp_plan 用于稠密模块，base_model_ep_plan 用于专家，加载后分别暴露为 model.tp_plan 与 model.ep_plan。当 tp_size 与 ep_size 都大于 1 时，两套计划同时生效：张量并行计划切分注意力与稠密 MLP，专家并行计划切分专家。文档特别说明，对同一模块而言 EP 规则优先于 TP 规则，因此专家权重只会被切分一次，由 EP 计划负责。tp_plan 仅在 tp_size > 1 时应用，ep_plan 仅在 ep_size > 1 时应用；若开启 TP 而关闭 EP，则完整的 TP 计划生效，其中也包含专家相关规则。
NVIDIA 开发者博客则从推理部署角度描述了另一组配套机制。GB200 NVL72 提供 130 TB/s 的一致 NVLink 域，用来抵消大规模专家并行带来的通信开销，使机架级部署变得可行。同时，自定义 NCCL 内核与专家并行负载均衡器（Expert Parallel Load Balancer，EPLB）负责处理动态专家路由，把「热」专家和「冷」专家重新分布，以维持各 GPU 的利用率均衡。
典型例子
Hugging Face 文档给出的示例使用 openai/gpt-oss-120b 模型，通过 DistributedConfig 同时设置 tp_size 与 ep_size（示例中两者都取自环境变量 WORLD_SIZE），再传给 AutoModelForCausalLM.from_pretrained 加载。这说明在实际用法中，张量并行与专家并行可以叠加配置。
NVIDIA 开发者博客举出的模型是 DeepSeek-R1，拥有 256 个专家、6710 亿参数，被用来说明为什么需要 TensorRT-LLM 的 Wide Expert Parallelism（Wide-EP）。该博客称，Wide-EP 把专家分布到八张或更多 GPU 上，以降低权重加载压力并提升 GroupGEMM 效率。在测试中，大规模 EP 配置（EP32）在每用户每秒 100 token 的条件下，每 GPU 输出 token 吞吐量比小规模 EP 配置（EP8）高出最多 1.8 倍。该博客还称，在 GB200 NVL72 上使用 Wide-EP 可以提升每 GPU 每秒 token 数，并降低万亿参数模型部署的总拥有成本。这些数字与结论均出自 NVIDIA 的这篇博客，属于该厂商在其测试条件下的结果。
边界与常见误解
首先，专家并行不是通用并行方案，它只对 MoE 模型有意义。稠密模型没有「专家」这一层结构，无从按专家切分，只能依赖数据并行或张量并行。
其次，专家并行并不自动等于更省钱。它把计算压力分散了，却把通信压力抬了上来：token 需要被送到持有目标专家的设备，结果还要再收回来。NVIDIA 博客明确把通信开销列为大规模 EP 的挑战之一，并指出 NVL72 的 130 TB/s NVLink 域正是为抵消这部分开销而存在。换句话说，跨设备互联带宽不足时，专家并行的收益会被通信吃掉。
第三，负载不均是这类系统的固有代价。路由是动态的，不同专家收到的 token 数量会随时间波动，因此需要 EPLB 这类机制把热专家与冷专家重新分布，以维持 GPU 利用率均衡。这意味着部署方需要额外的调度与均衡组件，而不是配置一个并行度就结束。
第四，配置方式存在模型间差异，容易被一概而论。Hugging Face 文档指出，多数 MoE 模型默认走 token dispatch，ep_size 可独立于 tp_size；但 Llama 4、Gemma 4 等仍默认 masking 加 all-reduce，且 masking 要求 ep_size=tp_size。如果按「EP 总是独立于 TP」的假设去配置这些模型，就会出错。
最后需要区分「专家并行」与「大规模专家并行」。后者并非另一套机制，而是同一思路在规模上的延伸；NVIDIA 博客为行文方便，把专家分布到八张或更多 GPU 的情形称为 large-scale EP，这是该博客给出的界定，而非普遍标准。