SingVL_S1_4B 与 LFM2.5-VL-3B：概率对阵段落

询问 SingVL_S1_4B 是否胜过 LFM2.5-VL-3B，本身就是一个不成立的问题；而想浪费一周时间，最快的方式就是照样去回答它。这些模型里，一个会围绕图像写出成段文字；另一个则只为你交给它的每个选项返回一个概率，自己从不吐出一个词。这种差异并不是要在排行榜上分高下的质量差距。它决定你的哪些流水线可以使用哪个模型，而这在任何基准测试被参考之前就已确定。所以，诚实的比较应当反过来进行：从你的代码需要接收到什么开始，再看哪个模型能产出它。

两种不同的返回类型

Liquid AI 的 LFM2.5-VL-3B 是通常意义上的视觉语言模型。给它一张图像和一个问题，它就会逐个 token 生成答案，这意味着它可以描述场景、进行多轮对话、调用函数、转录一页带有版面标注的文本，或为你指定的对象返回边界框。它于 2026 年 8 月 12 日发布，基于 LFM2.5-2.6B 语言主干和 SigLIP2 NaFlex 视觉编码器构建，并明确面向端侧部署——在 Apple M5 Max 上以低于 3.3 GB 的内存实现每秒 228 个 token，同时随原生检查点一同发布了 GGUF、ONNX 和 MLX 构建版本。

inclusionAI 的 SingVL_S1_4B 于 2026 年 11 月 11 日悄然上传，它只做一件事，并且通过单次前向传播完成。你给它一个状态——文本、JSON、最多四张图像——以及一个由命名问题组成的字典，每个问题都声明一种类型（choice、标签为“noul”的 yes/no，或有序的 2 到 10 级评分）及其候选答案。它会返回每个候选答案的概率。没有采样步骤，没有需要设置的温度，也没有需要解析的输出。模型卡本身通篇都使用这套词汇写成，连 API 示例也不例外。

如果你的端点需要返回“发票来自 Acme，日期为 3 月，总额 1,240.00”，那么 LFM2.5-VL-3B 可以做到，而 SingVL_S1_4B 做不到。如果你的端点需要 {"is_invoice": 0.97, "quality": {"1": 0.02, "2": 0.11, "3": 0.87}}，则情况相反。这就是整个决策，下面所有内容都围绕它的边界展开。

规格表，并排展示，无需表格

• 参数量 — SingVL_S1_4B 在 BF16 下约为 4.54B，分为两个分片，总计 9.1 GB；LFM2.5-VL-3B 为 3.1B，其中语言主干为 2.6B。

• 输出 — SingVL_S1_4B 通过单次前向传递返回每个选项的概率；LFM2.5-VL-3B 返回生成的文本、工具调用或结构化布局标注。

• 背景 — SingVL_S1_4B 仅在文本场景下接受 65,536 个输入 token，附加图像后降至 10,000 个；LFM2.5-VL-3B 宣称端到端支持 32,768 个 token。

• 每请求图像数量——SingVL_S1_4B 上限为四张，处理器每张最大 1,806,336 像素；LFM2.5-VL-3B 接受单图和多图输入，并将大图分割为 512×512 的图块外加一张缩略图。

• 语言——LFM2.5-VL-3B 列出了十五种，从阿拉伯语到越南语；SingVL_S1_4B 的模型卡完全没有提及任何语言支持。

• 许可 — LFM2.5-VL-3B 以 LFM Open License v1.0 发布，其量化衍生版本已流传在外；SingVL_S1_4B 没有许可证字段，也没有 LICENSE 文件。

• 部署 — LFM2.5-VL-3B 提供原生、GGUF、ONNX 和 MLX 构建，另有 WebGPU 演示以及 vLLM、SGLang 和 llama.cpp 路径；SingVL_S1_4B 则意味着克隆该仓库并在 8173 端口上运行其自带的 FastAPI 服务器。

