Liquid AI d1-omni-600M 与 LFM2.5-VL-3B：一个做决策，一个做描述

Liquid AI d1-omni-600M 和 LFM2.5-VL-3B 都很小，都是多模态，也都由同一实验室在 Hugging Face 上以相同的 lfm1.0 许可证发布——而把它们配成一对是一种范畴错误，结果却证明是一种有用的错误。LFM2.5-VL-3B 于 2026 年 8 月 12 日发布，是 Liquid AI 的边缘视觉语言模型：31 亿参数、32,768 token 窗口，输出为自然语言文本。交给它一张扫描页面，它就会以文本形式返回带版式的转录结果。Liquid AI d1-omni-600M 于 2026 年 10 月 7 日随其余开放的 d1 系列一同上传，它对相同输入做的事恰恰相反。它是一个 5.87 亿参数的决策模型：你把具名问题附加到一个状态上，它就会报告自己已经相信的结果——P(yes)、一个带置信度的选定标签、在一个有序的 2 到 10 级量表上的位置——只需单次前向传播，零输出 token，下游无需解析任何内容。如果你搜索的是“小型多模态 Liquid 模型”，那么现在你面前有两种形态，而形态即决策。

本页所述内容，正是两份模型卡、10月7日发布帖以及这些代码库本身实际确立的东西。它也明确说明了它们止步于何处。本对比中的任何内容都未在 Liquid AI 之外得到复现，而且对于这两个模型中的一个，厂商完全没有发布任何专门针对其自身主打能力的准确率基准。

两个复选框并排显示

规格表几乎在每一个维度上都不一致，这正是两款从未打算争夺同一位置的机型会有的表现。

• 它是什么 — LFM2.5-VL-3B 是一个生成文本的生成式视觉语言模型；Liquid AI d1-omni-600M 是一个返回结构化答案且不输出 token 的决策模型

• 参数 — LFM2.5-VL-3B 为 BF16 格式下的 3.1B，而 Liquid AI d1-omni-600M 为 587M，后者本身由 381M 的共享主干与决策头，加上 94M 的视觉编码器和 112M 的音频编码器构成

• 骨干 — LFM2.5-VL-3B 将 LFM2.5-2.6B 语言模型与 SigLIP2 NaFlex 形状优化的 400M 视觉编码器配对；Liquid AI d1-omni-600M 基于 LFM2.5-Encoder-3B（一个双向编码器）训练而成，其 SigLIP2 塔取自 LFM2.5-VL-450M，并配有用于音频的 17 层 FastConformer

• 输入 — LFM2.5-VL-3B 的文本和图像；文本加图像或 Liquid AI d1-omni-600M 的文本加最多 30 秒语音，如果在同一请求中同时传入图像和音频，则会引发 ValueError

• 上下文——LFM2.5-VL-3B 为 32,768 个 token，而 Liquid AI d1-omni-600M 的文本、图像和音频位置合计为 16,384 个；其模型卡还补充说，在存在图像时，状态和问题文本会被裁剪到 896 个 token，以匹配训练

• 词表 — LFM2.5-VL-3B 为 128,000 个 token，Liquid AI d1-omni-600M 为 65,536 个

• 运行时 — LFM2.5-VL-3B 可在 transformers 和 vLLM 中运行，并有一个单独的 DSpark 草稿模型用于推测解码；Liquid AI d1-omni-600M 附带自定义代码，需要 trust_remote_code=True，其模型卡建议在 GPU 上使用 float16，同时警告 bfloat16 会在某些行上改变最佳答案

• 许可证 — 两者均为 lfm1.0，允许微调和部署

那份清单里有一行承担的作用比其余各行都大。Liquid AI d1-omni-600M 建立在双向编码器而非解码器之上。这并不是 LFM2.5-VL-3B 的规模缩减；它有着不同的血统，而这正是无论怎样解读基准测试表，这两个模型都无法相互替换的架构原因。

输出契约比基准测试更能决定结果。

