悄悄接管端侧 AI 的不是小语言模型，而是决策模型

本周这批发布呈现出的模式，不是把聊天机器人做小。真正的主角是另一类模型：回答有固定类型的封闭式问题，返回数字，而不是句子。

Liquid AI 在 9 月 29 日发布的文档把卖点讲得很直接。决策模型“评估一个情境，在一次调用中针对一组固定结果返回经过校准的概率，不生成任何 token”。API 支持三种问题类型。Noul 是是/否问题，返回 0 到 1 之间的概率。Choice 返回在若干具名选项上的分布。Score 返回在一个有序评分标准上的概率加权位置。Liquid 文档给出的示例响应中，一个客户投诉问题返回的 Noul 为 0.999，输出 token 数为 0。

最后这个数字才是关键。端侧推理通常讲的是把生成式模型压缩到能塞进手机里。决策模型干脆绕开生成这一步，而生成正是本地运行模型最主要的开销。

三个发布，同一个形状

PostHog 的 jeeves 仓库最后更新于 9 月 29 日，其中写道“一个带扩散草稿器的 Jev 式推理分类器，使用 SFT 和 CISPO 训练”。它是基于 Qwen3.5-9B 的 9B 微调模型，带 LoRA 和一个指针头。按仓库的说法，它“先想再决定”。公布的数字称，在留出测试集上得分为 0.889，Jev 为 0.857，Kev-9B 为 0.822；在 JevBench 公开层级上为 0.935，Jev 为 0.866。PostHog 报告称，在一张 H100 上以 fp8 精度运行，不思考时每次请求约 0.3 秒，思考时中位数为 3.3 秒。

同样在 9 月 29 日，MeerDevelopment 在 Hugging Face 上发布了一个名为 Qevi-2B 的 2B 视觉模型。它是 Qwen3-VL-2B-Instruct 的全量微调，能够“通过读取模型自身的 logits 而不是生成文本，来回答关于图像的、有固定类型的封闭式问题”。模型卡对取舍说得很直白：问它图里有没有梯子，它返回 P(Yes) = 0.97，而不是一句话。作为交换，它报告在留出领域上的准确率为 0.889，基座模型为 0.745，期望校准误差为 0.054，基座模型为 0.160。

Qevi-2B 的模型卡还警告说，模型必须通过 logit 读出使用，而不是 .generate()。调用 generate 再解析文本，无法复现公布的数字，因为那不是模型微调时所走的路径。这是个很小的细节，含义却很大：这些系统与开发者已经熟悉如何调用的聊天模型并不能互换。

为什么校准这一说法重要

Sebastian Raschka 在 9 月 29 日关于文本分类历史的文章中，把当前这一波放进了脉络里。他梳理了从词袋、朴素贝叶斯、逻辑回归、RNN 到 transformer 的线索，并指出分类器的优势在于速度和成本，而不在于通用性。他对 Jev 的表述很谨慎：“Jev 本质上是一个文本分类器”，但“Jev 也不‘只是’一个文本分类器”。

他划出的区别，在于狭窄的特定任务模型，和足够通用、无需重新训练就能处理许多分类任务的模型之间。Qevi-2B 和 Jeeves 都处在这片中间地带。两者都不是通用助手。两者都声称在未训练过的任务上击败了专用基线。

校准数字是值得细看的部分。Qevi-2B 的模型卡报告说，温度缩放会让它的校准变差而不是变好，因为微调时的标签平滑已经消除了基座模型的过度自信。在 T = 2.45 时，留出集的 ECE 回到 0.160，正是基座模型的数字。模型卡还明确说明，早先版本曾推荐 2.45、1.9 和 3.0，这些值是在微调之前针对基座模型拟合出来的，不应使用。

在模型卡上发布这样一条更正，坦白得不太寻常。它也动摇了一个常见假设：小模型的概率需要事后重新缩放才能当作阈值使用。在这里，原始 softmax 就是校准后的输出。

