d1-omni 与 Liquid AI D1 Omni 600M：两个名字，同一个检查点，以及一个无人能溯源出处的上下文数字

Liquid AI D1 Omni 600M 与 d1-omni 并不是两个模型，也不是同一个模型的两个检查点。它们其实是同一套权重——Liquid AI 的 587M 参数多模态决策模型，基于 Liquid AI LFM2.5-Encoder-350M 构建，于 2026 年 10 月 5 日以 LiquidAI/d1-omni-600M 这一仓库名发布在 Hugging Face 上——却在两个不同的目录中挂着两个不同的文件名。其中一个目录来自厂商，它告诉你这个模型是什么。另一个来自 Ollama，它告诉你有人把它打包成了什么，并在模型卡片上印出了三个厂商文档并不支持的数值。这个差距正是这篇对比值得一读的全部原因，因为对于这么小的模型来说，打包方式绝非无关紧要的脚注——它决定了你拿到的是文本加图像模型，还是卡片上声称你下载的那个模型。

供应商尚未就 Ollama 条目发布任何消息，Ollama 页面上也没有维护者说明、更新日志条目或 README 来解释这一切。因此，对以下所有内容，诚实的表述框架是这样的：权重是公开且可检查的，打包内容也是公开且可检查的，而这里对打包内容所作的解读是我们的，不是 Liquid AI 的。如果某个数字无法追溯到来源，本文会明确说明，而不是照搬。

这两个名字实际上是什么

Liquid AI 于 Hugging Face 发布了该模型，创建时间戳为 2026 年 10 月 5 日，比它于 10 月 7 日出现在厂商自己的博客文章《Open d1：面向文本、视觉和音频的边缘决策模型》中早两天。权重依据 Liquid 自己的 LFM 1.0 条款授权，标记为 d1_omni、system-one、multimodal、vision、audio以及decision-model，截至撰写本文时已获得约 13,900 次下载和 135 个赞。量化变体则按各自的时间表陆续推出：10 月 6 日发布 GGUF 仓库，10 月 12 日推出面向 Apple Silicon 的 MLX 构建版本。

Ollama 条目并不属于那些仓库中的任何一个。它是一个名为d1-omni的 Ollama 库页面，带有“vision 600m”徽章，显示四个标签，并且在撰写本文前几分钟刚刚更新过——这正是雷达能发现它的原因。其中没有任何内容提到 Liquid AI、LFM2.5-Encoder-350M，或这些字节所来自的 Hugging Face 仓库。

因此，实际差别在于文件名和分发路径，而不在于模型。真正不同、也真正重要的是包裹在这些字节周围的元数据。

Ollama 卡片上的三个数字，逐一核对

Ollama 的页面会为每个 tag 显示一个大小、一个上下文窗口和一个输入列表。这三项都值得再仔细看看，因为在这个模型上，其中两项一对照源就站不住脚。

• 上下文窗口——模型卡上写的是 125K，而所有厂商来源都写 16,384。 Liquid AI 的模型卡标明 16,384 个 token 的上限，合计涵盖文本、图像和音频位置，而厂商自己为 d1-omni-600M 提供的文档页面写着“16K tokens”。字符串 125K 在两者中均未出现。它可能是底层 LFM2.5-Encoder 架构的位置配置的产物，也可能是 Ollama 报告缓存限制方式的产物，但它不是 Liquid AI 公布的数字，也不是本文能够归因于任何人的数字。真正让这一差异不只是吹毛求疵的，是再往下的那个数字。

• 在图像路径上，你实际能传入的状态被限制在 896 个 token 以内。Liquid 的模型卡写道，当存在图像时，"状态和问题文本会被截断到 896 个 token，与训练时一致"。因此，一个附带照片的决策请求，其文本预算大约只相当于这句话的长度，无论拉取页面上印着多大的上下文数字。如果你按 125K 来规划一个分诊提示词，并期望为一段很长的状态付费，那你依据的就是一个并不描述实际运行时情况的数字。16,384 这个数字才是真正的上限；896 这个数字是多模态路径真正的工作限制；而 125K 则是一个没有书面依据的数字。

• 大小 — 卡上 850MB，注册表里有两个文件。 Ollama 标签 d1-omni:latest 对应一个 407MB 的量化权重文件（标记为 Q8_0）加上一个 442MB 的投影器文件（标记为 BF16），407 + 442 = 849，页面将其四舍五入为 850MB。两者都如实列出；这个算术只是混合精度配对相加的结果，而不是单个文件。另一个 d1-omni:600m-bf16 标签则更简洁：764MB 的 BF16 权重加上同样的 442MB 投影器，磁盘占用 1.2GB，而且投影器在两个标签之间逐字节完全一致。这一点在下一节值得注意，因为自带权重的投影器会改变有效参数数量。

还有一个细节值得记录而不是解释：Ollama 的 d1-omni 包内的运行时参数数据块，与 Ollama 另一个独立的 d1 包内的那个数据块字节长度完全相同——都是 18 字节——该包随附 Liquid AI d1-3B，包含 2.87GB 的 Q8_0 权重和 855MB 的投影器。两种架构、两种参数数量、彼此之间参数规模相差两个数量级，却有着相同的 18 字节运行时配置。这是一个打包常量，而不是关于任一模型的断言。

