实测过 Qwen 系列若干次微调之后，说实话，多模态模型和纯文本模型在调参上完全是两种思路。很多人拿文本模型的 LoRA 经验直接套到视觉语言模型上，结果要么不收敛，要么过拟合到把训练集里的图片背景都背下来了。Qwen2.5-VL 是当前开源社区里视觉语言模型的热门选择，它的微调流程涉及视觉编码器、投影层、语言解码器三部分，每一部分对学习率的敏感度都不一样，再加上视觉 token 数量远超文本 token，显存压力、训练速度、收敛行为都会出现和纯文本微调差异很大的表现。

这篇内容是我针对 Qwen2.5-VL 多模态微调过程中的超参数选择做的一次系统梳理（上篇），重点放在训练流程设计和优化策略背后的量化逻辑上，也就是每一个超参数是怎么算出来的、怎么互相影响的，以及从哪些迹象判断当前参数是否合理。如果你正准备用 Qwen2.5-VL 微调自己的图文数据集，或者之前调参总是靠感觉、效果不稳定，这篇内容应该能给你一套可以拿回去直接对照的框架。

1. 项目概述：为什么Qwen2.5-VL的调参不能照搬纯文本经验

1.1 多模态微调和纯文本微调的本质差异

先说一个常被忽略的事实：纯文本模型微调时，输入序列的 token 数量是相对可控的，一般在几百到几千这个量级。而 Qwen2.5-VL 这类视觉语言模型，一张 448x448 的图经过视觉编码器后，产生的视觉 token 可能是几百甚至上千个。如果你输入的是视频帧或者多图拼接，视觉 token 会直接占据序列长度的大头，文本反而只占一小部分。

这个差异带来的第一个直接影响就是显存计算方式不同。纯文本微调用"序列长度 x 隐藏层维度"估算显存开销基本准确，但多模态模型必须把视觉 token 数量纳入计算。同样一个 batch 大小，多模态模型的显存开销可能比纯文本模型高出数倍。这还不是最关键的，最关键的是视觉 token 对注意力计算的影响是二次方的，序列长度翻一倍，注意力矩阵的显存占用就是原来的四倍。

另一个差异在参数更新的敏感性上。Qwen2.5-VL 的结构里，视觉编码器用的是大规模预训练权重，它对学习率非常敏感，微调幅度过大很容易破坏已经学好的视觉特征表示。我在实际训练中发现，视觉编码器的 LoRA rank 取太高，或者学习率设置超过文本部分的合理范围，很常见的一个现象是训练 loss 看起来很漂亮，但验证集上对未见图片的描述能力反而下降了。这就是典型的"灾难性遗忘"，只是发生在视觉端而不是语言端。

1.2 聚焦点说明：训练流程与优化策略的量化分析主线

这篇是上篇，所以我把核心聚焦在两块：一是训练流程的整体设计，也就是从数据到模型再到超参数，整条链路里哪些环节决定了最终效果的上限；二是优化策略的量化机制，也就是学习率、batch size、梯度累积、权重衰减这些超参数背后，到底是怎么影响参数更新的数学过程，以及怎么根据模型规模和训练数据量来估算合理的取值范围。

关于量化机制，这篇文章里讲的主要是指微调过程中使用的低比特量化技术如何与优化器状态交互，以及量化参数（比如 NF4 的 block size、双重量化）如何选择，而不是指模型推理阶段的 INT8/INT4 部署量化。这两个概念经常被混在一起，但它们的关注点完全不同，前者是为省显存跑微调，后者是为省显存跑推理。

我先给出一个贯穿全文的核心原则：Qwen2.5-VL 微调的每一个超参数都不是孤立存在的，学习率影响优化器状态，优化器状态影响显存占用，显存占用反过来限制了 batch size，batch size 又影响梯度噪声，梯度噪声最终决定收敛稳定性。所以调参的本质是在整个约束系统里找平衡点，而不是追求某一个参数的最优值。

2. 训练流程设计：从数据集组织到优化策略的整体链路

2.1 数据集格式与预处理：chat模板和图像token的排列逻辑

Qwen2.5-VL 微调的第一步不是调参，而是把数据整理成模型能够正确解析的格式。这一点比很多超参数都重要，因为数据格式错了，模型根本学不到东西。Qwen2.5-VL 的训练数据主要用 chat 模板组织，每条样本包含 messages 字段，里面交替排列 user 和 assistant 的对话内容。

