Liquid AI、PostHog 与 Qevi 同日发布决策模型，小模型走向本地部署

9 月 29 日，三个小而专的模型在几小时内先后落地。三者思路相同：不做文本生成，直接从模型里读出概率，并且跑在自己能掌控的硬件上。

Liquid AI 的文档页把 d1 描述为“一类专为结构化决策打造的新型 AI 模型”。页面说，决策模型不逐个生成 token，而是“评估一个情境，在一次调用中返回固定结果集合上的校准概率，生成的 token 数为零”。公司给出的示例响应显示，一条投诉检测查询的 usage.output_tokens 为 0，返回的 noul 值为 0.999。

三种问题形态，不生成文本

Liquid 把决策问题分成三类。noul 是是非题，返回 0 到 1 之间的概率，文档称之为“滑动刻度上的布尔值”。choice 返回具名选项上的分布，例如 {"billing": 0.65, "technical": 0.30, "account": 0.05}。score 返回有序评分表上按概率加权的位置。一个三档紧急程度的问题，可能返回 1.85，落在“Medium”和“High”之间。

文档明确说 noul 和 score 不能互换。noul 取 0.5，表示在“是”与“否”之间最大的不确定，“不说明程度或强度”。代码要在连续量上比阈值，文档指向 score；要用布尔值做开关，就用 noul。API 接收一个状态加上一个或多个具名问题，一次调用全部作答。客户端库有 Python（typesafe-sdk）和 JavaScript（@typesafe-ai/sdk），密钥以 liquid_ 开头。

Liquid 这个页面是文档，不是基准测试论文，所以没有给出 d1 的准确率数字。这一点很关键。同一周出现的另外两个模型都公布了数字，而两者之间的差距很有说明性。

Jeeves 在 Jev 的公式上加进推理

PostHog 在 GitHub 上为 Jeeves 建的仓库把它描述为“一个带扩散草稿器的推理型 Jev 式分类器，用 SFT 和 CISPO 训练”。它是基于 Qwen3.5-9B 的 9B 模型，加了 LoRA 和一个指针头，外带 block-4 扩散草稿器，以及完整的训练代码和数据。仓库称它在从未训练过的测试数据上超过 Kev-9B 和 Jev，得分为 0.889，对手分别为 0.822 和 0.857；在 JevBench 公开档位上为 0.935，Jev 为 0.866。

仓库还公布了更完整的一张表，而这张表并非处处好看。Jeeves 在覆盖 MMLU-Pro 和 buried state 的迁移任务上得 0.746，低于 Jev 的 0.800。在 MMLU 上掉到 0.793，Jev 为 0.900；在 MMLU-Pro 十选一上降到 0.739，对手为 0.840。它赢在 PAWS（0.875 对 0.788）、留出规则结构（1.000 对 0.885）和对比策略（1.000 对 0.963）。在回答不可知问题时，它给出 0.9 及以上概率的频率低于 Jev，为 0.055 对 0.090，这里越低越好。

仓库还提到，同一份检查点在不启用思考时，于 2962 条测试集上得 0.804，启用思考时为 0.840。代价是延迟：单张 H100、fp8 精度下，不思考每次请求约 0.3 秒，思考的中位数为 3.3 秒。在 M4 Pro 上，一个问题思考时大约每秒 20 个 token。权重在 bf16 下占 21 GB，默认缓存再加 28 GB，所以 README 建议 48 GB 的 Mac 使用更小的缓存设置。

表里本身就印了一条说明。Kev-9B 在 JevBench 上没有公布结果，而带星号的两行是跑在 Qwen3 上的 Kev-8B。也就是说，部分对比的对象与列标题所指的并不是同一个模型。

Qevi-2B 把同一招用到图像上

Hugging Face 上的 Qevi-2B 模型卡介绍的是对 Qwen3-VL-2B-Instruct 的全面微调。它回答关于图像的、带类型的封闭问题，“靠读取模型自身的 logits，而不是生成文本”。问一张图里有没有梯子，它返回 P(Yes) = 0.97，而不是一句话。模型卡直言它不是聊天模型，并警告调用 .generate() 再解析文本无法复现公布的数字，因为那不是它微调时走的路径。

