最近带团队做大模型微调时我经常遇到一种情况项目组的新同学一上来先问“用哪张卡”“跑多少step”但聊到训练阶段划分、数据类型、PEFT参数高效微调这些基本盘时却说不出个所以然。不是说这些细节不重要而是顺序反了——训练阶段决定数据怎么准备数据类型决定计算精度和显存占用PEFT微调体系决定可训练参数量级和效果上限。这三件事才是模型最终效果的地基。这篇文章我就把这套体系完整拆开聊聊我实际踩过的坑、反复验证过的配置以及为什么某些“看上去合理”的做法在真实场景里根本不成立。1. 训练阶段划分为什么顺序比什么都重要大模型不是“拿一份数据从头训到尾”这么简单。业界主流路线基本都是分阶段推进预训练、监督微调、偏好对齐。每个阶段的目标、数据形态、资源消耗完全不同。很多人觉得自己只是“微调一下”不需要关心预训练——错了你手里的底座是预训练产物它的状态直接决定你微调时的起点和策略。1.1 预训练与领域继续预训练决定了模型的“知识底座”预训练做的事情是让模型从海量文本中学习语言规律、世界知识和推理能力。一个底座模型如果在该阶段没有见过足够多的领域语料那你在后面阶段再怎么调SFT它也没有“知识”可以输出。这就是为什么做金融、医疗、法律垂直领域落地时通常需要先做一步领域继续预训练拿几亿到几十亿token的领域干净语料在底座上以较低学习率继续训练让模型内部权重逐步“偏向”领域表达方式。继续预训练阶段的典型配置是学习率很低一般在1e-5到2e-5之间epoch也少过一遍或两遍数据。很多人以为“多训几轮一定更好”但领域语料往往规模不大反复过好几遍容易让模型对原底座知识产生灾难性遗忘。我见过有人在几十GB金融语料上重复训练五六个epoch结果模型连通用问答能力都明显退化了。这个阶段的正确打开方式是把大领域语料切成几份混合采样控制重复率训练过程中持续在基准任务上做评估一旦发现通用能力下滑信号立刻停止。1.2 SFT监督微调教模型“按人类的格式回答”预训练模型只会做“补全下一个词”不会听指令不会按照对话格式来回复。SFT阶段的任务就是用人工或模型构造的高质量“问题-答案”对让模型学会“用户问什么我该怎么组织回答”。这个阶段对数据质量极其敏感。我踩过的最深的坑是以为数据越多越好直接拿爬来的几百万条低质量问答去跑SFT结果模型学会了啰嗦、重复和幻觉。SFT数据应当注重多样性和指令覆盖度。单轮指令和多轮对话都要有还要混合不同类型的任务格式比如分类、抽取、创作、推理、代码等。很多开源模型的数据格式是Alpaca风格一条样本包含instruction、input、output三个字段对话模型则更常用ShareGPT风格把多轮对话组织成一个messages列表。这些格式本质上不影响模型学习能力但它们决定了你切分loss时怎么标注哪些token要计算损失。1.3 偏好对齐阶段SFT之后再谈“合不合口味”SFT教会模型“会答”但没教会它“答得好”。偏好对齐阶段用真人或AI反馈构造的偏好数据告诉模型哪个回答更符合人类期望。最常见的技术路线有两种RLHF基于PPO的强化学习和DPO直接偏好优化。这里必须强调一个前提偏好对齐一定是在SFT之后。底座模型没有经过SFT时它生成的回答连基本格式都不对做偏好对齐没有意义。DPO等算法在实现上比PPO简单很多不需要单独训练奖励模型和做在线采样因此在开源社区落地更广。但DPO对SFT模型的质量有隐性要求——如果SFT阶段模型已经产生了大量“虽然格式正确但内容平庸”的回答DPO阶段要花费更多样本才能纠正甚至可能把模型往相反方向拉得过于极端。训练阶段的顺序不是“惯例”而是由模型的学习规律决定的。先学知识再学格式最后学偏好。跳步操作短期看好像省了时间长期看都要用更多数据和不稳定效果来还债。2. 数据类型选型BF16、FP16、FP32到底怎么搭训练大模型时数据类型的选择会直接影响显存占用、训练稳定性和最终精度。这里没有“越精确越好”的说法关键是理解每种精度的特点和适用位置。我遇到过不少人直接在代码里把所有层都设成FP16然后训练过程中loss直接变NaN各种排查都找不到原因——本质就是没有理解精度的适用范围。2.1 三种主流精度的底层逻辑先看一张整体对比。FP32是32位浮点一位符号位、8位指数、23位尾数动态范围和精度都最充裕缺点是存储开销大、算力利用率相对较低。FP16是16位指数位砍到5位导致它的最大可表示数值只有65504训练时一旦中间梯度或激活值超过这个阈值就会溢出成inf反传loss因此变成NaN。BF16同样是16位但保留了和FP32一样的8位指数位动态范围可以到3e38量级它牺牲的是尾数精度只有7位有效尾数。这也是为什么在比较新的GPU和框架上大模型训练基本都默认BF16。FP16那个65504的上限在实际深层网络中非常容易踩雷尤其是刚开始训练时loss比较大梯度的量级也大激活值动不动就溢出。BF16虽然尾数精度低但大语言模型的训练可以被看作是“海量样本平均逼近”的过程单次前向的微小精度误差在大量批次迭代中被平滑掉了实际收敛效果与FP32差别很小。而FP32在如今的训练中主要用来保存优化器状态和做参数更新时的累加。2.2 混合精度训练不只是一个开关在PyTorch里混合精度训练本质上是“用低精度做计算、用高精度做累加”。AMP自动混合精度会为不同的算子自动选择合适的数据类型对于矩阵乘法这类计算密集算子用FP16或BF16计算对于loss计算、梯度累加等容易失精度的位置保持FP32。如果使用FP16模式关键还要配合GradScaler——它会在loss反传前乘一个缩放因子把梯度放大到安全范围内更新参数前再缩回去从而规避FP16动态范围的限制。使用BF16时不需要GradScaler因为BF16动态范围和FP32一致不存在溢出问题。这也是为什么现在很多大模型训练框架一上来就用BF16。具体到代码实现你可以这样开启混合精度from torch.cuda.amp import autocast, GradScaler scaler GradScaler() # 仅FP16模式需要 model.to(cuda) for batch in dataloader: with autocast(dtypetorch.bfloat16): # 或 torch.float16 loss model(batch) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()需要注意的是如果你用了DeepSpeed或HuggingFace Trainer这类上层框架它们内部已经封装了混合精度逻辑一般只需在配置里指定bf16: true或fp16: true。我的习惯是能BF16就BF16只有在老显卡不支持BF16时才退一步用FP16并开着缩放器。2.3 推理阶段的量化和训练不是一回事数据类型话题延伸到推理阶段时另一个常常被混淆的概念是量化。比如你经常听到有人说“我用了INT8/INT4推理”也就是把模型权重从16位压缩到8位或4位存储和运算。这种量化和训练阶段的混合精度完全是两码事。训练时用BF16是为了在有限显存下保持稳定收敛推理时用低比特量化是为了减小显存占用、提高吞吐。我做推理部署时一般优先尝试GPTQ或AWQ这类训练后量化方案把7B模型压到INT4后显存占用可以从14GB降到4GB左右。但量化也不是白拿的某些任务上会有可感知的精度损失尤其是需要细致推理或输出长文本的场景。所以合理的做法是先跑FP16推理拿到效果基线再量化对比量化后如果关键指标下降超过可接受阈值就要考虑更高比特量化或混合量化。3. PEFT参数高效微调LoRA、QLoRA与同类技术的选型逻辑PEFT全称是Parameter-Efficient Fine-Tuning核心思想是冻结原始模型的大部分参数只训练少量新增或选中的参数。参数高效微调体系的出现本质上解决了两类痛点一是全参数微调需要完整保存和更新模型梯度显存和计算开销极高普通开发者很难承担二是每次业务方向调整都要微调一份全量模型存储成本巨大。而PEFT方法通常只需要保存极小一部分增量参数一个底座模型可以挂载多个不同的下游适配器。3.1 LoRA原理把“大手术”变成“贴补丁”LoRA是目前应用最广泛的PEFT方法。它的思路非常直观在冻结原权重矩阵W的前提下训练两个低秩矩阵A和B让前向计算变成W与BA的和。原权重参数完全不更新只有A和B参与训练。BA的参数量远小于W因为它的秩r远远小于矩阵本身的维度。举个例子一个4096x4096的权重矩阵全参数训练要更新约16.7M个参数而LoRA如果设rank为16A和B加起来只有约131K参数差不多是原矩阵的0.8%。LoRA的初始化有一个关键细节矩阵A用高斯随机初始化矩阵B初始化为零矩阵。这样训练开始时BA是零矩阵相当于前向计算没有发生任何变化模型起点与原始底座完全一致。如果随便给B赋一个非零初始值模型一开始就会输出紊乱的结果训练也非常不稳定。这一点在源码里体现得很清楚但很多人只抄用法不读代码最后训练loss发疯半天找不出原因。3.2 QLoRA单卡跑大模型的杀手锏QLoRA是LoRA的高效扩展版核心是先把原始模型权重做4位量化加载到显存中再在LoRA适配器上做正常的BF16训练。这样7B模型权重在显存中只要约3.5GB配合LoRA的低参数量单张24GB显卡跑7B甚至13B模型微调都成为可能。QLoRA还引入了NF4量化格式、双重量化和分页优化器三个机制。NF4是一种分位数量化让4位整数尽量贴合真实分布的数值间隔双重量化是对量化常数再做一次量化进一步压缩内存分页优化器利用CPU内存换页来缓解显存峰值。QLoRA的劣势在于训练速度偏慢。因为底层权重是4位存储每次前向都要反量化成BF16参与计算多了一层开销。如果你有A100多卡环境时间成本敏感度高直接用BF16的LoRA会更划算如果你只有消费级显卡QLoRA是性价比最高的选择。我实测下来同样数据和配置下QLoRA训练耗时大约是LoRA的1.5到2倍但显存占用只有后者的三分之一。3.3 其他PEFT方法何时选LoRA之外的路LoRA虽然通用但并不是所有场景的唯一解。Prefix Tuning的做法是在每层Transformer的key和value前拼接一组可训练的虚拟token相当于给每层注意力机制加了一个方向指引。P-Tuning v2则是只在输入层前面加可训练的连续提示向量修改的范围更小。这两种方法在有足够长度的输入序列空间时效果尚可但一旦输入本身已经很长可插入的虚拟token数量受限效果就会打折扣。AdaLoRA和DoRA是另外两个值得关注的方向。AdaLoRA会根据重要性得分动态调整每个权重矩阵的秩把更多参数容量分配给更重要的层效果在某些任务上略优于固定秩的LoRA。DoRA先把权重分解成方向分量和幅度分量再分别用低秩方式微调由于更贴近权重更新的内在结构在指令跟随和推理类任务上经常能看到比LoRA更明显的好处。我的建议是通用起步用LoRA遇到效果瓶颈再尝试AdaLoRA和DoRA不要一开始就追新方法——大部分情况下数据和训练配置对效果的影响远大于这几种方法本身的差距。4. 实操复盘从数据准备到训练参数配置的完整流程理论说再多不落到具体操作上都是空的。这一节我用一个7B模型的SFT微调项目作为例子完整走一遍流程重点是在每个环节说明我的选择逻辑和显存换算过程。假设目标是做一个客服对话模型数据已经人工标注了几万条多轮对话。4.1 数据准备格式、截断、Loss遮蔽首先把原始数据统一成模型容器适应的对话格式。目前最通用的是从开源模型社区流行起来的ShareGPT风格大体结构是连续的角色消息列表{ messages: [ {role: user, content: 你好我想查询上月账单}, {role: assistant, content: 好的请提供您的注册手机号。}, {role: user, content: 138XXXX8888}, {role: assistant, content: 已查到上月账单总额为358.6元其中基础套餐费用199元。} ] }有了这种结构处理时可以直接把所有消息拼成一段文本再接上模板中的特殊分隔符。训练的关键细节在于损失遮蔽loss只在assistant回答的部分计算user的提问和模板标记都不用计算loss。如果一股脑把所有token都参与loss计算模型会强化“复述用户问题”的行为导致推理时输出大量重复输入。实现时我们要提前构造一个与token一一对应的mask数组把非assistant部分的loss权重置为0。数据截断方面一般处理规则是每个样本限制在模型上下文长度内。但如果样本真的超过长度不能简单从头部截断最好保留后半部分对话因为它更接近需要生成的终点。我一般在token化时设定truncation_sideleft从左侧丢弃多余的早期对话。4.2 显存估算7B模型LoRA微调的账怎么算网上一堆人发“幻的配置”但很少有人推演显存分账。我们来粗算一笔。7B模型以BF16加载单纯权重就是7e9乘以2字节约14GB。如果做全参数微调优化器状态按AdamW算还要再为每个参数保存两份额外的FP32状态和一份梯度状态显存直接爆炸。而用LoRA之后原始模型权重不仅冻结也不再产生优化器状态这14GB就是纯静态占用。接下来算LoRA本身的额外开销。假设7B模型有32层每层对q/k/v/o和两层MLP共6个线性层挂LoRArank设为16。每个线性层的LoRA参数量是hidden_size乘以rank乘以2hidden_size是4096即4096乘16乘2约131K乘以每层6个再乘以32层全部LoRA参数量约25M。这些参数完整保存需要25M乘2字节约50MB梯度又是50MBAdamW优化器状态是25M乘12字节约300MB。LoRA整体额外开销控制在400MB以内完全可以忽略。大头在两块中间激活值和采样后的动态临时变量。以batch_size为1、序列长度1024为例即使开启gradient checkpointing激活值预留大概2到3GB不开启的话可能到15GB以上直接跟权重冲突。所以我的经验下限是7B模型LoRA微调开启gradient checkpointing后24G显存可以跑batch_size为1或2如果用QLoRA量化权重单张16G的卡也能扛下来但比较极限24G就从容很多。4.3 超参数配置与训练执行SFT阶段的经典超参数范围如下LoRA rank一般在8到32之间常用16alpha一般设为rank的1到2倍比如rank为16时alpha取16或32这个参数只影响初始缩放倍数实际影响要看数据大小。学习率通常选2e-5到5e-5之间用余弦退火调度器前几百步做warmup。训练轮次对SFT数据来说不要贪多5万条高质量数据跑两到三个epoch就是比较合理的上限再多就会出现严重的重复生成问题。训练阶段对loss的观察也有门道。我看loss曲线时重点看的是下降趋势和震荡幅度而不是追求最小绝对值。如果loss在训练初期就异常低大概率是模型只是学会了复读模板开头真正该学习的知识没有被激活。如果loss下降极慢且持续震荡那可能是学习率过大或者数据里存在大量互斥的指令模式可以考虑先降学习率或者清洗数据再试。训练结束后保存的仍然是原始底座的完整权重加上一小份LoRA权重推理阶段把两者合在一起使用或者用框架动态加载LoRA adapter。5. 常见问题与排查心得实战中反复遇到的坑到了这个环节我要把训练过程中真正消耗我好几天时间的问题集中讲一遍。技术文档不会告诉你这些但项目时间表会因此被拖垮。5.1 显存OOM和训练速度慢OOM是最常见的问题但原因往往不同。如果训练刚开始就报OOM先看是不是别的进程占显存了用nvidia-smi确认。如果确实是自己爆的最先考虑两个方向降低batch size或开启gradient checkpointing。gradient checkpointing的原理是前向时丢弃中间激活值反传时重新算一遍用额外计算量换显存。开启后训练速度大约会慢20%到30%但在单卡场景下它能保证模型跑起来这点代价完全可以接受。另一种OOM发生在训练中途而不是刚开始。这种通常是由序列长度导致的。训练数据集中如果混入了一些超长的样本模型会根据padding和mask处理但长序列激活值峰值会暴涨。一个有效的做法是开启Dynamic Padding也就是把同一个batch内的样本按最大长度对齐而不是把所有batch都按全局最大长度来padding能显著压缩无效计算和临时显存。我之前在处理长短差异极大的对话数据时靠这一招把显存峰值直接压低了近40%。5.2 Loss为NaN或训练发散Loss出现NaN最典型的两个原因是FP16溢出和学习率过高。先把学习率降一个数量级试试比如从2e-4降到2e-5。如果问题仍是FP16模式下出现的直接把训练切成BF16或FP32模式。另外一个容易被忽视的坑是数据中存在无穷值或极端值——比如回答文本里包含了不可见的特殊字符、超长数字序列它们经过词表编码后可能产生异常梯度。排查方法是先对tokenizer后的token序列做一次长度和id范围检查把明显异常的样本剔除。还有一种情况loss不NaN但模型输出完全垃圾通常表现为不断输出同一个词或一句话的循环。这多半是SFT数据里存在大量重复的“机械式回答”或者epoch数太多导致模型过度拟合到高频模板。我的处理方案是检查训练集里的回复重复率设定一个阈值比如同一回复模板出现超过几百次就抽样替代同时在训练结束时用困惑度之外的指标如文本多样性做并行评估。5.3 多轮对话的隐藏陷阱多轮对话场景比单轮问答复杂得多最典型的坑是模型在长上下文里犯迷糊把早前对话内容“遗忘”。这里不单纯是注意力长度问题还涉及训练数据的构造一致性如果训练时每个样本都是从对话中间开始截断的但测试时却让模型从头回答模型会天然感到不自然。所以在多轮SFT数据里除了完整对话样例刻意加入一部分“只有最近两轮”的短对话样本能让模型更好地适应真实用户的切入方式。另一个隐藏陷阱是padding位置对attention mask的影响。如果采用右padding模型最后一层输出会集中在padding token上用它们来取loss会导致大量无效学习。实践中很多框架默认已经处理好这个问题但如果你是自己写训练循环一定要确认attention mask与loss mask完全独立且正确。我经常看到自制训练脚本的同学在这里翻车——loss不对齐训练一万步都是白跑。最后我差点忘了提一个常常被忽略的细节PEFT权重合并后务必用底层推理框架重新验证一遍输出。因为合并是把BA加进原始权重矩阵的过程如果目标模块指向错误或合并后精度被截断训练时评估正常部署后却表现受损。我个人的习惯是训练完成后立刻写一个冒烟用例带上几条第N轮追问和多轮长上下文样本统一做一次输出对比测试确认无误后才进入部署流程。这样做虽然多花二十分钟但能避免上线后才发现问题的尴尬。