多模态数据在 messages 里的组织有讲究。图片需要放在 content 的列表里，与文本并存。比如一条样本可以是 user 的消息里包含一张图和一句话"请描述这张图片的内容"，assistant 的消息里是期望模型生成的描述。这里有两个细节：

第一个细节是图片的放置位置。Qwen2.5-VL 支持在一条消息里放多张图片，模型会按照你给定的顺序读取图片 token。实际微调时，如果一条样本里有多张图，建议在文本中明确使用"第一张图"、"第二张图"这样的自然语言引导，能显著提升模型对多图任务的响应准确性。

第二个细节是图片分辨率。Qwen2.5-VL 会根据输入图片尺寸动态调整视觉 token 数量，但不意味着图片越大越好。高分辨率图片直接导致视觉 token 剧增，训练速度成倍下降。我在处理实际项目时，一般会把最长边缩放到 768 像素以内，这样既保证模型能看到足够的细节，又不至于让序列长度失控。

数据处理完成后，如果用的是开源工具，通常会先把数据集转成 JSONL 格式，一行一条样本，每条样本包含一个 messages 字典。不方便直接给出完整代码，但大致结构就是构建一个符合 chat 模板的 dict，然后按照对话顺序填充 user 和 assistant 内容。

2.2 训练工具与基础配置：一个可复现的LoRA训练骨架

Qwen2.5-VL 微调的主流方案是 LoRA，也就是在冻结大部分权重的前提下，对指定的模块插入低秩可训练矩阵。这样做有两个直接好处：一是可训练参数量大幅减少，从全量微调的几十亿参数降到几千万参数规模；二是显存占用显著降低，让普通消费级显卡也能跑起来。

我在选择训练框架时，优先使用的是 Hugging Face 的 transformers 配合 peft 库。Qwen2.5-VL 的视觉编码器和语言解码器都支持 peft 进行 target_modules 指定。一个典型的 LoRA 配置包括：

• r（低秩矩阵的秩）：控制可训练参数量，一般取 8 到 64 之间
• alpha（缩放系数）：控制 LoRA 权重对原始权重的扰动强度，常用值是 r 的 1 到 2 倍
• target_modules（目标模块）：需要指定插入 LoRA 的层，比如注意力层的 q_proj、k_proj、v_proj、o_proj 等

从参数计算的逻辑来看，LoRA 微调等于在原始权重矩阵 W 旁边加了一个低秩增量矩阵 BA，其中 B 的形状是 (r, hidden_size)，A 的形状是 (hidden_size, r)。前向传播时，输出是 Wx 加上 alpha 除以 r 再乘以 BAx。这里 alpha 除以 r 的比值决定了增量对原始输出的影响幅度。比如 r 取 8，alpha 取 16，那么缩放系数就是 2，意味着 LoRA 增量被放大了两倍。

实际训练时，我对 target_modules 的选择倾向是覆盖 q_proj、k_proj、v_proj、o_proj 这四个注意力的投影矩阵，再加上前馈网络的 gate_proj、up_proj、down_proj。视觉编码器部分选不选，取决于你的任务是否需要模型改变视觉特征提取方式。如果是文档理解这类任务，视觉编码器一般保持冻结就够用；如果是细粒度物体识别，可以尝试对视觉模块加 LoRA，但学习率必须压得更低。

2.3 训练流程的分阶段策略：冻结视觉编码器还是全模块协同训练

一个值得单独展开的问题：Qwen2.5-VL 微调时，视觉编码器到底是冻结还是参与训练？我在不同任务上的测试结果表明，这不是一个非此即彼的选择，而是可以根据任务性质分成三种策略：

第一种策略是只训练语言部分的 LoRA，视觉编码器完全冻结。这种方案适用于图文对话、基础 OCR、通用描述生成这类任务。在这种情况下，预训练视觉特征已经足够好，语言端只需要学会把视觉特征转化成符合任务风格的文本。这个策略训练最快、最省显存，也是我建议大多数场景优先尝试的方案。

