Hugging FaceAI 领域最新发展2026-11-09约 13 分钟5,355 字

你的专家有搭档：HOPE 让它们保持在一起

本文目录

引言#

混合专家（Mixture-of-Experts，MoE）模型让最先进的大语言模型（LLM）得以扩展到数千亿参数，但它们有一个根本且代价高昂的附带问题：推理时每个专家 MLP 都必须占用内存，哪怕对任意给定 token 来说绝大多数专家都处于空闲状态。例如，Qwen3.5-122B 的 48 个 MoE 层中每层有 256 个专家，其约 250 GB 参数内存占用中有 95% 完全被这些专家 MLP 占据。然而，对任意给定 token，每层实际只用到 8 个专家。

专家剪枝（expert pruning）是解决这一内存瓶颈最直接的办法之一，即永久删除最没用的专家。剪枝避免了动态加载/卸载专家所带来的延迟问题，不需要任何训练，还能与量化组合使用。鉴于这些诱人的好处和思路的简洁性，专家剪枝成为缩小 MoE 的常用方法也就不足为奇了。难点在于判断哪些专家删除最安全。

现有剪枝方法独立地给每个专家打分：基于校准数据集为每个专家分配一个标量重要性分数，然后（在每一层内独立地）剪掉最不重要的专家。这些是一阶方法（first-order methods），因为它们假设每个专家的贡献与其他专家无关。现实中，专家会形成协作群体。我们在自己的实验中观察到稳定的共激活专家簇，其他独立研究也表明，专家协作是 MoE 的一种稳定属性，并且对模型性能很重要。忽略这些相互作用会导致次优剪枝，在激进剪枝率下尤其如此。

我们的最新论文提出了 HOPE（Higher-Order Pruning of Experts，专家高阶剪枝），这是一种考虑专家两两相互作用的二阶方法（second-order method）。在 50% 剪枝率下，HOPE 取得了所有方法中最好的平均排名，在智能体编程任务上比次优剪枝方法最多提升 +6.1%。

本文将解释 HOPE 的工作原理，展示它在哪些地方优于现有方法，并说明如何将它用于你自己的模型。对于不熟悉 MoE 架构的读者，请参阅《Transformer 中的混合专家（MoEs）》。

专家不是单打独斗#

在标准 MoE 中，每层有 E 个专家，每个输入 token x 被独立路由到 K 个专家（K=8 是常见选择）。路由由一个层执行，它为每个专家 k 生成经 softmax 归一化的门控权重 g_k(x)，其中门控权重最高的 K 个专家被选为活跃专家集合 T(x) ⊂ {1,...,E}。该层的输出为 Σ_{k∈T(x)} g_k(x) f_k(x)，其中 f_k(x) 是专家 k 对 token x 的输出。

左：典型 MoE 层，每个 token 被路由到 top-K 专家。右：一阶方法根据标量重要性分数对专家排序并删除，但最佳剪枝决策还应考虑专家之间相互作用的强度。

重要的是，被选中集合 T(x) 中的专家并非彼此独立。专家会形成稳定的协作群体，持续地被一起激活。文献中此前也观察到了这一点：专家共同选择模式在训练早期就会出现，并在整个训练过程中趋于稳定。

这意味着，当我们从 MoE 层中剪掉专家时，剪枝决策需要考虑这些专家之间的高阶效应。单独看，删除专家 A 似乎没问题；但如果与 A 经常协作、依赖 A 的专家 B 非常重要，那么仅仅删除 A 就会拆散一个协作群体。一阶方法完全错过了这一点，因为它们分别给 A 和 B 打分。

这种效应在高剪枝率下会累积。当我们删除多达 50% 的专家时，就有可能破坏许多协作链接。这正是二阶剪枝最具优势的地方。

HOPE 如何确定剪枝集合#

（HOPE 目标的完整推导见对应论文的附录 A。）

