d1-2B：Liquid AI 发布了一款 1.9B 决策模型，却没有发布任何公告帖来宣布它

Hugging Face 上 LiquidAI/d1-2B 的仓库创建于 2026 年 10 月 24 日 19:30 UTC。它的姊妹仓库 d1-Omni-2B 在二十四秒后出现。到当晚结束时，两个仓库都已完整——3.84GB 的 BF16 safetensors、四十多个自定义 Transformers 代码文件、一张校准表、一个类型化问题 API——而 Liquid AI 发布的任何内容都没有说这两个模型存在。第一句提到 d1-2B 的厂商表述出现在 10 月 27 日，位于 LFM3 家族发布之中——同一篇帖子发布在 liquid.ai 和 Hugging Face 自己的博客上——作为一段关于两个决策模型的文字里的一个分句。此后没有专门文章。所以这不是一个发布故事，把它当作发布故事会凭空发明一个从未发生过的营销时刻。这是一个关于模型产物完整、公告却不完整的故事，也是关于读者仍可对此做的两件事：读仓库，以及对厂商的数字保持审慎距离，直到实验室之外有人实际运行验证它们。

砝码与判决之间的那五天

d1 系列已经发布过两次，而这两次发布都不像这一次。10 月 7 日，Liquid AI 发布了“Open d1：面向文本、视觉和音频的边缘决策模型”，其中推出了拥有 31.2 亿参数的 d1-3B 和拥有 5.87 亿参数的 d1-omni-600M，并附有一项引人注目的核心声明、一张基准测试表、延迟数据，以及一篇此后一直保持上线的博客文章。那篇文章中并没有 2B 模型。

2B 产品线遵循了不同的时间表。基础检查点 LFM3-Omni-2B 于 10 月 21 日出现。10 月 24 日 UTC 19:30 和 19:30:24，Liquid AI 创建了 d1-2B 和 d1-Omni-2B 仓库。随后，在 10 月 27 日，LFM3 发布帖将这对模型称为“从视觉模型和全模态模型专门化而来的决策模型”——这是一种描述，而不是公告。同一天，d1-2B 的四个衍生仓库上线：fp16、8 位和 4 位的 MLX 构建版本，外加一个 ONNX 导出。也没有人写过关于这些内容的帖子。

这一点重要，原因很实际。公告是厂商明确自身定位的地方：模型是做什么用的、成本是多少、面向哪个运行时、以及它不做什么。这张卡片承担了其中一部分工作，而且做得格外出色。但缺失的那篇博文留下的空白是真实而具体的，它们被列在本文末尾，而不是被粉饰掩盖。

仓库实际上会告诉你什么

抛开包装不谈，这个检查点就是一个小型、规格高度明确的多模态分类器，它拒绝生成文本。每次调用都会返回附带概率的类型化答案，并且output_tokens: 0。模型卡直言不讳：d1-2B“不是聊天模型”。

• 参数 — 1.92B，以单个 3.84GB 的 BF16 safetensors 文件形式发布。

• 基础版 — LFM3-VL-2B，基于 LFM3 骨干网络：24 层，其中 13 层为门控短卷积，5 层为滑动窗口注意力，6 层为全局注意力。

• 上下文——128K 个 token 和 128,000 个 token 的词表，是 d1-3B 的 32,768 窗口的四倍。

• 输入——一种状态，可以是文本或任意 JSON 值、图片或视频，以及任意数量的命名问题，全部放在一个媒体列表中。视频是 d1-3B 未列出的能力。

• 输出——是/否、从命名选项中择一、有序评分、从文档中读取并附带其位置范围的值或日期、带 p10–p90 区间的数字、边界框，或某个对象的每个实例及其计数。每一项都带有概率。

• 语言 — 十六种：英语、阿拉伯语、中文、法语、德语、意大利语、日语、韩语、葡萄牙语、西班牙语、越南语、泰语、印尼语、印地语、俄语、波兰语。

