arXiv’25 | SMoE：expert 不在 GPU 上？别搬了，找个”平替”直接算

原文：SMoE: An Algorithm-System Co-Design for Pushing MoE to the Edge via Expert Substitution

1. 前言

MoE offloading 这个赛道我很熟：GPU 显存装不下所有 expert，只能把大部分放 CPU 内存，router 选中谁就现从 PCIe 搬谁。所有已有工作——MoE-Infinity、HybriMoE、各种 prefetch/cache 方案——都在回答同一个问题：怎么把”搬运”调度得更聪明。

这篇南京大学（联合清华、荣耀）的工作换了一个问法：这个 expert 真的非搬不可吗？

它的观察起点很扎心。看三个 MoE 模型（DeepSeekMoE、XverseMoE、Qwen2MoE）的 gate score 分布：

各排名位置的平均 expert score，长尾明显

Top-k 选出来的 expert，score 分布是陡峭的长尾：排第一的 expert score 是 0.13，排在 active/inactive 边界附近的只有 0.02-0.03——同为”被激活的 expert”，对输出的贡献差了一个数量级。而现有 offloading 系统对它们一视同仁：不管你贡献大小，选中了就得从 PCIe 搬过来（DeepSeekMoE 上搬一个 expert 要 0.75ms，比 GPU 算一次贵 7 倍还多）。

为一个贡献 2% 的 expert 付一次全价 PCIe 运费，这个账怎么算都不划算。

2. 核心思路：低分 expert 用”平替”

SMoE 的做法说人话就是：router 选中的低分 expert，如果 GPU 缓存里恰好有一个 score 相近的其他 expert，直接拿后者顶替，不搬了。

替换策略示意：raw 选择 vs 带替换的调度

看上图左侧的例子：gate 排序后选中 a、b、c、d、e 五个 expert，其中 d、e 是低分的，且不在 GPU 上；GPU 缓存里躺着 f、g 两个没被选中但 score 接近的 expert。传统做法要走 3 次 PCIe（c、d、e），SMoE 用 f、g 顶替 d、e，只需要 1 次 PCIe。表格里的数字：GPU 命中从 2/5 提到 4/5。

凭什么敢替？两个依据：

gate score 本身就是重要性度量——低分 expert 对加权求和的贡献小，替换引入的扰动有限
替换有严格的分数带约束：设 S(k+1) 是第 k+1 名的分数，被替换的 expert 分数必须落在 (S(k+1), (1+α)·S(k+1))，替补的分数必须落在 ((1-α)·S(k+1), S(k+1)]——两边都贴着 top-k 边界，α 这个超参控制”平替”的容忍度。找不到满足约束的替补就老老实实回退到 PCIe 搬运或 CPU 计算，不硬替

这套逻辑在 CPU 上跑，每层搜索空间就几十个 expert，完全和 GPU 计算流水线重叠，开销可忽略。

3. 配套系统设计

光有替换还不够，SMoE 是一套组合拳，目标是最大化”router 命中 GPU 缓存”的概率：

3.1 Score 感知的缓存淘汰

要让”平替”可行，GPU 里得囤着分数带附近的 inactive expert。传统 LRU 只看访问时间，SMoE 改成按近 n 轮平均激活分数淘汰——历史贡献高的留下，不管你最近有没有被用到。同时有个保护机制：本层被 router 选中的 expert 在计算完成前免疫淘汰，避免”刚要用就被踢”。

再看一个支撑这个策略的数据：

expert 复用概率随 score 排名递减

高分 expert 的跨 token 复用概率高达 0.4-0.6，长尾 expert 只有 0.1 出头——按分数囤货比按时间囤货更接近未来需求。

3.2 top-score expert 预取 + CPU 协同

