一次前向传播、0 个输出 token：LiquidAI 把 d1-3B 做成了一台「只判断不写话」的边缘决策引擎
这周看到 LiquidAI 把 d1-3B 挂上 Hugging Face 时，我第一反应是愣了一下它的定位——3B 参数的 decision model，不是聊天模型，不写文本。你给它一段状态（文字、JSON、图片或混合输入）加一组问题，它一次前向传播直接返回结构化答案，输出 token 数是 0。放在「模型发布」这个语境里，这个角度挺不一样：大多数开源模型还在卷生成质量，d1-3B 干脆把「生成」整个砍掉，只做判断。
先看它拿得出手的数字。在 Decision Index 0.2.1 上它拿到 48.57，官方文档标注为 10B 以下最优决策模型，超过所有 4B、9B 的对手，也压过 35B（36B 参数）的 Decider 35B-A3B（47.11）。有意思的是，这分数靠单次前向传播就跑出来了，没有链式思考，也没有多轮采样。视觉那一路也保留了：11 个公开图像 benchmark 均值 74.1，比它底座 LFM2.5-VL-3B（73.9）还略高一点点；而把图片去掉后，同一组问题只拿到 45.1，说明分数确实是看图看出来的，不是靠猜。
真正让我有体感的是速度和部署形态。单问题在 RTX 4090 上 8ms，AMD MI325X 上 9ms，Apple M5 Pro 上 30ms；边缘设备这边，Jetson AGX Thor 单问题 16ms，Jetson Orin Nano 50ms。更夸张的是 batch：64 个请求无 padding 打包进一路，RTX 4090 上能到 475 次/秒，AMD MI325X 上 1106 次/秒。它天生就是干「工位判断型任务」的料：路由和分诊、内容审核、意图和话题分类、抽取校验、rerank、LLM-as-a-judge 打分、Agent 护栏、视觉质检。
这些东西放在一起，指向一个很具体的痛点：现在不少 Agent 和内部 pipeline 里，LLM-as-a-judge 是拿一个完整聊天模型去套固定模板，结果每次判断都要生成一大段 token、付一次推理延迟，还得处理格式不稳定的 JSON。d1-3B 的做法是把判断本身做成一个前向传播的原语——你定义好问题（yes/no 用 noul，选项用 choice，分级用 score）和 criteria，它一次读完 state 和图片，把多个问题一起答完，返回 {"answers": ...}，usage 里 output_tokens 永远是 0。
用法也不算复杂，transformers>=5.14 装上，trust_remote_code=True 加载就行。代码里给了一个挺典型的客服分诊例子：一封「我被重复扣款，请退其中一笔」的工单，一次调用同时判 refund、team（billing/technical/fraud）和 urgency，还附带一张「两只猫在沙发上」的图，要判别有几只猫——这是为了说明图片可以直接作整个 state 输入，system_one(None, questions, images=[...]) 这个写法。batch 场景用 system_one_batch，把多个请求打包在一起跑。
当然，夸之前得把边界讲清楚。它不做文本生成，你要它写推理过程、写摘要、凑一段回复，它干不了，这本来就是设计目标。再一个，所有 benchmark 都是公开数据集上的结果，Decision Index 那行 48.57 是 LiquidAI 用官方 scorer 自己跑的（不是 leaderboard 提交），横向对比的其他行来自公开榜单 v0.2.1——这类分数我只当参考，不当「能打遍天下」的证据。模型底座是 LFM2.5-VL-3B（3.1B 参数，SigLIP2 视觉编码器 400M，上下文 32768 token），目前派生模型有两个 finetune、17 个量化版本，说明社区已经有人开始往下游改了。
我的判断是：d1-3B 想重新定义的不是「更强的模型」，而是「判断这件事在端侧该怎么被嵌入」。以前要在边缘设备塞一个能做审核、做分诊的东西，要么上完整的 7B/13B 聊天模型拖慢速度，要么写死规则逻辑。它给了个中间态：专门做结构化决策的小模型，跑在 Jetson 甚至手机芯片上，一次前向传播出答案。这个思路能不能被广泛接受，还得看真跑进 production 之后的事——比如对格式不稳定输入的鲁棒性、17 个量化后掉多少分、以及「0 输出 token」这个卖点是不是真能省出明显成本。这些我暂时没核到更多公开细节，先不下定论。反正有一点是确定的：下次再看到「LLM 判题」，我不会默认它必须是个会写字的聊天模型了。