Liquid AI d1 与 Liquid AI d1-3B：Ollama 库称之为一个模型，而厂商称之为两个模型

为同一组权重命名有两种方式，Liquid AI d1 和 Liquid AI d1-3B比任何参数比较都更能说明这种差异。从第二个名称中减去一个连字符和一个尺寸后缀，就会得到第一个名称，因此很容易把较短的字符串当作昵称。实际列出这些模型的两个目录并不认同这种解读。Liquid AI 自己的文档索引把 d1 单独放在一行，在下载链接的位置写着“API”，并把 d1-3B 和 d1-omni-600M 放在另外两行，那里有可用的 Hugging Face 和 GGUF 链接，且在“可训练”一列中写着“否”。Ollama 的库条目正是这对名称值得写一写的原因，它把所有这些都合并到一个名为 d1 的页面中，用一句话将其描述为“来自 Liquid AI 的 3B 决策模型，基于 LFM2.5-VL-3B 构建”，并在下面恰好提供三个标签。因此，将 Liquid AI d1 与 Liquid AI d1-3B进行比较，并不是在比较一个托管端点和一个开放检查点，也不是在比较两个检查点。它比较的是一个托管端点，以及本地运行时生态在你无额外限定地说出这个词时已经认定为 d1 的那个开放检查点。下文大部分内容都在讨论你的部署实际依赖的是上述哪种解读。

关于下文数据来源的说明：诚实比它的呈现格式更重要。这里所有数字均来自 Liquid AI 自己的报告，或见模型卡，或见 10 月 7 日发布帖。Decision Index 各行由供应商使用官方评分器打分，而非提交参与公开排名；并且据我们所知，没有任何第三方独立复现过任何 d1 结果。如果某个数字是对已发布数据做算术得出的，而不是实测值，文中会注明。

这两个名字来自哪里

较短的名字出现得更早。Liquid AI 10月5日的文章将该模型介绍为 Liquid AI d1——“我们的首个决策模型”，在该版本中为多模态，能在一次前向传递中，基于文本、图像或两者构成的状态回答提出的问题，且输出 token 为零。那篇文章给出的托管价格为每百万输入 token 0.04 美元，仅对输入 token 计费，并指出图像按文本同样计费，每 32×32 图像块为 1.5 个 token，因此一张 1024×1024 图像需要 1,536 个 token。它还给出文本决策延迟为 200–300 毫秒。这些是托管服务的数据，文章明确指出，其背后的运行时是供应商自己的决策端点 api.liquid.ai/decisions/v1/systemone。

更长的名称出现在 10 月 7 日的帖子和 Hugging Face 上，而且正是它承载着可复现的细节：3.12B 参数、32,768 token 的上下文、128,000 token 的词表、十六种有文档记录的语言、一个 SigLIP2 NaFlex 形状优化的 400M 视觉编码器，以及基础链 LFM2.5-2.6B-Base → LFM2.5-VL-3B → d1-3B。那张模型卡还直白地说明，该模型不是聊天模型，也不写文本。整个本地生态系统都建立在这个检查点之上：GGUF 仓库包含 1.67 GB 的 Q4_K_M、2.87 GB 的 Q8_0，以及各 5.4 GB 的 F16 和 BF16。

没有一份厂商文档会明说的是，Liquid AI d1 和 Liquid AI d1-3B 是同一套权重。文档索引将它们分列在不同的行中。发布帖称 d1 是一个系列，而不是一个检查点。第三方报道已经注意到这一缺口，并指出厂商尚未确认这种等同关系。所以，诚实的说法很短：这两个名称公布时所用的数字，在我们能找到的任何地方都不冲突；系列版本的发布和提供服务的端点是在相隔两天内宣布的，描述也彼此相容；而厂商并没有说过它们是同一个模型。请把这种等同视为一个合理的工作假设，而不是厂商已经署名确认的事实。

本地构建实际改变了什么

Ollama 的上架既不是重新发布，也不是新的检查点。它是一个打包决策，而这种打包方式带来了三项约束，厂商自己的文档对此只字未提。第一项是标签列表：d1:latest、d1:3b 和 d1:3b-q8_0，三个标签指向同一种量化。Liquid 发布的 GGUF 仓库包含四种精度，而 1.67 GB 的 Q4_K_M——大多数人在笔记本上会首选的那一个——并不在 Ollama 的标签之列。你能拉取的是 2.87 GB 的 Q8_0，以及它在本地存储中展开后的体积；库页面显示的下载大小为 3.7 GB。

