Qwen2.5-VL与LoRA驱动的机械臂视觉控制微调实践

把一个大模型微调成机械臂的“眼睛加大脑”，听起来像科幻片，但最近我用两周时间，基于 Qwen2.5 视觉语言模型和 LoRA 参数高效微调方法，做了一套能驱动仿真机械臂完成抓取、搬运任务的视觉控制系统。整个过程没有真实机器人、没有大集群，一块消费级显卡就能完整跑通。这篇文章把这个项目的完整链路一次讲清楚：为什么选这套技术路线、数据怎么造、LoRA 参数怎么配、闭环推理怎么调、最后效果和踩坑都在哪里。不管你是做机器人方向的学生，还是想试试多模态模型控制实物的工程师，这篇文章应该能帮你省掉至少一周的摸索时间。

1. 项目整体拆解：为什么选 Qwen2.5-VL + LoRA 这套组合

1.1 “视觉控制仿真机械臂”到底是个什么任务

先说清楚我做的这个“视觉控制”具体指什么。它不是让模型去写一串机械臂的正逆运动学公式，也不是用某张照片做一次性的目标识别，而是一个实时的感知-决策-执行闭环：机械臂上方装一个主视角摄像头，末端再装一个腕部摄像头，每个控制周期先拍图，把图像、当前关节角度、一句自然语言指令拼成多模态输入，喂给模型，模型输出下一步动作，仿真器执行动作，然后拍照进入下一个周期。

我用来验收的任务是三类：抓取指定物体放到指定区域、把某个颜色的方块推到目标点、把物体从 A 区搬到 B 区。任务本身不复杂，但它要求模型同时具备三个能力：看懂画面里“谁是谁”、听懂指令里“要做什么”、知道机械臂“下一步该怎么动”。这三个能力刚好是纯语言模型给不了的——它没有视觉通道；也刚好是传统视觉伺服最头疼的——换一个物体、换一句说法，规则就要重写。所以这个项目本质上是在验证一件事：一个通用的多模态大模型，能不能通过轻量微调，被“压”成一个可用的机械臂策略。

模型的输入输出长度都不长，单步推理只生成几十个 token，但整条链路涉及图像编码、指令理解、动作生成、闭环执行，任何一个环节断了，机械臂就会停在原地或者乱抖。项目做到后期我才意识到，真正的工作量不在训练，而在把“会生成文字的模型”变成“会生成的指令”这件事上。

1.2 对比几条技术路线，我最后怎么定的

做之前我认真对比过四条路线，这里直接说结论，省得大家重复踩坑。

传统视觉伺服加规则：需要标定相机内外参、手写颜色阈值或特征提取器、再设计一套控制律。单个任务能跑，但换场景、换光照基本要返工。我这次要的是“一个模型管多个指令”，它撑不住。

专门的端到端策略网络：用卷积网络或小型 transformer 做行为克隆，数据需求小、推理快，但语义理解弱。你说“把红色方块放到那个盘子里”，它还得单独训练一个指令编码器，工程上绕一圈。

直接用 VLM 做零样本控制：把 Qwen2.5-VL 原样接上机械臂，初测时我发现它更擅长“用文字描述自己会做什么”，而不是真的输出动作。让它输出下一个动作，它给你回一段完整的任务计划，然后说“已完成”。零样本这条路线基本不可用，后面会有详细对比。

微调 VLM 作为策略：保留模型的视觉理解和指令理解能力，通过微调教会它输出“动作格式的文本”。这是最终采用的路线，核心思路很简单：模型本来就会看图、会听指令，我只需要用数据告诉它“看完图之后，接下来该输出什么格式的数字”。

模型选择上我用了 Qwen2.5 系列的视觉语言版本 Qwen2.5-VL。选它而不是其他模型，主要看中四点：开放权重，可以本地部署微调；动态分辨率处理图像，对仿真器里不同尺寸的摄像头画面适应好；中文指令理解扎实，我的任务指令都是中文，可以直接用原始表达，不需要翻译成英文再喂；模型尺寸覆盖 3B 到 7B，理性预算内能完整跑通。

1.3 LoRA 在这里解决的三个实际问题

