一个 token 都不生成：Liquid AI 开源 d1 决策模型，3B 打平 35B，边缘设备上 50 毫秒出答案

你让大模型审一条评论。它想了 800 毫秒，吐出来五个 token：{"toxic": true}。你等了一整个来回，付了一整次的钱。

更扎心的是，这五个 token 里真正有用的只有 true 那一个。括号、引号、键名，全是格式税。

10 月 7 日，Liquid AI 这家公司开源了 d1 决策模型，两个尺寸一起放上 Hugging Face：d1-3B 和 d1-omni-600M。它做了一个很极端的选择，一个 token 都不生成。

我们一直在为一次根本不需要的生成买单

审核、分类、路由、打分，这些活的终点是一个判断，不是一段文字。可我们偏要让一个自回归模型把答案一个 token 一个 token 憋出来，再用正则把它塞回结构体里。这在工程上叫 workaround，在账单上叫浪费。

我们之前聊过让大模型闭嘴只做选择题，用约束把输出锁成一个 JSON。那是在生成式模型的笼子里做约束，token 还是一个一个吐。d1 不走这条路，它直接把生成这一步砍掉了。

用法朴素到有点反直觉：喂进去一个 state，可以是文本、JSON、图像或音频，再喂一组问题，一次前向传播，直接返回带类型、带校准的答案。没有自回归，没有 KV cache 一点点长出来，也没有那句多余的寒暄。

带类型，就是返回布尔值、枚举值、数字，不是一段还得再解析一遍的字符串。带校准，就是官方在训练阶段对齐过概率，那个数字能拿来排序，而不是 softmax 拍脑袋的产物。

结果是延迟恒定。它不是更快的大模型，它是另一个东西。

两个尺寸的底座完全不同。d1-3B 基于 decoder-only 的 LFM2.5-VL-3B，吃文本加图像。d1-omni-600M 基于双向编码器 LFM2.5-Encoder-350M，外挂视觉编码器和 FastConformer 音频编码器，587M 参数，吃文本加图像，或者文本加音频。官方明说了，omni 是实验性 checkpoint，早期研究版本，别拿它扛生产。

一次前向传播出答案：文本、图像、音频进，概率、枚举、分数出

只有三种问法，却覆盖了大部分脏活

d1 只认三种问题类型。

noul：问是或否，返回”是”的概率。
choice：从你给出的命名选项里挑一个，返回每个选项的概率加一个置信度。
score：按你描述的量表打分，2 到 10 级，从最低到最高。

够用吗？看官方列的那串场景：路由与分诊、内容审核、意图分类、抽取校验、重排序、LLM-as-a-judge 打分、Agent 护栏、视觉质检。清一色的选择题和打分题。生产环境里真正需要”写一段话”的活，比我们以为的少太多了。

还有一条边角信息：llama.cpp 侧的 choice 最多支持 255 个选项。这条来自 llama.cpp 的相关说明，不是官方承诺，接近上限时自己压一遍。

边缘设备上的决策闭环：从质检产线到配送机器人，一次判断几十毫秒

把决策搬回设备本地：4090 上 8 毫秒，Orin Nano 上 50 毫秒

速度这组数字是官方与 NVIDIA 联合测的，单问题：RTX 4090 8 ms，AMD MI325X 9 ms，Jetson AGX Thor 16 ms，Jetson AGX Orin 64GB 26 ms，Apple M5 Pro 30 ms，Jetson Orin Nano 50 ms。

先别激动。这组数字的前提是短输入。把 state 拉到 3.4K token，画面立刻变了：RTX 4090 102 ms，Apple M5 Pro 640 ms，Jetson Orin Nano 1640 ms。8 毫秒是短输入的数字，输入越长越贵，而且几乎是线性地贵。这条比前面那一整串都重要。

反过来，它有个别的模型给不了的好处：一次问 3 个问题，大约是问 1 个的 1.3 倍耗时。问题可以打包，这是决策模型才占得到的便宜。

吞吐也测了，打包 64 个 states：MI325X 1106/s，RTX 4090 475/s，Jetson AGX Thor 262/s，Orin Nano 38/s。