第二种策略是语言部分和视觉部分都加 LoRA，但视觉端的 rank 设置得比语言端小，学习率也压低。这种方案适用于需要对视觉特征做领域适配的任务，比如医学影像描述、工业缺陷检测，这些场景的图片分布和预训练数据差异较大。我在实际操作中，视觉端 rank 一般取语言端的四分之一左右，学习率取语言端的一半以下。

第三种策略是部分解冻视觉编码器做全量微调，这个方案显存开销最大，只在数据量非常充足且任务和预训练任务差异极大的情况下才值得使用。全量微调视觉编码器时，一个必须注意的问题是要给视觉部分单独设置更低的学习率，比如语言部分的学习率是 2e-4，视觉部分可以降到 2e-5 量级。

从训练流程的视角看，这三种策略不是冲突的，而是可以组合使用的。我常用的做法是：先按策略一跑一轮 baseline，看一下模型在验证集上的表现，如果发现模型对图片内容的理解偏差较大，再考虑加上视觉端的 LoRA。这种方式比一开始就全模块齐上更可控，也更容易定位问题出现在哪一端。

3. 超参数量化分析：每个关键参数背后的数学与工程逻辑

3.1 学习率、批次大小与梯度累积的相互作用

学习率是微调里最核心也最敏感的超参数。以我常用的 LoRA 微调配置为例，文本端学习率一般落在 2e-4 到 1e-4 之间，视觉端如果参与训练则落在 1e-5 到 5e-5 之间。学习率的上限受两件事约束：一是优化器的二阶动量估计，二是 LoRA 增量矩阵的数值稳定性。

从优化器角度解释，AdamW 是 LoRA 微调中最常用的优化器，它的一阶动量是梯度均值，二阶动量是梯度平方的指数移动平均。每个参数的有效学习率等于全局学习率除以二阶动量的平方根。如果一个参数的历史梯度幅值很小，它的二阶动量就很小，有效学习率反而会被放大，可能导致单步更新过大。这就是为什么 LoRA 微调时需要对 alpha 和 r 的比值做约束。

batch size 的影响则体现在梯度噪声上。大 batch size 意味着梯度估计更精确，可以用更大的学习率；小 batch size 意味着梯度噪声更大，需要更小的学习率来保持稳定。一个粗略的参考是：batch size 翻倍，学习率可以尝试乘以根号二左右，但这个规律在视觉语言模型上并不精确，因为每次迭代的 token 数量差异太大了。

梯度累积是解决显存不足的工程方案，它的原理是把多个小 batch 的梯度累加后再统一更新参数。数学上和直接使用大 batch 是等价的，但实际训练中有一个容易被忽略的问题：如果选择了梯度累积，梯度剪裁的阈值要相应调大，或者直接用累积后的总梯度范数来剪裁。否则，每个小 batch 的梯度在累积前就被剪裁到同一个阈值，累积后总梯度反而被压缩了。

我建议用一句话记住三者的关系：学习率由有效 batch size 决定，有效 batch size 等于单次前向的 batch size 乘以梯度累积步数，显存容量决定单次前向 batch size，而有效 batch size 又影响收敛曲线和最终效果。调参时应该先确定显存约束，再反推其他参数，而不是反过来先选学习率。

3.2 权重衰减、学习率调度与梯度剪裁的边界条件

权重衰减在 LoRA 微调中的作用一直存在争议。我的经验和很多开源实验类似：LoRA 的低秩矩阵本身就有隐式的正则化效果，权重衰减设置太大会让可训练参数被过度压制，导致模型欠拟合。一般建议权重衰减设置在 1e-2 到 1e-4 之间，倾向于取较小值，我常用的是 0.01，但更严格的做法是只对 LoRA 参数设置权重衰减，不对 LayerNorm 和 bias 设置。

学习率调度器方面，LoRA 微调一般采用带 warmup 的余弦退火或者线性衰减。warmup 的比例一般占总训练步数的 3% 到 10%。为什么要 warmup？因为在训练初期，优化器的二阶动量还没有充分估计，此时直接上大学习率容易导致更新步长过大，参数在早期出现震荡。warmup 的本质是在前几步用很小的学习率把优化器的统计量"预热"起来，等二阶动量稳定后再逐步提升学习率。

