Liquid AI 的手机视觉模型挑战更大规模的对手

Liquid AI 凭借两款开放权重视觉模型登上 Google 新闻，其中包括一款专为在资源受限设备上私密运行而设计的 4.5 亿参数版本。

其核心主张听起来近乎过于理想：一款适配手机的模型可以分析图像、遵循指令，并超越一些参数量数倍于它的竞争对手。Liquid AI 还表示，其架构可提供同类视觉语言模型两倍的 GPU 推理速度。

真正的较量并非 Liquid AI 与某一家特定实验室之间的竞争，而是优先面向边缘部署的 AI 对“更强视觉智能必然需要更大模型和云端连接”这一假设的挑战。Meta、Google、Alibaba、Microsoft 以及多家较小的模型开发商，如今都面临同样的部署问题。

Liquid AI 的结果为本地部署路线提供了可信的佐证，但尚不足以定论。大多数公开分数来自该公司的模型卡和技术材料，而真实应用还会受到发热、内存、电池和可靠性等限制。

Liquid AI 实际发布了什么

LFM2-VL 将 Liquid AI 的紧凑型语言架构扩展为一个可同时处理图像和文本的开放权重系统。

这一系列最初包含两个检查点。LFM2-VL-450M 面向高度受限的硬件，而 LFM2-VL-1.6B 则在仍然较小的体积内提供更强的视觉能力。它们的名称指的是包括视觉组件在内的大致总参数量。

视觉语言模型，或称 VLM，能够在同一次交互中接收图像和文本。它可以描述照片、读取文档中的文字、回答有关图表的问题，或解读屏幕上显示的元素。

这种组合对手机尤为重要。当本地助手能够查看摄像头或显示屏所呈现的内容，而非只处理输入的文字提示时，它会更有用。

Liquid AI 发布了可供开发者下载和运行的模型权重。开放权重让构建者能够访问模型训练后的参数，但这一术语并不必然意味着所有训练数据集和开发细节都已公开。

较小的模型结合了 LFM2-350M 语言骨干网络与一个拥有 8600 万参数的 SigLIP2 NaFlex 视觉编码器。SigLIP2 是一种图像编码器，可将视觉内容转换为语言组件能够使用的表征。

1.6B 模型则将 LFM2-1.2B 骨干网络与一个针对形状优化、拥有 4 亿参数的视觉编码器配对。两款模型均使用多模态投影器，将编码器的视觉表征转换为与语言模型兼容的输入。

Liquid AI 公布的模型详情列出了 32,768 token 的文本上下文窗口、65,536 token 的词表，以及 bfloat16 参考精度。量化版本可降低部署所需的内存。

这些模型可接受原始分辨率最高为 512 × 512 像素的图像。原始尺寸处理避免了将每张图像自动拉伸为相同形状，从而减少图表、照片和文档布局的失真。

对于更大的图像，系统会将输入拆分为不重叠的图块。1.6B 版本还会接收一张保留完整场景的缩略图，使其同时获得局部细节和全局上下文。

Liquid AI 让图像 token 的数量可调。图像 token 是模型内部用于表征视觉信息的单位。开发者可以使用更多 token 来提升准确性，或减少 token 以降低延迟。

这种控制是此次发布的核心。该模型并未被呈现为一种固定的速度与质量配置，而是让应用开发者能够决定每项请求应获得多少视觉细节。

Liquid AI 建议针对狭窄应用对这些小型检查点进行微调。其模型卡称，它们专为遵循指令和轻量级代理工作流构建，并不适用于安全关键型决策。

这一限定意义重大。4.5 亿参数模型能够部署在数十亿参数模型无法容纳的场景中，但紧凑的规模同样限制了其通用知识和推理能力。

因此，这一发布改变的是部署选择，而非重新定义最先进智能的标准。开发者如今可以评估小型、可下载的 VLM，而此前视觉任务往往需要服务器或更大的本地模型。

为什么 Google 新闻的主张给云优先 AI 带来压力

真正的压力来自部署经济性和数据控制，而不是在每一项基准测试中取胜。