向 LFM2.5-VL-3B 询问一个关于图像的问题，你会得到语言形式的回答。当答案需要由人阅读、作为字符串记录，或输入到期望自然语言表述的步骤时，这是有价值的。这也是一种你必须通过工程设计来应对的负担：生成的输出可能跑偏，一个 JSON 形式的请求返回的结构可能与你要求的不同，而且每个 token 都要计费并等待。该模型明确面向单轮、高吞吐、低延迟的视觉任务——扫描文档的批量 OCR、车辆中的实时检测、标识的端侧翻译——并明确避开长上下文、重推理的问题，例如“这张蓝图有什么问题”。

Liquid AI d1-omni-600M 在一个严格更可靠的边界内，回答一个严格更窄的问题。它的接口是一个状态——文本、JSON、一张或多张图像，或最长 30 秒的语音——外加一组具名问题，每个问题各自声明自己的类型。一个 noul问题是一个是/否问题，返回介于 0 和 1 之间的 P(yes)。一个 choice问题从你指定的一组标签中选出其中一个标签，并返回该标签、一个置信度以及每个选项的概率。一个 score问题将状态置于二到十级的有序量表上，并返回期望级别及其分布。多个问题可以挂接在同一个状态上，并在一次传递中读取，因此模型卡的用量计数器会报告 output_tokens: 0。这里没有生成步骤，这意味着不存在解析失败的输出。

你放弃的，是生成的回答所承载而标签所没有的一切：推理、留有余地的措辞、能粘贴进工单的句子，以及在同一个对话里继续追问的能力。Liquid 说得很直白——该模型不是聊天模型，也不写文本。如果你的流水线需要在判定结果旁边附上解释，那么 Liquid AI d1-omni-600M 就是这对组合里错误的那一半，而诚实的答案是两个都跑：LFM2.5-VL-3B 负责生成对图像的解读，Liquid AI d1-omni-600M 负责生成关于它的决策。

没有头对头的视力数值，而这正是发现。

接下来本能的举动，就是把视觉基准测试一一排开。你做不到。在 LFM2.5-VL-3B 上，厂商公布了一整套结果——RefCOCO Macro Precision@1 为 87.9，ScreenSpot-v2 为 80.7，ChartQA 为 81.3，POPE 为 88.7，MMStar 为 63.3，BLINK 为 61.5，MuirBench 为 58.3，ToolSandBox 为 59.5，OCRBench v2 英文为 47.5，以及达到 73.1 的 RealWorldQA，略微超过了此前 LFM2-VL-3B 的 71.1。所有这些都是厂商自行报告的，没有一项经过独立复跑，但它们仍然是对具体能力的具体说法，读者可以据此向该实验室问责。

对于 Liquid AI d1-omni-600M，发布文章称 Decision Index v0.3 包含一个私有的视觉拆分，“本次发布中我们不会对此进行报告”，并且 Liquid 转而验证了 600M 检查点“处理所有三种模态”，相关证据放在 playground 演示中。这就是已发布的全部视觉记录。无论是其模型卡还是发布文章，都没有给出该检查点的图像基准数值。同一篇文章更直接地确认了音频方面缺失的内容：专门的音频决策基准，用供应商自己的话说，“目前是一个开放问题”。

因此，对这场对比的正确解读是不对称的，也应该这样表述。LFM2.5-VL-3B 已经展示了带有数据支撑的视觉能力。Liquid AI d1-omni-600M 则有一个从同门模型借来的视觉编码器、一个针对冻结主干网络训练出的适配器、一个演示，以及一个承诺。如果你的部署需要模型这个月就能在图像方面靠得住，那么在这两者中，只有 3B 有任何站得住脚的依据。

速度：其中只有一个已被测量

因为决策模型不生成任何内容，延迟才是关键的数字，而且同样只有一方的数据被记录在案。LFM2.5-VL-3B 标称在 Apple M5 Max 上达到每秒 228 个 token，在 AMD Ryzen AI Max+ 395 上达到每秒 116 个 token，两者都控制在 3.3 GB 内存之内；在 Galaxy S26 Ultra 上约为每秒 20 个 token，而在 vLLM 下的单块 H100 上约为每秒 11,000 个 token。这些数字描述的是解码吞吐量，而对于一个会写作的模型来说，这才是正确的衡量指标。

