从写出答案，转向直接回答问题
Liquid AI 发布的 Open d1，是 d1 决策模型系列中的两个开放权重多模态模型。d1-3B 接收文本和图像，d1-omni-600M 接收文本与图像，或文本与音频；两者都不生成自然语言答案，而是在一次前向计算中，根据输入状态和一组问题返回带类型的概率结果。响应中的 output_tokens 为 0，说明模型不以逐 token 写答案的方式交付结果。
这改变的是模型与应用代码之间的接口，而不只是输出长短。常见生成式调用先得到一段文本，再由程序从中提取标签、分数或判断，解析格式本身也可能出错。d1 则把答案范围放到调用中，让模型直接对允许的结果给出概率。它仍然需要计算，也仍然可能判断错误，只是把“读懂一段回答”的工作换成了“检查一个结构化决策”。
答案空间先由业务定义
d1 提供三种问题类型。noul 用于是非题，返回 P(yes)；choice 用于在命名选项中选择，并返回完整概率分布；score 则针对有序评分标准，给出概率加权位置，标准可以有 2 到 10 个等级。多个问题可以针对同一段输入一次提交，因此一条客服消息可以同时接受资格判断、团队分派和紧急程度评分。
这种设计适合答案可以事先枚举的工作流，也让调用方更容易看到模型到底被要求判断什么。但结构化结果不会自动修复问题定义：退款规则若漏掉例外，路由选项若没有合适的接收团队，模型就只能在不完整的选项中作答。概率看起来精确，也不等于它在该业务数据上已经校准。技术负责人需要把选项、评分锚点和阈值当作系统设计的一部分，而非调用模型时顺手填写的参数。
两个检查点的多模态能力并不相同
d1-3B 有 3.12B 参数，基于 decoder-only 的 LFM2.5-VL-3B，使用 400M 参数的 SigLIP2 NaFlex 视觉编码器，上下文长度为 32,768 tokens。Liquid AI 描述的构建过程包括对模型权重求平均、用不同随机种子和数据配方微调多个检查点，再合并这些检查点。材料还特别提到长输入、打乱答案选项和修复数据捷径，说明训练时要防止模型把表面线索误当成判断依据。
d1-omni-600M 是早期研究版本，总参数量为 587M，其中共享主干和决策头为 381M，视觉编码器为 94M，音频编码器为 112M。它使用双向的 LFM2.5-Encoder-350M 主干和 17 层 FastConformer 音频编码器，上下文长度为 16,384 tokens，音频片段最长 30 秒。一次请求可以带图像或音频，不能同时带两者；音频训练覆盖的是英语用户对助手发出请求的场景。这些限制意味着“支持音频”并不等于适用于所有语言、声学环境或音频任务。
零输出 token 只是延迟账本的一部分
Liquid AI 将 Open d1 放在 NVIDIA 的部署路径上，从 DGX 服务器、RTX 工作站到 Jetson 边缘板卡。两个检查点都可从 Hugging Face 获取，可通过 Transformers 加载，并有 llama.cpp 首日支持。这些入口降低了接入实验的门槛，但是否能进入生产，仍取决于目标硬件、推理栈和请求形态，而不是“开放权重”或兼容某个运行时本身。
d1-3B 模型卡报告，RTX 4090 上最快决策时间为 8 毫秒；不使用 model.compile(mode="reduce-overhead") 时，该卡每个问题为 16 毫秒。公开的 GPU 数字是在 bf16 下、一次处理一个暖请求测得，报告 20 次运行的中位数，Jetson 数据由 NVIDIA 测量。材料以 33.3 毫秒作为 30 帧每秒的一帧时长参照，但这不能替代特定业务的端到端延迟预算。尤其是 d1-omni-600M 尚无公开延迟数字，因此不能把 d1-3B 的测量结果外推给它。
适用边界由业务风险和评估决定
Liquid AI 给出的应用方向包括路由、内容审核、意图分类、重排、LLM-as-a-judge 评分、Agent 防护和视觉检查。这些任务有一个共同点：系统通常可以提前定义候选标签或评分尺度，因而可能受益于直接返回概率，而不是解析自由文本。比如客服分流可以把判断拆成是否符合退款条件、由哪个团队接手、紧急程度如何，再让后续业务代码按策略处理。
但“返回概率”不等于“概率可以直接当阈值使用”。上线前仍要用业务数据检查分类质量、校准情况、错误代价和边界案例，并在目标设备上测端到端表现。Open d1 使用 LFM Open License v1.0，年收入低于 1,000 万美元可免费商用，部署方仍需确认许可条件适用于自身情况。实际判断应当是：先选答案空间稳定、失败可监控的窄任务做对照评估，再决定是否把生成式调用替换为 d1；开放权重、零输出 token 和一次前向计算，都不能代替这一步。