Liquid AI d1-3B 登陆 Ollama：为决策模型打造的安静本地端点

Ollama 的模型库中出现了一个新的 d1，它并非聊天模型。条目用一句话描述它——“来自 Liquid AI 的 3B 决策模型，构建于 LFM2.5-VL-3B 之上”——而这短短一句话包含了两个最关键的事实。Liquid AI d1-3B，这个由 Liquid AI 在 Liquid AI LFM2.5-VL-3B 之上构建、并于 2026 年 10 月 5 日以开放权重形式发布的小模型，如今已被打包好，只需一次 pull 就能把它放到你自己的机器上；并且它仍然像底层检查点一样，对带类型的问题返回经过校准的概率，而不是生成文本。如果你的流水线中有分诊、路由、审核或门控步骤，这是该特定模型系列首次只需一条命令即可运行，无需 API 密钥、无需按调用付费，也不会有任何状态文本离开你的硬件。

不过，这里的“quiet”一词确实在发挥实际作用，因此值得精确说明：这个故事中哪一半有文档记录，哪一半没有。Liquid AI 自己的博客从未提及 Ollama：该实验室最近的一篇文章发表于 2026 年 10 月 13 日，介绍的是 LFM2.5 系列中的另一个模型；而它的两篇 d1 文章——10 月 5 日的视觉公告和 10 月 7 日的“Open d1”发布——描述的是权重、API 和基准分数，而不是本地运行时。Ollama 针对 d1 的库页面也没有任何公告，厂商的文档索引也同样没有；索引中将 GGUF 勾选为可用于 Liquid AI d1-3B及其支持音频的同系列模型 Liquid AI d1-omni-600M，同时仅将 llama.cpp、Ollama 和 MLX 列为通用部署选项。确实存在的，是一个已发布的软件包、一个带有可验证摘要的注册表条目、一份可用的 readme，以及一个下载计数器；在本文写于 2026 年 10 月 15 日时，该计数器的读数为 10.4K。不存在的，则是厂商一句“我们做了这件事”的说明。

该列表实际包含的内容

页面上列出了三个标签——d1:latest、d1:3b 和 d1:3b-q8_0——而这三个都解析到同一个清单摘要 8c2d9ddae441。这是理解该页面首先要明白的一点：库中的“3 个模型”计数器统计的是标签数，而不是检查点数量。一个产物，三个名称，3.7 GB，32K 上下文窗口，并支持文本和图像输入。如果你原本希望能挑选一个尺寸或一种量化版本，那么目前还没有任何可选项。

页面背后的注册表比页面本身提供的信息更多。该软件包的配置数据块报告：模型系列为 lfm2，模型类型为 2.7B，文件类型为 Q8_0，最低运行时为 Ollama 0.40.4。它以两个权重层分发：一个 2.87 GB 的生成模型和一个单独的 856 MB 投影器。第二层是视觉编码器，它的存在表明本地构建保留了多模态路径，而不是把 d1 精简成纯文本——模型仍然可以同时读取一张照片和一张支持工单，并就两者回答问题。本页面上看似矛盾的两个数字——描述中的“3B”和注册表中的“2.7B”——最好理解为主干与整体：Liquid AI 的模型卡显示该检查点有 3.12B 参数，其中包括一个 400M 参数的视觉编码器，而语言主干是较小的那个数字。这个算术是我们的，不是供应商的，而且它是作为一种解释而非规格提供的。

库页面上任何地方都没有一个具体的日历日期。它报告的是相对时间戳——在抓取那一刻显示"2 小时前更新"——外加一个下载计数器，这意味着这条列表最初出现的日期无法从列表本身得知。带日期的锚点全都在 Hugging Face 和厂商那边：Liquid AI d1-3B的权重仓库创建于 2026 年 10 月 5 日，配套的 GGUF 仓库创建于 10 月 6 日，而 Liquid AI 于 10 月 7 日发布了它的发布公告。如果你非要给"它是什么时候可以在本地运行的"定个日期，那么今天诚实的答案是：这个包已经存在，而且此刻正被拉取，而 Ollama 之外的任何人都说不出它是在哪个早上上线的。

为什么包装活动是一场真正的活动