Google 新闻的表述强调在手机上的私密运行。这一承诺很重要，因为图像请求可能包含面孔、金融文件、健康信息、工作场所屏幕内容，或用户物理环境的细节。

云端视觉服务通常会将这些材料发送至远程基础设施进行处理。服务提供商可以通过加密和数据保留控制来保护数据，但传输本身仍会扩大系统的信任边界。

本地模型可以让图像、提示和输出都保留在设备上。这种设计可支持离线使用，并减少对网络质量的依赖，也能让应用运营方更好地控制数据保留。

不过，隐私并不会自动实现。应用仍可能收集模型输入、分析数据或生成的输出。端侧推理只是消除了将某项特定请求发送给远程模型的技术必要性。

延迟构成第二层压力。云服务会增加网络传输、排队和服务器处理时间。本地推理避免了前两个因素，尽管实际速度仍取决于手机处理器和软件栈。

这一优势在重复交互中更为明显。控制用户界面的视觉助手可能需要在完成一项操作时多次检查屏幕，网络延迟会在这一循环中累积。

可穿戴设备则提出了更严苛的要求。智能眼镜、摄像头和嵌入式系统必须在严格的功耗与连接预算内运行。将每一帧都发送至远程服务，可能缓慢、昂贵或不切实际。

Liquid AI 的路径让既有云模型提供商陷入尴尬处境。它们最大的系统具备更广泛的能力，但对于普通手机硬件而言仍然过于庞大。

云厂商可以用自家的小型模型回应。Google 有 Gemma，Microsoft 有 Phi，Meta 有 Llama，Alibaba 有 Qwen，Hugging Face 则推广了 SmolVLM 系列。

这一回应已经让紧凑型多模态 AI 成为一个竞争激烈的模型类别。竞争如今涵盖内存占用、支持的运行时、量化能力、持续运行速度和特定任务准确率。

设备制造商也面临另一种选择：依赖与硬件平台绑定的专有模型，或让开发者在多种操作环境中部署可下载模型。

开放权重使第二条路线更加可行。开发者可以检查检查点、进行微调、测试量化构建，并且无需为每次远程推理请求付费即可运行模型。

这种灵活性也能降低对供应商的依赖。围绕开放模型设计的应用，对升级和部署拥有更大控制权。它并不能消除迁移工作，但会改变由谁决定模型何时变更。

最有力的商业方案往往是混合系统。手机可在本地处理图像分类、文档提取或屏幕理解，再将困难请求升级交给更大的云端模型。

即使小型模型并非在所有场景中都更优，混合路由仍赋予它们角色。只要本地检查点能够可靠处理有价值的一部分请求，就能减少网络使用和数据暴露。

因此，更大型 AI 厂商必须作出的回应很明确：它们需要易于部署的紧凑模型，或提供足以证明远程处理价值的附加云端能力。

这是一种长期压力，而非一场持续一周的发布之战。一旦开发者构建起本地视觉工作流，云服务提供商就必须在原始模型质量之外展开竞争。

LFM2-VL 如何以模型规模换取实用速度

Liquid AI 的核心机制，是在模型进入部署阶段之前便围绕设备限制设计架构。

大多数现代语言模型高度依赖 Transformer 注意力机制。注意力机制让模型能够关联序列中的信息，但随着序列变长，其计算和内存需求也会增加。

根据 Liquid AI 后续发布的技术报告，LFM2 使用混合骨干网络，将门控短卷积与较少数量的分组查询注意力模块结合起来。

卷积可检测序列中相邻部分的模式。门控决定哪些信息应继续向前传递。分组查询注意力则降低了传统注意力相关的一部分内存成本。

其目标并非完全移除注意力机制。Liquid AI 而是将其保留给更广泛上下文最具价值的位置，同时以成本更低的操作处理更多局部信息。

该公司称，这种设计可在 CPU 上提供最高两倍于同等规模模型的预填充和解码速度。预填充负责处理输入提示，而解码则逐 token 生成响应。

视觉处理会在这两个阶段之前增加另一项工作负载。系统必须将图像转换为 token，与提示结合，并生成答案。过多的图像 token 可能抵消小型语言骨干网络带来的优势。

