ISCA'26 最佳论文 | 44 亿种专家组合背后，其实藏着可预测的规律

July 30, 2026

2026   ·   LLM   MoE   推理优化   论文解读  

ISCA’26 最佳论文 | 44 亿种专家组合背后，其实藏着可预测的规律

原文：Patterns behind Chaos: Forecasting Data Movement for Efficient Large-Scale MoE LLM Inference

1. 前言吐槽

做 MoE 推理优化，有个问题绕不过去：专家选择到底是不是随机的？

这个问题看起来很学术，但它直接决定了你能做什么优化。如果专家选择完全随机，那 prefetch、cache、replication 这一整套系统优化的思路全都不成立——你没法预测下一步要用哪个专家，就只能傻等数据搬过来。DeepSeek V3 每层 256 个专家选 8 个，$C_{256}^{8}$ = 4,426,165,368 种组合。44 亿。面对这个数字，”随机”几乎是个下意识的结论。

但我们做优化的人心里一直有个直觉：它不该是随机的。因为 MoE 的 gating 是学出来的，学出来的东西就该有结构。问题是没人拿大模型系统性地验证过——之前的工作最多profile一两个 Mixtral 8x7B 这种量级的小模型，报几个表面观察就结束了。

这篇 ISCA’26 最佳论文把这件事做实了。四个 2025 年的 SOTA 大模型（235B 到 1000B），24000+ 条请求，2000+ GPU 小时，150GB 的 expert selection trace，然后给出六条可以直接指导系统设计的 insight。今天想和大家聊聊这篇工作到底测出了什么，以及为什么这些结论对做 MoE serving 的人很重要。

2. 先交代背景：为什么数据搬运是 MoE 的核心矛盾

MoE 的宣传语一直是”稀疏激活，参数量涨了但推理开销不涨”。听着很美好，落地的时候第一个撞上的墙就是数据搬运。

先看这篇论文给的 latency breakdown。DeepSeek V3、4K 序列长度，在三种真实 serving 配置下：

DeepSeekV3 不同 serving 配置下的延迟拆解

MoE 相关的数据搬运（MoE All-to-All + MoE Weight）占了总延迟的 60%-90%。注意这不是 attention 慢、不是 GEMM 慢，是”把数据搬到该去的地方”这件事本身慢。

为什么会这样？因为 MoE 的稀疏激活是动态的。token 走到 gating 之前，你不知道它要去哪个专家。而现代大模型的部署方式必然是多单元的——DeepSeek V3 671B 参数要 32+ 张卡，专家分散在不同 GPU 上。于是每一层 MoE 都要做一次全局的 token 重排（all-to-all），再把结果搬回来。这也是整个行业推 MoE 落地时绕不过去的核心矛盾：稀疏计算的收益，被动态搬运的开销吃掉了。

模型还在往大走。看这张图，横轴是发布时间，纵轴是参数量，气泡大小是每层专家数：

MoE 模型参数量与发布时间趋势

2025 年这一波（红色气泡）是 DeepSeek V3、Kimi K2、Llama4-Maverick、Qwen3-235B，也就是这篇论文 profile 的四个。橙色的 DeepSeek V4 和 GLM-5 是论文写完之后才出的。趋势非常明确：参数量和专家数都在快速涨，搬运问题只会越来越严重。

3. 论文的方法论：从 system-centric 翻转到 model-centric

这篇工作我最欣赏的一点是它的定位。

以前的 MoE 优化工作是 system-centric 的：先选定一个平台（CPU-GPU offload、多 GPU 集群、PIM 架构），然后针对这个平台的数据搬运特性做优化。MoE-Lightning 做 CPU 内存 offload，Comet 和 MegaScale-Infer 做多 GPU 通信重叠，Duplex 上 processing-in-memory。这些工作都很好，但它们的 insight 是平台绑定的——换个部署形态就不一定成立，而且每篇只看到整体规律的一个切片。

