01

60 秒回答模板

当专家数远大于 GPU 数时，不能把每个专家都复制到每张卡上，通常要做 expert parallelism：每张 GPU 持有一部分专家，路由后 token 被发送到对应专家计算。策略设计可以分三层。第一是静态放置：根据历史 token load、专家参数大小、通信拓扑和显存，把专家均衡分布到 GPU；热门专家要打散，频繁共现或同一 group 的专家可以做拓扑感知放置，尽量减少跨节点通信。第二是运行时调度：每个 batch 根据 Gate 结果统计每个专家 token 数，做 token packing、per-expert queue、micro-batch 或 grouped GEMM，让专家计算有足够 batch，同时用 capacity、backpressure 或 overflow 策略控制热点。第三是动态调整：训练中迁移专家要考虑 optimizer state 和一致性，通常不宜每步频繁移动；推理中可以基于长期热度复制热门专家、让冷专家低频驻留或分层加载，但要严控冷启动延迟。评估时看每专家 token 分布、GPU 利用率、显存、all-to-all 流量、p99 延迟、丢 token 比例和模型质量，目标是在吞吐、质量和资源成本之间平衡。

考点 专家到 GPU 的映射
难度 真实面经题
回答目标 讲清专家放置、调度和资源取舍
02

深入解析

01

先明确资源约束和目标

专家数量超过 GPU 数时，每张 GPU 通常要承载多个专家，或者只承载某些专家的分片。设计目标不是简单平均参数个数，而是同时让显存放得下、专家收到的 token 尽量均匀、跨节点通信可控、每个专家的 batch 足够大，并且不牺牲模型质量。

02

静态放置要看专家热度和拓扑

最简单的 round-robin 放置只能平衡专家数量，不能平衡真实负载。更合理的做法是统计训练或线上流量中的专家 token count，把热门专家分散到不同 GPU 或不同节点，避免多个热点挤在同一设备上；同时考虑机器内高速互联和跨节点带宽，把容易共路由的专家、同一层专家组和通信密集路径做拓扑感知安排。

03

运行时调度围绕 token queue

每个 batch 经过 Gate 后会得到每个专家的 token 数。系统要把 token 打包到 per-expert queue，再由专家所在 GPU 取本地 queue 做 batched FFN。为了提高 GPU 利用率，常见做法是把多个专家的矩阵计算做 grouped GEMM，或者把多个请求和 micro-batch 合并，让冷门专家也有足够工作量。

04

热点专家需要容量和复制策略

如果某些专家长期过热，可以通过负载均衡训练、capacity 控制、router penalty、热门专家复制或重放置来缓解。复制热门专家能降低排队和跨节点通信，但会增加显存和一致性成本；capacity 太小会丢 token 或退化，capacity 太大又会带来 padding 和尾部等待。这里没有单一最优，需要按流量分布和质量指标调。

05

训练和推理的调度边界不同

训练时专家参数、梯度和 optimizer state 都要一致，频繁迁移专家会带来状态搬迁和同步成本，因此更适合按较长窗口重平衡。推理时没有反向梯度，专家热度缓存、热门专家复制、冷专家分层驻留或按服务实例分片更灵活，但必须控制冷专家加载、首 token 延迟和 p99 抖动。

06

用指标闭环而不是凭直觉放置

专家调度是否有效要看每专家 token 分布、每 GPU compute time、通信字节数、跨节点比例、queue 等待时间、显存峰值、吞吐、p99 延迟、overflow 或 dropped token 比例，以及模型 loss 和任务指标。只看 GPU 平均利用率可能掩盖某些专家导致的尾部延迟。

03

易错点

  • 以为专家数超过 GPU 数时只能增加 GPU，没有讨论专家分片、放置和调度。
  • 只按参数量平均放置专家，忽略专家热度、token count 和跨节点通信。
  • 把训练和推理的专家迁移混为一谈，没有考虑 optimizer state 和梯度同步成本。
  • 认为热门专家复制没有代价，忽略显存、版本一致性和训练同步。
  • 只讲负载均衡损失，不讲运行时 queue、合批、grouped GEMM 和 p99 延迟。
  • 把冷专家全部 offload 当成无风险方案，没有说明加载延迟和服务抖动。
04

面试官追问

专家放置为什么不能只按专家数量平均分？

因为真实负载由 Gate 分配的 token 数决定，不同专家热度差异可能很大。平均专家数量可能导致某张 GPU 上都是热点专家，另一张 GPU 上都是冷门专家，最终吞吐和 p99 都很差。

热门专家复制有什么代价？

它会占用额外显存，训练时还涉及梯度和参数同步，推理时也要维护版本一致。复制能缓解热点，但不是免费扩容。

专家迁移应该按 step 实时做吗？

通常不适合每 step 迁移。专家参数和状态很大，频繁搬迁会超过收益。更常见的是基于统计窗口做周期性重平衡，或在推理服务层按热度调整副本和实例分片。

capacity factor 在调度中起什么作用？

它限制每个专家最多接收多少 token，防止热点专家无限排队。但容量过小会丢 token 或走 fallback，容量过大会增加 padding 和等待，所以要结合质量和吞吐调。

如何让冷门专家的计算不浪费 GPU？

可以跨请求合批、用 grouped GEMM 合并多个小专家计算、调整专家放置让冷门专家共享设备，或者在推理中按热度做分层服务。关键是避免大量小 batch 让 GPU 启动开销超过有效计算。