Qwen2-VL 视觉塔上板：版本锁定解决导出故障

dev.to · AI#边缘部署#模型转换#依赖兼容

Editor brief · 编辑速览

作者通过源码排查，将导出失败定位到 transformers 的视觉模块路径和注意力参数契约变化，最终锁定 4.51.3。Qwen2-VL-2B 视觉塔在 RK3588 上编码一张 392×392 图片耗时约 4.45 秒，该结果不代表完整多模态推理性能。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

Qwen2-VL-2B 的视觉编码部分，已经在 RK3588 开发板上跑出了约 4.45 秒的单张图片处理时间。但完整的多模态问答还没跑通，作者验证的是视觉塔，不是整个模型。

这份记录值得读的地方，是它把「官方示例为什么跑不起来」拆到了具体接口和版本，也明确划出了测试结果的边界。对于需要接入模型、维护推理环境的程序员，这比一句「端侧部署成功」更有参考价值。

Rockchip 官方 RKLLM 多模态示例的视觉导出脚本，依赖两个旧接口：通过 model.visual 访问视觉模块，并向每个 block 传入 rotary_pos_emb。

库升级后，这两个假设分别失效：

在 transformers 5.8.0 中，视觉模块移到了 .model.visual，脚本触发 AttributeError。
在 transformers 4.57.0 中，VisionAttention 会直接解包 position_embeddings，收到 None 就触发 TypeError。

作者最初尝试给 .visual 加别名，绕过了第一个错误，却依然卡在注意力模块的参数约定上。第一处报错消失，并不能证明整条调用链兼容。

他们通过阅读源码定位到 transformers 4.51.3：这个版本仍然保留 self.visual，而且当 position_embeddings 为 None 时，会根据 rotary_pos_emb 推导位置编码。这段兼容逻辑在 4.54 被移除了。

这次修复靠的是锁定兼容版本，而不是修改模型逻辑。

更麻烦的是，同一仓库里的量化与 embeddings 脚本，又按照 5.x 的 model.model.language_model 结构编写。视觉导出需要 4.x，另一部分脚本依赖 5.x。不能因为代码来自同一个官方仓库，就假设它们共享一套可用环境。

作者完成的链路是 Vision → ONNX → RKNN → 开发板运行。

第一步使用 transformers 4.51.3 和 torch 2.6.0，得到 53 MB 的 ONNX 图，以及一个 2.66 GB 的数据文件，并通过 onnx.checker。因此，53 MB 不能当成导出产物的总体积。

第二步通过 RKNN-Toolkit2 构建出 1.44 GB 的 RKNN 模型。构建日志出现了 11 行 E RKNN，涉及 REGTASK 位宽警告，以及两条 Unknown op target: 0，但最终仍输出 rknn building done。

第三步在 RK3588 上使用 3 个核心运行，输入为 demo.jpg：

这里的视觉塔，可以理解为把图片转换成后续语言模型能够使用的特征。约 4.45 秒测的是这个过程，模型加载时间另计。

构建时出现的 11 行错误级别日志，没有在板端运行时复现。这说明该产物在这次测试中可以执行，但还不能据此认定所有警告都无害，更不能证明输出特征的数值正确性。

语言部分仍未完成。用于导出完整 .rkllm 的 GPU 机器在下载过程中离线，完整问答测试因此还在等待。作者计划运行 24 道题，包括示例自带的 20 道 MMBench 题和自行添加的 4 道中文题，目前没有这些测试的结果。

作者最值得肯定的是测试口径：把「视觉塔能运行」和「整个 VLM 能问答」分开陈述。三个独立进程的耗时接近，支持这张图片在该配置下具有初步的重复性；原文称波动约为 1%，但样本仍然只有三次。

锁版本也确实适合这次问题。既然旧版本已经满足导出脚本的接口要求，固定环境比临时加别名更容易核查。

不过，「锁版本，不要补丁」仍是经验之谈，原文没有给出不同修复方案的对照数据。一般团队可能还要兼顾其他依赖；这个仓库自身就存在 4.x 与 5.x 的结构冲突。按转换阶段隔离环境，或者维护经过验证的适配代码，都可能是合理选择。

另一个缺口是正确性验证。onnx.checker 通过、板端没有 E RKNN，分别说明图检查通过、运行没有出现这类日志。原文没有提供转换前后的输出误差对比，也没有完整问答准确率。现阶段可以确认链路跑到了视觉特征输出，模型效果还需要后续证据。