权重本身说明了什么

抛开包装不谈，这个模型的文档记录异常完备。Liquid AI D1 Omni 600M 共有 587M 个参数，分为三部分：381M 的共享主干和决策头、94M 的视觉编码器，以及 112M 的音频编码器。主干是双向的——这是编码器，不是解码器——而且它对每种模态都是同一个主干，只是外挂了特定于模态的塔。

• 视觉来自继承自 Liquid AI LFM2.5-VL-450M 的 SigLIP2 塔，配有适配器和 LoRA 更新，这些更新仅在图像输入时生效，而编码器本身保持冻结。

• 音频来自一个带有独立适配器的 17 层 FastConformer：在文本主干冻结的阶段进行微调，然后对整个堆栈进行微调，合并 LoRA，并将权重相对于之前的检查点进行平均回退。

• 词汇表包含 15 种语言的 65,536 个词元：英语、德语、西班牙语、法语、意大利语、荷兰语、波兰语、葡萄牙语、阿拉伯语、印地语、日语、俄语、土耳其语、越南语和中文。

• 模态不能混用。单次请求接受文本加图像，或文本加最多 30 秒的语音——不能同时包含两者。音频预期为 16kHz 单声道，长度在 0.5 到 30 秒之间，并且是在英语说话者与助手之间的对话上训练的，这对任何多语言或嘈杂场景都是实实在在的限制。

这些内容都没有出现在 Ollama 页面上，而这一遗漏所带来的后果，你可以直接从用法示例中看到。Ollama 的代码片段是聊天调用——一个模型字符串、一个 messages 数组、一句“Hello!”——而底层的检查点根本无法应答它们。它不是聊天模型，也不会撰写文本。它返回的是类型化答案：一个是/否概率、一个带逐标签概率的标签，或是有序标尺上的一个位置，这些全都直接读取自输出分布，且生成的输出 token 数为零。已发布的接口也反映了这一点：system_one 与 probabilities 通过 Transformers 调用，或通过 llama.cpp 0.7.0 及更高版本调用 /v1/systemone 端点。针对决策模型发起聊天形式的调用，正是这一命名缺口所招致的错误。

每一个数字都附带两点注意事项。

首先，Liquid 是用官方评分器给自己的条目打分，而不是将其提交公开排名；也没有任何第三方复现过任何 d1-omni-600M 的结果——厂商在模型卡上明确说明，它不报告该检查点的推理数值，因为这是一个仍在积极开发中的早期研究版本。其次，两个主要数字彼此矛盾：32 分的指数差距和 4.5 分的基准均值差距描述的是同一个模型，因此有用的是各项子分数，而不是总分。检索（Retrieval）为 35.0、工具（Tools）为 15.1，而艺术（Arts）为 6.8，这能说明该检查点已准备好承担哪些任务、尚未准备好承担哪些任务。音频完全没有基准列；Liquid 称专门的音频决策基准仍是一个开放问题。

在七项基准中的两项上，Liquid AI D1 Omni 600M 也在其所属系列中领先：Civil Comments 为 95.8，PAWS-X 为 79.5。这两项正是 587M 编码器彻底胜过 3B 解码器的两行，而且两者都属于文本分类型任务，而非推理型任务——这与该架构相符，而不是与之矛盾。

根据你的需求来选。如果你想在 Ollama 下本地运行，d1-omni 就是可行的名称——Q8_0 构建为 850MB，BF16 为 1.2GB，与 Liquid 文档所述相同的镜像路径，而且两个标签都不带音频投影器。如果你想要厂商所描述的模型，Liquid AI D1 Omni 600M 才是应该搜索的名称，而通过 Hugging Face 仓库的 Transformers 路线，其上下文长度、模态列表和参数数量都与文档一致。

无论采用哪种方式，这都是流水线中成本较低的一半。决策模型负责分类；分类结果必须由其他环节来执行。这正是 OrcaRouter 所处的边界，也是值得精确说明的边界：我们的目录中没有任何 Liquid AI 模型，因此 d1-omni 调用本身会发往你当前运行它的任何位置——这些权重可以部署在你自己的硬件上，而托管版本则使用供应商自有 API 和第三方平台。而一个 OpenAI 兼容密钥背后的 200 多个模型的用途，则在于所有下游环节：按各提供商的标价原样透传，0% 加价，并跨提供商自动故障转移，当已分诊的请求分发到某个状态不佳的模型时。

什么能解决这个悬而未决的问题？

有三件事可以为这件事收尾，而且没有一件需要厂商公告。有人把 850MB 的 Ollama tag 的输出与 Hugging Face checkpoint 在相同输入下的结果进行比较，就能告诉我们打包方式是否改变了答案。一条解释该上下文数值的 llama.cpp 提交或 Ollama 更新日志条目，就能告诉我们 125K 是错误，还是模型卡尚未跟上的能力。而一个已发布的音频结果——任何音频结果——都能让这个 checkpoint 脱离它目前所属的类别：一个文档齐全的模型，却有一层没有文档的打包层，以及一个完全由厂商自己提供的记分板。

此类发布背后有据可查的 AI 故障与智能体事件，均收录于OrcaRouter AI 事件档案，其中每条记录都带有自己的来源、严重程度、置信度评级和争议标记。