这篇论文把流程反过来，做 model-centric 的分析：不绑定任何系统，只 profile 模型本身的专家选择行为，得出的规律因此是 system-agnostic 的，能往各种平台上套。

具体怎么切？作者把 expert selection 的规律分成两个维度：

MoE 推理流程与两个维度的划分方式

  • Temporal（时间维度）：当前的专家选择能不能预测未来的选择？这决定了你能不能做 prefetch / cache / migration，是单个计算单元内部的优化。图里左半部分标了三个观察尺度：Ob1 层级（相邻两层之间）、Ob2 token 级（相邻两个 token 的同一层）、Ob3 prefill-decode 级（两个阶段之间）。
  • Spatial（空间维度）：在一个时间窗口内，专家激活怎么分布到各个单元上？这决定了你怎么做 expert placement 和负载均衡，是跨单元的优化。图里右半部分是 Ob4（单个专家的激活倾斜）和 Ob5（专家对的共激活亲和性）。

这个切法很清晰：时间维度管”预取什么”，空间维度管”放在哪”。下面按这两个维度看结论。

整篇论文的逻辑链我画了一张图，可以对着往下读：

从 profiling 到六条 insight 的推导关系

4. Temporal：专家选择在时间上确实可预测

4.1 Ob1 层间相关性

先看相邻两层。热力图的含义是：上一层激活了专家 i 的条件下，下一层激活专家 j 的条件概率，亮的地方概率高。

相邻层专家选择的条件概率热力图和 CDF

看 (a) DeepSeek V3 和 (b) Qwen3 的热力图，能看出几个东西：

  • 白点：某些特定的专家对，跨层选择概率显著高于其他组合
  • 亮的竖线：某些专家不管上一层选了谁都会被频繁选中——这就是”热门专家”，后面空间维度会专门讲
  • Qwen3 的热力图整体更亮，说明它的层间相关性比 DeepSeek 更强
  • 同一个模型不同层的模式也不一样，第 3-4 层和第 30-31 层长得不同

光看热力图容易主观，作者用条件 CDF 量化了一下。(c) 图的读法：横轴是”取下一层候选专家的前百分之多少”，纵轴是”这些候选覆盖了多少条件概率质量”。结论是取 top 20% 的候选，就能覆盖 50%（DeepSeek V3）、65%（Qwen3）、77%（Llama 4）、56%（Kimi K2）的概率质量。

换句话说，如果你愿意预取 20% 的专家，就有一半以上的把握命中。这个数字对 prefetch 设计来说完全够用了。相关性强度是 Llama 4 最强、DeepSeek 最弱。

4.2 Ob2 token 间相关性

再看同一层、相邻两个 token 之间：

相邻 token 专家选择的条件概率热力图

白点、亮竖线这些跟层间类似，但多了一个所有模型共有的新特征：明显的对角线。

对角线意味着什么？意味着相邻 token 倾向于选同一个专家。这个特征对 cache 设计极其有价值——你把这一个 token 用过的专家留在本地，下一个 token 有相当概率直接命中。

更有意思的是这个对角线只在高层出现（17 层、43 层），低层（1 层、3 层）没有，而且四个模型都是这个规律。我的理解是：低层还在处理比较通用的词法/句法特征，token 之间差异大；到了高层已经在处理语义了，相邻 token 在语义上高度连续，所以路由到同一批专家。

CDF 量化的结果：top 20% 的下一个 token 候选专家覆盖 47%（DeepSeek V3）、62%（Qwen3）、80%（Llama 4）、53%（Kimi K2） 的累积条件概率。同样是 Llama 4 最强、DeepSeek 最弱。

4.3 Ob3 prefill 和 decode 的一致性

这是我认为最有工程价值的一条。作者对比了 prefill 阶段和 decode 阶段的专家选择模式：

prefill 与 decode 阶段的热力图对比及 Spearman 相关性