• 生态系统 —— LFM2.5-VL-3B 自八月起就已登陆 Hub，并获得了社区的量化版本与移植；而在撰写本文时，SingVL_S1_4B 才刚刚问世一天，下载量为零。

其中有两行比看起来更具决定性。第一行是许可证那一行：没有许可证的代码库不会授予任何人再分发或交付的权利，而“供应商尚未说明”并不是你可以在合规审查中作为依据的许可。第二行是部署那一行：能在手机上运行的 ONNX 构建与需要 CUDA 设备的 Python 服务器，并不会在你的架构中争夺同一个位置，无论参数量怎么说。

为什么基准测试数值不能相减

两张卡片都报告了在名称重叠的数据集上的分数，而这种重叠是个陷阱。SingVL_S1_4B 在 RealWorldQA 上报告 82.17，在 BLINK 上报告 72.11，在 MMMU-Pro vision 上报告 50.17，在 InfographicVQA 上报告 96.31。LFM2.5-VL-3B 在 RealWorldQA 上报告 73.1，在 BLINK 上报告 61.5，在 MMMU Pro 上报告 30.5，在 ChartQA 上报告 81.3。把它们并排列出，看起来像一场碾压。这并不是任何有意义的比较。

第一个原因是作答模式。SingVL_S1_4B 的每一项数值，都是通过对一组给定选项打分并取概率最高者得出的；这本质上比生成一个自由形式的答案、再让评分器去匹配要容易得多。Decision Index 衡量的正是这一点，并且明确说明了：其分数经过随机猜测校正，因此靠猜不会得分，但模型仍然完全不需要生成该字符串——只需对别人写好的候选答案进行排序。一个生成式模型从零开始回答同一个问题时，为了在图表上拿到同样的分数，所做的功要多得多。

第二个原因是谁运行了它。两组数据都是厂商报告的，且各自基于厂商自己的评测框架。两者都没有被中立实验室复现过。SingVL_S1_4B 还额外只有一天历史，且没有向 Decision Index 的公开复现工具包提交任何内容——卡片中包含了制作提交的说明，这表明有意向，但什么也证明不了。LFM2.5-VL-3B 则已经被人们运行了三个月，这不等同于经过审计的数字，但确实意味着它的数据至少被陌生人看过。

第三是版本漂移。LFM2.5-VL-3B 自己的模型卡将其 OCRBench v2 数值标注为仅英文子集。SingVL_S1_4B 的 InfographicVQA 一行是在一个带有自身归一化处理的套件内报告的。两个数据集名称相同但子集不同的数字并非同一个数字，诚实的做法是停止对它们做减法。

效率的说法只属于一方。

LFM2.5-VL-3B 的核心卖点不是准确率，而是在内存限制下的吞吐量：低于 3.3 GB 时，在 M5 Max 上达到每秒 228 个 token，在 Ryzen AI Max+ 395 上达到 116 个，在 Galaxy S26 Ultra 上达到 20 个。最后一个数字对产品设计至关重要，因为它决定了一项功能是能在设备端运行，还是需要一次往返。SingVL_S1_4B 仓库中没有任何内容能提出可比的宣称，也没有可用于支撑这种宣称的量化版本——你拿到的只有 BF16 分片和一个服务器脚本。

反过来看，单次前向传播的成本特征，是生成式模型无法匹敌的。对一个问题给四个选项打分只需要一次前向传播；生成一段 200 个 token 的描述则需要 200 次串行前向传播。如果你的任务确实是分类——这份文档是不是收据、这一帧里有没有人、这条商品信息是否合规——那么 SingVL_S1_4B 的设计应当会让每次决策的成本更低，而且它返回的是一个经过校准、可供阈值直接作用的数值，而不是一句必须由解析器硬扛过去的自然语言。这一优势是结构性的，并不取决于厂商的基准测试是否正确。它同样尚未经过实验室之外任何人的实测，因此请把它当作一种预期，而非事实。

