Liquid AI d1-3B 与 MiniCPM5-2B：笔记本电脑规模下的概率还是散文

两个开放权重模型，都小到足以运行在你面前的机器上，而它们对模型该返回什么意见不一。Liquid AI d1-3B 是 Liquid AI 的 3.12B 决策模型，于 2026 年 10 月 7 日开放权重：它读取一个状态和一组具名问题，并在一次前向传播中返回一个标签、每个选项的概率以及一个置信度，不生成任何内容。MiniCPM5-2B 是 ModelBest 和 OpenBMB 的 2.52B 稠密模型，于 7 月 19 日在世界人工智能大会上亮相，并于 2026 年 9 月初以 Apache-2.0 许可悄然发布到 Hugging Face——一个会写答案、用 XML 调用函数的推理、编码和工具调用助手，下载量已超过一百万。较小的那个拥有四倍的上下文窗口和宽松得多的许可；较大的那个即使你想让它生成一个 token，它也做不到。这两种形态中哪一种属于你的流水线，完全取决于调用下游的东西想要的是一个数字还是一句话。

值得首先注意的反转

关于这个搭配，几乎所有直觉上的预期都是反的，所以就从这里入手。

MiniCPM5-2B 是较小的模型，却拥有更长的上下文：131,072 个 token，而 Liquid AI d1-3B 为 32,768 个。它也是两者中许可条款更宽松的一个——Apache-2.0，无需门控审批，训练数据集作为 UltraData 系列的一部分与权重一同发布。Liquid AI d1-3B 以 Liquid 自家的 lfm1.0 许可证发布，该许可证允许下载和微调，但它是厂商许可证，而非标准的宽松许可证。

Liquid AI d1-3B 是更大的模型——总参数量为 3.12B，而后者为 2.52B，不过在非嵌入参数上，比较结果又会反转——而且它是那个不会写作的模型。它具备视觉能力；MiniCPM 则仅支持文本。它只针对一件事进行了后训练；MiniCPM 则针对许多事进行了后训练。而且，MiniCPM5-2B 发布时附带一张将其置于同尺寸级别顶端的对比图表，Liquid AI d1-3B 发布时则只带有一个单一指数分数和一组延迟表。

这些都不能说明哪一个更好。它意味着两者面向的是不同的任务，而最能说明这一点的是它们各自返回的答案形态。

线上返回的内容是什么

MiniCPM5-2B是一个生成式语言模型。它会推理，会用散文作答，并发出 XML 风格的工具调用，这些调用会被 SGLang 内置的 minicpm5解析器转换为 OpenAI 兼容的 tool_calls，无需自定义适配器。它的后训练是其故事中有意思的部分：先进行 4000 亿 token 的深度思考监督微调，然后使用借鉴自 JustRL II 的基于 critic 的算法进行强化学习，再通过同策略蒸馏将十六个专门化的 RL 教师——其中五个是智能体——整合回一个稠密网络。模型卡称，RL 加蒸馏在推理和通用任务上平均带来 10.96 分的提升，在智能体任务上带来 6.96 分的提升，并报告在其自己的对比集上平均为 53.9，高于该集中纳入的最大模型。这些是 ModelBest 内部产出的数字，目前尚无独立复现发布。

Liquid AI d1-3B 返回结构化结果。一个 noul 问题会以 0 到 1 之间的 P(yes) 返回。一个 choice 问题会返回标签、置信度以及每个选项的概率。一个 score 问题会返回有序的 2 到 10 级量表上的预期等级，及其分布和图例。usage 对象会报告 output_tokens: 0，并且如果你想要未经处理的向量，还有一个原始的 probabilities 访问器。它的后训练是另一种相反的工作：将两个检查点取平均，在不同数据混合上微调多个随机种子，合并它们，然后把精力花在长输入训练上——打乱答案选项顺序，并从训练数据中剔除捷径——因为一个决策模型如果学会的是“选项 B 通常是对的”，而不是读取状态，那就比无用还糟。

一种做法是让模型先思考，然后再说些什么；另一种则是问模型它已经相信什么。

并排显示，标注出处

下文所有数据均为厂商自行报告。MiniCPM5-2B 的数据来自 ModelBest 自己发布的模型卡及其自有的对比集；Liquid AI d1-3B 的数据则来自 Liquid 自行运行官方 Decision Index 评分器，而非提交至公开排行榜。截至开放权重发布之时，这两个模型均未经过第三方独立基准测试。

• 参数 — Liquid AI d1-3B 总计 3.12B，配备 400M SigLIP2 视觉编码器和 128,000 token 词表；MiniCPM5-2B 总计 2,516,756,480，非嵌入参数 1,981,982,720，42 层，16 个查询头对 2 个 KV 头，词表 130,560。

• 上下文 — Liquid AI d1-3B 为 32,768 tokens；MiniCPM5-2B 为 131,072。

• 输入模态——Liquid AI d1-3B 支持文本和图像；MiniCPM5-2B 仅支持文本。

• 输出 — 针对 Liquid AI d1-3B，概率、标签、置信度和有序分数，且输出 token 为零；针对 MiniCPM5-2B，生成的文本、推理和 XML 工具调用。

• 主要得分 — Liquid AI d1-3B 在 Decision Index 0.2.1 上为 48.57，在厂商表格中 10B 以下模型里排名第一；MiniCPM5-2B 在其自身对比集上平均为 53.9，而该集合不同，衡量的是不同的东西。

