为 Laya 与 Nimble 对比生成的标题卡,带有本文自身的副标题,以及一行页脚,说明哪一方的数据由厂商提供、哪一方的数据来自第三方。
Engineering & Research

Laya 对比 Nimble:对比数据与更快的编码器

作者

Gideon Frost

发布日期

最新模型 · 20查看全部模型
基准测试:Artificial Analysis · 每日更新
返回全部文章

Laya 和 Nimble 是两个开放权重决策模型,其作者在解释模型如何构建方面做得最多,而他们的解释在难点究竟位于何处这一问题上存在分歧。Convai Innovations 于 2026 年 9 月 18 日以 Apache 2.0 许可发布 Laya——一个 421M 的 ModernBERT-large 英文检查点、一个覆盖 100 多种语言的 322M mmBERT-base 多语言检查点、二者之间一个亚毫秒级路由器,以及公布的 Tesla T4 上每次决策 32.8ms 的 p50 延迟。Bespoke Labs 将 Nimble 打造为基于 Qwen3.5-9B 的 LoRA 微调模型,采用 Apache 2.0 许可,并将其描述为“开源版 Jev”——受 TypeSafe AI 的 Jev 启发,但既未使用其权重、其架构,也不是其输出的蒸馏。Convai 对准确率问题的答案是速度和一个可微调的基础模型。Bespoke 的答案则是训练数据。这一差异比头条表格中出现的三个百分点的准确率差距更值得关注。

每个项目实际上正在提出的主张

Laya 的主张是架构层面的。严格来说,它是非自回归的——一个双向编码器,没有解码循环,没有需要解析的 JSON,也没有任何可以在声明类型之外输出文本的空间。这种结构性保证与 Jev 所提供的如出一辙,只是从不同的方向达成;对于任何曾围绕一个偶尔忘记闭合花括号的模型编写重试逻辑的人来说,它确实很有价值。代价是,一个拥有 512 token 窗口、背后没有生成式预训练的 421M 编码器,所知并不算多。Convai 在模型卡上也是这么说的:“Laya 是一个可快速特化的基座,而不是零样本决策引擎。”

A screenshot of the Laya project page, showing the Apache 2.0 licence, the 421M ModernBERT-large English checkpoint with a 512-token window, the 322M mmBERT-base multilingual checkpoint with a 1,024-token window, the 32.8ms p50 per decision on a Tesla T4, and the pip install entry point.A screenshot of the Nimble repository on GitHub, showing the description "Local typed decisions, contrastive data curation, and model evaluation", the README heading "Bespoke Nimble - Data, Model, Recipe for an open Jev", the contrastive example where changing one fact flips the correct answer, and the 2,676-example training split against the frozen 324 held-out set.

Nimble 的主张是关于数据的。Bespoke 的方法是对比式策展,改编自该团队此前的 Bespoke-MiniCheck 工作:编写两个几乎相同的示例,它们只在一个“焦点事实”上不同,从而使正确的标签发生翻转。该流程包含四个明确步骤——检查决策规则是否确实可能得出不同答案,通过最多改动八个词来构建这对示例,用独立的模型调用验证两个示例并辅以逐句移除检查,以及在代码中生成标签,同时只保留标签确实不同的示例对。目标不是更多示例,而是更锐利的示例:迫使模型学会哪些证据应当改变决策。这是关于小型决策模型为何失败的一种不同理论,而且比再添一个准确率数据点更有意思。

已公布的数字究竟支持什么

Nimble 报告称,在 324 个留出样本上与参考标签的一致率为 90.12%,而 Jev 为 93.21%,未调优的 Qwen3.5-9B 基础模型为 66.36%,未调优的 27B Qwen3.8 为 84.88%。它报告在 H100 上中位数约为 106 毫秒,在配备 64GB 的 M5 Pro 上中位数约为 444 毫秒。这些是 Bespoke 自己的测试框架数据。324 样本评估集是需要仔细权衡的部分,项目自己也说明了原因:这些样本覆盖十个训练来源家族中的六个,它们由模型生成和验证,未经人工审核,因此向未见类别的泛化能力尚未得到证明。当一个模型使用数据整理方法训练,然后在同一整理分布的留出划分上评估时,准确率数字说明的是该方法内部的一致性,而不是你的流量。