弄清真相要付出什么代价

LFM2.5-VL-3B 今天下午就能在笔记本电脑上评估。MLX 构建版可在 Apple silicon 上运行，GGUF 构建版可通过 llama.cpp 在 CPU 上运行；如果你想在下载任何内容前先看看，还有一个托管 playground。切换成本只是配置文件中的一个模型标识符，而风险有限，因为权重已获得许可，且格式是标准的。

SingVL_S1_4B 需要一块 GPU 和半天时间来完成配置。你需要 Python 3.12、与你的显卡相匹配的 PyTorch 构建、仓库自带的依赖要求，以及一个空闲端口。该服务器只提供一个路由 —— POST /v1/systemone —— 使用扁平 JSON 请求体；对于一个研究产物来说，这异常容易接入，而且模型卡为文本和图像请求都提供了可用的 curl 示例。你无法做的是把现有的 OpenAI 形态客户端直接指向它，因为它不是那种形态。该端点是为 Decision Index 评估套件设计的，而该套件也是为它设计的。

这种不对称正是“我应该先试哪个”的实际答案。如果你还没有确认一个返回概率的模型对你的流水线有帮助，那么成本低的实验就是把这个模式跑在已经提供服务的东西上。OrcaRouter 以每百万输入 token $0.042 的价格提供 TypeSafe Jev 1.14，只需一个密钥，它是一个可用的决策端点，你可以在一个小时内用自己的任务对它做基准测试，无需托管检查点，也没有需要上报的许可证问题。SingVL_S1_4B 在那里不可用——它根本没有托管提供商——所以今天你真正能做的比较是“类型化决策评分在我的数据上是否胜过生成”，而不是“这个特定的新检查点是否胜出”。先得到第一个答案，再为第二个花钱。

每个应该放在哪里

• 你必须阅读并引用的文档——LFM2.5-VL-3B。它会生成带有版面标签的转录文本，其 OCR 一行体现的是真实能力，而非一个分数。

• 屏幕、表单和图形界面——LFM2.5-VL-3B。ScreenSpot-v2 得分 80.7，以及相较上一代在 grounding 能力上的提升，正是本次发布的关键所在。

• 任何能在手机或笔记本电脑上运行的东西——LFM2.5-VL-3B，而且毫无悬念，因为替代方案需要服务器。

• 在高成本调用前加一道门控——两者都行；而如果你能托管它，SingVL_S1_4B 的形态更合适，因为门控需要的正是一个概率值。

• 在固定分类体系上进行多标签分流——原则上，SingVL_S1_4B 可以做到。它的选择型和评分型问题类型可直接映射到分类体系，而生成式模型则必须借助提示和后处理被重新约束到一个分类体系中。

• 内容审核——两者都并非无需投入。SingVL_S1_4B 自己的卡片显示，应用技能提示后，其仇恨模因一行的得分从 71.64 降至 43.28，这警示了提示敏感性，而这恰恰是在假阴性代价高昂的领域中。

• 本季度进入商业部署——LFM2.5-VL-3B，仅凭授权许可方面的理由。

仍未测量的部分

真正有意思的问题不是哪个模型更好，因为它们并不在同一个竞争赛道里。问题是：一个在视觉骨干网络之上训练的45亿参数分类器，能否在只需要标签和置信度的狭窄任务范围内，与通用视觉模型匹敌。如果它能做到，就会改变许多流水线的成本，因为单次前向传播与生成一段文字在开销上完全不是一个量级。inclusionAI 之外还没人知道——代码库才发布一天，许可证是空白的，基准测试也是该实验室自己的。

与此同时，通用模型已经可用、获得许可、完成量化、有文档记录，而且快到足以在手机上运行。当一个团队问该把其中哪一个投入生产时，目前的答案是那个乏味的；而那个有趣的，则是一个附带代码仓库的假设。