HOPE二阶剪枝法：MoE模型50%剪枝率下如何保住专家协作

为什么 MoE 模型需要更聪明的剪枝

混合专家模型（Mixture-of-Experts, MoE）眼下已经是大语言模型扩充参数规模时最常走的路子。拿 Qwen3.5-122B 来说，参数规模达到数千亿，可它真正的长处在于稀疏激活：任意一个输入 token 进来，被调用的专家网络都只占极小一部分。

麻烦也就出在这儿：算的时候是稀疏的，占内存却是实打实的稠密。Qwen3.5-122B 的 48 个 MoE 层，每层 256 个专家，这些专家的多层感知机（MLP）参数差不多吃掉了模型总内存 footprint 的 95%，约 250 GB。可处理单个 token 时，每层真正用上的专家只有 8 个。也就是说，显存里绝大部分参数在当下这一刻是“沉默”的。

内存卡在这里，专家剪枝（Expert Pruning）就成了一个顺理成章的解法：把判定为“没用”的专家直接永久删掉。动态加载、卸载专家会带来延迟，剪枝没有这个问题，它一次做完、不用重新训练，还能和量化技术搭着用。思路不复杂，难的是拿什么标准判断：删掉谁才最安全？

现在的主流做法基本都属于一阶剪枝。它们通常基于校准数据集给每个专家单独打一个分，再按分数从低到高把末尾的切掉。这套做法背后藏着一个假设：每个专家的贡献是各自独立的。可现实不是这样。研究观察到，MoE 里的专家会结成稳定的协作群组，有些专家总是一起出现，成对或者成群。要是无视这层互动，随手切掉一个看着不重要的专家，整个协作网络可能被破坏，模型性能跟着大幅下滑。

亚马逊云科技团队新提出的 HOPE（Higher-Order Pruning of Experts）针对的正是这一点。这是一套二阶剪枝方法，除了专家个体的重要性，还把专家两两之间的交互强度算进去。在 50% 的高比例剪枝测试里，HOPE 的平均排名在所有对比方法中排在首位，智能体编程任务上比次优方法高出 6.1%。

专家从不单独工作

想弄明白 HOPE 的价值，得先看清楚 MoE 内部是怎么运转的。

一个标准 MoE 层里，设有 $E$ 个专家，每个输入 token $x$ 由路由网关独立分给 $K$ 个专家（一般 $K=8$）。网关会给每个专家算一个经 softmax 归一化的门控权重 $g_k(x)$，权重最高的 $K$ 个专家被选中，组成活跃集合 $T(x)$。这一层的输出，就是被选中的那些专家输出加权求和的结果。

要紧的地方在于，活跃集合 $T(x)$ 里的专家并非随机凑到一起。文献和实验都观察到，专家之间存在稳定的共激活模式（Co-activation patterns）。这种协作关系在训练早期就成形了，之后的训练里一直保持稳定。

一阶方法的盲区就在这里暴露出来。假定专家 A 单看分数不高，可它经常和极重要的专家 B 搭档干活。一阶方法见 A 分数低就把它删了，等 B 被激活时，原本由 A 补上的那块功能就空了，整个协作小组的功能因此受损。剪枝率低的时候这种效应还看不出来，可一旦剪枝比例上到 30%、50% 甚至更高，大批协作链接被切断，模型性能就会断崖式下跌。

HOPE 抓住的核心一点是：剪枝决策得把高阶效应算进去，尤其是 pairwise（成对）的交互。

HOPE 如何找出该删的专家

HOPE 的目标很清楚：找出一个剪枝集合 $P$，让剪枝后模型输出的变化（也就是剪枝误差）尽可能小。

真实剪枝误差直接算非常难，因为删掉某些专家之后，原本没被选中的替补专家会顶上来，整个路由分布随之改变。HOPE 用了一个巧妙的近似：定义一个可计算的上界 $Z$，它严格大于等于真实剪枝误差的主导项。

$$ Z = \left[ \sum_{j \in P \cap T(x)} g_j(x) |f_j(x)|_2 \right]^2 $$

公式里那个平方项值得留意。把平方和展开，交叉项 $g_i(x)g_j(x)|f_i(x)|_2|f_j(x)|_2$ 自然就冒出来了。这些交叉项捕捉的，正是专家 $i$ 和 $j$ 同时被激活时的联合贡献。一阶方法把这些交叉项丢掉了，只留对角线上的个体项；HOPE 则把它们用足了。

要找最优的剪枝集合，HOPE 把问题转成了一个二次规划（Quadratic Program, QP）：

$$ P^* = \arg\min_p p^\top F p $$

约束条件是 $p$ 为二进制向量（表示保留或删除），并且删除数量符合预算。核心在矩阵 $F$：

$$ F_{i,j} = \frac{1}{|\mathcal{X}{i,j}|} \sum{x \in \mathcal{X}_{i,j}} g_i(x)g_j(x)|f_i(x)|_2|f_j(x)|_2 $$

其中 $\mathcal{X}_{i,j}$ 指的是专家 $i$ 和 $j$ 同时被激活的全部 token 集合。

矩阵 $F$ 的对角线元素 $F_{k,k}$ 量的是专家 $k$ 的个体重要性，这跟现有的一阶方法（比如 REAP）用的评分几乎一模一样（Spearman 相关系数高达 0.988）。非对角线元素 $F_{i,j}$ ($i \neq j$) 量的则是专家 $i$ 和 $j$ 之间的协作强度。

实际操作时，HOPE 只需对校准数据集跑一次前向传播，把统计信息收集起来构建 $F$ 矩阵。求解这个二次规划并不费时，每层 1-2 秒，跟数据采集花的时间比可以忽略不计。

