LoRA 大家都熟了。往大模型的权重里塞两个低秩矩阵，冻住原参数，微调成本砍掉几个数量级。这套方法在 dense 模型上已经是默认选择。
但 MoE 模型上，LoRA 的做法有点别扭。
MoE 的核心逻辑是——每个 token 只激活少数几个专家，其他专家根本不动。那你在所有专家上都挂 LoRA 适配器，不就是给不干活的人也发工资吗？
一个简单到几乎"废话"的想法
HELLoRA 的论文标题很长——Hot-Experts Layer-Level Low-Rank Adaptation for Mixture-of-Experts Models——但核心思路一句话就能说完：只在每层最常被激活的专家上加 LoRA，其他专家原封不动。
听起来太简单了，对吧？简单到你可能觉得这能发论文？
但实验结果不跟你开玩笑。
在 OlMoE-1B-7B 上，HELLoRA 用的可训练参数只有 vanilla LoRA 的 15.7%，适配器 FLOPs 降低 38.7%，训练吞吐量提升 1.9 倍，准确率反而高出 9.2%。
在 DeepSeekMoE 上，用 23.2% 的参数就超过了完整 LoRA。
三个骨干模型（OlMoE、Mixtral-8x7B、DeepSeekMoE）、三个任务族（数学推理、代码生成、安全对齐），全部一致地验证了这个结论。
为什么"少"反而"好"
论文给出的解释是：这其实是一种结构化正则化。
当你只微调活跃专家时，非活跃专家保持了预训练时的 specialization——它们原本学好的知识没有被破坏。这就像你装修房子，只翻修最常用的那几个房间，其他房间保持原样，整体效果反而比全部重搞更好。
作者还做了一个更激进的变体 HELLoRI，把 LoRI（冻结上投影、稀疏化下投影）和 HELLoRA 组合起来，在极端参数预算下进一步压缩。
对实际微调工作意味着什么
如果你在用 MoE 模型做领域适配：
- 别再用 vanilla LoRA 了。它在 MoE 上浪费了大量参数在非活跃专家上，效果还不如挑几个重点调。
- 活跃专家的选择可以用激活频率统计来做，不需要复杂的分析。论文的方法很朴素——先跑一轮推理，统计每个专家被激活的次数，选 top-K。
- 训练速度会快很多。参数少了，GPU 内存省了，吞吐量上去了，这对迭代速度影响很大。
这个工作的价值不在于技术复杂度——说实话，想法简单到让人觉得"我怎么没想到"——而在于它揭示了一个被忽略的事实：在稀疏架构上做参数高效微调，稀疏性本身就应该被利用，而不是被无视。
LoRA 的发明者大概也没想到，他们的方法在 MoE 时代需要这样一层"激活感知"的改造。但这正是工程研究该有的样子——发现问题，用最小改动解决问题，然后用实验说话。
论文：HELLoRA: Hot Experts Layer-Level Low-Rank Adaptation for Mixture-of-Experts Models 代码：尚未公开