Laya 的数字来自另一端。在 TypeSafe 的类型化决策基准上,它的零样本得分为 0.362——随机为 0.318,多数类基线为 0.461——而在该基准自带的训练划分上微调后为 0.766。在 Banking77 上,77 个标签,它得分为 0.425,而 Jev 为 0.870,这是其多选项上限最鲜明的例证。在四标签的 AG News 上,它得分为 0.950,而 Jev 为 0.910;在六标签的 DAIR Emotion 上,为 0.595 对 0.480。它的校准误差发布时为 0.466,在按问题类型重新拟合温度后降至 0.081。一项针对 100 条 Mars-base 紧急消息的第三方测试中,Jev 为 100/100,Laya 为 53/100。而在一项独立的智能体工具调用评估中,Laya 对危险调用实现了 100% 的拒答召回率,但只是通过标记所有内容实现的,这是一种伪装成安全胜利的精确率失败。

把这两组数字并排放在一起,诚实的解读是:它们衡量的是不同的东西。Nimble 的 90.12% 是其与自家精心整理的参考标签之间的一致性。Laya 的 0.362 是一个并非由它自己构建的基准。这两个数字都不能通用。

校准:两个项目都异常坦诚的唯一之处

这正是两个项目精神上最为接近、结果上却相距最远之处。

Bespoke 的 README 明确警告称,Nimble 的概率是对所提供候选进行 softmax 归一化后的 logits,而非经过校准的正确率——0.9 并不意味着 90% 正确。它建议添加一个“以上都不是”选项,因为如果正确答案不在候选之中,其中一个候选仍然会胜出。在一项涵盖 13 个子集的较新 3,880 条记录评估中,Jev 在 13 个子集里的 11 个中报告了更低的校准误差,并在 13 个子集里的 10 个中取得了更低的 Brier 分数。因此,相似的标签一致性并不意味着相似的概率质量,而 Bespoke 也正是这么说的。

Convai 的披露则是镜像般的存在:0.466 的预期校准误差白纸黑字写在模型卡上,紧挨着按问题类型重新拟合温度参数所得到的 0.081。两个项目都没有交付一个无需额外工作、就能让你直接依据其置信度采取行动的模型。两者都以书面形式明确告知了这一点。如果你正在构建一个置信度阈值——高于 0.95 自动放行,低于 0.7 升级转人工——两位作者的文档都在告诉你同一件事:先在你自己的标注数据上拟合这个阈值。

比较,逐维度进行

• 骨干网络 — Laya:ModernBERT-large 421M 编码器,双向,无生成式预训练。Nimble:Qwen3.5-9B,带 LoRA 微调,保留生成式基础。

• 语言 — Laya:通过 322M 多语言检查点支持 100+ 种语言。Nimble:英语。

• 提示词预算 — Laya:英语 512 个 token,多语言 1,024 个。Nimble:每个提示词最多 2,048 个 token,仅支持扁平 schema,枚举每个字段最多 26 个选项。

• 速度 — Laya:在 T4 上 p50 为 32.8ms,批大小为 10 时每题 7.2ms。Nimble:在 H100 上中位数约为 106ms,在 M5 Pro 64GB 上为 444ms。

• 硬件 — Laya:CPU、CUDA 和 Apple MPS;在 MLX 移植版上常驻内存不足 1 GB。Nimble:所述数据基于 BF16 CUDA GPU,同时支持 MLX 与 CUDA 路径。