为什么非要 LoRA，而不是全参数微调？三个字：没必要。LoRA 的核心是低秩分解：把预训练权重 W 保持冻结，只训练两个低秩矩阵 A 和 B，新的权重写成 W' = W + BA。A 的维度是 r×k，B 的维度是 d×r，这里的 r 通常只有 16 到 64，比原始矩阵的尺寸小了几个数量级。打个比方：全参数微调是把整栋楼的承重墙都拆了重新砌，LoRA 则是在原有墙体外面加一套模块化的外挂龙骨，不破坏原有结构，但能按新需求重新布置内部空间。机械臂控制这个任务，本质上是从“视觉特征加指令语义”到“少量动作维度”的映射，容量需求并不大，低秩适配完全够用。

实际收益也很直接。第一，显存开销降了一个量级，7B 模型用 4bit 基座加 LoRA 可以在一张 24GB 的显卡上跑微调，全参数微调同样的模型没有双卡基本不用想。第二，检查点文件很小，LoRA 权重通常只有几十到一两百 MB，我可以同时保存五个实验版本随便切换，这在做超参对比时非常爽。第三，冻结基座意味着模型原本的语言能力和视觉能力不会被“洗掉”，这对保留指令理解至关重要——我后面专门做过实验，全量微调的模型在动作任务上分数高，但换个说法描述同一个任务就听不懂了。

仿真环境我选的是开源物理仿真引擎加内置渲染器，具体用哪家不强求，关键要有 Python 接口、能渲染 RGB 图像、能读取关节角度。选仿真的理由也很务实：真实机械臂加相机标定，光硬件就够折腾两周，而且微调初期模型大概率乱动，仿真里撞坏了重启就行，真实环境里是实打实的设备风险。

2. 数据生产流水线：从仿真轨迹到可训练样本

2.1 仿真环境里的“专家示范”是怎么采的

微调的第一道坎是数据。我的方案是“脚本专家采集示范轨迹”：在仿真环境里用逆运动学求解器写一个专家策略，给定物体的目标位置，专家自动规划末端朝向、移动到抓取点、闭合夹爪、搬运到目标区域。这套专家策略写得粗糙没关系，它的作用是“生产标签”，不是“最终部署”，只需要在仿真里稳定成功就行。

每个 episode 流程是这样的：随机生成一组物体位置和颜色，重置机械臂到一个随机初始姿态，然后专家以 10 赫兹的刷新率执行任务，每一步都记录三样东西：主相机 RGB 图像、机械臂当前关节角度、专家这一步输出的动作增量。动作增量我按如下格式记录：末端执行器在三个方向上的位移增量、夹爪的开合状态。这样记录的好处是，模型学的是“基于当前画面和当前状态，下一步相对动多少”，而不是绝对坐标。绝对坐标在部署时受标定误差影响极大，相对增量则鲁棒得多。

专家跑出来的轨迹未必是“好看”的。如果专家只会走直线，数据里就全是直线轨迹，模型微调完也会只走直线，一遇到障碍就傻眼。所以我给专家加了两种扰动：一是在每个控制周期给目标点加一个随时间变化的小偏移，让轨迹带一点弧线；二是对动作增量加高斯噪声，让同一任务在不同 episode 里长得不一样。整个过程我用随机种子控制，保证同样配置下可以完整复现，后面评估模型时才不会因为数据不可复现而说不清。

样本总量上，我最终采集了 6000 个 episode，每个约 20 到 40 步，总样本量接近 18 万条。听起来很多，但仿真环境里采集是自动跑的，基本睡一觉就采完了。真正花时间的是清洗数据：检查有没有物体飞出桌面、夹爪空抓、轨迹中途崩掉的 episode，这些坏样本如果不筛掉，模型会学到莫名其妙的动作模式。

2.2 样本格式与 prompt 模板

采集完原始轨迹，要把它组装成模型认识的对话格式。我的每个样本是一条多模态对话，system 提示词固定说明“你是一个机械臂控制器，根据图像和关节状态输出 JSON 动作”，user 消息里包含图片，以及一段带关节状态的文字描述，assistant 消息就是标准的动作 JSON。单个样本长这样：

{ "system": "你是仿真机械臂的视觉控制器。根据图像和当前关节角度，输出下一步动作，只输出JSON，不要解释。", "user": { "image": "episode_00012/frame_00041.jpg", "text": "当前关节角度: [-0.12, 0.43, 1.02, -0.87, 0.30, 0.05]。任务: 把红色正方体放到蓝色托盘里。" }, "assistant": "{\"gripper\": \"close\", \"dx\": 0.012, \"dy\": -0.004, \"dz\": 0.003}" }

