Amazon HOPE：剪专家也要保搭档

Amazon 在 11 月 9 日公开了 HOPE，一种专门面向混合专家模型的高阶专家剪枝方法。它解决的问题很直接：过去的剪枝算法只看每个专家单独有多重要，HOPE 则进一步判断哪些专家经常一起工作，尽量避免把一个有效的“专家小组”拆散。

**HOPE 是一种将专家两两交互关系纳入优化目标的 MoE 免训练剪枝方法。**HOPE 的全称是 Higher-Order Pruning of Experts，其核心不是发明新的模型架构，而是改变“应该删除哪些专家”的决策方式。Amazon 团队在官方技术文章中称，在 50% 专家剪枝率下，HOPE 在智能体编码任务上的成绩最高比第二名高出 6.1%，并取得所有参评方法中最好的综合排名。(huggingface.co)

这项工作的价值不在于让 MoE 再多省几个百分点，而在于它指出了一个长期被简化的问题：专家的重要性不是一个只属于专家自身的标量，而是由它和其他专家的组合共同决定。

MoE 的计算省了，显存并没有跟着省

**混合专家模型是每次只激活部分前馈网络，但仍需保存全部专家参数的稀疏模型架构。**一个典型的 MoE 层会包含几十到数百个专家，路由器根据每个 Token 的内容，从中选出少量专家参与计算。

这套设计解决的是计算量问题，而不是参数驻留问题。

Amazon 给出的 Qwen3.5-122B 案例很典型：模型的 48 个 MoE 层分别包含 256 个专家，每个 Token 在一层中只会调用 8 个专家，相当于激活约 3.1% 的专家；但在推理时，全部专家仍然需要存放在内存或显存里。该模型约 250GB 的参数内存中，专家 MLP 占比达到 95%，也就是约 237.5GB。(huggingface.co)

**MoE 最大的部署矛盾，是计算路径稀疏、参数存储却依然稠密。**动态加载和卸载专家听起来合理，但在实际推理中，Token 的路由选择不断变化，频繁在 CPU、GPU 和存储之间搬运权重，很容易让数据传输延迟抵消稀疏计算带来的收益。

专家剪枝因此成了一个朴素但有效的方案：永久删除一部分专家，直接生成更小的模型检查点。它不需要重新训练，可以和量化叠加，而且不会在每次推理时增加额外的权重调度步骤。

如果对上述 Qwen3.5-122B 做 50% 的均匀专家剪枝，并暂时忽略元数据和结构差异，那么专家参数理论上可从约 237.5GB 降至 118.8GB，模型总参数内存可粗略降到约 131GB。这个数字不是 Amazon 公布的实测显存，而是根据官方参数占比计算出的理想估算，但它足以说明高比例专家剪枝为什么对部署有吸引力。

传统剪枝的问题，是把团队绩效拆成个人 KPI

**一阶专家剪枝是为每个专家计算独立重要性分数，再删除低分专家的方法。**常见指标包括激活频率、路由权重、专家输出范数，或者几者的组合。

这种方法的优点是简单。只要对一批校准数据做一次前向计算，就能得到每个专家的分数，然后从低到高删除。

问题在于，MoE 路由器通常一次选择多个专家，而不是只选择一个专家。多个专家的输出经过路由权重加权后共同形成该层结果，这意味着专家之间并非互不相关。

可以把它理解成篮球阵容。球员 A 单独看得分不高，球员 B 的数据也不算突出，但两人同时上场时，一个负责掩护和传球，另一个负责终结，阵容效率反而很高。如果只按个人场均得分裁人，很可能先把这个组合拆掉。

**专家协作关系是多个专家在相同 Token 上稳定共同激活，并共同贡献层输出的统计关系。**Amazon 团队观察到，MoE 中存在明显的专家共激活簇，而且这种组合关系会随训练逐渐稳定。删除其中一个看似不重要的专家，可能影响另一个高价值专家的实际作用。(huggingface.co)

传统方法只比较专家 A 和专家 B 各自的重要性，HOPE 则会继续问一个问题：A 和 B 被一起删除时，造成的误差是否远高于分别删除它们时的误差之和？

这就是所谓的二阶信息。

HOPE 怎么把“搭档关系”算进去

**HOPE 的交互矩阵 F 是一个记录专家个体贡献与专家对协作强度的方阵。**对于拥有 E 个专家的 MoE 层，F 的尺寸为 E×E。

矩阵的对角线元素代表单个专家的重要性，非对角线元素代表两个专家同时被激活时的联合贡献。HOPE 统计的数据包括：

• 专家是否被路由器共同选中；
• 两个专家各自的路由权重；
• 两个专家输出向量的 L2 范数；
• 这种共同激活在校准数据中的平均强度。

