你拍下菜单、路牌或电脑界面，让手机里的 AI 直接读字、找按钮，不把图片上传服务器——这正是 LFM2.5-VL-3B 想解决的问题。它是一款约 3B 参数的视觉语言模型（VLM，即同时理解图片和文字的模型）。值得关注的不是又多了一张跑分表，而是它已经在真实手机上运行。只是“能跑”和“好用”之间，仍隔着两分多钟的等待。
本文的规格与性能主要来自 Liquid AI 官方模型卡；iPhone 演示和 ScreenSpot-v2 数据来自 atomic.chat 创始人的单次 Reddit 实测，后者同时带有产品推广动机。
它怎样缩进手机？
LFM2.5-VL-3B 面向端侧部署，也就是让模型直接在手机或电脑上推理，而非把素材交给云端。这样可以离线使用，也能让数据留在本地；代价是必须适应终端有限的算力、内存和耗电条件。
模型以 LFM2.5-2.6B 作为语言骨干，再配上约 400M 参数的 SigLIP2 NaFlex 视觉编码器。视觉编码器相当于模型的“眼睛”：先把图片转成语言模型能处理的数值表示。两部分合计约 3.1B 参数，标题里的“3B”是取整。
据 Liquid AI 官方模型卡，模型推理时占用约 3GB、低于 3.3GB 内存；atomic.chat 创始人则称模型“重约2GB”。这两个数字并不冲突：前者指运行时内存，后者很可能指经过压缩后的模型文件大小，不能混为一个指标。
它不只会说“图里有什么”
这款模型支持整页 OCR——从图片中读出文字——并能保留版面标注。它还强化了 grounding，也就是把问题里的对象对应到画面中的具体位置。例如，你不只问“屏幕上有没有提交按钮”，还可以让模型指出按钮在哪里。这类能力适合读取文档、理解界面，或按自然语言寻找物体。
官方给出的上下文长度为 32,768 tokens。token 是模型切分文字后的基本单位，不完全等同于字或词。模型词表大小为 128,000，并支持英语、中文、阿拉伯语等16种语言。
真机演示比峰值速度更诚实
官方称，模型在 Apple M5 Max 上可达到每秒228个 token，在 AMD Ryzen AI Max+ 395 上为116个，在 Galaxy S26 Ultra 上为20个。不过官方没有披露量化方式、推理框架、提示长度、功耗等完整条件，因此这些数字不适合直接横向比较，也不能证明手机端普遍已有实时体验。
更有参照意义的是一次具体演示。atomic.chat 创始人在 Reddit 展示了模型通过其应用在 iPhone 17 本地分析一张玩具照片。模型最终认出这是《Minecraft》的 Steve，并给出细节描述，但耗时约2分31秒。这只是单一样例，不能证明模型普遍识图准确；它却清楚展示了端侧多模态目前的位置：模型确实住进了手机，但响应速度还不像日常工具。
同一实测者称，模型在 ScreenSpot-v2 desktop 上的分数从上一代的6升至78.7。该测试关注界面元素定位，这一跃升与模型强化 grounding 的方向一致。但该说法没有附评测配置或原始结果，暂时只能视为单一来源的效果报告。
为什么值得关注
这次进展的意义不在于3B模型刷新了某项纪录，而在于“手机本地看图、读字、找位置”已经从设想变成可操作的真实演示。它为离线菜单翻译、路牌识别、扫描文档转文字等应用提供了更具体的技术起点。
同时，Liquid AI 明确把它定位为单轮、高吞吐、低延迟任务，而不推荐用于长上下文、重推理、视觉网页设计或高技术性蓝图问答。换句话说，它更像一件小而专用的端侧工具，不是缩小版的全能助手。
局限与未知
- 官方速度缺少统一测试条件，“可在手机运行”不等于普遍实时可用。
- Steve 识别和 ScreenSpot-v2 跃升均来自同一名应用创始人的材料，尚缺独立复现。
- 官方宣称 OCR、grounding 等能力有所改善，但现有材料没有提供足够的独立实测来判断稳定性。