这里有一个关键选择：动作格式用 JSON 文本而不是扩展词表。扩展词表的意思是给分词器新增 N 个“动作 token”，把连续的位移量离散成几百个桶，每个桶对应一个 token，模型输出这些 token，解码即动作。这个做法控制精度更高，但需要改词表和损失函数，工程复杂度上升不少。我这次的位移量本身是厘米级的数，JSON 里写成三位小数，模型在低温度下完全能学会精确输出，所以先用文本格式验证整条链路，等后续要上真机再加离散动作 token。

prompt 里为什么要把关节角度写进去？因为纯图像无法给出准确的机械臂自身状态，夹爪是否已经闭合、手臂是否处于奇异位形，这些信息靠眼睛看会有一两帧滞后。把关节角作为文本输入，模型就有了“本体感觉”，动作预测稳定性会好很多。

2.3 数据规模、平衡与增强

数据里我做了三件事。第一，混入了约 5% 的“保持不动”样本，也就是专家在某些状态下输出零位移和夹爪不动作，防止模型训练完养成“每帧都要动一下”的习惯。第二，保证三种任务的样本比例接近 1:1:1，避免模型偏向数据量大的任务。第三，做了轻量图像增强：亮度扰动、对比度扰动、少量高斯噪声，以及 2% 概率的相机位置微偏移。

这里要特别注意，不要做水平翻转这种会颠倒左右语义的增强。机械臂的左右和画面左右是对应的，翻转过模型就学乱——它以为自己在往左，实际上机械臂往右去了。增强的幅度也要克制，仿真环境的光照和纹理本来就稳定，过度增强会让模型忽略画面里的真实几何关系。我实测亮度扰动幅度超过 30% 之后，训练 loss 下降明显变慢，最后把扰动控制在正负 15% 以内。

3. LoRA 微调实战：一整套能跑通的超参与配置

3.1 模型加载与显存预算

训练脚本我基于开源社区的 transformer 工具链改的，核心思路是：加载 Qwen2.5-VL 基座，冻结视觉编码器和投影层，只在语言解码器上挂 LoRA。为什么冻结视觉塔？视觉编码器在预训练阶段已经见过海量自然图像，底层特征非常通用，仿真器渲染出来的图像虽然和自然照片有差距，但边缘、颜色、形状这些基础特征是可以迁移的。微调视觉塔的直接后果是过拟合仿真场景——模型学会了这个仿真器的特有渲染风格，换一个环境就废。

显存规划方面，我给出一个实测估算表，按单张显卡、bf16 精度计算：

如果你只有 12GB 显存，老老实实选 3B 加 4bit 量化，别硬上 7B。节省显存的三板斧是：冻结一切能冻结的模块、开梯度检查点、用混合精度训练。视觉塔冻结之后，反向传播根本不会走到那里，省下的显存非常可观。

3.2 LoRA 参数配方与 target modules

LoRA 的参数看起来就那几项——rank、alpha、dropout、target modules，但每一项都直接影响收敛质量。我最终用的配置是：

• rank = 32
• alpha = 64
• dropout = 0.05
• target modules：语言模型的 q_proj、k_proj、v_proj、o_proj，以及 MLP 的 gate_proj、up_proj、down_proj

rank 为什么取 32？控制任务的“可学习容量”不需要很大，rank 8 也能收敛，但收敛慢、损失略高；rank 64 以上在训练集上可以做到更低 loss，但会在仿真静态场景上过拟合得更快，rollout 成功率反而掉。32 是我在两个任务上试出来的平衡点。alpha 取 2 倍 rank 是社区常用比例，这个比例下更新幅度和预训练权重融合得比较自然。dropout 取 0.05，主要是防止模型对动作序列里的高频 token 组合过拟合。

target modules 我建议至少覆盖 attention 的四个投影矩阵。attention 是模型做视觉特征和指令语义交互的主要场所，控制策略里“看哪里、动哪里”的对应关系主要在这里建立。MLP 层加上之后收敛确实快一些，代价是 LoRA 权重从大约 60MB 涨到 150MB，训练时间增加约 20%。如果显存很紧张，先只调 attention 四个投影，效果不会差太多。

3.3 训练超参与 loss 观察

