Liquid AI d1 API：托管还是本地部署

如果应用需要的是分类、是非判断或评分，Liquid AI d1 值得纳入评估。 官方托管 d1 API 的价格为每百万输入 token 0.04 美元，不生成输出 token。本地部署可选支持文本与图片的 d1-3B，或体积更小、额外支持语音的实验模型 d1-omni-600M。三者属于不同的部署选项，同属一个系列并不代表效果相同。

想快速验证业务流程，可以先试托管 API；需要离线运行、控制数据流向或降低设备端延迟，再评估开放权重。在这个托管单价下，单纯为了省 token 费用而自建服务，未必划算。

d1 能做什么

Liquid 在 2026 年 10 月 5 日发布托管模型，并于 10 月 7 日开放两个模型的权重。d1 通过一次前向计算返回指定类型的决策结果，无需逐 token 生成答案。它支持三类问题：

• noul：返回“是”的概率，例如判断工单是否要求退款。
• choice：从预先定义的类别中选择，并返回各选项的概率。
• score：按预先定义的有序等级，返回概率加权后的分数。

适合的任务包括工单路由、检索结果重排，以及文本或图片检查。需要写代码、生成摘要或用自然语言解释原因时，仍应使用生成模型。官方迁移指南明确区分了这些任务。另一类决策 API 的接入方式可参考我们的 Jev 指南。

托管 d1、d1-3B 与 d1-omni-600M 对比

600M 模型卡还有几项不能忽略的限制：同一请求只能携带图片或音频，不能同时携带两者；使用图片时，状态和问题文本会被截到 896 token。音频需为 16 kHz 单声道、最长 30 秒，训练任务来自英语说话者与助手的交互。这不构成多语言语音准确率保证，也不是转写服务。

Liquid 公布的 Decision Index 0.2.1 结果为 d1-3B 48.57、d1-omni-600M 15.95，使用官方评分器计算，并非榜单提交成绩。这支持把大模型作为重视质量时的优先评估对象，但不能推导出它在所有分类任务中都更好，也不能据此认定开放模型与托管 d1 效果一致。

每百万 0.04 美元究竟怎么计费

托管版发布说明的方法部分给出每百万输入 token 0.04 美元的单价。API 文档进一步说明：每个问题都按自己的文本和全部传入图片计费。把多个问题放进一次 HTTP 请求，不代表共享输入只收费一次。

假设有 10 万次请求，每个问题合计 1,000 个计费输入 token：

• 每次一个问题：100,000 × 1,000 ÷ 1,000,000 × 0.04 美元 = 4 美元。
• 每次三个问题，且每个问题仍合计 1,000 token：12 美元。

以上只计算 token 费用，不含税费和其他费用。问题长度与重试次数都会改变账单，应读取 usage.input_tokens，不能只统计状态文本。HTTP 响应虽然包含 JSON，但 usage.output_tokens 仍为零。

每张图片对每个问题贡献的输入 token 为 ceil(ceil(width / 32) × ceil(height / 32) × 1.5)。一张 1024 × 1024 图片为 1,536 token，对应 0.00006144 美元，还需加上文本。对这张图片提三个问题，图片部分就是 4,608 token。这是图片理解费用，不是图片生成价格，也不是 OmniaKey 报价。

本地部署真的更便宜吗

应比较月度总成本，包括硬件折旧或租金、电费、工程时间、监控、适用的授权费用，以及错误决策的处理成本。“权重可免费下载”不等于服务免费运行。

举一个明确假设的例子：本地总成本若为每月 50 美元，按托管单价可购买 12.5 亿输入 token，计算为 50 ÷ 0.04 × 1,000,000。每次请求计费 1,000 token 时，对应 125 万次请求。这只是账单比较，不是硬件报价，也不证明本地模型与托管模型质量相同。

如果决定性需求是断网可用、数据边界或设备延迟，即使用量较低，本地运行仍可能更合适。评估时记录总运行成本 ÷ 验收通过的决策数，同时保留错误和人工复核数据。路由错了，即使调用更便宜也可能增加业务成本。

下载前先看许可证和硬件需求

两个仓库都使用 LFM Open License v1.0。官方授权指南说明，年收入低于 1,000 万美元可免费商用，超过门槛需另行取得商业许可。处在门槛边界时，应结合许可证原文向 Liquid 确认资格。再分发还需保留许可证和署名、按要求附带 NOTICE，并标明修改；下游商业用户也要分别判断自身资格。实际交付前请阅读对应的 d1-3B 许可证和 600M 许可证。开放权重不等于不受限制的 Apache-2.0 授权。

按参数量乘以两个字节估算，16 位权重本身约占 6.24 GB 和 1.174 GB，这里使用十进制单位。这是计算出的权重存储量，不是最低内存或显存要求。运行时缓冲、激活值、媒体处理和批处理都会增加占用；量化也可能改变决策质量。

3B 模型卡报告：预热后的单问题调用在 RTX 4090 上为 8 ms，在 Apple M5 Pro 上为 30 ms；换成 3.4K token 的状态输入后，分别为 102 ms 和 640 ms。RTX 4090 数据使用了编译优化。这些是特定输入条件下的厂商数据，不是冷启动耗时或 API 延迟承诺。600M 模型卡没有公布推理耗时。

托管 API 调用与本地启动

官方托管接口为 POST /decisions/v1/systemone，请求结构不同于 Chat Completions。先将 Liquid 控制台创建的密钥放入 LIQUID_API_KEY。下面保留英文客服请求作为统一示例，执行时会产生计费调用：

curl --fail-with-body https://api.liquid.ai/decisions/v1/systemone \
  -H "Authorization: Bearer $LIQUID_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "d1",
    "state": "Please refund the duplicate charge.",
    "questions": {
      "refund": {"type": "noul", "instructions": "Is a refund requested?"}
    }
  }'

读取 answers.refund.noul 中的概率，并用自己业务的标注样本确定阈值。发送图片时，官方 API 要求 base64 图片数据，不接受远程图片 URL。

本地运行需安装支持 d1 决策接口的较新 llama.cpp 版本，然后按官方 GGUF 示例启动：

llama-server -hf LiquidAI/d1-3B-GGUF:Q8_0

在另一个终端调用本地决策接口：

curl --fail-with-body http://127.0.0.1:8080/v1/systemone \
  -H "Content-Type: application/json" \
  -d '{
    "state": "Please refund the duplicate charge.",
    "questions": {
      "refund": {"type": "noul", "instructions": "Is a refund requested?"}
    }
  }'

若要评估较小模型，先停止上述服务，再使用 600M 的启动参数：

llama-server -hf LiquidAI/d1-omni-600M-GGUF:Q8_0 -b 4096 -ub 4096

它的批大小必须容纳整个问题；模型卡要求较长状态相应增大参数，最高到 16,384。本文对照官方资料核查了命令，未实际执行推理。评估时请一并记录模型、量化方式和运行时版本。

应该先试哪个

网络稳定且用量较低或尚不确定的服务，可以从托管 d1开始。本地文本和图片决策可优先评估 d1-3B；需要语音或更小体积，并能接受实验版限制时，再单独评估 d1-omni-600M。

三种方案都应使用相同的标注任务、分类定义和验收规则，记录误路由、漏判、p95 延迟、峰值内存和转人工或备用模型的频率。模型返回概率不等于换一种语言或数据分布后仍然可靠，校准效果也要在业务数据上复核。

OmniaKey 的模型目录提供网关当前模型及价格。本文核实的是 Liquid 官方 API 和本地部署方案，不代表 OmniaKey 已支持 d1。决策流程之外的生成任务，可另外比较目录中已列出的模型。