HOPE 的目标可以简化为：在必须删除固定数量专家的约束下，寻找一个二进制选择向量 p，使 p^T F p 尽可能小。

**这个二次目标同时计算了删除单个专家的代价，以及同时删除一组专家造成的交互损失。**传统方法基本只使用 F 的对角线，而 HOPE 将非对角线也放进了优化过程。

HOPE 并不直接求解真实的模型输出误差，因为剪掉专家后，原本排在路由权重第九位或第十位的候选专家可能补位，替代关系会随剪枝集合改变，直接穷举几乎不可行。Amazon 的做法是构造一个可计算的误差上界，再把专家选择转化为二次规划问题，通过连续松弛求解并舍入为最终的二进制结果。(huggingface.co)

这里有一个值得注意的工程细节：HOPE 看起来比按分数排序复杂不少，但它没有显著增加校准成本。所有方法都需要让校准数据跑一次前向传播，HOPE 只是额外记录专家之间的共激活统计；之后每层求解二次规划大约需要 1 至 2 秒，主要耗时仍然来自模型前向计算。(huggingface.co)

它不是推翻 REAP，而是补上 REAP 丢掉的信息

**REAP 是一种根据路由权重和专家输出强度评估单个专家重要性的一阶剪枝方法。**Amazon 的实验显示，HOPE 交互矩阵 F 的对角线排序与 REAP 的专家排序高度一致，Spearman 相关系数达到 0.988。(huggingface.co)

这个结果很关键。它说明 HOPE 的收益并不是来自完全不同的个体评分指标，而是来自 F 矩阵的非对角线，也就是专家之间的交互项。

| 方法 | 决策依据 | 是否考虑专家协作 | 优点 | 主要风险 | |---|---|---:|---|---| | Frequency | 专家激活次数 | 否 | 实现简单、统计成本低 | 高频不等于高贡献 | | MAN | 专家激活或输出统计 | 否 | 无需重新训练 | 对专家组合不敏感 | | EAN | 专家输出相关指标 | 否 | 可直接生成剪枝排序 | 高剪枝率下容易破坏协作簇 | | REAP | 路由权重与输出强度 | 否 | 个体重要性评分较强 | 每个专家仍被独立评估 | | HOPE | 个体贡献与两两交互矩阵 | 是 | 高剪枝率下更稳健 | 仍未建模跨层和三元交互 |

**HOPE 的实际取舍，是允许保留某些单独得分不高、但与其他保留专家配合良好的成员。**Amazon 对 HOPE 与 REAP 产生分歧的专家进行了分析，结果显示，仅被 HOPE 保留的专家，与其余保留专家之间具有更高的平均协作分数。(huggingface.co)

换句话说，HOPE 有时会放弃一个个人能力较强但与团队联系较弱的专家，转而保留一个个人分数一般、却处在高价值协作网络中的专家。

这不是在剪枝中加入一个漂亮的数学修饰，而是改变了剪枝集合的结构。

50% 剪枝率，才是 HOPE 真正拉开差距的地方

**HOPE 的优势会随着剪枝比例提高而扩大。**这符合直觉：只删除 10% 的专家时，破坏关键协作组合的概率相对有限；当一半专家都要被删除时，独立排序造成的组合损失会快速累积。

Amazon 在 Qwen3.5-122B、Qwen3.5-35B 和 GLM-4.5-Air 三个模型上进行了测试，使用 Evol-CodeAlpaca 和 SWE-Bench Verified 轨迹作为校准数据，并在 Tulu3 与 SWE-Bench Pro 上评估剪枝后的模型。实验覆盖 10% 至 50% 的专家剪枝率，对比方法包括 REAP、MAN、EAN 和 Frequency。(huggingface.co)

| 指标 | HOPE 结果 | 对比结果 | |---|---:|---:| | 全部条件平均排名 | 2.07 | 5 种方法中最佳 | | 获得第一名的条件占比 | 39% | 参评方法中最高 | | 进入前两名的条件占比 | 67% | 参评方法中最高 | | 50% 剪枝平均排名 | 1.58 | REAP 为 2.42 | | 编码任务最大领先幅度 | 6.1% | 相对次优剪枝方法 |

最有代表性的结果出现在 Qwen3.5-35B-A3B 上。模型被剪掉 50% 专家后，HOPE 在 SWE-Bench Pro 上得到 42.3 分，不仅高于 REAP 的 36.2，也略高于未剪枝模型的 41.8。REAP 相比未剪枝模型下降约 13%。(huggingface.co)

**剪枝模型偶尔超过原模型，并不等于删除专家天然能提高智力。**更合理的解释是，校准数据让算法优先保留了与目标任务相关的专家组合，同时删除了一些会带来噪声或路由干扰的专家。这种收益很可能具有任务分布依赖，不能直接外推到所有场景。