梯度剪裁的阈值设置，在 Qwen2.5-VL 微调中比纯文本模型更重要。因为视觉 token 产生的梯度范数可能远大于文本 token，尤其是当你对视觉编码器做微调时，梯度范数会出现剧烈的波动。我一般把最大梯度范数设置为 1.0，如果发现 loss 曲线频繁出现尖峰，就把阈值降到 0.5 或者检查数据中是否有异常样本。

3.3 训练步数、评估策略与过早停止的经验法则

很多人在微调时只盯着训练 loss，却不关心验证集表现，这在大模型微调中是个很大的坑。大模型的拟合能力很强，训练集 loss 降到很低完全不代表泛化能力好，甚至可能出现过拟合。我的经验是：每训练一定步数就在固定的验证集上评估一次，记录验证 loss 和任务相关的指标，比如图文问答准确率或者描述相似度。

训练步数或训练轮数的设定需要结合数据量、模型规模、任务难度来判断。以 Qwen2.5-VL-7B 为例，如果使用 1 万条高质量图文样本做 LoRA 微调，训练 3 到 5 个 epoch 通常就够了。这里"够"的判断标准不是训练 loss 已经收敛，而是验证指标在一个合理区间内波动。数据量越大的情况下，通常不需要训练太多轮；数据量小的情况下，训练轮数可以适当增加，但是要更加警惕过拟合风险。

关于提前停止的判断标准，我常用的做法是：当验证 loss 连续多个评估点没有下降，或者模型已经出现过拟合迹象时，就保存最后一个表现最好的 checkpoint，不再继续跑下去。显式地在训练脚本里配置好保存最优模型、按评估指标筛选的逻辑，而不是等训练完再从一堆 checkpoint 里挑，会省下很多时间。

3.4 LoRA rank 与 alpha 的量化选择依据

LoRA rank 的选择经常被简单理解为"越大越好"，实际上它受到模型规模和数据量的双重约束。从数学角度看，LoRA 的增量矩阵 BA 的秩最多是 r，如果真实的任务适配需要的秩超过了 r，模型的学习能力就不够；如果 r 太大，可训练参数量增加，对数据量的要求也相应提高。

在 Qwen2.5-VL 这类 7B 级别的模型上，我对 rank 的经验取值范围是 16 到 64 之间。对于简单任务，比如风格迁移或一般描述生成，rank 取 16 到 32 通常已经足够，更低的 rank 还能顺便充当正则化。对于复杂任务，比如细粒度的图表理解或多图推理，rank 可以取到 64 甚至更高，但需要注意训练时间与显存消耗随之上升。

alpha 和 rank 的比值关系是另一个关键。如果保持 alpha 不变而调大 rank，那么 alpha 除以 rank 的比值会变小，LoRA 增量对输出影响就变弱了。所以调整 rank 时，alpha 也要同步调整。我的习惯是把 alpha 设为 rank 的 1 到 2 倍，这不是某个数学推导得出的绝对最优值，而是在多次实验中验证的相对稳定配置。如果你把 rank 从 16 调到 32，最好把 alpha 也从 16 或 32 相应调大，否则最终模型的输出变化幅度可能没达到预期。

4. 量化机制深析：低比特优化器状态与模型权重的显存平衡

4.1 QLoRA、NF4 与双重量化的工作机制

当显存不够时，一个非常有效的方案是使用 QLoRA 这类低比特量化微调技术。很多人在这个环节有个误区，以为量化之后模型效果一定下降，实际上，QLoRA 微调时模型权重虽然被量化成了低精度存储，但训练过程中计算梯度用的是反量化后的高精度数值，因此精度损失被控制在一个很小的范围内。这也是它能用消费级显卡训练几十亿参数模型的原因。

QLoRA 背后的量化机制大致是这样的：模型权重在加载后，被量化为NF4格式，也就是 4-bit 的归一化浮点数。NF4 的量化区间不是均匀分布的，而是根据正态分布做了非线性映射，这样可以让更多的量化级别集中在权重值出现概率更高的区域，减少量化误差。你看到模型参数文件变小了很多，但推理计算时，反量化回高精度的过程比较繁琐，这一部分是在计算单元内自动完成的，不需要人工干预。

