LFM3-Omni-2B 对比 LFM2.5-VL-3B：看得更少的继任者

Liquid AI 最新的多模态模型在视觉表现上不如它所取代的模型。在 RealWorldQA 上，LFM3-Omni-2B得分为 66.68，而 LFM2.5-VL-3B得分为 73.1。在 MMStar 上为 55.67，对比 63.3。在 RefCOCO 指代表达定位任务上为 73.55，对比 87.9。在 MMBench 上为 73.68，对比 81.0。两个模型都报告的五个基准中，有四个更有利于较旧、更大、纯视觉的检查点，而且差距并非噪声——差距在 7 到 14 分之间，具体取决于哪一行。在两个模型之间进行路由不应增加平台费用。0% 加价提供商目录价原样透传。

这不是丑闻。这只是当你让一个较小的网络同时承担更多任务时会发生的事，而且对于任何要在这两个检查点之间做选择的人来说，这是唯一最有用的信息。LFM3-Omni-2B 并不是视觉产品的升级路径。它是另一款产品，只是恰好共享同一个家族名称。

两个模型执行不同的任务

这种困惑是可以理解的，因为这两个模型看起来像是同一思路的连续几代产品。二者都出自 Liquid AI，都面向端侧部署，都是非推理模型，都沿用 LFM Open License v1.0，并且都定位在相近的内存预算上。LFM2.5-VL-3B 于 2026 年 8 月 12 日发布，是一款视觉语言专用模型：由 2.6B 的文本主干网络搭配 400M 的 SigLIP2 NaFlex 编码器，总参数量约为 3.1B。

LFM3-Omni-2B 于 2026 年 10 月 27 日发布，是一个任意到任意模型。它接收文本、图像、带或不带音轨的视频以及 16 kHz 音频，并返回文本、24 kHz 语音，或两者兼有。视觉只是四条输入路径之一，而不是全部任务。参数预算从 3.1B 降至 2.17B，而任务数量从一项增至四项，视觉得分正是这套算术体现出来的地方。

• 参数 — LFM3-Omni-2B 为 2.17B 稠密模型，而 LFM2.5-VL-3B 约为 3.1B，其中 400M 为视觉编码器。

• 输入 — 文本、图像、视频和 16 kHz 音频，对比文本、图像和视频。

• 输出 — 文本和 24 kHz 语音，对比仅文本。

• 上下文 — 32,768 个 token 对比 32,768 个 token。完全相同，并且两者都计入输入加输出。

• 视觉预算 — 每张图像 2,048 个视觉 token，原生分辨率，对比带缩略图路径的原生分辨率 512 像素图块。

• 定位 — 作为四模型流水线的全模态替代方案，对比用于 OCR、UI 理解和视觉问答的专用 VLM。

• 许可证 — 两种情况均为 LFM Open License v1.0，包括约束商业使用的收入门槛。

数字真正重合的地方

不同实验室的模型之间的基准比较通常并不诚实，因为评测框架不同。这一项比大多数都更干净：两个检查点都由同一家公司、在相同的非推理模式下评估，并且都报告了五个相同的数据集。这并不会让这些数字变得独立——它们并不独立——但这确实让它们彼此之间具有可比性，而跨实验室的表格很少能做到这一点。

• RealWorldQA——LFM3-Omni-2B 为 66.68，而 LFM2.5-VL-3B 为 73.1。在日常场景类问题上下降了 6.4 分。

• MMStar — 55.67 对 63.3。在旨在抵御数据污染的基准测试上下降了 7.6 个百分点。

• MMBench — 73.68 对 81.0。广泛多模态能力下降了 7.3 个百分点。

• RefCOCO pointing — 73.55 对 87.9。下降了 14.4 个百分点，是该组中差距最大的，出现在图像中定位指定物体的任务上。

• DocVQA—— 92.47 对 91.1。例外：LFM3-Omni-2B 在文档问答任务上领先 1.4 分。