(a)(b) 是 cross-layer 热力图的 prefill / decode 版本，(c)(d) 是 cross-token 的，肉眼看亮点分布高度相似。(e)(f) 用 Spearman 相关系数做了量化——这个系数衡量两个变量的单调关系，范围 -1 到 1，一般 ρ > 0.7 算强相关，0.4 < ρ ≤ 0.7 算中等相关。结果是大部分层都落在强相关区间，少数层是中等相关。

除了专家对的热力图，单个专家的频率分布也一致：

prefill 与 decode 的专家频率分布及 top 专家重叠率

(a) 是 Qwen3 第 66 层的专家选择频率，蓝色 prefill、橙色 decode，两条分布基本贴在一起（低频专家那里有些偏差）。(b) 是 top 专家的重叠率：prefill 的 top-5 专家覆盖了 decode top-5 的约 60%，top-10 覆盖 75%，top-20 覆盖 90%。(c) 确认这个关系在四个模型上都成立。

这条为什么重要？因为它解决了一个真实的工程空窗期。现在大规模 MoE serving 用 EPLB（Expert Parallelism Load Balancer）来动态调整专家放置，但 EPLB 需要先攒够 profiling 数据才能生效——要 3000+ 步才触发一次。那前面这 1000 个 decode token 怎么办？尤其是短输出的请求，EPLB 从头到尾都攒不够数据。

Ob3 给的答案是：用 prefill 阶段的 trace 去预测 decode。这在现在流行的 PD 分离架构里特别顺——prefill 和 decode 本来就在不同机器上跑，prefill 机器顺手把 trace 传过去就行。

4.4 从时间维度出来的两条 insight

Insight 1：用 prefill 数据驱动预测（来自 Ob3）。拿 prefill 阶段的专家选择 trace 去预测 decode 阶段的选择，尤其适合 decode 刚开始、历史数据还很少的时候。

Insight 2：跨层次内存管理（来自 Ob1、Ob2）。这条的巧思在于把两种相关性映射到不同的内存层级上，理由是reuse distance 不一样：

  • 层级相关性 reuse distance 短——相邻 MoE 层是紧接着执行的，中间隔的时间很短
  • token 级相关性 reuse distance 长——要遍历完所有层才生成下一个 token

而现代系统的内存层级刚好是分层的。以多 chiplet 架构为例，每个 die 上有 LLC（小而快）和 local DRAM（大而慢）：用层级相关性管 LLC，用 token 级相关性管 DRAM。这个原则能往其他配置上套——CXL 系统（本地 DRAM + 远端 CXL 内存）、SSD offload 系统（DRAM + flash）、PIM 系统（本地和远端 DRAM die），都是”层级相关性管快的那层，token 级相关性管慢的那层”。

5. Spatial：负载倾斜和专家对亲和性

5.1 Ob4 单专家激活倾斜

看 Llama4 第 7 层各专家的激活频率：

Llama4 第 7 层的专家激活倾斜与任务相关性

(a) 图非常直观：少数专家的激活频率超过平均值的 16 倍（红线是平均值）。这种倾斜直接导致负载不均衡——存着热门专家的那个单元被打爆，其他单元在等它。

(b)(c) 是我觉得这篇论文里更有意思的部分。作者跑了 MMLU 全部 57 个学科（生物、历史、数学等等），画出每个学科的 top 10 热门专家：

  • 横向亮线：某些专家不管什么学科都热门——这是全局热点
  • 除此之外，各学科的热门专家差异明显——说明确实存在任务特化

然后作者做了个很漂亮的对照实验：用 MMLU Pro 的中文版本，题目内容完全相同，只换语言。结果 (c) 图的模式明显不同——虽然也有 5-6 个专家跨学科热门，但只有两个和英文 MMLU 的热门专家重叠。

内容相同、只换语言，激活的专家就换了一批。这个发现挺反直觉的，说明 gating 学到的不只是”语义领域”，还包含了语言层面的表面特征。对系统设计来说这是个好消息：语言/任务类型是可以提前知道的元信息，可以拿来做主动的专家放置。