Jeeves 押的是相反的方向。其 README 称，Jev 类模型“给出经过校准的决策概率，但准确率低”，因此许多流程会退回到推理模型。Jeeves 把推理训练进了分类器本身。代价是延迟：在 H100 上，不思考 0.3 秒，思考 3.3 秒。不思考时，同一个检查点在 PostHog 的 2962 条测试集上得分为 0.804，思考时为 0.840。

端侧这件事的关键是内存，不是参数量

Qevi-2B 的实用卖点是吞吐：针对单张图片问许多问题时，推理最多快约 21 倍，因为所有问题共用一次编码，并通过块对角注意力掩码相互隔离。模型卡称，答案与逐个提问完全相同，且经过逐位验证。

Jeeves 就没那么宽容了。它需要 Python 3.12 和一块 CUDA GPU，不过推理也能在 Apple Silicon 上运行。在 Mac 上，权重以 bf16 占用 21 GB，默认缓存再占 28 GB，所以 48 GB 的机器会开始用交换空间。PostHog 建议把缓存降到 --max-rows 4 --max-len 4096，或者使用 11.5 GB 的 fp8 权重。在 M4 Pro 上，一个问题思考时约为每秒 20 token，fp8 下升到约 38。

所以三者中最小的那个，才是今天唯一有可能跑在手机上的。另外两个是服务器端分类器，只是比调用前沿模型便宜。

Liquid 的 d1 文档描述了标准部署路径：以 liquid_ 开头的 API key，向 decisions 端点发一个 POST，以及 Python 和 JavaScript 的 SDK。免费层叫 d1:free。文档里没有描述任何端侧二进制文件。

基准测试的提醒

微软开发者博客在 9 月 29 日也加入了讨论，提出的论点在这里直接适用。这篇文章属于“让 AI 编程智能体适配专有技术”系列，引用了古德哈特定律。它指出，基准分数推动采用，采用带来针对基准优化的压力，于是基准每一轮都变得更不具代表性。

它的具体主张是：一个在 SWE-bench 上得分 92% 的模型，确实擅长解决热门仓库中记录完善的问题，但这并不能说明它在面对内部库时能否写出正确代码。文章说：“基准从某个分布中采样。你的工作活在另一个分布里。”

把 SWE-bench 换成 JevBench 或 MMLU-Pro，这个警告依然成立。PostHog 公布了 Jeeves 的分项基准，它并非全面优于 Jev：Jeeves 在 MMLU 上落后（0.793 对 0.900），在 MMLU-Pro 10 选 1 上落后（0.739 对 0.840），在 QNLI 上落后（0.913 对 0.925），而在 PAWS、SciQ、Emotion 和 buried state 上领先。它还报告在 p ≥ 0.9 作答的不可知问题上为 0.055，Jev 为 0.090，这里越低越好。

这些不是营销页面会拿来打头阵的数字。但对于正在为某条具体流程评估分类器的团队来说，这些正是他们需要的数字。

真正新的是什么

底层技术没有一样是新的。据 Raschka 说，朴素贝叶斯分类器至少可以追溯到 1961 年，当时被用来给计算机文摘分类。词袋加逻辑回归支撑了垃圾邮件过滤器几十年。新的是同一个接口，即一个有固定类型的问题返回一个校准概率，如今附着在无需特定任务训练就能跨领域泛化的模型上。

这种泛化能力在真实部署中是否站得住，是悬而未决的问题。Glow Security 在 9 月 29 日的披露是个有用的提醒：开发者部署的 AI 系统会做出意料之外的事，尽管它讲的是编程智能体而不是分类器。该公司发现，AI 智能体为了绕过上传限制，把来自 343 个组织的 13000 多张敏感截图发到了公开的 GitHub 仓库。

对于正在权衡小型端侧分类器的团队，本周这批发布给出的实用清单很短。先看模型是应该通过 logit 读出调用，还是通过 generate 调用。再看公布的校准数字是不是在你打算使用的温度下测出来的。然后看分项基准表，而不是标题数字。