Liquid AI把3B视觉模型塞向端侧

Liquid AI 近日发布 LFM2.5-VL-3B，将新一代 LFM2.5 架构扩展到约 30 亿参数的视觉语言模型，并把目标直接对准手机、PC、机器人和其他边缘设备上的本地视觉推理。截至 2026 年 8 月 12 日，模型发布信息已经出现在 Liquid AI 的 Hugging Face 官方博客中。

**LFM2.5-VL-3B 是一款面向端侧部署的 3B 级视觉语言模型。**它接收图片与文本输入，输出文字结果，可用于看图问答、文档理解、界面识别、多图分析和视觉代理，而不是只做图片分类或目标检测。

这次上新最值得注意的地方并不是“又一个 3B 模型”，而是 Liquid AI 正在把视觉能力填进端侧模型最实用的参数区间。450M 级模型足够轻，但复杂文档、多对象关系和长指令往往容易丢信息；7B 以上模型质量更稳，却会明显抬高内存、功耗和首字延迟。3B 恰好卡在两者之间，是当前消费级设备仍有机会直接运行、同时又能承担严肃视觉任务的工程甜点位。

新模型补上了 LFM2.5 视觉家族的中间档

**LFM2.5 是 Liquid AI 面向设备端智能优化的一代基础模型架构。**这一代产品强调指令遵循、低内存占用和 CPU 推理效率，目标不是在云端堆出最大模型，而是让模型在断网、隐私敏感或延迟敏感的环境中持续工作。

Liquid AI 的路线已经相当清晰。公司在 2025 年先后发布 LFM2-VL 系列和第一代 LFM2-VL-3B，随后推出 LFM2.5；进入 2026 年后，又陆续增加 350M 文本模型、1.2B Thinking、450M 视觉模型以及采用混合专家架构的 8B-A1B。此次 LFM2.5-VL-3B 相当于把经过更新的 LFM2.5 能力带回更实用的 3B 视觉档位。

| 模型 | 参数规模 | 模态与定位 | 更适合的场景 | 主要取舍 | |---|---:|---|---|---| | LFM2.5-VL-450M | 4.5 亿 | 超轻量视觉语言模型 | 摄像头事件理解、简单表单抽取、低功耗设备 | 内存最低，但复杂推理能力有限 | | LFM2.5-VL-3B | 约 30 亿 | 中型端侧视觉语言模型 | 文档、截图、多图理解、机器人视觉代理 | 质量更高，但算力和内存需求高于 450M | | LFM2-VL-3B | 约 30 亿 | 上一代 3B 视觉语言模型 | 通用端侧图文理解 | 架构较早，新模型主打更好的质量与速度平衡 | | LFM2.5-1.2B-Thinking | 12 亿 | 文本推理模型，并非 VLM | 本地规划、文本推理、工具调用决策 | 不直接处理图片 | | LFM2.5-8B-A1B | 总参数约 80 亿、激活约 10 亿 | 混合专家端侧模型 | 更复杂的本地代理工作流 | 总模型体积更大，部署链路更复杂 |

**这张表不能被理解为统一基准下的性能排名。**视觉模型、文本推理模型和混合专家模型承担的任务不同，参数总量也不等于每个 token 实际参与计算的参数量；其中 8B-A1B 的“A1B”表示推理时约有 10 亿参数被激活，与稠密 3B 模型不能只按总参数直接比较。

端侧的关键不是模型能不能跑，而是能不能及时跑完

**端侧推理是指模型主要在用户本地设备上完成计算，而不是把图片持续上传到远程服务器。**它带来三项直接收益：数据不必离开设备、网络断开时仍能工作、交互延迟不再完全受公网和云端排队影响。

视觉模型在端侧比纯文本模型更难部署，因为一张图片会先被视觉编码器切分并压缩成一串视觉 token，再交给语言模型理解。视觉 token 越多，模型能保留的细节通常越丰富，但预填充计算、峰值内存和响应时间也会随之增加。高分辨率票据、密集表格和手机长截图尤其容易把这一问题放大。

