导读Vela3-fast-vision 已在 RK3588S 上跑通 RKNN 推理。本次固定360条文档分类验证中，最终 FP16 版答对328条，三单核并发吞吐约0.453张/秒，比原 FP16 版提高约12.5%。从原生对齐、INT8 尝试到等价算子改写，这次部署的重点，是弄清每一步改变了什么，以及结果能支持怎样的使用判断。
先交代结果：模型能跑，但速度要看具体口径
上一篇在「多模态视觉」介绍了 Vela3-fast-vision 的文档分类与电脑端 GPU 部署。这次，我把同一个决策分支搬到鲁班猫 LubanCat-4IO：RK3588S、16GB 内存、Ubuntu 24.04，RKNN Toolkit2、Lite2 和运行库均为2.5.0。
Vela3-fast-vision 实测：从文档分类到 GPU 部署
Vela3 在这里承担的任务很明确：输入图片和问题，再从我们提供的候选中选答案。本次固定询问文档类型，候选为发票、邮件、表格等12类；部署的是约2.54亿参数的决策分支，没有把整个多任务模型包一起搬上板。
最终版在固定360条记录中答对328条，准确率91.11%。三个工作进程各占一个 NPU 核心，每个进程一次处理一张原图，整批用时约794秒，吞吐0.453张/秒。这个数包含图像预处理、逐图审计和调度开销，排除模型初始化与每个分支3次预热；并发时每张图片自身的平均端到端耗时约6.51秒。系统同时处理三张，持续出结果的间隔才会小于单张耗时。
这批数据来自 RVL-CDIP-N，每类30条，按图片字节去重后是355张，不是官方完整评测集。它适合检查同一输入在不同部署阶段的变化，不能据此宣称复现了官方成绩。
第一关，是让参照保持一致
工具链的分工先要划清：电脑上的 Toolkit2 负责把模型转换成 RKNN；板子上的 Lite2 提供 Python 调用入口，底层运行库与驱动负责执行。CPU 仍要读图、准备输入和处理输出，不能把整条程序都叫作“NPU 推理”。瑞芯微官方仓库也明确区分了这些职责。
我先固定官方权重和原生预处理，确认原生 FP32 参照，再对照导出的 ONNX，最后检查板端 RKNN。这里的 FP32 是参照模型使用的计算精度，不是 x86 的别名。
一个容易忽略的地方是切片。原生预处理会根据图片形成3张或5张512×512切片，因此本次静态导出保留了两个形状版本。它们使用同一套权重，区别在输入形状和编译产物；每次仍输入一张原图，不是一次输入三张或五张独立照片。
这也限定了当前入口：问题、12个候选及已验证的输入形状都固定在导出方案内。换候选、换问题或遇到其他形状，需要重新检查导出和验收，不能把它当成任意文本都能直接调用的完整原生接口。
原生 FP32 答对326/360。最初 RKNN FP16 答对328/360，但有3条记录的分类与原生不同，严格的逐条分类和最大概率差门槛均未通过。我最后采用的是“允许少量浮点差异，重点比较准确率与速度”的标准，而不是把正确数接近解释为完全一致。
INT8 跑得更快，这次却没成为最终方案
接下来尝试的是 PTQ，也就是训练完成后量化。我从独立训练样本中准备120条校准数据，用来估计量化所需的数值范围，没有把这360条验证记录用于校准。
结果并不适合只报一个速度。
以上均为同板、三单核进程并发的独立完整轮次，使用相同输入与计时范围；量化实验主要针对占357条的5片分支，另外3条仍走 FP16 的3片分支。小幅速度差不作统计显著性判断。
直接 INT8 的效果明显不符合要求。量化会把浮点值映射到更少的离散数值，校准范围、舍入及多层误差传播都可能影响输出；本次没有继续逐层定位主因，因此不能认定就是某一个算子或校准样本量造成的。
自动混合精度则保留部分浮点计算，答对330条，不能说它“也不能用”。不过，相对原 FP16 的候选概率仍有明显变化，且没有比最终纯 FP16 更快。多答对两条也不足以证明普遍更准。综合本轮效果、速度与维护复杂度，我选择继续优化 FP16，保留混合精度结果作参照。
真正带来收益的，是换一种等价写法
原始视觉分支用16×16、步长16的卷积，把图像小块投影成特征。编译记录显示，这个操作被展开成先计算较大的中间网格，再抽取需要的位置。
我没有直接据此断定它是最大瓶颈，而是先做局部对照：将每块16×16像素重排到通道维度，再用原始权重重排后的1×1卷积做投影。它表达同一项计算，不增加训练，也不额外缩小图片。
这里改的是每张切片内部的 patch 投影，原图的3片、5片预处理保持不变。数学等价也不保证有限精度累加逐位相同，所以先检查高精度数值、真实输入和 ONNX，再验证完整 RKNN。
局部单核测试预热2次、测量6次，平均从约1.03秒降到0.098秒，但整图还有大量其他计算，不能把这个十倍收益套到全模型。完整360条验证给出的实际结果是：主优化版与原 RKNN FP16 的分类360/360一致，正确数仍为328，吞吐从0.403升到0.452张/秒，约提高12.3%。候选概率并非完全相同，最大差约0.0406。
随后把两个形状都按单核模式重新编译，调度仍保持三个单核进程。最终吞吐0.453张/秒，与主优化版接近；360条候选概率也与主优化版完全一致。两个形状文件合计约844MiB。在36次5片缓存输入短测中，三进程 RSS 合计采样峰值从约3708MiB 降到3399MiB，减少约8.3%；这是进程内存口径，不能当作整机全部内存占用。
NPU 接近满载，下一步该优化什么？
最终完整轮次采集到3921条负载样本，覆盖约794秒测试窗口。NPU 运行在1GHz，三个核心的平均忙碌率分别为91.9%、96.8%、96.8%，峰值都达到100%。
这说明三单核并发确实让设备持续工作，但忙碌率不等于标称 TOPS 的利用比例。换成一个上下文同时使用三核，主优化版在36次缓存输入短测中的平均推理时间约3.96秒，吞吐约0.253张/秒：它更关注单请求耗时，而三个单核进程更适合提高整批吞吐。这个短测不含图像读取、预处理和 softmax，不能与前面的完整处理时间直接混比。
我的判断是，当前 FP16 可以先作为部署基线：用于低频文档分类或后台分流，再用真实业务输入检查效果。若要求每秒处理多张，甚至摄像头逐帧识别，现有速度仍然不够，后续应评估模型规模和输入策略，而不是只追求负载数字更接近100%。
本次已经完成固定集的完整运行和独立单图入口验证，还没有据此宣称生产环境的长期稳定性通过。模型格式转换成功后，效果、速度与运行边界仍要分别验收；这也是我愿意先把这版 FP16 固定下来的原因。
这次 RK3588 部署的代码、环境配置和实验记录都已保留。如果你也准备在板子上复现，欢迎留言说明板卡型号和使用场景。后续我会根据实际需求，再把这部分整理成可复现的开源部署示例。
参考资料 上下滑动
•Vela3-fast-vision 官方模型卡与决策分支说明： https://huggingface.co/vllm-sr/vela3-fast-vision•瑞芯微 RKNN Toolkit2 官方说明与2.5.0版本记录： https://github.com/airockchip/rknn-toolkit2/blob/master/README.md•作者板端实测：固定360条验证、逐图配对、编译记录及负载采集；相关配置、文件身份、命令和原始输出已归档，供后续复核与整理
文章仅做学术分享，如有侵权请联系删除，非常感谢！