LFM3-VL-2B：一个 1.92B 视觉模型，其头条分数全系于一个开关

LiquidAI/LFM3-VL-2B在公开领域存在了八天，Liquid AI 才对此发声。该 Hugging Face 仓库创建于 2026 年 10 月 19 日，当晚就出现了 GGUF 构建；厂商的公告——一篇博客文章、一个模型合集、一张带有完整基准测试表的模型卡——于 10 月 27 日发布。它所取代的模型，LFM2.5-VL-3B，是显而易见的参照标准：其参数量为 3.1B，而新模型为 1.92B；在 Liquid 自有的 62 项基准测试套件上，新模型平均得分为 71.4，而旧模型为 57.6。同一张模型卡还记录了第二个关注度低得多的数字：在禁用思考功能时，LFM3-VL-2B 平均得分为 62.1。仅这一个配置开关就值 9.3 分，而这正是决定性代际胜利与小幅胜利之间的差别。

本文涵盖截至10月28日实际记录在案的内容——仓库时间线、规格说明、基准测试表及其注意事项——并清楚标明证据止于何处。

出现了什么，以及何时出现？

时间线很重要，因为它解释了为什么这个模型发布时没有获得任何报道。Liquid AI 没有发布预告、候补名单或研究文章。它只是上传了权重和模型卡，而模型卡就静静地待在那里。第三方追踪者注意到了这个仓库，而关于 LFM3-VL-2B 的第一篇公开文章，是基于一个尚未合并的推理框架拉取请求做出的猜测，而非来自厂商的任何信息。

• 仓库已创建 — 根据 Hugging Face API，2026年10月19日 19:51 UTC。

• GGUF 仓库已创建 — 2026年10月19日 20:29 UTC，三十八分钟后。

• 卡片最后修改时间 — 2026年10月27日 16:24 UTC，即公告发布当日。

• 厂商公告 — 2026年10月27日：一篇家庭博客文章、一篇 Hugging Face 博客文章以及一个模型合集。

准确的描述不是“悄悄发布且仍未公布”，而是“悄悄发布，八天后才公布”。在那段窗口期内撰写该仓库相关内容的人，描述的是一个真实、可下载的检查点，而不是一个在 Liquid 产品线中有明确位置的产品。这个位置现在已经存在：LFM3-VL-2B 是一个基于共享 1.7B 基础构建的六模型家族中的视觉成员，厂商的定位是端侧视觉理解——文档、图表、应用屏幕、物体查找，以及面向机器人的空间推理。

该模型，以卡片自身的数字呈现

Liquid 的模型卡对参数的去向说明得异常具体，这一点值得留意，因为模型名称里的“2B”通常隐藏的信息比它透露的更多。

• 总参数 — 1.92B：1.73B 语言模型、164M 视觉编码器和 25M 投影器。

• 编码器 — 内部自研，采用卷积加注意力机制，取代 LFM2.5 视觉模型中所使用的 SigLIP2 塔。

• 模态——输入文本、图像和视频；输出文本。它是首个接受视频的 LFM 视觉模型，视频以每秒 2 帧采样。

• 视觉分词 —— 每个 2×2 的图像块都会成为一个语言 token，并保持原生分辨率。

• 上下文 — 128K 个 token，输入加输出，最大位置为 128,000。

• 许可证 — LFM 开放许可证 v1.0，与家族其他成员一样，采用非宽松但开放的条款。

• 预训练 — LFM3-1.7B-Base 主干，总计 22T tokens，具备 128K 上下文扩展，并在中期训练期间使用了 256K 扩展。

• 不建议用于——根据该卡自身的指引，编程、多轮对话或复杂推理。

最后那句话值得读两遍。一个被明确不建议用于多轮对话的模型，也是一个其 128K 上下文窗口很难按长上下文通常的使用方式来使用的模型。这个窗口是真实存在的，而且几乎是 LFM2.5-VL-3B 的 32,768 个 token 的四倍。在 1.92B 模型上，它还是一个增长速度快于其所依附权重的 KV 缓存。

