Amazon 研究团队（Alex M. Tseng、Stefano Soatto 等）在 Hugging Face 与 GitHub（awslabs/HOPE）开源了名为 HOPE 的混合专家模型（MoE）剪枝方法。面对 Qwen3.5-122B 这类拥有 48 个 MoE 层、每层 256 个专家，且专家权重独占 250GB 显存中 95%（每个 token 每层却仅激活 8 个专家）的显存黑洞，HOPE 在不重新训练的前提下直接永久删去一半专家，为 Qwen3.5-122B 释放约 115GB 显存。在 50% 剪枝率下，HOPE 于五种主流方法中拿到 1.58 的最佳平均排名，其剪枝后的 Qwen3.5-35B-A3B 在 SWE-Bench Pro 智能体编程基准上不仅比次优方法 REAP 高出 6.1 个百分点，甚至以 42.3 分反超了未剪枝的原模型（41.8 分）。
过去业内压缩 MoE 显存，通行做法是以 Cerebras 提出的 REAP，以及 MAN、EAN、激活频率为代表的一阶剪枝：拿校准数据集跑一遍前向传播，给每个专家独立算一个标量重要性分数，然后按层砍掉末位专家。Amazon 团队指出了一阶方法在高剪枝率下崩溃的病根：MoE 的专家在训练早期就会结成稳定的协同激活群组，独立打分一旦误删某个看似平庸、实则充当核心搭档的专家，整条协作链路就会断裂。
0.988 的相关性与 6.1 个百分点的反超：只因保留了专家搭档
HOPE 的核心改动是把剪枝误差上界展开为二次型，构建出一个捕获成对专家共激活强度的交互矩阵 $F$，再通过二次规划求解最优剪枝集合。拆解这个矩阵会发现一个极具说服力的数学事实：如果把 $F$ 矩阵的非对角线元素（即成对专家交互项）全部抹去，只保留代表单个专家重要性的对角线元素，HOPE 给出的专家排序与当前最强的第一阶方法 REAP 几乎完全重合，两者的斯皮尔曼相关系数高达 0.988。
这意味着 HOPE 相比 REAP 赢下的每一分，纯粹来自非对角线上的成对交互项。当剪枝比例拉升到极具部署价值的 50% 时，一阶方法大面积拆散专家搭档，导致 Qwen3.5-35B-A3B 在需要多轮工具调用、推理与写代码的 SWE-Bench Pro 上，REAP 得分从原模型的 41.8 跌至 36.2（退步 13%）；而 HOPE 宁可牺牲部分单打独斗得分高的专家，也要保住高协同群组，最终拿到 42.3 分。这种剪掉一半专家反而略超原模型的反常现象，源于剔除低相关专家后减少了目标任务上的路由噪声。
一阶剪枝看个人简历裁员，二阶剪枝按项目组留人。
对于私有化部署和边缘推理团队而言，50% 剪枝率下 HOPE 与 REAP 省下的显存完全相同，且论文并未证明 HOPE 能降低单 token 推理延迟；它的真实工程价值是在同等显存瘦身幅度下保住复杂 Agent 能力。原本需要約 250GB 权重显存的 Qwen3.5-122B，经 HOPE 砍半后权重显存降至约 125GB，腾出的 115GB 空间可以直接让给更长的上下文 KV Cache 或更高并发。
| 评估维度 | Qwen3.5-35B-A3B | Qwen3.5-122B-A10B | 工程影响判断 |
|---|---|---|---|
| 50% 剪枝后权重显存 | 减半（按比例缩减） | 降至约 125GB（省 115GB） | 显著降低多卡部署门槛 |
| 每千条校准耗时（HOPE vs REAP） | 1.27 小时 vs 1.20 小时 | 1.55 小时 vs 1.48 小时 | 准备时间仅增加 6%–8% |
| 全层二次规划求解耗时 | 75.4 秒 | 92.4 秒 | 求解开销相对校准可忽略 |
| 99% 决策一致性所需校准量 | 约 10,000 条 prompt | 约 10,000 条 prompt | 比 REAP（8,000 条）略吃数据 |
算清这笔工程账会发现，引入非凸二次规划并没有让压缩成本失控。在 Qwen3.5-122B 上，跑完 48 层的二次规划连续松弛求解一共只需 92.4 秒，连同前向传播收集激活统计量的时间在内，总准备开销仅比 REAP 多出 6% 至 8%。此外，团队在 GLM-4.5-Air（106B 参数、每层 128 专家）及 Tulu3 套件（含 MMLU、GSM8K、LiveCodeBench 等）上的测试证实，哪怕只用代码数据（Evol-CodeAlpaca 或 SWE-bench 轨迹）做校准，剪枝后的通用问答与数学能力也不会出现断崖下跌。
- 结论.只要剪枝比例达到 30%–50%，二阶交互矩阵就应当全面接管 REAP 等一阶独立打分方法，成为 MoE 免训练压缩的新基线。
高阶之名下的三处技术边界：范数代理、跨层失衡与校准陷阱
尽管 Amazon 将这套方法命名为高阶剪枝（Higher-Order Pruning），但如果紧盯论文的数学推导与代码实现，准备在生产环境落地的算法工程师必须避开三个隐蔽的限制。
名义上是高阶，HOPE 实际上只算到了二阶成对交互。由于三元组及更大专家群组的组合估计在计算与内存上代价过高，算法直接放弃了三阶以上协同；即便是二阶项，它计算的也只是两个专家的门控权重与输出向量 $L_2$ 范数的乘积（$g_i g_j \|f_i\|_2 \|f_j\|_2$）。这种标量范数代理只衡量了两个专家是否同时大声说话，却完全没有测量它们输出向量的方向究竟是同向增强、正交互补，还是反向抵消。
更棘手的工程短板出在跨层预算分配上。从 GLM-4.5-Air 的交互矩阵可视化能清楚看到，MoE 早期层、中间层与晚期层的专家抱团结构差异极大，理应按层动态分配剪枝比例。但标准版 HOPE 依然只能在每个 MoE 层内部独立按固定比例裁剪；研究团队尝试的跨层扩展版 CHOPE 目前并不稳定，极易导致部分层被过度剪枝而引发模型坍塌。
- 风险.开发者若直接拉取 Cerebras 官方开源的 REAP 检查点与 HOPE 对比，会因为 REAP 官方权重使用了另一套 24,576 条混合校准配方（含 Mixture-of-Thoughts、xLAM 等）而产生基准偏差；同时
awslabs/HOPE目前强依赖transformers==5.2.0及堆叠专家（stacked-experts）权重格式，接下来最值得盯紧的变量，是社区能否修好 CHOPE 的跨层预算失衡，以及二阶剪枝与 4-bit 量化叠加后在真实 Agent 生产流中的稳定性。