对于 Liquid AI d1-omni-600M，模型卡指出未报告推理数字，因为该模型属于早期研究版本，仍在积极开发中。同一家族中的 d1-3B 兄弟型号确实有延迟表——在 RTX 4090 上一个问题为 8 毫秒，在 Jetson AGX Thor 上为 16 毫秒，在 Jetson AGX Orin 64 GB 上为 26 毫秒，在 Orin Nano 上为 50 毫秒，而针对一个状态处理三个问题的耗时大约是一个问题的 1.3 倍。这些数字属于 3B 决策模型，绝不能套用到 600M 上。对于 Liquid AI d1-omni-600M，诚实的立场是：该架构意味着一个体积小、速度快的模型，但实验室之外还没有人公布过毫秒级数字。

权重占用至少可以估算。在显卡推荐的 float16 精度下，587M 参数在加上激活值之前大约是 1.2 GB 的权重——这是基于已公布参数量的算术推算，而非厂商实测——相比之下，Liquid 为 LFM2.5-VL-3B 报告的是不到 3.3 GB。在兆字节就是硬约束的设备上，这一差距正是选择 600M 的理由。

如何在它们之间进行选择

一旦把输出契约视为固定的而非可协商的，这个选择便能干净利落地解决。

请选用LFM2.5-VL-3B，当交付物是文本时：带布局标注的整页 OCR、基于自然语言查询的定位与检测、设备端的标识翻译，以及任何由人工或下游语言模型消费答案的环节。它在实践中还拥有 32,768 个 token 的更宽上下文和更深的语言覆盖，因为它的答案是语言，而非标签。

在以下情况下选择Liquid AI d1-omni-600M：当交付物是一个决策时——工单路由、画面分诊、片段审核、护栏门控、按 2 到 10 分量表给回答打分——而且，在这两者之间独一无二的是，当输入为语音时也选它。它是这对模型中唯一能接收音频的，每次请求最多 30 秒；不过其模型卡指出，音频是在英语使用者和助手之间的交流上训练的，而这对你的调用将来自的那个世界而言，是一种狭隘的描述。

如果任务需要对图像进行推理，而不是对图像作一次读取或一个判定，那就两者都别选，继续用通用视觉语言模型。两张模型卡都指向该用例之外，而 Liquid AI d1-omni-600M 也没有任何机制去尝试它。

尝试一个实验性检查点，但不把整个流水线押在它上面

按厂商自己的标注，Liquid AI d1-omni-600M 属于早期研究版本，其视觉与音频表现均未经基准测试。这正是那种你希望放在回退机制之后、而非直接面向客户的模型。OrcaRouter 通过一个 API 密钥路由 200 多个模型，并具备跨提供商的自动故障转移，这是把这样的检查点放上线上路径的低成本方式：一旦实验性路由性能下降，或某个提供商宕机，请求会在无需改动代码的情况下落到回退方案上。同一个密钥承载着流水线交接的每一个模型，均按各提供商的标价透传，加价 0%，因此厂商一降价，你的价格当天就跟着降。

有一点需要说明，之所以强调这一点，是因为它至关重要：开放 d1 模型和 LFM2.5-VL 系列目前不在我们的目录中。对于这两者，供应商推荐的方式都是自行托管权重，并且 llama.cpp 从第一天起就支持 Apple、AMD、Qualcomm 和 NVIDIA 硬件；而在托管端点上运行它们，则意味着使用供应商自己的 API 或第三方平台。把本页面理解为可用性声明将是一个错误。

看什么

有趣的问题不在于 600M 最终是否会在任何方面胜过 3B——它不会，而且它本来就不是为此而造的。问题在于 Liquid AI 是否会公开它此前扣下的私有视觉划分，以及是否有人会构建该实验室称尚不存在的音频决策基准。在这两者之一落地之前，Liquid AI d1-omni-600M 与 LFM2.5-VL-3B 之间的比较，就是一个经过测量的模型与一个看似合理的模型之间的比较。对于尚未被测量的工作——语音输入、给出判定，小到足以驻留在设备上——600M 是这个家族中唯一尝试它的开放权重检查点，而在没有记分板的情况下成为第一，依然是第一。

OrcaRouter 通过一个 API 密钥路由 200 多个模型，各提供商的标价均以 0% 加价原样传递，因此供应商一降价，你的价格当天就会同步下调。