d1-2B 对比 Liquid AI d1-3B：更小的模型赢了榜单，却输掉了部署

四个问题决定这场对比，而其中没有一个问题是“哪个模型更好”。状态中是否包含视频？是否超过 32K token？你是否需要在 llama.cpp 下运行它？你能否承担成为第一个测试它的人？ d1-2B 是 Liquid AI 的 1.92B 决策模型，基于 LFM3-VL-2B 构建，在厂商的 Decision Index 表中得分 51.1。 Liquid AI d1-3B 是 10 月 7 日发布的 3.12B 模型，基于 LFM2.5-VL-3B 构建，在同一张表中得分 49.0。更新、更小的模型平均领先。但它仍输掉了实际部署真正会启用的三行，而且它是两者中没有 llama.cpp 路径、也没有独立测试结果的那个。本页围绕这四个问题组织，而不是围绕排行榜，因为排行榜对这些问题一个都回答不了。

简而言之，按工作负载

• 大规模纯文本分诊——d1-2B 靠的是在 64 个批处理状态下每秒 1,132 次决策，以及 3.84GB 的权重。当输出只是一个标签时，3B 在 Typed Decisions 上的优势无关紧要。

• 图表阅读 — Liquid AI d1-3B。它在 AI2D 上以 79.9 比 76.7 获胜，并且它是背后有独立运行支持的模型。

• 长文档、长表单、长通话记录 — d1-2B。其窗口为 128K tokens，对比 32,768，且说明卡坦诚指出，超过约 64K 后可靠性会下降，但这仍留有 3B 总容量的两倍。

• 运行 llama.cpp 的边缘设备——Liquid AI d1-3B，是默认选择，而非凭实力。它有 GGUF 仓库和量化权重激活构建；d1-2B 两者都没有。

• 任何判断出错代价高昂且未经检验的场景——两者都不是，除非你先在自己的数据上把两者都跑一遍。它们之中甚至只有一个曾被第三方运行过。

同门同族，相隔一代

这两个模型并非名称所暗示的那种同代兄弟关系。Liquid AI d1-3B 源自 LFM2.5-VL-3B，而后者又衍生自 LFM2.5-2.6B-Base，并配备了一个 400M 参数的 SigLIP2 NaFlex 视觉编码器。d1-2B 则源自下一代家族中的 LFM3-VL-2B，其 24 层主干划分为 13 层门控短卷积、5 层滑动窗口注意力层和 6 层全局注意力层。基准测试中的反转正是源于这一代际差距：新架构在每个参数上能实现更多能力，因此在大多数行上，较小的检查点得分能超过较大的检查点。

• 参数——d1-2B 为 1.92B，Liquid AI d1-3B 为 3.12B。

• 下载 — 3.84GB 对比 6.25GB 的 BF16 safetensors，两者均为单文件。

• 上下文 — 128K 个 token 对比 32,768 个。

• 词表 — 128,000 个 token，对比 LFM2.5 的词表。

• 输入 — 文本或 JSON、图像 或视频，外加具名问题，适用于 d1-2B；3B 则为文本或 JSON 加图像。视频是两者之间最清晰的能力差异。

• 语言——各十六种，同一套。

• 许可证 — 两者均采用 LFM Open License v1.0，商业使用以年收入保持在 10,000,000 美元以下为条件。从许可角度看，没有理由偏好其中任何一个。

• 发布 — d1-3B 的权重于 10 月 5 日上线，并于 10 月 7 日公布。d1-2B 的仓库创建于 10 月 24 日，且从未有过自己的发布帖；唯一提到它的厂商语句出现在 10 月 27 日的 LFM3 发布会上。

{{1}}有一个文档细节值得作为信号而非事实来解读：{{/1}} {{2}}Liquid AI 的决策模型文档页面现在列出 d1-2B、d1-omni-2B、d1-omni-600M、d1.1 和 d1-ultra。它不再列出 d1-3B。{{/2}} {{3}}3B 并未退役——其仓库、GGUF 和 MLX 构建均仍在线——但厂商自己的索引已将开放权重的位置移到了 2B。{{/3}}

