d1-Omni-2B vs d1-omni：一个标签、两个检查点，以及八倍的差距

拉取 d1-omni，今天你就能得到一个 587M 参数、850MB 大小的决策模型。拉取 d1-omni:2b，你得到的则是 4.4GB 的完全不同的东西——d1-Omni-2B，即 Liquid AI 于 2026 年 10 月 27 日随 LFM3 系列发布的音频决策模型；而 d1-omni 是 Ollama 自 10 月初以来一直用来指代该厂商 d1-omni-600M 检查点的名称。它们不是两家厂商对同一个问题的回答。它们是同一想法的两代产品，参数量相差八倍；它们之间的选择，实际上是在选择模型必须在哪里运行。一个能装在手机上。另一个需要 GPU，而作为交换，它能做小模型完全做不到的事。

命名这件事让本来不该这么难的事情变得更难了，所以在给出数字之前，有必要先说明白：并没有一个就叫 d1-omni 的 Liquid AI 模型。厂商文档把 d1-omni-2B 和 d1-omni-600M 列为开放权重，把 d1.1 和 d1-ultra 列为仅托管。“d1-omni”是一个打包名称——把 587M 检查点放在一个更短的标签下。它就是本次比较中的对手，也是大多数人磁盘上已经有的那个。

每一个实际上是什么

两者都是 Liquid AI 在这个术语意义上的决策模型：你向它们提供一个状态和一组具名问题，它们在单次前向传播中返回带概率的类型化答案。两者都不写文本，也不产生语音，并且都报告零输出 token。相似之处仅止于接口。

• 参数 — d1-Omni-2B 为 2.17B，而 d1-omni 为 587M；在小模型中拆分为 381M 的共享主干和决策头、94M 的视觉编码器以及 112M 的音频编码器。

• 架构——2B 模型采用 LFM3 三混合骨干：24 层由 13 层门控短卷积、5 层滑动窗口注意力和 6 层全局注意力组成。587M 模型是基于 LFM2.5-Encoder-350M 构建的 LFM2.5 双向编码器，沿用来自 LFM2.5-VL-450M 的 SigLIP2 视觉塔，并配备用于音频的 17 层 FastConformer。

• 上下文——2B 模型为 128K 个 token，词表包含 128,000 个 token。587M 模型的文档标注为 16,384 个 token，同时涵盖文本、图像和音频位置；其模型卡还补充说明，当存在图像时，状态和问题文本会像训练时那样被截断至 896 个 token。Ollama 的页面为两个标签都显示 125K，但厂商并未公布这一数字；请依据厂商给出的数字来设置提示词的大小。

• 输入 — 2B 接收文本或 JSON 状态，外加图片、视频帧和音频片段，全部放在同一个媒体列表中。587M 接收文本加图像，或文本加最长 30 秒的音频，并且其模型卡未说明可将两者混合使用。

• 输出类型——两者均支持是/否、选择和评分。2B 版本新增了边界框、多选、带 span 的提取值以及带区间的数字。这些是 LFM3 代新增的，在 587M 上没有对应项。

• 磁盘占用 — 2B 的 BF16 safetensors 为 4.33GB，而 d1-omni 的 Q8_0 构建为 850MB，其 BF16 标签为 1.2GB。

• 许可证 — 两者均采用 LFM Open License v1.0。年收入低于 10,000,000 美元可免费商用，超过该收入需单独授权。

第八个参数能换来什么

有价值的对比是 Liquid AI 自己发布的那一份，因为它用同一个评分器对全部四个 d1 模型在同一批题目上重新打分。这使得表中各行之间具有内部可比性，而旧版模型卡则做不到这一点。

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

• DecisionBench (Hanno Labs) v1 — 76.4 对 58.7。

• decisionbench.ai v4 — 84.7 对 57.9。

• JevBench v1.4.1 — 75.3 对比 58.0。

• ImajevBench v2.0-lite——72.3 对 21.7，这是本组中差距最大的一项，也是视觉工作最关键的一项。

• WorkflowEvals — 77.1 对比 48.8。

• 类型化决策——63.1 对 57.5，差距最小，也提醒我们并非每项任务都会随参数规模而提升。

• 视觉平均，18 项图像基准 — 67.7 对 42.8。

伴随那份清单有两点告诫。第一是版本漂移：10月7日的模型卡在 Decision Index v0.2.1 上报告 d1-omni-600M 为 15.95，而新模型卡在 v0.3 上报告为 18.3。它们是不同的评测套件，将两者相减衡量的是指数，而不是模型。第二是来源问题：每个数字均由厂商报告、由 Liquid AI 评分，且基于 Liquid AI 选定的基准。公司之外没有任何人发布过任一检查点的运行结果。

不过，结果的形态是一致的。在分类式任务上，587M 的表现出奇地稳——Typed Decisions 的差距在六分以内。凡是需要读懂场景、清点物体或解读布局的任务，它都会崩掉：ImajevBench 上是 21.7 对 72.3，早些的测试套件中 VisualWebBench 上是 14.9 对 88.6。如果你的工作是给文本工单做路由，多出来的参数是奢侈品；如果你的工作需要看点东西，它们就是产品的全部。

587M 仍然胜出的地方，以及能证明这一点的数字

部署范围是 587M 模型的真正优势，而且这不是安慰奖。占用 850MB 的 587M 模型可在笔记本电脑、Raspberry Pi 或手机上运行，而 Liquid AI 打造 d1 系列正是为此。占用 4.33GB 的 2.17B 模型则需要 GPU 或配置充足的 Apple Silicon 机器，才能获得令人愉快的使用体验。