• 速度 — 在 RTX 4090 上每个问题 8 毫秒，在 Jetson AGX Orin 64 GB 上 26 毫秒，在 Jetson Orin Nano 上 50 毫秒，对于 Liquid AI d1-3B，每次传递 64 个打包状态，每秒 475 个。MiniCPM5-2B 的速度取决于它生成多少 token，因此没有单一数字可以与之对应。

• 许可证 — Apache-2.0，无门槛，训练数据已发布，适用于 MiniCPM5-2B；Liquid 的 lfm1.0 适用于 Liquid AI d1-3B。

• 证据 — MiniCPM5-2B 在 Hugging Face 上获得超过一百万次下载，并有社区进行了一个月的量化；而 Liquid AI d1-3B 仅存在两天，且没有第三方运行。

每个实际上擅长的工作

有一个两个模型都能执行的工作流，而它们执行方式的差异正是整个论证的核心。

假设你正在对支持工单进行分诊，或者判断检索到的段落是否回答了问题，或者根据评分标准给 LLM 输出打分。MiniCPM5-2B 这三件事都能做——它是一个能力强的小型推理模型，具备工具调用和长上下文，你可以像运行其他任何助手一样运行它，要求给出一个标签，然后解析返回的任何内容。有时它会返回干净的 JSON。有时它会返回外面包着解释的 JSON。有时它会以错误的格式返回正确答案，而这个失误是你解析器中的 bug，而不是模型中的 bug。

Liquid AI d1-3B 做不了别的事，而这恰恰是关键所在。在同样这三项任务上，它只返回一个概率和一个标签，没有任何需要解析的东西；针对同一个状态问三个问题，耗时是问一个问题的 1.3 倍；而且失效模式从“格式坏了”转变为“置信度校准有误”——这至少是可度量的，因为置信度就在响应里。

MiniCPM5-2B 真正彻底胜出的地方，在于决策之后的所有下游环节。它可容纳 131K token，因此状态可以是整个代码仓库的文件树或一份长文档，而不只是其中第一页。它能原生编写工具调用。它是一个可以让你在其之上构建小型智能体的模型，而且是专门为智能体工作做过后训练的。而它的 Apache-2.0 许可证意味着，通常那种需要商业律师介入的对话不会发生。

Liquid AI d1-3B 之所以能彻底胜出，在于其延迟下限与模态能力。一台无需 GPU 就能在 50 毫秒内完成一次决策的设备，并不是一台运行 MiniCPM5-2B 的设备；尽管参数量相近，两者却处于不同的硬件层级。而且这个 3B 模型“看得见”——厂商报告称，在十一个公开图像基准测试中（按决策方式解读），其得分为 74.1，而作为其构建基础的视觉语言模型为 73.9；同时还报告称，去掉图像后，同样的问题得分会骤降至 45.1，这正是他们用来表明答案源自像素的方式。生产线的视觉检测，根本不是纯文本的 2B 模型能够承担的任务。

运行它们，以及它们周围的层

两者都是自托管方案，而且两者的部署工作均已完成。Liquid AI d1-3B 首发即支持 llama.cpp，提供从 DGX 到 Jetson 的完整 NVIDIA 技术栈、NVFP4 量化、8 位权重与激活版本，并且 GGUF 转换版本已经发布。MiniCPM5-2B 是普通的 LlamaForCausalLM 架构，无需自定义内核，只有一个 BF16 safetensors 分片，所属的更大系列中还有 GGUF 和 MLX 版本，并且在需要工具调用解析器时，有文档表明其偏好使用 SGLang。两者都不在我们的目录中，本文也并非对其中任何一方的可用性声明。

托管替代方案是厂商自家的 API 和第三方平台。Liquid 提供托管的 d1，仅按输入 token 计费，价格为每百万 $0.04；图像按输入计费，每 32×32 像素区块计 1.5 个 token，且完全没有输出计费项；MiniCPM5-2B 没有第一方 API，这对 Apache-2.0 开放权重发布来说很正常。

这两者所支撑的，是同一个架构问题。本地 2B 或 3B 模型负责分类、路由或护栏检查，坐落在你并不自托管的生成式调用之前，而这种自有推理与租用推理并存的混合形态，正是路由层存在的意义。一个端点覆盖 200+ 模型，供应商目录价以 0% 加价透传，因此厂商调价当天即生效，自动故障转移，在某条上游链路劣化时触发。自持小模型只会让路由问题变得更难，而非更容易，因为这样一来，你的硬件与他人硬件之间的边界，就成了你必须按每个请求逐一做出的决策。

按答案类型选择

如果你需要的是一个标签、一个概率或一个评分，并且选项集是预先已知的，那么 Liquid AI d1-3B 是更诚实的工具——它就是为这类请求而构建的，答案不会以畸形的形式出现。把供应商许可证、32K 上下文以及仅有两天的证据记录当作代价接受下来。

如果你需要的是一个小模型，既能推理、调用工具，又能容纳长文档并用文字作答，那么 MiniCPM5-2B 是能力强得多的选择，优势相当明显；而且它采用 Apache-2.0 许可，背后还有百万次下载量所代表的他人实测积累。

能从这两个版本中获益最多的团队，是那些同时运行两者的团队：前面是一个决策模型，其答案是数字，毫秒之差至关重要；后面是一个小型生成模型，负责工作中需要语言处理的部分。它们不是竞争对手，而是一个过滤器和一个发声者。