d1-Omni-2B 对比 MiniCPM5-2B：决策模型不是小型聊天模型

两者都是开放权重，参数量都接近二十亿，而且都面向放在桌面上而非机架里的硬件。相似之处到此为止。d1-Omni-2B 接收一个状态——文本、JSON、图像、视频帧、音频——外加一组具名问题，并在单次前向传播中返回带校准概率的类型化答案。MiniCPM5-2B 接收文本并写出更多文本，一次一个词元地推理出答案。把其中一个换成另一个，既不是模型升级，也不是模型降级；而是重写所有消费该响应的部分。那么，值得做的比较不是哪个得分更高，而是你的流水线实际能接受哪一种契约，以及为了履行它，各自会在许可证、延迟和部署工作上让你付出什么代价。

一次调用实际会返回什么

一次 d1 调用看起来像一份 schema，而不是一段对话。你向 system_one传入一个状态和一个问题字典，每个问题都带有类型——是/否、单选、多选、有序评分、文本片段、数字、日期、一个边界框或多个边界框——然后你会得到每个问题的一个值，并附带概率。模型卡自带的示例会将一张支持工单分流：一个退款标志、一个根据两项指定标准得出的团队分配，以及每个结果上的置信度。没有散文，没有转录文本，也不生成 token。模型卡明确说明：它不是聊天模型。

这个设计就是产品的全部。因为不存在任何解码，所以没有解析步骤，没有 JSON 修复，也没有针对那种把答案裹在道歉里的模型的重试循环。返回的是一个值，落在你选定的阈值上；当选项集中没有适用项时，还有一条弃权路径。Liquid 报告称，在该弃权测试中，书面形式为 78.5，口语形式为 75.8。如果你的下游代码需要的是一个队列分配和一个数字，那这就是你想要的形态。

MiniCPM5-2B 呈现的形态恰恰相反。它是一个标准的 Llama 架构解码器，会在回答前先思考，建立在 4000 亿 token 的深度思考 SFT 阶段、领域 RL，以及一个同策略蒸馏步骤之上；该步骤将十六个专家教师模型融合进一个稠密检查点。你完全可以从它那里获得结构化输出——它的函数调用得分相当不错，而且 OpenBMB 为 vLLM 提供了工具解析器——但你是通过在提示词中请求，并信任解码器会照做来获得的。推理本身就是特性。它也是你每次调用都在为之付费的东西。

不存在的正面交锋

没有任何一个基准测试是两个模型都运行过的。这并不是报告中的遗漏；而是上文所述分裂的结果。d1-Omni-2B 仅出现在 Liquid 的决策套件中——DecisionBench v1 为 76.4，decisionbench.ai v4 为 84.7，Decision Index public suite v0.3 为 49.0，ImajevBench v2.0-lite 为 72.3，以及在十八个基准测试上的未加权视觉平均值为 67.7。MiniCPM5-2B 仅出现在 OpenBMB 的推理与智能体套件中：34 项测试的平均值为 53.9，LiveCodeBench v6 为 69.1，AIME 2025 为 86.5，SWE-bench Verified 为 46.4，BFCL v4 为 66.6，而在 Humanity's Last Exam 上仅为低得多的 8.9。这些数字中没有一个与第一份列表中的任何数字是在相同题目上、由相同评分者测得的。

任何把这些分数并排做成两列表格展示给你的人，都是在拼接，而这种拼接比表面上看起来更糟。d1-Omni-2B 的每一项数字都是厂商自行运行的，而且截至发布时，尚未被独立复现。OpenBMB 的主要平均分也是厂商自行运行的——该公司公开了其训练语料和 RL 框架，这比大多数实验室做得更多，但那是方法层面的可复现性，不是分数的可复现性。

确实存在的独立数字值得仔细阅读，因为它们在各个索引版本之间彼此不一致。Artificial Analysis 在 9 月 7 日报道该发布时，给 MiniCPM5-2B 在 v4.2 Intelligence Index 上打了 15 分；实时页面现在显示 12；OpenBMB 自己声称的 23 是在 v4.1.1 上得出的。这三个数字既不是下降，也不是争议——它们下面的索引变了，不同版本的分数不可比较。看方向，忽略数字。Artificial Analysis 根本没有 d1-Omni-2B 或其同系列 d1-2B 的页面，因此该决策模型目前还没有任何形式的独立测量。

有一个看似可迁移、实则不可迁移的数字：Liquid 对其 聊天模型 LFM3-1.7B 与 MiniCPM5-2B 进行了 27 项测试对比，并以 23 比 4 获胜。该结果说明，Liquid 经后训练的解码器在这些测试上胜过 OpenBMB 的解码器。它对决策头只字未提——决策头从未参与那次运行——也不应借用这一点来裁定这一配对。

规格真正拉开差距的地方

• 输出契约——带概率的类型化数值与零输出 token，对比带有隐式推理轨迹的生成文本。此列表上的其他所有内容都由此派生而来。

