Liquid AI d1-omni-600M 现已支持 Ollama 拉取：一款能听懂你说话的 600M 决策模型

Liquid AI d1-omni-600M 于 2026 年 10 月 17 日 22:32 UTC 成为 Ollama 软件包。这个时间戳不是猜测：Ollama 的注册表会在每个清单上提供 ollama-push-time 标头，而 d1-omni 这个名字背后的四个标签是在当晚 22:31:25 到 22:32:13 之间被接受的，大约比本文撰写时间早四小时。该模型本身并不新——Liquid AI 以开放权重方式发布 Liquid AI d1-omni-600M 以及 Liquid AI d1-3B 于 2026 年 10 月 5 日，并在 10 月 7 日的“Open d1”文章中同时宣布了这两款模型——但直到昨晚，要在自己的硬件上运行这个具备音频能力的模型，唯一的方法仍是要么使用设置了 trust_remote_code=True 的 transformers 环境，要么使用你自己编译的 llama.cpp 构建。现在则是 ollama pull d1-omni。没有人宣布这件事：Liquid AI 的博客没有，Ollama 的也没有。

包装本身就是故事，而值得精确说明的是其中哪些部分有文档记录。Liquid AI 最新的博客文章分别是 10 月 15 日关于 d1-ultra 和 10 月 13 日关于 LFM2.5-24B-A2B 的，二者都没有提到 Ollama；该实验室自己的 Ollama 部署页面仍在教你用 ollama run hf.co/LiquidAI/... 直接从 Hugging Face 运行其 GGUF 仓库，并且从未提到任何 d1 模型。Ollama 的博客同样沉默——其最新条目是 10 月 16 日的 Reflection's Beam 和 10 月 13 日的一篇 Fly.io 集成。取而代之存在的是一个注册表条目、四个标签、一个可验证的摘要值，以及一个在本文撰写时仍在编写的模型库页面：该页面的早期抓取返回了“No readme”，而四十分钟后的抓取则返回了一份完整的、由 Liquid AI 撰写的描述，包含基准测试表和许可证部分。如果你想要过去七天里一个有日期、可核查的事件，那个页头就是。

注册表实际接受的内容

四个标签对应两个镜像，这是你拉取前首先要了解的事。d1-omni:latest、d1-omni:600m 和 d1-omni:600m-q8_0 是同一个清单——摘要为 1ba59f63e836——而 d1-omni:600m-bf16 是第二个，摘要为 c1e95fce6627。没有 F16 标签，尽管厂商自己的 GGUF 仓库发布了一个 F16 主干。

• 权重层（Q8_0 构建）——来自 d1-omni-600M-Q8_0.gguf 的 407 MB 主干，加上来自 mmproj-d1-omni-600M-BF16.gguf 的 442 MB 投影器，以及 10.5 KB 的许可证数据块和 18 字节的参数数据块，总计 849,659,968 字节。

• 报告大小——默认标签为 850 MB，600m-bf16 为 1.2 GB，两者均与库页面上显示的完全一致。

• 运行时最低版本 — 要求：配置 blob 中为 0.40.4，该 blob 还会报告 model_family: lfm2、model_type: 380.73M 以及文件类型 Q8_0。

• 上下文 — 参数 blob 将 num_ctx 固定为 16,384。

• 许可证 — 内嵌文本为 LFM 开放许可证 v1.0，其中指定 Liquid AI, Inc. 为许可方，与模型卡上的 lfm1.0 标识符一致。

那个投影器值得再看一眼，因为它比它所附着的模型还要大。直接从注册表 blob 中读取 GGUF 元数据可以看到，同一个文件里 clip.has_vision_encoder = True 且 clip.has_audio_encoder = True：197 个视觉张量分布在 12 个块中，嵌入宽度为 768，输入为 256 像素；641 个音频张量分布在 17 个块中，嵌入宽度为 512，包含 128 个 mel 频带。也就是说，SigLIP2 塔和 FastConformer 编码器都一同随多模态包传输，这正是为什么一个 381M 参数的主干会藏在一个 442 MB 的附件背后。音频能力在物理上就存在于你下载的包中；至于端点能否访问到它，则是另一个问题，留待之后讨论。

该模型有 587M 个参数，而 125K 的标识比真实值更大。