双重量化则是为了进一步压缩量化过程中产生的额外内存开销。在 NF4 量化中，每个 block 都需要存储一个量化尺度，这个尺度本身也是浮点数。双重量化把尺度再做一次量化，通常是用 8-bit 表示，从而减少尺度参数的存储开销。在大模型场景下，block 数量多，这个优化累计下来节省的显存就比较可观了。

还有一个相关模块是分页优化器。它利用 CPU 和 GPU 之间的内存交换，将优化器参数溢出部分暂时放到 CPU 内存，在使用时再换回。这个机制的实际效果取决于任务的数据访问模式，对于数据量较大、顺序性较强的训练任务效果比较明显。我建议把它当作显存快用完时的手段，而不是默认配置。

4.2 量化超参数：block size、双重量化开关与量化噪声的影响

量化 block size 是一个值得仔细调整的参数。block size 越小，量化尺度越精细，量化误差越小，但存储开销越大；block size 越大，占用的存储越小，但量化误差会增大。常见的选择是 32 到 64 之间。我实测下来，对 Qwen2.5-VL 这种对视觉细节比较敏感的多模态模型，block size 建议取 32，这样可以尽量保住视觉编码器输出分布的细节。

双重量化开关一般保持开启即可，因为它的收益大于成本。但需要注意，双重量化在某些版本的库和特定模型中可能存在兼容性问题，如果你的训练因为环境问题报错，可以先关掉双重量化做排查。

量化噪声的影响不太容易直接观测。NF4 量化本质上给模型权重引入了少量噪声，这些噪声在前向传播时会传播到输出。大多数情况下，这个噪声的量级足够小，不会对训练产生显著影响。但如果你的数据集本来就有比较大的噪声，量化噪声和数据集噪声可能会叠加，导致训练难以收敛。这种情况下可以考虑使用 8-bit 量化作为替代方案，代价自然是显存占用上升。

4.3 梯度检查点与显存优化策略的实际配合

梯度检查点是个不太被重视但很实用的显存优化技术。它的原理是：在反向传播过程中，不保存每一层的中间激活值，只在前向传播时保留关键节点的激活值，在反向传播需要某一层的中间梯度时，重新计算一次前向并补齐缺失的激活值。这个思路以时间换空间，显著降低显存占用，代价是增加训练时间。对 Qwen2.5-VL 来说，启动梯度检查点后显存占用可以降低约 30% 到 50%，训练时间会增加 20% 到 30%。显存不够时优先考虑梯度检查点，比强行调小 batch size 更好，因为小 batch 会显著影响梯度估计的稳定性。

我在实际训练中会把梯度检查点和低比特量化组合使用。步骤如下：

• 先尝试不开启任何显存优化手段跑一次小规模训练，记录显存峰值
• 如果显存不足，先开梯度检查点，观察训练时间和显存变化
• 如果还不足，再引入 4-bit 量化加载模型
• 最后才考虑减小单次 batch size 或梯度累积步数

这个顺序很关键。因为它尽量避免以牺牲梯度稳定性为代价来省显存。梯度检查点和量化带来的主要代价是训练时间变长，而减小 batch size 带来的代价是优化行为变化、收敛不确定性增加，影响的不只是工程效率，还有训练效果。

4.4 优化器状态分解：8-bit AdamW 的实际收益与适用范围

除了对模型权重做量化，还可以对优化器状态做量化。最典型的方案是 8-bit AdamW。在标准 AdamW 中，每个参数需要保存一阶动量和二阶动量，这两个状态通常是 32 位浮点数。当可训练参数量较大时，优化器状态的显存占用甚至可能超过模型本身的显存占用。而 8-bit AdamW 通过分块量化压缩了一阶动量和二阶动量的存储，显著降低了这部分开销。

8-bit AdamW 的适用范围也有讲究。它的量化误差会对参数更新产生轻微影响，对于大多数 LoRA 微调场景来说，这个误差在可接受范围内。但如果你在训练时需要极快的收敛速度和严格的优化精度，可以对比一下普通 AdamW 和 8-bit AdamW 配合 4-bit 基座模型与配合 8-bit 基座模型之间的差异。目前开源社区的实际训练情况是：LoRA 微调场景下，8-bit AdamW 的精度损失基本可以忽略，显存收益明显，尤其是你同时开了较长序列长度的时候，是一项非常值得尝试的优化。

5. 常见问题与排查技巧实录

