Hugging Face 这次把一个行业习惯摊开了：做参数高效微调，很多人几乎不再选方案，直接选 LoRA。

这个“几乎”不是感觉。在 Hugging Face Hub 的单 PEFT 技术模型卡样本里，LoRA 占 98.4%；图像生成 checkpoint 样本里，约 95% 是 LoRA；GitHub 代码搜索里，约 71.3% 指向 LoRA。

问题不在 LoRA 还能不能用。它当然还能用。更要命的问题是，开发者是不是已经被一个默认选项绑住了，连重新比较的动作都省掉了。

Hugging Face 测到的不是淘汰，而是松动

PEFT 的价值很直接：冻结基座模型，只训练少量额外参数。

这带来几件现实好处：显存压力更低，checkpoint 更小，同一个基座可以挂多个适配器，也方便做量化模型微调。对开源大模型团队来说，这不是学术小技巧，是预算、交付和上线速度。

LoRA 能一家独大，也不奇怪。它早、有效、教程多、示例多、坑也被前人踩得差不多。研究代码喜欢它，工程部署也喜欢它。

Hugging Face 这次做的是 PEFT 基准测试，横向比较多种方法，覆盖 LLM 数学任务和图像生成任务。结论不能粗暴读成“LoRA 输了”，但足够说明一件事：普通 LoRA 不该再被当作无脑最优。

场景方法 / 结果读法
LLM 数学任务rank-stabilized LoRA 约 53.2% accuracy，22.6GB VRAMLoRA 变体仍在帕累托前沿
LLM 数学任务普通 LoRA 约 48.1% accuracy，22.5GB VRAM普通 LoRA 不该自动成为默认项
图像生成LoRA 约 0.697 / 9.97GB可用，但不占优
图像生成OFT 约 0.708 / 9.01GB相似度和显存同时优于 LoRA

最刺眼的是图像生成部分。OFT 不是“更贵但更强”，而是分数更高、显存更低。

这类结果对工程判断很有杀伤力。因为它挑战的不是信仰，而是成本表。

当然，基准不是圣旨。Hugging Face 也承认，超参选择可能偏向某些方法，不同任务会改写排序。论文里常见的“超过 LoRA”，也不能直接搬进生产环境。

但这组数据至少让一个旧问题重新变得具体：你现在用的 LoRA，是因为它在你的任务上最合适，还是因为所有教程都这么写？

受影响最大的不是研究员，是正在交付的人

对正在用开源大模型做微调的工程师，这件事的动作很明确：别只测普通 LoRA。

如果你在做数学、代码、结构化推理类任务，至少把 rank-stabilized LoRA 这类变体放进候选。普通 LoRA 的 48.1% 和 rank-stabilized LoRA 的 53.2%，差距不该被一句“我们一直这么训”抹掉。

如果你在做图像生成微调，OFT 更该进测试列表。Hugging Face 这组结果里，它同时拿到了更高相似度和更低显存。哪怕你最后不选，也应该知道它为什么没被选。

对技术负责人，判断要再冷一点。别让团队把“能跑通”误认为“已优化”。

更现实的评估表应该长这样：

决策变量该问的问题可能动作
效果accuracy、相似度或业务指标是否真的提升用自有数据复测 LoRA 变体、OFT、BEFT、Lily
显存训练和推理峰值是否卡预算把显存作为一等指标，不只看分数
checkpoint是否要服务大量客户或多任务适配器比较适配器大小和加载方式
部署vLLM 等框架是否支持不支持就评估转换、降级或继续用 LoRA
排障团队是否懂这套方法的失败模式小流量验证，不要直接替换主链路

这不是鼓励团队今天就迁移。很多生产系统继续用 LoRA，完全合理。

vLLM 等下游工具常常优先支持 LoRA，这个限制很硬。模型分数高一点，但上不了服务、不能稳定加载、出了问题没人会修，生产上就不是好方案。

PEFT 已经支持把部分非 LoRA adapter 转成 LoRA，这给了一个缓冲区：训练阶段尝试更合适的方法，部署阶段向 LoRA 生态靠拢。

但也别把这条路想得太满。不是所有方法都能顺利转换，转换后效果和兼容性也要测。工程里没有免费的桥。

LoRA 的护城河，是路径依赖

我更在意的是，LoRA 的真正护城河已经不只是性能。

它是教程、示例、默认配置、社区经验、部署框架、排障文档，也是团队里那句最有杀伤力的话：别折腾，先用 LoRA。

这句话不蠢。它经常是对的。

生产系统里，少踩坑就是收益。少改代码就是收益。少背锅也是收益。“天下熙熙，皆为利来”，放在技术生态里，这个“利”不只指钱，也包括确定性。

但确定性有价格。价格就是很多团队停止比较，停止问约束条件变没变。

这事有点像早期 Web 开发里的 jQuery。不完全一样，但结构相似：一个工具曾经解决了大量真实问题，后来生态太顺手，很多人忘了自己为什么还在用它。

LoRA 现在还没到被替代的阶段。它仍强，尤其是变体。真正松动的是“默认使用”的合理性。

接下来最该看的不是哪篇论文又声称赢了 LoRA，而是三件事：

  • 新方法在自有数据上的收益，能不能覆盖迁移和排障成本；
  • vLLM、PEFT、推理服务框架对非 LoRA adapter 的支持能不能跟上；
  • 团队有没有把显存、部署兼容性和 checkpoint 管理纳入同一张评估表。

如果这三件事答不上来，继续用 LoRA 也可以。但那就不是技术选择，只是惯性选择。

LoRA 今天的问题不是老了，而是太顺手了。顺手到很多人不再问：我的任务，真的需要它吗？