砍掉一半专家时，该留的不一定是单独分数最高的那些

2026 年 11 月 9 日，Amazon 的 Alex M. Tseng 在 Hugging Face 发文介绍一种叫 HOPE 的方法，全称是 Higher-Order Pruning of Experts。文章解释了论文 arXiv:2609.18916，共同作者是 AWS Agentic AI 的 Prannay Kaul、Luca Zancato、Wei Xia 和 Stefano Soatto，并指向 github.com/awslabs/HOPE 上的代码。混合专家模型能做大，是因为它们把每一层里负责变换 token 的那一部分拆成许多专科网络，也就是专家。token 是文本里的一小段，常常是词的一部分。每个 token 只送到其中几个专家。没被用到的专家仍然要占用显存。常见的办法是删掉看起来最没用的专家。HOPE 的主张是：这种常见办法打分打错了对象。单独看起来可以丢掉的专家，可能正是你打算留下的那些专家的搭档。

HOPE 要解决的问题

这篇 Hugging Face 文章用 Qwen3.5-122B 来说明显存问题。该模型在 48 个混合专家层里，每层有 256 个专家。对任意一个 token，每层实际只用 8 个专家。文章说，模型大约 250 GB 的参数显存里，约 95% 都是这些专家网络。论文给出的是同一幅图，数字稍紧一些：在 Qwen3.5-122B-A10B 里，1220 亿参数中有 1160 亿是专家网络，约占 240 GB。论文说，若剪掉 50% 的专家，占用会降到约 125 GB，从而在同一台机器上腾出约 115 GB，留给更长的上下文、工具调用和推理轨迹。

运行时再从别处把闲置专家调进来，对许多服务部署来说太慢。量化可以缩小每个数字所占的空间，但所有专家仍要留在显存里。剪枝是把专家永久删掉，不需要额外训练，也可以和量化一起用。发布的软件包写出的是标准 Hugging Face 权重。作者说，不必改 vLLM 或 SGLang 的模型定义，这两种是常见的语言模型服务系统。

真正困难的是决定删谁。

一阶剪枝漏掉了什么

现有方法先在校准数据上看模型的行为，再给每个专家打一个分数。校准数据是在删任何专家之前用来观察模型的一批文本。Frequency 留下最常被选中的专家。EAN 和 MAN 看每个专家输出的大小。REAP 的全称是 Router-weighted Expert Activation Pruning，它会用路由器的门控值给输出加权。路由器是负责挑选哪些专家处理某个 token 的小网络。论文把 REAP 当作生成任务上领先的一阶方法。

这些方法都假定，一个专家的价值可以单独判断。作者说，模型实际不是这样运行的。每个 token 会被送到一小群专家那里，常常是 8 个，然后再把它们的输出加在一起。有些专家对一起出现的次数远高于偶然，而且这种搭档关系会在训练中稳定下来。如果你因为专家 A 的单独分数低就删掉它，也可能连带拆掉专家 B，而 B 正是你因为单独分数高才留下的。

HOPE 想给这种损失标价。它只需要在校准数据上做一次前向计算，就为每一层建一个矩阵 F。第 i 行第 j 列的值，是两个专家同时被选中的那些 token 上，它们按门控加权后的输出大小相乘再取平均。F 的对角线是每个专家自己的重要性，对角线以外的项是成对配合。作者证明，用这些项构成的一个简单量，可以给出删除一组专家后主要误差的上界，并把寻找损害最小的那一组，写成一个二次规划。他们说，求解每层大约只要 1 到 2 秒，和校准那一步相比很小。

它和 REAP 的关系很直接。F 的对角线几乎能完全复原 REAP 的专家排名，Spearman 相关系数是 0.988。论文还写明，如果忽略对角线以外的项，HOPE 就退化成 REAP。按作者的说法，HOPE 相对 REAP 的任何增益，都得来自这些搭档项。

数字怎么说

作者测了三个模型：Qwen3.5-122B、Qwen3.5-35B 和 GLM-4.5-Air。他们用了两套校准数据，Evol-CodeAlpaca 和 SWE-Bench Verified 轨迹，并在 10% 到 50% 的剪枝比例上，把 HOPE 与 REAP、MAN、EAN 和 Frequency 比较。评测用了 Tulu3 套件，以及 SWE-Bench Pro。后者要求模型自己解决真实的 GitHub 议题。

