1. 训练前先算清三笔账：显存、算力和时间
真正开始做大模型训练的人，几乎都经历过同一个阶段：看了一堆并行方案、显存优化技巧、微调框架的文档，落到自己手头的卡上时，还是不知道从哪一步开始。这篇文章我想把大模型训练的核心内容串成一条可执行的路径：先学会估算模型要吃掉多少资源，再决定用哪种并行方式，然后把混合精度、梯度累积这类工程细节调顺，最后落到LoRA/QLoRA这种低成本微调上。整篇文章不追求把每个算法推到最细，而是把“怎么选、为什么这么选、实际跑起来有哪些坑”讲清楚。
项目里最常出现的第一个问题，就是把模型直接往单卡上放。很多刚接触大模型训练的人觉得“显存不够就买更大显存的卡”，但真实情况是，训练大模型时显存消耗不是“模型文件有多大”，而是由四部分叠加而成：模型参数、梯度、优化器状态和激活值。如果只看到参数大小，后面八成会在显存或速度上翻车。
1.1 7B模型一次训练到底吃多少显存？
先说结论：一个7B模型，用AdamW优化器、混合精度训练，单卡几乎跑不起来。我们来算一下这笔账。
模型参数是7B个，每个参数如果是fp16就占2字节，参数本身约14GB。反向传播需要保存梯度，同样是14GB。优化器状态最重：AdamW要保存fp32的参数主副本、一阶动量m和二阶动量v，每个都是4字节，7B乘上3份乘4字节，约84GB。光这三项加起来就超过112GB，这还没算前向过程中会短暂占据显存的激活值。对比一张80GB显存级别的卡，连模型加梯度加优化器都放不下，更不用说跑前向和反向传播了。
这也是为什么“单卡硬扛大模型”在绝大多数情况下不现实。想要用多卡训练，本质上就是在用“并行技术”把这112GB乃至更多的显存压力分摊出去。理解了这笔账，再回头看各种并行方案，就会清楚它们分别省的是什么。
1.2 训练时间不是拍脑袋估算：算力公式怎么用
训练时间同样可以提前估算。大模型训练的浮点计算量大约等于 6 × 模型参数量 × 训练token数，这个6大致来自一次前向加一次后向传播中每个参数上的浮点运算次数。假设我们有7B参数模型，想在1T token上做预训练，总计算量就是 6×7e9×1e12 ≈ 4.2e22 FLOPs。
那实际算力有多少？一张80GB显存级别的旗舰卡在BF16下的理论算力约312 TFLOPS，按实际利用率50%~60%算，单卡有效算力约1.8e14 FLOPs。也就是说，单卡要跑接近7年，8卡也要接近一年，这还不算通信开销和反复实验的时间。看到这个数字，你应该能明白为什么绝大多数团队不会从零预训练一个超大模型，而是拿现成的开源基座模型做高效微调。微调的数据量小得多，同样一张卡上，几天甚至几小时就能完成一轮实验。
2. 并行技术怎么选：数据并行、模型并行和ZeRO落地
并行是分布式训练最核心的部分。它解决的就是第一节里的显存问题，同时兼顾训练速度。但并行方案非常多，数据并行、张量并行、流水线并行、ZeRO、FSDP……如果对这些概念没有清晰的分类，很容易在配置的时候手忙脚乱。我习惯把并行分成两类看：一类是“大家都复制一份模型，各算各的，再同步梯度”，这就是数据并行；另一类是“模型太大单卡放不下，只能把模型本身切开，让几张卡协作算同一份模型”，这就是模型并行。
大部分大模型训练场景都是两类混着用。下面按使用频率和实际收益排个序，方便你对照自己的场景挑选。
2.1 数据并行和ZeRO：大多数项目的默认起手式
数据并行最简单直观。每张卡都复制一份完整的模型，各自读不同的batch，前向反向完成后，用all-reduce把梯度同步到所有卡上，再统一更新参数。PyTorch的DistributedDataParallel（DDP）就是经典实现。它的缺点是显存占用不降反升：每张卡都要存完整参数、梯度和优化器状态，也就是第一节里算出来的那112GB一分不少。所以DDP对模型大小有上限，7B模型在80G单卡上仍然放不下。
ZeRO解决了这个问题。ZeRO的核心思路是把“冗余”的数据分片存储，不再让每张卡都保存完整副本。它分三个等级：ZeRO-1只分片优化器状态，ZeRO-2在优化器状态之上再加梯度分片，ZeRO-3则把所有状态包括参数都分片。对于微调场景，ZeRO-2基本是甜点配置，显存节省明显、通信开销可控；ZeRO-3省得最狠，但通信量会显著增加，训练速度可能反而不如预期。PyTorch原生的FSDP（Fully Sharded Data Parallel）思路与ZeRO-3接近，好处是不用额外装DeepSpeed，和transformers生态配合得也顺。
实操建议比较直接：先上DeepSpeed ZeRO-2或者FSDP，多数7B到13B模型用一张或多张消费级卡的微调任务就已经能跑起来。不要一上来就ZeRO-3，通信瓶颈后面容易变成新的麻烦。
2.2 张量并行与流水线并行：什么时候才真正需要
当单张卡的显存连“切分后的一层”都放不下，或者模型规模到了几十B甚至百B级别，数据并行和ZeRO就不够用了，这时候必须做模型并行。
张量并行（Tensor Parallelism，TP）是把一个Transformer层内部的矩阵运算切开。比如注意力投影是一个大矩阵乘法，可以按列切成两份，放到两张卡上各算一半，再用all-reduce把结果拼起来。这种方案通信非常频繁，每个层都要同步多次，所以TP最好只在单机内使用，依赖NVLink这类高带宽互联。跨节点强行用TP，网络延迟会直接把训练拖垮。
流水线并行（Pipeline Parallelism，PP）按层切分。把前若干层放在第一张卡，中间若干层放第二张卡，层与层之间传递激活值和梯度。它的问题在于会产生“气泡”，也就是某张卡等上一张卡算完才能启动，导致一部分算力空转。虽然GPipe、PipeDream这些调度策略能把气泡压下去，但PP仍然是三种并行里对使用条件最挑剔的一个。
所以我给团队的建议是：单机8卡以内，优先考虑ZeRO或FSDP；到了单卡放不下一个完整模型且机器间网络又只有万兆时，再考虑TP/PP/DP混合的“3D并行”。3D并行看起来专业，但调试复杂性成倍上升，不是所有项目都有必要上。
2.3 一套能直接用的DeepSpeed/FSDP启动配置
理论讲完了，给一套我经常用做基线的启动配置。下面是一个DeepSpeed ZeRO-2的配置示例，适用于在4~8张卡上做微调的场景：
{ "zero_optimization": { "stage": 2, "offload_optimizer": { "device": "cpu", "pin_memory": true }, "contiguous_gradients": true, "overlap_comm": true, "reduce_bucket_size": 5e8 }, "gradient_accumulation_steps": 4, "train_micro_batch_size_per_gpu": 1, "optimizer": { "type": "AdamW", "params": { "lr": 2e-5, "weight_decay": 0.01 } }, "scheduler": { "type": "WarmupDecayLR", "params": { "warmup_min_lr": 0, "warmup_max_lr": 2e-5, "warmup_num_steps": 100 } } }这里有几个参数非常关键。
gradient_accumulation_steps控制多少个micro-batch累积一次梯度更新，我习惯把它和真正的global batch size对应起来。比如单卡micro batch是1、8张卡、累积4步，实际更新一次参数用的batch size就是1×8×4=32，这个数字直接决定训练的稳定性和最终效果。
offload_optimizer把优化器状态放到CPU内存，适合显存紧张但CPU内存充足的机器，代价是每步都会增加Host-Device数据传输。reduce_bucket_size影响梯度通信的分桶大小，调大一些通常能降低通信次数，但太小会频繁同步损失性能。
如果你用FSDP，不需要DeepSpeed的配置文件，直接在PyTorch里给模型包一层就行：
from torch.distributed.fsdp import FullyShardedDataParallel as FSDP from torch.distributed.fsdp.fully_sharded_data_parallel import CPUOffload model = FSDP(model, cpu_offload=CPUOffload(device=torch.device("cpu")))这一层封装最大的好处是代码侵入小，而且对transformers类的模型基本是透明的。我实际对比下来，FSDP在7B~13B规模上，和DeepSpeed ZeRO-3的显存效果接近，但调试体验、报错信息友好程度都更好。
3. 混合精度与梯度累积：单卡效率的细节之战
并行解决了“多卡怎么一起训练”的问题，但单卡上的工程细节同样决定训练速度。混合精度和梯度累积是我每次必调的两个旋钮。
3.1 FP16和BF16怎么选，为什么现在首选BF16
混合精度的本意是：大部分计算用低精度（fp16或bf16）来跑，既省显存又加快计算，同时维护一份fp32的权重副本或关键状态来保证训练稳定。AMP（Automatic Mixed Precision）做的事情就是自动决定哪些算子用fp16、哪些用fp32，并在fp16大量出现时插入loss scaling。
FP16的问题是数值范围太窄，很容易溢出或下溢。直观地说，fp16的指数位只有5位，有效数字约3位十进制，大数一冲上去就变成inf，小数又容易变成0。解决这个问题要靠loss scaling，也就是在反向传播前把loss放大若干倍，更新权重时再缩小回去。PyTorch的GradScaler就是做这个的。
BF16的出现把这件事简化了一大步。BF16的指数位和fp32一样有8位，动态范围和fp32几乎相同，因此不存在溢出问题，也不用loss scaling。代价是尾数位从fp16的10位减少到7位，表示精度更低，但实验表明，对大规模模型训练来说，bf16带来的精度损失通常是可接受的，稳定性却大幅提升。所以只要硬件支持，我的默认选择就是bf16。
实操上，PyTorch里可以直接用torch.autocast("cuda", dtype=torch.bfloat16)包住前向和loss计算。使用原生分布式训练时，只需在初始化阶段把模型转为bf16：model = model.bfloat16()。用transformers的Trainer时，则设置fp16=False, bf16=True即可。需要注意的是，如果数据里频繁出现极小值，比如自监督任务中某些特殊loss，bf16的精度下降确实会造成指标明细损失，这种情况才需要退回fp32计算部分关键算子。
3.2 梯度累积、梯度裁剪与学习率策略的配合
梯度累积解决的问题是“物理显存放不下大batch”。它把一个大batch拆成多个micro-batch，逐个前向反向，梯度原地累加，等累积步数到了再做一次优化器更新。要注意两点：第一，梯度累积并不会减少总计算量，训练速度等同于小batch训练，但因为减少了参数更新次数，在大batch下往往更稳定；第二，如果用了loss scaling，需要确保每个micro-batch的gradient scale正确，如果不在意这一步，fp16下训练很容易出现梯度异常。
梯度裁剪是大模型训练里几乎必备的配置。长期训练中很容易碰到某个batch的loss异常大，反向传播出来的梯度范数飙到几百几千，一步就把权重更新冲坏。我用torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0)基本能挡住这类问题。max_norm取1.0是一个通用稳妥值，遇到loss特别容易爆的模型可以先调到0.5，如果模型收敛很稳定，也可以适当放宽。
学习率策略也是隐藏的关键项。大模型微调几乎都要做warmup和余弦退火。Warmup让学习率从小到大爬升，避免训练刚开始时大学习率把随机初始化的权重冲乱；余弦退火让学习率在训练后段平滑下降，帮助收敛到更稳的最优点。我常配的一组参数是：max_lr=2e-5，warmup步数占总步数的3%~5%，min_lr设置为max_lr的十分之一。过高的warmup比例会拖慢收敛，过低容易在开头就炸loss，这个比例是从多次实验里得到的经验值。
4. 高效微调实战：LoRA/QLoRA把成本压到极致
前面几节讲的都是训练基础设施，接下来是大多数人最关心的一块：在有限硬件上，把模型调成自己需要的效果。全参数微调当然效果好，但7B模型的全参微调光是优化器状态就已经把显存吃掉了绝大多数。于是PEFT（Parameter-Efficient Fine-Tuning）成了默认选择，其中LoRA和QLoRA是最常用的两种。
4.1 LoRA原理与参数配置：rank、alpha、target_modules
LoRA的思路是在原始权重矩阵旁边并联一个低秩分支。比如某个权重矩阵W是d×d，正常情况下它参与y = Wx，LoRA把它改成y = Wx + BAx。其中B的维度是d×r，A的维度是r×d，r远小于d。训练时W被冻结，只更新B和A，可训练参数量从d×d降到了2×d×r。以7B模型为例，如果只对注意力层的查询和值矩阵做LoRA，可训练参数量通常是几百万到一两千万，只占全模型的1%左右。
rank（即r）决定低秩子空间的表达能力。r太小，线性层的表达能力不够；r太大，LoRA引入的参数和显存开销都会增加，而且并不一定带来更好效果。我默认从r=8或r=16开始尝试，如果验证集指标不够，再往32提，多数任务在16附近就能达到不错效果。
alpha是一个缩放系数，实际生效的LoRA分支要乘上alpha/r。LoRA论文里的一个默认经验是把alpha设为r的两倍，比如r=16时alpha=32。这样在训练初期LoRA分支的更新幅度不会过大，冻结的原权重不会被冲得面目全非。
target_modules决定对哪些模块注入LoRA。常见的做法是只对注意力层的查询和值投影做LoRA，这是最省算力的方案；如果想追求更高效果，可以再加上键投影、输出投影以及前馈网络里的几个投影，但这会让可训练参数翻好几倍。我的建议是：先只调查询/值矩阵跑通流程，确认数据没问题后再逐步放开，不要一上来就全模块注入。
一个典型的PEFT配置用代码写出来是这样的：
from peft import LoraConfig, get_peft_model lora_config = LoraConfig( r=16, lora_alpha=32, target_modules=["q_proj", "v_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_config)这里lora_dropout默认经验是0.05，偏低的dropout有利于保留原始模型的先验知识。bias一般都保持"none"，完全不训练bias，减少不稳定因素。
4.2 QLoRA量化微调：24G显存跑13B模型的操作细节
LoRA虽然省了可训练参数，但模型本身的权重还是要完整加载到显存里。一个7B模型在bf16下光权重就占14GB，加上激活值和LoRA的梯度，24G显卡勉强够用。如果模型到13B，连权重都放不下，QLoRA就在这个背景下派上用场。
QLoRA把原始权重做4bit量化后再加载，量化权重本身只占原来的1/4，同时依然对需要训练的低秩分支保持bf16精度。它用了一种叫NF4的量化格式，比普通的int4更适配正态分布权重；再用双重量化把量化常数也量化，省下额外显存；最后靠分页优化器处理某瞬间超出的显存请求，把它暂时落到CPU内存。这些细节决定了QLoRA不只是“简单的4bit加LoRA”。
实际跑起来，单张24G显存卡可以训练13B模型的QLoRA，甚至16G显存的卡也能勉强跑7B。我用过的一个基础配置大致如下：
from transformers import AutoModelForCausalLM, BitsAndBytesConfig from peft import LoraConfig, get_peft_model bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_use_double_quant=True, bnb_4bit_compute_dtype="bf16", ) model = AutoModelForCausalLM.from_pretrained( "some/open-llm", quantization_config=bnb_config, device_map="auto", ) model = get_peft_model(model, lora_config)需要注意几个细节。compute_dtype建议设成bf16，保持计算精度同时避免fp16数值问题。device_map="auto"让transformers自动把量化权重分布到多卡或CPU上，省去手动分配。如果训练时发现速度很慢，先检查是不是offload到CPU太频繁，这种情况通常意味着显存确实吃紧，可以调小max_length或者减小batch。
推理阶段要特别注意：QLoRA训练得到的LoRA权重可以直接合并回4bit模型，但如果要导出用于部署，建议先把模型用bf16权重合并后导出，否则某些推理框架对4bit基座支持不稳定，可能输出乱码。
4.3 微调数据的组织方式和过拟合判断
数据组织是微调效果的分水岭。指令微调最基础的数据格式是“指令加输入加输出”三元组。对对话模型，要组织成多轮对话结构；对代码模型，要保留完整的代码块上下文。我给团队定的一个惯例是：每条样本不要只给模型“标准答案”，而是附上尽量接近真实使用场景的上下文，否则模型只能学到格式，学不到迁移能力。
训练时，我会把数据按9:1切训练集和验证集。验证集不可参与训练，用于观察eval loss。如果训练loss持续下降但eval loss先降后升，就是过拟合信号，此时应该增加数据量、提高LoRA dropout，或者降低rank。不要只看训练集loss，这一步是最容易被新手忽视的。
还要警惕灾难性遗忘。比如拿通用对话模型做垂直领域指令微调后，模型在处理原本擅长的通用问题时可能变笨。缓解办法是在微调数据里混合10%~20%的通用数据，让模型在学新任务时不会完全丢掉旧能力。这个比例是个经验值，数据越偏向通用，遗忘越轻，但新任务的学习速度也会变慢。
5. 训练排障手记：常见问题、定位思路和避坑经验
训练大模型最耗时间的不是搭建框架，而是调试。模型和数据规模都很大，出问题时定位路径和普通小模型训练有些不同。我把自己踩过的坑整理成几类，方便你对照排查。
5.1 loss不降或震荡怎么办
loss从第一步开始就不降，最常见的几个原因我按排查顺序列出来。
首先检查数据。喂进去的样本有没有大量空文本、全是特殊token、或者标签严重错位。我习惯在训练前写一个简单的数据抽样脚本，把dataloader里实际出来的batch打印成文本肉眼检查一遍，很多问题在这一步就能发现。
然后是学习率。如果loss从几千直接到nan，多半是学习率过高或者梯度爆炸，先把学习率降到1e-5以下，并打开梯度裁剪。如果loss在固定值附近来回震荡，比如一直卡在7.3这种常数附近，那很可能是模型的输出被某种先验概率锁死了，常见于分类头初始化异常或数据里某种标签占比超过99%。
还有一种非常值得养成的排查习惯：先拿少量样本做overfit测试。取100条训练样本，反复训练很多个epoch，如果loss不能降到很低，说明模型结构或数据管线有问题；如果连100条都过拟合不了，那几乎可以断定是数据或参数配置有问题，而不是训练量不够。我通常在正式训练前把这个测试作为必跑项，能省下大量调参时间。
5.2 OOM、通信超时与checkpoint异常
OOM是最常见的报错，但“显存不够”背后原因不同。如果是在前向阶段OOM，多半是单卡batch或序列太长，先把max_length缩短、micro_batch_size降到1，再配合梯度累积。如果是在反向阶段OOM，要考虑是否开了太大的显存buffer，可以减小reduce_bucket_size，或开启激活重计算（activation checkpointing）。激活重计算用“多算一遍前向”换显存，典型能省30%~50%激活显存，是性价比很高的手段。
通信类问题里，最常见的两个是NCCL超时和AllReduce卡死。NCCL timeout通常发生在跨节点训练时，某台机器网络不通或带宽过慢，可以先跑一个nccl-tests测试多机通信带宽，排除硬件问题。如果AllReduce卡死，多数是因为某张卡提前退出或数据加载不均匀，典型症状是一部分rank在等梯度，另一部分rank已经去打印日志了。检查每个rank的数据量、随机种子、batch分配逻辑是否一致。
checkpoint保存也是一个容易被忽略的坑。多进程同时写同一个路径，会让部分rank保存失败；CPU offload数据在保存时需要先收回到设备，否则容易出现设备端数据不完整。我的解决方法是统一用一个rank写文件，保存前先同步所有rank，再一次性完成IO。写完后立即重新加载验证，不要在训练几天后才发现checkpoint是损坏的。
5.3 训练完成之后：评测与部署衔接
训练完成不等于结束。很多项目在微调后只盯着训练loss，结果模型上线才发现答非所问、格式混乱。我的建议是，在训练开始前就定义好评测集：至少包括领域能力测试、通用能力抽样、格式符合率三项。领域能力验证微调是否学到目标知识，通用能力抽样确认没有灾难性遗忘，格式符合率防止模型学会了内容但不会按预期格式输出。对生成任务，有条件的话还要加人工评测，因为自动指标对长文本生成的质量判断很有限。
部署方面，如果训练用的是LoRA，推理前可以把LoRA权重merge进基座，导出为一个完整模型文件，也可以保留基座加LoRA分开部署。合并后的模型在加载和推理时少一层，部署更简单；分开部署的好处是可以随时切换多个LoRA适配器，适合同一基座服务多场景。我一般会同时导出两种形式，一个用于正式上线，一个用于实验验证。导出的数据类型也值得留心，优先统一用bf16或fp16，避免和推理框架精度不一致导致结果波动。
最后再说几句经验。如果只挑一条最重要的经验分享，我会选“把训练过程可视化”。loss曲线、学习率曲线、梯度范数曲线，这三个图几乎能回答训练中80%的问题。loss不降看数据和学习率，学习率异常看warmup和schedule，梯度范数爆涨看裁剪和优化器状态。很多看似玄学的问题，放到曲线上一眼就明白了。
大模型训练这个领域变化太快，但底层思路是稳定的：先算清资源账，再选并行方案，然后把单卡工程细节调到位，最后用PEFT快速迭代实验。希望这篇文章能给你提供一个可执行的起点，少走一些我走过的弯路。