5.2 Ob5 专家对共激活亲和性

超越单个专家，看专家两两之间是否倾向于同时被激活：

专家对共激活热力图与 CDF

热力图的每个像素是一个专家对，值是共激活频率除以理论随机概率 $p = \frac{2}{n(n-1)}$（$n$ 是专家数）。所以值等于 1 就是”和随机没区别”。

结果是亮点的概率达到理论值的 20-40 倍。这远远超出随机能解释的范围。

(a) 图里 DeepSeek 的热力图有个特别的结构：频繁激活的专家对集中在红线之间形成的亮方块里。这不是自然涌现的，是 DeepSeek 的路由限制导致的——它限制 token 只路由到相邻节点来减少通信开销，所以共激活自然集中在同组内。

(c) 图量化：top 10% 的专家对占了总共激活量的 60-80%。倾斜非常强。

（Llama 每层只选一个专家，所以没有共激活关系，这里只分析了 DeepSeek 和 Qwen。）

5.3 从空间维度出来的四条 insight

空间维度对应的是粗粒度、静态的策略，可以在系统启动时或者周期性重分布（比如每 10 分钟）的时候应用。

Insight 3：专家放置感知的负载分配（Ob4、Ob5）。分配任务的时候要考虑专家实际放在哪。这里有个思路上的转变值得注意：传统多 GPU 系统倾向于”把计算分配到专家所在的本地 GPU”，避免跨单元通信。但在 multi-chiplet GPU 上，inter-unit 通信变快了，所以可以考虑把任务分给远端 die 来换取更好的负载均衡。设计空间比以前大。

Insight 4：热门专家去中心化（Ob4）。把热门专家在多个单元上复制，摊平负载。另外要避免把多个热门专家放在同一个单元。

Insight 5：专家对分离（Ob5）。把频繁共激活的专家对分到不同计算单元，最大化并行度。但论文很诚实地指出这条有 trade-off：分离会引入跨单元通信开销，是否值得取决于系统拓扑和 batch size。

Insight 6：workload 感知的 serving 系统（Ob4）。利用任务类型、语言这些元信息，在 serving 之前就做专家迁移。比如已知当前是英文流量，就提前复制/重分配英文相关的专家。关键是这个 task-to-expert 映射只需要一次离线 profiling，之后整个部署周期都能复用，成本很低。

6. Case Study 1：wafer-scale GPU 上 6.6× 提速

Insight 光说不练没意思，论文做了两个 case study。第一个是未来的 wafer-scale GPU。

6.1 为什么是 wafer-scale

这个背景值得交代一下。单 die 面积受 photomask 限制卡在 800-1000 mm²，Moore’s Law 也快到头了，所以厂商都在往 multi-chiplet 走：AMD MI300 集成 8 个计算 chiplet，NVIDIA Blackwell 是 2 个，即将出的 Rubin 预计 4 个。再往前一步就是 wafer-scale——TSMC 的 System-on-Wafer 能在一片晶圆上放 24 个计算 die 和 96 个 HBM die，面积超过 200,000 mm²，HBM 容量 3TB+，算力到 PFLOPS 级别。

wafer-scale GPU 架构、SoW 技术与 Global CP 的数据结构

(b) 是 SoW 的物理结构：每个 GPU die 通过 LSI（local silicon interconnect）连本地 HBM，相邻 GPU die 之间纵向走 LSI、横向走 XSR SerDes。虽然 LSI 和 SerDes 带宽都到 Tb 级，inter-die 通信仍然是主要瓶颈——远端访问要跨多跳，延迟高；多个 die 同时访问远端 HBM 还会带宽争抢。本地 vs 远端访问的开销差距可以到 15 倍。

6.2 编程模型的选择

这里有个设计决策值得单独说。wafer-scale 芯片的编程模型现在是开放问题，有两条路：

