Laya 与 Jev 对比：开源替代方案真的够好吗？

TypeSafe 在 9 月 15 日发布了 Jev。几天之后，Convai Innovations 以 Apache 2.0 许可放出了 Laya：一个 421M 参数的模型，回答同样的类型化问题，跑在您自己的硬件上，每次调用不产生费用。

此后至少出现了七个 Jev 的开源仿制品。大多数报道就是在列举它们都有哪些。几乎没有哪一篇回答您真正关心的那个问题：它们当中有没有哪一个好到可以拿来用。

就 Laya 而言，简短的答案是：可以，但适用的范围比那些标题让人以为的要窄。它确实更快，确实更省钱，并在多项分类任务上胜过 Jev。它开箱即用的分数也低于多数类基线，并且在选项很多的问题上会垮掉。这场对比之所以做得成，是因为 Convai 把两面都写进了自己的模型卡，包括对自己不利的那部分。

Laya 是什么#

Laya 做的事和 Jev 一样。您把状态交给它，把带类型的问题交给它，它在一次前向传播中把这些问题全部回答完，并给出校准过的概率。它支持同样的三种基本类型：choice 用来挑一个选项，score 用来按有序等级打分，noul 用来问一个是否类问题并拿到一个概率。没有任何内容被生成，所以也没有任何内容需要解析。

连训练方法都是同一套。Convai 用 RLCD 配合严格恰当评分规则训练 Laya，正是 TypeSafe 为 Jev 描述的那套做法。

一共发布了三个 checkpoint：

它用 pip install laya 安装，公布的基准测试跑在一块 Tesla T4 上。

Laya 赢在哪里#

Convai 公布的正面对比，所有数字都来自它的模型卡：

“带路由”这三个字很重要。那些准确率数字来自一个路由器针对每条输入在英语 checkpoint 和多语言 checkpoint 之间做选择，而不是来自单一模型。只用英语 checkpoint 的分数是 0.947 和 0.573，所以路由确实在起作用，而这套路由得由您自己搭。

延迟才是真正的成果。Jev 那 70 毫秒的下限是在模型端测的；您实际体验到的是一次跨网络的托管 API 调用，第三方测出来是 236 到 276 毫秒。Laya 在本地 32.8 毫秒就给出答案，批处理还能更好：十个问题总共 72.3 毫秒，平均每个约 7.2 毫秒。

Emotion 是更有意义的那项准确率胜绩，因为它被排除在 Laya 的训练数据之外。AG News 不是，所以那一项看看就好。

Laya 输在哪里#

两处失手，而且都不小。

高基数。 在 Banking77 上，模型要从一长串里挑出唯一一个银行业务意图，Jev 在一个 72 标签的版本上得 0.870，Laya 在全部 77 个标签上得 0.425。两边的标签数量并不相同，这一点对这里想说的结论是不利的，所以请把这个差距看作“很大”，而不是一个精确数值。Convai 没有回避，而是解释了其中的机制：在默认设置下，一个 77 选项的问题平均分给每个标签大约三到四个 token，不足以把它们表示清楚。文档里给了几种变通办法，涉及加长输出头、用嵌入做候选筛选，或者把一个问题拆成粗筛和精选两遍。模型卡自己的总结很直接：“在不做调优的情况下，Jev 目前更适合 50 个以上选项的场景。”

零样本准确率。 这一项最要紧，却最少被报道。两个基础 checkpoint 在 typed decisions 基准上是 0.362 和 0.352。随机猜测是 0.318。每次都选最常见的答案是 0.461。开箱即用的 Laya，离随机比离一个平凡基线更近，而 Convai 把结论说得很直白：“Laya 是一个可以快速专门化的基础模型，不是一台零样本决策引擎。”

还有三个较小的约束。有序打分是最弱的一种基本类型，在 SST-5 上只有 0.372。两个 checkpoint 出厂时都过度自信，您要先做温度重校准，才谈得上相信一个概率。而英语 checkpoint 一离开英语就会垮掉，多语言 checkpoint 在英语里又更弱，所以要么在两者之间做路由，要么有意识地只挑一个。

那个值得核一核的数字#

Laya 的头条数字是 typed decisions 基准上的 0.766，对 Jev 的 0.727。这看起来是一场干净利落的胜利，直到您把同一张表再往下多看两行。

这个 0.766 属于 laya-typed-decisions，一个在该基准自带的 1,200 条训练集上微调过的 checkpoint。而同一张表还列出了 0.735 的教师自一致性上限，微调后的模型超过了它。分数高过生成标签的那套流程本身的上限，正是一个模型学会了基准、而不是学会了任务的标志。Convai 自己对这个 checkpoint 的描述也是一致的：“在其他任何任务上，请预期它的表现与基础 laya checkpoint 相当，或者更差。”

在同一张表上，Jev 赢下了没人引用的那两列。软准确率：0.580 对 0.471。校准误差：0.144 对 0.213。在这个 Laya 专门为之调过的基准上，Jev 的校准更好，出错时也离正确答案更近。

两套数字都告诉不了您的事#

三处不对称，这样您就能用同一把尺子去读两家厂商。

Convai 表格里 Jev 那一行标的是“published”。它不是在同一套测试框架、同一天、同一批输入上跑出来的。它是从 TypeSafe 的材料里摘出来、再放到一个由 Convai 实测的数字旁边的。

Laya 那 7.8 倍的延迟优势，比的是一块本地 GPU 和一个走公网的托管 API。对一个要在两者之间做选择的开发者来说，这是诚实的比较，但它不是同等条件下的模型速度测量。

而 Jev 自己的头条数字也比看上去要软。正如我们在那个 193 倍基准测试到底没测什么一文中讲过的，TypeSafe 的工作流评估把正确答案定义为 GPT-6 Astra 与 Fable 5.1 的平均值，因此它们衡量的是与两款前沿模型的一致程度，而不是准确性。这场对比里的两方，都不是站在标准答案之上的。

该用哪一个#

这个决定无关哪个模型更好，而在于您手上有什么。

选 Laya，如果您有标注数据、或者做得出标注数据，并且有地方跑 GPU。您会拿到 33 毫秒的答案、没有按次调用的费用、Apache 2.0、100+ 种语言，以及完全的掌控权。您得先实打实地花时间做微调和重校准，这部分工作应该提前列进预算，而不是做到一半才发现。

选 Jev，如果您这周就需要它零样本地跑起来、您的问题选项很多，或者您不想自己运维推理。它不用调优就能应付高基数，而托管这条路本来就是它的意义所在。

Laya 不是一个可以直接顶替上去的选项，Convai 也从没这么宣称过。它是一个快速、免费、诚实的基础模型，一旦被专门化就有竞争力。开源替代品是真实存在的。只不过它向您要的是几天标注工时，而不是 API 额度。

不管上哪一个#

无论您最后落在表的哪一边，从模型到生产之间的工作形状都是一样的：走 Laya 就得算上微调和重校准的投入，两条路都要做 schema 与阈值设计，外面还要有自托管推理或智能体与自动化工程把它撑起来。

参考来源

• Laya 模型卡与 laya-typed-decisions，Convai Innovations：checkpoint、基准测试表格与局限。
• Laya 代码库：安装、API 示例、速度表格与基数处理指引。
• Introducing System One Models & Jev，TypeSafe AI：Jev 的定价、延迟与评估方法。