LFM2-VL 通过可变分辨率处理和可调 token 预算解决这一问题。小图像无需仅为满足固定输入形状而被放大。

同样，应用也不必为每项请求提供最高视觉细节。判断表单是否包含签名，与阅读整页中的小字，需要不同的视觉预算。

当请求涉及精细细节时，开发者可分配更多 token；对于简单场景描述或重复画面，则可减少数量。这一选择形成了准确性与延迟之间的直接权衡。

该架构还按用途区分了最初的两个检查点。450M 模型侧重速度和受限硬件，1.6B 模型则将更多能力投入语言和视觉编码。

这种区分比将较小检查点视为普遍更优的模型更有价值。仓库摄像头、移动文档扫描仪和读屏助手具有不同的错误容忍度。

Liquid AI 的架构文档说明，较大的编码器在处理图块化输入时会加入一张完整图像缩略图。这张缩略图有助于关联不同区域的细节。

设想一部手机正在查看餐厅菜单。图块可保留小字，缩略图则保留标题、分区与价格之间的关系。

读屏助手面临类似挑战。它既要读取标签，也要理解标签在界面中的位置。无论丢失细节还是整体布局，都可能导致错误操作。

这一机制解释了小型模型为何能在特定评测中击败更大的竞争对手。参数量衡量的是容量，但无法衡量模型使用视觉 token 的效率，也无法衡量其训练与基准测试的匹配程度。

训练同样重要。Liquid AI 表示，初代视觉模型使用了约 1000 亿个多模态 token 进行训练，数据来自开放数据集和内部生成的合成数据。

合成数据可以为指令、图像问题和结构化回答提供有针对性的示例。它也可能复现生成它的系统中存在的偏见或伪影。

这一设计仍然对边缘部署难题给出了可信的回答。Liquid AI 并非简单压缩一个未明确说明的云端模型，再宣称它适用于移动设备。它围绕资源受限的部署环境构建了视觉管线、骨干网络和推理控制机制。

这种差异让此次发布更具实质意义。该模型的速度主张源于可识别的机制，而非仅仅取决于模型规模。

基准测试更有利于 Liquid AI，但存在重要限制

LFM2-VL 在其规模级别上取得了多项亮眼成绩，但这些分数并不能证明它在所有场景下都优于更大的视觉模型。

Liquid AI 表示，其模型在 GPU 上的运行速度最高可达现有 VLM 的两倍，同时保持具有竞争力的准确率。这是公司自行报告的对比，实际性能取决于硬件、精度、运行时环境和输入设置。

质量结果更便于核查，因为公开的基准测试卡列出了 Liquid 模型以及多个对比检查点的分数。

LFM2-VL-1.6B 在 RealWorldQA 上得分为 65.75。该基准测试针对以真实世界图像为基础的视觉问答。同一张表中，InternVL3-2B 的得分为 65.10。

这款 Liquid 模型在多模态指令遵循评测 MM-IFEval 上取得 46.35 分。InternVL3-2B 为 38.49 分，SmolVLM2-2.2B 为 19.42 分。

在 MathVista 上，LFM2-VL-1.6B 得分为 51.70。它以微弱优势超过了 51.50 分的 SmolVLM2-2.2B，但仍落后于 57.60 分的 InternVL3-2B。

在其他任务上，结果则有所变化。Liquid 的 1.6B 模型在衡量文本识别及相关视觉理解能力的 OCRBench 上得分为 729，而 InternVL3-2B 得分为 831。

多学科多模态推理基准 MMMU 同样更有利于 InternVL3-2B。其得分为 48.70，而 LFM2-VL-1.6B 为 39.67。

更小的 LFM2-VL-450M 在多项测试中对 SmolVLM2-500M 取得了更明确的同规模优势。它在 RealWorldQA 上得分为 52.03，对比模型为 49.90。

在涵盖信息图表问答的 InfoVQA 上，Liquid 的 450M 模型得分为 44.56，而对比模型得分为 24.64。

在多模态指令遵循方面，差距同样较大。LFM2-VL-450M 在 MM-IFEval 上得分为 33.09，而 SmolVLM2-500M 为 11.27。

