Optimizer替换实践：Adafactor与Lion的应用场景
在大模型训练的世界里，显存墙和训练效率的瓶颈正变得越来越真实。当你试图在一块24GB显存的A10卡上微调一个7B参数的模型时，哪怕只是加上LoRA，AdamW优化器也可能直接把你推入OOM（内存溢出）的深渊。这种“还没开始就结束”的体验，几乎成了每个大模型工程师都曾面对的噩梦。
也正是在这种背景下，Adafactor和Lion这两个名字逐渐从论文走向生产环境，成为真正能“救火”的优化器。它们不是简单的算法变体，而是针对现代深度学习训练中两大核心矛盾——显存占用 vs. 训练速度——提出的系统性解决方案。而像ms-swift这类现代化训练框架，正是让这些先进优化器快速落地的关键桥梁。
我们不妨先抛开传统“总-分-总”的叙述方式，直接从一个典型问题切入：为什么 AdamW 在百亿模型面前显得如此笨重？
答案藏在它的状态管理机制里。AdamW 为每个参数维护两个动量项：一阶矩（均值）和二阶矩（方差），这意味着其优化器状态大小是模型参数量的两倍。对于一个7B模型来说，仅优化器状态就需要约56GB显存（FP32下）。这还没算上梯度、激活值和模型本身，显然无法在单卡运行。
而 Adafactor 的出现，本质上是一次“降维打击”。它不直接存储完整的二阶动量矩阵 $ v_t $，而是将其分解为行向量 $ Z_{\text{row}} $ 和列向量 $ Z_{\text{col}} $，通过外积近似重建：
$$
v_t \approx Z_{\text{row}} \otimes Z_{\text{col}}
$$
这一招将原本 $ O(N) $ 的存储复杂度压缩到了接近 $ O(\sqrt{N}) $。以Transformer中的注意力权重为例，假设其形状为 $ [d_k, d_v] $，传统方法需存储 $ d_k \times d_v $ 个值，而Adafactor只需 $ d_k + d_v $，当维度较大时节省极为显著。
更聪明的是，Adafactor 并非对所有参数都采用这套机制。对于偏置项、LayerNorm等小张量，它仍沿用标准Adam逻辑，避免因过度简化导致性能下降。这种“因地制宜”的设计思路，体现了工程实践中宝贵的实用主义精神。
此外，Adafactor 内置了动态学习率缩放机制。你可以设置scale_parameter=True和relative_step=True，让优化器根据训练步数自动推导合适的学习率，无需手动精细调节初始值。这对于预训练任务尤其友好——毕竟没人愿意花几天时间做学习率搜索。
from transformers import Adafactor optimizer = Adafactor( model.parameters(), lr=1e-3, beta1=0.9, scale_parameter=True, relative_step=False, warmup_init=False, )这段代码已在 Hugging Face 生态中广泛使用，并被无缝集成进 ms-swift 的Trainer组件。用户只需在配置文件中声明optimizer: adafactor，即可完成切换，无需修改任何训练逻辑。
但如果你追求的不是显存节省，而是极致的训练速度呢？这时候 Lion 就登场了。
Lion（EvoLved Sign Momentum）的设计哲学完全不同。它完全抛弃了二阶动量，甚至连除法运算都不要。它的更新规则极其简洁：
维护一个指数移动平均的一阶动量：
$$
m_t = \beta_1 m_{t-1} + (1 - \beta_1) g_t
$$参数更新仅依赖动量的方向：
$$
\theta_{t+1} = \theta_t - \eta \cdot \text{sign}(m_t)
$$
注意，这里不是用原始梯度，也不是加权后的动量值，而是它们的符号。也就是说，无论梯度多大，只要方向一致，更新步长就是固定的 ±η。这种“只认方向不认大小”的策略，听起来有些激进，但在实践中却展现出惊人的收敛能力。
为什么有效？一种直观解释是：sign 操作增强了更新的稀疏性和同步性。大量参数在同一方向上集体移动，有助于模型更快地跳出局部极小点。Google 的实验表明，在 ViT、T5 和 PaLM 等架构上，Lion 不仅训练速度提升15%以上，最终性能还能高出2–3%。
更重要的是，Lion 的计算极其轻量。没有平方根、没有倒数、没有自适应缩放，只有乘加和符号判断。这对硬件非常友好，尤其适合部署在支持 bit-wise 运算的 ASIC 或 FPGA 上。在分布式训练中，由于只需传输一阶动量，通信开销也大幅降低。
当然，天下没有免费的午餐。Lion 对超参数更为敏感，尤其是学习率。如果设得太大，容易引发剧烈震荡；太小则收敛缓慢。通常建议配合较大的 batch size 使用，以稳定梯度估计。weight_decay 的设置也需要谨慎，因为它会直接影响 sign 判断的结果。
以下是一个基于 PyTorch 的 Lion 实现示例：
import torch class Lion(torch.optim.Optimizer): def __init__(self, params, lr=1e-4, betas=(0.9, 0.99), weight_decay=0.0): defaults = dict(lr=lr, betas=betas, weight_decay=weight_decay) super().__init__(params, defaults) @torch.no_grad() def step(self, closure=None): loss = None if closure: with torch.enable_grad(): loss = closure() for group in self.param_groups: for p in group['params']: if p.grad is None: continue grad = p.grad state = self.state[p] if len(state) == 0: state['exp_avg'] = torch.zeros_like(p) exp_avg = state['exp_avg'] beta1, beta2 = group['betas'] # 更新动量 exp_avg.mul_(beta1).add_(grad, alpha=1 - beta1) # 构造更新方向 update = torch.sign(exp_avg) if group['weight_decay'] > 0: update.add_(p, alpha=group['weight_decay']) # 执行更新 p.add_(update, alpha=-group['lr']) return loss这个实现不到30行，却蕴含着强大的表达力。在 ms-swift 中，你可以通过插件机制将此类自定义优化器注入训练流程：
from swift import Trainer trainer = Trainer( model=model, args=training_args, optimizers=(Lion(model.parameters(), lr=5e-5), None) )整个过程无需侵入原有训练逻辑，体现了现代训练框架应有的灵活性。
那么，什么时候该用 Adafactor，什么时候该选 Lion？
我们可以从几个关键维度来做决策：
| 维度 | Adafactor 更适合 | Lion 更适合 |
|---|---|---|
| 显存限制 | 极端受限（如单卡微调7B+模型） | 中等，但仍希望减少状态体积 |
| 训练目标 | 长期预训练、稳定性优先 | 快速迭代、收敛速度优先 |
| batch size | 可小可大 | 建议较大（>1k）以稳定 sign 更新 |
| 硬件平台 | TPU、HPU 等内存敏感设备 | GPU 集群、支持 BF16 加速的设备 |
| 混合精度 | FP16/BF16 均可 | BF16 下表现更稳，FP16 需小心调参 |
举个实际例子。某团队在 A10（24GB）上尝试对 Qwen-VL 进行 QLoRA 微调，使用 AdamW 时常因 OOM 中断。切换为 Adafactor 后，优化器状态从约48GB降至20GB以内，成功跑完全部epoch，最终指标提升5%。这是一个典型的“内存优先”场景。
而在另一个案例中，团队在多节点环境下训练 Llama3-8B，发现 AdamW 的动量同步带来了显著通信开销。改用 Lion 后，每秒处理样本数提升了18%，整体训练时间缩短近一天。这是“速度优先”的胜利。
值得注意的是，这两种优化器并非互斥。你甚至可以在不同阶段组合使用：前期用 Lion 快速探索，后期换 Adafactor 精细调整。ms-swift 支持的插件化架构使得这类策略切换变得轻而易举。
回到最初的问题：优化器的选择还只是算法偏好吗？
显然不是。在当前大模型训练成本动辄数十万甚至百万级的背景下，每一个百分点的效率提升、每一GB的显存节省，都在直接影响项目的可行性与 ROI。Adafactor 和 Lion 正是从工程现实出发，重新定义了“高效训练”的边界。
前者代表了一种内存智能的设计理念：通过低秩近似、动态缩放、选择性应用等手段，在不牺牲太多性能的前提下，极大缓解资源压力；后者则体现了一种计算极简主义：回归梯度方向的本质，用最轻量的机制换取最快的前进速度。
而像 ms-swift 这样的框架，正在把这种前沿技术民主化。它不仅支持600+大模型和300+多模态模型的统一训练接口，更通过插件机制让开发者可以自由组合优化器、调度器、量化策略等组件。无论是命令行一键启动，还是图形界面勾选配置，都能快速完成优化器替换。
未来，随着更多轻量优化器的涌现（如 Prodigy、Dadaptation 等），我们或许会看到一种新的训练范式：不再依赖固定模式，而是根据任务需求、硬件条件和预算约束，动态构建最优训练流水线。而今天对 Adafactor 与 Lion 的探索，正是通向这一未来的起点。
某种意义上，这不仅是优化器的进化，更是整个AI工程体系向更高层次自动化迈进的缩影。