5.1 训练不收敛或loss震荡的排查路径

训练 loss 不下降或者反复震荡，排在首位的原因往往不是超参数，而是数据问题。先检查你的数据里是否包含图片无效、文本为空、或图文不对应的样本。这些脏数据混入训练集后，梯度方向互相冲突，损失函数自然难以收敛。先把数据清洗得干净些，再开始调整超参数，这是排查的第一步。

如果数据没问题，再来看学习率是否过高。Qwen2.5-VL 的视觉 token 梯度分布和文本 token 梯度分布差异较大，偶尔会出现某一步的梯度范数异常大，导致 loss 跳变。此时尝试降低学习率，或者调低梯度剪裁阈值。我发现当 loss 出现周期性震荡时，大概率是学习率偏高，需要下降一半左右再观察。

还有一种情况是训练 loss 正常下降，但验证集指标长期不动。这种情况通常是因为训练集和验证集的分布差异过大，或者验证集上存在测试困难样本。我的建议是先在训练集上随机抽取一部分样本，单独评估模型效果，如果这部分效果也不行，说明模型能力还没学到位；如果这部分效果好但验证集差，就是分布不匹配问题，需要重新划分数据。

5.2 显存溢出与OOM的排查方向

显存溢出时最容易犯的错误是无脑调小单次 batch size，导致梯度噪声剧增、收敛变慢。更合理的排查顺序是：

• 先确认是否已开启梯度检查点，如果还没有开启，优先开启
• 再检查是否因为模型加载位数过高导致基础显存占用过高，可以换成 4-bit 加载
• 检查数据中的最大图片是否异常大，对单批样本的序列长度做一个统计，如果某几个样本特别长，可以考虑缩短图片最长边
• 如果以上手段都用上还溢出，才考虑减小单次 batch size，并用梯度累积补回有效 batch size

一个需要特别留意的点是：OOM 不一定发生在整体训练过程的最开始，而可能在训练到某些特殊样本时才出现。这是因为有些图片产生的视觉 token 数量特别多，序列长度瞬间拉长，显存峰值随之飙升。所以排查显存问题时，建议记录一下每次 OOM 时数据批次里的图片属性，看看是不是集中在特定类型的样本上。

5.3 超参数速查表与常见故障对照

以下是我在实际微调过程中整理的速查表，适合作为起步配置参考。它不是绝对的“标准答案”，但可以省掉不少在黑暗里摸索的时间。具体调参时一定要结合自己的数据规模、图像平均分辨率、显存容量做调整。

遇到典型的故障表现，可以优先按照对应方向排查：

• 训练 loss 急速下降然后停滞：观察是否过拟合，调低学习率或减小训练轮数，检查验证集表现
• 训练 loss 下降但验证集指标也下降：过拟合类型的问题，增加数据量或增大 dropout，减小 LoRA rank
• 训练 loss 反复横跳：学习率过高或数据中有异常样本，先洗数据再降学习率
• 显存 OOM：按梯度检查点、模型量化、降低图片分辨率、减小 batch size 的顺序排查
• 模型输出出现重复文本：学习率过高或数据集质量不高，也可以验证是否 LoRA rank 设置偏高导致可学习参数过多

5.4 一套完整的起步配置示例

我把一套适合大多数场景的起步配置放在下面，它对应的场景是：普通消费级显卡（显存约 16GB 到 24GB）、约 1 万条图文样本、通用图文理解任务、视觉编码器暂时冻结。这套配置的要点是保守优先：学习率取中间偏低，rank 取中等，显存优化手段全开，优先保证训练能跑通、能稳定收敛，再逐步调优。

• 模型加载：4-bit 量化加载，开启双重量化
• 视觉编码器：冻结，只训练语言部分的 LoRA
• LoRA 配置：rank 为 32，alpha 为 32，target_modules 覆盖 q_proj、k_proj、v_proj、o_proj、gate_proj、up_proj、down_proj
• 优化器：AdamW，权重衰减 0.01
• 学习率：1.5e-4，warmup 比例 5%，余弦退火到 1e-5
• 单次 batch size：1 或 2，按显存调整，梯度累积步数设置为 8 到 16，保证有效 batch size 达到 16 左右
• 梯度剪裁：max_grad_norm 为 1.0
• 梯度检查点：开启
• 图片处理：最长边缩放到 640 像素左右
• 训练轮数：4 轮，每累计一定步数做一次评估，保存验证集表现最优的 checkpoint

