d1-Omni-2B：Liquid AI 最低调的 2B 决策模型随附了什么——又省略了什么

Hugging Face 仓库，对应 LiquidAI/d1-Omni-2B，创建于 2026 年 10 月 24 日 19:30 UTC。第一篇点名提及该模型的 Liquid AI 博客文章于 10 月 27 日发布。在那三天里，该仓库是公开且完整的——完整规格表、4.33GB 的 BF16 safetensors、可运行的 Transformers 代码——而厂商发布的任何内容都没有说明它存在。当提及最终出现时，它只是六款模型系列发布中的两段文字和一张四行表格，而不是一次独立发布。这就是本次发布的样子，也是以下所有内容的诚实框架：权重可供检查，说法来自厂商，而买家通常会从发布公告中获得的部分——价格、托管端点、独立基准测试——目前还不存在。

砝码与话语之间相隔的五天

Liquid AI 的决策模型叙事已经讲述过两次，而 d1-Omni-2B 在两次叙述中都没有出现。10 月 7 日，该公司发布了《Open d1：面向文本、视觉和音频的边缘决策模型》，其中恰好推出了两个开放检查点：d1-3B，一个 3.12B 的视觉与文本模型；以及 d1-omni-600M，一个 587M 模型，可接收文本加图像，或文本加最长 30 秒的音频。那篇帖子仍然在线，并且仍然不包含任何 2B 模型。

2B 系列按不同的时间表登场。10 月 21 日，基础检查点 LFM3-Omni-2B 出现在 Hugging Face 上。10 月 24 日，相隔二十四秒，Liquid AI 为 d1-2B 和 d1-Omni-2B 创建了仓库。随后，10 月 27 日的 LFM3 发布帖点明了该系列：六款约 2B 参数的模型，其中四款覆盖文本、视觉、音频和全模态，并且用帖子自己的话来说，“最后两款是从视觉和全模态模型专门化而来的决策模型。”这句话就是公告。没有单独的 d1-Omni-2B 发布帖，没有定价页面，没有发布合作方引述，也没有对 10 月 7 日那篇文章的更新。

所以这个模型并非没有文档——该仓库是 Liquid AI 已发布的文档较为完善的小型检查点之一，而且厂商面向决策模型的文档页面将它和 d1-2B、d1-omni-600M 并列列出。它只是宣传不足。这一区别很重要，因为它能告诉你哪些说法经过了发布审核，哪些没有。

把卡片当作规格表来读

抛开这些包装，这个 checkpoint 其实很直接。d1-Omni-2B 是基于 LFM3-Omni-2B 后训练得到的决策模型，它不是聊天模型：它不输出文本，也不生成语音，每次调用都返回output_tokens: 0。

• 参数 — 2.17B，以单个 4.33GB BF16 safetensors 文件形式发布。

• 架构 — LFM3 主干：24 层，其中 13 层是门控短卷积，5 层是窗口为 256 个 token 的滑动窗口注意力，6 层是全局注意力。该系列文章称，这种三混合组合是对 14 种设备和后端组合进行硬件在环架构搜索的结果。

• 上下文与词汇 — 128K 个 token 和 128,000 个 token 的词汇表，与 LFM3 的其余部分共享。

• 输入 — 一种可以是文本或任意 JSON 值的状态，再加上图片、视频帧和音频片段，再加上任意数量的具名问题，可以是书面或口头形式。该卡片的 API 将所有这些都接收在一个 media 列表中，这与 587M 检查点相比是一个有意义的差异：d1-omni-600M 的文档说明为文本配图像或文本配音频，而不是同时支持两者。

• 输出 — 带概率的类型化答案。是/否、从命名选项中选一项、有序评分、从文档中读取并附带其跨度的值、带 p10–p90 区间的数字、边界框，或对象的每个实例及计数。

• 语言——十六种。语音覆盖同一组语言，但不包括印地语、泰语、越南语和印度尼西亚语，这一点值得指出，因为文本侧列出了这些语言。

