你打开一个评论区，系统要同时判断每条留言是否有毒、是否是垃圾信息、是否在提问，以及整体语气。普通生成式模型会把答案逐字写出来，系统再从文字里提取结果。Liquid AI 想省掉这段绕路：让模型看完状态后，一次给出多个结构化判断。
这就是它所谓的“决策模型”——把输入直接映射到“是/否”、指定类别或评分，而不是陪人聊天。Liquid 现在用 d1-3B 和 d1-omni-600M 把这条路线铺成了一大一小两档，并由第三方把小模型搬进浏览器。需要先说明，榜单、速度和“零输出 token”等关键说法主要来自发布方；浏览器数据则是一位移植者的单次演示，并非完整测评。
不写答案，直接做选择
决策模型适合审核、分类和路由：例如判断一张电路板是否合格，或把一张工单分给哪个团队。用户提供文字、JSON——一种便于程序读取的结构化数据格式——或图片，再列出若干命名问题，模型从预设选项中选择答案。
Liquid 对 d1 的核心描述是“一次前向计算”。前向计算就是输入完整通过神经网络、得到结果的一轮计算。按照官方说法，d1-3B 不必逐字生成回复，而是直接读取各选项的概率；token 是模型处理和生成文字的基本单位，因此“zero output tokens”意味着不用先写成句子，再由程序解析。
不过，这一点尚不能当作完全坐实。Liquid 的 Hugging Face 页面一边把 d1-3B 描述为零输出 token 的决策模型，一边又展示了 model.generate 和最多生成 256 个新 token 的通用示例。后者可能只是平台自动提供的生成式接入模板，但在技术文档进一步澄清前，两种接口究竟如何对应仍不明确。“calibrated”——概率经过校准、能较可靠地表示置信程度——也没有配套指标可供核查。
从 3B 主力，到 600M 随身版
d1-3B 基于 LFM2.5-VL-3B，可同时处理文字、JSON 和图片。官方给出的 Decision Index 0.2.1 得分是 48.57，高于 Decider 35B-A3B 的 47.11，并称其为 10B 参数以下最佳决策模型。但这里混用了模型总参数量与每次推理实际激活的参数量，“超过 35B”并不等于用 3B 正面击败同口径的 35B；材料也没有提供榜单权重、精度格式和复现实验。
它在 11 个公开图像基准上的汇总分为 74.1，略高于基础模型的 73.9。Liquid 还宣称单次决策在 RTX 4090、AMD MI325X 和 Apple M5 Pro 上分别需要 8、9 和 30 毫秒。这些数字说明它瞄准低延迟应用，但测试配置、批大小等条件没有披露。目前 Hugging Face 已提供模型权重，并列出 Transformers、vLLM、SGLang 和 Docker 等接入入口。
d1-omni-600M 则把同一思路压到边缘设备尺度。按发布材料，它实际有 587M 参数：共享主干与决策头 381M，视觉编码器 94M，音频编码器 112M。多模态意味着模型能同时处理文字、图片或声音；它可接收文字或 JSON，结合图片或最长 30 秒的语音，在一轮计算中回答多个命名问题。
第三方开发者已把它移植到 runntime：这是一个基于 TypeGPU、用纯 TypeScript 编写的 WebGPU 推理库。WebGPU 让网页调用设备的图形处理能力，因此模型可以直接在浏览器里加载 Hugging Face 的 safetensors 权重。演示中，每条评论同时回答四个审核问题约需 180 毫秒，平均每题约 45 毫秒。不过作者没有说明硬件、浏览器、量化方式、样本量或统计方法，这只能看作一次可运行证明。
为什么值得现在看
我们此前报道过，ruNNtime 已借助 WebGPU 把 EmbeddingGemma 2 带进浏览器，当时解决的是跨模态检索。这次工具链没变，任务却从“找出相近内容”前进到“直接作出结构化判断”。模型不只变小了，输出方式也开始围绕产品流程设计。
据 Liquid AI 官方介绍，公司由四位 MIT CSAIL 研究者创立，早期就主张从生物学、物理学和神经科学等“第一性原理”重新设计模型。d1 不追求写得更像人，而是把审核、分流、检查这类窄任务做得更直接。3B 版本覆盖常见部署框架，600M 版本加入声音并进入浏览器，已经显出产品线轮廓。
局限与未知
- “一次前向、零输出 token”的专用决策接口，与 Hugging Face 页面上的生成式示例存在表述冲突。
- 榜单、视觉得分和硬件延迟均主要来自发布方，缺少完整测试条件与独立复现。
- 浏览器移植尚未进入 runntime 的 npm 正式版本；180 毫秒只是未注明环境的演示结果。