• 许可 — LFM Open License v1.0。年收入低于 10,000,000 美元时授予商业使用许可；许可文本将该数字定义为阈值，而超过该阈值的商业使用权利以不超过该阈值为条件。

• 速度 — 在 H100 PCIe 上单次决策耗时 5.7 毫秒，在 AMD MI325X 上为 3.8 毫秒；将 64 个状态批处理到一次调用时，每秒分别可完成 1,132 和 1,699 次决策。在 Apple M5 Pro 上，单问题耗时为 18.6 毫秒。

值得争论的说法：它胜过了它所取代的模型

Liquid AI 的模型卡提出了一项毫不含糊的比较性论断：d1-2B“{{1}}平均而言，并在我们由一百多个决策基准组成的榜单上，领先于各开放 d1 模型；其规模不到 d1-3B 的三分之二，却领先于 d1-3B。”{{/1}}这是一个 1.92B 模型针对 3.12B 模型作出的强硬声明，而且它是可核查的，因为模型卡将全部四个开放 d1 模型列在同一张表中，并由同一评分器针对相同项目评分。

最显眼的数字是 Decision Index 公共套件 0.3 版上的 51.1 对 49.0——领先 2.1 分。在任何人将其解读为一场毫无保留的胜利之前，有两点必须同时说明。首先，d1-3B 自己的卡片在 Decision Index 0.2.1 上报告的是 48.57，而 48.57 与 49.0 之间的差异来自指数版本，而不是模型有所改进；d1-2B 的卡片指出，所有四个模型都在相同条目上重新评分，因此 d1-3B 的少数数字与其自己的卡片不同。其次，公共套件只是决定公共排行榜排名依据的一小部分：重建该套件的独立评估者描述称，37 个公共基准按分数的 20% 加权，其余部分来自只有维护者才会运行的私有测试。

49.0 作为一个数字之所以可信——尽管 d1-2B 本身没有外部核验——在于已经有人在这个确切版本上复现了 3B。Efraín Garay 在 10 月中旬对 Decision Index 0.3 的 6,000 条请求分层样本运行了 d1-3B，得到 49.11，而 Liquid 自己在相同数据行上为 49.04，在完整套件上为 48.99。这是一次在 0.1 分以内的复现。它并不能验证 d1-2B 的 51.1——没有第三方运行过它——但确实验证了 51.1 所在表格背后的评分方法。

较小模型不占优势之处

“在大多数单项基准上领先”这句话在这句话里起着不动声色的作用。在同一轮运行的表格中，对于影响部署决策的二十多行，d1-3B 仍赢下其中三行：

• 快速决策 — 3B 为 59.3，对 58.8；这是以速度为导向的决策基准中，较大模型唯一略占优势的一项。

• 类型化决策—— 65.0 对 61.3，相差 3.7 个百分点；当输出必须是有类型的值而不是标签时，这是支持较旧模型的最清晰单一论据。

• AI2D——在图表阅读基准测试中，79.9 对 76.7，更大的视觉塔仍能换来更高的准确率。

在其他所有地方，排序都发生了反转，有时还相当剧烈。VisualWebBench 上，d1-2B 为 96.2，而 d1-3B 为 71.4。ImajevBench v2.0-lite 为 75.5 对 64.0。MMMU-Pro 为 26.4 对 18.5——两者都低到不应信任任一模型进行困难的多模态推理，这一点值得直说，而不是把 7.9 分的差距呈现为一场胜利。视觉平均分分别为 70.2 和 65.4。

这张卡无法填补的三处空缺

缺失的公告会以缺失的产物形式显现出来。这些都不是模型本身的缺陷；每一条都是该模型如今比其基准线所暗示的更难被采用的理由。