Multi-GPU-like：把整片晶圆暴露成一个多 GPU 系统，程序员能细粒度控制每个 die。WSC-LLM、MoEntwine 走这条。灵活，但和产业趋势不符——Blackwell 和 Rubin 都是多 die，但 NVIDIA 根本没暴露 die 级细粒度控制的工具链。MIG 倒是能把多 die GPU 切成独立实例，但这个模式下高速 D2D 链路是被禁用的，inter-die 通信被迫走慢 10-100 倍的 NVLink 或 PCIe，多 die 封装的好处就没了。

Single-GPU-like：把整片晶圆暴露成一个统一的 GPU，完全屏蔽多 die 拓扑和数据放置。这篇论文选的是这条，理由有两个：和 Blackwell/Rubin 这些商用多 chiplet GPU 对齐，有产业相关性；程序员不用管 NCCL/NVSHMEM 那套显式通信。

但选了 single-GPU-like，优化负担就全压到硬件上了——程序员看不到跨 die 的数据搬运，那就只能靠架构层面去优化。这也是这个 case study 要改硬件的根本原因。

6.3 当前 GPU 架构的两个不足

任务分配太简单。现在 GPU 的 command processor 把所有 SM 一视同仁，完全不管 SM 的物理位置和数据放在哪。这种分配方式在 wafer-scale 上会产生大量 D2D 流量，而且忽略了专家选择的倾斜性，结果是大部分 die 闲着、少数 die 过载。

本地 HBM 管理不足。现在 GPU 把所有 HBM die 当成统一内存空间，但 wafer-scale 上每个计算 die 直连本地 HBM，本地访问比远端快得多。热门的远端专家本来可以缓存到本地，但当前架构不区分本地和远端，白白产生额外流量。

6.4 两个改动

对应上面两个问题，论文做了两处架构扩展（上图 (a) 里橙色的部分）：

第一，Command Processor 改成两级：晶圆级的 Global CP + 每个 die 内的 Local CP。Global CP 维护全局的专家选择和放置信息。它管两个数据结构（上图 (c)）：

  • Expert Distribution Table：每个专家的初始 die ID + 一个 n 位二进制码，每位表示该专家在对应 die 上是否存在
  • Cross-token Heatmap：专家激活的历史模式，给预测用

第二，D2D controller 扩展出 ATU 和 PDU：

  • ATU（Address Translation Unit）：远端数据被复制到本地后，把远端地址翻译成本地地址
  • PDU（Prediction Unit）：判断哪些远端数据值得复制。每个 PDU 维护一张 prediction table，每个专家两个字段：cp_en（是否该缓存到本地，由 Global CP 算好下发）和 is_local（是否已经缓存在本地 HBM）

远端数据读取的流程变成这样：SM 读一个不在本地的远端数据 → D2D controller 正常路由 → 数据返回时 PDU 查 prediction table 做复制决策，不管决策如何都先把数据给 SM（不阻塞）→ 如果要复制，PDU 写入 LLC 和本地 HBM，更新 ATU 里的地址，把 is_local 置 1。下次再读同一个数据，ATU 直接把远端地址翻译成本地地址，重定向到 LLC。

6.5 两个算法

任务分配算法与数据驱动预测器的示意

任务分配算法（对应 Insight 3）。精确的任务分配是 NP-hard 的，所以用两个启发式：候选机制缩小要考虑的 die 集合，块粒度分配在候选里搜近似解。

任务分配算法伪代码

走一遍这个算法：输入 expert_reqs_dict 是每个专家有多少请求，expert_die_map 是专家放在哪（来自 Expert Distribution Table）。

  1. 先按请求数升序排序专家（第 2 行）——请求少的先分配
  2. 对每个专家，生成候选 die 列表 = 存了这个专家权重的 die + 它们的相邻 die（上图 (a) 里绿色是本地 die，红色是远端 die）
  3. 候选按当前负载排序，列表长度限制在 maxsplitnum 以内，这个值由该专家的请求数决定
  4. 请求按块大小 50 分发到候选 die（第 6-11 行）——粒度太细搜索开销大，太粗均衡效果差，50 是效率和精度的折中
  5. 每一块用 cost model 选最优 die，cost model 考虑 DRAM 访问、计算、die-to-die 通信三项
  6. 最后把分到同一个 die 的块合并（第 12 行）

