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/s。仓库称开发集问题上准确率和 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 描述的“前沿模型加兜底”模式，公开基准尚无法回答。