Liquid AI d1-ultra 与 Liquid AI d1-3B：每百万 $0.042 的租用端点，还是一个归你所有的 2.87 GB 检查点

Liquid AI d1-ultra按每百万输入 token $0.042 计费，并运行在别人的数据中心里、别人的加速器上。Liquid AI d1-3B每次调用计费为零，并运行在桌上的一台 Jetson Orin Nano 上。这两句话描述的是 Liquid AI 相隔八天发布的模型——d1-3B 是 2026 年 10 月 7 日宣布的开放权重检查点，d1-ultra 是 10 月 15 日发布的仅提供 API 的模型——而它们描述的是同一个任务：把由文本、图像或二者组成的状态交给模型，把一组带类型的问题交给它，然后在一次前向传播中取回经过校准的答案，且不生成任何输出 token。二者都不撰写散文。二者都不进行流式输出。它们之间的区别并不在于抽象意义上的“哪一个更聪明”，因为诚实的答案完全取决于你一天要问多少次。对于一个失败模式仍未被记录在案的模型，有用的对照物是其他地方已经出错的记录：围绕这一类模型的已记录 AI 事件和智能体故障都收录在 OrcaRouter AI Incident Archive其中每条条目都带有自己的来源、严重程度、置信等级和争议标记。

这种视角，正是这项比较比一纸规格表更有价值的原因。d1-3B 和 d1-ultra 分处一个决策的两端，而 Liquid AI 如今已在其自家文档中把这个决策明确说清：你可以按 token 租用该系列中能力最强的模型，也可以拥有一个 31.2 亿参数的模型，转而用芯片、电力和工程工时来买单。两者都是当前产品。d1-ultra 是该公司最新推出的东西，而 d1-3B 则可能是大多数读者应该首先上手的那一个。对于某个给定流水线来说，哪一个才合适是一个带有真实交叉点的算术问题，并且可以用已公开的数字来回答——接下来正是如此。

在给出数字之前，先做一条来源说明，因为它比数字的呈现形式更重要。下文几乎所有内容都来自 Liquid AI 自己的报告：模型卡、10 月 7 日的开放权重文章，以及 10 月 15 日的 d1-ultra 文章。我们没有为本文独立复现任何决策模型基准测试，而且据我们所知，也没有其他人复现过。如果某个数字是我们基于已公布数值所做的算术推算，而非任何人的实测结果，那么承载该数字的句子中会予以说明。

截至2026年10月中旬，每个模型实际上是什么

Liquid AI d1-3B 是一个开放权重的、拥有 31.2 亿参数的决策模型，基于 LFM2.5-VL-3B 训练而成，后者是一个仅含解码器的视觉语言模型。它配备了 SigLIP2 NaFlex 400M 视觉编码器、32,768 个 token 的上下文窗口和 128,000 个 token 的词表，可将文本、JSON、图像或其混合形式作为其状态，并在一次前向传播中回答一个或多个问题——Choice、Score 或 noul，后者是返回 0 到 1 之间概率的是/否原语。权重已在 Hugging Face 上以 LFM 开放许可证发布，供应商称该许可证可免费使用，包括年收入低于 1000 万美元的商业使用。官方表示首日即支持 llama.cpp，并提供覆盖 Apple、AMD、Qualcomm 和 NVIDIA 的 NVFP4 构建版本。

Liquid AI d1-ultra is the same shape of product pointed at a harder problem. It is API-only — there are no weights, no GGUF, no MLX or ONNX export, and the vendor's documentation index lists it in a row whose only downloadable artifact is the word "API". It was built, per the announcement, on "a larger open-weight model with a series of Liquid-specific heavy customizations," which is the entire architectural disclosure: no parameter count, no context window and no latency figure appear on the vendor's pages. Third-party gateway listings put the context window at 32,768 tokens and one listing has described it as roughly 8.3B total parameters with about 1.5B active per token, but those are catalogue entries, not vendor statements, and we treat them as unconfirmed. The model string is d1-ultra, on the same endpoint as d1: https://api.liquid.ai/decisions/v1/systemone.

那几段之所以显得如此失衡，并非出于编辑层面的取舍。它反映的就是整个对比本身。d1-3B 的文档详细到让你在下载任何东西之前就能把硬件配置估好。d1-ultra 的文档详细到只够你调用它，仅此而已。

这两个指数并不在同一把尺子上。

