HOPE 二阶专家剪枝：MoE 砍掉一半专家还能不掉 SWE-Bench 分，凭什么？

笔名：小六 / 上海 / 1995 女 / 某互联网公司工程师

先说结论

11 月 9 日，亚马逊团队在 Hugging Face 博客发布 HOPE（Higher-Order Pruning of Experts），把 MoE 专家剪枝从「给每个专家打一个独立分数」改成「按专家之间的配对协作强度做一次二次规划求解」。论文挂在 arXiv（编号 2609.18916），代码在 awslabs/HOPE 仓库。

我的结论：这条路线真正解决的不是「剪枝能省显存」这个老命题，而是「剪枝为什么会在高强度剪枝时崩掉」这个具体病因——它把专家协作当成一阶方法看不见的结构，然后用一个可解的二次规划把它捞回来。工程上最值钱的两个数字是：50% 剪枝率下，Qwen3.5-35B-A3B 在 SWE-Bench Pro 上 42.3 分，比未剪枝的 41.8 还略高；而同条件下上一代方法 REAP 掉到 36.2，退步 13%。代价是它只在 40%–50% 这种激进区间领先，低剪枝率下并不占优。

发生了什么

官方事实一：发布主体、时间与位置。 主来源是 Hugging Face 博客的亚马逊投稿栏目《Your Experts Have Partners. There’s HOPE for Keeping Them Together》，页面标注发布日期 2026 年 11 月 9 日，作者 Alex M Tseng（与 Prannay Kaul、Luca Zancato、Wei Xia、Stefano Soatto 共同署名）。原始 URL 见文末 Q&A。同一天对应论文与开源代码库一并放出。

官方事实二：它针对的是一个具体的显存账。 官方开篇给了一个非常具体的例子：Qwen3.5-122B 在 48 个 MoE 层里每层有 256 个专家，约 250 GB 的参数显存里，95% 全部被这些专家 MLP 占掉；但对任何一个 token，每层实际只用到 8 个专家。也就是说，绝大多数专家在推理时是闲置的，却必须常驻显存。这正是 MoE 的「便宜算力、昂贵内存」结构性问题。

官方事实三：剪枝本身不新，难点在「剪谁」。 官方明确说，专家剪枝是应对这个内存瓶颈最直接的办法之一：永久删掉最没用的专家，不需要训练，可以和量化叠加，也不会像动态加载/卸载那样引入延迟。真正难的是判断哪些专家「删了最安全」。既有方法（REAP、MAN、EAN、Frequency 等）都是一阶的——给每个专家单独打分，逐层独立地砍掉分数最低的。它们的隐含假设是「每个专家的贡献与别的专家无关」。

官方事实四：这个假设是错的。 官方给出的观察是：专家会形成稳定的协作群组，被持续共同激活；这个现象在训练早期就出现并稳定下来，独立研究也验证过「专家协作是 MoE 的稳定属性，且对性能重要」。于是删除专家 A 看似无害，但若与 A 高频协作的 B 很重要，删 A 就等于拆掉一个协作群——一阶方法完全看不见这一层，因为 A 和 B 是分开打分的。这个效应在剪枝率高时被放大：砍到 50% 时，会打断大量协作链路。

相关背景（非当日新闻，作为对照）。 11 月 4 日同一批 Hugging Face 博客里出现过 Dharma Field Extractor（2B 专用模型做文档字段抽取），11 月 5 日是 NVIDIA Cosmos 3 的四个开放检查点，11 月 6 日是 AllenAI 的 ToyBlocks 机器人基准。这几天的一条共同线索是「把大而全的东西切成小而专用的部件」；HOPE 属于这条线索的另一端——不换模型，只把已有 MoE 的冗余结构拆掉。

技术细节

1. 一阶 vs 二阶：差别就在那个交叉项

标准 MoE 里，每层有 E 个专家，每个 token 被路由到 top-K（常见 K = 8）。路由层输出 softmax 归一化的门控权重，取权重最高的 K 个专家构成激活集，层输出是这些专家输出的加权和。

一阶方法只看「单个专家的贡献」。HOPE 的做法是先定义一个代理量 Z：对被剪掉的、本来会被选中的那批专家，把它们的门控权重与输出范数乘起来再求平方和。官方强调 Z 是剪枝误差主导成分的严格上界。关键在「平方」这一步：平方展开天然产生成对的交叉项——两个专家的门控权重相乘、输出范数相乘。这些交叉项就是一阶方法丢掉的东西。

2. 把剪枝变成一个二次规划

于是问题被重写成：在给定剪枝预算下，找一个剪枝集合，使校准集上的期望 Z 最小。官方把它化成二次规划：目标是最小化「选择向量转置 × F 矩阵 × 选择向量」，约束是选择向量为 0/1、且 1 的个数等于预算。

