如何在 Rubik Pi 上使用视觉语言模型进行屏幕抓取

时间：2026-06-09 17:47:53

关键字： Rubik Pi 物联网边缘计算

[导读]走进任何一家工厂的车间(或想象波士顿动力的Spot机器人为你完成)，你都会看到那些没有数据传输功能的传统LCD屏幕和模拟仪表，这会限制你的物联网应用管道。提取这些数据通常意味着需要更换昂贵的硬件。然而，正如TinyML领域的先驱皮特·沃登所指出的，有一种更快、更便宜的替代方案：用低功耗摄像头对现有的显示屏进行拍摄，并在本地处理图像数据。

走进任何一家工厂的车间(或想象波士顿动力的Spot机器人为你完成)，你都会看到那些没有数据传输功能的传统LCD屏幕和模拟仪表，这会限制你的物联网应用管道。提取这些数据通常意味着需要更换昂贵的硬件。然而，正如TinyML领域的先驱皮特·沃登所指出的，有一种更快、更便宜的替代方案：用低功耗摄像头对现有的显示屏进行拍摄，并在本地处理图像数据。

在之前的项目中，我们在OpenMV板上搭建了一个TinyML流水线，用于读取预付费电表。虽然功能正常，但实现过程十分繁琐。为了使阈值检测有效，必须将屏幕与电表外壳分离开来，这迫使我们采用一种脆弱的基于规则的边界框方法，并硬编码像素坐标。随后，我们还不得不费力地对10个类别中的3,260张图像进行手动标注，完成相机标定，并调试感兴趣区域(ROI)。

该系统在测试中达到了99.8%的准确率，但仍需要专用设备、一个WiFi屏蔽罩，并希望光照条件不会发生变化。夜间拍摄完全不在其适用范围内。这正是传统计算机视觉屏幕抓取方案的极限，而由于该方案难以适应夜间环境，更不用说其他应用场景，因此你实现这一目标的速度远超预期。

进入视觉-语言模型时代。现在，你无需再为脆弱的OCR脚本而烦恼，只需使用视觉问答功能，直接向本地AI代理提问：“读取此显示屏上的锅炉压力，并返回JSON格式输出。” 视觉语言模型对眩光、奇怪角度和脏污镜头具有出色的抗干扰能力，这正是机器人在工厂检查时可能遇到的环境条件，因此它们是大规模从现有系统中提取数据的理想升级方案。但有一个问题：视觉语言模型会消耗大量内存，将这类生成式AI从云端拖拽到边缘硬件上，实现完全离线运行，这才是真正的工程挑战所在。而这正是我们接下来要解决的问题。

边缘计算墙

要理解为何VLM(视觉语言模型)尚未全面取代设施审计，就必须考虑其局限性。流行的轻量级多模态模型虽然非常高效，但众所周知，它们对内存占用极高。在推理过程中，仅需存储权重和KV缓存就需要庞大的内存资源。你无法将一个数十亿参数的模型直接部署到普通的边缘设备上，期望它能解析图像。虽然可以默认使用云端API，但流式传输数GB的敏感工厂图像会带来严重的安全风险，并且可能高度依赖于并不存在的工业Wi-Fi网络。大多数情况下，智能处理必须严格本地完成。

Rubik Pi 3 for the Win

这正是Thundercomm Rubik Pi 3解决瓶颈的关键所在。该设备搭载了6纳米高通Dragonwing™ QCS6490 SoC，专为突破边缘计算的性能壁垒而设计。在本次VQA项目中，最关键的规格是其8GB LPDDR4x内存。这一内存容量恰好为我们提供了充足的空间，可将高度量化的小型视觉模型完全加载到内存中，并实现本地推理，完全无需依赖云端服务。该板卡配备Hexagon NPU，提供高达12 TOPS的专用AI计算能力，同时集成Adreno 643L GPU，可通过OpenCL进行访问。相比同类产品，Rubik Pi 3的价格相对较低，使其成为以往需要更高成本硬件的边缘AI项目的一站式入门选择。

型号：Liquid AI LFM2.0-VL-1.6B

Liquid Foundation 模型在设计上就具备了架构上的高效性。LFM 系列从零开始构建，专为受限的硬件部署而设计，而非事后从数据中心模型中缩小而来。Liquid AI 的专家团队建议采用 Q4_K_M 量化方式，在质量和体积之间取得平衡，可将模型权重压缩至不足 1 GB。

LFM2.0-VL 之所以特别适合屏幕抓取任务，主要得益于一系列针对该任务至关重要的能力组合。该模型在视觉基础方面对OCR具有很强的适应性，其遵循指令的能力足够精准，能够确保每次推理输出都可靠地生成干净的JSON格式。更重要的是，在实验中我们证明了它对低分辨率输入具有良好的鲁棒性。即使大幅缩小图像尺寸，读取准确率几乎不受影响，这一点在边缘设备上尤为重要，因为视觉编码器中的每个token都伴随着内存和延迟成本。

推理引擎：llama.cpp

为了实现可靠的边缘基础设施，推理引擎需要轻量级。依赖Python的框架会带来过多开销。本项目使用llama.cpp，其中llama-server作为与OpenAI兼容的API端点，libmtmd用于多模态处理。运行后，llama-server提供一个标准的/v1/chat/completions端点，任何HTTP客户端均可直接调用。图像以Base64编码形式，与文本提示一同作为消息内容数组的一部分发送。

设置说明：要在 Rubik Pi 3 上启用 GPU 转发，必须使用 OpenCL 后端编译 llama.cpp(-DGGML_OPENCL=ON)。Thundercomm 官方构建指南已对此进行了完整说明，包括 OpenCL 头文件和 ICD 加载器的依赖项。请通过检查启动日志中的 ggml_opencl：所选平台为“QUALCOMM Snapdragon(TM)”来确认 OpenCL 路径是否已启用。

调优以实现可靠推理

要在 Rubik Pi 3 上使用 llama.cpp 运行 VLM 且避免 OOM 错误，必须考虑以下标志参数：

上下文大小(-c 1024)：这是最重要的标志。对于VQA任务，你发送一张图像并提出一个问题，因此不需要128K个上下文标记。将上下文大小限制在4096后，KV缓存从数吉字节降至约200-400MB。

模型量化(Q8_0 至 Q4_K_M)：Q8_0 权重约为 1.25GB。降至 Q4_K_M 后，权重将显著低于 1GB，大幅释放内存空间，同时比纯 Q4_0 提供更优的质量。

GPU 离线卸载(-ngl 99)：此标志指示 llama.cpp 将尽可能多的模型层卸载到硬件加速器上。我们将其设置为 99。如果之前提到的 OpenCL 标志已启用，那么 -ngl 99 就会将繁重的矩阵乘法运算卸载至板载集成的 Adreno GPU 上，根据 Thundercomm 的基准测试，可实现约 33% 的性能提升。