Liquid AI d1 与 Liquid AI d1-omni-600M：能听见你的开放决策模型

搜索一下 Liquid AI d1这个名字，你会找到一个拥有三十亿参数的模型，它能读取文本和图像。同一家族中的另一个开放检查点只有它的五分之一大小，可处理长达三十秒的语音，并且是两者中唯一能对声音做出任何判断的模型。它叫做 Liquid AI d1-omni-600M，如果你是通过本地运行时库而不是厂商自己的文档发现这个家族的，那你很可能从未见过它的名字。这正是本次对比要解决的问题，因为这两个模型并不是对同一个问题的竞争性答案。它们是对两个不同问题的回答，而其中只有一个涉及聆听。

以下每个数字都来自 Liquid AI 自己的材料：LiquidAI/d1-omni-600M 模型卡、配套的 d1-omni-600M-GGUF 仓库，以及 10 月 7 日同时公布这两个开放检查点的发布文章。性能数据行是由供应商在其自行维护的一个指数上评出的，而非提交用于公开排名；该文章还直言，专门的音频决策基准测试仍是一个未解决的问题。这里的任何内容都尚未被实验室以外的任何人复现。

5.87亿个参数是由什么构成的

这个头条数字背后隐藏着一种不寻常的拆分。总参数量为 587M，但它们并非单一堆栈：一个 381M 的共享主干（附带决策头）、一个 94M 的视觉编码器，以及一个 112M 的音频编码器。每一种模态都经由同一套主干权重运行，正是这一设计决策让整体保持小巧——这个模型并不是三个模型披着一件风衣，而是一个负责决策的主干，配有两种向它喂入信息的方式。

这些组件来自 Liquid 产品目录中的不同位置。主干源自 LFM2.5-Encoder-350M，这是一个双向编码器，而非其更大同门所出自的仅解码器系列。视觉塔是从 LFM2.5-VL-450M 中取用的 SigLIP2，并在主干上应用了适配器和 LoRA 更新。音频路径是一个 17 层 FastConformer 编码器，带有自己的适配器，并针对冻结的文本主干进行了微调。模型卡报告称，其上下文长度为 16,384 个 token，由文本、图像和音频位置共同共享；当存在图像时，文本会被裁剪到 896 个 token；词表大小为 65,536 个 token——是其更大同门 128,000 的一半。如果你使用的语言是该系列仅部分覆盖的语言，最后这个数字值得留意。

双向与仅解码器之分，正是任何同时运行过这两个模型的人都会觉得两者手感不同的原因。编码器形状的主干在产出任何内容之前，会一次性、双向地读取整个状态。解码器形状的那个则像语言模型那样向前读取。两者都被训练成基于某种分布、以零输出 token 的方式报告答案，因此谁都不写文本——但其底层的机制属于另一类模型，而下面讨论的准确率差距，正是这个更小的、编码器形状的设计所付出的可见代价。

三十秒的演讲，却没有什么可以为之配乐。

音频是这个检查点存在的原因。它能在生成答案的同一次前向传播中接收一段最长 30 秒、16 kHz 单声道的音频片段，并且它是该系列中唯一能做到这一点的开放权重成员。对于端侧工作而言，这并非边缘功能。在生产线上标记缺陷的摄像头，是更大的同门模型已经处理的视觉问题；而一个负责路由语音请求、对话语进行分类，或判断来电者是否在要求退款的设备，则是只有这一个模型才能被指向的问题。

这项能力之上还附加着两项约束，而两者都有文档说明，这意味着在生产环境中被它们绊倒没有任何借口。首先，一次请求只能携带图像 或音频，绝不能同时携带两者——同时传入两者会抛出 ValueError，而不是悄悄丢弃其中一个，因此这种失败是响亮的，在测试中也易于发现。其次，音频路径是在英语使用者和助手之间的对话上训练的，且音频片段被截断为 30 秒。那意味着一种说话人几何结构、一种轮次结构，以及一种口音分布。把它用于呼叫中心录音或现场音频，就是在要求模型卡中并未声明支持的行为，而这恰恰是基准测试（如果存在的话）会暴露出来的那类缺口。

这样的基准目前并不存在。发布公告把专门的音频决策基准称为"当前的一个开放问题"，并邀请社区来构建一个——对一个实验室而言，这话写得很坦诚，但对任何评估该模型的人来说，都是一项实实在在的制约。Liquid AI d1-omni-600M却要凭借一项目前无人能够衡量的能力来证明自己。厂商还完全隐瞒了推理数据，给出的理由是：该模型是处于积极开发中的早期研究版本。因此，这个 600M 模型根本没有任何延迟数字——文本没有，视觉没有，而作为全部意义所在的音频路径同样也没有。

在不凭空编造任何内容的前提下，能说的就是对已公布参数数量做算术：按照模型卡为 GPU 推荐的 float16 精度，587M 参数在考虑激活值之前，权重大约为 1.2 GB；而在相同精度下，3.12B 的同系列模型大约为 6.2 GB。模型卡还带有一个容易被略过、但不该被略过的精度警告：该模型以 float32 训练，在 GPU 上推荐使用 float16，而在测试期间，bfloat16 改变了某些行上的最高答案。如果你的服务栈默认使用 bfloat16，那么对这个模型来说，该默认设置并不安全。

为什么这个家族中较小的一半很容易被忽略

读者会来到 3B 就停下，这背后的原因是结构性的，而非偶然。Liquid AI 的文档索引在决策模型下列出了三行，而它们读起来并不一样：d1-3B和d1-omni-600M都带有 Hugging Face 和 GGUF 链接，"可训练"一栏写着 "No"，而d1则独占一行，在其他所有模型本该显示下载链接的位置上，只有光秃秃的字母 "API"。发布帖称d1是一个家族名称，却从未区分提供服务的端点和开放的检查点。于是本地运行时库会选用 3B，因为它的规模和模态数量恰好与它们想要发布的条目相符，而 600M 压根不出现在同一份列表里。