F 矩阵的定义很直白：每个元素 F(i,j) 是「专家 i 与 j 同时被激活的那些 token 上，两者门控权重乘积 × 两者输出范数乘积」的平均值。对角元素 F(k,k) 衡量单个专家的重要性；非对角元素衡量成对的协作贡献。求解时用连续松弛再取整到 0/1，官方给出的耗时是每层 1–2 秒，相对校准前向传播的总时间可以忽略。

3. 一个很硬的验证：对角项几乎就是 REAP 的排名

官方专门做了一次对照：F 矩阵的对角项，与上一代最强一阶方法 REAP 的专家排名几乎完全一致——Spearman 相关系数 ρ = 0.988，差别只在专家贡献的方差口径。这句话的工程含义很重：HOPE 相对 REAP 的全部增益，都可以归因于非对角的那部分交互项，而不是「换了个更好的单专家打分公式」。这是一条干净的可归因链条，也是我认为这篇发布最可信的地方。

4. 实验结果：平均排名 2.07，50% 剪枝率下 1.58

评测设置：3 个模型（Qwen3.5-122B、Qwen3.5-35B、GLM-4.5-Air），2 套校准数据（Evol-CodeAlpaca 与 SWE-Bench Verified 轨迹），测试集用 Tulu3 套件加 SWE-Bench Pro（agentic coding），对照组是 4 个一阶基线（REAP、MAN、EAN、Frequency），剪枝率从 10% 扫到 50%。

总体结果：HOPE 在所有条件下的平均排名是 2.07（5 个方法里），top-1 占比 39%，top-2 占比 67%；在多数条件下对每个基线都是正面赢。随着剪枝率上升，优势扩大：50% 剪枝率时平均排名升到 1.58，而第二名 REAP 是 2.42。

最值得单独拎出来的是 SWE-Bench Pro：这是要求模型自主解决真实 GitHub issue 的 agentic coding 基准，任务组合多样（写代码、调工具、推理），多轮交互，天然会激活更多样的专家组合——正是「保住协作结构」最有价值的场景。Qwen3.5-35B-A3B 在 50% 剪枝下拿到 42.3，而未剪枝版本是 41.8；同条件 REAP 是 36.2，相对未剪枝退步约 13%。

5. 官方自己承认的边界

官方在「局限」一节写得很清楚，值得原样记住：

• 优势主要在 40%–50% 这种激进剪枝率；10%–20% 的低剪枝率下，REAP 和 MAN 这类一阶方法有时能打平，HOPE 的优势会缩小。
• 和多数专家剪枝算法一样，HOPE 逐层独立剪枝，不处理跨层交互；论文里给了跨层框架，但结果还是初步的。
• 它只建模成对交互；三元组以上的更高阶交互可能还有信号，但组合爆炸，难以估计。

另外官方也解释了「剪过的模型偶尔能追平甚至超过未剪枝版本」这个反直觉现象：可能是因为删掉低相关专家后，目标任务上的噪声变少了。官方特意说明这不是 HOPE 独有，别的剪枝方法也观察到过。

6. 三步命令与一个关键事实：产物是标准检查点

官方给的流水线是三段：hope calibrate 用 HuggingFace transformers 钩住每层 MoE 的前向，记录每个 token 的选中专家、门控权重、输出范数和成对共激活统计，落成 HDF5 里的 F 矩阵；hope solve 求解二次规划，输出剪枝集合 JSON；hope prune 生成更小的模型检查点。官方强调最后一步产物是标准 HuggingFace 检查点，磁盘和内存都更小，vLLM 和 SGLang 的模型定义不需要改。这一点比分数更影响落地：剪枝后的模型可以直接塞进现有推理栈，不用改服务端代码。

官方说这套包已在 Qwen3、Qwen3-Next、Qwen3.5 和 GLM-4.5 上测过。校准只做一次前向，用 agentic rollout 或单轮轨迹都行——也就是说校准数据可以就是你自己业务里的真实调用轨迹，这一点对内部落地很关键。

对 Agent / 工程的影响

立刻能用上的场景：

• 自托管 MoE 的显存账：如果你在本地或私有集群跑 Qwen3.5、GLM-4.5 这类 MoE，显存里 95% 被闲置专家占着这件事就是硬成本。50% 剪枝带来的显存下降，直接换成更长的上下文、更深的推理链、更多的工具调用轮次——这三样恰好是 Agent 系统最吃资源的部分。
• 长跑 agent 的稳定性：SWE-Bench Pro 那组数字的意义不只是分数，而是「多轮、多工具、组合多样」这种形态下剪枝没有崩。Agent 场景的 token 分布比单轮问答散得多，一阶剪枝在这种分布上更容易误删协作群；用二阶口径做校准，等于把校准集换成你自己的 agent 轨迹。
• 不改推理栈：产物是标准检查点，vLLM/SGLang 不用改定义。这意味着可以在现有部署上做一次「模型瘦身」，不需要配套改服务代码。