• 没有 GGUF。d1-3B 和 d1-omni-600M 都在 10 月 6 日获得了 GGUF 仓库，这距离它们的权重发布仅一天；随后 d1-3B 又推出了 8 位权重-激活构建和四个 MLX 变体。截至 10 月 27 日，d1-2B 已有 MLX 和 ONNX 构建，但没有 GGUF——因此，尽管基础模型 LFM3-VL-2B 在 10 月 19 日有了自己的 GGUF，决策头仍没有发布 llama.cpp 路径。如果你的边缘技术栈是 llama.cpp，这就是全部情况。

• 没有价格，也没有端点。模型卡未列出托管 API、按 token 计价，也未列出推理提供商。对于开放权重版本来说，这并不罕见，但这意味着使用 d1-2B 的唯一方式就是自行运行，而且模型卡的部署部分只写到一段 Transformers 代码片段就结束了。

• 无独立基准测试。 截至10月28日，该仓库显示 44 次下载和 13 个点赞。现有的独立决策模型评估涵盖 d1-3B 和 d1-omni-600M，不涵盖此模型。上文所有性能数据均为 Liquid AI 自身的数据。

模型卡本身还说明了一项限制：回答“在状态超过约 64K token 后就会变得不太可靠”，这只是宣传的 128K 窗口的一半；估计值在计数和评分方面可靠，但在自由数量方面则不那么可靠。一个自己的模型卡能告诉你它在哪些方面会退化的模型，比不能做到这一点的模型更有用，但 128K 这个标题数字应被理解为容量数字，而不是工作范围。

第一次部署实际上是什么样子

实用路径是使用 Transformers 5.19 或更高版本，配合 trust_remote_code=True，在 GPU 上使用 bf16，并调用 system_one 或 system_one_batch 调用。没有采样参数，因为不存在采样。唯一重要的调优旋钮是 set_size，其默认值为训练时的 16；提高它会换来速度，但会牺牲文本准确性。

卡片自身的建议正是大多数团队跳过的一步：用你自己使用场景的数据来校准决策阈值。0.62 的概率单独来看毫无意义。如果你在做支持工单分流或标记文档，那么区分“升级”与“自动处理”的阈值必须在你自己的标注样本上拟合，因为供应商的校准是在他们的样本上拟合的。

它契合的形态是流水线中的一个步骤，而不是一个助手：分流、审核、意图分类、表单信息抽取、重排序、视觉检查。这些正是流水线已经会调用多个模型的地方，也正是决策周围的生成步骤通常来自托管 API 的地方。OrcaRouter 目前不提供任何 Liquid AI 模型——包括这一个——因此运行 d1-2B 意味着要自己运行。路由器的用武之地在于链条的其余部分：一个 OpenAI 兼容密钥即可访问 200 多个托管模型，一个能把各步骤组合成单次调用的路由 DSL，以及当提供商宕机时自动故障转移，这样你 GPU 上的决策节点就不会受制于旁边的生成节点。

什么会改变这个故事？

四件事，按重要性从高到低排列。GGUF 会让 d1-2B 与其同系列模型处于同一运行时基础上，并让边缘部署的卖点真正成立。一篇专门的文章会告诉买家，除了模型卡上列出的流水线步骤之外，Liquid AI 认为这个模型适合什么用途。一次独立运行——最好是复现 d1-3B 时所用的同一个 6,000 行样本——会把 51.1 从厂商宣称变成实测结果。而一个托管价格会让自建还是购买这个问题至少变得可以回答。

在此之前，一个坦诚的总结虽然范围有限，却很有用：一个 1.92B 的决策模型确实存在，其代码仓库完整到足以进行评估，它在基准测试中对 3B 的领先优势在厂商自家同一次运行的表格上是真实的，而在其他任何地方都未经验证；而缺失的公告则让它少了大多数团队在把模型放进流水线之前所需要的那些配套——运行时、端点、价格。如果你已经在用 Transformers，并且想要一个支持视频输入、128K 上下文的分类器，那它值得你花一个下午。如果你需要 llama.cpp 或托管端点，那就再等等。