结果是这样一个模型家族：其公开的访问说明快速读来，看起来就像一个模型和一行 API。实际提供的是两个开放检查点，它们有不同的主干、不同的模态，在厂商自己的指数上得分相差 32 分，外加一个托管端点，而厂商从未确认它与任一检查点的关系。这个 600M 并没有藏在任何东西背后。它只是没有一个能通过搜索 d1 找到的名字，而且它是两者中唯一能听的。

存在的那些评分，以及唯一值得一读的专栏

在 Decision Index 0.2.1 上，厂商给出的分数是 15.95，对应Liquid AI d1-omni-600M，而更大的同门型号则为 48.57——差距之大，使这个总分作为选择依据几乎毫无用处。各项子分数比总分更有参考价值，其中一项确实出人意料。

• 知识 — 8.3 对比 23.8

• 语言——12.9 对 56.4

• 检索 — 35.0 对比 52.8

• 工具 — 15.1 对比 74.5

• 文科 — 6.8 对 36.3

检索正是小模型能守住阵地的地方：它的得分损失不到大模型的三分之一，而在其他四列中，它的损失达到 60% 到 80%。这一模式符合训练有素的编码器应有的擅长之处：将状态与内容进行匹配，几乎正是主干被构建来做的事，而且它对分层语言能力的依赖要小得多——解码器形态的同类模型是从多得多的预训练中继承来这种能力的。工具列则是相反的故事，如果你的工作负载是将请求路由到正确的函数，那么那里 59 分的差距就是值得盯住的数字。

在七个公开文本基准上，情况就没那么鲜明了。厂商报告称，600M 的平均分为 78.4，而 3B 为 82.9；小模型在 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 以四分之一的参数量击败了 2B 决策模型的 77.1 平均分。两个基准套件给出了两种表面上不同的结论，而且都是自我报告，诚实的解读是：两者都无法就音频路径得出定论，因为音频路径不在任何一个套件中。

两者真正交汇之处

尽管存在这些分歧，编程模型却是完全相同的，而这正是它们在某一特定意义上可以互换的原因。两者都对某个状态回答 noul、choice 和 score 问题，两者都会返回所选答案，并附带一个概率图和 0 到 1 之间的置信度值，而且两者都会报告 output_tokens: 0。confidence 字段是最容易被人误读的一个：它衡量的是概率在多大程度上偏向某一个答案，而不是该答案正确的几率。在一个表述糟糕的问题上得到 0.96，就是一个自信的错误答案，而这个字段不会给你任何警告。

在实践中，它们相遇之处是一种级联。用 Liquid AI d1-omni-600M进行初筛——成本低、本地运行，并且涵盖仅文本评分器无法触及的音频案例——然后把它评分尺度上处于中间附近的条目升级到更大的检查点，以获得更犀利的判断。升级规则就是 600M 已经返回的置信度和分布，因此路由逻辑不需要额外模型；而在简单条目占绝对多数的工作负载上，大多数流量永远不会到达第二阶段。这种组合之所以有效，是因为两个模型返回的是同一种对象。任意两个模型则不会。

如果那条级联最终要触发一次对你租用而非自建的生成式模型的调用，那么它底下那一层才是管线真正有意思的地方，也正是我们登场之处。把一项决策经由一连串模型来路由，恰恰正是路由规则所要应对的问题形态：OrcaRouter 把多个模型组合在同一个兼容 OpenAI 的端点之后，每个模型都按其供应商的标价原样透传，0% 加价，并在供应商之间自动故障转移，因此，若某次升级在供应商层失败，它会在备用模型上重试，而不是让整个请求失败。我们不托管任何 Liquid AI 模型——写这篇之前我们查过了——所以上文并非在声称可以通过我们调用这些权重。要点在于：决策模型是整条管线中最便宜的部分，而另一端那个借来的模型才是会挂掉的部分。

这个文件来自哪里，如果你想今天运行它的话

对于本地部署，厂商自家面向 600M 的 GGUF 仓库提供 407 MB 的 Q8_0，以及各 764 MB 的 F16 和 BF16，且未列出 4 位构建版本——因此最小的官方下载体积大约只有更大模型对应构建版本的七分之一，与一张中等分辨率图像的体积大致相当。该显卡自身的说明会以 4096 的批处理标志启动 llama.cpp 服务器，并建议在需要更长状态时将其提高到 16384，随后查询与更大模型相同的 /v1/system 端点。

本地路径唯一不提供给你的，就是音频通路的数字，因为它们根本不存在。如果你打算在真实用户面前用这套东西跑语音，那么评估就只能由你自己来搭：一组带标注的音频片段、同样这三种问题类型，以及按类别测得的应答率。这并不是在否定这个模型——一个能在单次前向中就对一段语音做出判断的 587M 检查点，与在转录步骤后面硬接一个文本分类器相比，是真正不同的工具，它值得一场真正的测试，而不是靠感觉的测试。

如果那条级联链路最终要为一次调用设门控——调用的是你租用而非自建的生成式模型，OrcaRouter 把多个模型组合在一个兼容 OpenAI 的端点之后，每个模型都按其提供商的原价（标价）直通，0% 加价。

选择全模态检查点而非纯文本检查点，也是审视这一类模型已经出过哪些问题的好时机：涉及小型多模态模型的已记录 AI 事件与智能体故障，都汇集在OrcaRouter AI 事件档案中，其中每一条目都带有各自的来源、严重程度、置信度等级和争议标记。