训练超参很多人喜欢直接抄，但最好理解一下每个参数在干什么。我用 AdamW 优化器，学习率 2e-4 配合余弦衰减，前 3% 的步数做线性 warmup。LoRA 的更新量本来就小，学习率太低（低于 5e-5）模型基本学不动；太高（超过 5e-4）容易出现动作输出格式乱掉。有效批量大小我控制在 64 条左右，单卡批次 4 加上 16 步梯度累积。图像 token 数量大，单卡批次堆不上去，梯度累积是把“名义批次”撑起来的常规手段。

18 万条样本跑一个 epoch 大约是 2800 步。3B 模型在 24GB 显卡上全程大约四到六小时，7B 用 4bit 基座大约十小时，属于完全可以接受的范畴。训练时我会同时看两个指标：整体 cross entropy loss，以及单独统计“动作 JSON 字段”的 loss——因为样本里大部分 token 是图像描述和指令文本，整体 loss 会掩盖动作字段的学习情况。动作字段 loss 降到 0.3 左右，基本就说明模型掌握了动作格式。

还有一个只可意会的经验：loss 不是唯一决策依据。我见过 loss 一路下降、rollout 成功率却不涨的情况，这时候继续 train 只会浪费电。正确做法是训练到 1/3 和 2/3 时各做一次快速评估，以评估结果决定是否提前停止。

4. 从训练到部署：闭环控制里的“最后一公里”

4.1 推理端的动作生成与解析

模型训练完，接入仿真闭环时才发现，推理端比训练端更考验工程能力。第一步要管住生成过程：temperature 设为 0，不做采样，让模型每次输出最确定的动作；max_new_tokens 限制在 64，防止模型在动作后面继续“编故事”；top_p 设为 1，不启用核采样。

第二步是容错式 JSON 解析。模型即使训练得再好，偶尔也会输出带注释的 JSON、字段顺序错乱、或者多一个引号。我的处理链路是这样：先用标准 JSON 解析，失败就用正则把大括号里的内容抠出来再试，还失败就返回“保持不动”。千万不要在解析失败时报错退出，那会让整个闭环断掉。单帧保持不动通常不会立刻导致失败，比乱动安全得多。

第三步是候选 token 过滤。我把动作字段允许出现的 token 限定在数字、引号、冒号、括号和固定属性名这个范围内，模型在解码时只能在白名单里选，非法输出从根本上被杜绝。这样做之后，JSON 格式崩塌率从我观察到的 8% 直接降到接近零，这是整个项目里性价比最高的一次工程优化。

4.2 控制频率、动作分块与同步

部署闭环时遇到一个现实问题：模型单步推理在消费级显卡上要 100 到 200 毫秒，而仿真器控制周期我原本设定在 50 毫秒。如果每一步都等模型输出，机械臂的视觉反馈就太慢，抓取动作会像慢动作。解决方案是动作分块：我让模型一次输出 4 个连续动作增量，推理一次管 4 个控制周期。训练数据也要同步改成“未来 4 步的动作序列”作为目标，模型在训练时就学会了预测短时段的运动趋势，推理时动作也天然更平滑。

动作分块的长度不是越长约好。分块太长，模型要预测很远未来的运动，误差累积变大，而且指令中途变化时反应不过来。我实验下来 4 到 8 步是甜点区间，再往上成功率反而下降。

整个闭环的伪代码大概长这样：

while not task_done: rgb_front = sim.capture("front_camera") rgb_wrist = sim.capture("wrist_camera") joints = sim.get_joint_positions() text = build_prompt(joints, instruction) action_chunk = model.generate(rgb_front, rgb_wrist, text) for action in action_chunk: sim.step(action) if sim.check_collision(): break

这里图像拼接很关键。我把主视角和腕部视角两张图拼成一张再送进模型，Qwen2.5-VL 支持多图输入，但从工程上拼图更好管理数据尺寸。主视角负责“任务级感知”，腕部视角负责“抓取级反馈”，两者缺一不可。腕部相机离物体近，能看到夹爪和物体之间的毫米级间隙，这是主视角给不了的。

4.3 评估指标与验收方式

模型训出来到底行不行，不能靠肉眼“看着挺像样”拍板。我把评估设计成固定场景加随机扰动：五个任务，每任务固定 10 组基础场景，每组场景加 3 个随机种子，共 150 次 rollout。成功率定义为物体最终落在目标区域且机械臂没有发生碰撞。

另外记录三个辅助指标：平均完成步数、动作平滑度（动作增量的绝对值累计）、卡死率（连续 20 步动作增量总和小于阈值）。这三个指标能帮你区分“真的会干活”和“运气好蒙对了”。我见过一种情况：成功率看着还行，但平均步数比专家多了三倍，机械臂在空中反复比划——这种模型的部署价值就很低。