DocVQA 的结果正是让这件事不能简单归结为“新模型更差”这种说法的关键。文档文本这项任务中，统一模型能够以高分辨率读取页面并一次性进行推理，从而可能胜过流水线——而这也正是 Liquid 每张图像 2,048 token 上限最应该造成损害的任务。omni 模型在那里仍然胜出，说明视觉能力退化在不同任务间并不均匀。它集中在空间任务和指代任务上，而这恰恰是专用视觉容量更少的模型最预期会吃力的地方。

额外模式要花多少钱

音频路径并非没有代价，而这张卡异常清楚地说明了成本落在哪里。32K 上下文在所有模态之间共享：一段每秒 2 帧、共 384 帧的视频，在你还没提问之前就会消耗掉窗口的大部分。每张图像上限为 2,048 个视觉 token，这大约是在照片中读取密集文字的分辨率上限。纯视觉模型拥有同样的 32K 上下文，但不必把其中任何部分花在音频上。

语音输出带来了第二个考量，它与基准测试无关。LiquidCodec 将生成的 token 转换为 24 kHz 音频的速度快于实时，这正是流式语音回复得以实现的原因。但模型卡只记录了用于文本输出的 SGLang 服务，并未说明语音分支是如何提供服务的。如果你需要从自己的基础设施中获得语音回答，那么该模型这一半的参考实现是缺失的。相比之下，LFM2.5-VL-3B 背后有一年的工具链积累——GGUF、MLX、vLLM、SGLang、ONNX，并且有报告称其在 M5 Max 上以低于 3.3 GB 的内存实现每秒 228 个 token。

成熟度不是基准测试表里的一行，但它决定部署。一个今天就能在任何地方运行的模型，胜过一个明天只能沿一条路径运行的模型——除非那额外的模态正是你选择它的理由。

如何选择

如果任务是读取截图、解析文档、指向物体或根据摄像头画面回答问题，那么 LFM2.5-VL-3B 是更好的模型，而且在关键指标上差距悬殊。尤其是 RefCOCO 上 14 个百分点的差距，应该足以终结任何机器人或 UI 自动化用例的讨论。当替代方案是一个把三分之一容量花在耳朵和嘴巴上的 2.17B 模型时，3.1B 参数并不会成为劣势。

如果任务涉及人对设备说话、设备再回话——比如自助终端、手机助手、双手忙碌时使用的现场工具——那么 LFM3-Omni-2B 能做到的事，LFM2.5-VL-3B 无论参数规模多大都做不到。你并不是在选择一个更差的视觉模型；你是在选择把四个模型合并成一个，并接受视觉能力退步作为这种合并的代价。

基准测试表明显而易见的第三种选择：两者都运行。用视觉专家模型处理画面帧，用全模态模型处理对话。这就是两个检查点，在 BF16 下约 7.4 GB，仍在一张中端 GPU 的显存范围内。OrcaRouter 的 路由 DSL 正是为这种组合而存在——一个端点，用规则把图文请求发给专家模型，把语音请求发给全模态模型，并在任一路径失败时自动故障转移。今天我们的目录里没有这两个检查点，所以这是一种模式而非承诺；关键在于，“该用哪个模型”这个问题有第三个答案，而两家厂商的发布文章都没提到它。

裁决

LFM3-Omni-2B 在 2.17B 参数规模上是一项真正的工程成就，但对于任何以视觉为主要用途的应用来说，它都是 LFM2.5-VL-3B 的糟糕替代品。诚实地解读这一对产品的方式，是把它们看作 Liquid 自家产品线上的一个分叉：一支为"看"而优化，另一支为"参与对话"而优化。相同的家族名和共享的许可证让它们看起来像是一个序列。而基准测试表说明它们是兄弟，并且年长的那一位更擅长它当初被打造出来要做的事。

能改变这一判断的，是一次独立评估，因为上述整个比较都建立在 Liquid 就其自家两个模型所产出的数字之上。有可能 omni 模型是在这些数据集更难的变体上评估的，或者是在一种对其不利的模式下评估的。卡片中没有任何内容表明如此，而且五行中有四行方向一致，这也反驳了这种可能。在公司外部有人复现任一表格之前，最稳妥的解读也最简单：专用模型看得更好，而 omni 模型听得更好。