需要进一步验证的：

• 校准集就是你的业务分布：官方用的是代码类轨迹（Evol-CodeAlpaca、SWE-Bench Verified）。如果你的 agent 主要做文档抽取、客服、报表查询，专家协作结构大概率不同，F 矩阵必须用自己的轨迹重算，不能照抄官方剪枝集合。
• 剪枝率的选择：40%–50% 是优势区间，但也是风险区间。10%–20% 用一阶方法更省事且不差。真正的决策点是「显存缺口有多大」，不是「哪个方法排名高」。
• 跨层效应：逐层独立剪枝意味着层与层之间的补偿关系没被建模。深层被剪后浅层是否需要同步调整，官方只说框架初步，没给可用结果。

短期不要碰的：

• 别把它当「通用压缩」用。它只删专家，不处理注意力头、embedding 层、量化误差；要和量化叠加才有完整收益。
• 别在没跑过自家校准集的情况下，把官方的 42.3 分当成自己业务的预期。

我的判断

第一，这是一篇「病因明确」的论文，不是「又一个 SOTA」。 它把一阶剪枝在激进区间崩掉的原因定位到「协作群被拆」，并用 ρ = 0.988 的对角项对照证明增益全部来自交互项。这种可归因的结构，比一个漂亮的平均排名更值得信任。

第二，50% 剪枝率 + agentic coding 不掉分，是这条路线最实用的卖点。 但它的适用范围也正好卡在这里：低剪枝率不占优，跨层没解决，三元组没建模。所以它是「显存真的不够、且业务是长跑 agent」时的解法，不是默认解法。

第三，落地顺序应该是「先换校准集，再换剪枝率」。 先用自己业务轨迹跑一次 calibrate，看 F 矩阵的块结构是否明显；块结构清晰说明协作群存在，二阶口径才有意义。然后再按显存缺口选剪枝率，而不是先追排名。

Q&A

Q1：来源/出处？
A：主来源是 Hugging Face 博客的亚马逊投稿《Your Experts Have Partners. There’s HOPE for Keeping Them Together》，页面标注发布日期 2026-11-09，URL：https://huggingface.co/blog/amazon/higher-order-pruning-experts 。对应论文《Higher-Order Pruning of Experts in Mixture-of-Experts Language Models》，arXiv 2609.18916，URL：https://arxiv.org/abs/2609.18916 。开源代码库：https://github.com/awslabs/HOPE 。文中所有分数、排名、剪枝率、模型规格均取自该博客正文与论文摘要。

Q2：能不能复现／怎么验证？
A：可以，且不需要重训。最小验证三步：一，准备一批你自己的调用轨迹当校准集；二，跑一次 calibrate 得到 F 矩阵的 HDF5；三，在 20% 和 50% 两个剪枝率各解一次，分别在你的评测集上对照未剪枝版本。判断标准不是「分数有没有涨」，而是「50% 剪枝下相对未剪枝的退步是否小于一阶基线」——这才是 HOPE 声称的优势区间。另可先看 F 矩阵可视化：若对角块结构明显，说明协作群真实存在。

Q3：适用边界是什么？
A：适合显存确实不够、模型是 MoE 架构、业务分布偏多轮多工具的 agent 场景。不适合稠密模型（没有专家可剪）、不适合只需要省一点显存的轻度压缩（10%–20% 用一阶更简单）、也不适合把剪枝当唯一压缩手段的场合（需与量化叠加）。

Q4：和 REAP 的关系到底是什么？
A：不是替代关系，是包含关系。HOPE 的 F 矩阵对角项几乎复刻了 REAP 的专家排名（ρ = 0.988），所以 HOPE 等于「REAP 的单专家打分 + 成对交互项」。这也意味着：如果你的场景里协作结构不明显，两者结果会非常接近，用 REAP 更省事。

Q5：实施有什么坑？
A：三个。一是校准集必须匹配业务分布——用代码轨迹算出的剪枝集合套到文档任务上，协作群可能对不上；二是剪枝集合是逐层的 0/1 向量，层间不协调，剪完必须整模型重测而不是逐层抽检；三是「偶尔追平未剪枝」这个现象别当成保证，官方自己说这来自噪声减少，不是稳定收益，做预算时按退步上界留余量。