关于这一对数字的每一篇二手解读，都会把 65 和 48.57 并列在一起，让你得出显而易见的结论。先看清标签，因为这两个数字是按不同的统计口径发布的。

• 在 10 月 7 日的发布帖中，d1-3B 在 Decision Index v0.2.1 公开划分上的分数为 48.57。厂商还表示，该模型领先于所有 10B 以下的模型，并与 Decider 35B-A3B 持平，而后者的规模是它的十二倍。

• d1-ultra 的数值——65，在 10 月 15 日的帖子中被描述为在 Artificial Analysis Decision Index 上领先至少八分，并声称 d1-ultra 在所有任务上都胜过 Jev 1.14。有关该公告的媒体报道称 Jev 1.14 为 57，这与八分的领先优势相符。

有两件事是事实，且值得直说。第一，d1-ultra 的 65 背后的索引来自第三方，但这个数字是通过 Liquid AI 自己的公告以及对其的新闻报道传到我们这里的——我们自己无法加载出显示 65 的公开表格——因此在本文中它属于厂商报告的数据。第二，version-0.2.1 的公开划分分数和未标版本的索引分数并不保证处于同一尺度，而 v0.3 索引有一个私有视觉划分，公开版本明确没有针对它报告结果。应把这个差距视为方向性的——付费模型明显更好——而不是一个 16.4 分的测量值。包括我们在内，没有人让这两个模型经过同一套通用测试框架。

延迟：一个数字已公布，另一个没有。

开源模型的速度得到了异常详尽的记录，这使得付费模型上缺失相关信息更加引人注目。d1-3B 的模型卡报告称，在 RTX 4090 上单个问题耗时 8 毫秒，在 AMD MI325X 上为 9 毫秒，在 Jetson AGX Thor 上为 16 毫秒，在 Jetson AGX Orin 64 GB 上为 26 毫秒，在 Apple M5 Pro 上为 30 毫秒，在 Jetson Orin Nano 上为 50 毫秒，而在 MI325X 上打包吞吐量达到每秒 1,106 次决策。

这些是在具名硬件上的前向传播计时，不是端到端请求计时，而这个区别并非咬文嚼字。Liquid AI 上一次发布某个决策模型的托管延迟——即 10 月 5 日介绍 d1 的那篇帖子——是文本决策 200 到 300 毫秒，那是一个包含排队和网络的 API 往返，无法与本地显卡上 8 毫秒的一次前向传播相比。对于 d1-ultra，厂商根本没有发布任何延迟数字，无论哪种形式都没有。如果你的流水线受延迟约束而非受准确率约束，那么这种缺失就是本页最重要的一件事：你目前无法判断这个昂贵的模型是否快，而唯一能查明的方法就是自己测量。

营销页面不做的那道算术

这正是两个产品真正分道扬镳的地方，而且这是一道在餐巾纸上就能算出来的计算题。假设有一个支持分诊门控，每张工单问一个 noul 问题，每月 200,000 张工单，每个问题大约 1,200 个输入 token，其中包括一张小截图。那就是每月 2.4 亿个输入 token，而正是这个数量让每百万 token 的费率变得清晰可读。

• 对于 d1-ultra，按每百万输入 token 0.042 美元计算，每月约为 10.08 美元。对于 d1-3B，每次调用费用为零时，每月为 0.00 美元，再加上硬件的任何成本。

• 一个 2.87 GB 的 Q8_0 构建版本可以轻松装进 Jetson Orin Nano。如果你专门为这个工作负载购买这台设备，那么相对于托管端点的回本周期要以年计，而不是以周计——这才是诚实的结论，也是硬件厂商绝不会写进宣传册的那个结论。

• 把用量翻过来看。按每月 2 亿个问题——2400 亿输入 token——来算，d1-ultra 的账单大约是每月 10,080 美元，而本地版本仍然在消耗同样多的电。正是在这里，拥有检查点不再是一种哲学偏好，而变成了一项明细支出。

三点注意事项，全都指向同一个方向。上面每一个 token 计数都是我们选定的；你的状态长度和图像数量会不同，而图像按文本计费，每 32×32 像素的图块收 1.5 个 token，所以一张 1024×1024 的图像就是 1,536 个输入 token。每个问题都作为独立的提示计费，包含其文本和所有图像，所以对同一张截图问三个问题，就要为那张截图付三次钱。而这些都没有把工程成本算进去：本地路线给你带来的是要做的量化选择、要持续更新的运行时，以及一个在 3.12B 权重之前就先吃掉内存的视觉编码器。如果你一个月调用模型几千次，托管端点的成本比那场决定自托管的会议还低。

