Liquid AI d1-3B 与 Granite 4.2 3B：两个从不做相同工作的 3B 模型

把 Liquid AI d1-3B 和 Granite 4.2 3B 放在同一块单 GPU 上，两者都能轻松装下——一边是 3.12B 参数，另一边是 3B。它们还会表现得仿佛来自不同学科。IBM 自己的模型卡标注日期为 2026 年 8 月 25 日的 Granite 4.2 3B，是一个推理模型：三种思考模式、一个 <think> 块，以及一个你读到的答案。Liquid AI d1-3B 于 2026 年 10 月 5 日上传到 Hugging Face，两天后由 Liquid 发布，它是一个决策模型：它接收一个状态以及一组显式的带类型问题，并在一次前向传播中返回一个概率、一个标签或一个刻度上的位置，报告 output_tokens: 0，因为它从不写任何东西。有用的问题不是哪一个更好，而是你的哪些调用实际上是一个决策，因为这两个仓库正是为这一划分的两半而构建的。

每个仓库里实际上都有什么

以下所有内容均来自两份模型卡以及 Liquid 的公告文章。这里没有任何内容经过独立复现，也没有任何第三方在同一评测框架上对这两个模型进行评分，模型卡中的数字均来自厂商自己。

• 规模 — Liquid AI d1-3B 总计 3.12B，基于 Liquid 的 LFM2.5-VL-3B 构建；Granite 4.2 3B 是一个基于 granite-4.1-3b-base 构建的 3B 仅解码器稠密 Transformer

• 输出 — d1-3B 返回概率、标签和置信度，完全不输出任何文本；Granite 4.2 3B 生成 token，包括位于 <think>标签

• 上下文 — d1-3B 32,768 个 token；Granite 4.2 3B 原生支持 128K，并可在显卡上通过长上下文扩展至 512K

• 输入 — d1-3B 文本、JSON、图像或混合内容，通过 SigLIP2 NaFlex 400M 视觉编码器；Granite 4.2 3B 仅文本

• 许可证 — d1-3B 依据 Liquid 的 LFM Open License v1.0；Granite 4.2 3B 依据 Apache 2.0

• 语言 — d1-3B 列出 16 种；Granite 4.2 3B 列出十二种已测试语言，卡片注明其他语言尚未测试

• 服务 — d1-3B 附带自定义代码（trust_remote_code=True、transformers>=5.14），同一系列中还提供 GGUF 和 w8a8 仓库，并附有为 llama.cpp、Ollama 和 LM Studio 编写的模型卡文档；Granite 4.2 3B 可在 vLLM 0.20+ 或 SGLang 0.5.18+ 上运行，并配有自定义 thinking parser

这些行中有两行比其他所有行承担的作用都更大。输出那一行就是本文的全部论点，而许可证那一行则是没人会放进对比表里的那一行。

一个写出思维链，另一个拒绝写

Granite 4.2 3B 靠把思考过程说出来体现价值。它的模型卡记录了三种模式：默认开启思考、非思考，以及低耗模式——该模式保留推理轨迹但将其缩短。服务栈会将推理轨迹与最终答案分开，因此你的应用会收到干净的内容，外加一个单独的推理字段。对于需要逐步推导的问题——一道数学题、一个逻辑分支、一段必须先写出来才能评判的代码——这是一种很好的设计。

d1-3B 没有这种模式，它的说明卡直言不讳地写道：“它不是聊天模型，也不写文本。”一次调用会用一个类型来声明问题。noul是一种返回 0 到 1 之间 P(yes) 的是/否类型。choice从一组具名选项中选出一个标签，并返回该标签、一个置信度以及每个选项的概率。score把状态放到一个有序的二到十级量表上，并返回期望等级及其分布和图例。信号是在一次前向传播中从占位位置的 logits 读取的，而不是逐 token 采样得到的，正因如此，usage 块才能报告零输出 token 而不说谎。

这一差异会先改变你的账单，再改变你的准确率。一次 Granite 分类调用如果思考了 400 个 token，就是一次你要为 400 个输出 token 付费的调用，而你想要的标签则埋在文字中，之后还得让解析器去提取。一次 d1-3B 调用只对输入计费。如果你的大部分流量都是带规则的标签，那么无论推理是否改变了标签，你都一直在为推理付费。

在 Granite 4.2 3B 显然是更佳选择的情况下

从表面看待这些推理基准测试成绩——它们是 IBM 自家的，通过内部 NeMo Evaluator 流水线运行，且没有外部方复现过——而这个 3B 模型就其规模而言异常强大：AIME25 78.33，HMMT February 2025 66.67，GPQA 54.80，LiveCodeBench v6 69.71，MMLU-Pro 67.84，IFBench 74.33，BFCL v4 52.41，tau3-bench 45.78，以及 RULER 64K 67.52，在 128K 时降至 55.30。

从那份清单可以引出四项工作，而 d1-3B 不在其中任何一项之内。

• 原生 128K 上下文，可扩展至 512K，而 d1-3B 上只有 32,768 个 token——如果你的状态是一份长文档，那选择已经为你做好了

• 智能体式工具调用，配有文档化的解析器以及面向 OpenCode、Pi 和 OpenHands 的 harness 集成，而决策模型没有与之对应的能力

• 任何答案是一段文字的任务：摘要、起草、提取为自由格式结构、代码生成

• 不受收入上限限制的微调和再分发，因为 Apache 2.0 没有门槛条款

请注意 Granite 卡片上没有哪些内容：SWE-Bench 和 Terminal-Bench 两行在 3B 上均标为 NA。IBM 的智能体强化学习阶段只应用于该系列中的 8B 和 30B 成员，因此最小的模型并不具备其更大同门所拥有的智能体评分。若有团队看到“Granite 4.2”就以为 3B 会继承该系列的智能体特性，将会大感意外。

