d1-2B 对比 Liquid AI d1-omni-600M：当决定性输入是声音时

把一条语音留言和一张拍照的发票放到这两个模型面前，只有一个能回答，而且不是得分更高的那个。d1-2B可读取文本、JSON、图片和视频，完全无法接收音频。Liquid AI d1-omni-600M可读取带图像的文本，或带最长 30 秒语音的文本，但不能在同一请求中同时接收音频和图像。正是这一单一不对称性，在参考任何基准之前就决定了大多数真实部署。尽管如此，下面仍是诚实的对比版本：587M 模型真正有竞争力之处，1.92B 模型远不能被取代之处，以及唯一一种同时使用两者、又不假装它们可以互相替代的流水线模式。

这个决定是模态问题，而不是分数问题。

决策模型接收一个状态和一组具名问题，并返回每个答案的概率，不生成任何 token。状态就是整个输入，而状态的 type 是硬性约束。d1-2B 的模型卡列出文本、JSON、图片和视频。Liquid AI d1-omni-600M 的模型卡列出带图像的文本，或带音频的文本——并且代码强制排除这种情况：同时向 system_one 传入一张图像和一段音频会引发 ValueError。

所以第一个问题并不是哪个模型得分更高，而是你需要评判的东西是以像素、文本还是波形的形式呈现。如果它以波形的形式呈现，那么在这一对模型中就只有一个答案，而本页接下来的内容讲的是为了得到它，你需要牺牲多少准确率。

587M 实际上能买到什么

600M 并不是 d1-2B 的小型版本。它是一种不同的构造，预算值得逐项列出，因为它既说明了它的优势，也说明了它的上限。

• 参数量 — 总计 587M：一个 381M 的共享主干与决策头、一个 94M 的视觉编码器，以及一个 112M 的音频编码器。每个模态都流经同一套主干权重。

• 基础版 — LFM2.5-Encoder-350M，一个双向编码器，配备从 LFM2.5-VL-450M 借用的 SigLIP2 视觉塔，以及用于音频的 17 层 FastConformer。

• 上下文 — 在文本、图像和音频位置上合计 16,384 个 token，以及 65,536 个 token 的词表。d1-2B 的窗口为 128K。

• 音频——每次请求最多支持 30 秒的 16 kHz 单声道语音。卡片明确指出，音频部分是基于英语使用者与助手之间的请求训练的，而对于一个人们会拿来处理通话录音的模型来说，这样的分布范围相当狭窄。

• 媒体规则 — 图像或音频，绝不可同时使用。该卡片记录了这一 ValueError，而不是让你自己去发现它。

• 许可证 — LFM Open License v1.0，与 d1-2B 相同的阈值结构：年收入低于 $10,000,000 时可商用。

• 速度 — 未公布。该卡片未报告任何延迟数据，并称该模型为处于积极开发中的早期研究版本。d1-2B 在 H100 PCIe 上公布为 5.7 ms，在 MI325X 上为 3.8 ms，在 M5 Pro 上为 18.6 ms。

同一次运行的表，以及差距很小的行

两个模型都出现在 d1-2B 模型卡上的基准测试表中，该表使用同一评分器在相同题目上对四个开源 d1 模型进行评分。这使得这一比较比大多数跨模型卡的比较更为清晰，但有一点需要注意：d1-omni-600M 自己的模型卡在 Decision Index 0.2.1 上报告为 15.95，而此表在 0.3 版本上报告为 18.3。差异源于指数版本不同，两个数字对各自的测试而言都是正确的。

• Decision Index 公开套件 v0.3 — d1-2B 为 51.1，而 Liquid AI d1-omni-600M 为 18.3。

• DecisionBench（Hanno Labs）v1 — 77.1 对 58.7。

• 决策基准（decisionbench.ai）v4——85.2 对 57.9。

• ImajevBench v2.0-lite — 75.5 对 21.7，是两者之间在决策侧的最大差距。

• WorkflowEvals — 81.6 对比 48.8。

• 视觉平均，18 项基准测试 — 70.2 对 42.8。

• VisualWebBench—— 96.2 vs 14.9，这与其说是比较，不如说是在说明一个 94M 视觉编码器能承载多少。

接下来是那些支持谨慎判断的行。Typed Decisions为 61.3，对比 57.5——对于一个参数量只有三分之一的模型而言，这是 3.8 分的差距。POPE，即物体幻觉基准测试，为 88.7，对比 82.7。JevBench为 77.9，对比 58.0，差距很大，但DecisionBench v4为 85.2，对比 57.9，而两者合起来说明 600M 的表现并不均衡，而非全面偏弱。Liquid AI 自己的发布帖将其七项基准的平均值定为 78.4，对于 587M 来说这很高；d1-2B 的模型卡没有公布等效平均值，因此不应将这两个数字并排比较。