记分牌，逐行读取

下文所有数字均来自 d1-2B 模型卡上的基准表，该表用同一评分器对四个开放 d1 模型在相同条目上进行评分。这一点很重要，因为 Liquid AI d1-3B 自己的模型卡在 Decision Index 0.2.1 上报告 48.57，而本表在 0.3 版本上报告 49.0；差距来自指数版本，而不是模型变化，模型卡也在注释中说明了这一点。直接比较这两张模型卡——48.57 对 51.1——会是在两个不同测试之间做减法。在本表内部进行比较是合理的，本节其余部分也正是这样做的。

• Decision Index 公开套件 v0.3 — 51.1 对 49.0。

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

• Decision Bench (decisionbench.ai) v4 — 85.2 对 83.6。

• JevBench v1.4.1 — 77.9 比 76.2。

• ImajevBench v2.0-lite——75.5 对 64.0，决策侧最大差距。

• WorkflowEvals — 81.6 对 74.4。

• Liquid AI 的内部榜单——63.2 对 58.8。

• 视觉平均分——十八项基准测试中 70.2 对 65.4。

该表中的每一个具名决策套件都由 2B 胜出，这正是 LFM3 发布文章称 d1-2B 是 d1-3B 的替代品时所表达的意思——“参数少了三分之一”，并且在“所有四个决策套件”上得分更高。这一说法按原文所述是准确的——但范围比“击败 3B”要窄，这正是下一段存在的原因。然后是三个朝相反方向走的行。Fast Decisions 上，d1-2B 为 58.8，而 3B 为 59.3。Typed Decisions 为 61.3，对 65.0。AI2D 为 76.7，对 79.9。这些差距都不大，而且三个中有两个不到一个点，但它们正是多出的 1.2B 参数仍能带来可衡量收益的行：面向速度的决策、类型化提取和图表阅读。如果你的流水线任务是从表单中进行类型化提取，那么 3B 并不是文档页面所暗示的那种过时选项。

延迟：这两个主要数字不可直接比较

Liquid AI 给出的数据是：d1-2B 每次决策 5.7 毫秒，Liquid AI d1-3B 为 8 毫秒，而这两者并不是同一种测量。2B 的数字是在 H100 PCIe 上测得的；3B 的数字是在 RTX 4090 上测得的。两块不同 GPU 之间 2.3 毫秒的差距，完全不能说明哪个模型在你的硬件上更快；把它当作对比来重复，正是这个博客要避免的那种“数字洗白”。

两张卡都报告了同一台机器。在 Apple M5 Pro 上，d1-2B 每个问题耗时 18.6 毫秒，3B 耗时 30 毫秒——在相同芯片上降低了 38%。这是诚实的速度对比，其结论与规模差异所暗示的方向一致。在批处理方面，d1-2B 在 H100 PCIe 上每秒处理 1,132 个决策；在 MI325X 上、一次调用处理 64 个状态时，每秒处理 1,699 个决策。3B 的卡报告在 RTX 4090 上每秒 475 个，在 MI325X 上每秒 1,106 个。MI325X 这一行是两张卡共有的，而在这一项上，2B 领先约 54%。

现存唯一的独立测试运行了3B

十月中旬，Efraín Garay 让八个决策模型在 Decision Index 0.3 和三个真实数据任务上进行了测试，并连同代码一起公布了结果。有两项发现与这一比较相关。

第一点对记分板来说令人放心。他用其工具包重建了公开测试套件，检查了下载的文件是否与官方文件一致，抽取了 6,000 个请求，并给 Liquid AI d1-3B 评分为 49.11——相比之下，Liquid 自己在相同行上的评分为 49.04，在完整套件上为 48.99。这是现有最有力的证据，证明上表中的 v0.3 数字计算正确。这是关于 3B 的证据，而不是关于 d1-2B 的，因为他没有测试后者。