六十二项基准测试、一个实验室，以及一张点名其竞争对手的表格

基准测试部分是这次发布中最有用的部分，不仅因为数字很高。Liquid 发布了一张包含 62 项基准的表格，其中纳入了自身模型的两种配置，以及九个竞品：LFM2.5-VL-3B、MiniCPM-V 4.7 1B、Qwen3.5 2B、Qwen3.5 4B、InternVL3.5 4B、Gemma 4 E2B、Gemma 4 12B、GPT-5.6 Luna 和 Gemini 3.5 Flash Lite。每项得分都归一化到 0–100，每个类别是其下各项基准的未加权平均值，总平均分则是全部 62 项基准的未加权平均值。

相比新闻稿图表，这是一份更可证伪的产物。它明确列出了评测工具，也列出了竞争对手，卡片脚注还说明了哪些模型在启用推理的情况下运行、哪些没有。这仍然是厂商自己做的工作：Liquid 选择了这 62 项基准，运行了每一个模型，并发布了表格。公司外部没有人复现过其中任何内容。

• 平均 — LFM3-VL-2B 为 71.4，相比之下 LFM2.5-VL-3B 为 57.6，MiniCPM-V 4.7 1B 为 57.5。

• 文档、OCR 和图表—— 83.9，这是端侧宣传最倚重的类别。

• GUI 理解——83.1，而 LFM2.5-VL-3B 为 66.0。

• 视觉定位 — 77.3，对比 68.3。

• 视频——61.2，对比 41.3，在首个真正支持视频的 LFM 视觉模型上。

• Agentic — 42.5，对比 21.1。表中每个小型模型最弱的类别。

• 数学与逻辑推理——68.8，对比 40.6。记住这个数字；它才是值得关注的那个。

这张卡片在文字说明中提出了三项比较性主张：LFM3-VL-2B 在 62 项基准测试中得分至少领先所有规模相近的模型 8 分；它与 Gemma 4 12B 持平；并且与 GPT-5.6 Luna 的差距在 2 分以内，同时胜过 Gemini 3.5 Flash Lite。对照表格核查后，这些主张成立：Gemma 4 12B 平均为 71.7，GPT-5.6 Luna 为 73.4，Gemini 3.5 Flash Lite 为 70.0。一个 1.92B 模型的平均分与一个 12B 模型相差在 0.3 分以内，这是最核心的宣传主张，而且这是厂商基于自身跑分数据提出的主张。

思考开关承担了大部分工作

LFM3-VL-2B 对同一组权重报告了两个分数。在推理模式下，它平均为 71.4。禁用思考时，它平均为 62.1。这一差距并非均匀分布在各个类别中——它集中在你会预期推理能带来帮助的地方，而在你不会预期的地方几乎不存在。

• 数学与逻辑推理 — 启用思考时 68.8，不启用时 41.0。相差 27.8 分，是迄今为止最大的。

• 文档、OCR 和图表—— 83.9 对 71.6。在看似属于感知类、但往往并非如此的任务上，出现了 12.3 个百分点的波动。

• GUI 理解——83.1 对 81.5。几乎没有变化，这表明屏幕阅读能力存在于编码器和后训练中，而不是推理循环中。

• 感知 — 75.6 对 68.9。

• 平均值 — 71.4 对 62.1。

其结果是，头条对比以一种特定方式抬高了新模型。LFM2.5-VL-3B 不支持推理模式，因此 Liquid 是在将一个思考模型与一个非思考模型进行比较。公平的较量是 62.1 对 57.6——仍然是胜出，但这是 4.5 个百分点的领先，而不是 13.8 个百分点。而在那种配置下，它不再领先附近的所有模型：Qwen3.5 2B 平均为 64.0，不过该数字同样来自启用推理的运行。

这一切都不会让这次发布变得不那么有趣。它让这次发布变得清晰易懂。Liquid 构建了一个小型模型，其默认部署速度快且不进行推理，而当你让它思考时，它的上限会高得多。哪个数字适用于你，完全取决于你的产品能否承受手机上推理循环带来的延迟。