唯一不给任一模型留情面的数字，是独立评测得出的那个。Efraín Garay 在 Decision Index 0.3 的 6,000 条请求样本上运行了 Liquid AI d1-omni-600M，得到 14.0，而厂商自己在同一样本上的成绩是 14.17——非常接近的复现。他还发现，有 1,758 条请求超出了该模型的指令与选项预算并被拒绝，计为错误；对于一个为更长状态而构建的测试套件来说，16K 窗口在这一点上付出了实实在在的代价。

在600M是唯一选择的情况下

音频路由正是该模型所针对的场景，而卡片中的示例也很具体：通话和语音消息路由、声音事件、在书面状态之上叠加语音指令。这些在 d1-2B 上都无法以任何准确度实现，因为它没有音频编码器，其输入模式中也没有音频位置。

两个独立的数据点应当让这番宣传有所收敛。第一个是上文中的评估：在真实数据任务上，600M 的枪声检测 AUC 为 0.580，降雨预报 AUC 为 0.593——仅略高于随机水平，且落后于所有测试过的更大模型。第二个是一项实操评测，其测得运行时显存占用低于 2GB，并发现该模型对音频中表达方式和语气的分类可靠性远高于对语义含义的分类，而在推理型问题上表现几乎接近抛硬币。两者指向同一结论：这是一个筛选模型。它擅长判断“这是哪一类东西”，但不能替代能理解“说了什么”的模型。

这不是对 587M 检查点的批评。这正是当其中 381M 是共享主干时，587M 所能换来的东西。使用它的理由是成本和占用——低于 2GB 的显存、自 10 月 6 日起提供的 GGUF 仓库、自 10 月 12 日起提供的 MLX 构建，以及一次前向传播即可完成决策——而不是保真度。

一个同时使用两者的级联

错误在于把它们当作竞争对手。它们是同一个过滤器的两个阶段，而自然的流水线会先运行成本较低的模型。

第一阶段：Liquid AI d1-omni-600M 接收传入条目——一条语音留言、一通支持电话、一封带附件的书面投诉——并回答粗粒度问题。这是账单问题还是技术问题？来电者生气了吗？这条消息到底包含请求吗？在不到 2GB 且只需一次处理的情况下，这足够便宜，可以对每个条目都运行。

第二阶段：凡是 600M 在其尺度上判定为接近中间值的，或凡是带有需要识读的图像而来的，都会升级到 d1-2B。2B 拥有 128K 窗口、视频输入，以及大约三倍的视觉平均表现，而且它只会看到第一阶段未能解决的那部分流量。

阈值才是关键所在。两张卡都会返回概率，而且都告诉你要用自己的数据做校准——d1-2B 的卡片就是这么说的。一个中间带未校准的级联，要么把所有情况都升级，那样 600M 就成了摆设；要么什么都不升级，那样 2B 就永远无法纠正那个读不懂的阶段。

在大多数真实系统中还有第三个阶段：撰写回复的模型。托管 API 正是在这一阶段登场，也正是 OrcaRouter 发挥作用的地方。我们并不提供任何一款 Liquid AI 模型的服务，因此决策节点仍留在你自己的 GPU 上；而消费其标签的生成步骤则可以来自一把兼容 OpenAI 的密钥，覆盖 200 多个模型，按提供商标价 0% 加价，并且当某家提供商在流量中途掉线时可自动故障转移。路由 DSL 也是如实表达这一级联流程的方式——把两个决策模型作为 GPU 侧步骤、把回复生成作为托管侧步骤，以组合而非在应用代码中硬粘在一起。

两个模型都没做到的事，以及第三种选择

两者都不生成文本。二者都会返回类型化答案和概率，且输出 token 为零；如果下一步需要成段文字，那就得换另一个模型。两者都无法处理带音频的视频：d1-2B 可接收视频帧但不处理声音，600M 可处理声音但不能与图像同时处理，而 30 秒音频上限是硬性限制，而非建议。

如果需求确实是“同一请求中包含音频和图像”，那么答案两者都不是——而是 d1-Omni-2B，也就是 Liquid AI 在 d1-2B 之后二十四秒推出的 2.17B 同门模型，它可以在一个媒体列表中接收文本、图片、视频帧和音频片段。它在同一张 v0.3 表上的 Decision Index 得分为 49.0，视觉平均分为 67.7，并且和 d1-2B 一样缺乏独立测试。它的参数量约为 600M 的四倍，这就是不必在模态之间做选择的代价。

所以规则很短。如果状态中包含语音，且没有其他需要看的内容，那么 Liquid AI d1-omni-600M 就是这一对中唯一能运行的成员，应将其视为一道筛查。如果状态是文本、图像或视频，而且答案必须站得住脚，那么 d1-2B 就是那个模型——它是唯一有已公布延迟数据、128K 上下文窗口，并且其基准领先优势经得起逐行细读的模型。如果状态两者兼有，那么两者都不是答案，2.17B 的 omni 模型才是。