但即便这组对比也并非全面胜出。450M Liquid 模型在 MME 上得分为 1,229.91，低于 SmolVLM2-500M 的 1,448.30。MME 评估多项感知与认知任务。

这些参差不齐的结果支持一个比标题所暗示更谨慎的结论。Liquid AI 在一些重要的选定测试中超过了更大或规模相近的模型，尤其是在指令遵循和部分真实世界视觉问答方面。

它并未证明 LFM2-VL 是适用于所有视觉工作负载的最佳小型模型。OCR、广泛推理、感知能力以及特定应用场景中的可靠性，仍是独立的问题。

基准测试配置又增加了一层不确定性。图像分辨率、提示词、生成参数和评估软件都可能影响结果。当分数接近时，微小变化也很重要。

这些比较还反映了快速变化市场中的一个时点。竞争对手可以发布新的检查点、改善运行时支持，或推出更强的量化版本，而无需更改模型名称。

Liquid AI 自身已经超越了最初的版本。其后续 LFM2.5 系列改善了多项视觉结果，并增加了边界框预测和函数调用等能力。

这些进展强化了边缘优先战略，同时也让最初的 Google 新闻标题不那么具有持久性。重要的发展是这条模型产品线，而非某一份固定的排行榜。

独立的应用测试仍然比汇总平均分更有价值。用于处理收据的模型，应在相关语言、版式、拍摄角度和印刷质量条件下接受评估。

同样的原则也适用于屏幕控制。模型可能在通用图像问答中表现良好，却无法区分两个相似图标，或无法定位一个较小的界面元素。

开发者还应比较模型的失败行为，而不只是平均准确率。能够承认不确定性的模型，可能比自信地编造文本或物体的模型更安全。

私有手机 AI 仍受硬件与可靠性限制

本地运行消除了网络依赖，但并未消除多模态 AI 的工程成本或失效模式。

内存是首要限制。一个检查点的参数数量并不等于其完整的运行时占用。应用还需要为模型激活值、图像 token、提示上下文、生成 token 和推理引擎预留内存。

量化可减少模型权重所需的存储和内存。它以更少的位数表示模型数值，通常以少量质量损失换取更好的速度和效率。

实际权衡因硬件而异。量化模型在手机 CPU、GPU 和神经处理单元上的表现可能不同。运行时内核决定设备能否高效利用这些组件。

持续使用时，热限制同样重要。手机可能在短时基准测试中表现出色，随后随着热量累积而降速。持续摄像头分析远比处理一张照片困难。

电池消耗带来了另一项现实限制。本地请求避免了无线通信和云端计算，但会消耗设备能量。即使模型很小，反复进行视觉编码也可能代价高昂。

发布材料没有提供通用的电池消耗数据，因为并不存在有意义的单一数值。屏幕状态、图像大小、芯片组、运行时、量化方式和请求频率都会影响耗电量。

兼容性同样重要。在较新的旗舰设备上运行良好的模型，在较旧或低成本手机上可能带来糟糕的体验。开发者必须选择最低硬件目标。

操作系统策略也可能中断本地推理。移动平台会限制后台活动，并在内存紧张时回收资源。视觉助手必须能在这些条件下维持任务状态不被破坏。

准确率则构成更严肃的问题。Liquid AI 明确表示，原始模型不适用于安全关键型决策。手机不应仅依赖它们来进行医疗解读、身份验证或危险设备控制。

根据原始模型卡，这些模型支持英语。当图像包含其他语言、混合文字系统、地区缩写或不熟悉的文档格式时，性能可能下降。

微调可以缩小这一差距。开发者可以让模型适应发票、产品标签、界面屏幕或制造业图像。然而，微调也会带来新的测试和维护义务。

Liquid AI 后来的一篇教程说明了这个问题。在一项开箱即用的汽车品牌分类实验中，原始 450M 和 1.6B 模型在进行任务特定干预前表现不佳。

这个例子并未否定通用基准测试。它表明，广泛的视觉能力并不能保证在狭窄的生产标签集合上取得成功。

开放权重同样需要细致的安全工作。团队必须跟踪模型文件、运行时依赖、微调数据和应用权限。本地部署将更多责任转移给应用运营方。