Ollama 的页面在每个 tag 上都标着“125K 上下文窗口”。而该包自带的 num_ctx 是 16,384,Liquid AI 的模型卡也用文字说明了同样的事:16,384 个 token 由文本、图像和音频位置共同分享,一旦存在图像,状态文本和问题文本就会被裁到 896 个 token。125K 这个数字是有出处的——主干 GGUF 里写着 lfm2.context_length = 128000——但那是架构的上限,不是你实际能用的窗口,而且它最容易误导那些要为长上下文分类器挑选替代模型的人。请把 16,384 当作实际可用的数值,当状态中含有一张图像时,把 896 个 token 的文本当作实际可用的数值。

其余元数据印证的是模型卡，而不是营销宣传语。主干是 18 个块、宽度为 1,024 的嵌入以及 65,536 的词表，而且它不是解码器：lfm2.attention.causal 为 False。其逐层 KV 头数显示为 0、0、8、0、0、8、……，这意味着其中大多数块根本不是注意力块，这是双向编码器血统的显现。决策头是两个块（lfm2.decision.block_count = 2），厂商保存在 config.json 中的校准常量也在这个 GGUF 里——选择题在两个选项时温度为 1.7465，三到五个选项时为 1.3999，六到十个选项时为 1.1751，十一个以上时为 1.3725；是/否题为 1.6663；评分题在三到五个等级时为 1.7301，六到十个等级时为 1.0。整个设计集中体现于此：一组固定的具名答案，一次完成评分，按问题形态校准，末尾为 output_tokens: 0。

它不是聊天模型，也不撰写文本。Liquid AI 列出了十五种语言，音频训练数据仅使用英语——说话者与助手之间的请求——并将片段上限设为 30 秒。该模型卡还警告不要在 GPU 上使用 bfloat16：在供应商自身的检查中，它改变了 0.8% 的文本行和 1.7% 的音频行中的首选答案，而 float16 在所有情况下都与 float32 一致。

音频存在于权重之中，而在有文档记录的 API 中并不存在。

在提交 bug 之前，有一处差异值得了解。库页面上的 README（由 Liquid AI 编写）在记录音频用法时，是把 base64 WAV 放进 /v1/systemone 请求的 images 数组里。供应商针对同一检查点的 Hugging Face GGUF README 则采用了不同的记录方式：用一个 files 数组将 data:audio/wav;base64,… 传入 llama.cpp 服务器。而 Ollama 发布的端点参考文档对这两种方式都未作说明：其请求 schema 包含 state、images、questions 和 keep_alive，将 images 描述为“需要具备视觉能力的模型，例如 Clef”，并且完全不包含 audio 字段，也不包含 files 字段。与此同时，Ollama 自己的决策模型指南将 Nimble、Tev1、Clef 和 Clef Flash 列为决策模型，并且只说明 Clef 模型还可以判断图像。

因此，如今对 Ollama 中音频的诚实立场是：编码器已确认存在于 blob 中，厂商的 readme 称其可通过图像工作，而已发布的 schema 并不承认它。同一模型上的图像输入则更有依据——视觉是一项有文档记载的 System One 能力，且 d1-omni 出现在 Ollama 的视觉类别列表中。除此之外还有两个较小的文档缺口：端点参考文档允许选择题最多有 255 个选项键，而决策指南说的是 2 到 26 个；该软件包的运行时最低要求为 0.40.4，高于端点文档所引用的 0.35.0。

归入愿景，而非决策

Ollama 的模型搜索将决策模型归入它们自己的类别。该类别包含九个条目——nimble-v3、pplx-decider、kev、tev1、nimble、clef-flash、clef、laya 和 strands-decider——而 d1 和 d1-omni 都不在其中。d1-omni 页面被标记为 vision 和 600m，并且它确实出现在 vision 列表中，因此浏览“决策模型”的读者不会找到最新的那个。这是可发现性问题，而不是能力问题，但如果你原本打算在 Ollama 自己的目录中比较各个决策模型系列，并因此得出结论认为这个模型不存在，那这一点就很重要。

它还意味着，d1-omni 是 Ollama 模型库中首个能够接收语音的决策模型——音频编码器已包含在该包中，而那份包含九个模型的列表里，没有其他模型带有音频编码器。端点是否会把你的 WAV 交给它，是上一节留下的未解问题，而且到你读到本文时，这最可能是唯一已经发生变化的地方。

这些数字，以及每一个数字的出处