每个在何处不再是正确答案

Liquid AI d1-3B当以下任一情况成为硬性约束时，它就是合适的默认选择：数据不能离开本地或设备；网络跳转不可接受；调用量足够高，按次调用定价成为主要成本；或者状态是实时摄像头帧或截图，而你宁愿不把它发送给第三方。厂商自己的表述也支持第一点——开源发布明确面向 NVIDIA DGX、RTX 和 Jetson 硬件上的边缘与设备端部署——而该检查点在首月录得的 17,820 次下载表明，很多人很快就得出了同样的结论。

Liquid AI d1-ultra当决策本身才是难点时，它才是正确的选择。知识密集型问题、需要与现实世界背景进行匹配的视觉主张——供应商自己的示例是电路板缺陷，以及将损坏索赔与客户照片进行匹配——以及长尾案例，在这些案例中，3B 模型的置信度根本不值得信任。Liquid AI 对其提出的具体主张不仅是准确性，还有校准：文章认为，大多数决策模型都过度自信，而 d1-ultra 经过训练，使其概率具有实际意义。如果你是基于概率而非取 argmax 来设定阈值——将高于 0.8 的任何内容路由到自动解决，其余全部交给人工——那么校准就是决定成败的全部，而这也是本次发布中最难让外部人士核实的主张。

两者都不适用的情形也值得点名说明。如果你的答案是自由格式文本、多步推理轨迹或摘要，那么决策模型就是错误的工具，厂商在自己的文档里也这么说。如果你需要状态中包含音频，而不仅仅是文本和图像，那么这个家族的第三个成员 d1-omni-600M 才是能承接它的那一个——用 d1-ultra 来做这件事不是升级，而是范畴错误。

将其融入你已经在运行的技术栈中

决策模型几乎从来不是整条流水线。它是那道闸门：决定一张工单是否紧急、一张照片是不是缺陷、一次工具调用会不会获批的东西。总得有什么来写回复，而在本地路线上，那个什么就是你如今必须托管的第二个模型——这才是自托管真正的成本，也是那种永远不会出现在按 token 计费对比里的成本。在中小规模下真正行之有效的模式是：用一个本地的 d1-3B 承担高频闸门，用租来的端点处理罕见的棘手情况，再配上一个 OrcaRouter key，承载这些决策所分发到的生成式模型：一个 API 覆盖 200+ 模型，按提供商标价透传、0% 加价，以及跨提供商的自动故障转移，这样一个上游的糟糕下午就不会把你的分诊队列变成积压。值得把话说准：它覆盖什么、不覆盖什么——我们不托管任何 Liquid AI 模型，所以决策调用本身会发往 Liquid AI 的 API 或本地 checkpoint，而 OrcaRouter 是它背后的东西。

一旦你不再把决策模型当作固定不变，这种比较就不再是非此即彼。路由 DSL 让你能把廉价的 gate 和昂贵的 writer 组合进一次调用，而 fusion 则让一组模型共同给出答案——当单个模型不够可信时。这两者都不是选择 d1-ultra 而非 d1-3B 的理由，而是说明：在算账真正产生影响的量级上，这个选择值得重新审视。

什么会改变这个答案

三件事，按可能性排序。一个独立基准测试，让 d1-3B 和 d1-ultra 在相同任务上跑同一套测试框架——到那时，48.57 对 65 的差距就会成为一项测量结果，而不是方向性猜测。一个公开的 d1-ultra 延迟数据，没有它，任何对延迟敏感的流水线都应把托管模型视为未知项，并先在金丝雀路径中测量它。以及最终基于更大骨干网络发布的开放权重版本，这个家族的历史让这件事听起来没那么牵强：其他每一个最初以托管形式推出的 d1 模型，最终都在两天内变得可供下载。

在那之前，这条经验法则依然成立。先从 d1-3B 开始，因为它可以免费试用，在你可能已经拥有的硬件上运行得很快，而且文档足够完善，让你在正式投入之前就能合理评估所需规模。把那些结果无法令人信服的具体决策交给 d1-ultra。两者之间的差距是真实存在的；只是它比价格差异所暗示的要小，并且远小于那些指标数字在缺少版本标签、被并排列出时所暗示的差距。