隐私主张也需要同样严谨。若产品承诺私有处理，开发者应验证提示词、图像、日志、崩溃报告和分析数据是否都保留在本地。

模型许可证也值得审查。开放权重发布可能附带与宽松开源软件许可证不同的条件。企业在发布前应审查再分发和商业使用条款。

围绕手机直接性能还存在验证缺口。Liquid AI 的模型面向边缘部署设计，其平台也支持移动工作流。但这并不意味着每项基准分数都来自消费级手机。

公司报告的速度声明广泛指向 GPU 推理。采购方应要求在确切的目标设备上、采用预期运行时和热条件进行测量。

一项可靠的试点应测试多个类别。团队需要评估冷启动延迟、首个 token 时间、持续吞吐量、峰值内存、电池消耗，以及代表性图像上的准确率。

随后还应测试弱光、局部遮挡、旋转文档、小字体和会话中断等情况下的失败表现。这些条件往往比公开排行榜更能揭示问题。

因此，持审慎态度的解读很直接。LFM2-VL 让私有手机视觉更具可行性，但此次发布并未让它成为开箱即用的方案。

Google 新闻关注之后值得观察什么

三个信号将表明 Liquid AI 的边缘优先优势能否转化为持久的平台地位。

第一个信号是独立的设备端测量。开发者需要来自 iPhone、Android 旗舰机、中端手机、笔记本电脑和嵌入式系统的可重复结果。

有价值的报告应说明模型版本、量化方式、运行时、芯片组、图像大小、token 预算和热状态。没有这些细节，速度对比仍难以复现。

持续性能比单次请求更重要。如果独立测试确认其能够在不严重耗电的情况下维持稳定的低延迟运行，Liquid AI 的论点将更有说服力。

如果结果在不同设备间差异显著，该模型可能仍是一种专业化选择。硬件碎片化会削弱“一个紧凑检查点即可服务广泛移动市场”的设想。

第二个信号是其在真实应用中的采用情况。下载量和演示展示了兴趣，但生产环境集成才能揭示该模型是否解决了有价值的问题。

最可信的用途将是边界明确的任务，例如文档提取、界面解读、产品识别、无障碍功能和离线现场支持。

Liquid AI 已通过可下载检查点、移动工具和浏览器实验展示了该模型。其边缘平台也强调在本地设备上进行测试、定制和部署。

关键问题在于，开发者会继续使用原始检查点、对其进行微调，还是转向后续版本。频繁替换可以提升能力，但也会增加维护成本。

稳定应用中反复使用的证据将强化边缘优先论点。若演示之外的活动有限，则表明基准效率尚未转化为产品可靠性。

第三个信号是更大模型供应商的反应。Google、Meta、Microsoft、Alibaba、Apple 及其他开发者都有理由改进紧凑型多模态模型。

竞争对手可以通过多种方式挑战 Liquid AI。他们可以发布更小的检查点、为手机加速器优化现有模型，或将本地模型直接与操作系统捆绑。

硬件供应商也能通过首选运行时和开发者框架塑造市场。一款技术上高效的模型，如果仍难以部署到主流设备上，其优势也有限。

Liquid AI 后续的开放科学发布增加了更完整的技术报告，以及面向多种常见运行时的部署包。这提升了可复现性，并降低了集成摩擦。

该公司还在原始模型之后推出了更新的 LFM2.5 变体。后续版本表明，这一架构正在成为持续发展的产品线，而非一次性的实验。

这些进展并不保证市场领导地位。拥有更深分发能力的竞争对手，可以通过让其模型成为数百万设备上的默认选项，抹平基准测试上的劣势。

开发者应将原始 Google News 报道视为一个起点信号。Liquid AI 表明，小型开放权重模型在面向本地运行的同时，也能产出具有竞争力的视觉结果。

接下来的决策取决于构建者。请根据产品将面对的具体图像、设备与隐私要求测试 LFM2-VL，并将其持续表现与本地竞品及云端回退方案进行比较。

如果这款更小的模型能够稳定处理一部分请求，边缘优先的路径就已具备实际价值。如果它在真实条件下失效，云端仍将是整体设计的一部分。