这套配置跑完后，如果模型效果不够理想，优先调整的顺序是：先微调学习率（减半或加倍各试一次），再调整 rank 和 alpha，然后考虑是否启用视觉端 LoRA，最后才动 batch size 和梯度累积。整体思路是每次只动一个变量，保持其他变量不变，这样出了问题才方便定位。

6. 评测视角：从数值指标到业务效果的微调验收方法

6.1 客观评估指标的选择与计算口径

多模态微调的效果评估不能只看 loss。我通常会从三个维度建立评估体系：生成指标、理解指标和业务指标。在生成维度，对描述类任务计算生成文本和参考文本之间的相似度得分；对问答类任务计算准确率或 F1。在理解维度，让模型基于图片做事实判断，比如计算图中目标数量、判断两个物体的相对位置，统计正确率。在业务维度，则是和实际使用场景挂钩的指标，比如是否能正确提取票据里的关键字段。

这里的一个重要经验是：评估集和你最终的使用场景越接近，微调效果的可信度越高。不要用那些网上公开的、和你的任务类型差得很远的验证集来做最终判断。我在实际操作中会专门构造一个"困难样本集"，里面收集的是 baseline 模型最容易犯错的图片，每次微调后用这些样本单独评估，如果困难样本集的指标明显提升，说明微调真正解决了痛点问题，而不是整体分数虚高。

6.2 主观样本巡检：用最小集快速判断模型行为变化

除了跑指标，我建议每次训练结束后，抽 20 到 50 条样本，人工看模型的输出。重点不是看它是否和参考答案完全一致，而是观察以下几个方面：

• 模型是否学会了和任务相关的表达风格，比如正式、简洁、详细
• 模型是否出现幻觉，比如描述图片里根本不存在的物体
• 模型是否对图片的位置信息敏感，比如是否混淆左右和上下关系
• 模型是否对训练集里的某些图片产生了记忆，而不是学会泛化

这种人工巡检可以在指标之外提前发现很多问题。比如有一次我微调过后的模型在指标分数上提升了 20%，但人工巡检发现它对某类特定背景的图片产生了过强偏好，几乎把所有内容都往那个背景上靠。这种在指标上很难暴露的行为偏差，只有人工看输出才能快速发现。

6.3 迭代调优思路：一个版本只动一个变量的复现原则

微调迭代最忌讳的是一轮训练同时改很多参数。改学习率、改 rank、换数据集、改 prompt 模板，然后发现效果提升了，你根本不知道是哪个改动起了作用。我自己的习惯是：无论多急，一次只改一个变量，并且在实验记录里写清楚上一版配置和这一版配置的差异。

同时，微调是一个工程链路，最终效果是数据、模型、参数、评估几方面叠加的结果。如果只盯着超参数调优，而数据质量没有保证，效果提升空间很有限。大部分情况下，我把效果不佳归因排序为：数据问题、prompt 模板问题、LoRA 配置问题、超参数设置问题。一个很典型的例子是：有一次任务效果不好，排查了半天，最后发现是数据里有一半样本的 assistant 回答是用旧模板生成的，格式和预期不一致，导致模型被带偏。

调整 prompt 模板时也需要注意一致性。微调数据里 model 的回答风格，就是模型在微调后会模仿的风格。如果你希望模型输出简洁，训练样本里就不能出现大段啰嗦的回答；如果你希望模型输出 JSON 结构，那么所有训练样本的模型回答都应该保持同一套 JSON 格式。这个细节比很多超参数都关键，因为它直接决定了模型学到的输出分布。

每次训练结束后，建议把配置、训练曲线、验证集得分、人工巡检结论、使用的数据集版本一起记录下来。时间久了你会发现，这套记录本身就是最宝贵的资产，很多调参经验都可以从历史实验记录里归纳出来，而不需要重复踩坑。这比任何一篇教程里的 "经验之谈" 都更适用于你自己的项目场景。

等到积累了几轮成功的微调经验之后，你自然会把关注点从"超参数怎么选"转向"数据怎么设计"和"任务怎么拆解"，那才是一个更高层次的迭代阶段。