企业官网建设流程全解析

做检测模型训练这行当久了，你会发现一个问题：模型越来越大，微调越来越贵。前阵子团队拿到 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×d，B 的维度是 d×r，r 远小于 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 的核心理念是"以最小参数量学习最大的有效变化"。分类分支对应的语义空间在不同数据集之间差异最大，所以 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 Conv2d：

import torch import torch.nn as nn import torch.nn.functional as F class LoRAConv2d(nn.Module): """将 1x1 卷积或线性层替换为带 LoRA 分支的版本""" def __init__(self, original_module, r=8, alpha=16): 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.01，B 矩阵用零初始化。这样初始阶段低秩分支输出为 0，模型行为跟原始预训练权重完全一致，微调过程是从"原模型"平滑开始的，不会一上来就破坏特征。如果你把 A 也初始化为零，梯度在前几步会特别小，收敛会慢不少；用小的非零初始化是最稳的折中。

scaling = alpha / r 这个缩放系数不是拍脑袋定的。保留这个缩放因子，可以在 rank 改变时让模型表达力不出现剧烈跳变。如果你的任务里 r 调得比较大，缩放系数会跟着变，这时候通常不需要额外调 alpha。比如 r 从 8 涨到 16，alpha 同步从 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, r=8, alpha=16): 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, r=r, alpha=alpha) 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_grad=True 的参数：

from torch.optim import AdamW trainable_params = [p for p in model.parameters() if p.requires_grad] optimizer = AdamW(trainable_params, lr=1e-3, weight_decay=0.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 有一个常见误区：rank 越大不代表效果越好。低秩假设的核心是"增量变化存在一个低维子空间"，当数据量有限时，强行加大 rank 反而会让 LoRA 分支过拟合训练集，验证集表现变差。我测试过 r=4/8/16/32 四档，在 5k 张图的业务数据集上，r=8 和 r=16 的 mAP 差异小于 0.2 个点，r=32 开始明显出现过拟合。所以不要迷信大 rank，先跑一版 r=8 的基线，再按验证集表现决定加不加。

alpha 和 r 的关系也值得说一下。标准实现里最终缩放因子是 alpha/r，所以如果单独把 r 从 8 改成 16 但 alpha 不变，相当于每个 LoRA 分量的贡献被减半。为了让行为一致，要么同时把 alpha 从 16 改成 32，要么接受更低的有效学习率。我的选择是：默认 alpha=16，r 改成 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_decay=0.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 而是 buffer，requires_grad=False 对它们没有约束力。只要模型处于训练模式，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 显存的训练卡。预训练权重是官方在公开检测数据集上训练的版本。

从数据可以清晰看到：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 NaN

LoRA 微调最常见的症状是：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_grad=False 的参数也会触发 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 适配流程整体跑通，再谈调参。这套方法对工程实践的帮助，是实实在在的。