可视化结果显示，$F$ 矩阵有明显的块状结构（Block Structure），在 GLM-4.5-Air 等模型的中后期层里尤其突出。那些亮块对应的是彼此紧密协作的专家群落。HOPE 要做的，就是在砍掉一半专家的同时，让这些亮块尽量保持完整。

实验结果：高剪枝率下的优势

研究团队选了三个主流 MoE 模型做测试，分别是 Qwen3.5-122B、Qwen3.5-35B 和 GLM-4.5-Air，校准数据用的是 Evol-CodeAlpaca 和 SWE-Bench Verified，评估则在 Tulu3 套件和 SWE-Bench Pro（智能体编程基准）上展开。

拿来对比的基线方法有四种一阶剪枝算法：REAP、MAN、EAN 和 Frequency。剪枝比例覆盖 10% 到 50%。

整体表现

全部测试条件下，HOPE 的平均排名是 2.07（共 5 种方法，数值越低越好），39% 的情况排第一，67% 的情况进前两名。剪枝率越高，HOPE 的优势越明显。

到了最具部署意义的 50% 剪枝率，HOPE 的平均排名升到 1.58，次优的 REAP 只有 2.42。原因在于高剪枝率下被切断的协作链接更多，二阶交互信息这时候就变得关键了。

智能体编程任务的突破

SWE-Bench Pro 上，HOPE 的优势格外突出。这个基准要求模型自己去解决 GitHub 上的真实 Issue，涉及写代码、调用工具和多步推理。这类任务往往要调动多样化的专家组合，对协作结构是否完整相当敏感。

在 Qwen3.5-35B-A3B 模型上做 50% 剪枝后：

• HOPE 得分：42.3
• 未剪枝原模型得分：41.8
• REAP 得分：36.2

砍掉一半专家，HOPE 的性能没降，反而比原模型略高一点。研究人员推测，这可能是因为去掉了一些引入噪声的低相关性专家，起到了正则化的作用。REAP 则出现了 13% 的性能回退。这一结果说明，在复杂的代理任务里，保住专家之间的协作结构，比只留住个体高分专家更重要。

实验还发现，即使用代码数据做校准，HOPE 在非代码类的 Tulu3 基准上也没有严重退化，泛化性表现不错。

为什么 HOPE 更有效？

研究人员分析了 HOPE 和 REAP 产生分歧的专家，发现 HOPE 更愿意留下协作分数高的专家，哪怕这些专家的个体分数略低。换句话说，它宁可牺牲个别“明星专家”，也要保全整个“团队协作”。这种全局优化的视角，正是一阶方法被它超越的根本原因。

如何使用 HOPE

亚马逊云科技已把 HOPE 的代码库开源，支持 Qwen3、Qwen3.5 和 GLM-4.5 等模型。整个流程分三步：校准、求解、剪枝。

第一步：校准（Calibrate）

这一步要跑一次前向传播，把专家激活的统计信息收集起来。

hope calibrate \
    --model-path Qwen/Qwen3.5-35B-A3B \
    --prompts calibration_prompts.txt \
    --out-path observations.h5

输出是一个 HDF5 文件，构建 $F$ 矩阵所需的数据都在里面。

第二步：求解二次规划（Solve QP）

用收集到的数据，求出最优的剪枝集合。

hope solve \
    --obs-path observations.h5 \
    --prune-frac 0.50 \
    --out-path pruneset.json

这一步会生成一个 JSON 文件，列出需要删除的专家索引。求解很快，每层只要几秒。

第三步：执行剪枝

拿到生成的剪枝集合后，就可以创建新的模型检查点了。

hope prune \
    --model-path Qwen/Qwen3.5-35B-A3B \
    --pruneset-path pruneset.json \
    --out-path ./Qwen3.5-35B-A3B-pruned-50

新模型是标准的 HuggingFace 检查点，加载即可使用，vLLM、SGLang 等推理框架的代码不用做任何改动。磁盘和内存占用也随之下降。

开发者同样能通过 Python API 在代码里直接调用：

from hope.calibrate import calibrate
from hope.solve import solve
from hope.prune import prune_model
calibrate("Qwen/Qwen3.5-35B-A3B", calibration_prompts, "observations.h5")
solve("observations.h5", prune_frac=0.50, out_path="pruneset.json")
prune_model("Qwen/Qwen3.5-35B-A3B", "pruneset.json", "./Qwen3.5-35B-A3B-pruned-50")

局限与后续方向

HOPE 表现虽好，却谈不上万能。

第一，它的长处集中在高剪枝率区间，也就是 40%-50% 这一档。到了 10%-20% 的低剪枝率，REAP、MAN 这类一阶方法有时也能拿到差不多的结果，HOPE 能多赚的提升并不多。

第二，眼下的 HOPE 是一层一层单独处理的，层与层之间的专家交互没有被纳入考虑。论文里虽然给出了跨层 HOPE 的理论框架，可初步结果还不够成熟。MoE 各层之间存在依赖，跨层优化或许会是今后一个要紧的方向。

第三，HOPE 只抓住了 pairwise（二阶）交互。从理论上说，三元组乃至更高阶的交互可能携带更多信息，但计算复杂度会按组合级往上翻，难度估计极大。怎么在算力开销和更高阶信息之间找平衡，目前仍是个开放问题。

说到底，HOPE 给出的是一种更细的观察角度，让人重新审视 MoE 模型的结构。它也提醒开发者：模型轻量化不光是比单个专家的强弱，群体之间怎么配合同样要尊重。对要在有限资源下部署超大 MoE 模型的人来说，HOPE 值得上手试一试。