决策模型走向小型化：Qevi-2B、Liquid d1 与 Jeeves 把分类搬到设备端

模型叫 Qevi-2B，是在 Qwen3-VL-2B-Instruct 上做的完整微调。作者说它“不是聊天模型”：问照片里有没有梯子，它返回 P(Yes) = 0.97，而不是一句话。模型卡给出的域内准确率是 0.977，基座模型为 0.855；留出域为 0.889，基座为 0.745；留出数据上的期望校准误差为 0.054，基座为 0.160。速度上的说法靠问题打包：多个问题共用一次图像编码，用块对角注意力掩码隔开，并与逐个提问的结果做了逐位校验。

这只是这个出现才两周的品类里的一个产物。如今它已经有了 SDK、基准、一个竞争性的基准套件，以及至少一个开源复刻。据 Casco 称，TypeSafe 于 9 月 15 日发布了 Jev。Casco 把该模型走红的时间点定在“四十八小时之内”。

Liquid 给这些基本构件起了名字

Liquid AI 于 9 月 29 日发布了 d1 的文档，称其为自家的第一个决策模型。文档对这些系统的用途说得异常直白：决策模型不是一次生成一个 token，而是评估一个状态，在一次调用中、零生成 token 的情况下，对一组固定结果返回经过校准的概率。

Liquid 定义了三种问题类型，它们已经成为事实上的接口。Noul 是一个是/否问题，返回 0 到 1 之间的概率；文档举的例子是垃圾信息检测返回 0.92。Choice 返回一组命名选项上的分布，比如工单路由返回 {"billing": 0.65, "technical": 0.30, "account": 0.05}。Score 返回在有序评分标准上的概率加权位置，所以“这件事有多紧急？”在三个档位上可能返回 1.85，落在 Medium 与 High 之间。Liquid 的建议是按代码接下来要做什么来选类型：要按类别分支就用 Choice；要与阈值比较就用 Score；要用布尔值做门控就用 Noul。

公司还提醒不要混淆一种常见误解。按文档的说法，Noul 取 0.5 意味着在是与否之间不确定性最大，“与程度或强度无关”。要衡量程度，就得用带明确档位的 Score。

Jeeves：上面加推理，外加 3.3 秒的账单

对这个品类最有趣的质疑来自 PostHog。它于 9 月 29 日发布了 Jeeves：一个 9B 的类 Jev 模型，基于 Qwen3.5-9B，带 LoRA 和一个指针头，用 SFT 和 CISPO 训练，先推理再决策。仓库对自己要纠正的取舍毫不含糊。README 写道：“类 Jev 模型给出经过校准的决策概率，但准确率低”，这也是许多流水线已经退回到推理模型的原因。

Jeeves 在一个含 2962 条、既留出又跨域的测试集上报告 0.889，Jev 为 0.857，Kev-9B 为 0.822，但附带说明 Kev 和 Jev 两列的数字是 Kev 自己公布的。在 JevBench 的 231 条公开题目上，它号称 0.935，Jev 为 0.866；在 111 条的困难档上，0.865 对 0.730。它在 JevBench 公开题目上的校准误差为 0.037。同一个检查点不开启思考得 0.804，开启后得 0.840。

然后是成本。PostHog 测得每请求不思考约 0.3 秒，思考后中位数 3.3 秒，环境是一块 H100、FP8 精度，并指出截断思维链可以缩短这个时间。推理也能在 48GB 及以上的 Apple Silicon 上运行。如果小型决策模型的意义就是把工作留在本地，这一点很重要。

Jeeves 表格里的基座模型数字并非都可比：仓库给它的 Kev-9B JevBench 数字打了星号，说明 Kev-9B 的 JevBench 结果没有公布，表中显示的是 Qwen3 上的 Kev-8B。

到底谁在为分类器付钱

最清楚的生产环境论据来自 Evan Schwartz，他运营个性化内容流 Scour。在 9 月 29 日的一篇文章里，他描述了自己每月对约 110 万份文档提出 54 个问题：50 个 Noul、3 个 Choice 和 1 个 Score，约 2150 个 token，其中约 260 个 token 是固定开销。他的问题现在占输入 token 的约 88%，每次请求都原样发送。他的总支出每月不到 150 美元。他说，把同样的内容跑一遍哪怕最便宜的 LLM，对一个靠自筹的项目来说也贵得难以承受。

他的诉求很具体：提示缓存，或者能够注册可复用的问题集。

他说自己不会把多条帖子打包进一次请求，因为文档警告状态里混入无关内容会降低准确率。他建议提供一种接收多个问题和多份输入的 API，作为避开打包损失的替代方案。别人已经在填补 TypeSafe 周围的空白。一个名为 Jeb 的 GitHub 项目于 9 月 29 日更新，它通过读取 token 的 logprobs，把任何兼容 OpenAI 的端点变成决策模型，在 POST /v1/systemone 返回结构化 JSON，CLI 上用同样的请求格式。它的 README 坦率说明了前提：一个端点可以在普通聊天上兼容 OpenAI，却缺少 Jeb 需要的对数概率，所以选服务商之前要先确认这项能力。

基准问题来得很早

安全公司 Casco 把 2449 条发现送进八个模型，包括 Jev、Claude 和 GPT，把它们给出的 CVSS 3.1 严重度评分与自家公布的参照对比。所有模型平均都高估了。Jev 给一个只含 55 条公开严重发现的 2449 条数据集打了 550 个严重，其中 500 个在 Casco 的参照里低于严重。GPT-6 Astra 总体最准，平均绝对误差 1.92 分；Jev 以 3.40 排第七，好于 Haiku 的 3.94。

带符号的误差都指向同一个方向：在十分制上，Jev +3.30 分，Haiku +3.89，Astra +1.18。Casco 的说法是，结构化且经过校准的输出并没有让严重度判断相对其参照更准确，由此产生的“安全垃圾”要工程师花时间清理。研究对每个模型都用了同一份发现证据，没有给 Casco 的评分策略或内部应用上下文，所以它衡量的是判断本身，而不是算术。

还有一个没人回答的维护问题。Jeeves 是在 Qwen3.5-9B 上的微调，带一个扩散草稿器和一个兼容 Jev 的 API；Qevi-2B 是 Qwen3-VL-2B 的微调。两者都依赖日后会被取代的基座模型。这个品类的卖点是你可以不重新训练就加问题。这话对 API 表面成立，对权重并不成立。

9 月 29 日，Sebastian Raschka 发表了一篇很长的文本分类技术史，从词袋讲到 RNN、CNN 和 transformer，再讲到他称为类 Jev API 的东西，明确是为了“给炒作祛魅”。他的结论最不刺激，大概也最有用：对一个狭窄而定义明确的问题，Jev 式模型在准确率、速度或成本上都不会胜过专用分类器。它的卖点是在分类这个位置上具备通用性，而这比外界的反应所暗示的要小得多。