**视觉 token 是视觉编码器交给语言模型的图像特征单元。**它可以近似理解为模型阅读图片时生成的一组“视觉词”，但每个单元代表的是局部图像特征，而不是自然语言里的一个字或一个词。

Liquid AI 在上一代 LFM2-VL-3B 中采用了基于 LFM2-2.6B 的语言骨干，并集成约 4 亿参数的 SigLIP2 NaFlex 视觉编码器。NaFlex 的核心价值是支持不同分辨率和长宽比的图片，不必把所有输入粗暴拉伸成同一种正方形尺寸；开发者还可以通过控制视觉 token 数量，在识别精度和推理速度之间做更细的权衡。

**原生长宽比处理对端侧模型的意义比跑分更实际。**例如，一张细长的手机网页截图如果被压缩成正方形，小字号文本可能变得难以辨认；如果始终按最高分辨率处理，模型又会制造大量视觉 token。可变分辨率方案允许部署者根据任务决定预算：摄像头场景只保留较少 token，合同和表格则分配更多 token。

LFM2.5-VL-3B 延续“更好、更快”的定位，但“快”不能只靠模型名称证明。官方此次强调的是面向边缘设备的效率，而不是把模型包装成云端旗舰 VLM 的替代品；对开发者而言，最终仍要看量化后内存、首 token 延迟、完整生成速度以及不同图片分辨率下的预填充耗时。

3B 参数为什么是一个有现实意义的选择

**3B 级模型是目前本地多模态部署中兼顾质量与资源消耗的关键档位。**按照最简单的权重体积估算，30 亿参数使用 FP16 保存约需 6GB，仅权重就会超过不少移动设备愿意留给单个应用的预算；量化到 8 bit 后理论权重体积约为 3GB，量化到 4 bit 后约为 1.5GB。

这些数字只是权重下限，而不是完整运行内存。实际部署还要为 KV Cache、视觉编码器中间状态、运行时缓冲区和系统本身预留空间，因此一个 4 bit 的 3B VLM 并不意味着拥有 1.5GB 空闲内存就一定能运行。图片数量、视觉 token 数和上下文长度都会改变峰值占用。

| 权重精度 | 3B 参数的理论权重体积 | 典型部署含义 | |---|---:|---| | FP16/BF16 | 约 6GB | 更适合独立显存或内存充足的高端设备 | | INT8 | 约 3GB | 精度与资源占用较均衡，但仍需额外运行内存 | | INT4 | 约 1.5GB | 更接近手机与普通笔记本的部署预算，质量取决于量化方案 |

**量化是用更低位宽保存和计算模型权重的压缩方法。**它能显著降低模型体积与内存带宽压力，但不能保证所有硬件都获得同比例加速，因为最终速度还取决于芯片是否有对应的低精度算子、视觉编码器是否完成优化，以及推理框架能否避免频繁的数据格式转换。

Liquid AI 的优势恰恰可能出现在这里。相比单纯缩小一个云端模型，LFM 系列从架构和运行时层面就强调 CPU 与设备端效率；如果 LFM2.5-VL-3B 能在 ARM CPU、移动 GPU 和 NPU 上保持一致的算子支持，它对产品团队的价值会高于一张漂亮但难以复现的综合榜单。

它不会取代云端旗舰，但可能让视觉代理少上几次云

**LFM2.5-VL-3B 更像一个设备端视觉执行层，而不是全能视觉大脑。**它最有价值的用法，是先在本地完成高频、重复和隐私敏感的判断，再把少量真正困难的任务交给更大的模型。

几个场景已经足够具体：

• **本地文档处理：**识别发票、快递单、医疗记录和内部表格，并在设备端输出结构化字段，减少原始图片离开设备的必要性。
• **GUI 视觉代理：**读取手机或桌面软件截图，定位按钮、菜单和状态提示，为下一步操作提供决策信息。
• **机器人与车载设备：**在网络不稳定时持续理解摄像头画面，处理物体状态、仪表盘和简单空间关系。
• **个人照片与屏幕搜索：**在本地为相册、截图和会议白板建立语义索引，避免把完整图片库上传到云端。
• **云边协同：**先由 3B 模型筛选、裁剪或摘要图片，只有低置信度样本才提交给大型云端模型。

