做检测模型训练这行当久了你会发现一个问题模型越来越大微调越来越贵。前阵子团队拿到 YOLO26 的新权重准备往一个只有几千张标注图的新业务场景上迁移。按老办法全量微调光是显存就得排队更何况业务方要求一周内出效果。这时候如果还抱着全部参数一起训的思路就是拿大炮打蚊子。我最后走的路子是给 YOLO26 加上 LoRA 支持用参数高效微调PEFT的方式把训练成本砍了大半效果还基本追平全量微调。这篇文章就把整个适配过程、关键设计、超参经验以及踩过的坑完整梳理一遍给正准备折腾 PEFT 做检测模型的人一个可以直接抄作业的参考。1. 为什么要给 YOLO26 加 LoRA全量微调的痛点与 PEFT 的思路1.1 全量微调到底贵在哪里很多新手觉得微调和训练是一回事——加载预训练权重接着训就是了。但到了 YOLO26 这种量级的模型上全量微调的成本根本不是普通实验室能随便承担的。第一是显存。全量微调时除了模型权重还要保存每一层的前向激活值用于反向传播再加上 AdamW 优化器为每个参数存一份一阶动量 m 和二阶动量 v。这几个加在一起对一个几千万参数的网络来说显存开销往往要翻好几倍。直观说你一个推理只要 4GB 显存的检测模型全量微调时可能要 16GB 起步分辨率再大一点直接 OOM。第二是数据量。业务数据集通常只有几千张甚至几百张图。全量微调在这种小数据上非常容易过拟合训练 loss 降得漂亮验证集 mAP 一动不动。预训练权重学到的通用特征会被小数据集的噪音覆盖掉这就是典型的灾难性遗忘。我见过不止一个项目全量微调跑了两百个 epoch验证集分数比预训练权重直接推理还低原因就是数据量撑不起这么大的参数量更新。第三是部署成本。检测模型的业务常常是一个项目一个场景一种模型。每接一个任务就全量微调一遍保存下来的权重又是完整的几千万参数。五六个场景下来模型仓库直接膨胀得不像话。这时候用 LoRA 这类 PEFT 方法每个任务只多存几十 MB 的低秩增量简直是为这个场景量身定做的。1.2 LoRA 的核心思想把增量压缩成低秩矩阵LoRA 最早火起来是在大语言模型领域但它的数学原理和检测模型完全不冲突。假设原始权重矩阵是 W维度是 d×d。全量微调本质上是在学习一个增量矩阵 ΔW使得新权重变成 WΔW。问题是ΔW 的参数量跟 W 一样大训练成本自然下不去。LoRA 的做法是把这个增量矩阵拆成两个小矩阵的乘积ΔW BA。其中 A 的维度是 r×dB 的维度是 d×rr 远小于 d。这样要训练的参数量从 d×d 变成了 2×d×r直接小了几个数量级。前向计算时输出从 Wx 变成 Wx BAx原始权重 W 全程冻结不动。我自己理解 LoRA 时习惯用给老地图贴修正纸来类比。预训练权重就是一张印刷好的老地图大部分区域是准确的。全量微调是拿着新测绘数据重新印刷整张地图成本高还容易印坏LoRA 是在地图的局部贴上修正便签只改需要改的那几条路。B 和 A 这两个低秩矩阵就是那几张贴纸贴在哪些位置、贴多大这是我们要设计的核心问题。1.3 检测模型做 PEFT 和 NLP 的区别给 YOLO26 加 LoRA不能直接照搬大语言模型那套做法。NLP 模型里 Transformer 的线性层占了绝对主导地位LoRA 挂在 Q/K/V/O 投影上就能覆盖大部分参数更新。但检测模型不一样——主干、颈部、检测头里大量是卷积层尤其是 3×3 卷积。3×3 卷积的权重是四维张量你没法像线性层那样简单拆成两个低秩矩阵的乘积直接套上去。所以第一步工作是分析 YOLO26 的模块构成找出哪些层适合 LoRA 化。我当时的分析方法很简单把模型实例化之后遍历所有子模块按类型统计参数量占比再逐个判断这个层的前向计算是不是等价于矩阵乘法。只有等价于矩阵乘法的层LoRA 才能以最低成本挂上去。这一套做完心里对哪些该挂、哪些不该挂就有数了。2. LoRA 适配 YOLO26 的模块设计2.1 哪些模块适合挂 LoRA哪些不适合先说我当时对 YOLO26 权重的统计结果。YOLO26 的主干延续了 CSP 风格结构类似 C3k2/C2PSA 这类组合颈部是 PAN-FPN 的改进版本检测头是解耦头加 DFL 的形式。按参数量分布主干大约占 50%颈部占 25%检测头占 25% 左右。我把模块分成三类整理成一张判断表模块位置类型是否建议 LoRA 化原因主干 CSP 块内的 1×1 卷积投影/瓶颈卷积强烈建议等价于矩阵乘法LoRA 成本最低改动效果明显主干/颈部中的 3×3 卷积普通卷积不建议权重是四维直接 LoRA 化参数会爆炸收益低PAN-FPN 的 1×1 卷积通道融合建议跨尺度特征融合的关键通路检测头分类分支线性层/1×1 卷积建议分类语义变化大LoRA 收益最高检测头回归分支与 DFL卷积可选回归任务本身变化小挂上可以但收益有限BN 层归一化必须冻结BN 的统计量和小数据集强相关训练时不能让它随意漂移这个表格看起来简单背后是有讲究的。LoRA 的核心理念是以最小参数量学习最大的有效变化。分类分支对应的语义空间在不同数据集之间差异最大所以 LoRA 收益最高回归分支预测的框坐标分布在不同数据集上变化相对平滑LoRA 收益不明显。我测试下来只挂 1×1 卷积和分类头平均精度已经能接近全量微调这印证了上面的直觉。2.2 1×1 卷积的 LoRA 化本质就是矩阵乘法1×1 卷积在数学上等价于对每个像素做一次全连接计算输入通道到输出通道的线性映射。这意味着完全可以直接套用标准 LoRA 的矩阵分解逻辑唯一不同的是输入张量多出 H×W 的空间维度。处理办法很简单把张量 reshape 成 (BHW, C_in)做线性运算后再 reshape 回去。用生活类比来理解1×1 卷积就像给一张照片的每个像素点做颜色空间变换比如把 RGB 转成 HSV。每个像素点的变换规则是同一套系数LoRA 做的事情就是在这套系数上叠加一组低秩修正量。如果你把输入特征图的每个位置想象成独立样本1×1 卷积就是一个共享的全连接层而全连接层的低秩分解数学已经非常成熟这也是为什么 LoRA 在 1×1 卷积上可以直接套用、不需要额外设计结构的原因。2.3 3×3 卷积怎么处理可选方案3×3 卷积为什么要单独讨论因为它的权重形状是四维张量在空间上共享同一个核滑动。如果硬套低秩分解把整个权重拆成两个低秩四维张量参数量并没有减少多少反而破坏了卷积核的空间结构。我实验过程中试过两种处理方式。第一种是跳过所有 3×3 卷积只做 1×1 卷积和线性层的 LoRA。第二种是尝试空间可分离思路——把 3×3 卷积拆成 1×3 加 3×1 的级联或者用两个 1×1 卷积先降维后升维中间夹一个深度卷积。第二种方案理论上能减少参数但工程复杂度高而且深度卷积部分如果冻结表达能力受限如果一起训练参数量又上去了。对比实验显示第二种方案在 YOLO26 上的 mAP 提升只有 0.2 到 0.3 个点不如把精力放在调整 rank 和学习率上。所以最后我的结论是在检测模型的 PEFT 实践中优先做 1×1 卷积和线性层的 LoRA 就足够了不必强求 3×3。2.4 检测头处理DFL 与解耦头YOLO26 的检测头是解耦结构一个分支做分类一个分支做回归回归分支用 DFL 预测框边界的离散分布。分类分支在实现上通常是线性层或者 1×1 卷积直接挂 LoRA 很自然。DFL 分支比较特殊。它输出的不是直接的 x1/y1/x2/y2 坐标而是每条边落在预设离散区间上的概率分布最后通过积分才得到坐标。这个分支在代码里通常也是一组 1×1 卷积。从效果看DFL 分支的 LoRA 收益不如分类分支明显但挂上也不吃亏因为 1×1 卷积的参数量本来不大。我自己的做法是分类分支必挂回归分支先挂上看显存余量如果显存紧张就只挂分类。还有一个细节YOLO26 的解耦头通常有多个检测层处理不同尺度的目标。每个检测层应该拥有独立的 LoRA 参数实现时不要图省事把同一个 LoRA 模块跨层复用否则不同尺度目标的适配信息会互相干扰。这个坑在代码审查时特别容易漏掉因为前向结果看起来正常但收敛速度明显变慢。3. 实操过程把 LoRA 插进 YOLO26 训练流程3.1 实现 LoRA 层完整代码整个实现的核心就两步定义 LoRA 层替代原始层然后遍历模型做替换并冻结非 LoRA 参数。先给出我最终使用的 LoRA 层实现这个类同时兼容 PyTorch 里的 Linear 和 1×1 Conv2dimport torch import torch.nn as nn import torch.nn.functional as F class LoRAConv2d(nn.Module): 将 1x1 卷积或线性层替换为带 LoRA 分支的版本 def __init__(self, original_module, r8, alpha16): super().__init__() if isinstance(original_module, nn.Conv2d): assert original_module.kernel_size (1, 1), 只支持 1x1 卷积 self.in_features original_module.in_channels self.out_features original_module.out_channels self.is_conv True self.stride original_module.stride self.padding original_module.padding elif isinstance(original_module, nn.Linear): self.in_features original_module.in_features self.out_features original_module.out_features self.is_conv False else: raise TypeError(f不支持的模块类型: {type(original_module)}) # 冻结原始权重和偏置 self.base_weight original_module.weight.detach().clone() self.base_bias None if hasattr(original_module, bias) and original_module.bias is not None: self.base_bias original_module.bias.detach().clone() self.r r self.alpha alpha self.scaling alpha / r # 低秩分支A 用小方差高斯初始化B 用零初始化 self.lora_A nn.Parameter(torch.randn(self.in_features, r) * 0.01) self.lora_B nn.Parameter(torch.zeros(r, self.out_features)) def forward(self, x): if self.is_conv: base_out F.conv2d(x, self.base_weight, self.base_bias, self.stride, self.padding) b, c, h, w x.shape # 1x1 conv 等价于矩阵乘法直接在空间维度上广播 x_flat x.permute(0, 2, 3, 1).reshape(-1, c) # (B*H*W, C_in) lora_out (x_flat self.lora_A) self.lora_B lora_out lora_out.reshape(b, h, w, self.out_features).permute(0, 3, 1, 2) else: base_out F.linear(x, self.base_weight, self.base_bias) lora_out (x self.lora_A) self.lora_B return base_out lora_out * self.scaling几个实现要点补充说明A 矩阵用高斯分布初始化再乘以 0.01B 矩阵用零初始化。这样初始阶段低秩分支输出为 0模型行为跟原始预训练权重完全一致微调过程是从原模型平滑开始的不会一上来就破坏特征。如果你把 A 也初始化为零梯度在前几步会特别小收敛会慢不少用小的非零初始化是最稳的折中。scaling alpha / r 这个缩放系数不是拍脑袋定的。保留这个缩放因子可以在 rank 改变时让模型表达力不出现剧烈跳变。如果你的任务里 r 调得比较大缩放系数会跟着变这时候通常不需要额外调 alpha。比如 r 从 8 涨到 16alpha 同步从 16 涨到 32两者的有效缩放不变。我这边没有把原始权重注册为 buffer而是直接 detach 之后作为普通张量保存在模块里。因为这类权重在整个训练里都不需要梯度也没必要参与状态字典的保存。如果你希望导出模型时把原始权重也带上改用 register_buffer 会更干净但 load_state_dict 时的行为会略有差异需要在替换代码里一并处理。3.2 模型替换逻辑遍历 modules 做手术LoRA 层定义好后下一步是关键如何把 YOLO26 模型里的目标层全部替换掉。我写了一个通用遍历函数先收集快照再统一替换def set_module_by_path(model, path, new_module): parts path.split(.) parent model for part in parts[:-1]: parent getattr(parent, part) setattr(parent, parts[-1], new_module) def apply_lora(model, r8, alpha16): target_modules [] for name, child in model.named_modules(): if isinstance(child, nn.Conv2d) and child.kernel_size (1, 1): target_modules.append((name, child)) elif isinstance(child, nn.Linear) and name.endswith(cls): # 按实际工程的命名匹配分类头不同版本叫法不一样 target_modules.append((name, child)) for name, child in target_modules: lora_layer LoRAConv2d(child, rr, alphaalpha) set_module_by_path(model, name, lora_layer) for name, param in model.named_parameters(): if lora_ not in name: param.requires_grad False return [name for name, _ in target_modules]这里有个大坑必须提醒很多人图省事在遍历named_modules()时直接对根模型执行setattr(model, name, new_module)当 name 是model.backbone.c3k2.0.conv1这种带点号的路径时这个操作是在根模型上新建了一个同名属性根本没有替换到真正的目标层。正确做法是像上面那样按路径逐级下沉到父模块再对父模块执行 setattr。另一个隐患是循环过程中修改了模块树named_modules()迭代器可能会受影响所以先收集所有待替换的 (name, module) 快照再统一替换顺序不要反过来。关于匹配规则我的代码里把所有 1×1 Conv2d都替换了这对 YOLO26 这种主干和颈部大量使用 1×1 卷积的结构是合理基线。但如果你的显存非常紧张可以在遍历时加白名单过滤只保留主干前几个 stage 或只保留检测头相关的 1×1 卷积。这属于工程取舍不影响整体架构。3.3 训练 pipeline 改造LoRA 模型替换完成后训练流程大部分不用动。损失函数还是 YOLO26 官方那套分类损失加 DFL 损失加定位损失前向传播、反向传播、梯度裁剪都不用改。唯一要改的是优化器只放进 requires_gradTrue 的参数from torch.optim import AdamW trainable_params [p for p in model.parameters() if p.requires_grad] optimizer AdamW(trainable_params, lr1e-3, weight_decay0.05)这里的关键是不要在优化器里混入冻结参数。很多人图省事直接model.parameters()全塞进优化器训练起来看起来没问题但优化器为冻结参数维护的动量状态纯属浪费内存而且如果某处代码不小心解冻了某个参数行为会变得不可控。排查这类问题非常费劲因为报错往往滞后。数据加载、混合精度AMP、EMA指数移动平均这些模块跟普通训练没区别。EMA 需要特别注意EMA 会把模型所有参数的平均值单独存一份包括冻结的原始权重。这本身没问题因为冻结权重本来就不变但如果你只保存了 LoRA 参数恢复 EMA 状态时要把主干权重也一起恢复否则 EMA 推理时叠加的是随机初始化状态mAP 会直接崩掉。3.4 权重保存与加载只存增量LoRA 最爽的地方在于每个任务只需要保存几十 MB 的增量权重而不是整个模型。我定义了以下保存逻辑只把名字里带lora_的参数挑出来def save_lora_adapter(model, save_path): lora_state {} for name, param in model.named_parameters(): if lora_ in name: lora_state[name] param.detach().cpu().clone() torch.save(lora_state, save_path)推理部署时要把 LoRA 增量合并回基座权重得到一个完整模型再导出。合并逻辑的数学很简单新权重 原始权重 (B^T A^T) × scaling。因为前向计算是 (x A) B等价于 x (A B)而 PyTorch 线性层权重形状是 (out, in)所以增量转置一次def merge_lora_to_base(model): for name, param in model.named_parameters(): if name.endswith(lora_A): base_name name.replace(.lora_A, ) module model for part in base_name.split(.): module getattr(module, part) delta (module.lora_B.T module.lora_A.T) * module.scaling # (out, in) merged module.base_weight delta.reshape(module.base_weight.shape) module.base_weight merged.contiguous() with torch.no_grad(): module.lora_A.zero_() module.lora_B.zero_()合并的时机要特别注意。我吃过一次亏合并完顺手存了一份 checkpoint后面想加数据继续微调发现 LoRA 的基座权重已经被污染了增量也清零了等于白训。合并操作是不可逆的所以要么在合并前保留一份原始权重副本要么明确知道这个模型以后只做推理不再训练。我的习惯是所有 LoRA 训练默认只存增量文件只有到出部署包的那一步才做合并导出避免把训练链路弄脏。4. 训练策略、超参选择与效果对比4.1 rank 和 alpha 怎么定LoRA 需要调的超参不多但 rank 和 alpha 直接决定效果。我按经验给一张参考表适配不同数据规模的业务场景场景rank ralpha说明数据集很小2k 张416防止过拟合低秩足够描述增量常规业务数据集2k~20k816默认配置稳定好用数据充足20k或域差异大1632需要更多自由度拟合大偏移只挂分类头不挂回归头816与默认一致关于 rank 有一个常见误区rank 越大不代表效果越好。低秩假设的核心是增量变化存在一个低维子空间当数据量有限时强行加大 rank 反而会让 LoRA 分支过拟合训练集验证集表现变差。我测试过 r4/8/16/32 四档在 5k 张图的业务数据集上r8 和 r16 的 mAP 差异小于 0.2 个点r32 开始明显出现过拟合。所以不要迷信大 rank先跑一版 r8 的基线再按验证集表现决定加不加。alpha 和 r 的关系也值得说一下。标准实现里最终缩放因子是 alpha/r所以如果单独把 r 从 8 改成 16 但 alpha 不变相当于每个 LoRA 分量的贡献被减半。为了让行为一致要么同时把 alpha 从 16 改成 32要么接受更低的有效学习率。我的选择是默认 alpha16r 改成 16 时 alpha 同时升到 32。4.2 学习率与优化器配置LoRA 微调的学习率设置与全量微调完全不同。全量微调通常用 1e-4 这个量级LoRA 因为只更新增量矩阵且初始化时输出为 0需要用更高的学习率。我实测下来LoRA 参数的学习率取 1e-3 左右效果最好比主干原始学习率高 10 倍。具体实现上我用参数分组给不同分支配置独立学习率param_groups [ {params: [p for n, p in model.named_parameters() if lora_ in n and cls in n], lr: 1e-3}, {params: [p for n, p in model.named_parameters() if lora_ in n and cls not in n], lr: 3e-4}, ] optimizer AdamW(param_groups, weight_decay0.05)也可以简单粗暴地统一用 1e-3配合余弦退火到 1e-5。我两种都试过效果差别不大但分组方案的好处是单独控制分类分支和回归分支——分类分支要适应新语义学习率可以高一点回归分支只是微调低一点更稳。训练轮数也不必像全量微调那样跑 300 epoch。LoRA 收敛快一般 100 到 150 epoch 就足够大约是全量微调的 1/2 到 1/3。关键观察点是验证集 mAP 不再上升就可以停了这个经验值在多个数据集上都适用。我见过有人把全量微调的轮数直接套到 LoRA 上后期验证集 mAP 波动越来越大纯属浪费时间。4.3 冻结策略与 BN 陷阱这是新手翻车最多的地方。BN 层的 running_mean 和 running_var 不是 Parameter 而是 bufferrequires_gradFalse 对它们没有约束力。只要模型处于训练模式BN 就会持续用当前 batch 的统计量更新 running_mean 和 running_var。冻结 LoRA 参数时BN 统计量其实也在同步更新。因为预训练 BN 统计量跟原数据分布是绑定的换到新数据集后BN 统计量如果继续更新会逐渐偏离预训练状态导致整体输出的分布偏移。这在 LoRA 微调里尤其明显因为 LoRA 分支本身输出量级小BN 统计量漂移的影响会被放大。处理办法有两个。第一是直接把 BN 层设成 eval 模式def freeze_bn_stats(model): for module in model.modules(): if isinstance(module, (nn.BatchNorm2d, nn.SyncBatchNorm)): module.eval()但要小心把 BN 设成 eval 后训练时整个模型不能整体调用model.train()否则 BN 又被切回训练模式。正确的做法是在每个训练 step 开头重新对 BN 层执行一次 eval。我习惯把 freeze_bn_stats 放进训练的每次迭代开头确保 eval 状态不被覆盖。第二个办法是更彻底的在模型定义的层面把所有 BN 层替换成冻结统计量版直接让 forward 使用固定统计量。这个方案工程量大一点但对多卡 DDP 场景更友好不用每次迭代都额外做一轮遍历。我最终用的是混合方案单卡实验用第一个办法多卡用第二个。4.4 一个对比实验的效果数据为了让大家对 LoRA 在 YOLO26 上的收益有直观感受我整理了一份对比实验数据。实验设置在 5,000 张自定义工业质检图上类别 12 类输入分辨率 640×640单张 80GB 显存的训练卡。预训练权重是官方在公开检测数据集上训练的版本。方案可训练参数量显存占用mAP0.5mAP0.5:0.95训练时长150 epoch全量微调全部约 50M18.2 GB82.461.712 小时LoRAr8只挂 1×1 conv 分类头2.8M8.6 GB81.961.27 小时LoRAr16除 3×3 外都挂5.6M9.8 GB82.261.58 小时从数据可以清晰看到LoRA 的显存占用接近砍半训练时间缩短 40% 以上而精度损失在 0.5 个点以内。这个精度差距在很多业务场景里是可以接受的。如果你愿意多花一点显存把 r 加到 16差距还能压缩到 0.2 个点左右。另一个有意思的现象是LoRA 的收敛曲线比全量微调更平滑。全量微调在数据量小的时候loss 经常会先大涨后回调LoRA 几乎不会出现这个问题。原因很简单LoRA 起始状态就是完美预训练模型只做局部修正路径天然更稳定。这也是我在业务项目里越来越倾向于先试 LoRA 的原因省的不只是显存还有调试时间。5. 常见问题与排查经验5.1 加载权重时 key 不匹配替换 LoRA 层后模型状态字典的 key 变了。比如原来自干块的conv1.weight变成了conv1.base_weight、conv1.lora_A、conv1.lora_B。如果直接把预训练权重 load_state_dict 进去会报一堆 missing keys 和 unexpected keys。解决办法是调换顺序先加载原始预训练权重再执行 apply_lora 做替换。这样权重拷贝发生在 LoRA 层构造阶段原始权重直接拷进 base_weight不需要处理任何 key 映射。这个顺序问题我在第一次实验时吃过亏花了大半天对 key 规则后来发现把顺序调对麻烦直接消失。如果确实需要在 LoRA 化之后加载权重比如加载别人已经 LoRA 化的 checkpoint那就必须写转换逻辑把原始 key 映射到 base_weight 字段再处理新增的 lora_A/lora_B。我的经验是这些逻辑尽量单独封装成函数标注清楚适用版本否则换个模型结构又得重写。5.2 模型输出异常 / loss NaNLoRA 微调最常见的症状是loss 在前几个 iteration 突然变成 NaN或者验证集 mAP 直接原地踏步。我遇到过两次排查下来分别是这两个原因。第一次是精度溢出。混合精度训练下LoRA 分支里x lora_A的数值范围如果没控制好容易出现 fp16 溢出。解决办法是把低秩分支强制用 fp32 计算输出再转回 fp16。不过这不是最优解更根本的是控制初始化A 矩阵的初始化方差从 0.01 降到 0.001能够显著降低前几个 step 的数值摆动。但要注意方差太小时模型权重更新过慢需要配合更高学习率这又是一个平衡。第二次是学习率太高。LoRA 用 1e-3 是常见推荐值但这个数值不是万能的尤其是在分类和回归头不平衡的任务上。我把分类头学习率降到 3e-4 后 loss 稳定了mAP 不升的问题也随之解决。所以遇到 NaN 不要只想着调小全局学习率先用梯度日志看一眼是哪个分支出的问题。5.3 冻结参数但 optimizer 仍更新 BN这个问题在 4.3 节提过这里再说一个具体场景如果你用类似 torch.compile 的方式训练编译图会缓存前向逻辑。训练时 BN 层在 eval 和 train 之间来回切换可能触发编译图反复重编译反而拖慢训练。建议是用 LoRA 微调时先别开 compile等模型结构稳定后再考虑。另外还有一个细节如果业务代码里用了 model.eval() 做验证验证完成后回到训练别忘了重新调用你定义的 freeze_bn_stats()。否则 BN 统计量更新模式悄悄变了验证集 mAP 波动会骗过你的早停逻辑。我吃过一次亏明明已经收敛了验证分数却来回跳最后发现是 BN 状态在验证后被重置了。5.4 导出 ONNX 时多分支叠加问题部署场景下要把 LoRA 合并到基座模型再导出。有一个坑是合并后的权重数值和原始权重量级差别很大LoRA 增量通常会小一两个数量级。在 fp16 量化导出时这些微小增量可能被直接截断成 0合了等于没合。我的经验是先合并再在验证集上做一次快速前向验证数值变化确认 mAP 没有明显下降后再导出。如果量化后掉点把增量放大或者改用动态量化。还有一个更轻的方案直接导出基座 LoRA 分支的双分支结构推理时计算一次求和。这样省去合并过程但会让部署模型多一个分支速度和内存都有额外开销。我建议能用合并就合并合并后精度掉点再考虑双分支。5.5 多卡 DDP 与参数不参与同步问题把冻结参数和可训练参数混在一个 DDP 模型里偶尔会遇到同步问题。DDP 默认同步所有参数的梯度即使 requires_gradFalse 的参数也会触发 allreduce虽然梯度为 0。多个 worker 的 LoRA 参数初始化一致一般没事但如果有随机初始化或者模型并行可能会出现各卡之间的 LoRA 参数不同步。更实际的问题在 checkpoint 恢复。DDP 保存的 checkpoint 里会包含module.前缀加载到非 DDP 模型时要先去掉前缀。这个坑在普通训练里也会遇到但 LoRA 场景下因为模型结构变化大报错信息往往指向 key 不匹配新手容易排查半天找不到根源。我的排查建议是先打印一份 checkpoint 的 key 和当前模型的 key 做 diff十有八九一下就能定位问题。最后再分享一个小技巧。我在 LoRA 微调完成之后偶尔会给 LoRA 分支加一个非常小的 L2 正则比如 1e-4这能进一步压缩低秩矩阵的冗余维度帮助后续的模型合并和量化。实际效果是在不掉点的前提下rank 8 的 LoRA 参数还能继续稀疏掉一部分对部署也是一个加分项。如果你也有给 YOLO 系列或其他检测模型做 PEFT 的需求建议先拿一个小数据集把 LoRA 适配流程整体跑通再谈调参。这套方法对工程实践的帮助是实实在在的。