Ollama 于 2026 年 9 月 29 日开辟了一个决策模型类别，当时它发布了 /v1/systemone 端点和 --ask CLI 标志，面向那些能在单次前向传播中回答类型化问题的模型。Nimble 和 Clef 是最早跨过这道门的两大系列。新的 d1 软件包所添加的东西，与新增一行基准测试结果不同：它把一个此前要么存在于带有内置模型类的 Python 环境中、要么位于托管端点背后的模型，变成了只需一条命令即可进行的本地推理。

这份约定值得重申，因为它并不是大多数读者所说的“运行模型”。你把一个状态——一个字符串、一个 JSON 对象、一个数组，或一个字符串加图像——以及一组具名问题交给 d1，然后拿回答案，完全没有任何生成的 token。noul 是一个是/否问题，以 0 到 1 之间的单个概率作答。choice 返回选中的标签、一个置信度，以及针对你所提供选项的完整概率图。score 把该状态放到一个由二到十级组成的有序评分量表上，并返回按概率加权的等级以及每个等级的概率。一个状态，最多 64 个问题，对输入进行一遍处理。Ollama 自己针对支持工单的示例响应返回 usage.output_tokens: 0，这是对该设计最简洁的说明。

对于任何流水线已经通过 HTTP 调用决策模型的人来说，本地路线会同时改变三件事：延迟，因为请求不再离开本机；成本，因为没有按调用计费的计量；以及数据处理，因为你正在分类的工单文本和照片永远不会经过网络。如果涉及的状态是客户的消息或内部文档，最后一点通常就是唯一需要提出的理由。

运行它，以及文档对其施加的限制

有三种受支持的接入方式，它们都记录在库页面上。CLI 路径是 ollama run d1 --ask "是否正在请求退款？"，其中状态通过管道从文件传入，另外两种问题类型则使用 --choice 和 --level 标志。HTTP 路径是向 http://localhost:11434/v1/systemone 发送 POST 请求，携带 model、state、可选的 images 数组和 questions 对象。SDK 路径将 TypeSafe 的 Python 客户端指向 localhost，此时 API 密钥会被忽略，任何占位值都可以使用。

这些限制来自 Ollama 的端点文档，而不是来自 Liquid AI，并且它们比生成式模型的限制更严格：请求在无图像时必须不超过 64 KiB，带图像时不超过 32 MiB，不支持流式传输，云端托管的模型会被直接拒绝，而且图像必须是随请求体发送的 base64 PNG、JPEG 或 WebP——远程 URL 会被拒绝。一次请求中的每个问题都会共享图像，因此，一张你只想让第一个答案考虑的图片，必须作为单独的一次调用发送。输入永远不会被截断，这意味着过大的状态会是错误，而不是被静默裁剪的提示词。

两个文档细节值得标记为未解决。Ollama 的端点参考将 choice 类型描述为接受 2 到 255 个选项键，而决策模型的能力页面则说 2 到 26——两者中有一个已经过时，而且并不明显是哪一个。另外，能力页面将其支持的模型列为 Nimble、Tev1、Clef 和 Clef Flash，完全没有提到 d1，尽管 d1 软件包自己的 readme 说明它可通过 /v1/systemone 和 --ask 工作。该软件包要求 Ollama 0.40.4；端点本身在文档中的最低版本要求是 0.35.0。这些都不构成会阻止你拉取该模型的矛盾，但请以该软件包上的版本要求为准，而不是能力指南中的那个。

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

现在是最需要谨慎对待的部分。附着于此模型的所有性能数据都出自 Liquid AI，而且据我们所知，并不存在对Liquid AI d1-3B的独立评估。厂商报告的结果——在 Ollama 页面和模型卡上反复出现——如下：

• 决策指数 0.2.1 —— d1-3B 为 48.57，而 Decider 35B-A3B 为 47.11，Liquid 称这是参数量低于 10B 的决策模型的最佳得分。• 视觉 —— 在十一项公开图像基准测试中平均为 74.1，而其构建所基于的 LFM2.5-VL-3B 基础模型为 73.9。• 延迟 —— 在 RTX 4090 上每次决策 8 毫秒，在 AMD MI325X 上为 9 毫秒，在 Apple M5 Pro 上为 30 毫秒。• 吞吐量 —— 当问题打包成批次时，在 4090 上每秒 475 次决策，在 MI325X 上为 1,106 次。• 消融 —— 同一组问题在没有图像的情况下回答得分为 45.1，这是 Liquid 自己对视觉路径贡献程度的衡量。