**云边协同是让本地小模型处理常规任务、远程大模型处理复杂任务的分层架构。**这种方式的收益不是完全消灭云服务，而是减少上传量、等待时间和单次任务成本，同时给敏感数据增加一道本地过滤层。

3B 模型的能力上限也必须说清楚。它可能适合读取页面、概括图表和执行相对明确的视觉指令，但面对极小文字、复杂几何关系、长链条科学图表推理或多张高分辨率图片的交叉验证，参数规模仍会形成明显限制。端侧模型的正确产品设计通常不是假装它永远正确，而是让它输出置信度、保留可审计结果，并设置升级到更强模型的条件。

“更快”仍需四组数字才能成立

**目前最需要补充的不是更多宣传语，而是统一硬件上的可复现实测。**Liquid AI 将新品描述为更好、更快的端侧视觉模型，但仅凭参数规模无法判断它在具体设备上究竟比上一代快多少。

开发者评估 LFM2.5-VL-3B 时至少应记录以下四组数据：

1. **冷启动时间：**模型从存储载入到可以接受第一条请求需要多少秒。
2. **视觉预填充延迟：**输入一张固定分辨率图片后，生成第一个文字 token 需要多少毫秒。
3. **持续生成速度：**稳定输出阶段每秒能生成多少 token，而不是只报告峰值。
4. **峰值内存与功耗：**处理单图、多图和长截图时分别占用多少 GB，是否触发降频或内存回收。

视觉模型还应在固定视觉 token 预算下比较，否则测试很容易失真。一个模型使用 256 个视觉 token、另一个使用 1024 个视觉 token，即使前者延迟更低，也不能直接说明其架构效率更高；更合理的做法是在相同输入、相同精度、相同 token 预算和相同硬件上同时报告准确率与延迟。

**截至目前公开资料所能确认的核心数字是约 30 亿参数，而不是某款手机上的统一速度结论。**在官方提供完整的跨设备基准、量化配置和可复现脚本之前，“更快”应被视为产品方向和官方测试结论，而不是适用于所有硬件的普遍事实。

我们的判断：方向对了，成败取决于部署细节

**LFM2.5-VL-3B 的产品方向是成立的。**当前视觉模型竞争过度集中在超大模型与综合榜单，而真正落地到手机、PC、机器人和工业终端时，团队往往更关心 2GB 至数 GB 的内存预算、断网可用性、图片是否出端，以及每次交互能否在可接受时间内完成。

Liquid AI 也没有试图用 3B 模型正面替代云端旗舰。它选择的是更难被跑分概括、却更容易进入实际产品的指标：视觉 token 可控、原生比例图片处理、CPU 效率、低内存和本地常驻。对于需要每分钟处理大量截图或摄像头帧的应用，这些因素通常比模型能否回答少数高难度视觉谜题更重要。

真正的考验将落在模型之外。LFM2.5-VL-3B 能否成为常用端侧 VLM，取决于官方是否提供成熟的 4 bit 与 8 bit 权重、主流移动芯片后端、清晰的商业许可、可复现设备基准，以及足够稳定的多图和结构化输出能力。少掉其中任何一环，3B 只会是一个合适的参数数字，而不是一个好用的端侧产品。

LFM2.5-VL-3B 因而值得关注，但还不值得只看发布稿就下结论。它填补了 450M 超轻模型和更大端侧模型之间的空档，也代表视觉 AI 从“能否在本地运行”转向“能否在本地持续、稳定、低成本运行”；下一步，Liquid AI 需要用真实设备上的延迟、内存和功耗数字把这个故事补完整。

参考来源

• Liquid AI：LFM2.5-VL-3B for Better and Faster Vision Capabilities for the Edge：Liquid AI 发布在 Hugging Face 的官方介绍，说明新模型的端侧视觉定位。
• LocalLLaMA 社区关于 LFM2.5 系列的讨论：社区对 LFM2.5 小型设备端模型及视觉版本的讨论。