落地路径不绕：day-one 就支持 llama.cpp，覆盖 Apple、AMD、Qualcomm、NVIDIA，含 NVFP4。据第三方整理，Q8_0 约 2.87 GB，加上图像投影约 580 MB，大约 4 GB 内存能跑起来，Q4_K_M 约 1.67 GB。也可以直接用 Python transformers 加载 LiquidAI/d1-3B。

想直观感受这个速度差，去 HF Space 看那 10 个实时摄像头 demo。手势游戏、实时内容审核，每一帧都完整跑一次前向传播，画面是连着的。换成调云端 API，每一帧都要等一个来回，卡的是肉眼。

48.57 分，打平一个 12 倍身量的对手

Decision Index v0.2.1 公开集上，d1-3B 拿到 48.57。官方口径是超过所有 10B 以下模型，并与 Decider 35B-A3B（47.11）持平，后者大约是它 12 倍大。d1-omni-600M 是 15.95，量级差着，别硬比。

七个公开文本基准的平均分，覆盖阅读理解、毒性检测、意图分类、医学问答、跨语言理解：d1-3B 82.9，d1-omni-600M 78.4，Decider 4B 81.1，Decider 2B 77.1。

拆开看更诚实。SQuAD 2.0 85.3；Civil Comments 93.0，而 omni 在这项上是 95.8，全表最高；MASSIVE 意图 87.3，不如 Decider 4B 的 88.3；PubMedQA 66.0；BoolQ 86.7，Decider 4B 是 89.0；XNLI 85.0，Decider 4B 是 88.6；PAWS-X 76.9。赢的赢在细粒度判断，输的输在知识。

短板官方也认：world knowledge 只有 23.8，更大的模型在 30 以上。别拿它当知识库使。视觉和音频没有公布基准分数，官方的说法是音频决策基准本身还是个开放问题。

这些数字全部是 Liquid AI 自测，厂商口径，公开集上的厂商跑分，没有第三方复现。可以拿它做选型参考，别拿它当验收标准。

两个尺寸怎么挑，看你有什么输入和什么设备

这两个不是大小版本的关系，是两条不同的路。选错不是慢一点的问题，是根本跑不起来。

如果你要最高的决策质量，输入是文本加图像：选 d1-3B，边缘端走 llama.cpp，服务端用 transformers 都行。
如果你只有几百 MB 内存余量，或者必须吃音频：选 d1-omni-600M，代价是它挂着实验性版本的牌子。
如果你的输入是摄像头视频流：官方在 HF Space 放了 10 个实时摄像头 demo，手势游戏、实时内容审核这类，每帧一次前向传播；他们同时和 NVIDIA 在 Isaac Sim 里跑硬件在环。
如果你打算喂音频：先记下三条限制，16 kHz 单声道、最长 30 秒、训练数据以英语请求为主，覆盖话语类型、主题、意图。它不是通用声音分类器。

四个坑，官方 README 里不会写

坑1：在 Ollama 里搜 d1，搜不到。根因是 Ollama 库里放的是 Liquid 的 LFM2、LFM2.5 聊天模型，跟决策模型是两条产品线。解法是回到本地部署那条老路，用 llama.cpp 起服务，启动就一行命令 llama-server -hf LiquidAI/d1-3B-GGUF:Q8_0，然后把 state 和 questions 提交到 /v1/systemone。
坑2：把 8 毫秒当成常态，上线后发现比调云端还慢。根因是 8 ms 对应的是短输入、单问题、RTX 4090 三个条件同时成立。解法是拿你真实的 state 长度压一遍，3.4K token 在 Orin Nano 上是 1640 ms，这不是故障，是线性代价。
坑3：看到开放权重，直接搬进生产。根因是许可是 LFM Open License v1.0，不是 Apache 2.0。解法很土，商用前先读官方 LICENSE 原文，别读二手解读。
坑4：把返回的概率直接当业务阈值，卡 0.5 一刀切。根因是校准是在它自己的训练分布上做的，不是在你的数据上。解法是先拿概率当排序用，阈值用自己的标注数据重新定。