数据驱动预测器（对应 Insight 1、2）。用当前 MoE kernel 的专家选择去预测下一个 token 在每个 die 上会用哪些热门专家。看上图 (b)：当前 token 选了专家 (1, 4) → ① 从 cross-token heatmap 里取出对应的行（红色阴影）→ ② 每行取 top n 专家 → ③ 对应的下一 token 专家就是预测结果（绿色阴影），这里预测出 (2, 4, 6)。因为这个 die 当前只读了专家 1 和 4，所以只把专家 4 复制到它的本地 DRAM。

6.6 效果

评测用自己写的 multi-chiplet 模拟器（现有工具都不合用：Gem5/gpgpusim/mgpusim 是 cycle-accurate 的，20+ die、batch 15000+ 的规模跑不动；ASTRA-sim 支持多 GPU 但微架构建模不够细，也不支持 single-GPU-like 编程模型）。模拟器对着 8×H100 DGX 实测校准过，误差在 5% 以内。

硬件配置两种拓扑：Tesla Dojo（5×5 mesh）和 TSMC SoW（8×3 mesh），每个 chiplet 是 H100 级别（989 TFLOPS FP16、80GB HBM、3.35TB/s 本地带宽、1.7TB/s inter-die 带宽）。

MoE 层吞吐（上）与跳数削减比（下）

跨模型看：Allo+Pred 在 DeepSeek、Kimi、Llama、Qwen 上分别拿到 7.0×、8.2×、7.3×、4.1× 吞吐提升（论文摘要里的 6.6× 是平均值）。DeepSeek 和 Kimi 收益更大，因为它们专家数更多（256 vs 128）、选择模式更复杂——优化空间本来就更大。

跨拓扑看：Dojo 上 6.0×，TSMC 上 7.5×。die 数量差不多（25 vs 24），但 TSMC 的长条形布局让 die 之间平均距离更远，不做策略性任务分配的话跨单元通信更多，所以我们的策略在这里收益更大。

和 EP 基线对比（EP = 把每个专家的计算都分到它所在的 die，完全消除 D2D 通信，但可能严重负载不均）：batch 4096 这种小 batch 下两者差不多——每个专家分到的 token 太少，执行是 memory-bound 的，把一个专家拆到多个 die 上没有收益，我们的策略退化成 EP。优势在大 batch 出现，batch 16384 时比 EP 快 1.44×。

跳数削减这里有个很有意思的现象，值得单独说。跳数是所有跨单元通信的曼哈顿距离之和：

  • Pred Only：跳数降 4.5×，性能提升 3.0×——比较接近，说明跨单元通信确实是 baseline 的主要瓶颈，减少跳数就能按比例提升性能
  • Allo Only：跳数降 142×，但性能只提升 6.3×——严重不成比例
  • Allo+Pred：跳数降 213×，性能提升 6.63×，比 Allo Only 只多了 1.1×

这说明什么？跳数已经不是瓶颈了。任务分配算法把大部分任务分给了持有相关专家的本地 die，只有极热门的专家需要往远端分配，D2D 流量已经压到很低，瓶颈转移到了负载分配本身。这是个很好的例子：优化到一定程度，你盯的那个指标就不再是瓶颈了，继续压它收益递减。

DRAM 访问的拆解印证了这一点：

DRAM 访问拆解：本地读/远端读/本地写

baseline 里大部分读都是远端读，用了我们的策略之后大部分远端读被转成了本地读。Allo+Pred 相比 Pred Only 远端读更少（任务大多分到本地 die），相比 Allo Only 也更少（热门专家缓存在本地 HBM）。

