为了处理 Agent 运行过程中最琐碎的路由分流和工具选择,业界习惯性挂载一个 4B 甚至 8B 的生成式大模型,忍受着逐字吐词的延迟和格式偶尔崩溃的风险。Fastino Labs 在 2026 年 9 月 24 日推出了开源决策模型 GLiNER2.5-Decide,试图打破这种大马拉小车的惯性。这个基于 Apache 2.0 协议开放的判别式模型只有 340M 参数,官方宣称它不仅能在 CPU 上顺畅跑起来,而且在自建基准上的准确率直接压过了 4B 级别的生成式架构。

参数量缩减一个数量级,还能在通用决策上实现反超,听起来像是一次专精架构对大模型的降维打击。但在兴奋之前,有必要把它的评测机制、硬件成本和决策逻辑拆开细看。

全匹配度量的偏向与算分落差

GLiNER2.5-Decide 的底座并非生成式 Decoder,而是基于 DeBERTa-v3-large 编码器、由 gliner2-large-v1 微调而来的纯分类器。它不生成任何新词,不需要配置冗长的提示词模板,只在调用时接收预设的 Schema 字段与文本,通过单次前向传播给所有合法选项打分,再由约束解码模块直接挑选最优组合。

全匹配规则容不下丝毫冗余,多输出一个字符便直接判为零分(示意图)
全匹配规则容不下丝毫冗余,多输出一个字符便直接判为零分(示意图)

Fastino 给出的 Fast Decisions 评测集包含 17 个垂直分类领域,每个领域配置 300 个隐藏测试样本,总计 5,100 个样本。在这个基准上,GLiNER2.5-Decide 拿到了 60.1% 的完全匹配准确率,领先于基于 Qwen3.5-4B 的 JevK5(57.5%)以及 SemIf(56.4%)。不过官方发布渠道里出现了一处微小的数据出入:官方博客公布的成绩是 60.1% 对 57.5%,而在 Hugging Face 对应的数据集卡片上,两者的数字分别记录为 60.2% 与 57.6%。同系列中基于 Ettin 1B 编码器的 1B 版本得分为 59.6%,甚至略低于 340M 版本;而 287M 的多语言版本 GLiNER2.5-multi-Decide 则录得 56.7%。

评测机制对照:全匹配规则下的架构博弈 生成式 Decoder(如 4B 模型) • 依赖自回归逐字生成结构化 JSON • 单一标点或键名微调即导致全匹配失败 • JevBench 公开测试中标准层达 95.8% Fast Decisions 表现:57.5% 受制于格式严苛惩罚,能力被低估 GLiNER2.5-Decide(340M 编码器) • 纯判别式前向计算,天然契合固定集合 • 约束求解器直接输出合规标签组合 • 免除 Prompt 模板拼接与 Token 解析 Fast Decisions 表现:60.1% 规则量身定做,占尽零容忍度量便宜

这种反超带有鲜明的规则红利。Fast Decisions 采用零宽容度的完全匹配机制,多标签预测必须与标准答案集合丝毫不差,只要多标或漏标一个标签,哪怕语义完全吻合也按零分计算。对于依靠生成式逐字预测的 Decoder 而言,只要输出稍有冗余或格式波动就会全盘尽失;而在自有基准 JevBench 上,JevK5 的标准层得分实际上高达 95.8%。GLiNER2.5-Decide 的胜出,很大程度上是因为它用硬编码的判别式接口,规避掉了大模型在生成格式上的不必要损耗。

48核服务器撑起的低延迟表象

摆脱对高功耗 GPU 的依赖,是此类轻量级模型最常打出的一张牌。但所谓支持 CPU 部署,在工业现实里往往有着完全不同的语境。

测试依赖四十八核旗舰处理器,单流每秒仅能完成六次决策分流
测试依赖四十八核旗舰处理器,单流每秒仅能完成六次决策分流

模型权重文件大小约为 1.95 GB。Fastino 公布的基准数据表明,在输入 64 个 Token、批处理量为 1 的条件下,系统在 Intel Xeon Platinum 8581C 上的 p50 延迟为 167.3 ms。

实测硬件与性能指标分解 1.95 GB 模型权重大小 支持标准管道安装 48 vCPU 测试基准硬件规格 Intel Xeon 8581C 167.3 ms 批次1 p50 延迟 64 Token 短文本输入 ~6 QPS 单流理论吞吐上限 难以承载边缘高并发

这台用于测试的 Intel Xeon 是拥有 48 个虚拟核心的企业级旗舰处理器。换句话说,单次处理消耗了整台高配计算节点的算力,单流状态下的处理能力大约只有每秒 6 次决策。如果将它放到中小团队常见的 4 核或 8 核云服务器容器中,或者部署在缺乏高规格矢量加速的边缘端,处理时间很可能直接跳跃到数百毫秒甚至秒级。相比之下,英伟达 V100 显卡处理同样任务耗时为 38.3 ms,T4 为 43.6 ms。短文本在不同 GPU 之间的耗时差异在 9 ms 以内,算力瓶颈主要在固定的前后处理和算子启动上。如果团队缺乏重型服务器,盲目听信能在 CPU 跑就贸然把路由任务撤下显卡,大概率会迎来严重的队列堆积。


规则约束并不能消解置信度盲区

GLiNER2.5-Decide 的核心卖点在于联合解码。举例来说,当模型单独判定输入文本时,可能会对提示词注入给出 0.82 的危险打分,却又同时打出 0.52 的安全分。为了解决这种打架现象,模型引入了解码约束规则:只要识别出有害特征,就强制输出不安全。

模型同时给出危险与安全分,底层死锁时依靠放宽规则勉强妥协(示意图)
模型同时给出危险与安全分,底层死锁时依靠放宽规则勉强妥协(示意图)
用外挂规则抹平逻辑冲突,掩盖不了模型底层判断的犹豫。

在开源代码库中,这套约束解码引擎提供了三种模式:independent、exact 以及 beam。但极其关键的一点是,当规则组合出现死锁时,系统默认的处理策略是 on_infeasible='relax',也就是在无解时自动放宽约束并返回一个妥协结果。

更深层的隐患出在置信度本身。Fastino 官方发布的集成文档 SKILL.md 中有明确提示:模型输出的置信度并没有经过标准化校准。它既不能在不同的分类任务之间直接横向比较,更不代表现实世界中发生该判断的真实概率。把一个未校准的分数配合一个遇到死锁就自动放宽约束的规则引擎,直接用作防御提示词注入的安全护栏,等于把系统的安防底线建立在沙滩上。面对稍微复杂的编码混淆、多语言变异或上下文污染,语义层面的分类器极易失手。

  • 提醒.判别式小模型非常适合承接固定意图分流与确定性工具匹配这类脏活,但绝对不可直接替代动态鉴权与生产级注入防护体系。

古人讲善除害者察其本。在 Agent 架构的演进里,将路由与初筛任务从小参数模型中剥离出来,是控制成本与确定性的务实选择。但若把度量偏向当成真实超越,甚至寄望于未校准的分类规则去把守安全边界,到头来支付的系统返工代价,恐怕远比省下的几张显卡要昂贵得多。