• 规模 — 4.33GB 的 BF16 检查点中有 2.17B 参数，而对比对象总计 2.52B、非嵌入部分 1.98B，BF16 下约 5GB。两者足够接近，单就占用空间而言谁也无法胜出。

• 输入——文本或 JSON 状态、图像、视频帧与音频，可在单个请求中混合输入，而不仅仅支持文本。MiniCPM5-2B 没有视觉编码器，也没有音频通路；如果状态中包含波形，那么这一比较到此为止。如果你想要 OpenBMB 的多模态产品线，那就是 MiniCPM-V 4.7，属于另一个产品家族，取舍也有所不同。

• 上下文——128,000 个 token 对 131,072 个。这是同一个数字的两种表述，并不是选择任一模型的理由。它唯一的意义在于，两者都能容纳长文档；d1-Omni-2B 的限制在于，长段语音内容会在窗口填满之前很早便降低其准确率，而说明卡也写明了这一点。

• 许可证——采用 LFM Open License v1.0，设有 10,000,000 美元的年收入门槛，而 Apache-2.0 则完全没有任何条件。这是表中最大的单一差异，且与模型质量毫无关系。

• 运行时 — 基于 trust_remote_code 的自定义建模代码，要求 Transformers 5.19 或更高版本，仅支持 BF16，无厂商提供的 GGUF，也没有文档记载的 vLLM 或 SGLang 路径；相比之下，未经修改的 Llama 工具链支持：vLLM、SGLang、llama.cpp、MLX、GPTQ、仓库中的官方 GGUF，以及已在流通的量化构建。

• 采用情况——仓库于10月24日出现后的四天内获得36次下载和10个点赞，而自9月6日以来则已获得1,216,145次下载和1,823个点赞。补充说明：MiniCPM的数据已有七周时间并配有发布帖，d1的数据则两者皆无，因此应将其视为成熟度信号，而非最终结论。

五毫秒与一个念头相比

Liquid 公布了 d1-Omni-2B 的热调用延迟，测量方式是在 BF16 下执行 compile() 之后，取二十次调用的中位数。在 H100 PCIe 上，单个问题耗时 5.8ms，三个问题 7.7ms，5,000 token 的状态 52ms，384 像素的图像 12.1ms，十秒音频 12.4ms。每次调用以 64 个状态为一批时，它每秒可处理 1,154 个状态；MI325X 还要更快，为 3.7ms 和每秒 1,697 个状态。M5 Pro 处理单个问题耗时 21.1ms，每秒处理 110 个状态——与数据中心级显卡相比算慢，但仍快到足以在桌面应用中感觉即时。

这一切都不是一场公平的竞赛，因为另一方并不公布用时。从结构上能说的是，解码器的延迟会随着它“思考”的多少而扩展，而 MiniCPM5-2B 就是一个为思考而构建的模型。在路由或分诊调用中——正确答案只是四个队列名称之一——你却在为没人要求的推理依据付费，而且还要按 token 为其付费。Artificial Analysis 给出了一个数字：在其 Intelligence Index 运行中，该模型输出了 7400 万个输出 token，而同类模型的中位数为 6700 万个，其摘要称其“略显啰嗦”。这并不是反对该模型的论据；而是反对把它用在 d1-Omni-2B 原本所构建的角色中的论据。

对待 d1 的这些数字，还是照例保持谨慎。它们是厂商测量值，在特定硬件上带着编译步骤测出来的，独立复现几乎肯定会落在别处。真正站得住的是数量级——每次决策个位数毫秒。

那条比记分牌更有分量的许可条款

MiniCPM5-2B 以 Apache-2.0 许可证发布。你可以将其用于商业用途、分叉、再分发、嵌入产品，而无需为此咨询律师。d1-Omni-2B 以 LFM Open License v1.0 发布，该许可证仅在你的组织年收入低于 10,000,000 美元时授予商业使用权。达到或超过该门槛时，许可证声明商业使用“不在本协议许可范围内”——这意味着你需要与 Liquid AI 另行达成安排，否则就不能发布该模型。

两者都允许再分发，其中 LFM 一侧附带条件：随附许可证、标注修改过的文件、保留声明。没有更名要求。对于一个研究团队、一个原型项目，或是一家从容处在门槛之下的公司来说，这一条款不过是形式上的手续。而对于一家有可能在该模型的有效生命周期内跨过这道门槛的公司的产品团队而言，这是一个在首轮基准测试结果出炉之前就会摆上桌面的采购问题——也是那种由法务部门在架构已经确定之后才迟迟发现的问题。

这种不对称足够明显，应当直言不讳而非含糊其辞：单就许可证而言，MiniCPM5-2B 是任何商业部署更稳妥的选择，而选择 d1-Omni-2B 时，其许可证是一项实实在在的代价，绝非可有可无的脚注。

你今天实际能运行的是哪一个？

