科技媒体 MarkTechPost 近日报道,Nace AI 宣布开源一款专为离散决策设计的 9B 参数模型 Drex 1.5。与当前主流语言模型不同,这款模型彻底阉割了文本自回归生成能力,不输出对话,也不输出思维链,只负责在给定选项中计算离散选择、是非判断或序数分数的概率。

将大模型改造为纯粹的判别器,切中了当下自动化工作流对高延迟与格式幻觉的痛点。然而撕开开源与榜首的包装,Drex 1.5 更像是一次技术妥协与商业防守的混合体:其领先微弱且严重偏科,而严苛的商用门槛,已将大部分成熟技术团队挡在了免费试用的大门之外。

放弃逐字生成:指针头架构换取的延迟红利

在智能体协作与工作流调度中,工程师常常陷入两难:让传统自回归大模型做分类,长上下文下的逐 token 输出不仅推高了延迟,还经常跳出约束集合产生格式幻觉;而强化学习中常用的奖励模型,又只能对文本对打标量分数,难以直接处理多项选择。

模型切断了逐字生成机制,仅靠外挂指针头完成离散打分(剖面示意)
模型切断了逐字生成机制,仅靠外挂指针头完成离散打分(剖面示意)

Drex 1.5 选择了一条彻底工具化的路线。该模型实际参数量约为 8.95B,基于 XiaomiMiMo/MiMo-V2.6-Distill-Qwen-9B 开发,底层骨干网沿用 Qwen3_5ForCausalLM 的 32 层结构,其中每层全注意力对应 3 层线性注意力。不同之处在于,模型在输出端外挂了一个独立的 head.pt 指针头,把原本预测下一个词的逻辑,改造成只对单选题、是非题和序数打分做单次前向概率推断。

工作机制对比:生成式 LLM 与 Drex 1.5 决策路径 传统生成模型(自回归) 输入上下文与候选集合 逐 Token 自回归解码生成 输出:非受控长文本 / 易幻觉 延迟高,需正则解析,存在格式崩坏 Drex 1.5 决策模式(指针判别) 输入长文本(最高 131K 配置) 单次前向传播 + head.pt 指针 输出:离散概率分布(Choice/Score) 零文本输出,中位延迟 0.65-2.0 秒

这种特化结构的直接回报是长文本下的执行速度。该模型默认上下文为 16,384 tokens,最高可拓展至 131,072 tokens。在长文本基准测试中,8K–32K 区间准确率为 89.5%,中位延迟压到了 0.65 秒;而在 32K–128K 超长区间,准确率维持在 93.4%,中位延迟也仅为 2.0 秒。对于必须频繁翻阅大段日志或调用工具上下文的执行流来说,这种响应速度确实具备吸引力。

跑分水分与偏科:0.9 分误差带内的虚假领先

然而,Nace AI 标榜的性能榜首难以经受推敲。官方宣布 Drex 1.5 在公开基准 Decision Index 0.3.1 中斩获 58.08 分,位居第一。但只要拉平数据就会发现,这个分数与第二名 Jev 1.13.0(57.96 分)以及 Bespoke Nimble 9B v3(57.19 分)相差不到 0.9 分,完全落在此类离散基准测试的容差并列带内。

榜首分差仅有零点一二,完全落在仪器公差带内
榜首分差仅有零点一二,完全落在仪器公差带内
所谓领先只是小数点后两位的微调,并未形成能力代差。

更重要的是评测环境的规范性。这套 58.08 分的战绩完全由 Nace 自行运行评测脚本得出,至今缺乏独立第三方复现。在训练数据方面,官方不仅未公布数据集配比、优化器超参、训练步数和算力消耗,其训练集更直接包含了测试基准的官方训练切分。甚至在其产品官网上,2026 年 9 月 28 日旧版 Decision Index 0.2.1 的跑分(58.28 对 Jev 的 57.91)依然与 0.3.1 版本数据并行展示,暴露出版本评估标准的摇摆。

Drex 1.5 关键基准测试得分与分项断层 工具调用 (Tools) 75.0 综合分 (Drex 1.5) 58.08 基准第二名 (Jev) 57.96 知识推理 (Reasoning) 44.6 注:Decision Index 0.3.1 官方自测数据;综合分处于 0.9 分并列带内,知识推理出现断崖式偏科

细看分项数据,Drex 1.5 表现出极端的偏科特征。其工具调用能力拿到 75.0 分,但在知识与推理项上,得分断崖式滑落至 44.6 分。这意味着它虽然消除了格式脱轨的风险,但在面对复杂因果链条时,仍会在固定选项里挑选错误答案。模型直接给出的概率输出并不等于严密校准后的置信度,更不是强化学习里的期望效用。

伪开源与生态绑架:企业落地的隐形栅栏

除性能局限外,Drex 1.5 最受争议之处在于其许可证结构。项目名义上打着开源旗号,但只有运行时代码遵循宽松的 Apache-2.0 协议,核心模型权重采用的是定制版 Nace.AI Open RAIL-M License(2026 年 10 月 v1.0)。

私有分支线缆锁死机柜,主流开源运行环境被空置
私有分支线缆锁死机柜,主流开源运行环境被空置

这份协议为商用划定了极其严苛的红线:任何在过去 12 个月内总营收超过 100 万美元,或累计融资超过 100 万美元 的实体,若要将模型用于商业目的,必须向 Nace 签署独立书面许可;与此同时,协议明确禁止竞争对手使用。按照开源倡导组织(OSI)的标准,这属于典型的受限权重共享,而非真正意义上的开源。

在工程部署层面,该模型并未并入主流通用的运行环境。开发者若想在本地拉起服务,无法直接调用官方主干版本的 llama.cpp 或 Ollama,而必须使用 Nace 自行维护的代码分支。

  • 风险.中大型团队若将业务调度绑定在私有推理分支上,不仅要承担维护断代的工程包袱,还会在跨过双百万财务红线后陷入被动的商务议价。

对于正在构建自动化流的团队来说,Drex 1.5 验证了剥离生成、专注判别的低延迟可行性,但它绝非即插即用的生产级利器。相比于承担私有分支与严苛授权的代价,采用成熟的开源轻量基座,辅以 Outlines 或 JSON 约束解码等成熟方案,依然是当下兼顾合规安全与工程稳定性的更优解。