附在Liquid AI d1-omni-600M上的每一个准确率数字都是 Liquid AI 自己的；就我们所能找到的而言，目前不存在对任何 d1 模型的独立评估——没有排行榜条目，没有第三方运行结果，也没有公开发表的对厂商评分的否定。厂商使用官方 Decision Index 评分器自行对两个 d1 checkpoint 进行了评分，而不是将它们提交到公共排行榜，并在模型卡上说明了这一点；其表格中每一个对照条目都来自排行榜 v0.2.1，这意味着该比较是一个自评分数与外部评分的数字并列放在一起。

决策指数 0.2.1 —— d1-omni-600M 为 15.95（知识 8.3、语言 12.9、检索 35.0、工具 15.1、艺术 6.8），而 d1-3B 为 48.57。

• 以基准测试作为决策依据，七次运行的平均值——d1-omni-600M 为 78.4，d1-3B 为 82.9；其中 600M 模型在 Civil Comments（95.8 对 93.0）和 PAWS-X（79.5 对 76.9）上领先，在 BoolQ（77.7 对 86.7）和 SQuAD 2.0（74.0 对 85.3）上落后。

• Fast Decisions，dev split — 76.9，供应商报告，未发布对比行。

• 速度——无可奉告。卡片上明确说明，未报告推理数据，因为这是一个仍在积极开发中的早期研究版本，所以你在别处看到的任何关于它的延迟说法，都是别人自己的测量结果。

• Ollama 页面上的固定示例数值——readme 中的完整示例显示，urgent 的回答得分为 0.998，technical 为 0.995。这些只是运行时发布的、单次请求的示意性输出，并非基准测试结果。

15.95 和 48.57 之间的差距是这张卡片上最有用的信息，因为它用厂商自己的话回答了选购问题：readme 告诉你，当文本和图像上的准确率才是关键时，应使用 d1；当规模重要或你需要音频时，则应选择 d1-omni。一个在七项公开基准上得分 78.4 的 587M 模型，若把这些分数转译为决策，就是一个说得通的边缘分类器。它不是 3B 的缩小版。

OrcaRouter 适合用在何处，又不适合用在何处

我们不提供此模型。10 月 18 日检查我们的目录时返回了 208 个模型 ID，其中没有一个来自 Liquid AI，因此这里并不是在声称可用性，我们这边也没有任何途径可以拉取它。如果你想要 Liquid AI d1-omni-600M，本地路径就是上文所述的那条，托管路径则是厂商自己的 API，以及任何接入它的第三方平台。

封装形态改变的是其周围系统的形态，而这正是我们的用武之地。决策模型几乎从来不是整条流水线：它标注的工单、它标记的帧以及它路由的转录文本，仍然需要由某个能写文本的东西来回答、总结或升级。这些生成式调用位于一个兼容 OpenAI 的密钥之后，可访问 200+ 托管模型，按提供商标价计费，以 0% 加价透传，因此供应商的价格变动当天就能传达到你这里，而不是等到新合同。而且，由于 d1-omni-600M 没有附带独立准确率证据，也没有公布延迟，把它放到真实流量前面的正确方式，是置于跨提供商自动故障转移之后——让它处理自己有把握的调用，在没把握时保留一条退出路径，而不是让 587M 参数成为你分诊步骤的单点故障。决策留在本地；回退不必如此。

什么会改变这个读数

四件事，任何一件都会把一篇打包说明变成另一篇不同的文章。Ollama 在 System One 请求架构中记录音频，这会将该 readme 中“把 WAV 塞进图像”的技巧转化为受支持的输入，并使其成为首个只需一条命令即可运行的具备语音能力的决策模型。两家公司中任何一家承认这次移植——Liquid AI 将 d1-omni 加入其部署文档的 Ollama 页面，或 Ollama 将其列在决策模型而非视觉模型下。任何人给出的速度数据，无论是否来自厂商，因为目前尚无此类数据。以及任一 d1 模型在独立 Decision Index 中的一行，这仍是整个系列中唯一缺失的一环。

在那之前，决定很简单。如果你已经在运行 Ollama 0.40.4 或更高版本，拉取只需一条命令，下载量为 850 MB，得到的是一个 587M 分类器，它通过一次对文本和图像的前向传播来回答输入的问题——而且，如果 readme 说得没错，还能处理超过 30 秒的英语语音。如果你的状态很长，请记住 16,384 个 token 的窗口和 896 个 token 的文本预算，而不是那个 125K 徽章。如果你需要在它给任何客户可见的内容打标签之前，先获得它准确的证据，那么这种证据尚不存在——对这个模型或其任何同类模型都是如此。

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