在这些设定里，HOPE 的平均排名最好，五种方法中是 2.07。它在 39% 的设定里排第一，在 67% 的设定里进入前两名。剪到 50% 时，平均排名升到 1.58，REAP 是 2.42。

博文最先拿出的，是智能体编程上的数字。在删掉 50% 专家的 Qwen3.5-35B-A3B 上，HOPE 的 SWE-Bench Pro 分数是 42.3。未剪枝模型是 41.8。REAP 是 36.2，博文称这是 13% 的回撤。论文里对应的表记录的是：用 Evol-CodeAlpaca 校准时，HOPE 为 42.33 加减 1.23，未剪枝模型为 41.82，REAP 为 36.23 加减 0.93。更老实的读法是：在报告的波动范围内，HOPE 和未剪枝模型持平，REAP 则没有。

博文说，删掉的专家越多，HOPE 的优势越大，而且在 SWE-Bench Pro 上最明显，因为模型必须在许多轮里组合多种工作。这正是各种专家组合最可能被用到、拆散搭档也最可能受伤的场合。当 HOPE 和 REAP 对某个专家意见不合时，HOPE 留下的专家，与其他幸存者的配合分数，要高于 REAP 留下的那些。

作者也写到，剪枝后的模型有时能追平甚至略高于未剪枝基线，原因可能是去掉了与目标任务关系不大的专家，减少了噪声。他们说这一点并不只属于 HOPE。

更宽容的读法，以及缺口

对一阶剪枝更宽容的读法并不复杂。只剪 10% 到 20% 时，搭档项没那么要紧，博文自己也说 REAP 和 MAN 在这一档有时能打得不相上下。如果只需省下不多的显存，更简单的分数可能就够了。REAP 已有理论依据，HOPE 也把自己写成对这一方法的推广，而不是否定。额外开销不大：论文的计时表里，校准只比 REAP 长约 6% 到 7%，外加几秒钟求解。

评测仍然是作者自己做的。Tseng 和同事在 Amazon 工作。他们用公开模型、点名的基线和公开代码来比较 HOPE，这比一张厂商幻灯片更容易核验，但并不是另一家实验室在重复 SWE-Bench Pro 上的那个数字。42.3 对 41.8，不应该被说成 HOPE 让模型变得比原来更好。论文里 42.33 的误差范围，大到可以覆盖 41.82。

HOPE 仍然按层单独做决定，也只建模成对关系，而不建模三个及以上的组合。作者草拟了一个跨层版本，并称那些结果仍是初步的。校准数据也会影响结果。不同提示集会给出不太一样的删除名单，Evol-CodeAlpaca 与 SWE-Bench Verified 之间的 Jaccard 指数约为 0.60，和 REAP 的 0.61 相近。这里的 Jaccard 指数衡量的是两套删除名单的重叠程度。指数为 1，意味着两套校准数据删掉了同一批专家。

谁该在意，接下来看什么

在显存紧张的 GPU 上部署大型混合专家模型的团队应当留意，尤其是当他们考虑删掉 40% 或 50% 的专家，好让更长的上下文和工具轨迹装得下时。已经在用 REAP 的人更该看一看，因为 HOPE 说多出来的信号，恰恰是 REAP 丢掉的那一部分。

未来六个月里，能核对的是复现和服务报告。看 Amazon 以外的团队是否会在 Qwen3.5 或 GLM-4.5 上公布一次 50% 剪枝，并得到类似的 SWE-Bench Pro 差距。看经过 HOPE 剪枝的权重是否出现在公开模型仓库里，以及是否有人在同一硬件上报告每秒输出的 token 数和显存占用，并与未剪枝基线并列。

收束

这种方法讨论的是怎么记账，而不是混合专家模型已经被解决了。如果独立实验仍能保持 50% 剪枝时 SWE-Bench Pro 上的差距，那么按单独分数删专家，在最能省显存的剪枝比例上就会显得是砍错了对象。如果换一套校准数据或评测框架后差距缩小，那 HOPE 的搭档项就只是对一个实验室套件的有用修正，而不是新的默认做法。接下来半年应当能看出它属于哪一种。