第二个是对某个指数衡量内容的警告。在一个包含 10,000 笔支付的合成信用卡欺诈数据集上，Liquid AI d1-3B 的 AUC 得分为 0.314——低于随机水平，把异常排名得比正常支付更不可疑，因为连续多笔支付的突发情况中位概率为 0.41，而正常支付为 0.56。该模型在公开指数上排名第二，却在那项任务上排名最后。这个教训可以直接迁移：d1-2B 的 51.1 是通用决策套件上的得分，没有人证明它能预测模型在你特定决策上的表现。厂商在自己的说明卡中也承认了这一点，并指示要基于你自己的数据校准阈值。

你今天可以实际运行的内容

对比到这里就不再接近了。Liquid AI d1-3B 自 10 月 6 日起就有 GGUF 仓库，自 10 月 7 日起有 8 位权重激活构建，自 10 月 12 日起有四个 MLX 变体。d1-2B 在 10 月 27 日获得了三个 MLX 构建和一个 ONNX 导出，除此之外别无他物。没有 d1-2B 的 GGUF，也没有超出 MLX 4 位和 8 位的量化，因此决策头没有已发布的 llama.cpp 路径——尽管基础模型 LFM3-VL-2B 自 10 月 19 日起就有自己的 GGUF。

对于 Transformers 部署，这种差异就消失了：两者都通过 trust_remote_code=True 加载，并暴露相同的 system_one 和 system_one_batch 调用。对于边缘部署则不然。如果你的技术栈是在 Jetson 或手机上运行 llama.cpp，那么 3B 版本是两者中唯一无需编写运行时集成就能运行的那个，而且它公布的边缘指标——Jetson AGX Thor 上 16 ms、AGX Orin 64GB 上 26 ms、Orin Nano 上 50 ms——正是你可以据此规划的指标。

OrcaRouter 不提供这两个模型中的任何一个，因此无论选哪个，都是自托管决策。路由器的价值体现在更外一层：决策模型很少单独运行，而根据路由标签执行动作的生成步骤通常来自托管模型。 一个兼容 OpenAI 的密钥，可访问 200 多个模型、一种可将这些步骤组合成一次调用的路由 DSL，以及自动故障转移，共同让流水线的这一半不至于变成第二个集成项目，同时决策节点仍留在你自己的硬件上。

如果你正在迁移，会有三件事发生变化

API 接口面足够接近，以至于移植看起来很简单，实际却并非如此。首先，输入契约：d1-3B 接收图像；d1-2B 接收一个媒体列表，该列表可以包含视频，而且其卡片将媒体描述为在一次调用中为所有问题仅编码一次。传入单张图像的代码会运行，但它不会用到该模型原本为之构建的用途。

其次，是阈值。两个模型都会返回概率，并且都需要在你的数据上拟合一个决策阈值。在 d1-3B 的校准上调好的阈值无法迁移——校准表随每个仓库分别提供，并且是单独拟合的——因此，沿用旧截断值的迁移会产生不同的工作点，并且在审核或欺诈路径中会产生不同的错误特征。

第三，可靠性断崖。{{1}}128K{{/1}} 窗口是宣传重点；{{2}}模型卡{{/2}} 指出，状态超过约 {{3}}64K token{{/3}} 后，回答会变得不那么可靠。在 {{4}}3B{{/4}} 上，上限是 {{5}}32,768{{/5}}，所以迁移到 {{6}}d1-2B{{/6}} 通常会是直接的容量提升——但如果某个 {{7}}流水线{{/7}} 因为现在有能力了就开始送入 {{8}}100K token{{/8}} 的状态，那它就是在测试厂商已标记为较弱的那部分区间。

裁决并不像记分牌那样对称。对于在 Transformers 中新建的项目，无论是文本、图像还是视频，且状态可能持续很久，d1-2B 都是更好的默认选择，运行成本也更低。对于在 llama.cpp 下的边缘部署、类型化抽取，或图表密集型视觉任务，Liquid AI d1-3B 仍是应选模型——而且它是两者中唯一有外部证据支持的。唯一不要做的，就是仅凭 51.1 对 49.0 这一行做选择。厂商指数上的两分之差，发生在两个没人你的任务上跑过的模型之间，这不是决策，而是平局决胜。