为什么一定要改硬件？ 论文做了个对照：任务分配算法理论上也能跑在 host CPU 上。结果在 Dojo 配置下，host CPU 方案的开销是 DeepSeek V3 的 5.2%-6.4%、Qwen3 的 11.1%-14.2%；换到 Dojo-Enhanced（die 换成 B300 级别，4500 TFLOPS）开销飙到 DeepSeek 的 19.3%-23.8%、Qwen3 的 42.0%-51.6%。

两个原因：Qwen3 比 DeepSeek 差是因为它 MoE 层更多（94 vs 58），CPU-GPU 之间要过 PCIe 的次数更多，而且单层计算量更小，传输开销占比被放大。Dojo-Enhanced 比 Dojo 差 3.7 倍以上，是因为 die 变快了，固定的 PCIe 传输开销占比更重。结论很清楚：GPU 算力增长快于互连带宽增长，把分配器放进 GPU command processor 是越来越必要的。

硬件开销方面，设计支持最多 100 层 × 512 专家（远超 Kimi-K2 的 61 层 384 专家）。完整 heatmap 50MB 放在 Global CP 的 DRAM 里，片上只留 0.5MB 缓存一层。总面积和功耗开销都低于 0.04%。

7. Case Study 2：真实 8×H100 上的 prefill 感知专家放置

第二个 case study 不需要改硬件，是纯软件的，落地更近。

问题是前面提过的 EPLB 空窗期：EPLB 3000+ 步才触发一次，最初 ~1000 个 decode token 没有 profiling 数据可用，短输出请求更是从头到尾都攒不够。Insight 1 说 prefill 和 decode 相关，那就用 prefill trace 来定 decode 的初始专家放置。

两种专家放置策略：Remap 与 Dup

两个算法：

Remap-based：保持每个 GPU 的专家数量不变，重新分配专家的归属。做法是按 roofline cost 降序排列专家，贪心地把每个专家分给当前负载最小的 GPU，约束是每个 GPU 恰好 $E/G$ 个专家。

Duplication-based：在每个 GPU 上预留额外的专家槽位，用 prefill trace 把热门专家复制进去。从默认的连续布局出发（GPU 0 放专家 0-15、GPU 1 放 16-31……），贪心地每次加一个副本，选那个能最大程度降低瓶颈负载 $\max_g load_g$ 的 (专家, GPU) 组合。被复制专家的 token 在所有副本之间平均分。

两个算法都用 roofline cost model 估计每个 GPU 的负载。

实验是 Qwen3-235B（94 个 MoE 层、每层 128 专家选 8）+ SGLang + 8×H100 NVLink，MoE 后端用 DeepEP，通过 SGLang 的 init_expert_location 接口控制放置，ep_dispatch_algorithm 设成 dynamic 保证副本间均分 token。指标只算 MoE 计算时间（三个 expert linear 层），不含 attention、all-to-all、top-k。

prefill 感知专家放置的性能

Remap 和 Dup 相比 Default 分别快 15.5% 和 12.5%，相比 Worst 快 2 倍以上，而且都在 Best 的 10% 以内——注意 Best 是用 oracle decode 信息算出来的理论最优，实际拿不到。两个算法表现接近，可以按内存和系统约束自由选。

这里论文有一段自我批评我觉得很实诚：8 卡的 EP 规模本身就限制了能拿到的提升。EP8 下每张卡放 16 个专家，冷热专家自然混在一起，即使用默认布局负载也相对均衡（最大/最小执行时间比只有约 1.3×）。所以真实的大规模部署（200+ GPU）里不均衡更严重，提升空间应该更大。这种不吹不黑的表述在最佳论文里挺常见的——审稿人最烦的就是过度声明。

8. 我的几点 take

第一，这篇论文最大的价值不是那两个 case study，是 trace 本身。论文自己也这么定位——两个 case study 只是证明 insight 可用，主要贡献是 profiling。150GB 的 expert selection trace 和多 chiplet 模拟器都开源了（HuggingFace），这意味着后面做 MoE serving 的人不用再花 2000 GPU 小时去重新 profile。这种”做基础设施”的工作在系统方向是最难被承认的，能拿最佳论文说明 ISCA 的审稿品味不错。

