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

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 家公司的 13000 多张企业软件项目截图发布到了公开的 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 视觉模型。在自有数据上测试它们的工具现已公开，这比任何单一分数都更值得关注。