• 报告的准确率 — Laya:零样本 0.362,微调后 0.766,在 Banking77 上为 0.425。Nimble:在 324 个精选留出样本上达到 90.12%,而 Jev 为 93.21%。

• 方法 —— Laya:架构优先,按部署场景分别微调。Nimble:对比式数据整理,以配方形式发布。

• 许可证 — 两者均为 Apache 2.0。

那份清单里有两项限制,值得你在拍板之前读上两遍。Nimble 每个枚举最多 26 个选项的上限,以及 2,048 token 的提示词上限,都是硬性的 schema 限制,而不是性能下降——如果你的分类体系有四十个标签,或者你的提示词里带着一份长文档,那么无论 Nimble 的准确率有多高,它都是不合适的工具。而且 Nimble 会对每个字段独立评分,所以任何跨字段的一致性规则——"如果 A 为真,那么 B 必须为假"——都必须放在你的代码里,而不是模型里。

为什么数据配方是更具可移植性的产物

以下是支持 Nimble 的论点,而准确率表格却未体现。Bespoke 公开的是策展流水线,而不仅仅是权重。如果你的决策问题拥有固定分类体系,而且你能把规则写下来,那么你就可以用自己的数据、自己的焦点事实,在你偏好的任何基础模型之上运行这种对比方法。9B LoRA 既是一个产品,也同样是对该方法的展示。

Laya 的可移植性有所不同,且形成互补。因为它很小,因为它在 CPU 上运行,还因为存在 ONNX 和 MLX 版本,Laya 是你可以放进一个没有 GPU、也没有网络的进程里的模型。在一项第三方浏览器智能体基准测试中,Laya 完成了 50 项任务中的 0 项,并在 33 次尝试中过早宣称完成——但基准测试作者指出,它训练用于支持工单、发票和智能体轨迹审查这类判断型工作,而非导航。应把这一结果理解为范围说明,而不是最终裁决,而且这与两个项目的定位一致:它们是用于某一类特定决策的组件,而不是通用智能体。

Laya 和 Nimble 都不是 OrcaRouter 上托管的模型。两者都是你自己运行的权重,本文中的任何内容都不应被解读为我们在提供它们的说法。之所以会提到路由产品,原因与它在任何决策模型架构中被提及的原因相同:决策模型只回答一次调用,而围绕它的应用仍然需要成文的文字。一条用 Nimble 评估草稿是否合规、用 Laya 路由异常情况的流水线,仍然需要一个生成式模型来撰写草稿。把生成的那一半保留在一个 OpenAI 兼容端点上——200+ 个模型,按供应商标价透传,0% 加价因此厂商降价当天即可生效,还能跨供应商自动故障转移——意味着可以在不触及生成层契约的情况下替换决策层。

裁决,以及将改变它的实验

如果你的分类体系固定且范围狭窄、输入是简短的英文、你有 GPU,并且你想要的不只是模型、还有数据配方,那就选 Nimble。如果你需要多语言输入、40 毫秒以内的预算,或者完全没有 GPU 的流程,那就选 Laya——并且从一开始就把微调的成本算进去,因为零样本检查点的表现低于最平凡的基线,而模型卡上也是这么写的。

能一锤定音的那个实验,是在真实流量上做配对评估:相同的输入、相同的选项集、相同的置信度阈值,对照人工标注来评估,并为每个模型各配一张可靠性图。Nimble 自己的文档警告说,它的概率并不是正确率,而 Laya 的模型卡报告了重拟合之前 0.466 的校准误差,所以那张图才是真正能告诉你该把哪个模型放到生产环境前面的产物。两个项目都没有发布这样一张图,也都没有发布对方的。在设定阈值之前,先在你自己的数据上把它做出来。

A generated two-column scoreboard comparing Laya and Nimble across backbone, languages, prompt budget, label agreement, latency and licence, with a footer reading "Nimble's 90.12% is agreement with its own curated labels; Laya figures per its model card."