缺的是能让这笔权衡变得精确的延迟对比。d1-Omni-2B 的卡片公布了完整的速度表：在 H100 PCIe 上，单个问题 5.8 毫秒、三个问题 7.7 毫秒；在 MI325X 上为 3.7 毫秒和 5.6 毫秒；在 M5 Pro 上为 21.1 毫秒和 28.9 毫秒；在 H100 上批处理时每秒可处理 1,154 个状态。d1-omni-600M 的卡片什么也没公布，并说明了原因：“我们不报告 d1-omni-600M 的推理数据，因为它是一个早期研究版本，正处于积极开发中。”因此，更小的模型几乎肯定更快，但没有任何厂商数据可供引用，说明快多少。任何告诉你 587M 快三倍的人，都是在根据参数数量做外推。

有一个真正与准确性相关、值得指出的优势。d1-Omni-2B 的卡片在无音频时推荐 d1-2B 而非自身，并给出了理由：d1-2B 在文本和单框任务上更强，更常报告缺失值，并且校准得更好。同样的建议也指向：纯文本工作应避开这个 omni 模型。它并没有说 587M 的校准更好——只是说 2B omni 为一个你可能用不到的能力付出了代价。

音频上的分界正是两代产品清晰区分开的地方。

音频是唯一让两个模型直接竞争的模态，且其约束条件差异足以决定架构选择。

587M 模型最多可处理 30 秒语音，要求 16kHz 单声道，其模型卡带有明确警告：音频能力是在英语使用者和助手之间的请求上训练的，涵盖话语类型、主题以及说话者想要什么。这是一种狭窄的分布，并且被明确列为一项限制，而不是脚注。

2B 模型支持与文本侧相同的十六种语言的语音，但不包括印地语、泰语、越南语和印度尼西亚语；模型卡的音频结果显示，ESC-50 声音事件得分为 84.5，FLEURS 在 43 种语言上的语言识别得分为 92.5。它也会以模型卡中记录的方式出现性能下降：口语短陈述从书面形式的 42.0 降至听觉形式的 22.8，八种语言中的 Belebele 段落从 83.6 降至 41.8。长口语段落的准确率会下降，非拉丁文字尤甚。

所以区别并不是“2B 更擅长音频”。而是：2B 能处理更多种类的音频，却仍在长时语音状态上吃力；而 587M 处理的是更窄、更受控的一部分音频，并且从未在声音事件或语种识别上做过基准测试。对于英语语音命令路由，587M 的这些限制尚可承受。对于多语言通话分诊，这些限制则是致命的。

要拉取哪个标签

决策规则足够简短，可以直接作为规则陈述。

• 仅文本和图像，产品中没有音频 — 两者都不拉取。在决策指数上，d1-2B 的得分高于 d1-Omni-2B，分别为 51.1 和 49.0，而且厂商自己的说明卡也建议你使用它。为 Omni 多付的溢价买到的是你用不到的音频。

• 受限硬件上的语音路由——d1-omni 在 850MB 下运行。接受 30 秒上限、英语使用者训练分布和 16,384 个 token 的上下文，并自行测量延迟，因为供应商不会给你一个具体数字。

• 在同一次决策中同时处理音频和图像，或在输出中给出边界框和跨度 — d1-Omni-2B。587M 无法表达这些请求，因此无从比较。

• 多语言语音—— d1-Omni-2B，在你提交之前，已对照你的实际流量核查了四种被排除的语言。

• 批处理吞吐量——d1-Omni-2B，其卡片是两者中唯一一个真的会发布每秒状态数据的。

有一个采用信号值得记录，因为它与基准测试的叙事相悖：自 10 月 5 日以来，d1-omni-600M 在 Hugging Face 上获得了约 18,900 次下载和 148 个赞。而 d1-Omni-2B 在其仓库出现四天后，只有 36 次下载和 7 个赞。早期的下载量衡量的是新鲜感和包装，而非质量——587M 模型有一个 Ollama 标签，让它只需一条命令即可获取——但这些数字确实描述了人们今天实际在运行哪个模型。

决定之后，通话的剩余部分

无论你拉取哪个 tag，决策模型都只是第一跳，而不是最后一跳。它返回一个带概率的标签；但仍需要有东西来撰写回复、升级工单或调用下一个 API，而第二跳是生成式的。OrcaRouter 不承载 Liquid AI 模型，因此 d1-omni 或 d1-Omni-2B 的调用仍在你原本运行它的地方进行——用 Hugging Face 权重在自己的硬件上运行，或通过供应商运行。一个与 OpenAI 兼容的密钥背后，是目录中另外 200 多个模型，按各供应商的标价、0% 加价提供，并且当你选择的下游模型正好状态不佳时，可跨供应商故障转移。对于这么新的模型，这种分离很有用：尚未验证的部分留在本地且成本低，而接触生产流量的部分则获得重试路径。

两张卡都没有给你的数字

两个检查点都没有独立评估。587M 自 10 月 5 日起就已公开，至今仍没有；2B 才发布四天。在有人用同一套音频、同一支麦克风和相同语言对两者进行测试之前，八倍的参数差距只是厂商的表格，而不是实测事实。值得关注的具体数字是口语短状态上的 22.8——这是新模型自己的模型卡中承认存在足以改变部署决策的弱点的唯一一行，也是最有可能在 Liquid AI 之外的人拿麦克风对它进行测试时发生变化的行。