Liquid AI d1-omni-600M 与 Liquid AI d1-3B：d1 家族中你真正需要的是哪一半？

Liquid AI d1-omni-600M 和 Liquid AI d1-3B 于 2026 年 10 月 5 日相隔不到八小时先后上传到 Hugging Face，并在 10 月 7 日的同一则公告中一起发布，这让通常的那个问题——哪个更新、哪个更好——成了一个错误的问题。它们是一次刻意权衡的两端。Liquid AI d1-3B 是成品：3.12B 参数，在厂商评分的 Decision Index 0.2.1 上得到 48.57，有基准测试表格，延迟一直测到 Jetson Orin Nano，发布帖中称其为同规模下最高的决策质量。Liquid AI d1-omni-600M 是实验品：587M 参数，在同一指数上得到 15.95，具备 3B 所没有的音频输入，而模型卡直言它是一个早期研究版本，没有推理数据，因为它仍在积极开发中。在两者之间做选择不是一个质量决策。它是一个关于你需要家族底端的额外模态，还是顶端的额外准确率的决策，而数字支持这一分野，而不是将其模糊化。

以下所有内容均来自两份模型卡和 10 月 7 日发布帖，并沿用发布帖自身的标注：Decision Index 上的 d1 各行由 Liquid AI 使用官方评分器评分，而非提交至公开排行榜；此处的任何内容均未经独立复现。

两条永远不会交汇的主干

d1 系列并没有把单一配方按比例缩小。这两个检查点从 Liquid 模型目录的两端出发，在中间相遇。

Liquid AI d1-3B构建于 LFM2.5-VL-3B 之上，这是该厂商于 2026 年 8 月推出的仅解码器视觉语言模型。其基础模型是通过将 LFM2.5-2.6B 的权重与 LFM2.5-VL-3B 的文本骨干进行平均，然后在不同随机种子和数据混合下微调检查点，再将它们重新合并而成。它配备 SigLIP2 NaFlex 形状优化的 400M 视觉编码器、32,768 个 token 的上下文、128,000 个 token 的词表，以及十六种有文档记载的语言。

Liquid AI d1-omni-600M则来自另一个方向。它的主干是 LFM2.5-Encoder-350M，一个双向编码器，先在决策任务上进行微调，然后分阶段扩展——用于音频的 17 层 FastConformer 编码器加适配器，随后音频编码器针对冻结的文本主干进行微调，接着是从 LFM2.5-VL-450M 移植来的 SigLIP2 塔，配有适配器，并对主干进行用于视觉的 LoRA 更新。最终模型由这些 LoRA 更新合并而成，并与之前的检查点进行平均。它最终总共有 587M 参数：381M 的共享主干与决策头、94M 的视觉编码器和 112M 的音频编码器。

仅解码器与双向架构才是要抓住的重点。3B 读取状态并做出决策，就像语言模型生成词元序列那样，一次一个方向。600M 则一次性读取整个状态并做出判断，这正是你从一个从未为生成而构建的编码器那里会预期到的行为。两者都被训练为以零输出词元的方式依据模型的分布给出答案，但底层的机制并非同一类模型，而下方所见的准确率差距，正是这个更小的、编码器形态设计所付出的可见代价。

决策指数的分布区间很大，而各分项得分比总分更有意思

在 Decision Index 0.2.1 上，Liquid 报告 Liquid AI d1-3B 为 48.57，Liquid AI d1-omni-600M 为 15.95，而 Winnow-12B 为 50.02。这是同一个实验室在同一天发布的两个检查点之间 32 分的差距，而细读五个子分数就能解释它从何而来。

• 知识 — Liquid AI d1-3B 为 23.8，相比之下 Liquid AI d1-omni-600M 为 8.3

• 语言 — 56.4 对 12.9

• 检索 — 52.8 对比 35.0

• 工具 — 74.5 对 15.1

• 文科 — 36.3 对 6.8

检索是小模型唯一能守住阵地的地方，在那里它损失的不到 3B 得分的三分之一，而在其他四个类别中，它要损失 60% 到 80%。这一模式与 600M 的本质相符：它是一个经过训练的编码器，具备真正的表征能力，能将状态与内容进行匹配，而从在远比它更多的语言上预训练的解码器继承来的分层能力，3B 拥有得多，它却少得多。如果你的工作负载是检索形态的决策——这段文字是否回答了这个问题、这些文档中哪一篇是相关的——那么 600M 的表现画像就没有它的总分所显示的那么差。如果你的工作负载是工具路由决策，那么那一列中 51 个百分点的差距就是那个值得你盯着看的数字。

文本基准表所呈现的情况比该指数更为温和，这一点在任何一个数字被用来论证之前都值得了解。在七个公开基准上，3B 以 82.9 的均值领先，而 600M 达到 78.4。600M 实际上在 SQuAD 2.0（74.0 对 85.3）、PubMedQA（61.3 对 66.0）、BoolQ（77.7 对 86.7）和 XNLI（74.7 对 85.0）上以微弱差距落败，但在 Civil Comments 毒性检测（95.8 对 93.0）和 PAWS-X 释义识别（79.5 对 76.9）上获胜。Liquid 自己的说法是，600M 以四分之一的参数量击败了 Decider 2B 的 77.1 均值。两套基准套件，两种不同的表面结论，且均为厂商报告——这就是证据所支持的全部，仅此而已。

600M 有而 3B 没有的

容忍 32 点指数差距的原因在于，Liquid AI d1-omni-600M 能做到一件 Liquid AI d1-3B 做不到的事，而这并非保真度上的差异。

• 音频 — Liquid AI d1-omni-600M 通过其 FastConformer 编码器，每次请求最多可处理 30 秒的语音；Liquid AI d1-3B 则完全不支持