预取只押注高分 expert：用 GPU 上已有的参数提前预测下一层的 top expert（GPU 相对空闲，预测不占关键路径），预取带宽花在刀刃上——高分 expert 替不得，必须真身上场
CPU 也是算力：低 batch 下 CPU 直接算一个 expert（0.56-2.2ms）和 PCIe 搬运（0.75-2.3ms）是同一量级，与其干等搬运，不如让 CPU 就地算。SMoE 用双指针策略在”PCIe 搬到 GPU 算”和”CPU 就地算”之间做负载均衡

三条流水线（GPU 计算 / CPU 计算 / PCIe 加载）的编排如下：

GPU、CPU、加载三条流水线的跨层编排

4. 效果

三个平台组合（DeepSeekMoE+3080Ti、XverseMoE+4060Ti、Qwen2MoE+A6000），五个任务，对比 llama.cpp、MoE-Infinity、DeepSpeed、HybriMoE：

五个 workload 上的 TPOT 对比

decode 延迟（TPOT）比最优 baseline 平均降 24%（batch=1）/ 35%（batch=3），摘要里那个 48% 是相对更广基线的总体口径；绝对值看，S3（Qwen+A6000）batch=3 时 SMoE 跑到 0.09s/token，HybriMoE 要 0.16s
GPU cache 命中率 70% 上下，比 baseline 们的 30-40% 高出一截：

GPU 缓存命中率对比

精度是替换方案最容易被质疑的地方，论文扫了 α 从 0 到 0.6 的全谱（8 个 benchmark × 3 个模型）。结论：α ≤ 0.3 时精度基本无损——GaoKao 上 Qwen 的精度甚至从 73.5% 涨到 76.1%（α=0.25），作者归因于轻微扰动起了类似正则化的作用；α 拉到 0.5 以上才开始看到一致的下降（掉 1-2 个点）。MT-Bench、HumanEval 这类生成任务也是同样的模式。

消融显示替换（CE）、预取、CPU 协同三个组件各自贡献都在，其中替换是命中率提升的主力。

5. 一点个人 take

这篇论文动了一个大家默认不敢动的东西：路由结果的忠实性。所有 offloading 工作都把 router 的输出当圣旨，只优化执行；SMoE 说低分 expert 的选择本来就带噪声，在分数带内换一个功能相近的，输出扰动比量化还小。从 ExpertFlow 时期我就有个体感——gate score 的信息量远没被榨干，大家只拿它做 top-k 排序，其实它还告诉你”这个选择有多重要”。SMoE 是我看到的第一个把这层信息用在调度决策上的系统工作。
和前几天解读的 ST-MoE（时空相关性预取）对照着看很有意思：ST-MoE 赌”我能预测你要谁”，SMoE 赌”你要的那个其实可以不给”。预取是把搬运藏起来，替换是把搬运消灭掉，两者完全正交，理论上可以叠加——预取管高分 expert，替换管低分 expert，正好是同一个分数轴的两端。
冷静的部分：α 的最优值有模型依赖性（精度-速度 trade-off 曲线不同模型形状不一样），实际部署要自己扫一遍；另外”score 相近 ≈ 功能相似”这个假设在论文里是用端到端精度间接验证的，没有从表征层面深挖——万一某些模型的 expert 特化程度很高（比如代码 expert 和数学 expert 分数相近但功能迥异），替换的风险会大一些。HumanEval 上 DeepSeek 的 pass@1 波动（26.7→20.7 @ α=0.6）可能就是这个信号。

欢迎评论区交流，尤其是在边缘设备上折腾 MoE 的朋友。

顺带扯一句题外话：SMoE 的”expert 平替”思路——用功能相似的组件替换开销大的组件、再用端到端指标验证损失——和模型压缩里的结构化剪枝、模型融合是同一个方法论家族。我们把这条线的积累整理成了《动手学 AutoML：从 NAS 到大语言模型优化实战》，第 8 章讲 LLM 压缩与模型融合，实战篇有 LLM 后训练剪枝的完整代码，感兴趣的读者可以对照着看：剪枝是”永久删掉不重要的”，SMoE 是”临时替换不重要的”，殊途同归。