简介这份面向MicroPython单片机环境的LoRa驱动源码专为资源受限的嵌入式设备设计主要解决远程传感器节点与网关之间的低功耗无线通信问题适合具备基础Python语法、正在搭建物联网应用的开发者参考学习。驱动以扩频通信为底层机制完整覆盖初始化参数配置、LoRaWAN网络入网设置、数据收发、事件回调以及休眠节能管理等功能模块读者能从中理解通过SPI接口控制射频模块、建立长距离低功耗链路的典型实现思路并可直接迁移到自己的项目中使用。资源压缩包内共1个文件为单个Python驱动脚本包体约1KB代码量少、函数职责清晰便于逐段阅读、按需修改和快速移植。目前已有481人学习下载说明其具备一定的参考价值配合简易实验板可应用于智能农业、环境监测、物流追踪等远程数据采集场景。通过研读源码开发者能看清初始化、入网、收发与节能处理之间的调用关系降低从零上手LoRa开发的调试成本。1. LoRA 是什么为什么 Python 微调大模型都绕不开它LoRALow-Rank Adaptation低秩适配是目前用 Python 做大模型微调时统治力最强的一种参数高效方案冻结预训练模型的全部权重只在旁边挂一对小矩阵去学任务增量真正被更新的参数往往不到总量的 1%。对只握有一两块消费级显卡的人来说这意味着原本要几十 GB 显存的全参微调能被压到个位数 GB 显存里跑完效果在多数指令微调场景下逼近甚至持平全参微调。像秋叶训练器这类一键工具已经很流行但到了大模型指令微调这一步它们渐渐不够用——低秩假设在什么情况下成立、rank 取多大、和量化叠加会不会互相干扰这些边界问题用 WebUI 感知不到。只有把 LoRA 放进自己的 Python 脚本里亲手调一次 alpha、盯一条 loss 曲线才真正明白这套方案能走到哪、在哪会翻车。这篇笔记按做项目的路径写先拆 LoRA 在动模型的哪一部分再给一套能直接照跑的微调脚本覆盖数据、配置、训练、合并与推理最后把高频踩坑按「现象 → 原因 → 解决」列出来。适合想用 LoRA 微调自己数据、又不想停留在点按钮层面的从业者。2. LoRA 原理与最小实现手写 PyTorch 适配层看低秩矩阵在动哪根权重2.1 低秩分解在动模型的哪一部分两个小矩阵替换一次矩阵更新先看全参微调在做什么。一个线性层的前向是 h Wx训练时反向算出梯度后更新整个 W。以 7B 规模的 decoder 模型为例hidden size 通常是 4096一个 q_proj 权重矩阵就是 4096×4096光这一层就 1600 万参数模型里这样的线性层有几十上百个。全参微调意味着所有这些权重都要计算梯度、更新并保存在优化器状态里这是显存和算力的大头。LoRA 的做法非常直接既然微调产生的增量 ΔW 不需要那么高的自由度那就把它拆成两个小矩阵的乘积。设原始权重 W0 ∈ R^(d×k)学习增量 ΔW B·A其中 A ∈ R^(r×k)、B ∈ R^(d×r)r 远小于 d 和 k。前向公式变成h W0·x (α / r)·B·A·x训练时 W0 被冻结只有 A 和 B 参与梯度更新。A、B 加起来的参数量是 r·(dk)以 7B 模型、r16、dk4096 来算只有约 13 万参数单个模块比原来少了两个数量级。这里的 α/r 是缩放系数社区习惯叫 scaling后面调参主要动它。为什么敢做这种压缩因为预训练模型已经是一个很强的特征提取器微调只是在现有能力上做小幅偏移偏移方向集中在一个低维子空间里。论文里的对照实验把微调增量投影到少数几个方向发现一两个维度就能承担大部分任务适配既然任务增量本质低秩用低秩参数去学它就是顺理成章的。这个假设不总是成立——数据分布和基座能力差距越大需要的秩越高——这正是后文 rank 调参的根源。还要区分一个常见误解LoRA 不是 adapter 也不是 prefix tuning。adapter 是在 Transformer 层之间插入新的前馈模块改变的是网络结构prefix tuning 是在注意力输入前拼可学习的向量改的是输入序列。LoRA 不动结构也不动输入它只给已有的线性层加一条并行的低秩旁路推理时甚至可以把增量合并回原权重让模型变回「没有 LoRA 的样子」。这个特性决定了它落地最干净也是后面 merge_and_unload 操作的基础。2.2 手写 LoRALinearPyTorch 最小可运行版本与初始化细节不依赖任何库先自己实现一遍会对挂载位置和初始化为什么这么设计有非常直观的体感。下面是最小可运行的 PyTorch 实现。import torch import torch.nn as nn import torch.nn.functional as F class LoRALinear(nn.Module): 给普通 Linear 层包一层 LoRA 增量路径的最小实现 def __init__(self, in_features: int, out_features: int, rank: int 8, alpha: int 16, dropout: float 0.1): super().__init__() # 原权重随机初始化随后冻结requires_gradFalse 后不再参与更新 self.weight nn.Parameter(torch.randn(out_features, in_features) * 0.02) self.weight.requires_grad False self.bias nn.Parameter(torch.zeros(out_features)) self.bias.requires_grad False # LoRA 分支A 把输入压到 rank 维B 再映射回输出维 self.rank rank self.scaling alpha / rank self.A nn.Parameter(torch.randn(rank, in_features) * 0.01) self.B nn.Parameter(torch.zeros(out_features, rank)) # B 全零是关键 self.dropout nn.Dropout(dropout) def forward(self, x): base_out F.linear(x, self.weight, self.bias) # 冻结的原路径 lora_out (self.dropout(x) self.A.t()) self.B.t() # 低秩增量路径 return base_out lora_out * self.scaling # 两路相加逻辑说明前向把输入 x 同时过两路——原权重路径和 LoRA 增量路径。增量路径先被 A 压缩到 rank 维再被 B 映射回 out_features。训练时只有 A、B 有梯度原权重连梯度都不算省下的反向开销就是 LoRA 显存优势的一部分。初始化细节有三个坑。第一B 必须全零这样第 0 步的增量路径输出为零插入 LoRA 后模型行为和基座完全一致不会因为凭空多了条路径而改变推理输出。第二A 用小标准差高斯0.01 量级保证更新过程增量方向稳定不会一开始就冲乱基座。第三scaling 放在相加后整体乘等价于控制整条增量路径的学习步长alpha 固定时 rank 越大、scaling 越小每一步对权重的影响越被稀释这个约束关系在 2.3 展开。写完后可以快速验证路径是否真的生效layer LoRALinear(768, 768, rank8, alpha16) x torch.randn(4, 768) with torch.no_grad(): out_base layer(x) # 未扰动前的输出 layer.A.data.mul_(10.0) # 人为放大 A制造可观测的增量 with torch.no_grad(): out_shift layer(x) diff (out_base - out_shift).abs().max().item() print(f增量路径最大偏移: {diff:.4f}) # 远大于 0说明 LoRA 路径活着如果 diff 输出接近 0检查是不是把 B 也扰动到了——B 全零时无论 A 多大增量路径输出恒为 0这是符合预期的。这个最小实现不能直接接到大模型上生产环境用 peft 库来做但它把「增量 B·A·x」这件事讲透了。2.3 rank 与 alpha两个必调参数的约束关系和经验取值LoRA 只有四五个超参但真正要花心思的只有两个rank 和 alpha。rank 决定增量子空间的维度alpha 决定增量路径的缩放比例两者共同决定有效步长不能孤立地调。参数控制什么常见取值小数据集1k 条大数据集1w 条rank增量表达力上限8 / 16 / 32 / 648~1632~64alpha增量路径缩放与 rank 共同决定步长16 / 32 / 64alpha ≈ 2×rankalpha ≈ 2×rankdropoutLoRA 分支丢弃率防小数据过拟合0.05 / 0.10.10.05社区经验里有一条很实用的规则保持 alpha 2×rank。这样 scaling 恒等于 2有效步长不随 rank 变化切 rank 时不用同步重调学习率。如果你非要偏离这个比例记住一个换算关系把 rank 翻倍但 alpha 不变每一步对权重的实际影响减半等价于学习率减半——很多「升 rank 后 loss 反而不降」的求助帖答案就藏在这里。rank 不是越大越好。数据只有几百条时r64 的增量路径完全有能力把训练集的噪声背下来验证集表现断崖下跌反过来数据量到几万条r8 可能学不完任务子空间loss 停在平台期。先按数据量级选 rank再通过上面的换算关系微调 alpha是成本最低的调参路径。提示rank 和 alpha 的「合理」区间还会随基座规模变化。1B 量级模型 r8 效果明显13B 量级模型往往 r32 才能看到差距。不要拿小模型的参数直接套大模型。3. 用 peft 在 Python 里跑通 LoRA 微调数据预处理、LoraConfig 与训练参数3.1 指令数据格式与预处理脚本LoRA 微调大模型十有八九是指令跟随场景给模型一批「用户问什么、助手答什么」的样本让它学会回答风格和领域知识。最通用的存储格式是 JSONL每行一个样本读取方便、也方便后续清洗和抽样检查。{instruction: 用一句话解释什么是低秩适配, input: , output: 低秩适配是一种参数高效的微调方法用低维矩阵近似权重更新量。} {instruction: 把下面的句子翻译成英文, input: 今天天气很好, output: The weather is nice today.}预处理的核心是把每条样本拼成模型惯用的对话模板再 tokenize 成 input_ids。不同基座模型的模板不一样最稳的做法是调用基座自带的 chat 模板下面演示的是手工拼接的通用写法便于你看清模板里每个字符的作用。import json from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-1.5B) # 换成你的基座模型 def build_text(item: dict) - str: # 统一拼成“用户/助手”结构结尾必须带 eos让模型学会何时停止 if item.get(input): prompt f用户{item[instruction]}\n{item[input]}\n助手 else: prompt f用户{item[instruction]}\n助手 return prompt item[output] tokenizer.eos_token def load_and_tokenize(jsonl_path: str, max_length: int 512): samples [] with open(jsonl_path, encodingutf-8) as f: for line in f: item json.loads(line.strip()) text build_text(item) enc tokenizer(text, truncationTrue, max_lengthmax_length) samples.append({ input_ids: enc[input_ids], attention_mask: enc[attention_mask], labels: enc[input_ids], # 因果 LM 的 label 就是输入序列自身 }) return samples dataset load_and_tokenize(./train.jsonl)逻辑说明labels直接复制input_ids是因为因果语言模型的训练目标是「根据前文预测下一个 token」Trainer 内部会自动把输入右移一位再计算损失不需要手工做 shift。一个容易被忽略的点是结尾加 eos_token——不加的话模型学不会在回答结束时停下来推理时就会一直生成到 max_new_tokens 上限。参数说明max_length512 是把每条样本截断到 512 token。序列越长训练越慢、显存越高。中文指令数据里 512 token 通常能覆盖八成以上样本如果你发现大量样本超出这个长度优先做数据裁剪而不是盲目加长把两条长样本硬截断远比堆显存划算。3.2 用 peft 给模型挂 LoRALoraConfig 的 target_modules 怎么设生产环境不手写 LoRA 层用 Hugging Face 的 peft 库。它负责把 LoRA 层挂到模型指定模块上并管理 adapter 的保存、加载和合并。这也是目前 Python 生态里最主流、维护最活跃的做法。from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM model AutoModelForCausalLM.from_pretrained( your-base-model, torch_dtypeauto, # 按 checkpoint 原 dtype 加载 device_mapauto, # 多卡或 CPU offload 交给 accelerate 处理 ) config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, # LoRA 默认不动 bias除非你有明确理由 task_typeCAUSAL_LM, # 模型类型声明peft 需要它做适配 ) model get_peft_model(model, config) model.print_trainable_parameters()逻辑说明get_peft_model会把模型里所有和target_modules名字匹配的线性层替换成「原层 LoRA 分支」的复合结构原权重冻结只有新增的 A/B 矩阵可训练。print_trainable_parameters()打印可训练参数量与占比。以 1.5B 模型、r16、挂注意力四件套为例通常只训 400 万~600 万参数占比在 0.2%~0.4% 量级如果看到占比超过 1%先怀疑 target_modules 是不是写宽了。target_modules 的选择是 LoRA 配置里最影响效果的一项没有绝对标准按经验分三档只挂q_proj、v_proj最保守显存最低适合快速验证流程。挂q/k/v/o四件套社区默认配置覆盖注意力全部投影性价比最高。把 MLP 里的gate_proj、up_proj、down_proj也挂上接近「全量 LoRA」效果通常最好但可训练参数多一倍训练时间明显变长。不确定模型里模块叫什么名字先print(model)或扫一遍model.named_modules()别凭记忆填——不同家族、甚至不同版本的模型命名习惯都不一致填错名字 peft 会静默跳过匹配不到的模块你以为挂了 LoRA实际上什么都没训。3.3 训练循环Trainer 最小脚本与八个关键参数用 transformers 的 Trainer 封装训练循环代码最省、出错也少。下面是一份我在单卡上常用的配置配合 3.1 的数据可以直接跑。from transformers import Trainer, TrainingArguments training_args TrainingArguments( output_dir./lora_ckpt, per_device_train_batch_size4, gradient_accumulation_steps8, learning_rate2e-4, num_train_epochs3, logging_steps20, save_strategysteps, save_steps500, fp16True, # 30 系以上 N 卡可用A100/H100 换 bf16 更稳 gradient_checkpointingTrue, remove_unused_columnsFalse, ) trainer Trainer( modelmodel, argstraining_args, train_datasetdataset, ) trainer.train()逐个说参数per_device_train_batch_size4是单卡每步进 4 条样本配合gradient_accumulation_steps8等效 batch size 等于 4×832比直接开 batch 32 省显存得多。learning_rate2e-4是 LoRA 的常见起点比全参微调高一到两个数量级——因为只更新小矩阵可以用更大的步长但别超过 5e-4否则 loss 容易震荡。gradient_checkpointingTrue用重计算换显存激活显存能降一半以上代价是训练慢 20%~30%显存紧张时必须开。三个容易翻车的设置fp16True在老显卡上数值可能不稳定如果 loss 出现 NaN先关掉它或换成bf16Trueremove_unused_columnsFalse必须保留否则 Trainer 会把你自定义的input_ids、labels之外的所有列清掉导致数据加载报错save_steps500按步存 checkpoint中断后可以续跑也让你始终有后悔药可吃。训练任务重、时间长的项目建议再补两个设置lr_scheduler_typecosine配合warmup_ratio0.03前 3% 的 step 线性升温、之后余弦衰减比默认的线性调度在长训练里更稳eval_strategysteps加eval_steps500让验证 loss 和训练 loss 一起打点方便判断有没有过拟合。提示第一次跑先设max_steps200中断一次确认 loss 在合理区间下降、日志里没有 NaN、checkpoint 能正常写入再铺满三个 epoch。别一上来就全量跑等发现数据有问题时已经浪费几个小时。4. LoRA 训练后落地权重合并与推理验证两类部署方式怎么选4.1 合并还是保留 adaptermerge_and_unload 的使用时机训练产出的是 adapter——一套轻量 LoRA 权重文件adapter_model.safetensors 加 adapter_config.json。部署时两种路线保留 adapter、推理时动态挂到基座上或者把增量合并回基座权重、产出单一模型文件。两者各有适用场景。保留 adapter 的好处是灵活同一个基座可以挂多个不同任务的 adapter切换任务只是换一下加载路径不需要重新加载基座adapter 文件通常只有几十到几百 MB分发方便。坏处是每次推理多一次增量路径计算推理框架还需要额外支持 peft 加载。合并的好处是推理速度最快、部署依赖最少——权重已经是普通模型文件任何推理框架都能直接读坏处是合并后就回不去了想换任务得留一份原始 adapter 副本。from peft import PeftModel from transformers import AutoModelForCausalLM, AutoTokenizer from_pretrained_kwargs {torch_dtype: auto, device_map: auto} base AutoModelForCausalLM.from_pretrained(your-base-model, **from_pretrained_kwargs) # adapter 路径指向训练时保存的 checkpoint lora_model PeftModel.from_pretrained(base, ./lora_ckpt/checkpoint-500) # 合并把 ΔW 按 scaling 折算后写回原权重并卸载 LoRA 包装 merged_model lora_model.merge_and_unload() merged_model.save_pretrained(./merged_model) # 分词器一起存部署时才能和模型词表对齐 tokenizer AutoTokenizer.from_pretrained(your-base-model) tokenizer.save_pretrained(./merged_model)逻辑说明merge_and_unload()把每个 LoRA 层的增量按 scaling 折算进原权重矩阵W W0 (α/r)·B·A然后拆掉 LoRA 包装结构之后merged_model就是一个干净的普通模型。注意这个操作就地完成、不可撤销所以强烈建议合并前把 adapter 原样备份——它就是你的后悔药。如果还要继续训练留着lora_model别合或者合完从原始 adapter 重新加载。注意合并后权重精度会发生累加。基座是 fp16、LoRA 权重是 fp32 时peft 会做精度转换合并后模型占用的显存略高于纯基座。部署在意显存的话合并后做一次量化或者干脆走保留 adapter 的动态加载路线。4.2 推理验证先跑通功能再量化回归合并或加载完成第一步是跑通一次生成确认输出格式正确。验证阶段有个原则不要用采样用贪心解码。prompt 用户用一句话解释什么是低秩适配。\n助手 inputs tokenizer(prompt, return_tensorspt) outputs merged_model.generate( **inputs, max_new_tokens128, do_sampleFalse, # 验证阶段用贪心解码排除采样随机性 repetition_penalty1.1, ) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))为什么验证阶段要关掉采样do_sampleFalse走贪心解码同样的输入永远得到同样的输出方便你对照基座和微调后的差异换成采样模式后同一个 prompt 两次生成结果不同你很难判断变化来自模型还是随机性。repetition_penalty1.1在验证时也建议保留它会温和地惩罚重复 token避免微调后模型偶尔陷入循环、干扰你对内容质量的判断。跑通之后做两层验证。第一层功能验证挑 20~30 条训练集外的样本看模型是否学会了目标格式——「用户/助手」结构是否完整、结尾是否知道停。第二层回归验证LoRA 只更新了百分之零点几的参数但灾难性遗忘依然存在。把基座原本擅长的事通用问答、格式转换等抽 50~100 条 golden set微调前后各跑一遍对比哪些输出明显退化。这一步很多人跳过直到上线被用户反馈「模型变笨了」才回头查到那时数据、超参、checkpoint 全变了排障成本高得多。验证维度方法工具/参数单样本功能贪心解码看输出格式与内容generate decode批量回归同一批 prompt 微调前后对照手工 golden set稳定性同一 prompt 多次采样看方差do_sampleTrue, temperature0.85. LoRA 微调避坑五个高频问题的现象、原因与参数修正训练 LoRA 的坑和全参微调不完全一样——它省显存但不省调试时间。以下五条都是实际开发中反复出现的典型问题按「现象 → 原因 → 解决」写方便直接对照排查。5.1 loss 不下降或震荡先查学习率再查 rank最后查数据现象跑了 500 步loss 从 1.9 只降到 1.85 就卡在平台期或者曲线像锯齿每一步跳 0.1 以上完全看不出收敛趋势。原因最常见是学习率过大。LoRA 只更新 A、B 两个小矩阵2e-4 已经比全参微调常用的 1e-5 高了一个数量级推到 5e-4~1e-3 就很容易震荡。其次是 rank 太小任务增量复杂度超过 8 维子空间的承载能力loss 停在平台期。还有一个隐蔽原因在数据侧labels里如果包含大段 prompt 文本模型把大量损失花在预测用户提问上回答部分反而没学好——在指令数据里表现为「学到了格式没学到内容」。解决先把 learning_rate 压到 1e-4 重新跑 200 步看斜率没有改善再把 rank 升到 16 或 32同时按 alpha2×rank 的比例同步调高 alpha。数据侧打印一条样本的 input_ids 解码文本确认「助手」之后的回答部分占比足够回答太短的样本做截断或过滤。5.2 显存 OOMLoRA 省的是参数量不是激活值现象per_device_train_batch_size8 直接 CUDA OOM或者训练到一半、跑了几百步才突然爆显存。原因LoRA 减小的是可训练参数量和优化器状态但前向的中间激活值照样要存——激活显存和 batch size、序列长度成正比和用不用 LoRA 没关系。同一个模型全参能跑 batch 8LoRA 未必也能跑 batch 8。另一个常见原因是显存碎片保存 checkpoint、日志统计时都会临时申请显存在保存节点附近出现峰值上涨。解决优先开 gradient_checkpointing激活显存通常砍一半以上代价是训练慢 20%~30%第二步把 per_device_train_batch_size 降到 2用 gradient_accumulation_steps 补回等效 batchfp16/bf16 打开。单卡实在放不下时让 device_mapauto 把部分层 offload 到 CPU速度慢但能跑通。训练开始前用torch.cuda.max_memory_allocated()打一次峰值心里有数。5.3 加载 adapter 报 key mismatch顺序错了或者基座对不上现象PeftModel.from_pretrained 报 size mismatch for lora_A.weight 或大量 missing keys。原因最常见是加载顺序错误——训练时 model 是 PeftModel基座套了 LoRA 包装推理时用 AutoModelForCausalLM 直接读裸模型adapter 里的 lora_A/lora_B key 全部找不到对应位置。另一个高发原因是基座不一致adapter 在 A 模型上训练拿去挂 B 模型即使同系列不同规模1.5B 换 7B也可能因模块名不同而失败。还有一个是文件不齐只传了 adapter_model.safetensors、丢了 adapter_config.jsonpeft 不知道 rank、alpha 和 target_modules 是什么。解决严格按「裸基座 → PeftModel.from_pretrained」的顺序加载。adapter 是绑定基座架构的换基座前先确认模块名一致拿到别人的 adapter 时先检查目录里有没有 adapter_config.json没有就找对方要别硬试。5.4 微调后输出崩坏重复循环、空转、丢格式现象生成同一句话循环三遍或者完全丢掉「用户/助手」格式输出一段没头没尾的文本甚至回答到一半截断。原因三种常见原因。一是训练轮数过多小数据集跑 3 个 epoch 以上LoRA 把训练集里的重复模式背了下来二是 lora_dropout 设成 0增量路径完全没有随机性模型对自身输出过度自信容易进入重复循环三是数据清洗不彻底训练集里混进了没有回答的坏样本模型学到的是「看到提问就沉默」。解决训练时加 eval 和 early stopping验证 loss 连续几个评估点不降就停lora_dropout 保持 0.05~0.1别为了「纯净」把它清零训练前抽 20 条样本人工检查输出字段完整性。生成侧临时加 repetition_penalty1.1~1.2 能缓解重复但根因在数据惩罚只是治标。5.5 tokenizer 与基座模型对不上中文全变 [UNK]现象输入中文 prompt解码出来是乱码或 [UNK] 刷屏或者训练 loss 正常但生成的内容文不对题。原因最常见的操作失误是换了 base modeltokenizer 却还用着前一个项目复制来的路径或者用 AutoTokenizer 加载了和模型不匹配的词表。tokenizer 的 vocab 和模型的 embedding 不对齐网络根本接收不到想让它看的中文训练和推理都是「鸡同鸭讲」。这个问题在中文场景特别隐蔽因为模型不报错只是效果奇差。解决训练和推理两端的 tokenizer 必须来自同一个 base model 目录不要手动指定其他路径。如果基座是社区魔改版或量化版先确认它的 tokenizer 目录里有词表文件且和官方一致不一致就换回官方 checkpoint。6. LoRA 进阶rank 与数据量匹配、QLoRA 量化叠加与多分支取舍6.1 rank 与数据量的匹配关系一张经验表别再盲开 64rank 选多大最核心的决定因素是训练数据量其次是任务和基座的差距。下面这张表来自实际项目经验不是数学结论但比拍脑袋可靠。训练样本量建议 rank理由500 条以下8数据撑不起高维增量rank 大必过拟合500 ~ 5000 条8 ~ 16指令微调最常见的区间5000 ~ 5 万条16 ~ 32更多样本能学到更细的方向5 万条以上32 ~ 64接近全参微调的表达上限我的习惯是先按数据量定 rankalpha 固定等于 2×rank跑 300 步左右看 loss 斜率。loss 收敛但验证效果差说明 rank 太大在过拟合降一档loss 不降先降学习率再考虑升 rank——这两个动作的顺序别搞反否则永远分不清是哪个参数在拖后腿。6.2 QLoRA 量化叠加与多分支取舍adapter 是最好的后悔药模型太大、显存不够时社区标准做法是 QLoRA基座用 4bit 量化加载再挂 LoRA 训练单张 24GB 显存就能微调 7B~13B 量级的模型。from transformers import BitsAndBytesConfig quant_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_compute_dtypefloat16, # 计算时用 fp16量化只负责存权重 ) model AutoModelForCausalLM.from_pretrained( your-base-model, quantization_configquant_config, device_mapauto, ) # 之后照常 get_peft_model Trainer 训练量化基座训练完我一般建议保留 adapter 做动态加载而不是 merge_and_unload——合并会把量化权重反量化回高精度显存占用回到 fp16 水平省显存的意义就没了。这也引出更通用的原则adapter 不合并就是后悔药合并之后想换任务只能重新训。多 LoRA 分支和这个原则是一体的。同一个基座挂语言风格、领域知识、格式规范三个 adapter推理时按任务路由到对应分支成本只是多存几个几百 MB 的文件却能一个基座服务多个场景。我自己现在固定一个习惯任何 LoRA 项目开工先定三件事——数据量级、rank、验证集rank 宁可保守也不追大训练中断后从 checkpoint 续跑也绝不因为 loss 好看就中途改参数。模型微调这东西很多时候参数不是调出来的是排障排出来的。希望帮到你。本文还有配套的精品资源点击获取