• 许可证 — LFM Open License v1.0。年收入低于 10,000,000 美元时授予商业使用许可；超过该金额时，许可证文本称商业使用“未根据本协议授予许可”。

音频是值得验证的主张

选择这个检查点而不是 d1-2B 的原因在于音频。Liquid AI 将其定位为“通话和语音消息路由与声音事件”，而模型卡提供了发布文章通常会首先强调的那一项证据：同一批条目上的口语与书面语对比。

• 业务路由与分诊（DecisionBench，Hanno Labs v1）——书面 83.4，口语 78.2。

• 客服案例（打字决策） — 书面 50.5，口语 48.0。

• JevBench v1.4.1，语音可朗读的各行—— 书面分为 87.6，口语分为 89.0，这意味着口语运行得分略高，但这只是噪声，并非提升。

• 声音事件（ESC-50）——84.5，无对应的书面形式。

• 口语语种识别（FLEURS，43 种语言） — 92.5.

这些数字支撑了这套宣传。音频部分的其余内容则在告诉你哪些地方不该构建，而对厂商模型卡来说，这种坦率非同寻常。口语短陈述从书面的 42.0 降至听觉的 22.8。八种语言的 Belebele 段落从 83.6 降至 41.8。该模型卡明确表示，长篇口语段落会损失很大一部分准确率，“尤其是在非拉丁字母语言中”，并指引任何没有音频输入的人改用 d1-2B；据称 d1-2B 在文本和单个框方面更强，更常报告缺失值，且校准更好。

把这些行放在一起看，它们描述的是这样一个模型：它擅长处理主要语言中简短、可路由的话语，而在任何需要保持较长语音状态的任务上要弱得多。呼叫中心分诊适合它。四十分钟的录音会议则不适合。

记分板是供应商的，而索引更改了版本。

这个模型上的每一项性能数据都是 Liquid AI 自己的。模型卡明确说明了方法：所有四个 d1 模型都在相同的项目上使用相同的评分方式进行了评分，因此部分数字与它们各自来源的单独模型卡略有出入。它并未说明有第三方复现了其中任何结果，而且截至撰写本文时，尚不存在对 d1-Omni-2B 的独立评估。

• Decision Index 公开套件，v0.3 — d1-Omni-2B 为 49.0，而 d1-2B 为 51.1，d1-3B 为 49.0，d1-omni-600M 为 18.3。

• DecisionBench (Hanno Labs) v1 —— 76.4，相比之下分别为 77.1、73.1 和 58.7。

• decisionbench.ai v4 — 84.7，对比 85.2、83.6 和 57.9。

• ImajevBench v2.0-lite — 72.3，相比之下分别为 75.5、64.0 和 21.7。

• 厂商自己的包含一百多项基准测试的排行榜—— 61.8，对比 63.2、58.8，而 600M 没有得分。

• 18 个图像基准的视觉平均分 — 67.7，对比 70.2、65.4 和 42.8。

这里中间有一个陷阱。10 月 7 日的帖子报告 d1-omni-600M 在 Decision Index v0.2.1 上为 15.95。新卡片报告它在 v0.3 上为 18.3。这些是不同的评测套件，差异并不是能力提升；不要把两者相减。唯一公平的比较是卡片实际所做的那种：所有四个模型都在相同条目上重新评分。

重新评分后依然成立的模式是：d1-Omni-2B 在几乎所有方面都略低于 d1-2B，但大幅高于上一代。Liquid AI 将其表述为：在参数量仅为 70% 的情况下，它在自己的决策看板上以及 18 项图像基准中的 16 项上击败 d1-3B；就所印表格而言这属实，但这也是与该系列如今已被取代的模型作比较。

该仓库未回答的内容

还有五个问题悬而未决，而仅靠读取权重无法回答其中任何一个。

