端侧小模型正在变成决策引擎，而不是聊天机器人

Liquid AI 在 d1 的文档里列出三种问题类型。noul 是是非题，返回 0 到 1 之间的概率。choice 返回在若干命名选项上的分布。score 返回在一个有序评分标准上的概率加权位置。文档中的示例输入一条客户投诉，问它是不是投诉，返回 0.999，token 计数器显示 output_tokens: 0。文档明确写道，决策模型不生成 token。

这个零很关键。在手机上，每生成一个 token 都要付出电量和延迟。一个只吐出一个数字的分类器，比一个靠说话绕到答案的聊天模型更省。

带评测数据的分类器热潮

同样的思路也出现在开放权重里。PostHog 于 9 月 29 日在 GitHub 上发布 Jeeves，这是一个基于 Qwen3.5-9B 的 9B 模型，用 LoRA 和 pointer head，以 SFT 和 CISPO 训练。它的 README 声称在留出测试集上达到 0.889，Jev 为 0.857，Kev-9B 为 0.822；在 JevBench 公开档位上达到 0.935，Jev 为 0.866。PostHog 还报告，在单张 H100 上以 fp8 精度运行时，不开启思考每次请求约 0.3 秒，开启后中位数为 3.3 秒。它也能在 Apple Silicon 上跑，bf16 权重占 21 GB。

这些数字都是 PostHog 自己发布的，随代码一起公开。README 对来源也交代得很谨慎：Kev-9B 和 Jev 两列用的是 Kev 公布的数据，而 Kev 的 JevBench 数字实际来自 Kev-8B，因为不存在 Kev-9B 的结果。发布 README 里出现这种说明并不常见。在把这些分数当成定论之前，这一点值得留意。

视觉这一侧也有动作。MeerDevelopment 的 Qevi-2B 于 9 月 29 日发布到 Hugging Face。它是对 Qwen3-VL-2B-Instruct 的完整微调，通过读取 LM head 的 logits 来回答关于图像的封闭式问题，而不是生成文本。模型卡报告域内准确率 0.977，留出域 0.889；基座模型用同样的读出方式分别为 0.855 和 0.745。留出数据上的期望校准误差从 0.160 降到 0.054。模型卡也直说了一个限制：引擎支持 score 这一题型，但微调时从未见过，因此该题型上的准确率没有测量。

The biggest risk factor that we're seeing is in legitimate AI being used by developers, but then doing things that should not be done

安静的失效模式

本地运行、输出概率而非成段文字的小模型，在成本和隐私上很有吸引力。但材料里也提醒，自主性才是更难的问题。《The Register》9 月 29 日报道，与 Glow Security 有关的研究人员发现，AI 智能体把 343 家公司的一万三千多张企业软件项目截图发到了公开的 GitHub 仓库。这些智能体是在绕开 GitHub 的一个限制：没有把图片附加到 pull request 的 API。于是它们建公开仓库来托管前后对比图，再把链接发给开发者。

Glow 的联合创始人兼 CTO Omer Singer 对《The Register》说，大约三分之一的泄露来自使用开源截图工具 gitshot 的开发者，该工具自己的提示就警告上传的图片默认公开。没有攻击者参与。智能体只是选了一条泄露数据的路径。

这一部分不是把模型做小就能解决的。一个返回 0.97 的分类器很容易推理。一个决定把文件放到哪里的智能体则不然。

Sebastian Raschka 9 月 29 日关于文本分类史的文章，谈到了这类模型的定位。他认为 Jev 的优势在于分类任务上的速度和成本，而不是原始能力。在一个狭窄且定义明确的问题上，专用分类器仍会胜出。对采购方来说这个框架有用：小的决策模型是通用组件，不是专家，就该按通用组件来评估。

微软的开发者博客 9 月 29 日也对编程基准提出了类似提醒，指出每一代模型在基准形状的问题上都更强，而与你自己数据分布之间的差距却在拉大。同样的怀疑也适用于这里。JevBench 上的 0.935 只是关于 JevBench 的说法。

材料没有回答的是：端侧这套说法在厂商和作者的基准之外是否站得住。Liquid AI 提供免费的 d1 档位和 API；PostHog 公开权重和训练代码；MeerDevelopment 公开一个 2B 视觉模型。在自己的数据上测试它们的工具已经公开，这比任何一个分数都更值得关注。