1. 先搞清楚LoRA微调到底吃多少显存显存估算这件事说穿了就是一道加法题。很多人一上来就盯着模型参数量看觉得7B模型用fp16加载也就14GB32GB卡肯定绰绰有余结果一跑训练就OOM。问题出在训练时的显存占用和推理完全不是一个量级训练要额外存梯度、优化器状态、中间激活值还有LoRA适配器本身的参数和梯度。1.1 显存占用的四大块拆解我把训练时的显存占用拆成四块来看这样估算的时候不容易漏项。第一块是基座模型权重。这部分取决于你用什么精度加载。fp16是2字节每参数7B模型就是约14GB。如果用4bit量化加载QLoRA大概3.5到4GB。8bit的话约7GB。这里有个容易忽略的点即使你冻结了基座模型不训练权重本身还是要占显存的只是不存它的梯度和优化器状态。第二块是LoRA适配器参数和梯度。LoRA的参数量取决于你挂载的模块和秩rank。以7B模型为例如果对q_proj、k_proj、v_proj、o_proj都挂rank16的LoRA参数量大概在几百万到千万级别。fp16下每参数2字节梯度也是2字节再加上AdamW优化器要为每个参数存一阶矩和二阶矩各2字节所以LoRA部分的显存大概是参数量 × (2222) 参数量 × 8字节。假设LoRA参数量是2000万那就是约160MB相对基座来说很小。第三块是激活值。这是最容易被低估的部分。激活值的大小和batch size、序列长度、模型层数、隐藏维度都相关。序列长度翻倍激活值大概翻倍batch size翻倍激活值也翻倍。用gradient checkpointing可以把激活值显存降到原来的三分之一到四分之一代价是训练速度慢20%到30%。第四块是临时缓冲和碎片。CUDA kernel运行时的临时张量、通信缓冲、显存碎片这部分通常占总量的5%到15%。32GB卡上跑7B QLoRA我一般会预留2到3GB给这部分。1.2 一个可以直接套用的估算公式我平时用的快速估算公式是这样的总显存 ≈ 基座权重显存 LoRA参数与优化器显存 激活值显存 缓冲余量其中激活值显存可以用这个经验公式粗估激活值 ≈ batch_size × seq_len × hidden_size × num_layers × 系数系数取决于是否用gradient checkpointing。不用的话系数大概在10到20之间还要乘2字节用了的话降到3到5。这个系数不是精确值但用来判断“能不能跑”足够了。举个例子7B模型hidden_size4096num_layers32seq_len512batch_size4开gradient checkpointing。激活值 ≈ 4 × 512 × 4096 × 32 × 4 × 2字节 ≈ 2.1GB。加上基座14GBfp16、LoRA约0.2GB、缓冲2GB总共约18.3GB。32GB卡跑这个配置很轻松。如果把seq_len拉到2048batch_size拉到8激活值就变成约17GB总数超过33GB直接OOM。这时候要么降batch size要么上QLoRA把基座压到4GB。1.3 不同模型规模的显存速查下面这张表是我实测和根据经验整理的基于fp16加载基座、LoRA rank16、开gradient checkpointing、AdamW优化器模型规模基座显存推荐最小显存32GB卡可跑配置1.5B3GB8GBseq 2048, batch 167B14GB24GBseq 1024, batch 813B26GB40GB需QLoRA或降精度7B QLoRA4GB12GBseq 2048, batch 1613B QLoRA7GB16GBseq 1024, batch 8这张表里的“可跑配置”是指不OOM的前提下比较舒服的配置实际还要看具体模型结构和框架实现。2. 32GB GPU上的训练配置怎么定32GB这个档位很特殊它刚好卡在“能跑7B全精度LoRA”和“跑13B必须量化”的分界线上。我手上用的是一张32GB的卡踩过不少坑下面把配置思路捋一遍。2.1 精度选择fp16、bf16还是4bit精度选择直接决定基座模型占多少显存也影响训练稳定性。fp16是最常见的选择2字节每参数7B模型14GB。但fp16有个问题训练时梯度容易溢出需要loss scaling来兜底。大部分框架会自动处理但偶尔会遇到loss变成NaN的情况。bf16的数值范围比fp16大训练更稳定不容易溢出。同样是2字节每参数显存占用和fp16一样。如果你的卡支持bf16Ampere架构及以后都支持我强烈建议用bf16。实测下来bf16的loss曲线比fp16平滑很多尤其是学习率稍微大一点的时候。**4bit量化QLoRA**把基座压到约4GB代价是训练速度慢一些而且量化本身会损失一点精度。但如果你要跑13B甚至更大的模型QLoRA几乎是唯一选择。32GB卡上跑13B QLoRAseq_len1024、batch_size4显存占用大概在18到20GB还有余量。我的建议是7B模型优先用bf1613B模型用4bit QLoRA。除非你的卡不支持bf16否则没必要用fp16。2.2 batch size和梯度累积的配合batch size直接吃激活值显存是最容易调节的旋钮。但batch size太小会影响训练稳定性这时候就要用梯度累积来凑等效batch size。举个例子你想要等效batch size32但显存只够跑batch size4。那就设batch_size4gradient_accumulation_steps8等效就是32。梯度累积不额外占显存只是多花点时间。这里有个细节梯度累积的时候BatchNorm或者某些归一化层的统计量是按micro-batch算的不是按等效batch算的。不过LoRA微调通常不涉及这个问题因为基座模型是冻结的归一化层不更新。我一般会先把batch size拉到不OOM的最大值然后看等效batch size够不够。如果不够就加梯度累积。32GB卡跑7B bf16 LoRAseq_len1024的情况下batch size8通常没问题等效batch size32的话梯度累积设4就行。2.3 序列长度对显存的影响序列长度是显存杀手因为它同时影响激活值和注意力矩阵。注意力矩阵的大小是seq_len的平方虽然现在大部分框架用Flash Attention把这块优化掉了但激活值还是随seq_len线性增长。我实测过一组数据7B bf16 LoRAbatch_size4gradient checkpointing开启。seq_len512时显存占用约16GBseq_len1024时约19GBseq_len2048时约26GBseq_len4096时直接OOM。所以如果你的数据里长文本比较多要么截断到1024要么用QLoRA把基座省出来的显存留给激活值。截断虽然损失信息但比OOM强。我一般会先统计一下数据里token长度的分布取95分位数作为max_seq_len这样既能覆盖大部分样本又不会浪费显存。2.4 LoRA rank和target modules的选择rank越大LoRA参数量越大显存占用也越大但模型容量也越大。rank8到16适合大部分场景rank32到64适合数据量大、任务复杂的情况。target modules决定LoRA挂在哪些层上。只挂q_proj和v_proj是最省显存的但效果可能不如全挂。我一般会挂q_proj、k_proj、v_proj、o_proj这四个注意力层的投影再加上gate_proj、up_proj、down_proj这三个FFN层的投影。全挂的话LoRA参数量大概翻倍但显存增加有限因为LoRA本身参数量就小效果通常更好。有个经验如果你的任务和原模型领域差异大全挂rank32效果明显好于只挂qvrank8。如果只是微调风格或者格式只挂qvrank8就够了。3. 实操从零跑通一个32GB卡上的LoRA微调这一节我以7B模型为例把完整流程走一遍。框架用HuggingFace的pefttransformers这是最通用的方案。3.1 环境准备与依赖安装先装依赖。我习惯用conda建一个干净环境避免版本冲突。conda create -n lora_train python3.10 conda activate lora_train pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install transformers datasets peft accelerate bitsandbytes pip install scipy sentencepiece protobuf这里有几个版本要注意bitsandbytes在Linux上装起来比较顺Windows上可能需要额外配置。accelerate用来管理设备分配peft提供LoRA实现datasets处理数据。装完之后跑一下python -c import torch; print(torch.cuda.is_available())确认CUDA可用。如果返回False检查一下驱动和CUDA版本是否匹配。3.2 模型加载与LoRA配置加载模型的时候有几个关键参数。以bf16为例from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name your-base-model tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue )device_mapauto会让accelerate自动分配显存单卡的话就是全放一张卡上。torch_dtypetorch.bfloat16指定用bf16加载。如果要上QLoRA加载方式改成这样from transformers import BitsAndBytesConfig bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.bfloat16, bnb_4bit_use_double_quantTrue ) model AutoModelForCausalLM.from_pretrained( model_name, quantization_configbnb_config, device_mapauto, trust_remote_codeTrue )nf4是4bit正态浮点量化use_double_quant会再省一点显存。compute_dtype设成bf16计算的时候会反量化到bf16再算。然后配置LoRAfrom peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training if use_qlora: model prepare_model_for_kbit_training(model) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) model.print_trainable_parameters()lora_alpha一般设成rank的两倍lora_dropout设0.05到0.1防止过拟合。print_trainable_parameters()会打印可训练参数量7B模型全挂rank16的话大概在2000万到4000万之间。3.3 训练参数配置与启动训练参数用TrainingArguments来配from transformers import TrainingArguments, Trainer training_args TrainingArguments( output_dir./lora_output, per_device_train_batch_size4, gradient_accumulation_steps8, num_train_epochs3, learning_rate2e-4, bf16True, logging_steps10, save_strategyepoch, gradient_checkpointingTrue, gradient_checkpointing_kwargs{use_reentrant: False}, optimadamw_torch, lr_scheduler_typecosine, warmup_ratio0.03, report_tonone )几个关键点gradient_checkpointingTrue省显存但慢一点use_reentrantFalse是新版PyTorch的推荐设置避免一些梯度计算的问题。optimadamw_torch是标准AdamW如果显存紧张可以换成adamw_8bit优化器状态从8字节每参数降到2字节。学习率2e-4是LoRA微调的常用值比全量微调大一个量级。cosine调度加3%的warmup是比较稳的组合。启动训练trainer Trainer( modelmodel, argstraining_args, train_datasettrain_dataset, data_collatordata_collator, ) trainer.train()训练过程中用nvidia-smi -l 1盯着显存。如果显存占用在训练开始后快速上升然后稳定说明正常。如果一直涨到OOM可能是数据里有超长样本或者gradient checkpointing没生效。3.4 显存监控与动态调整训练的时候我一般开两个终端一个跑训练一个跑watch -n 1 nvidia-smi。重点看两个数显存占用和GPU利用率。显存占用稳定在某个值附近就没事。如果GPU利用率很低比如低于30%说明数据加载是瓶颈可以增加dataloader_num_workers。如果显存占用离上限很近比如30GB/32GB但还没OOM可以适当降batch size留点余量避免训练中途因为碎片问题崩掉。有个技巧在训练脚本里加一段显存打印import torch def print_gpu_memory(): allocated torch.cuda.memory_allocated() / 1024**3 reserved torch.cuda.memory_reserved() / 1024**3 print(fAllocated: {allocated:.2f}GB, Reserved: {reserved:.2f}GB)在训练前后各调一次能清楚看到模型加载和训练各占多少。4. 常见问题与排查技巧实录这一节是我踩坑最多的地方把典型问题和解决方法整理出来。4.1 OOM了但显存看起来还有余量这种情况通常是显存碎片导致的。PyTorch的缓存分配器会预留比实际需要更多的显存如果碎片多即使总空闲显存够也找不到连续的大块。解决方法设PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True让分配器用可扩展段来管理显存减少碎片。另外可以在训练前调torch.cuda.empty_cache()清一下缓存。还有一个可能是device_mapauto把模型分散到了多张卡上但训练时数据只在主卡上导致主卡OOM。单卡的话设device_map{: 0}强制放一张卡。4.2 loss变成NaN或者不下降bf16下loss变NaN的概率比fp16低但也不是没有。常见原因有三个学习率太大、数据里有异常样本、梯度累积时没有正确缩放。先降学习率试试从2e-4降到1e-4或者5e-5。如果还不行检查数据里有没有空样本或者超长样本。梯度累积的话HuggingFace的Trainer会自动处理loss缩放但如果你自己写训练循环记得除以gradient_accumulation_steps。4.3 训练速度慢得离谱32GB卡跑7B LoRAseq_len1024、batch_size4正常速度应该在每秒2到5个iteration。如果慢很多检查这几点gradient checkpointing开了会慢20%到30%这是正常的dataloader_num_workers设成4或8别用默认的0确认用的是bf16而不是fp32fp32会慢一倍以上检查数据预处理是不是在训练时做的应该提前tokenize好4.4 QLoRA训练时loss波动大QLoRA的4bit量化会引入噪声loss波动比bf16大是正常的。但如果波动特别剧烈可以试试把bnb_4bit_quant_type从nf4换成fp4或者把bnb_4bit_compute_dtype从bf16换成fp32。fp32计算更稳但更慢显存也多一点。另外QLoRA的LoRA rank可以适当调大因为基座被量化了需要更大的适配器容量来补偿。4.5 保存的LoRA权重加载后效果不对LoRA权重保存的是适配器部分加载的时候要先加载基座模型再加载适配器。如果基座模型版本不对或者加载时没指定torch_dtype效果会差很多。加载的正确姿势from peft import PeftModel base_model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.bfloat16, device_mapauto ) model PeftModel.from_pretrained(base_model, ./lora_output) model model.merge_and_unload() # 合并LoRA到基座merge_and_unload()会把LoRA权重合并进基座推理时不再有额外开销。如果还要继续训练就不要merge。4.6 常见问题速查表问题现象可能原因解决方法OOM但显存有余量显存碎片设expandable_segments:Trueloss变NaN学习率太大降到1e-4或5e-5训练速度慢dataloader瓶颈增加num_workersQLoRA loss波动大量化噪声换fp4或compute_dtypefp32加载后效果差基座版本不匹配确认基座和训练时一致显存一直涨数据有超长样本截断到max_seq_lenGPU利用率低batch size太小增大batch或梯度累积5. 几个容易被忽略的细节最后聊几个细节都是实际跑的时候才会遇到的问题。tokenizer的padding side。训练时一般用right padding推理时用left padding。如果搞反了生成结果会乱。HuggingFace的tokenizer默认是right训练没问题但推理前记得改。数据格式。LoRA微调的数据通常是instruction-input-output三段式或者纯文本。格式不对的话loss会降不下去。我一般会先用几条数据手动跑一遍forward确认loss在合理范围比如2到5之间再开始正式训练。随机种子。LoRA微调对随机种子比较敏感尤其是数据量小的时候。建议固定seed跑两三次看结果稳不稳定。如果波动大说明数据量不够或者学习率太大。显存监控工具。除了nvidia-smi还可以用torch.cuda.memory_summary()看详细分配情况。这个在排查碎片问题时特别有用。保存策略。训练过程中定期保存checkpoint别只保存最后一个。LoRA权重文件很小几十MB多存几个不占地方。万一最后一个过拟合了还能回退到中间的。学习率调度。cosine调度适合大部分场景但如果训练步数很少比如几百步linear可能更稳。warmup比例3%到5%就行太高会浪费训练步数。评估集。一定要留一个评估集别全拿去训练。LoRA微调很容易过拟合尤其是数据量小于1000条的时候。评估集不用大几百条就够用来判断什么时候该停。合并后的模型推理。merge_and_unload之后模型就是一个普通的因果语言模型可以用transformers的generate直接推理。但注意合并后的模型显存占用和基座一样如果之前用QLoRA训练的合并后需要fp16或bf16的显存。多卡训练。32GB单卡跑7B LoRA够用但如果要跑13B或者更大可能需要多卡。多卡用accelerate或者deepspeed配置会复杂一些。单卡能跑就别上多卡多卡的通信开销和调试成本都不低。数据质量比数量重要。LoRA微调几百条高质量数据就能出效果几万条低质量数据反而可能把模型带偏。我一般会先人工检查100条数据确认格式和内容没问题再批量处理。学习率预热。warmup不是必须的但加上更稳。尤其是用bf16的时候前几十步loss可能会跳一下warmup能缓解这个问题。梯度裁剪。设max_grad_norm1.0防止梯度爆炸。大部分框架默认就是1.0但确认一下没坏处。混合精度训练。bf16比fp16稳但有些老卡不支持bf16。如果只能用fp16记得开loss scalingHuggingFace的Trainer会自动处理。显存不足时的降级顺序。先降batch size再降seq_len再开gradient checkpointing最后上QLoRA。这个顺序是按对训练效果的影响从小到大排的。LoRA权重的可移植性。LoRA权重和基座模型绑定换基座就要重新训练。但同一个基座上的不同LoRA可以合并也可以叠加。叠加的时候注意权重缩放一般用加权平均。训练日志。loss、学习率、显存占用都记下来方便回溯。我一般用TensorBoard或者wandb但report_tonone也行手动打印关键指标。数据去重。训练数据里有重复样本的话模型会过拟合到那些样本上。去重很简单用set或者pandas的drop_duplicates就行。序列打包。如果数据里短样本多可以用序列打包把多个短样本拼成一个长样本提高训练效率。但打包会改变注意力掩码需要框架支持。HuggingFace的DataCollatorForSeq2Seq支持打包但因果语言模型要小心处理。模型并行。32GB单卡跑7B不需要模型并行但跑13B可能需要。模型并行配置复杂能用QLoRA解决就别上模型并行。检查点恢复。训练中断后从checkpoint恢复要确保优化器状态也恢复了。HuggingFace的Trainer会自动处理但自己写循环的话要注意。显存泄漏排查。如果显存占用随训练步数一直涨可能是某个地方存了计算图没释放。检查有没有在训练循环里累加loss或者存中间变量。LoRA dropout。设0.05到0.1防止过拟合。数据量大的话可以设0数据量小的话设0.1。target_modules的命名。不同模型的层命名不一样LLaMA是q_proj/k_proj/v_projChatGLM是query_key_valueQwen是c_attn。挂之前先打印模型结构确认一下。学习率与rank的关系。rank越大LoRA参数量越大学习率可以适当小一点。rank8用2e-4rank32用1e-4大概这个比例。评估指标。因果语言模型用perplexity或者loss就行生成任务可以看BLEU或者ROUGE。但自动指标不一定准最好人工看几条生成结果。训练轮数。LoRA微调一般3到5轮就够了太多会过拟合。数据量大的话1到2轮也行。保存格式。LoRA权重保存成safetensors格式比bin格式安全且加载快。HuggingFace的save_pretrained默认就是safetensors。推理时的temperature。LoRA微调后的模型推理时temperature设0.7到0.9比较合适。太低会重复太高会乱。模型卡。训练完写个模型卡记录基座模型、LoRA配置、训练数据、超参数。以后自己或者别人复现的时候方便。版本兼容。peft、transformers、bitsandbytes的版本要匹配不然会出各种奇怪的错误。我一般用最新稳定版遇到问题再降级。显存测试。正式训练前先用小批量数据跑几步确认显存够用。别等跑了几个小时才OOM。数据预处理。tokenize可以提前做也可以训练时做。提前做省时间但占磁盘。训练时做省磁盘但慢。我一般提前tokenize好存成arrow格式。LoRA的bias。一般设none不训练bias。如果任务需要可以设all训练所有bias但显存会增加一点。梯度累积与学习率。梯度累积不改变学习率等效batch size变了但学习率不用调。但如果等效batch size变化很大学习率可以适当调整。混合精度与优化器。bf16训练时优化器状态还是fp32所以优化器显存不变。adamw_8bit可以把优化器状态压到8bit省显存但可能影响精度。模型加载的trust_remote_code。有些模型需要这个参数才能加载但要注意安全只加载可信来源的模型。显存预留。训练时留1到2GB余量避免因为碎片或者临时张量导致OOM。LoRA的初始化。LoRA的A矩阵用随机初始化B矩阵用零初始化这样训练开始时LoRA输出为零不影响基座。这是peft的默认行为不用改。训练数据的shuffle。一定要shuffle不然模型会学到数据的顺序。HuggingFace的Trainer默认会shuffle。学习率查找。如果不确定学习率可以用lr_find跑一下找loss下降最快的点。但LoRA微调一般用2e-4就行不用太纠结。模型保存的间隔。save_steps设成500或者1000别太频繁保存也要时间。save_total_limit设成3到5别把磁盘占满。日志间隔。logging_steps设成10到50太频繁会拖慢训练太稀疏看不到趋势。评估间隔。eval_steps和save_steps一致就行评估也要时间。数据加载的pin_memory。设成True可以加速数据传输但占一点显存。显存紧张的话设False。dataloader的persistent_workers。设成True可以避免每个epoch重新创建worker加速数据加载。训练前的显存清理。跑训练前先torch.cuda.empty_cache()把之前的缓存清掉。多进程数据加载。num_workers设成CPU核心数的一半到三分之二太多反而慢。LoRA的merge。推理前merge可以加速但merge后不能再训练。如果要继续训练别merge。模型量化后的推理。QLoRA训练后推理可以用4bit加载基座也可以merge后转fp16。4bit推理省显存但慢一点。训练数据的长度分布。先统计一下取95分位数作为max_seq_len避免截断太多或者浪费显存。LoRA的target_modules选择。全挂效果一般更好但显存和训练时间都会增加。只挂qv是最省的选择。学习率与batch size。batch size大学习率可以适当大一点。但LoRA微调一般不用太大2e-4到5e-4之间。训练轮数与数据量。数据量小轮数可以多一点。数据量大轮数少一点。一般3到5轮。模型评估。除了loss还要看生成质量。自动指标只是参考人工评估更准。显存监控的频率。训练时每秒看一次就行太频繁会拖慢训练。LoRA权重的版本管理。每次训练保存一个版本记录配置和数据方便对比。训练中断的处理。中断后从最近的checkpoint恢复别从头开始。模型部署。LoRA微调后的模型可以部署成API也可以用transformers直接推理。部署时注意显存和并发。数据隐私。训练数据里如果有敏感信息训练后模型可能会记住。注意数据脱敏。模型许可。基座模型和训练数据都有许可商用前确认一下。训练成本。32GB卡跑7B LoRA3轮大概几个小时到十几个小时看数据量。云GPU按小时计费算好成本。模型更新。基座模型更新后LoRA权重可能不兼容需要重新训练。社区资源。HuggingFace上有大量LoRA权重和训练脚本可以参考但别直接抄配置要根据自己的情况调。实验记录。每次实验记录配置、数据、结果方便回溯和对比。我一般用表格记。显存与速度的权衡。省显存的配置通常慢快的配置通常费显存。根据需求选。训练稳定性。bf16比fp16稳小学习率比大学习率稳warmup比不warmup稳。模型容量。LoRA rank决定模型容量rank太小可能欠拟合rank太大可能过拟合。数据质量。高质量数据比低质量数据效果好哪怕数量少。训练目标。LoRA微调的目标是让模型适应特定任务不是从头学知识。数据要针对任务设计。评估集的设计。评估集要和训练集同分布但样本不能重复。超参数搜索。LoRA微调的超参数不多主要调学习率、rank、batch size。可以网格搜索但别太复杂。训练时间。7B LoRA1000条数据3轮32GB卡大概1到2小时。数据量大的话线性增长。模型大小。LoRA权重文件很小几十MB到几百MB方便分享和部署。推理速度。merge后的模型推理速度和基座一样没merge的话会慢一点。显存占用。推理时显存占用和基座一样QLoRA推理可以省显存。模型兼容性。LoRA权重和基座模型版本绑定换版本要重新训练。训练数据格式。不同框架的数据格式不一样peft用datasets的格式自己写循环的话要适配。学习率调度器。cosine最常用linear也行constant适合短训练。优化器选择。adamw_torch最常用adamw_8bit省显存sgd适合特定场景。梯度裁剪。max_grad_norm1.0防止梯度爆炸。混合精度。bf16优先fp16次之fp32最稳但最慢最费显存。模型并行。单卡能跑就别多卡多卡配置复杂。数据并行。多卡数据并行用accelerate或deepspeed配置复杂但能加速。训练监控。loss、学习率、显存、GPU利用率都要盯着。模型保存。定期保存别只保存最后一个。训练日志。记录关键指标方便回溯。实验管理。用wandb或tensorboard或者手动记表格。模型评估。自动指标加人工评估确保效果。部署考虑。推理显存、速度、并发都要考虑。成本控制。云GPU按小时计费算好训练时间。数据安全。敏感数据脱敏模型许可确认。社区交流。遇到问题查文档、搜论坛、问社区别自己死磕。持续学习。LoRA微调技术还在发展关注新方法和新工具。实践出真知。看再多教程不如自己跑一遍踩坑才能学到东西。