• 托管访问与价格。 LFM3 的帖子称，基础模型和后训练模型可在 Hugging Face、Playground 和 Liquid AI API 上使用。然而，decision-models 文档表格将 d1-Omni-2B 列为开放权重，并把仅托管访问的行留给 d1.1 和 d1-ultra，且 Hugging Face 模型页面指出“此模型未由任何推理提供商部署”。本文未能找到任何地方发布该检查点的每次调用价格，因此应将托管访问视为看似合理但尚未确认。

• 训练数据。卡片未提供语料库，未说明构成，也没有数据集描述。它提到要在“没有任何训练行覆盖”的片段和声音上进行测试，这暗示存在训练集，却对其内容只字未提。

• 量化。主仓库提供 BF16，Liquid AI 发布了三个同系列构建：MLX fp16、MLX 8 位和 ONNX 导出。没有官方 GGUF，不过 Ollama 的 d1-omni 库带有一个 2b 标签，大小为 4.4GB、上下文为 125K，而且其大小与 BF16 检查点足够接近，看起来不像是激进量化。

• 独立评估。 无。上述所有数字均由供应商使用其自家评分器在自有开发板上运行得出。

• 它是否会取代 d1-omni-600M。 模型卡建议，在没有音频时选择 d1-2B 而非此模型；在有音频时则建议选择此模型而非 d1-2B。它没有说明 587M 检查点的未来，Liquid AI 也尚未将其废弃。

运行它，以及它在硬件上的成本

推理路径为 Transformers 5.19 或更高版本，并启用 trust_remote_code，调用方式为 model.system_one(state, questions, media)。没有需要设置的采样参数，因为不会进行任何采样。首次调用时编译大约需要一分钟；之后，该卡报告在 H100 PCIe 上，一个问题耗时 5.8 ms、三个问题耗时 7.7 ms，在 AMD MI325X 上为 3.7 ms 和 5.6 ms，在 Apple M5 Pro 上为 21.1 ms 和 28.9 ms。一个 5K token 的状态在 H100 上耗时 52 ms。吞吐量来自批处理：在 H100 上每秒 1,154 个状态，在 MI325X 上单次调用 64 个状态时每秒 1,697 个状态。

对这类模型来说，这些数字本身就是论据。它不是在质量上与聊天模型竞争；它是在与“是否要运行聊天模型”这件事本身竞争。一次返回校准概率的 5.8 毫秒前向传递，与一次返回一段你还得解析的文本的生成式调用，是完全不同的成本项。

决策至此结束，流水线其余部分由此开始

这样的模型只做一跳。它把一张工单、一段通话录音或一帧摄像头画面转成一个标签加一个置信度，然后必须有某个环节基于这个标签采取行动——起草回复、升级工单、调用 API。OrcaRouter 的模型目录里没有任何 Liquid AI 的模型，所以第二跳正是我们产品所处的位置：消费这个决策的生成式模型，全部通过一个兼容 OpenAI 的密钥来访问 200 多个模型，按各服务商的标价原样透传、0% 加价，并且在请求恰好落到某个正赶上“状态不佳的一分钟”的服务商时自动故障转移。决策模型是便宜、快速、确定性的那部分。而把昂贵、非确定性的那部分接到一个能重试的东西上，是值得的。

什么才能了结此事

有三件事能让 d1-Omni-2B 从“有前景”变为“值得推荐”，而这三件事都不需要再写一篇博客文章。第一件是在供应商无法控制的硬件上独立运行音频测试套件——语音短状态上 22.8 对 42.0 的差距，是最有可能在别人的麦克风下发生变化的数字。第二件是公布托管访问的价格，没有它就无法完成自建还是外购的权衡计算。第三件是在相同的带音频任务上与 d1-2B 进行直接比较，因为卡片自身的建议——只有当输入包含音频时才使用 2B omni——是其中最有用的句子，也是除 Liquid AI 之外无人测试过的那一句。