一句话看懂：开发者张益达Yida把一个基于本地OCR加0.6B文本模型的自动记账App做到全程离线运行，通过后端更换、GPU启用和输出精简，把单张支付截图的处理时间从596秒压到约10秒。这说明端侧小模型在结构化提取类任务上已经具备可用性，前提是选型与工程优化到位。
事件核心：发生了什么
据掘金文章（2026年10月31日发布），该App读取支付截图，识别金额、商户和日期并自动记账，不联网，也不使用无障碍服务监听屏幕。作者最初尝试Qwen3-VL-4B视觉模型，但vision prefill单张需3到5分钟，受手机SoC算力限制，推算要15到40分钟，于是改为PP-OCRv5方案落地时实际用v4版OCR加0.6B文本模型输出JSON。
优化分四轮：编译参数调整使耗时从596秒降至208秒；后端从llama.cpp换成LiteRT-LM的dynamic INT8，降至41.9秒；启用OpenCL GPU后到17.4秒；将输出契约从7字段砍到4字段并让引擎常驻，稳定在8.4到11秒。作者称30张真实截图的质量闸门全程通过，金额识别96.7%，日期100%。
为什么重要
支付截图包含余额、订单号乃至卡号后四位，上传云端意味着隐私暴露，这使得自动记账长期由云端OCR或系统级监听两条路线主导。该案例提供的第三条路径是：把OCR和约0.6B的小模型都放在手机本地，只在确认识别结果时让用户介入。它同时给出一个反直觉结论：在文本转JSON这类结构化任务上，Qwen3-0.6B在同一测试集上准确率高于1.7B版本，且耗时只有约三分之一。
对用户/开发者/创作者的影响
对开发者而言，文中列出的三个静默失败值得注意：漏写uses-native-library声明会让OpenCL静默回退到CPU，AAR缺一个GPU采样器so会导致输出稳定截断在145字符，INT4量化在LiteRT-LM 0.17.0上语法掩码失效。这些坑的共同点是“不报错、只是慢或错”，说明端侧部署的复杂度主要在运行时和打包链路。对用户，这类方案意味着更少的隐私让步；对创业者，验证过的需求加可控的端侧成本，是一条可评估的产品路线。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是App是否正式上线、在哪些机型上实测通过；二是LiteRT-LM后续版本能否修复INT4掩码问题，让4bit方案重新可用；三是热节流对耗时的实际波动，作者自述同一配置在208到389秒间浮动，稳态数字依赖测试口径，复现需参考其条件。目前公开信息仅为作者个人项目记录，并非产品发布公告。
来源：juejin