读取逻辑大约 30 行普通 transformers 代码，不需要 trust_remote_code。与走完全相同读取路径的基座 Qwen3-VL-2B-Instruct 相比，Qevi-2B 的域内准确率从 0.855 升到 0.977，在 12 个留出域上从 0.745 升到 0.889。留出数据上的期望校准误差从 0.160 降到 0.054。模型卡说，对一张图问很多问题时，速度优势可达约 21 倍，因为块对角注意力掩码让多个问题共用一次图像编码，并且与分别提问的结果做了逐位校验。

模型卡还警告不要用早期版本推荐的温度缩放：T = 2.45 时留出集 ECE 为 0.160，基本等于基座模型的数字，“全部校准收益都被抵消了”。

还有第二条坦白的说明。训练语料只有 noul 和 choice 两类问题。引擎支持 score，基座模型也能零样本处理这类问题，但微调过程中从未见过。所以模型卡写明 score 的准确率和校准未经测量，应视为未经验证。

为什么本地部署这条线反复出现

Sebastian Raschka 在 9 月 29 日写的文本分类史文章在这里很有用，因为它点出了这些模型真正放弃了什么。他指出，最新的 GPT 和开放权重模型能做与 Jev 相同的分类任务，同时通用得多，但 Jev 式模型的优势在速度和成本。另一端，“对于一个狭窄、定义明确的问题，Jev 大概不会比专用分类器分得更准、更快或更便宜”。卖点在中间地带：比专用模型更通用，比前沿模型更便宜。

Raschka 的文章把谱系追溯到词袋表示喂给朴素贝叶斯、逻辑回归、SVM 和 XGBoost 的年代，并提到 Gmail 的垃圾邮件过滤器据称就是一个基于词袋的朴素贝叶斯模型。不同之处在于，如今的分类器是带校准概率头的微调语言模型，可以作为权重发布出去，而不是作为服务调用。

本地部署的论点正是在这里生效。Jeeves 在 CUDA 上以 bf16 或 fp8 运行，也能通过 MPS 跑在 Apple Silicon 上。fp8 版本把权重压到 11.5 GB，并把 M4 Pro 上的思考吞吐从约 20 提高到约 31 个 token 每秒。仓库说开发集问题上准确率和 NLL 没有可测量的变化，并且发布了预量化的 PostHog/jeeves-fp8 仓库，下载体积约为一半。

Qevi-2B 更小，只有 2B 参数，这种体量适合笔记本或手机，而不是机架。Liquid 的文档说模型在一次调用中评估状态和问题，输出 token 为零。正是这一点让每次请求的成本可预测。

测量数据仍然单薄

这些工作都不是没有问题。最接近的最新研究是 Cameron Berg 和 Caspar Kaiser 于 9 月 28 日提交的一篇 arXiv 论文。他们发现，在来自五个家族的七个开放权重模型中，隐藏的效价相关激活模式会可预测地左右后续选择，即便所有可见 token 完全相同。作者写道，这些痕迹是否伴随任何与模型福利相关的主观体验，“仍不清楚”。这提醒人们，读取模型内部状态如今是一种设计模式，而不只是诊断手段。

实际层面的反对意见来自微软 9 月 29 日发布的开发者博客。文章认为公开基准几乎说明不了你自己的负载会怎样。帖子引用古德哈特定律，并指出 SWE-bench 的任务来自公开仓库，因此与训练数据重叠不可避免，而且每代都在增长。帖子说，一个在 SWE-bench 上得 92% 的模型，确实擅长解决热门仓库里记录详尽的问题，但这说明不了你的内部库会怎样。

同样的逻辑适用于决策模型。Jeeves 自己的表显示它在 MMLU 和 MMLU-Pro 上输给 Jev，却在留出规则结构上取胜。这意味着“哪个更好”完全取决于你的工单、图像或文档来自哪个分布。Liquid 对 d1 根本没有公布准确率数字。Qevi-2B 的模型卡把 score 列为未测试。真正存在的数字多半由发布模型的团队自报，用的还是他们自己选的切分。

本周的新东西不是小型分类器的存在。而是三个互不相干的团队把它们发布出来，用的是同一个接口思路：一次前向传播，在固定答案集合上给出校准概率；而且小到不需要数据中心就能跑。这是否足以取代 Jeeves README 描述的那种“前沿模型加兜底”的模式，公开的基准还回答不了。