当我们从某个 MoE 层删除一组包含 P 个专家的集合时，被选中的专家集合 T(x)（对任意 token x）可能会改变。原本会被选中的被剪专家，将由门控权重次高的专家替代。由此产生的层输出变化就是剪枝误差。我们的目标是找到剪枝集合 P（满足预定义的剪枝预算 |P|），使（在校准集的 token x 上）产生的剪枝误差最小。

遗憾的是，直接最小化关于 P 的剪枝误差是难以处理的。剪枝误差取决于替代专家的身份，而后者又取决于剪枝集合 P 本身。HOPE 通过定义一个可处理的替代量 Z 来绕开这个问题，Z 严格上界了剪枝误差的主导部分：

Z = [ Σ_{j∈P∩T(x)} g_j(x) · ||f_j(x)||_2 ]²  ≥  真实误差

由于 Z 是平方和，展开它自然会生成专家两两之间的交叉项 g_i(x)·g_j(x)·||f_i(x)||_2·||f_j(x)||_2。这些就是一阶方法丢弃的相互作用项。

为了找到最优剪枝集合，HOPE 在校准集上最小化 E[Z]，这可以重写为如下二次规划（quadratic program，QP）：

P* = argmin_p  pᵀFp
     满足  p ∈ {0,1}^E,  Σ_{k=1}^E p_k = |P|

其中 F ∈ R^{E×E} 定义为：

F_{i,j} = (1/|X_{i,j}|) Σ_{x∈X_{i,j}} g_i(x)·g_j(x)·||f_i(x)||_2·||f_j(x)||_2
其中  X_{i,j} = {x : i,j ∈ T(x)}

这个 F 矩阵在校准数据集上收集，最优剪枝集合通过用连续松弛求解所得二次规划获得（然后舍入为二值解）。每个元素 F_{i,j} 表示在专家 i 和 j 同时被激活的 token 上，两者门控加权输出乘积的平均值。对角线元素 F_{k,k} 衡量单个专家的重要性，而非对角线元素（i≠j 的 F_{i,j}）衡量两两协作贡献。

F 在实践中长什么样？它展示了专家协作的结构，而这种结构取决于层：

GLM-4.5-Air（每层 128 个专家，共 106B 参数）在三个代表性层（前、中、后）的交互矩阵 F 可视化。专家已经过聚类以显示块结构。沿对角线的亮块表示具有强两两互动分数的专家组。

就实际成本而言，HOPE 需要与任何其他专家剪枝方法相同的校准过程（在校准数据上做一次前向传播）。唯一的额外工作是求解二次规划；它是非凸的，但可以用标准 QP 求解器高效求解（每层 1–2 秒）。与一阶方法相比，总附加开销可以忽略不计，因为校准时间占主导。

与 REAP 的联系#

值得注意的是，HOPE 与 Router-weighted Expert Activation Pruning（REAP，路由加权专家激活剪枝）——一种最先进的一阶专家剪枝方法——有很强的联系。HOPE 的 F 矩阵在对角线上编码了单个专家的重要性分数，而这条对角线实际上恢复了 REAP 用来独立排序专家的分数（区别仅在于专家贡献的方差）。F 的对角线几乎完美地恢复了 REAP 的专家排名（Spearman ρ=0.988）。因此，HOPE 相对 REAP 取得的任何改进，都可归因于 F 矩阵非对角线元素中的二阶交互项。

结果#

我们把 HOPE 作为专家剪枝方法，在 3 个模型（Qwen3.5-122B、Qwen3.5-35B 和 GLM-4.5-Air）和 2 个校准数据集（Evol-CodeAlpaca 和 SWE-Bench Verified 轨迹）上进行了评估。我们用 Tulu3 套件和 SWE-Bench Pro（智能体编程）测试剪枝后的模型，在从 10% 到 50% 的剪枝率上，将 HOPE 与 4 个一阶基线（REAP、MAN、EAN 和 Frequency）进行比较。

HOPE 在所有条件下取得最佳总体排名，并在激进剪枝率下占据主导。左：所有模型、校准集和基准上的平均排名（越低越好）。右：Qwen3.5-35B 上的 SWE-Bench Pro 表现。