第二，”随机”这个假设值得反复质疑。44 亿种组合听起来是天文数字，但实际的条件概率分布高度集中——top 20% 覆盖 50%-80%。这提醒我一件事：组合空间大小和实际分布的熵是两个完全不同的东西。以后看到”这个空间太大不可能预测”的论断，我会先问一句实际分布长什么样。

第三，语言影响专家选择这个发现被低估了。内容完全相同、只换语言，热门专家就换了一批，只有两个重叠。这件事对多语言服务的部署有直接影响——如果你的流量是中英混合，按单一语言 profile 出来的专家放置可能是错的。而且这也让我对 MoE 的 gating 到底学到了什么更好奇了，它显然不只是在做语义路由。

第四，跳数降 213× 但性能只提升 6.63× 这个现象很有教育意义。做优化的人容易盯死一个 proxy 指标，但 proxy 和最终目标的关系是非线性且会随优化进程变化的。跳数在 baseline 阶段是好 proxy，优化到后期就完全脱钩了。所以优化过程中要反复确认瓶颈还在不在原来的地方。

第五，两个 case study 的落地难度差很多，值得区别看。wafer-scale 那个是模拟器上的结果，依赖尚不存在的硬件 + 架构改动，6.6× 这个数字要打折看；prefill 感知放置那个是真机 8×H100 实测，改的是 SGLang 的一个接口调用，今天就能用。1.25× 听起来不如 6.6× 性感，但对生产系统来说后者的价值更实在。

9. 一点吐槽和展望

写完这篇我有个感慨：MoE 系统优化正在从”猜”变成”测”。

之前做 MoE 相关的工作，很多设计决策是基于直觉的——”专家应该有局部性吧”、”热专家应该比较稳定吧”。有了这种规模的 trace，这些直觉可以被验证或推翻。我自己做 ExpertFlow 的时候就吃过没有可靠 profiling 数据的苦，很多参数只能靠试。

还没被回答的问题也不少。比如这些规律在不同 batch size、不同并发下会不会变？论文的 trace 是特定配置下收集的，实际生产环境的请求混合更复杂。再比如模型更新之后 trace 要不要重新收？论文说 task-to-expert 映射一次离线 profiling 就够，但这个”一次”能撑多久，跨版本还成立吗？还有训练时的 aux loss 设计怎么影响这些规律——热专家倾斜 16 倍是不是意味着 load balancing loss 没起作用，如果调整 loss 让分布更均匀，是不是反而破坏了可预测性、让 prefetch 失效？这里可能有个有意思的 trade-off。

欢迎评论区交流，尤其是踩过 MoE 部署坑的同学。

扯一句题外话。这篇论文的方法论其实很”AutoML”——先大规模 profiling 拿到经验数据，再从数据里提炼可自动化的策略，最后把策略变成系统里的一个组件。这个”用数据驱动设计决策”的思路和我们做 NAS 时的 benchmark 方法论一脉相承（NAS-Bench 那套东西存在的意义就是让架构搜索可复现、可比较）。

我和合作者把这方面的积累整理成了《动手学 AutoML：从 NAS 到大语言模型优化实战》。这本书讲的是搜索空间设计、搜索策略（进化/贝叶斯/强化学习/DARTS）、架构评估这些自动化方法，以及 LLM 方向的架构自动化、压缩（剪枝/量化）、模型融合。它不涵盖 MoE serving 的系统工程——这篇论文里的 chiplet 架构、HBM 管理那些内容书里没有，方向相邻但不是一回事，我不想夸大。但如果你对”怎么让设计决策从拍脑袋变成数据驱动”这个方法论感兴趣，书里 NAS 和 benchmark 那几章可能有参考价值。

动手学AutoML书籍封面

Flag Counter