第二个是请求契约。Ollama 在 /v1/systemone 上为这些模型作答，接收一个 state 以及一个 questions 对象，并返回带有 output_tokens: 0 的类型化答案。这与厂商托管端点使用的形态相同，因此本地与托管之间的切换只是配置变更，而不是重写。第三个约束位于 Ollama 的端点文档中，而不是模型页面上，而且它比生成式模型的约束更严格：请求不含图像时必须不超过 64 KiB，含图像时不超过 32 MiB；不支持流式传输；云端托管的模型会被拒绝；图像必须是请求体中的 base64 PNG、JPEG 或 WebP——远程 URL 会被拒绝。一个请求中的每个问题都会共享图像，因此你希望只有一个答案考虑的图片需要单独发起一次调用。输入绝不会被截断，这意味着过大的 state 会返回错误，而不是被静默裁剪。这是更好的失败模式，但它仍然是你的客户端必须处理的失败模式。

有两个文档细节仍未解决，在你提交 bug 之前值得了解。Ollama 的端点参考文档称选择题类型可接受 2 到 255 个选项键，而它的决策模型能力页面则说是 2 到 26；两者之中有一个已经过时。此外，该能力页面列出的支持模型为 Nimble、Tev1、Clef 和 Clef Flash，完全没有提到 d1——尽管 d1 包自己的 readme 记录了 /v1/systemone 和 --ask 支持，而且该包要求 Ollama 0.40.4，而端点自身文档标明的最低版本是 0.35.0。请以包上写明的版本要求为准，而不是指南里的那个。

那些数字，以及它们是以哪个名字发表的

这是配对中最容易出错的部分，因为这两个名称都公布了性能数据，而这些数据的组织方式并不像你预期的那样。

• 决策指数 0.2.1 — 48.57，发布于Liquid AI d1-3B。Liquid 称这是 10B 参数以下决策模型的最佳成绩，并称其领先于得分 47.11 的 35B-A3B 模型。• 文本决策延迟 — 200–300 毫秒，发布于Liquid AI d1 的托管 API 帖子中。该开放检查点自身名称下并未附有对应数据。• 本地硬件上的单问题延迟 — RTX 4090 上为 8 毫秒，Jetson AGX Thor 上为 16 毫秒，Jetson AGX Orin 64 GB 上为 26 毫秒，Orin Nano 上为 50 毫秒，Apple M5 Pro 上为 30 毫秒。发布于Liquid AI d1-3B。• 吞吐量 — RTX 4090 上每秒 475 次决策，在将问题打包成批次的情况下，AMD MI325X 上每秒 1,106 次。发布于Liquid AI d1-3B。• 视觉 — 在十一个公开图像基准测试中平均得分 74.1，而其构建所基于的 LFM2.5-VL-3B 为 73.9。发布于Liquid AI d1-3B。• 图像消融 — 移除图像后用同一组问题作答得分为 45.1，这是厂商自身对视觉路径贡献的衡量。发布于Liquid AI d1-3B。

那份清单暴露出两个问题，而这两个问题都不致命，这恰恰正是它们被忽视的原因。托管方案的数字与本地方案的数字相差 25 到 37 倍——200–300 ms 对 8 ms——而且它们是在厂商并未以可比口径描述的对象上测得的。把这个差距解读为“本地更快”是缺乏依据的，因为托管数字是经由 API 的端到端耗时，而 8 ms 是在某款具名 GPU 上的一次前向传播。它们不是同一种测量，厂商也从未声称它们是。

第二个问题在视觉那一行。在十一个图像基准上相对基础模型提升 0.2 个百分点，这在大多数基准报告里都落在噪声范围内，所以无论这个决策头能带来什么，它都不是一个实质上更好的图像编码器。消融那一行在另一个方向上看起来要亮眼得多——加入图像后出现约 29 个百分点的摆动——但它比较的是两套不同的问题集，而不是同一套问题集的两个版本，Liquid 在文章中也这么说了。两行都有用。但两者都不足以支撑关于视觉决策质量的强主张，而且没有任何第三方运行过其中任何一项。

这两个名称在实践中出现分歧之处

对于买家而言，区别归结为四个问题，而答案并非都指向同一方向。