在所有条件下，HOPE 取得了最佳平均排名（5 种方法中为 2.07），拥有最高的第一名比例（39% 的条件）和前三名比例（67%）。在头对头比较中，HOPE 在大多数条件下击败了所有其他基线。

正如预期，HOPE 的优势在更高剪枝率下会扩大。删除的专家越多，被破坏的协作链接就越多，F 的非对角线项也就越重要。在 50% 剪枝率下，HOPE 的平均排名提升到 1.58（次优方法 REAP 为 2.42）。这也是与部署最相关的设置：内存节省足够大，可以容纳更长的上下文、更深的推理和更多的工具调用。

HOPE 的优势在 SWE-Bench Pro 上最为明显，这是一个智能体编程基准，模型必须自主解决真实的 GitHub issue。这些问题涉及跨多轮、组合多样化的任务（例如编程、工具调用、推理等），很可能会用到多样化的专家组合——这正是保留协作结构最重要的场景。在 50% 剪枝的 Qwen3.5-35B-A3B 上，HOPE 在 SWE-Bench Pro 上达到 42.3，与未剪枝模型的 41.8 相当（而 REAP 降至 36.2，回退 13%）。

值得注意的是，剪枝后的模型偶尔能持平甚至超过未剪枝基线，这可能是因为删除低相关专家减少了目标任务上的噪声。这种效应并非 HOPE 独有，在其他剪枝方法中也有观察到。此外，我们的实验表明，使用任何剪枝方法（包括 HOPE）进行以代码为重点的校准，都不会严重降低非编程基准；而且无论使用哪个校准集，HOPE 在 Tulu3 套件上都表现良好。

HOPE 保留了更多协作专家#

保留专家的平均协作强度（以 F 矩阵值衡量），按 HOPE 与 REAP 意见不一致的专家拆分。

HOPE 的优势源于在整个交互矩阵 F 上进行优化。为了理解这在实践中如何影响剪枝决策，我们考察了 HOPE 与 REAP 意见不一致的专家。对于每个有争议的专家，我们计算其协作分数（即它与其他被保留专家的平均 F 值）。仅由 HOPE 保留的专家，其协作分数始终高于仅由 REAP 保留的专家。换言之，作为 QP 优化的一部分，HOPE 牺牲了一些单独得分高的专家，以保留协作簇。基准性能的提升（如上所示）验证了这种权衡是有利的。

如何运行 HOPE#

我们创建了一个基础包来运行 HOPE。它有三个步骤：1）校准；2）求解；3）剪枝。我们的包已在 Qwen3、Qwen3-Next、Qwen3.5 和 GLM-4.5 上测试过。

第一步：校准#

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

校准步骤在校准数据上运行一次前向传播，无论数据是智能体 rollout 还是单轮轨迹。它使用 HuggingFace transformers 挂接每个 MoE 层的前向传播。对于每个 token，它记录哪些专家被选中、其门控权重、输出范数以及两两共激活统计。这一步的输出是 F 矩阵，存储在 HDF5 文件中。

第二步：求解 QP#

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

该命令生成 F 矩阵，并通过连续松弛求解二值二次规划。每层需要几秒钟，输出是一个包含剪枝集合的 JSON 文件。严格来说，这就是 HOPE 算法的最终输出。

第三步：剪枝#

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 的局限#

HOPE 的优势在更高剪枝率（40–50%）下最为明显。在较低剪枝率（10–20%）下，REAP 和 MAN 等一阶方法有时也很有竞争力，HOPE 的优势会缩小。此外，与大多数专家剪枝算法一样，HOPE 独立剪枝每一层，不考虑跨层交互。在论文中，我们提出了跨层 HOPE 的理论框架，但结果仍是初步的。最后，HOPE 捕捉的是两两交互，但更高阶的交互（三元组及以上）可能提供额外信号，尽管它们在组合上难以估计。

引言#