视觉那一行才是应该给预期降温的地方。在一组图像基准测试上比基础模型提升 0.2 个点，这落在大多数基准测试报告的噪声范围之内；无论这个决策头能带来什么，它都不是一个实质性更好的图像编码器。消融实验那一行则从另一个方向更值得玩味——加入图像后大约有 29 个点的落差——但它比较的是两套不同的问题集，而不是同一套问题集的两个版本。而决策指数是一件第三方评测工具，Liquid 是在它上面给自己的条目打分，而不是把条目提交去做公开排名，所以请把 48.57 当作一个用别人的尺子量出来的厂商自述。速度数据同样未经核验：在一个 30 亿参数模型做单次前向传播的情况下，4090 上 8 毫秒是个合理的数字，而且至今仍然没有人发表过一份不是自己跑出来的运行结果。

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

OrcaRouter 并不提供Liquid AI d1-3B。在撰写本文之前，我们已核查过自己的目录——共 207 个模型，其中没有一个是 Liquid AI 的，也没有一个是决策模型——所以，如果你想通过 API 而不是自有硬件来调用 d1，那么目前可用的托管途径就是厂商自己的决策端点 api.liquid.ai/decisions/v1/systemone，其中付费的 d1 层级可处理图像，而免费的 d1:free 层级仅支持文本，此外还有可能被其他第三方平台接入。本文中的任何内容都不应被理解为我们在托管该模型。

我们所做的事，与这个模型所解决的问题相邻。决策模型之所以存在，是因为流水线需要一种廉价、确定性的方式来在多个选项之间做选择，而 d1 自己文档中给出的示例就是一张被路由到目标团队的工单——这是一个比我们所处层级低一级的路由问题。当这一决策决定是否要调用一个你租用而非自建的生成式模型时，OrcaRouter 就是一个兼容 OpenAI 的密钥，可访问 200 多个托管模型，按提供商标价计费，0% 加价透传，因此供应商降价在生效当天就能传导到你这里，而不必等到下一次合同续签。而且，由于这条流水线中本地的那一半才是你真正拥有的那一半，风险就落在托管的那一半上：跨提供商自动故障转移让你路由过去的模型宕机时，经过分诊的请求依然能存活。这两点都不是使用 3B 决策模型的理由。它们是理由，说明决策另一侧的那一环不应成为单点故障。

怎样才能让它从一则包装说明变成一段故事？

五件事，其中任何一件都会改变解读。Liquid AI 承认这个移植版本，或者其文档索引把 Ollama 加入目前由 llama.cpp 和 MLX 填充的部署行。第二种量化：Liquid 自己的 GGUF 仓库在 Q8_0 之外还提供 Q4_K_M、F16 和 BF16，因此更小的本地构建在技术上是可以获得的，只是无法通过这个包获取。一条用于Liquid AI d1-omni-600M的本地路径，这个 587M 参数的姊妹模型可读取长达三十秒的音频，厂商将其标为早期研究发布版——对于端侧工作而言，它比 3B 更重要，而目前任何库中都还没有它的踪影。一个独立的 Decision Index 条目，或一条公开排行榜记录，这是整个模型系列唯一缺失的一环。以及 Ollama 把 d1 加入其决策能力页面，这是一行改动，却能告诉你这个移植是得到官方认可的，而非偶然为之。

在那之前，这个决定足够简单，可以按你自己的条件来做。如果你已经在运行较新版本的 Ollama，那么拉取只需一条命令，下载量为 3.7 GB，而它所替代的东西，要么是你不愿用客户文本去发起的托管调用，要么是一个维护成本高于模型本身价值的 Python 环境。如果你需要在这东西出现在真实用户面前之前获得关于准确性的独立证据，那么对于任何 d1 模型来说，这种证据目前还不存在，而且再多的本地打包也创造不出它。

在自有硬件上运行决策步骤，也是审视这一类问题中已经出过哪些差错的好时机：涉及决策模型且有记录的 AI 事故与智能体故障，都汇集在OrcaRouter AI Incident Archive中，其中每一条目都带有自己的来源、严重程度、置信度等级以及争议标记。