1.92B 能在一台设备上为你带来什么

效率层面的卖点才是 Liquid 真正在推销的部分，而这张卡用实测数据而非形容词来支撑它。在单块 NVIDIA B300 上以 BF16 运行 SGLang 时，该模型在 1,024 个并发请求下每秒输出超过 12,000 个 token。这个数字更多说明的是批处理，而不是模型本身，但它确立了服务链路在首日即已就绪。

在设备端，该卡片会公布每个被比较模型在固定工作负载下的预填充、解码和峰值内存：一张 512×512 图像，输入 1,024 个文本 token，输出 256 个 token，全部在 llama.cpp 中运行，使用 Q4_0 GGUF 语言模型和 F16 视觉投影器。这是一个可复现的设置，而在决定投入手机之前，应该看的是内存这一列。

工具链确实存在，但发展并不均衡。SGLang 支持在发布时就已经有了。llama.cpp 支持仍在审核中——拉取请求 31252——并且带有 Liquid 的明确警告：目前不支持视频输入。GGUF 权重已经存在，而且比公告早八天。如果你想要这个模型是因为视频，那么本地路径还没有完成，模型卡上也明确说明了这一点。

什么是尚不可知的

本文的坦率边界：上文所有量化内容都来自 Liquid AI。目前没有对 LFM3-VL-2B 的独立评估，没有第三方排行榜条目，没有复现 62 项基准测试套件，截至 10 月 28 日也没有公布该模型在 Liquid 自有 API 上的每 token 价格。模型卡列出的可用渠道包括 Hugging Face、Liquid playground 和 Liquid API，且权重是开放的，但“开放权重”和“经独立验证”是不同的说法。

综合平均分与部署实际表现之间也存在差距。62 项基准的平均分很适合用来给模型排名，却不适合预测你的工作负载。LFM3-VL-2B 最强的类别——GUI 理解、视觉定位、文档和图表阅读——恰恰是厂商对基准实例的选择就能让分数变动数个百分点的地方。它最弱的类别是得分为 42.5 的智能体任务，而这些任务最可能对产品卡片所宣传的机器人用例产生影响。

如果你正在构建某个东西，这适用于何处

LFM3-VL-2B 不在OrcaRouter 的目录中——在撰写本文时，这是一个需要你自行下载并运行的检查点，而不是通过我们的 API 调用的东西。这决定了有用的模式，而不是将其排除在外。此版本在成本上与之竞争的模型——处理长尾文档和视频的托管视觉模型——正是你会进行路由的模型，而将本地检查点和托管回退方案置于同一个路由决策的两侧，才是这些数字实际支持的架构。在设备上运行 1.92B 模型，并将困难帧升级到更大的托管模型，这种部署让 62.1 这个数字变得可接受，因为它失败的情况正是那些离开设备的情况。

对于我们确实进行路由的模型，一个端点意味着一个密钥、无需第二份合同，并且在主提供商降级时跨提供商自动故障转移。这是系统中需要路由器的那一半；设备端的那一半则需要良好的量化和电池预算。

什么会改变这幅画面

三件事，按它们的影响大小排序。对 62 项基准测试表的独立复现，要么会证实发布内容中最引人注目的说法，要么会推翻它。一个已合并、支持视频的 llama.cpp 构建，会让端侧方案从计划变成产品。而公布 API 价格，则能让任何人在决定大多数部署选择的那个维度上进行比较，而这个维度目前还是一格空白。

在此之前，站得住脚的解读范围狭窄但有用：Liquid 发布了一个 1.92B 视觉模型，在厂商自家测试套件上击败了它所取代的 3.1B 模型；启用推理时，它决定性地赢下这一比较，未启用时则仅以微弱优势胜出，并在屏幕和文档方面领先同尺寸级别。该仓库在发布公告前八天就已公开，这是关于 Liquid 发布流程的事实，而非关于该模型的事实——但这正是 LFM3-VL-2B 的首批报道属于猜测而非评测的原因。