d1-3B 在何处胜出——在 Granite 还没想完之前

Liquid 自己的延迟表——在预热状态下、一次一个请求测得——是其论据中最有力的部分：在 RTX 4090 上单个问题耗时 8 毫秒，在 AMD MI325X 上为 9 毫秒，在 Jetson AGX Thor 上为 16 毫秒，在 Jetson AGX Orin 64GB 上为 26 毫秒；而 64 个状态打包进一次传递，在 4090 上达到 475 次/秒，在 MI325X 上达到 1,106 次/秒。作为参照，这大约相当于 Granite 4.2 3B 发出其推理轨迹中几个 token 所需的时间。

在 4090 上，针对同一个状态处理三类问题只需 21 ms，而无需分别调用三次，因为该状态及其图像只需被读取一次即可供所有问题使用。在以往每条规则都要发起一次 HTTP 请求的审核或路由栈中，这就意味着一串排队等待的调用与仅一次调用之间的差别。

它也能看。d1-3B 在十一项公开图像基准测试中平均得分为 74.1，而其基础模型为 73.9，并且模型卡指出，移除图像后，同样的问题得分只有 45.1——答案来自图片，而不是文本提示。单项结果各有胜负（CV-Bench 82.1，基础模型为 87.6；POPE 88.5，基础模型为 90.1），因此其视觉能力的主张是“与基础模型持平”，而不是“优于基础模型”。

诚实的对照：d1-3B 在 Decision Index 0.2.1 上的 48.57 是由 Liquid 自行运行官方评分器得出的，而非通过排行榜提交产生，而与之竞争的各行则来自公开排行榜。它在八项基准即决策任务上的 77.1 均值，以及在 DecisionBench 上的 71.8，同样属于第一方数据。这一对比中 d1 这一侧的一切均未经核实。

为什么 3B 推理器不是 3B 决策模型

把 Granite 4.2 3B 当作 d1-3B 的更便宜替代品，或者反过来，都是很诱人的做法。两者都行不通，而这种行不通是结构性的，并非质量问题。

让 Granite 做决定，你得到的是一段必须解析的生成内容、一笔随模型认为该问题有多难而变化的费用，以及取决于你所选思考模式的延迟。让 d1-3B 去推理，你什么都得不到——它没有可供推理的 token 流。这两个模型位于一条线的两侧，而大多数流水线在每次请求中都会多次跨越这条线：总得有什么来做决定，也总得有什么来发声。d1-3B 属于前端，在那里，分诊规则会挑选出一条路由，并返回经过校准的置信度。Granite 4.2 3B 则属于它后面，位于需要把答案写出来的那条分支上。

还有第二个更隐蔽的陷阱。决策模型的价值在于校准——0.9 的置信度意味着十次里有九次是对的。Granite 4.2 3B 的模型卡没有公布任何校准指标，也没有公布概率；它公布的是准确率和推理分数。在基准排行榜上比较两者，并不能告诉你该信任哪一个来设定阈值。

没人放进表格里的许可证条目

Granite 4.2 3B 以 Apache 2.0 许可发布。d1-3B 以 LFM Open License v1.0 发布；该许可在读到第 5 条之前都显得很宽松：商业使用被授予，前提是你或你的法律实体保持在该文件所定义的阈值之下，即年收入达到或超过一千万美元；而任何越过这条线的商业使用则根本未获许可。非营利组织和研究用户被排除在外。

对于爱好者或初创公司来说，这根本不是问题。但对于一家在年中越过了那条线的公司——或者可能被这样一家公司收购的公司——无论两个仓库的参数规模看起来多么相似，它们都不是可以等价看待的产物，而等到有人已经交付了原型之后很久，许可证审查才会开始。这是本页上最廉价、也最值得尽早核查的一件事。

将这对组合作为一条流水线运行

这两个模型目前都不在我们的目录中，因此这并不是一份可用性声明：两者都是自托管产物，尤其是 Granite 4.2 3B，其卡片上根本没有列出任何推理提供商。但团队最终实际采用的模式是：一个调用负责决策，另一个负责表达，而这种模式正是路由层体现价值之处。Orca 将 200 多个模型置于一个 API 密钥之后，并以0% 加价透传提供商标价，因此供应商降价当天就能反映到你的账单上，而不是等到下一次合同续约，并且跨提供商的自动故障转移意味着，管道中间的共享组件不会在你仍在评估它时成为单点故障。如果你想在承诺采用自托管部署之前，用自己的流量将 d1-3B 与一个托管通用模型进行 A/B 测试，那么与 Granite 血统最接近的路由近邻是 Gemma 4 31B，每百万输入 token 0.13 美元，每百万输出 0.38 美元——一个大得多的模型，但在管道中扮演着同样的“负责写作的通用模型”角色。

裁决，以规则形式陈述

如果你需要的是一个判断——是不是垃圾信息、该分到哪个队列、有多紧急、这张图是否与那段描述相符——d1-3B 是两者中唯一能一次完成的，而且它能在个位数毫秒内完成。如果你需要的是一个书面回答、阅读一篇长文档、一次工具调用或一段代码，Granite 4.2 3B 才是有 token 流的那一个，而 3B 的推理分数就其规模而言确实令人印象深刻——这些分数来自 IBM 自家的评测，且还没有人核查过。

真正会改变局面的，不是基准测试里多出一行新结果。而是由第三方在同一套校准测试框架上给两个模型打分，因为决定你能否给一个模型设定阈值的那个特性，正是如今两张模型卡都不让你比较的那一个。