• 模态混合 — 600M 接受文本与图像或文本与音频，如果两者同时传入，则抛出 ValueError；3B 接受文本与图像

• 上下文窗口——600M 在文本、图像和音频位置上共有 16,384 个 token，当存在图像时文本会被裁剪至 896 个 token；3B 为 32,768 个 token

• 词汇表 — 600M 为 65,536，3B 为 128,000

• 精度——600M 模型卡建议在 GPU 上使用 float16，并警告 bfloat16 在一些行上改变了首选答案；3B 附带 15 种量化，包括一个 w8a8 构建版本

• 语言 — 600M 列出了 16 种语言，与 3B 的 16 种属于不同的一组；其音频被描述为基于一位英语使用者与助手之间的交流训练而成，而这只是生产环境音频流所包含内容的一小部分

音频训练说明很容易被一眼略过，但它不该被略过。一个仅用英语“说话人与助手”对话数据训练出来的模型，只见过一种说话人格局、一种轮次结构和一种口音分布。把它部署到呼叫中心音频或现场录音上，等于要求它表现出模型卡并未声称具备的行为；而发布文章也坦承，目前并不存在可用于检验它的音频决策基准——Liquid 称这“目前是一个开放问题”，并邀请社区来构建一个。

延迟：一个同级包含表格，另一个包含脚注

对于决策模型，值得关注的数字是端到端延迟，因为没有需要计时的解码过程。Liquid 为 3B 发布了完整的一组数据，而 600M 则没有。

• 一个问题——在 RTX 4090 上为 8 毫秒，在 MI325X 上为 9 毫秒，在 Jetson AGX Thor 上为 16 毫秒，在 Jetson AGX Orin 64 GB 上为 26 毫秒，在 Orin Nano 上为 50 毫秒，在 Apple M5 Pro 上为 30 毫秒

• 在一个状态上提出三个问题——在 RTX 4090 上耗时 21 毫秒，在 AGX Thor 上耗时 20 毫秒，大约是单个问题成本的 1.3 倍，而不是 3 倍

• 一个 3.4K token 的状态——在 4090 上为 102 ms，在 Thor 上为 220 ms，在 Orin Nano 上为 1,640 ms

• 打包吞吐量——在RTX 4090上每秒475次决策，在MI325X上每秒1,106次

• 384px 图像 — 4090 上 17 ms，MI325X 上 18 ms

那些数字仅涉及 Liquid AI d1-3B。对于 Liquid AI d1-omni-600M，模型卡说明未报告推理数值，因为该模型是仍在积极开发中的早期研究版本。并不是说小模型更慢——几乎可以肯定恰恰相反，因为参数量的五分之一在同一精度下并不会变慢——而是根本不存在任何数字，把 3B 的毫秒数拿来当作 600M 的，会是一种看似合理的捏造。在完全不编造任何东西的前提下，可以说的是：在模型卡推荐的 float16 精度下，587M 参数在考虑激活值之前大约是 1.2 GB 的权重，这是基于已公布参数量所做的算术，而不是一次测量。

对于大多数工作负载来说，层叠才是真正的答案

因为这两个检查点是同时发布的，并且返回同一类对象——一个概率、一个带置信度的标签，或一个有序分数——所以它们能以两个任意模型无法做到的方式组合起来。600M 可以负责筛选，3B 可以负责裁决。用 Liquid AI d1-omni-600M 对传入的条目打分，并将它放在其量表中间附近的那些升级给 Liquid AI d1-3B，以获得更精准的判断。升级规则就是 600M 已经返回的置信度和分布，因此路由逻辑不需要额外的模型。在绝大多数条目都很容易的工作负载上，大部分流量永远不会到达 3B，大部分钱也永远不会花出去。

这种模式也是这两个模型值得放在路由器后面运行的原因。通过 OrcaRouter，两者将共用一个 API 密钥，按各提供商的标价原样传递，0% 加价，因此级联只是一条路由规则，而非第二次集成；在提供商层失败的升级会在备用方案上重试，而不是让请求失败。自动故障转移在这里比在稳定模型上更重要，因为这对组合中的一半是一个检查点，其行为被供应商自己描述为正在积极开发中。

这些都不是可用性声明，而这个区别值得明确说明：开放的 d1 检查点不在我们的目录中。供应商的途径是下载权重并在本地运行——llama.cpp 支持在首日就覆盖 Apple、AMD、Qualcomm 和 NVIDIA 硬件——或者通过供应商自己的 API 和第三方平台来访问它们。

一次完成选择

如果你需要文本和图像，而且答案必须正确，那就选 Liquid AI d1-3B。它拥有基准测试、延迟表、更宽的上下文、更大的词汇量以及量化方案，并且它是 Liquid 定位为同规模下质量领先者的那对模型中的一员。

如果你需要在决策路径中加入语音，就选 Liquid AI d1-omni-600M，因为它是这一系列中唯一一个至少还能接受音频的开放权重选项；同时也要接受，在有人发布音频决策基准或那个被保留的视觉划分之前，你采用它靠的只是感觉和一个演示。

如果你还不知道其中哪一个描述了你的工作负载，就从 3B 开始，并测量它返回的置信度。子分数就是线索：一个位于工具或语言列的任务在 600M 上会表现很差，而检索类任务则是小检查点比其总分所暗示的更接近的唯一地方。这个系列的存在是为了让你可以用准确率换取占用空间，而只有当你清楚你的任务属于哪一列时，这种权衡才是安全的。

通过 OrcaRouter，两个模型都置于同一个 API 密钥之下，只需一条路由规则即可，而无需再单独集成；并且在提供商层失败的升级会在备用方案上重试，而不是让请求失败。