SWE-Bench Pro 恰好是 HOPE 最容易体现优势的基准之一。智能体编码任务需要模型在多轮过程中交替进行代码理解、工具调用、错误分析和修改验证，单个问题会触发更丰富的专家组合。任务需要的能力越复合，保留协作结构的意义就越大。

使用流程并不复杂，但校准集决定了剪出来的模型是谁

**HOPE 的工程流程由校准、求解和剪枝三个阶段组成。**Amazon 已经在 GitHub 发布了 HOPE 开源实现，采用 Apache-2.0 许可证，目前测试过 Qwen3 MoE、Qwen3-Next、Qwen3.5 MoE 和 GLM-4.5-Air，并以 transformers==5.2.0 作为测试环境。(github.com)

第一阶段让校准提示词通过模型，收集每个 Token 的专家选择、路由权重、输出范数和专家对共激活信息，并保存为 HDF5 文件。

第二阶段根据目标剪枝比例或专家数量构造 F 矩阵，求解二次规划，最终输出各层需要删除的专家编号。

第三阶段根据剪枝集合生成新的模型检查点。剪枝后的模型仍是标准 Hugging Face 格式，不要求修改 vLLM 或 SGLang 的模型定义。(huggingface.co)

**真正需要开发者花时间的不是运行命令，而是设计校准数据。**如果校准数据几乎全部是 Python 代码和 GitHub Issue，剪出来的模型自然会优先保存编码相关的专家组合；如果生产流量还包括中文问答、数学推理、检索总结和工具调用，就应该让校准集覆盖这些任务。

一次性剪枝不是通用压缩开关，而是用一批样本定义“哪些能力值得留下”。

对于线上模型，比较稳妥的做法是从真实请求中分层采样，并按任务类型、语言、上下文长度和工具使用情况控制比例。只使用公开基准作为校准数据，容易得到跑分好看但生产分布不匹配的模型。

HOPE 还没有解决哪些问题

**HOPE 当前只建模同一层内的专家两两关系。**它暂时没有充分解决三个更难的问题。

第一，HOPE 逐层独立执行剪枝，没有优化跨层专家组合。如果前一层某个专家的输出会稳定触发后一层特定专家，那么这种跨层依赖不会进入当前 F 矩阵。Amazon 已经给出了跨层 HOPE 的理论框架，但实验仍处于初步阶段。(huggingface.co)

第二，HOPE 只考虑专家对，没有考虑三个或更多专家组成的高阶组合。两两交互矩阵的规模是 E²，而三元组合会增长到 E³；对于每层 256 个专家的模型，潜在三元组合数量超过 1600 万，统计和优化成本都会明显增加。

第三，HOPE 的优势主要集中在 40% 至 50% 的激进剪枝区间。在 10% 至 20% 的低剪枝率下，REAP 和 MAN 有时仍具竞争力。(huggingface.co)

这意味着 HOPE 并不是所有场景下都值得使用。如果团队只是想删除少量冗余专家，显存压力也不严重，一阶方法可能已经够用；如果目标是把原本无法放进单机或单卡的 MoE 压到可部署范围，HOPE 的二阶优化才更可能产生实际回报。

我的判断：它把专家剪枝从排行榜问题变成了组合优化问题

**HOPE 最重要的贡献，是让 MoE 剪枝从“选出最差的专家”转向“找出代价最低的删除组合”。**这两个问题表面相近，实际并不等价。

过去的专家剪枝更像排行榜：先给每个人打分，再从后往前淘汰。HOPE 更像排阵容：它关心的不只是留下谁，还关心留下的人能不能继续配合。

从实验结果看，这种方法在低剪枝率下不是碾压式领先，但在 50% 剪枝率和复杂智能体任务上，优势已经足够明确。对于准备部署 100B 级 MoE、同时受限于 GPU 内存的团队，这种能力比再做一轮简单的激活频率统计更值得投入。

HOPE 也揭示了 MoE 压缩接下来可能出现的一条主线：**剪枝算法将不再只优化参数数量，而会越来越多地建模路由结构、专家关系和任务分布。**专家合并、剪枝和量化也可能从彼此独立的步骤，逐渐变成一个联合优化问题。

Amazon 这次给出的还不是终点。两两协作、逐层剪枝和一次性校准都有明显边界，但它至少证明了一件事：当模型能力来自多个专家的组合时，只看单个专家的分数，已经不够了。

参考来源

• Amazon：Your Experts Have Partners. There's HOPE for Keeping Them Together — HOPE 方法原理、实验配置、性能数据与局限性说明。
• awslabs/HOPE — Amazon 发布的 HOPE 开源实现，包含安装方式、支持模型和完整剪枝流程。