亚马逊HOPE研究：Qwen3.5模型砍半专家仍保持编码性能

亚马逊近日公开了名为HOPE的研究成果及配套代码，其中一项实验显示，在移除Qwen3.5-35B-A3B模型约一半的专家（experts）后，该模型在编码任务上的性能表现与原始模型相近。这一发现为混合专家（MoE）架构的模型压缩与高效推理提供了新的实证参考。

HOPE研究是什么？

HOPE是亚马逊近期公开的一项研究项目，其核心在于探索模型架构的优化与效率提升。与许多仅发布论文的做法不同，亚马逊同时分享了HOPE的研究文档和可运行代码，这为社区复现和进一步探索提供了便利。

从公开信息看，HOPE关注的是如何在保持模型能力的前提下，降低推理成本或调整模型结构。此次引发讨论的，是其中针对Qwen3.5-35B-A3B模型的专家剪枝实验。

移除一半专家，编码性能为何相近？

实验的对象是Qwen3.5-35B-A3B，这是一个采用混合专家架构的模型。MoE架构的特点是推理时仅激活部分专家，从而在控制计算量的同时扩展模型容量。

亚马逊在实验中移除了该模型约一半的专家，随后在编码任务上进行评估。结果显示，模型的编码性能与原始版本相近。这一结果暗示，对于特定的编码任务，模型中的专家可能存在较高的冗余度，或者部分专家对编码能力的贡献并不显著。

提一嘴，该结论仅限于“一项测试”中的编码表现。编码任务通常具有结构化和模式化的特点，模型可能依赖少数关键专家即可完成。至于其他类型的任务（如推理、多语言理解等）是否同样保持稳定，公开信息中并未给出结论。

混合专家（Mixture of Experts, MoE）架构的核心机制是"稀疏激活"：模型包含一个路由网络（router/gating network）和多个专家子网络，每次前向传播时，路由网络根据输入token的特征计算各专家的权重，只激活得分最高的少数几个专家（通常为 top-k，如 top-2）。这使得模型的总参数量可以很大，但单次推理的激活参数量保持较小，从而在不显著增加计算成本的前提下扩展模型容量。Qwen3.5-35B-A3B 命名中的"A3B"即指激活参数量约为 3B（30亿），而总参数为 35B。专家剪枝（expert pruning）就是在训练完成后移除部分专家并相应调整路由，以减少总显存占用和潜在的通信开销。由于每次推理只用到少数专家，被长期低激活或功能高度重叠的专家便成为剪枝的候选对象。

对MoE模型实践的启示

MoE模型近年来被广泛采用，其优势在于以较低的激活参数量实现较大的模型容量。但专家冗余问题也一直存在讨论：训练后的专家是否都不可或缺？

HOPE的这项实验提供了一个具体案例。如果移除一半专家后编码性能仍能保持，那么在实际部署中，针对特定场景裁剪专家可能成为降低显存占用和推理开销的可行思路。不过，这种裁剪需要针对任务类型谨慎评估，不能简单推广到所有场景。

从工程角度看，亚马逊公开代码的举动降低了验证门槛。开发者可以基于HOPE的代码，在自己的数据和任务上测试类似的专家剪枝策略，判断是否适用于自身业务。

专家冗余（expert redundancy）之所以在 MoE 研究中被反复讨论，与训练过程中的"路由塌缩"现象有关。研究发现，路由网络存在自我强化的正反馈：被激活较多的专家获得更多梯度更新，能力更强，进而被更频繁地选中，最终导致少数专家承担了大部分计算，其余专家逐渐"闲置"。此外，不同专家在表示空间上也可能高度相似，功能重叠明显。这意味着移除低贡献专家对模型输出的影响可能有限，这也是剪枝可行的理论基础。不过，专家的重要性与任务分布密切相关——面向通用语料训练出的专家分工，未必与某一垂直任务的最优分工一致，因此剪枝效果需要在目标任务上实测验证。

社区反应与待解问题

该研究在Reddit上引发了讨论。社区关注的点包括：剪枝后的模型在其他基准上表现如何、专家移除是否影响模型的泛化能力，以及这一方法是否适用于其他MoE模型。

目前公开的信息较为有限，实验细节、评估基准和具体配置尚未在原始摘要中充分展开。因此，将这一结果视为“编码任务上专家冗余的初步证据”比视为通用结论更为稳妥。

对于关注模型压缩和高效推理的开发者而言，HOPE的代码值得进一步研究。在自身任务上复现并扩展实验，是判断该方法实用价值的关键一步。