S11 · Route to Experts — 沿着专家路由追踪 token

EP 分散的是专家参数；token 必须移动到参数所在的设备。

01稀疏激活不等于没有大模型参数

MoE 为每个 token 选择少量 routed experts，因此一次计算只激活部分参数，但整个模型仍需存放全部专家。专家并行将专家参数分散到不同设备，gate 给出逻辑专家与权重。它不同于让每张卡各自完整处理独立请求的数据并行；同一个 token 的一次 MoE 可能跨越多张设备。

s11_expert_parallel.py

# Framework pseudocode for EP routing and return correspondence.
expert_ids, weights = gate.topk(hidden, experts_per_token)
physical_ids = resolve_replicas(expert_ids, replica_map)
routes = pack_routes(hidden, physical_ids, weights)

received, handle = dispatch_to_owners(routes)
local_outputs = empty_like(received.hidden)
for expert in local_experts:
    rows = received.rows_for(expert.id)
    local_outputs[rows] = expert(received.hidden[rows])

returned = combine_to_origins(local_outputs, handle)
output = zeros_like(hidden)
for route in returned:
    output[route.token] += route.weight * route.hidden

if shared_expert is not None:
    output += shared_expert(hidden)

02通信的两端必须能互相还原

dispatch 把 token 及其路由信息送往持有专家的设备，专家执行后 combine 把结果交回原始位置并按权重合并。一条 token 可被复制到多个专家，因此顺序、来源下标与权重都不能丢。真实系统还要处理不同设备 token 数不均、通信缓冲和计算重叠，通信成本也可能抵消部分稀疏计算收益。

03上游的逻辑专家与物理专家

DeepInfer 的 DeepseekMoE 对接 dispatch/combine 路径。模型选择 logical expert，框架再映射到包含冗余副本的 physical expert；物理专家数量需要满足 EP 分配约束。Attention 的 DP/CP 与 MoE 的 EP 属于不同职责的进程组，阅读时还要追踪路由来源与返回顺序。

TRY IT YOURSELF

动手想一想

将四个专家放到两个 rank，为三个 token 各选两个专家。画出 dispatch 消息、专家输出与 combine 的加权结果，保留每条消息的来源 token。