Nace.AI 开源 Drex 1.5：9B 决策模型不写文本，只给选项打分
来源MarkTechPost查看原文
速览
- Drex 1.5 是 9B 开源决策模型，一次前向传播即对给定选项输出概率，不采样 token。
- Decision Index 0.3.1 得分 58.08，与闭源 Jev 1.13.0 处于并列区间。
- 长文档准确率最高 93.4%（32K–128K tokens），截断到 8K 后明显下降。
- 单张 24 GB A10G 可跑 bf16，Q8_0 GGUF 约 9.5 GB 可跑 Mac 与 CPU。
- API 格式与 TypeSafe 的 Jev 一致，现有 Jev 客户端改几个环境变量即可迁移。
- 短板集中在知识类任务与细粒度情感分析，GPQA Diamond 仅 45.4%。
- 模型在 index benchmark 的官方训练集上训练，仅用留出集评估。
- 提供 Drex agent skill，可接入 Claude Code、Codex、Cursor 等编码工具。
- 许可证为 RAIL-M，含使用限制，商用前需核对条款。
Nace.AI 开源了 Drex 1.5，一个面向 Agent 和后端工作流的 9B 决策模型。它不生成文本，而是读取一个 state（文本或 JSON）和若干带类型的问题，对每个候选选项输出概率。模型在公开的 Decision Index 0.3.1 上得分 58.08，是 10B 参数以下最高分，与闭源的 Jev 1.13.0（57.96）落在榜单 0.9 分的并列区间内。权重已发布在 Hugging Face，托管版本上线 OpenRouter，输入定价 $0.04 / 1M tokens、输出 $0。模型采用 MiMo-V2.6-Distill-Qwen-9B 作为骨干，bf16 权重约 18 GB，可在单张 24 GB A10G 上运行，Q8_0 GGUF 约 9.5 GB 可跑在 Apple silicon 和 CPU 上。长文档是明显强项：32K 到 128K tokens 区间准确率 93.4%，中位耗时 2.0 秒；但知识类与细粒度情感分析是短板，GPQA Diamond 仅 45.4%（Jev 为 78.6%），ACOS 方面情感逐条 F1 仅 7.4%（Jev 为 29.5%）。
关键事实
- Drex 1.5 参数量 8.95B（dense），bf16 权重约 18 GB，默认上下文 16,384 tokens，最高可扩展到 131,072。
- 在公开 Decision Index 0.3.1（37 个 benchmark，chance-corrected）上得分 58.08，Jev 1.13.0 为 57.96，Bespoke Nimble 9B v3 为 57.19，Cloudflare clef-flash 为 56.15。
- Drex 1.5、Jev 与 Nimble 均落在榜单 0.9 分的并列区间内；Drex 在 37 个 benchmark 中的 20 个上领先 Jev。
- 在 JevBench（231 个公开条目）上 Drex 得分 86.2%，Jev 为 87.0%，两者在 hard 条目上均为 73.9%。
- 在 8 款 OpenSpiel 游戏的对战中，Drex 对 Jev 取得 122 胜 47 平 87 负（56.8%）。
- 长文档表现：8K–32K tokens 准确率 89.5%、中位 0.65 秒；32K–128K tokens 准确率 93.4%、中位 2.0 秒；截断到前 8K tokens 后准确率降至 76.5% 和 78%。
本站视角
对国内做 Agent 与后端自动化的团队来说，Drex 1.5 的价值不在于分数本身，而在于它把「决策」变成了一个可以本地部署、成本极低的独立组件。此前要用 Jev 这类决策模型只能走闭源 API，数据必须出域；现在 9.5 GB 的 Q8_0 GGUF 就能在 Mac 或 CPU 上跑，且 Nace 实测 bf16 与 Q8_0 在 A10G 和 Apple M5 Pro 上给出完全一致的答案——这意味着量化没有牺牲决策一致性，对数据敏感、需要私有化部署的场景是实质性的门槛下降。$0.04/1M 输入、$0 输出的定价也远低于用通用 LLM 做分类或打分的成本。 但需要保持清醒的是，58.08 与 57.96 的差距落在榜单 0.9 分的并列区间内，把它宣传成「超越 Jev」并不成立，更准确的说法是「在同等水平上提供了开源选项」。而且这个分数来自 Nace 自己跑官方评测工具的结果，Jev 和 Nimble 的分数则引自公开榜单，评测执行方不一致，横向比较的严谨性打了折扣。Nace 的发布图表还使用了更旧的 Decision Index 0.2.1（Drex 58.28 对 Jev 57.91），这种挑选版本的做法值得留意。 更关键的是训练数据问题：模型卡明确写了训练使用 index benchmark 的官方训练集划分。虽然只在留出集上评估，但这意味着 Drex 1.5 在评测覆盖的决策类型上天然占优，换到评测未覆盖的新业务领域，实际表现可能明显低于榜单数字。同时它在 GPQA Diamond 和 MMLU-Pro 上的大幅落后说明它不具备通用推理能力，不能当作 LLM 的替代品，只能作为决策层与 LLM 组合使用。 我们的判断是：值得跟进，但定位要准确。适合的团队是那些有明确枚举选项、需要可审计概率输出、且对数据出域敏感的场景，比如工单路由、审批分级、风控打标。不适合指望它做知识问答或开放生成的团队。另外两点需要观察：一是本地部署必须用 Nace 分叉的 llama.cpp 和 Ollama，主线版本不支持，长期维护能否跟上上游是未知数；二是 RAIL-M 许可证带使用限制，商用前必须逐条核对，不能默认等同于 Apache 或 MIT。
背景与影响
决策模型是一个相对新的品类，TypeSafe 的 Jev 是这一方向的先行者，其 POST /v1/systemone 请求格式事实上成了接口约定。Drex 1.5 直接复用这一格式，意味着 Nace 的策略不是另立标准，而是以「同接口、开放权重、更低部署门槛」切入已有生态。从技术路线看，Drex 1.5 把「决策」从生成式模型中剥离出来：骨干只负责编码 state 与问题，pointer head 负责对用户给定的选项打分，因此 temperature、top_p 这类采样参数完全不适用，模型也无法给出选项之外的答案。这种设计对需要可审计、可枚举结果的后端工作流（如工单路由、发票审批、风控分级）有天然适配性。值得注意的是，Nace 在模型卡中说明训练使用了 index benchmark 的官方训练集划分，只在留出集上评估——这解释了它在 Tools 等熟悉决策类型上的高分，也意味着在新领域的泛化能力仍需第三方验证。此外，Drex 1.5 在知识类任务上的大幅落后（GPQA Diamond 45.4% 对 Jev 78.6%）说明它并非通用模型的替代品，而是需要与 LLM 配合使用的决策层。本地部署依赖 Nace 分叉的 llama.cpp 与 Ollama，而非主线版本，这会给运维带来额外的跟进成本。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。
