先看证据
把机制串起来
分类、路由和审核本质上都是在有限答案集合中做决策，而不是生成一段新文本。概率输出表示模型对每个结果的信心，可用阈值把自动通过、自动拒绝和人工复核分开。校准概率的含义是：长期看，预测为0.8的样本应大致有80%真正属于该结果；但材料没有给出d1的校准评测方法。
请求由模型、状态和问题组成，状态可为文本或JSON，问题则提前声明类型与候选答案。Noul输出0到1的二元概率，Choice返回最高选项、完整分布和confidence，Score把有序等级映射为概率加权位置。多个问题可以在同一状态上一次评估，避免原本多个串行分类调用。零输出Token意味着不走逐Token文本解码，但不代表没有推理计算；材料没有公开其内部网络或概率头实现。代价是答案空间必须事先设计，无法直接承担摘要、写作、开放式问答等任务，且API-only限制了本地部署。
['适合分类、工单路由、审核、重排和LLM-as-judge', '用0.8/0.2等阈值划自动处理与人工复核', '置信度低于0.5时可回退到更强模型层级', '不适合摘要、写作、聊天、代码生成和开放推理']
先把问题从“生成什么”改成“选哪一个”
Liquid AI 发布的 d1 是一个面向结构化决策的模型，而不是用来写文本的通用语言模型。调用方提交一段状态信息，以及一组预先定义、带有类型的问题，d1 在一次请求中返回固定选项上的概率，而不是生成解释、标签字符串或 JSON 文本。每次响应的 usage.output_tokens 都是 0，这意味着模型的接口结果不是“少写一点”，而是根本不把答案组织成输出序列。
这个定位针对的是大量被通用 LLM 包办的窄任务：工单分类、路由、评分、内容审核、重排序和 LLM-as-judge 检查。Liquid 给出的迁移规则很直接：如果答案是 N 个已知选项之一，可以考虑决策模型；如果系统必须合成一段新的字符串，仍应保留 LLM。这个区分看似简单，却决定了团队应当把 d1 放在工作流的哪个位置，而不是把它当作一个更便宜的聊天模型。
三个原语把分类接口变成概率接口
d1 的接口由三种问题原语组成。Noul 用于是非判断，返回 0 到 1 之间的概率，例如“这是否是客户投诉”；Choice 从命名选项中选出一个结果，同时返回最高选项、完整分布和置信度；Score 则把输入放到有序评分标准上，并返回概率加权的位置。Score 的等级从 0 开始，因此四级紧急程度的范围是 0 到 3。
这三种问题可以放在同一个请求里，让模型针对同一份状态一次完成多项判断。材料中的例子显示，一条关于重复扣款的工单在 billing 选项上得到 0.9997，生产中断在四级紧急度上的得分为 2.9995，“是否投诉”的判断则为 0.999。这些数值应被理解为接口提供的概率结果，而不是模型用自然语言自报的信心分数。对工程团队而言，差别在于它们可以直接进入阈值和分流逻辑，而不必先解析一段文本。
真正的架构收益在解码环节之外
d1 的调用包含三个部分：model、state 和 questions。请求发送到 Liquid API 的 systemone 端点，官方示例使用 d1:free，并通过 TypeSafe AI 的 Python 或 TypeScript SDK 调用。state 可以是普通文本，也可以是 JSON 对象，因此模型输入的组织方式本身成为系统设计的一部分，而不是只能把一整段提示词塞进上下文。
Liquid 将它与带结构化输出的 LLM 对比时，强调了几项工程取舍：没有计费的输出 token，没有随输出长度增长的解码循环，答案始终符合问题类型，也就少了 malformed JSON 和重试路径。原本需要三次顺序分类调用的工作流，也可以合并为一次请求。对低延迟路由和审核流水线而言，这些变化比“回答更像人”更有价值，因为它们减少的是协议层和调度层的不确定性。
概率只有进入策略，才会变成系统能力
d1 的价值并不在于返回一个看起来精确的小数，而在于让团队可以把不确定性写进策略。Liquid 的审核示例把概率分成三个区间：高于 0.8 直接拦截，低于 0.2 放行，中间区域交给人工复核。路由示例则在置信度低于 0.5 时退回能力更强的模型层级。这样，模型不再只是给出一次性 verdict，而是成为策略引擎中的一个带门槛的判断节点。
这也改变了评估重点。团队需要验证的不是模型能否稳定生成某个标签，而是概率是否足以支持阈值决策，重复评估是否减少 verdict flips，以及人工复核区间是否可控。材料还指出，d1 在相同输入上的重复评估更加一致，但现有信息没有提供独立基准、延迟数据或校准误差，因此不能据此断言它在所有数据集上都优于通用 LLM。概率接口降低了接入成本，却没有取消校准和业务阈值的验证工作。
部署边界决定了它不是通用替代品
目前 d1 可以部署，但方式是调用 Liquid API 上的托管服务，模型名为 d1:free。Liquid 的模型库将其标为 API only 和 not trainable，因此没有 GGUF、MLX 或 ONNX 权重可供自托管。对于需要把数据留在本地、在边缘环境运行，或对模型进行微调的团队，这不是一个次要限制，而是架构选型的前置条件。
Road Decider 演示进一步说明了 d1 的适用形态：Node.js 18+ 的应用以 Choice 问题在每个决策 tick 选择左、中、右车道，速度约为每秒 2 到 5 次，Vite 代理负责把 API key 留在服务端。演示最有用的结论不是游戏本身，而是状态设计：包含各车道摘要和距首个障碍物距离的状态，比原始道路网格让决策更有信心。实际采用 d1 时，应先把状态压缩成可判定的结构，再决定阈值和回退路径。若任务需要摘要、起草、多轮对话、代码生成或复杂多步推理，保留 LLM 才是更稳妥的边界。