1. 项目缘起与实验目标拆解1.1 为什么要在 RTX2080Ti 上折腾 Qwen3-VL-4B手里有一张 RTX2080Ti 11GB这卡在二手市场价格已经跌到很舒服的区间但显存只有 11GB放在 2024 年之后的多模态大模型微调场景里说实话是有点捉襟见肘的。Qwen3-VL-4B-Instruct 这个模型本身参数量是 4B 级别如果做全参数微调光是模型权重加载就要吃掉接近 8GB 显存FP16 精度下 4B 参数约 8GB再加上视觉编码器、优化器状态、梯度、激活值11GB 根本不够看。所以这次实验的核心目标很明确在单张 RTX2080Ti 上用 QLoRA 的方式完成 Qwen3-VL-4B-Instruct 的指令微调并且把训练效率、显存占用、收敛情况完整记录下来。QLoRA 这套方案我在纯文本模型上已经跑过很多次了从早期的 LLaMA 到 Qwen 系列4-bit 量化加 LoRA 适配器的组合确实能把显存门槛压下来。但多模态模型不一样它多了一个视觉编码器分支图像经过 ViT 处理后产生的视觉 token 会和文本 token 拼接在一起送进 LLM这部分的显存开销和计算开销都需要单独考虑。我这次想验证的就是QLoRA 在多模态场景下到底能不能在 11GB 显存里跑起来能跑的话效率如何有哪些参数需要特别调整。1.2 实验环境与工具链选型工具链方面我选了 ms-swift这是魔搭社区出的一个训练框架对 Qwen 系列的支持比较到位QLoRA、LoRA、全参微调都有现成的配置模板。相比自己手写训练脚本用 ms-swift 的好处是它已经把多模态数据的处理流程、视觉编码器的冻结策略、LoRA 的注入位置都封装好了省去了大量调试时间。当然代价是灵活性稍差但对于这次效率实验来说快速跑通比什么都重要。具体环境配置如下组件版本/型号说明GPURTX2080Ti 11GB单卡无 NVLinkCUDA11.82080Ti 支持的最高稳定版本之一PyTorch2.1.2与 CUDA 11.8 匹配ms-swift2.4.x支持 Qwen3-VL 系列量化方案bitsandbytes 4-bit NF4QLoRA 标准配置精度bf16 计算fp16 存储2080Ti 不支持 bf16 原生计算需注意这里有个坑要先说RTX2080Ti 是 Turing 架构不支持 bf16 的原生计算只能做 fp16。而 Qwen3-VL 官方推荐用 bf16 训练因为 bf16 的动态范围更大不容易出现梯度溢出。在 2080Ti 上我们只能用 fp16这就意味着需要额外关注 loss scaling 和梯度裁剪否则很容易出现 NaN。这一点在后面调参部分会详细展开。1.3 实验要回答的三个核心问题整个实验我给自己定了三个要回答的问题第一显存够不够。4-bit 量化后模型权重约 2.5GB加上视觉编码器、LoRA 参数、优化器状态、激活值11GB 能不能撑住batch size 能开到多少。第二速度怎么样。单卡 2080Ti 的算力有限4B 模型加上视觉分支每秒能处理多少 token一个 epoch 要跑多久跟纯文本模型比慢多少。第三效果行不行。QLoRA 4-bit 量化本身会带来精度损失多模态任务对视觉信息的敏感度又比较高训完之后模型在验证集上的表现能不能接受loss 曲线是否正常收敛。这三个问题贯穿整个实验后面的所有配置和调参都是围绕它们展开的。2. QLoRA 与多模态微调的核心原理拆解2.1 QLoRA 到底省了什么很多人知道 QLoRA 省显存但说不清楚省在哪。我用最直白的方式拆一下。一个 4B 参数的模型如果用全参数微调模型权重 FP164B × 2 bytes 8GB梯度 FP164B × 2 bytes 8GB优化器状态AdamW4B × 8 bytes 32GB一阶动量二阶动量各 4 bytes激活值跟 batch size 和序列长度相关通常 2-6GB加起来轻松超过 50GB单卡 11GB 想都别想。QLoRA 做了三件事把这个数字压下来第一把基座模型量化到 4-bit。4B 参数 × 0.5 bytes 2GB直接省了 6GB。量化用的是 NF4Normal Float 4-bit这是一种针对正态分布权重优化的量化格式比普通的 INT4 精度损失更小。第二冻结基座模型只训练 LoRA 适配器。LoRA 的原理是在原始权重矩阵旁边挂两个小矩阵 A 和 B训练时只更新这两个小矩阵原始权重不动。这样梯度就只跟 LoRA 参数有关4B 模型的梯度直接省掉了。LoRA 参数量通常只有原模型的 0.1%-1%对于 4B 模型rank8 的情况下大概 400 万参数梯度开销可以忽略。第三优化器状态只针对 LoRA 参数。400 万参数 × 8 bytes 32MB跟之前的 32GB 比简直是零头。所以 QLoRA 的显存账大概是基座 2GB LoRA 参数和梯度 0.1GB 优化器 0.03GB 激活值 3-5GB 视觉编码器 1-2GB ≈ 6-9GB。11GB 是够的但余量不算特别充裕batch size 和序列长度需要控制。2.2 多模态模型比纯文本多出来的开销Qwen3-VL-4B-Instruct 的结构可以简单理解为一个视觉编码器ViT 一个投影层 一个 4B 的语言模型。图像输入后ViT 把它切成 patch编码成视觉 token然后通过投影层映射到语言模型的 embedding 空间和文本 token 拼在一起。多出来的开销主要有三块视觉编码器的显存。ViT 本身参数量不大Qwen3-VL 的视觉分支大概几亿参数但图像经过 ViT 后产生的视觉 token 数量不少。一张 448×448 的图patch size 14会产生 32×321024 个 patch加上 cls token 等视觉 token 轻松上千。这些 token 进入 LLM 后注意力计算的复杂度是 O(n²)序列长度直接翻倍甚至更多。视觉 token 的激活值。激活值显存跟序列长度成正比视觉 token 让有效序列长度大幅增加激活值开销自然上去了。这也是为什么多模态训练时 batch size 通常要比纯文本小很多。图像预处理的开销。这部分主要在 CPU 和内存不在显存但会影响数据加载速度进而影响 GPU 利用率。如果 dataloader 的 worker 数不够GPU 会经常等数据训练速度上不去。理解了这些后面的参数调整就有方向了控制图像分辨率、控制 batch size、增加 dataloader worker、用 gradient checkpointing 换显存。2.3 LoRA 注入位置的选择逻辑LoRA 挂在哪些层上直接影响训练效果和参数量。ms-swift 默认的配置是挂在 q_proj、k_proj、v_proj、o_proj 这些注意力层的投影矩阵上有些配置还会加上 gate_proj、up_proj、down_proj 这些 FFN 层。我的选择是注意力层全挂FFN 层也挂上。理由是多模态任务需要模型学会对齐视觉和文本信息注意力层负责跨模态交互FFN 层负责特征变换两边都调效果更稳。代价是参数量增加rank8 的情况下全挂大概 800 万参数比只挂注意力层多一倍但显存开销依然可以忽略。rank 的选择上我用了 8。rank 越大LoRA 的表达能力越强但参数量和显存也越大。对于 4B 模型做指令微调rank8 到 16 是比较常见的区间。我这次先用 8 跑基线如果效果不够再往上加。还有一个参数是 lora_alpha它控制 LoRA 更新的缩放比例通常设为 rank 的 2 倍也就是 16。这个比例不是绝对的但 2 倍是个比较稳的起点。3. 实操配置与关键参数详解3.1 环境搭建的完整步骤先把环境搭起来。我用的是一台 Ubuntu 20.04 的机器驱动版本 535CUDA 11.8。步骤按顺序来# 创建虚拟环境 conda create -n qwen3vl python3.10 -y conda activate qwen3vl # 安装 PyTorchCUDA 11.8 版本 pip install torch2.1.2 torchvision0.16.2 --index-url https://download.pytorch.org/whl/cu118 # 安装 ms-swift pip install ms-swift2.4.0 # 安装量化依赖 pip install bitsandbytes0.41.3 # 安装多模态相关依赖 pip install transformers4.40.0 accelerate0.29.0这里有几个版本要卡死。bitsandbytes 0.41.3 是我实测在 2080Ti 上比较稳的版本太新的版本有时候会有兼容性问题。transformers 用 4.40.0因为 Qwen3-VL 的模型代码在这个版本上验证过。accelerate 用 0.29.0配合 ms-swift 2.4.0。装完之后验证一下import torch print(torch.cuda.is_available()) # 应该是 True print(torch.cuda.get_device_name(0)) # 应该是 RTX 2080 Ti import bitsandbytes as bnb print(bnb.__version__) # 0.41.3如果 bitsandbytes 报错说找不到 CUDA通常是 CUDA 版本和编译版本不匹配重装对应版本即可。3.2 训练脚本的核心配置ms-swift 的训练入口是swift sft命令也可以用 Python 脚本调用。我用的是命令行方式配置写在参数里。核心参数如下swift sft \ --model_type qwen3-vl-4b-instruct \ --model_id_or_path Qwen/Qwen3-VL-4B-Instruct \ --dataset /path/to/your/dataset.jsonl \ --load_in_4bit true \ --quantization_method bnb \ --bnb_4bit_quant_type nf4 \ --bnb_4bit_use_double_quant true \ --torch_dtype float16 \ --lora_target_modules ALL \ --lora_rank 8 \ --lora_alpha 16 \ --lora_dropout 0.05 \ --max_length 2048 \ --per_device_train_batch_size 1 \ --gradient_accumulation_steps 8 \ --gradient_checkpointing true \ --learning_rate 1e-4 \ --num_train_epochs 3 \ --warmup_ratio 0.05 \ --lr_scheduler_type cosine \ --max_grad_norm 1.0 \ --fp16 true \ --logging_steps 10 \ --save_steps 200 \ --dataloader_num_workers 4 \ --output_dir ./output/qwen3vl_qlora逐个解释关键参数的选择理由load_in_4bit bnb_4bit_quant_type nf4这是 QLoRA 的核心4-bit NF4 量化。double_quant 开启后会再做一次量化进一步省显存代价是稍微慢一点但 11GB 的卡上这点速度换显存是值得的。torch_dtype float162080Ti 不支持 bf16必须用 fp16。这里要注意fp16 训练容易溢出所以后面 max_grad_norm 设了 1.0并且要开 loss scalingms-swift 默认会开。lora_target_modules ALL所有线性层都挂 LoRA包括注意力和 FFN。参数量大一点但效果更稳。max_length 2048这个长度是文本 token 加视觉 token 的总和。如果图像分辨率高视觉 token 多文本部分就要压缩。2048 是个平衡点再长显存吃不住。per_device_train_batch_size 1 gradient_accumulation_steps 8单卡 batch size 只能开 1靠梯度累积凑等效 batch size 8。这是 11GB 显存下的无奈之举但梯度累积能保证优化效果。gradient_checkpointing true用计算换显存激活值不全部保存反向传播时重新计算。会慢 20%-30%但能省 30%-40% 的激活值显存必须开。learning_rate 1e-4QLoRA 微调的常用学习率比全参微调大一些因为 LoRA 参数少需要更大的步长。cosine 调度加 5% warmup比较稳。3.3 数据集格式与多模态数据处理ms-swift 的多模态数据集格式是 JSONL每行一个样本。我用的格式是这样的{ messages: [ {role: user, content: image这张图里有什么}, {role: assistant, content: 图中是一只橘猫趴在窗台上。} ], images: [/path/to/cat.jpg] }image是占位符ms-swift 会自动把图像处理成视觉 token 替换进去。图像路径可以是本地路径也可以是 URL。这里有个实操细节图像分辨率要控制。Qwen3-VL 的视觉编码器支持动态分辨率但分辨率越高视觉 token 越多显存和计算开销越大。我的做法是预处理阶段把图像统一缩放到短边 448长边不超过 896这样视觉 token 数量可控。如果任务对细节要求高可以适当放大但要相应减小 batch size 或序列长度。数据加载的 worker 数设了 4因为图像解码和预处理是 CPU 密集型的worker 少了 GPU 会等数据。但 worker 也不是越多越好太多会占内存4 到 8 之间比较合适。4. 训练效率实测与数据分析4.1 显存占用实测跑起来之后第一件事就是看显存。用nvidia-smi监控训练稳定后的显存占用如下阶段显存占用说明模型加载后3.2GB4-bit 基座 视觉编码器前向传播峰值8.7GB含激活值和视觉 token反向传播峰值9.4GB含梯度计算优化器更新9.6GB峰值接近 11GB 上限稳定训练9.2-9.6GB波动范围9.6GB 的峰值意味着还有约 1.4GB 余量不算宽裕但能跑。如果想开 batch size 2显存直接爆所以 batch size 1 是这张卡的极限。这里有个观察视觉 token 对显存的贡献比预期大。我做了个对比实验同样的配置纯文本数据训练时峰值显存 7.8GB加上图像后涨到 9.6GB多了 1.8GB。这 1.8GB 主要就是视觉 token 带来的激活值开销。所以如果你的任务图像分辨率更高或者一个样本里有多张图显存会更紧张。4.2 训练速度实测速度方面我记录了不同阶段的吞吐指标数值说明单步耗时含梯度累积8步约 12.5 秒batch size 1序列 2048等效样本吞吐0.64 样本/秒8 样本 / 12.5 秒token 吞吐约 105 token/秒按平均序列长度估算单 epoch 耗时约 3.5 小时8000 样本3 epoch 总耗时约 10.5 小时含验证和保存这个速度说实话不算快。对比纯文本的 Qwen3-4B QLoRA同样配置下 token 吞吐能到 180-200 token/秒多模态版本慢了将近一半。慢的原因主要是视觉编码器的前向计算和视觉 token 带来的注意力开销。如果想提速有几个方向降低图像分辨率视觉 token 减少、减小 max_length、关掉 gradient checkpointing但显存会爆。在 11GB 的约束下速度和显存的权衡空间很小基本只能接受这个速度。4.3 Loss 曲线与收敛情况训练 loss 的走势是我最关心的。前 100 步 loss 从 2.3 快速降到 1.1然后进入缓慢下降阶段到 1000 步左右降到 0.75之后在 0.6-0.7 之间波动最终 3 个 epoch 结束时稳定在 0.62 左右。这个曲线是健康的没有出现 NaN 或者 loss 突然飙升的情况。fp16 训练最怕的就是梯度溢出导致 loss 变 NaN我开了 max_grad_norm 1.0 和 loss scaling整个训练过程没有出现异常。验证集 loss 在 0.68 左右和训练 loss 差距不大说明没有明显过拟合。这也符合预期LoRA 参数量少本身就不容易过拟合加上只训 3 个 epoch模型还没到过拟合的程度。有个细节值得说前 50 步 loss 下降特别快之后变缓。这是 LoRA 训练的典型特征适配器一开始快速学习任务的基本模式后面进入精细调整阶段。如果 loss 在前 100 步没降下来通常是学习率太小或者数据有问题需要排查。5. 踩坑记录与常见问题排查5.1 fp16 训练 NaN 问题这是我在 2080Ti 上遇到的最大的坑。第一次跑的时候大概 200 步左右 loss 突然变成 NaN训练直接崩了。排查下来原因是 fp16 的动态范围太窄某些梯度值超出了 fp16 能表示的范围最大 65504溢出后变成 inf再经过运算变成 NaN。解决方法有三个我全用上了第一开 loss scaling。ms-swift 默认会开动态 loss scaling它会在反向传播前把 loss 放大让梯度值落在 fp16 的安全范围内更新前再缩回来。这个机制能解决大部分溢出问题。第二梯度裁剪 max_grad_norm 1.0。把梯度范数限制在 1.0 以内防止个别大梯度破坏训练。这个值可以调1.0 是比较保守的设置如果训练稳定可以放宽到 2.0 或 5.0。第三降低学习率。我一开始用 2e-4后来降到 1e-4溢出频率明显降低。学习率大梯度更新幅度大更容易溢出。如果这三个都做了还是 NaN那可能是数据里有异常样本比如图像损坏或者文本里有特殊字符需要检查数据。5.2 显存不足OOM的排查思路OOM 是 11GB 卡上的常客。我整理了一个排查顺序排查项检查方法解决方向batch size是否大于 1降到 1用梯度累积max_length是否超过 2048降低序列长度图像分辨率视觉 token 是否过多缩小图像gradient checkpointing是否开启开启dataloader worker是否过多占内存适当减少其他进程nvidia-smi 查看杀掉无关进程有一次我 OOM 是因为忘了关 jupyter notebook它占了几百 MB 显存。所以训练前一定要nvidia-smi确认显存是干净的。还有一个隐蔽的 OOM 原因验证阶段。训练时显存 9.6GB验证时如果 batch size 没调小或者验证数据里有特别长的样本也会 OOM。我的做法是验证时 batch size 也设 1并且限制验证样本数量。5.3 训练速度慢的优化技巧速度慢是多方面原因我按收益从高到低排第一增加 dataloader_num_workers。从 2 加到 4GPU 利用率从 75% 提到 88%速度提升约 15%。图像预处理是瓶颈多开 worker 能缓解。第二用更快的图像解码库。默认的 PIL 解码比较慢换成 opencv 或者 turbojpeg 能快一些。ms-swift 支持配置图像处理器可以指定后端。第三减少日志和保存频率。logging_steps 从 10 改成 50save_steps 从 200 改成 500减少 IO 开销。这个提升不大但积少成多。第四关掉不必要的验证。如果只是跑通流程可以先把验证关掉训练完再单独验证。验证会占用额外时间。第五考虑用 DeepSpeed ZeRO。不过 2080Ti 单卡用 ZeRO 收益有限主要是多卡场景有用这里不展开。5.4 LoRA 效果不理想的调整方向如果训完之后发现模型效果不好比如回答质量差、视觉理解不准可以从这几个方向调提高 rank。rank8 可能表达能力不够加到 16 或 32 试试。参数量增加但显存开销依然可控。调整 lora_alpha。alpha 和 rank 的比例影响 LoRA 更新的强度默认 2 倍可以试试 1 倍或 4 倍。换注入位置。如果只挂了注意力层加上 FFN 层如果全挂了还不行可能是数据问题。增加训练数据。QLoRA 参数量少需要更多数据才能学好。如果数据只有几百条效果很难保证至少上千条起步。调整学习率和 epoch。学习率太大导致不收敛太小导致学不动。epoch 太少欠拟合太多过拟合。这两个参数需要根据 loss 曲线判断。6. 实验结论与后续扩展方向6.1 这次实验到底验证了什么回到开头那三个问题现在可以给出答案了。显存够不够够但很紧。9.6GB 峰值余量 1.4GBbatch size 只能开 1序列长度上限 2048图像分辨率需要控制。任何一项超了都会 OOM。速度怎么样单卡 2080Ti 跑 Qwen3-VL-4B QLoRAtoken 吞吐约 105 token/秒3 个 epoch 约 10.5 小时。这个速度做小规模实验可以大规模训练不现实。效果行不行loss 收敛正常验证集 loss 0.68没有过拟合。QLoRA 4-bit 量化的精度损失在可接受范围内多模态任务的表现需要具体任务具体评估但从 loss 看是健康的。6.2 这套方案适合谁如果你手里有一张 11GB 显存的卡2080Ti、3060、4060Ti 等想入门多模态大模型微调这套方案是可行的。它不需要多卡不需要 A100成本很低。但你要接受速度慢、batch size 小、需要精细调参这些现实。如果你要做生产级的微调或者数据量很大建议还是上更大显存的卡或者用多卡。11GB 单卡的天花板就在这里再怎么优化也突破不了物理限制。6.3 后续可以尝试的扩展有几个方向我打算后续试试换用更小的视觉分辨率。把图像缩到 336视觉 token 减少显存和速度都会有改善看看效果损失多少。试试 DoRA。DoRA 是 LoRA 的改进版把权重更新分解成幅度和方向两部分据说效果更好。ms-swift 支持 DoRA可以对比一下。混合精度策略。虽然 2080Ti 不支持 bf16 计算但可以试试 fp16 计算加 fp32 存储的混合方案看能不能兼顾速度和稳定性。数据质量优化。这次用的数据比较粗糙后续可以清洗数据提高指令质量看看效果能提升多少。最后分享一个我在这次实验里体会最深的点在显存受限的场景下参数配置不是调出来的是算出来的。你得先算清楚每一项开销再决定 batch size、序列长度、图像分辨率这些参数而不是盲目试。算清楚了一次就能跑通算不清楚就是反复 OOM 反复调浪费时间。这个思路在 11GB 卡上尤其重要因为余量太小容错空间几乎没有。