MiniCPM5-2B 部署起来很无聊，而这是这个尺寸的模型所能得到的最高赞誉。它是标准解码器，因此 vLLM 和 SGLang 无需补丁即可支持，llama.cpp 和 LM Studio 能读取 GGUF，MLX 覆盖 Apple silicon，Q4_K_M 构建大约 1.45GB。唯一的陷阱是工具调用：模型会发出 XML 风格的调用，因此 vLLM 需要启用 minicpm5 工具调用解析器，否则你的函数调用会以普通文本形式到达。

d1-Omni-2B 还没到让人无聊的程度。加载它意味着要使用较新的 Transformers，并启用 trust_remote_code=True，外加 torch、torchvision 和 Pillow；该仓库只提供 BF16 safetensors，别无其他。没有厂商提供的 GGUF，模型卡里也没有合并好的 vLLM 配方，Hugging Face 也没有为其列出任何推理提供商——因此没有可用于测试的托管端点，这也是为什么不存在可报价的托管价格。大多数人会采用的实际路径是 Ollama 标签 d1-omni:2b，这是一个 4.4GB 的社区打包，封装了相同的权重。这可行。这也是开发者能在一下午内试用这个模型的唯一原因，而且它是第三方的工作，不是 Liquid 的。

两个模型都没有公开的按 token 价格，因为两者都不是按 token 出售的。你能找到的任何每百万 token 数字，都是根据 GPU 租赁费用推算出来的，而不是供应商报价。如果你要从成本上比较它们，就按一次决策要花多少秒 GPU 时间来比较——并记住，决策模型的答案在调用返回时就已完成，而聊天模型的答案则在它停止思考时才完成。

同时使用两者的模式

这一比较得出的诚实结论是：它们并非竞争对手，而实用的架构也正是这样对待它们的。d1-Omni-2B 负责处理成本低、数量大、对延迟敏感的判断：属于哪个队列、哪个团队、这是不是同一张发票、有多紧急、这十二个框里是哪一个。它在本地运行，返回一个你可以设定阈值的数字，并且在不知道时选择弃权。

MiniCPM5-2B 负责处理需要语言能力的部分：向客户解释决策、起草回复、编写修复方案、调用链条中的下一个工具。它在第一项任务上表现较差，在第二项任务上表现更好，而这种拆分带来的成本不过是在两者之间多一次函数调用——一条只有在廉价模型的置信度低于你的阈值时才升级到昂贵模型的路由。这个升级层正是路由平台存在的意义所在：用一个 API 密钥覆盖 200+ 模型，在提供商标价基础上 0% 加价，提供商出现短暂故障时自动故障转移，并且提供一种路由 DSL，让你能在单次调用背后组合多个模型。目前，d1-Omni-2B 和 MiniCPM5-2B 都不在 OrcaRouter 的目录中，因此这种模式中负责决策的那一半暂时仍需自托管——但生成那一半，也就是随着更好的小模型出现你会想要替换的那一半，恰恰是值得交给路由而不是硬编码的那一半。

谁应该选哪个

当状态包含音频或视频时，当需要的是概率而不是一句话时，当答案必须是边界框、文本跨度或带范围的数字时，以及当调用处在循环中、6ms 和 78ms 就代表不同产品时，选择 d1-Omni-2B。选择它时要清楚：许可阈值适用于你，部署属于定制代码的范畴，而且目前还没有独立评估——Liquid 自己的模型卡把不需要音频的人引向 d1-2B，这比大多数供应商主动给出的指导都更诚实。

当输入是文本时，当输出必须由人阅读或提供给需要成段文字的工具时，当你需要跨长文档进行推理时，以及当 Apache-2.0 和标准的 Llama 部署路径能在你写下第一行代码之前消除两类风险时，选择 MiniCPM5-2B。选择它时要清楚：厂商的 53.9 平均分尚未被复现；它在当前指数上的独立评分为 12——远高于同尺寸级别模型的中位数 5，且不能与早期版本记录的 15 或 23 相提并论；它已公布的最弱结果——Terminal-Bench 8.6 和 SWE-bench Pro 14.4——恰恰是最接近智能体工作的项目，而这正是它营销力度最大的方向。

如果你真正想要的是一款能看的小型聊天模型，那这两个都别选。MiniCPM5-2B 看不了，d1-Omni-2B 不会聊天，而人们把这两个名字中的任何一个输入搜索框时通常想找的模型，其实是同一系列里的另一个。值得关注的是 d1-Omni-2B 的首个独立音频评测。它的口语结果——在覆盖 43 种语言的 FLEURS 上为 92.5，但书面语为 42.0，在短陈述上听到时降至 22.8，在多语言段落上从 83.6 降至 41.8——所描述的是一个擅长识别语言、却在理解朗读段落时很脆弱的模型。除非 Liquid 之外的人测量这一差距，否则语音输入这一用例只是一个附带数字的承诺，而不是一项结果。