又到了纠结显卡的时候。32GB还是128GB这问题在我朋友圈出现的频率快赶上“今天吃啥”了。玩大模型训练的朋友不管是大厂调参侠还是小团队自建几乎都被显存卡过脖子小卡跑不动大卡租不起换了顶级卡又发现瓶颈不在显存而在通信。这篇文章不打算给你堆参数表而是基于我自己在单卡到多卡、7B到70B折腾下来的真实经验把大模型训练的显存选型和任务拆解这两件事拆开揉碎聊清楚32GB到底能干嘛128GB的钱该不该花以及怎么把一个大训练任务拆成能让模型和agent各司其职的小步骤。1. 先搞懂显存到底消耗在哪再谈选型1.1 显存不只是装参数四块大头各占多少很多朋友一开始都觉得显存就是用来放模型权重的这是个误区。训练一个模型显存里同时待着的至少有四类数据模型参数、梯度、优化器状态、激活值。如果再算上临时缓冲区、通信缓冲、CUDA context水面下还压着一大块看不见的消耗。以7B模型、混合精度训练为例模型参数用bf16存储每10亿参数大约占2GB梯度同样是每10亿参数2GB优化器状态最夸张如果用AdamW每个参数要保存fp32主权重、一阶动量、二阶动量三份数据每10亿参数就是12GB。三者加起来每10亿参数吃16GB7B模型光是参数、梯度、优化器状态就要大约112GB。激活值还要另算这部分和batch size、序列长度强相关序列越长越恐怖。这个账算清楚后你就能明白为什么一张32GB卡几乎不可能全参微调7B也就能理解为什么LoRA这类技术会火成现在这样。省显存的本质无非就是两条路减少参与梯度更新的参数量或者把梯度、优化器状态这些冗余数据切到多张卡上。1.2 一个7B模型在不同模式下的显存账本我们把同一份“7B参数”放到三种场景里看感受会非常直观。如果只做推理只加载bf16权重14GB给KV cache留个2GB左右单张32GB卡非常宽裕。如果想跑更长序列把batch调大32GB也能撑不少并发。如果做全参微调参考1.1的计算112GB的硬性下限在那边摆着单卡32GB肯定没戏。有人会说我用梯度检查点、用混合精度、把batch设成1总该能塞进去吧但优化器状态是省不掉的除非你用Adam的省内存变体或者直接冻结大部分参数否则该爆还是爆。如果做LoRA或QLoRA微调情况完全不同。LoRA把可训练参数压到几千万到两亿级别梯度、优化器状态跟着缩小几个数量级QLoRA再把基础模型权重从bf16的14GB压到4bit的3.5GB左右。这样算下来7B的LoRA训练在32GB显存上能跑得相当舒服这也是我经常建议小团队先别急着上大显存的原因。1.3 选型之前先确认训练方式同样的模型推理、全参微调、LoRA微调、继续预训练显存需求天差地别。32GB还是128GB这个问题本质上不是在问买哪张卡而是在问你接下来一年要跑什么任务。如果是基于开源模型做垂直领域微调绝大多数情况LoRA就能满足32GB是甜点。如果你想做领域继续预训练数据量大、序列长、还要看loss曲线那么单卡32GB会非常憋屈128GB的多卡方案才谈得上效率。如果目标是70B甚至更大模型的全参训练那就不是单张卡的问题而是整个训练集群怎么设计的问题了。先定训练方式再定显存顺序不能反。2. 32GB和128GB的边界到底在哪2.1 32GB能扛住的场景与上限我自己在32GB单卡上跑得最多的组合是7B模型加LoRA配合bf16混合精度batch size开4序列长度2048显存占用大概在24GB到28GB之间实际能跑。如果把基础模型换成4bit量化同样配置下甚至可以把batch开到8序列长度拉到4096显存还能剩个两三GB。13B模型用32GB单卡也能做LoRA但batch和序列长度就要保守很多。常见做法是4bit量化、batch 2、序列长度2048训练速度会明显下降不过至少能跑。所以如果你主要任务是做垂直领域的模型微调数据量几万到几十万条32GB单卡完全够你完成从实验到交付的完整闭环。32GB的上限在哪里我的体会是全参微调7B基本别想除非你有极其特殊的省显存姿势70B模型直接加载权重做推理也吃力但用4bit量化勉强能跑。它最适合的定位是“单卡练手、小规模微调、快速验证想法”。2.2 128GB适合哪些任务128GB单卡的好处不是“能塞更大模型”而是“减少了切分模型的必要性”。如果你要在一个设备上跑70B模型的LoRA4bit量化后权重约35GB128GB卡可以轻松加载再留出大量空间给激活值、长序列和更大的batch。这在处理长文档、多轮对话数据时特别有用因为序列长度和batch大小直接决定了训练吞吐。再往上走多卡128GB组合的意义在于做更大模型的全参或半参数训练。但这里必须说句实话70B模型全参训练使用混合精度和AdamW光参数、梯度、优化器状态就要1120GB左右。8张128GB卡加起来是1024GB仍然不够还得靠激活重计算、CPU offload甚至牺牲batch来硬撑。所以128GB解决的是“单卡大模型微调”和“中规模全参训练”并不是买了128GB就能为所欲为。我自己建议的边界很明确如果你手里有垂直领域数据想微调一个7B或13B模型32GB足够起步如果你要处理的数据非常长、批量非常大或者要微调70B级模型才会真正需要128GB。2.3 别忽略带宽和多卡互联容量之外的显存陷阱讲一个我踩过的坑。有一段时间我觉得单卡32GB不够租了几张更高显存的服务器结果训练速度没有想象中快。后来发现瓶颈根本不在显存容量而在卡间互联带宽。显存容量是仓库显存带宽和卡间互联是传送带。仓库再大传送带不够宽货也运不快。比如TP这类并行策略每个Transformer层的前向反向都要做多次all-reduce操作如果卡间走PCIe 3.0通信延迟会直接拖垮整个训练。NVLink、NVSwitch、InfiniBand这些词在选型时比显存容量更值得你关注。所以我的经验是选多卡方案时优先保证节点内卡间互联足够好。同样预算下4张通信良好的32GB卡跑某些任务可能比8张工程机堆出来的128GB卡还快。显存容量决定能不能跑通信带宽决定跑得快不快。3. 任务拆解是agent的能力但更大程度是工程习惯3.1 谁负责拆解agent还是模型最近有个话题挺有意思任务的规划与拆解到底是agent的能力还是模型的能力。我做了这些训练任务之后观点很明确模型负责在给定子任务内生成结果agent负责调用工具、跟踪状态、编排流程而真正高质量的拆解必须由人或设计者提前定义清楚。以训练一个模型为例如果只丢给agent一句话“你把这个模型训练好”它大概率会把任务拆得乱七八糟。但如果你把任务拆成“准备数据”“小模型验证”“资源试跑”“正式训练”“效果评估”每个子任务再给明确的通过标准这时候agent才能真正帮你干活。任务拆解决不是花架子它是把巨大的训练工程变成一个个小实验的能力。我在实际项目里第一版任务拆解总是非常笨拙重要指标经常漏掉。后来养成了“每个子任务必须能独立验证”的习惯比如数据处理完就看格式和样本分布小模型跑完就看loss下降趋势正式训练跑完第一轮就提前判断要不要止损。这套流程跑顺以后显存选型反而变成了一个非常自然的结果。3.2 先从数据拆解垂直领域数据来源与清洗很多训练任务在显存上翻车根子不在模型而在数据。数据没有拆解清楚会导致训练时batch大小、序列长度、epoch数全部拍脑袋显存需求自然算不准。拿数控机床维修这个垂直领域举例。如果要做一台维修大模型数据来源通常很杂设备操作手册、维修工单、故障代码表、传感器时序日志、老师傅的维修笔记。这些数据格式完全不同必须先拆解成统一的训练样本格式比如“故障现象设备型号”为输入“排查步骤修复操作”为输出。我在处理这种数据时会先把每个来源分别清洗、去重再做字段对齐。维修手册里的文字要被切成长度相近的段落维修工单里的口语表达要转成结构化描述传感器日志要按时间窗口切成样本。这个步骤看着不烧显存但训练时你会发现同一批数据里如果一部分是长文本、一部分是短代码那么batch里的序列长度会被最长样本拖死显存利用率极低。数据拆解好之后才能按长度分桶训练显存使用更均匀。3.3 先训小模型再放大最省钱的拆解方式“大模型先训练小模型”这个说法我理解成两层意思。一层是正式训练大模型前先用小模型把整条流水线跑通另一层是小模型可以当大模型的“替身”做大量消融实验跑出趋势后再放大。实操中我会先用1B或3B模型加载同一条数据管线训练几十步看loss能不能降、数据有没有bug、显存占用是否稳定。这一步在32GB单卡上几分钟就能完成但能避免你在128GB多卡上跑了一天才发现代码里有个数据顺序错乱的问题。小模型跑通之后再切到7B、13B甚至更大的模型心里就有底了。很多人觉得小模型和大模型结论不一致怕白做。这个担心有一定道理但我的处理方法是小模型阶段只看流程和相对趋势不看绝对效果。比如小模型上LoRA rank多少损失下降更快小模型上长序列会不会训练不稳等这些趋势在大模型上通常成立。用这些结论指导大模型再配合少量大模型验证效率会高出很多。3.4 任务拆解和显存选型的关系任务拆解做到位显存选型就变得很具体。比如你把任务拆成“用10万条数据做7B模型LoRA微调目标是让回答涵盖知识库中的故障类型”这时候你可以很清楚地估算单卡32GBbatch设4序列长度2000跑5个epoch大概多久显存够不够。如果你不拆解张口就是“我要训练大模型”那32GB和128GB的争论永远没有答案。我的建议是动手买卡或租卡之前先在文档里把任务拆到“每个子任务都有明确输出”的程度。只有当你能写出“数据处理后多少条、序列长度分布如何、训练多少步、评估指标是什么”的时候才能算出到底需要多少显存也才能让agent帮你自动执行这些子任务而不是让agent猜你下一步要干嘛。4. DP、TP、PP三种并行方式怎么选4.1 数据并行DP和ZeRO显存不够时的第一反应数据并行是最容易理解的方式每张卡放一份完整模型各自处理不同batch的数据前向反向完成后把所有卡的梯度做一次同步再更新参数。它解决的天然是“单卡能放下模型但速度不够”的问题并不能直接帮你减小单卡显存。为了突破这个限制DeepSpeed的ZeRO出现了。ZeRO的原理是把冗余的优化器状态、梯度、参数按DP维度切分让每张卡只保存一部分。开启ZeRO-3之后7B全参训练在几张32GB卡上成为可能因为本应由每张卡各自保存的112GB状态被摊薄到了多卡上。我常用的DeepSpeed配置长这样核心是zero stage选3{ train_batch_size: 64, train_micro_batch_size_per_gpu: 2, gradient_accumulation_steps: 8, bf16: { enabled: true }, zero_optimization: { stage: 3, offload_optimizer: { device: cpu, pin_memory: true } } }这里train_batch_size是全局总batchtrain_micro_batch_size_per_gpu是每张卡每次前向的batch两者相除再除以卡数就是gradient_accumulation_steps。我一般先定micro batch再反推累积步数这样显存不会爆。ZeRO-3配合CPU offload能把优化器状态挪到内存里进一步省显存但训练速度会明显变慢适合实在挤不出显存时使用。4.2 张量并行TP单卡放不下单个层时的切分思路当模型大到一张卡连单个Transformer层都放不下时就需要张量并行。它把每个层的矩阵按行或列切开分散到多张卡上再用all-reduce把结果拼起来。TP的优点是一张卡不用保存完整的层缺点是通信量非常大每个Transformer块的前向反向至少要同步两次。我在实践中的判断标准是只有当单张卡的显存不足以容纳模型的最小切分单位时才优先考虑TP。TP的并行度不能盲目开大一般不超过节点内GPU数。比如一节点8卡TP8是极限如果跨节点做TP通信走网线基本就是慢性自杀。给个参考在8卡节点上跑30B模型全参微调卡间是NVLink的话TP4或TP8都可以接受如果是PCIe互联TP4会是更稳妥的选择再往上通信开销会吃掉很多计算收益。4.3 流水线并行PP多机场景的性价比选择流水线并行按层切分模型GPU0跑第0到第7层GPU1跑第8到第15层这样每张卡只需要持有模型的一部分层。它比TP通信量小很多因为只需要在层的边界传递激活值和梯度所以跨节点场景下PP往往比TP更现实。但PP有气孔问题一个batch被切成多个micro batch流水线地通过各层总有卡在等上游算完的时候。micro batch数量越多流水线越满气孔比例越低但每个micro batch过小又会降低计算效率。因此在PP配置里梯度累积步数天然就比较大整体batch不要设太小。实际项目里常用的是“PPDP”组合先按层切分再把每个层段复制到多张卡做数据并行。如果要同时处理超大模型还会再加上TP形成大家常说的3D并行。4.4 三维组合怎么定先做压力测试再定方案模型训练并行方式不是拍脑袋定的我每次换新模型都会先写一个“单batch压力测试”脚本加载模型把一个batch的数据跑一遍前向反向打印每张卡显存峰值。用这个结果去估算不同并行配置下的显存余量再决定TP、PP、DP怎么组合。一个简单的启动命令可能是这样配合Transformers的Trainer使用deepspeed --num_gpus 8 train.py \ --model_name_or_path your_model \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --deepspeed ds_config.json如果你试了一个batch就OOM那就把per_device_train_batch_size减半或者把gradient_accumulation_steps调大。如果单个batch勉强跑通但训练过程卡得不行就要检查TP规模是不是太大或者CPU offload把速度拖垮了。我在踩过几次坑之后得出一个结论并行配置的正确姿势不是求最优而是求“显存刚好放得下、通信刚好不爆炸”的那一组常规参数。5. 32GB单卡实战LoRA、梯度累积与激活重计算5.1 用LoRA把7B训练降维到单卡能跑LoRA的思路非常简单冻结原始模型的所有参数在每一个需要更新的层旁边插入两个低秩矩阵。训练时只更新这两个小矩阵原始模型参数只参与前向和反向计算不保存梯度和优化器状态。这样显存占用大幅下降效果在很多任务上又能逼近全参微调。我用HuggingFace的PEFT库做LoRA微调时核心代码其实很少from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training # 4bit加载基础模型 model AutoModelForCausalLM.from_pretrained( model_name, load_in_4bitTrue, bnb_4bit_compute_dtypetorch.bfloat16 ) model prepare_model_for_kbit_training(model) # 配置LoRA lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, v_proj], lora_dropout0.05, biasnone ) model get_peft_model(model, lora_config) model.print_trainable_parameters()这里target_modules一般选注意力层的q_proj、v_proj就够用了r是低秩矩阵的维度r越大可训练参数越多表达能力越强但显存开销也越大。我习惯先用r16做初试效果不够再加到32不要一上来就追求大r。5.2 梯度累积与激活重计算的取舍32GB卡上跑LoRA虽然显存宽裕但如果你把batch提高到8再把序列长度拉到4096照样会OOM。这时候最常用的两个手段是梯度累积和梯度检查点也就是activation checkpointing。梯度累积的原理是用多个小batch的梯度累加后再更新一次参数从数学上等价于更大的batch。代价是训练时间变长因为每个小batch都要额外做一次反向传播但你可以接受。比如per_device_train_batch_size2、gradient_accumulation_steps8实际等效batch size是16但显存开销只相当于batch size2。激活重计算则是在前向传播时丢弃中间激活值反向传播需要时重新计算一遍。它能省很多显存代价是大约增加30%的计算量。在Transformers Trainer里只要设gradient_checkpointingTrue就可以了。我通常在长序列任务里同时开启这两项效果立竿见影。5.3 怎么把32GB吃到恰到好处如果你有32GB单卡跑7B LoRA我的建议是先用bf16混合精度关闭CPU offload然后从per_device_train_batch_size4、序列长度2048开始手动看nvidia-smi的显存占用。如果峰值接近31GB就先减序列长度或batch。如果峰值在28GB左右可以尝试把batch加到8或者把序列长度拉到4096。原则是让显存利用率保持在80%到90%留一点余量给临时缓冲和意外波动。这里有个很容易犯的错只看总显存不看峰值显存。PyTorch的显存分配器是惰性的totalUsedMemory看起来没满但cudaMalloc突然失败。遇到这种问题先检查是不是CUDA context占了小几百MB然后看看activation memory是不是在某个超长样本上暴涨。把数据按照序列长度分桶每个batch内长度尽量均匀能明显缓解这个问题。6. 128GB多卡实战70B微调与断点续训6.1 70B全参训练的显存估算70B全参训练为什么那么吃显存我们再用公式看一遍。70B模型混合精度加AdamW参数、梯度、优化器状态合计大约是70乘以16GB等于1120GB。这是什么概念8张128GB卡加起来1024GB还不够16张128GB卡总共2048GB才比较从容。所以70B全参训练根本不是单卡问题而是集群设计问题。如果换一种任务70B LoRA微调情况就不一样了。4bit量化后基础模型权重约35GBLoRA可训练参数和优化器状态加一起不到10GB激活值看batch和序列长度128GB单卡有充足余量。所以128GB真正能覆盖的是“单卡或少量卡跑70B级微调”而不是“单卡全参训练”。实践经验里我用128GB级显卡跑70B LoRA时batch可以开到8到16序列长度拉到8192这在32GB卡上几乎不可能做到。长序列带来的训练质量提升在很多文档理解、代码生成任务里非常明显。6.2 多卡并行配置示例假设你要用8张128GB卡跑一个70B模型的LoRA微调并行策略我会推荐“DeepSpeed ZeRO-3 较小的TP”。ZeRO-3负责把模型参数、梯度、优化器状态按DP维度切分TP用来处理单卡放不下的层。config可以这么给{ train_batch_size: 128, train_micro_batch_size_per_gpu: 4, gradient_accumulation_steps: 4, zero_optimization: { stage: 3, reduce_bucket_size: 5e8, stage3_prefetch_bucket_size: 5e8, stage3_param_persistence_threshold: 1e6 }, tensor_parallel: { enabled: true, tp_size: 2 }, bf16: { enabled: true } }注意这里的tensor_parallel是DeepSpeed的配置不是所有版本都支持传统做法是在模型初始化时手动用model_parallel切分或者直接用Megatron-LM。如果你用的是Transformers Trainer更稳妥的方式是先只开ZeRO-3让框架自动切分参数训练脚本反而简单得多。启动时仍然用deepspeed命令指定8卡即可。最重要的一个提醒大模型启动时模型初始化会短时间内吃掉大量显存建议开一个debug环境先用1%的数据试通再正式跑。6.3 断点续训到底影响不影响效果“断点续训影响训练效果吗”是我最近被问得特别多的问题。答案很简单续训本身不影响模型上限但续训方式不对一定会影响。影响最大的坑是只保存模型权重不保存优化器状态、学习率调度器状态和RNG随机状态。你可以把训练想象成一辆车在爬坡模型权重是当前车的位置优化器状态是车的惯性学习率调度器是油门曲线随机状态是方向盘。你只保存位置重新点火后车停在原地但惯性没了油门曲线从头开始方向盘方向也变了整个训练轨迹自然就歪了。正确的续训流程至少应该包含四样东西模型权重、优化器状态、学习率调度器状态、数据加载器进度。在训练脚本里我一般每N步保存一次checkpoint把model、optimizer、scheduler、dataloader四个对象全部存进去。恢复时按相反顺序加载再手动把global_step和随机种子恢复。Transformers Trainer和DeepSpeed都有封装好的resume_from_checkpoint参数直接用就行。另外还有一个容易被忽略的点分布式训练中断后恢复必须保持和中断时相同的并行配置。你用TP4、PP2跑出来的checkpoint恢复时也必须用同样的TP和PP配置否则各个分片对不上。换并行度就等于换了模型存储结构必须重新合并权重再做切分这个操作很麻烦最好从一开始就定好配置。7. 常见问题速查与我的实操心得7.1 遇到OOM先做这几步别急着加卡在社区里看到很多人一OOM就喊加卡但很多时候优化一下配置就能跑。我的排查顺序是固定的。先看错误日志确认是CUDA out of memory还是正常报错。如果是显存溢出第一件事把per_device_train_batch_size改成1序列长度改成512先让程序跑通。跑通以后再依次开混合精度、开gradient_checkpointing、把batch加回去、把序列长度加回去。如果加batch到4又爆了就开LoRA或QLoRA或者用ZeRO-2、ZeRO-3。如果这些手段都用完还是OOM才考虑换卡或加卡。但我建议换卡前先看一眼时间成本一个batch都跑不动说明模型规模和你的硬件差距太大换卡是对的如果只是某个超长样本导致OOM那数据分桶比换卡更实在。还有一种情况是通信缓冲导致OOM这时候加大reduce_bucket_size反而会让情况恶化需要看具体日志判断。7.2 一份显存选型决策表我总结了一张高频任务对应的显存选型表适合大多数人做快速判断。它不是绝对标准但能帮你避免最夸张的配置错误。任务模型规模最小可用配置推荐配置7B LoRA微调7B1×24GB卡1×32GB卡7B全参微调7B4×32GB卡ZeRO-34×40GB以上卡13B LoRA微调13B1×32GB卡1×32GB卡或2×32GB13B全参微调13B4×80GB卡8×80GB卡70B LoRA/QLoRA70B1×32GB卡4bit量化1×128GB卡70B全参微调70B16×128GB卡更大集群这张表不是为了劝你买最贵的卡而是为了让你明白71%的常规微调任务一张32GB单卡就能搞定。128GB真正的价值是大batch、长序列、以及减少并行切分带来的心智负担。7.3 一些容易被忽略的实操细节最后分享几个我在实际项目中踩过或者看到别人踩过的细节问题。第一关闭训练模式不等于kill -9。有些人想让训练停下释放显存直接ctrlz或者kill -9进程是没了但训练进度全部丢失。如果程序支持信号处理尽量优雅退出让它先保存checkpoint再释放显存。没有优雅退出的话至少也要在代码里定期保存checkpoint把损失控制在最后几步之内。第二显存不够时CPU offload不是银弹。把优化器状态或者模型参数offload到CPU内存虽然能跑但速度可能慢到令人崩溃。我在32GB卡上试过把7B模型的优化器offload到CPU跑一个batch的耗时比正常情况多了好几倍。如果一定要offload请确认你的数据规模不大并且对训练时间没有硬性要求。第三agent和模型协作时别把任务拆解全交给agent。agent很擅长把任务拆成清单但清单是否正确、有没有遗漏关键约束还是要靠人去检查。我会把“最小验证集上的目标指标”作为每个子任务的验收条件agent跑完子任务后自动汇报结果由我来判断是否进入下一阶段。第四不要盲目追求纯原生大模型。很多任务用7B模型加上精心处理的垂直数据效果已经够用。训练数据质量和任务拆解的颗粒度往往比那多出来的几十GB显存更影响最终结果。第五关闭“大模型训练模式”这种说法我理解成“如何让训练任务优雅停止”。正确的做法是在训练脚本里监听中断信号收到信号后保存checkpoint再退出。如果运行环境不允许捕获信号那就用固定步数保存并且把每步的训练状态都写到同一个checkpoint目录这样随时都能恢复。我个人实际操作中的体会是显存选型没有标准答案只有适不适合当前任务。你先花半天时间把任务拆解清楚然后用小模型跑通流程再去判断32GB够不够、128GB值不值。绝大多数时候你会发现显存只是阶段性的约束真正决定训练效果的是对数据的理解和任务切分的功力。