• 成本形态 — Liquid AI d1按输入 token 计费，采用供应商公布的价格，无需为输出 token 付费。Liquid AI d1-3B在 Ollama 的打包中是一个 2.87 GB 的下载，或从供应商的 GGUF 仓库下载为 1.67 GB，完全没有任何按调用计费。• 延迟，可衡量 — 托管路线标称每次文本决策 200–300 毫秒。本地路线公布的 8 毫秒是在模型预热后的 RTX 4090 上的一次前向传播，这是一个真实的数字，而不是请求往返。• 数据路径 — 托管路线将状态发送给供应商。本地路线将其保留在机器上，对于支持工单、医疗记录或照片而言，这通常是终结讨论的论据。• 版本固定 — Liquid AI d1在端点后面就是供应商今天所提供的任何版本。Liquid AI d1-3B在 Ollama 中是一个由你控制的固定包，代价是你得自己负责升级。

这四点背后那个令人尴尬的现实是：开放检查点与托管模型是同级关系，而不是它的替代品，并且厂商并未作出相反说明。开放检查点的模型卡建议将其用于路由与分诊、审核、意图分类、抽取校验、重排序、LLM-as-a-judge 以及护栏，并称其是在 LFM2.5-VL-3B 上后训练而成，用于单遍校准决策。托管版文章用不同措辞描述了同一组任务，并给出了托管价格。如果二者是同一个模型，那么本地版本就是托管产品的免费副本，而实验室若这样做却不说明，会很不寻常。如果它们是同一基础模型的两个微调版本，那么就不应假定已公布的数据能在任一方向上迁移。第二种解释对厂商的要求更少，也更符合我们手头的证据。

运行决策的两部分而无需运行两个技术栈

无论你最终选定哪个名称，围绕它的流水线看起来往往都差不多。一条支持工单队列会拿到一个针对目标团队的选择题、一个判断是否正在申请退款的布尔问题，以及一个衡量紧急程度的评分问题——一个状态、三个答案、一次通过。这两个名称真正分道扬镳的地方，在于这个决策会控制一次对你租用而非自建的生成式模型的调用。那次调用是一个不同的问题，有着不同的失败特征，而它也正是在整条流水线中d1是否正确最无关紧要的一环：一个概率为 0.98 的路由答案，紧接着你所路由到的模型返回一个 502——无论哪种情况，都是一次失败的请求。

我们不托管任何 Liquid AI 模型——写这篇文章之前我们查过自己的目录——所以这里的一切都不是关于通过我们来调用这些权重的说法。我们做的是决策另一侧的那一层：一把 OpenAI 兼容密钥，供经分诊的请求扇出到的那些模型使用，按各家供应商的标价原价透传、0% 加价，因此厂商降价当天就能落到你手上，而不是等到合同续签；还提供跨供应商的自动故障转移，让经分诊的请求即使被路由到的模型下线也能存活。如果你第一次把决策模型接入流水线，这一半正是值得做到平淡无奇的部分。

不同情况下使用哪个名称

如果你想本周就试用这个模型，又不想维护一个值得打理的 Python 环境，那就使用本地运行时所用的名称。拉取 Liquid AI d1从库中获取，接受 Q8_0 和 3.7 GB，并把 64 KiB 的请求上限和禁止流式传输的规则视为设计约束，而非麻烦。第一天你就能获得真正的端点、真正的类型化回答，而且没有按调用计费。

如果你需要比 Q8_0 更小的占用空间，那么应该使用的名称是Liquid AI d1-3B，因为 1.67 GB 的 Q4_K_M 构建位于厂商的 GGUF 仓库中，而不在库条目里。这一事实是如今这两个名称之间最实际的差异，也是最容易被那些只读了库页面便就此止步的人所忽略的一点。

如果你要把这个展示给付费用户，并且首先需要准确性证据，那么这两个名字目前都帮不了你。我们找不到任何针对 d1 模型的独立评估，Decision Index 的各行是自评的，而且供应商根本没有发布音频决策基准。你能做的是对模型已经返回的置信度值进行监测——该值在 0 到 1 之间，反映的是概率在多大程度上偏向某一个答案，而不是该答案正确的可能性——然后在你自己的流量上找出模型不确定的地方。这种测量比上面任何幻灯片都更有价值，而且只需要一天。

决策模型是这条流水线中廉价的那一半。它路由到的生成模型，才是需要合同的那一半——一个兼容 OpenAI 的密钥承载着经过分诊的请求所扇出到的各个模型，每个模型都按其提供商的标价透传，加价 0%。

将蒸馏检查点的规模与其自身完整发布版本进行对比，也是核对记录的好时机：围绕小型 Liquid 模型已记录的 AI 事件和智能体故障，都汇集在 the OrcaRouter AI Incident Archive中，其中每条记录都带有各自的来源、严重程度、置信度评级和争议标记。