评估还要注意一点：必须用训练时没见过的随机种子。仿真器里可以无限生成新场景，如果评估场景和训练场景重叠，成功率会虚高 15 到 20 个百分点，这在社区里是常见的“只见分数不见效果”的坑。我会专门维护一份评估种子列表，训练和验证完全隔离。

5. 踩坑与效果对比：微调前后到底差多少

5.1 四个高频翻车点及对应修法

这个项目踩的坑不少，选四个最典型的写下来，每个都是花了一到两天才定位到根因的。

第一个坑是开环训练与闭环推理的分布漂移。训练数据来自专家脚本，专家永远不会输出烂动作，但推理时模型自己输出的动作总有偏差，一步偏一点，几步之后就进入训练数据里完全没见过的状态，模型就懵了。修法是“污染数据”：训练时给专家动作加 10% 左右的高斯噪声，再额外生成 20% 的“错误状态恢复轨迹”——让机械臂从偏离目标的位置开始，专家把它救回来。模型见过烂状态，推理时才不会在相同处境下宕机。

第二个坑是 JSON 格式崩塌。训练中期我发现模型偶尔会在动作 JSON 前面输出“好的，我来分析一下”之类的废话，或者把布尔值写成字符串。温度调成 0 之后好转，但根治靠两招：训练数据里刻意加入 1% 的错误回复样本并标记为“修正回复”，推理端再配一个候选 token 过滤器。这套组合拳下来，格式崩塌率基本清零。

第三个坑是背景过拟合。我的主视角摄像头位置固定，仿真背景里有个高对比度标记物，模型慢慢学会了“看到标记物偏移就知道机械臂往哪走了”，而不是真正看物体的位置。这导致我换一个相机角度后成功率断崖下跌。修法是随机化相机位置和光照方向，让模型必须靠物体本身的位置信息做判断。

第四个坑是语言能力遗忘。当我用纯任务数据训练时，模型为了专注输出动作格式，对指令文本的解析能力会下降，具体表现是换一种说法描述同一个任务就听不懂。修法是在训练集里混入 2% 的通用指令对话样本，让模型在做机器人的同时“不忘本”。这个比例要控制好，加多了动作任务学不扎实，加少了语言能力救不回来。

5.2 微调前后的效果对照

最终我以 3B 模型为主力，在统一场景下跑了一组对比：

原始模型的表现特别有代表性：它不是“不会”，而是“以为自己会”。让它输出动作，它会输出大段文字描述自己的计划，然后说“已完成”。这正是不能用零样本 VLM 直接控制机械臂的根本原因——模型缺少把视觉观察映射成具体低层动作的监督信号，光有世界知识是不够的。

微调后 78% 到 86% 的成功率，在仿真抓取任务里不算惊艳，因为专家脚本本身可能达到 95% 以上。但这个结果的意义在于：同一个模型，只换了 LoRA 权重，就能在不同指令之间切换行为模式，这是传统策略网络很难做到的灵活性。

5.3 还能继续扩展的方向

这个项目做完之后，我觉得值得继续深入的至少有三个方向。第一个是多视角融合的系统化，目前我是简单拼图，后续可以让模型分别处理两路图像再交叉注意力融合，抓取稳定性还能提。第二个是更细粒度的动作表示，把位移离散成动作 token 并加入词表，控制精度会从厘米级提升到毫米级，这是上真机之前必须做的改造。第三个是领域随机化，仿真到真实环境有巨大的 sim-to-real gap，光照、纹理、相机畸变都要在训练时随机化，LoRA 低容量反而是过拟合风险更低的优势，可以大胆加扰动。

最后说点个人体会。这个项目最颠覆我认知的一点是，大模型的“世界知识”并不会自动变成“操作能力”，它需要一条非常具体的监督路径，把视觉语义牵引到动作空间里去。而 LoRA 恰恰提供了这条路径的最小成本版本——你不需要几十万预算去训练一个机器人基础模型，只需要把预训练模型的语义理解和动作映射能力用低秩矩阵“重定向”一下。如果你也想试，我建议从最简单的单任务、单相机开始，先跑通闭环，再慢慢加指令、加视角、加动作分块。仿真环境的另一个好处是，所有数据、所有随机种子都是可复现的，你可以非常清晰地看到每一次改动到底是在变好还是变坏。