同样的一个开源模型放在两个工程师手里出来的效果经常是两个世界。一个人用单张A100几十个小时就把微调跑完loss曲线平滑下降再一量化推理延迟直接砍半另一个人却反复OOM、loss震荡到怀疑人生好不容易训完上线一测效果崩得没法看。差别往往不在模型结构上而在Model-Optimizer这一层的功课做没做足。Model-Optimizer这个词确实有点大它既指训练阶段的优化器optimizer选型与调参也指推理阶段的模型压缩与加速。说直白点训练侧优化器管的是“模型怎么学会”推理侧优化管的是“模型怎么跑得快跑得省”。这篇文章就从这两个方向展开把选型逻辑、参数细节、落地步骤以及我实际踩过的坑一次讲清楚。适合正在做模型微调、准备做量化部署或者想系统梳理优化工作的人看。1. 先把Model-Optimizer这个词拆清楚很多人一听到optimizer第一反应就是Adam、SGD、AdamW这些训练工具。但放到真实项目里Model-Optimizer的含义比这宽得多。我习惯把它拆成两个层面来看这样后面做决策才不会乱。训练侧优化解决的是“收敛问题”。模型定义好了数据准备好了loss函数写好了剩下就是靠优化器在参数空间里一步步找最优解。这个环节关心的是收敛速度快不快、训练稳不稳、显存占用高不高、最终泛化好不好。选错优化器或者参数没调好最典型的表现就是loss震荡、收敛慢、甚至训完还过拟合。推理侧优化解决的是“部署问题”。模型训练完了如果直接拿原始权重上线参数动辄几十上百G单卡都放不下更别提延迟和吞吐的要求。这个环节关心的是模型体积能不能更小、推理速度快不快、精度损失能不能控制在可接受范围。最常见的三大手段是量化、蒸馏和剪枝。我把这两侧放一起对比一下方便你判断一个项目到底该把精力花在哪边层面核心目标常见技术衡量指标训练侧让模型更快更好地收敛AdamW、SGD、Lion、Sophia混合精度8-bit优化器收敛速度、loss稳定性、显存占用、泛化性能推理侧让模型更小更快地落地量化GPTQ、AWQ、GGUF、蒸馏、剪枝模型体积、延迟、吞吐、精度保持率这里有个常见的认知偏差很多人以为优化器就是换个Adam这么简单。其实训练侧的优化器选型只是第一步后面还有lr策略、weight decay、warmup、梯度裁剪、混合精度这一整套东西要配合。而推理侧更不是套个量化库就完事量化方式、校准数据、精度评测都是关键。这篇文章后续的篇幅基本就是围绕这两侧展开的。2. 训练侧优化器选型从SGD到AdamW再到Sophia2.1 主流优化器的核心差异和数学直觉先把主流优化器拉出来看一遍。这里不列复杂公式只讲行为差异和适用场景。SGD带Momentum经典方案实现简单泛化能力往往强于自适应方法。缺点是对学习率非常敏感收敛慢需要精心设计lr schedule。适合CV分类、小规模fintune任务。Adam把一阶矩梯度均值和二阶矩梯度方差都考虑进来每个参数自适应lr收敛快。但原始Adam里的weight decay是指向梯度项的效果更像是L2正则和真正的权重衰减有细微差别。AdamWAdam的修正版把weight decay从梯度里剥离出来直接在参数更新后乘以衰减系数和L2正则的数学意义不再等价但更接近“真正的权重衰减”。LLM微调默认选它基本没错。LionGoogle 2023年开源的方法用梯度的符号方向做更新内存占用小大模型预训练时收敛速度不错但泛化性能有时略逊且对lr更敏感。Sophia斯坦福那边的工作利用二阶信息loss Hessian对角估计做自适应收敛步数比AdamW能少一半但显存占用更高配置也更复杂。我给的选型建议很直接中小模型微调、LoRA训练直接上AdamW如果你在100B级别做大模型预训练且显存吃紧可以试Lion如果就是想把收敛步数压下来且不差显存Sophia值得研究。SGD在LLM时代的存在感确实弱了但在结构化稀疏场景和小模型上仍有价值。2.2 参数设置的关键细节lr、betas、weight decay、warmup优化器选完真正的战斗才刚开始。参数设不对AdamW也能把loss训成心电图。学习率lrAdamW在LLM微调场景常规范围是2e-5到2e-4LoRA因为参数量小可以适当放到1e-4到3e-4。SGD则需要大得多0.01到0.1起步而且必须配好Momentum。我自己习惯看到一个任务第一眼先看模型和batch大小再决定lr落在哪个区间而不是无脑套默认值。betas默认是0.9, 0.999这个组合在大多数情况下都成立。beta2决定二阶矩估计的历史窗口调大比如0.95到0.98之间能使训练更平稳但收敛会变慢调小则让更新对近期梯度更敏感容易震荡。微调任务通常不需要动它预训练或有长尾分布数据时可以试试0.95配更长warmup。weight decayLLM微调用0.01比较常见也有用0.1的但0.1一般是为预训练大batch场景准备的。要注意的是在LoRA训练里并不是所有参数都需要weight decay通常lora_A、lora_B这种低秩矩阵和layernorm的bias可以选择不衰减否则老化效应会对效果产生细微影响。warmupAdam系列的二阶矩估计在初期非常不准如果一开始就用大lr参数很容易走飞。我一般设置100到500步的warmup或不超过总训练步数的10%。配合cosine或linear decay的lr schedule效果比裸跑稳定一个档次。梯度裁剪gradient clipping按全局范数裁剪到1.0是LLM训练的默认动作。特别在fp16混合精度下偶发梯度尖峰是肯定会出现的不裁剪loss一炸就是白跑几小时。2.3 大模型场景下的显存优化8-bit优化器和混合精度训练优化器还有一个容易忽视的问题显存。AdamW要保存一阶矩和二阶矩相当于每个参数多占两倍FP32空间。7B模型光优化器状态就多出来几十个GB单卡根本扛不住。方案一混合精度。PyTorch的AMP自动混合精度把FP32的计算用BF16/FP16替代同时保留一份FP32的master weight用于参数更新。BF16不需要loss scaling数值范围宽是LLM训练的标配FP16则需要配合动态loss scaling一旦loss scale溢出loss直接变NaN。方案二8-bit优化器。bitsandbytes这类库把AdamW的优化器状态量化到8bit训练时动态反量化为FP32参与计算。效果上几乎无损但能把优化器显存压掉一半。原理和模型量化类似都是利用状态值分布集中、量化误差在可接受范围的特性。方案三梯度累积和ZeRO offload。梯度累积解决的是batch不够大的问题不是显存问题ZeRO把优化器状态分片甚至offload到CPU能扛起更大的模型但对显存带宽的要求也高在小规模集群上收益有限。我个人的组合是LoRA AdamW BF16混合精度 梯度裁剪。这组合已经能覆盖大多数LLM微调场景稳定性和效果都经过大量验证。3. 推理侧落地量化、蒸馏和剪枝怎么配合3.1 量化级别怎么选W4A16、W8A8还是FP8训练完后性能优化大头在推理侧。量化是目前最成熟、收益最直接的方案。你要定义的无非两个维度权重用多少bit激活值用多少bit。量化方案权重bit激活bit优势适用场景W8A888算子兼容性好CPU/GPU通用精度损失小通用部署、需要跨平台兼容的场景W4A16416权重显存压缩明显LLM主流部署方案速度提升大大模型部署GPTQ/AWQ/GGUF常用它W8A16816平衡型速度不错精度损失很小对精度敏感又需要一定加速的场景FP888浮点专为H100等新硬件设计训练推理通吃使用H100时首推A100及以下不支持不是bit越低越好。4-bit以下的量化2-bit、3-bit会把模型压得很小但质量崩起来非常快开源社区玩过一圈之后基本共识是常规任务用W4A16稳得很追求极限速度才考虑W8A8动态量化。新卡上FP8是趋势因为硬件原生支持反量化开销小但要注意A100、V100这些老卡没有对应加速单元FP8无法直接落地。3.2 实际跑一遍LLM的4-bit量化LLM量化最容易上手的路径是AutoGPTQ/GPTQ它用少量校准数据去反推权重的最优低bit表示校准流程大致如下准备校准数据集。一般取C4、pile的几百到几千条文本我习惯获取500条左右覆盖足够多样性能让量化误差更均匀。设置关键参数bits4、group_size128、desc_actTrue。group_size指每128个权重共享一组缩放和偏移参数desc_act按激活值大小重排权重列再量化能提升精度但推理速度略降。跑评测。不能用“看起来能说人话”来判断至少要看量化前后的perplexity差值和几个下游任务的指标。用Transformers库加载GPTQ量化模型的典型写法from transformers import AutoModelForCausalLM, GPTQConfig model_id your-base-model quantization_config GPTQConfig( bits4, group_size128, desc_actTrue, datasetc4, tokenizermodel_id ) quantized_model AutoModelForCausalLM.from_pretrained( model_id, quantization_configquantization_config, device_mapauto, )如果你的模型是基于PyTorch原生流程训练的torchao的4-bit weight-only量化也很方便。它的思路是只压权重不压激活算子使用反量化后的FP16做计算精度保持能力很强from torchao.quantization import quantize_ from torchao.quantization.quant_api import int4_weight_only quantize_(model, int4_weight_only(group_size128))部署服务时LMDeploy也是绕不开的工具。它对W4A16的支持非常成熟自带KV Cache量化、连续批处理、paged attention吞吐比裸HuggingFace推理快不少lmdeploy lite auto_awq model_path --work-dir quantized_model lmdeploy serve api_server quantized_model --server-port 8080跑完量化我还有一个强制动作多跑几轮推理确认稳定性。量化模型在特定层上有时会出现偶发nan或者完全重复的输出这和校准数据规模、max_seq_len都有关系不是一次正常就完事的。3.3 蒸馏和剪枝的定位量化是硬压缩蒸馏则是软压缩。它的核心思路是让小模型学大模型的“行为”而不仅是“标签”。标准做法是对大模型的soft label做带temperature的KL散度约束再把和真实标签的交叉熵叠加起来。temperature控制soft label的平滑程度温度越高类别间信息保留越完整但学生模型的训练难度也会变大。# 蒸馏loss示意 import torch.nn.functional as F def distill_loss( student_logits, teacher_logits, labels, temp3.0, alpha0.7 ): soft_loss F.kl_div( F.log_softmax(student_logits / temp, dim-1), F.softmax(teacher_logits / temp, dim-1), reductionbatchmean ) * (temp ** 2) hard_loss F.cross_entropy(student_logits, labels) return alpha * soft_loss (1 - alpha) * hard_loss蒸馏适合的场景是你有一个非常好的大模型但推理成本扛不住必须换成小模型。它可以独立用也可以和量化叠加先蒸馏再量化是常见组合。剪枝在LLM时代用得少除了一些结构化稀疏框架。原因是LLM的权重剪枝对硬件不友好非结构化稀疏在GPU上很难吃到加速红利。倒是在CNN和检索排序模型里结构化剪枝剪掉整层或整通道是实打实能减小计算量的。如果你做的是推荐系统排序模型或者图像模型torch.nn.utils.prune可以快速做非结构化剪试验但要落地加速还是得走结构化方案。4. 工程集成中的细节训练稳定性和部署边界4.1 梯度累积与学习率缩放梯度累积是显存不够时最常用的招数。数学上它等效于增大batch size但有一个坑batch size变了之后lr不调整loss容易震荡。业内有一个经验性的线性缩放规则等效batch变大k倍时lr可以按sqrt(k)或k倍进行放大具体幅度要结合warmup长度判断。我在实际项目里的做法是等效batch从8变到32时lr从2e-5提到4e-5warmup步数同步拉长一倍loss曲线的稳定性明显变好。另外梯度累积的原子操作是“累加梯度再除累计步数”不是简单地累加就完事。如果不做归一化梯度范数会随累积步数增长梯度裁剪的意义就没了。大部分框架的accumulate_grads实现里已经做了这个归一化但你自己写训练循环时一定要确认。4.2 混合精度训练的loss scale问题BF16时代这个问题轻了很多因为BF16的动态范围和FP32基本一致不存在小梯度被清零的问题。但如果你还在用FP16比如某些老GPU不支持BF16就必须维护一个动态loss scale。loss scale的本质是把loss放大让反向传播的梯度落在FP16可表示范围内。迭代过程中如果出现inf或nan系统会下调scale稳定训练一段后又会尝试上调。很多人一看到loss变成NaN第一反应是lr太大其实先查一下loss scale是不是已经被多次压低到接近1以及梯度的全局范数是否已经异常。FP16训练的正确姿势是梯度裁剪 动态loss scale 定期检查grad norm的分布。4.3 量化模型部署时被忽视的边缘细节量化模型部署有一堆“软件工程”细节比量化本身更磨人。第一个是tokenizer的padding方向。LLM生成这种自回归任务padding策略和DP类模型不一样左侧padding才是正确姿势右侧padding会让attention mask错位生成结果假随机。第二个是KVCache的内存控制。量化只是把权重变小了KVCache还是随序列长度线性增长。长对话场景下不控制max_seq_len和缓存复用照样OOM。LMDeploy、vLLM这些工具帮你做了paged cache管理但你自己写推理脚本时这个开销必须算进去。第三个是层级量化策略。embedding层和输出层不应量化成4-bitnorm层在推理时保持FP32/FP16。torchao这类框架默认会跳过这些敏感层但如果你自己写量化逻辑很容易把所有线性层一刀切最后模型效果莫名其妙变差。第四个是batch size和动态shape。量化模型在静态shape下能吃到TensorRT、ONNX Runtime的加速优化但动态输入长度才是LLM的实际场景。真做低延迟部署需要权衡动态shape灵活但算子优化空间变小静态shape牺牲部分灵活性换速度多数服务选择带bucket的动态shape方案。5. 实际项目里踩过的坑5.1 把AdamW当成Adam用weight decay全乱套有次接手一个老代码训练脚本里用的是Adam优化器但写了weight_decay0.01。原始代码注释写着“参考了AdamW的设置”实际上Adam里的weight_decay和AdamW里的decoupled weight decay根本不是一回事。Adam的weight_decay是把正则项注入到梯度计算里相当于L2正则它和自适应学习率纠缠在一起会让那些更新频繁的参数正则更狠AdamW则是把weight decay放到参数更新之后直接乘系数是解耦的效果更接近预想的“权重衰减”。那次实验直接导致模型最终精度低了将近一个点排查了两天才定位到optimizer类型上。从那以后我定了一个规矩如果要严格实现L2正则效果用带weight_decay的Adam如果要解耦权重衰减一定用AdamW。二者不可混用参数再接近行为也有本质差别。5.2 7B模型GPTQ量化后生成nan之前做一个中文对话模型的部署基座7B量化方案选GPTQ W4A16校准数据集随便抓了当下待部署任务里的200条样本。万万没想到上线后偶发性复读和nan输出用户侧反馈一下子就炸了。排查后发现两个问题。第一是校准数据量太少200条且领域太单一权重的量化误差分布没有校准到真实推理时的分布导致特定输入触发异常。第二是max_seq_len设置比训练时的最大长度长了不少量化表格外推尾部token的激活值直接越界。处理方案校准数据加到1000条左右覆盖多个任务领域group_size保持128desc_act打开重新量化后跑了三轮完整评测perplexity和生成稳定性都回到可接受范围。这个坑给我最大的教训是量化模型的“偶发异常”不能靠重启解决要回到校准数据的量和分布上去找根因。5.3 蒸馏温度没调好反而被大模型带偏另一个项目是把一个70B的对话大模型蒸馏到一个7B模型。第一次实验温度直接设成5alpha设成0.9结果小模型的loss很快就掉到很低但评测指标反而比纯用硬标签训练还差。原因是温度太高teacher的soft label变得几乎均匀分布学生模型学到的全是“类别间模糊信息”对真实任务的关键区分特征学得少。后来把温度降到3alpha降到0.7并在训练后段做了temperature退火也就是从3逐步降到1.5效果才明显回升。蒸馏这个事温度、alpha以及teacher本身的精度三者是绑在一起的不能单独调一个。我最后的体会是Model-Optimizer从来不是“选个大牌优化器一跑就完事”的事情。训练侧要理解optimizer背后的数学行为推理侧要尊重量化、蒸馏这类压缩手段的边界条件。最实用的做法是无论你怎么调改动都先跑一个小规模的验证实验量化方案先量一个子层跑评测优化器参数先用500步小训练看loss趋势再全量铺开。这样看着慢实际是踩坑成本最低的路径。
