Laya 超越 Jev？那张“领先 16%”的表，作者自己改了

一个开源模型，只有几亿参数，本地就能跑，还宣称超过了刚发布的 Jev。这确实是一个让人想点进去的故事。

顺着“Laya 超越 Jev”的说法往下找，我找到了一张很有冲击力的表：Laya 83.8%，Jev 67.8%。 两个数相减，刚好差 16 个百分点。9 月 18 日的项目说明

但第二天，作者就提交了一次更正：仓库自己的测试，并不支持旧表中的 83.8%，也不支持“领先 Jev 16%”的说法。9 月 19 日的更正记录

旧表与更正记录的文字整理。83.8% 和 67.8% 是早期宣传中的数字，原有比较结论已被作者修订。

这次更正让整件事变得更值得讨论：旧结论站不住，Laya 仍然有可取之处；专项模型确实能取得更好的成绩，但那个成绩究竟适用于哪些任务？

把截至 2026 年 9 月 22 日能查到的项目说明、源码和第三方结果放在一起，答案逐渐清楚了：“Laya 全面超越 Jev”缺乏支持；Laya 的开放权重、本地运行和专项训练能力，则值得认真看。

一、那张胜负表，究竟改了什么

新版说明改为列出实际测得的结果，同时交代了一个关键条件：Laya 作者没有在这次测试中调用 Jev API，表里的 Jev 成绩引用自第三方，提示词和样本量可能存在差异。 后续文档还补充了 Jev 领先的方面。更正提交、更新后的说明

因此，继续转发旧表，会漏掉作者自己已经补上的重要信息。判断现在的 Laya，也应当看更正后的模型和测试条件。

二、先弄清楚：它们在做什么

Jev 和 Laya 都面向一种很具体的需求：给模型一份状态，再让它回答边界明确的问题。

例如，一封客户邮件已经到了系统里，程序需要判断：它属于咨询、投诉还是退款？需要普通处理还是加急？是否应当交给人工？模型交出选项、等级或概率，程序据此继续执行。

这种接口对自动化很有吸引力。开发者可以提前约定答案范围，减少从自由文本中提取结果的麻烦。但即使返回的字段完全合规，模型仍可能把投诉分到咨询里。格式稳定与判断正确，是需要分别验证的两件事。 Jev 接口说明、Laya 项目说明

两者的使用条件也不同。Jev 通过托管 API 提供服务；Laya 公开了代码和权重，用户可以本地部署并继续训练。Laya 源码采用文本编码器加选项打分模块，直接计算候选项的分数，不需要逐字生成一段答案。Jev 模型文档、Laya 实现

开放权重带来的控制权，是 Laya 的一项实际优势。要判断回答质量，仍然得回到具体模型和具体任务。

三、同样叫 Laya，36.2% 和 76.6% 可能都是真的

Laya 项目提供了多个版本。与这次争议最相关的，是下面三个：

这里列的是 SDK 默认配置；输入预算还要容纳问题和选项，不能直接理解成正文可以完整占用的长度。版本与配置见 Laya 项目说明及源码。

在 typed-decisions 这组工作流任务上，项目更新后的表格给出了两组相差很大的 Laya 成绩：

• 英文基础版：36.2%。
• 使用这套基准训练集训练过的专项版：76.6%。

同表引用的 Jev 成绩是 72.7%。也就是说，超过这项 Jev 公开成绩的是专项版 Laya。这里必须保留两层条件：专项版做过任务适配；Jev 数字来自第三方，并非 Laya 作者在同一次测试中得到。项目结果与限制说明

这套基准采用合成案例，并由教师模型生成参考标签，因此这些准确率也不能直接当成真实业务中人工核验的正确率。它的训练集和测试集分开，不能仅仅因为“用过这类任务的数据”，就指控测试泄漏。typed-decisions 数据集

专项训练本来就有价值。企业如果长期处理固定类型的工单，有自己的历史样本和明确的判定规则，一个可训练的小模型可能很有吸引力。另一份开发者实验，进一步展示了适配方法怎样改变结果。

同样的 140 个标签，适配方法会改变结果

Anthus 在 600 条合成情感测试文本上，比较了直接使用模型、加入反馈适配层，以及训练 Laya 权重这几种做法。反馈层和微调使用相同的 140 个标签预算，作者报告如下：

来源：Anthus 的对照实验。测试语料含人为设置的主题与情感关联；标签由脚本回放参考答案，不是实际客户反馈。反馈层结果有公开代码与逐条记录；本次核对的仓库版本中，未找到 89.6% 那部分对应的完整微调复现材料，这一项按作者报告引用。

这组结果给出了一种具体的使用方向：业务判断长期稳定、手里有标注数据时，开放权重提供了继续训练的空间。直接调用时的名次，未必就是完成任务适配后的名次。

问题出在省略条件之后的推广：在一个经过适配的任务上取得好成绩，不能直接推导出换一批业务、换一种表达，仍然普遍领先。

所以，看见“Laya 76.6%”时，先问清楚它指的是哪个版本、训练过什么。一个模型家族的名字，装不下这些差别。

四、放进同一套题里，结果怎样

另一份材料来自第三方项目 JevBench。它使用一套合成英文题，公布了 534 个决策的分层结果：

根据 JevBench 公开数据重绘。测试采用 Laya 英文基础版、SDK 0.3.3 和默认 512 token 输入上限；较长题目存在截断。四组分别包含 72、96、146、220 个决策。Laya 测量记录

在这套题和这套接入方式下，Jev 四组都更准确。最简单的一组，两边差距较小；hard 组中，Jev 为 74.1%，Laya 为 34.1%。JevBench 原始结果与测试配置

不过，这个差距里包含了一个不能省略的变量：Laya 的输入被截断了。

报告说明，部分较难题目的状态达到约 2,000 至 6,000 token，而测试使用的 Laya 默认预算是 512。关键事实如果落在被截掉的部分，模型根本没有机会完整读到题目。要进一步分清输入长度和推理能力各自造成了多少损失，还需要另外控制输入预算。

因此，这组结果说明的是英文基础版在当时默认配置下的表现，也没有覆盖全部专项版本。

JevBench 页面还有综合分。本文采用原始分层正确率，因为该项目后来调整过综合评分规则，同一批答题结果可以因此出现不同的总分。比较模型时，先看它实际答对了多少，再看榜单怎样计算分数。机器可读结果及修订说明

五、单题更快，为什么多问时会反过来

速度是 Laya 另一个很有吸引力的卖点。项目公布的 T4 GPU 测试中，多语言版处理一个问题约需 32.8 毫秒；一次批量处理十个问题约需 72.3 毫秒。这两个数字都是预热后的本地调用耗时中位数。后一个数除以十，才得到每题约 7.2 毫秒。Laya T4 测试结果

这说明批量处理可以摊薄每个问题的开销。如果十个判断能同时发出，收益很直接；如果第二个问题必须等第一个答案出来，程序就无法直接享受同样的摊薄效果。

Jev 官方同样支持把多个独立问题放进一次请求。比较时，两边怎样组织调用，会直接影响等待时间。Jev 多问题并行模式

Harry Munro 在 9 月 21 日发布了一份应用型测试：实际调用 Jev API，并在 Apple M3 Pro 上运行 Laya 的 MLX 移植模型，覆盖 1,470 条合成输入、8 类任务，公开了原始样本、逐条预测和计时记录。任务包括工单分流、内容审核、请求路由和长文查找。完整报告

其中一组测试固定输入状态，逐步增加同一次请求中的问题数：

按 Harry Munro 的原始计时重绘。Laya 为本地英文基础版、MLX FP16；Jev 为托管 API，包含当时网络耗时。测试在同一条消息上增加不同问题，每档预热 3 次、计时 30 次；图中为耗时中位数，不含模型加载，也不是处理同等数量的独立客户工单。

单题时，Laya 只需 42.2 毫秒，Jev 为 142.1 毫秒。增加到十题，Jev 为 135.4 毫秒，Laya 为 349.1 毫秒；五十题时，两者分别为 170.1 毫秒和 1,001.8 毫秒。在这台机器和当时的网络条件下，多问题调用的速度关系发生了反转。

这与两者处理多问题的方式有关：Jev 官方说明可以共享状态、并行判断；Laya 实现则把状态与每道问题分别拼接，再组成批次计算，增加问题仍然会增加需要处理的数据。Jev 模式说明、Laya 推理实现

落实到应用里，给一条内容打一个标签，与同时判断主题、风险、优先级和是否需要人工，是不同的负载。选模型时应计算完成全部判断的时间。 这组结果支持当时配置下的取舍，不能据此预测所有硬件、网络和任务中的交叉点。

六、分错队列时，高置信度能不能帮上忙

中文工单有一份更小、但能看到具体错误的公开测试。开发者 yibie 用 40 条自建中文样例，将消息分到“账单、物流、技术、售前”四类；Laya 使用多语言版的 MLX 移植模型，Jev 使用 API。结果是 Jev 正确 31/40，77.5%；Laya 正确 23/40，57.5%。 测试说明

其中一条输入是：

接口一直返回 500。

Jev 将它分到技术问题；Laya 将它分到账单问题，返回的 confidence 却约为 0.997。按这份回答自动分流，技术故障就会进入账单队列，而高分并不会提醒系统停下来复核。Laya 逐条记录、Jev 逐条记录

这 40 条样例不能代表完整中文能力，部分“你好”“谢谢”等边界消息的参考标签也有争议。它最适合说明一个应用问题：模型会不会在分错类时，仍然给出很高的分数。

置信度究竟表示什么

Laya 的 Choice 和 Score 实现中，这个字段由 1 减去候选项分布的归一化熵得到，主要反映分布是否集中。假设两个候选项的概率为 0.9 和 0.1，按源码公式算出的 confidence 约为 0.531。这个例子只是公式换算，却足以说明：最高选项概率、接口的 confidence、真实答对频率，不能直接画等号。 Laya 置信度定义

Jev 的文档也将 confidence 解释为输出分布形状的摘要。因此，在业务中设一个“低于某值就转人工”的阈值之前，应当拿真实标注样本检查：分数高的答案究竟有多可靠，哪些错误仍会高分出现。Jev 置信度文档

工单优先级，还要分清情绪与时限

Harry Munro 的合成工单任务中，有一个问题专门判断“是否表达时间压力、截止期或需要立即行动”。逐条结果里出现了这样的差异：

这里是紧急命题的概率，不是前文的 confidence 字段。案例编号为 triage-0006、triage-0005；原文与标签见合成样本，规则见问题定义，回答见双方预测记录。

如果程序以 0.5 为分界自动加急，Laya 在这两例里会漏掉有截止期的请求，并将没有明确时限的请求提前。这些是第三方合成任务中的案例，展示了错误可能怎样影响业务队列；它们并不是实际客户的上线事故。

这一点也提醒我们，对 Jev 的较好成绩不宜继续放大。它自己的限制说明列出了计数、日期与数值比较、多步间接推理、包含大量无关信息的长文本等失败类型。某份榜单上更准，并不等于可以让它无条件接管业务。Jev 1.13 已知局限

七、我会怎样看待 Laya 的价值

如果问题是“Laya 已经全面超越 Jev 了吗”，目前的公开证据不足以支持这个结论。早期最醒目的比较表已被更正；typed-decisions 中引用的领先成绩来自专项版本；另一套公开题目中，Jev 在既定测试配置下表现更好。

如果问题是“Laya 值不值得继续关注”，我的答案是值得。

这几组应用型测试，把选择条件说得更具体了：

• **短文本、一次只做少量判断：**本地 Laya 的低延迟有直接价值；是否能省下工作，还要看错误和复核量。
• **一份状态要同时判断多个字段：**应比较整次工作流的耗时。Harry Munro 的测试中，Jev 在多问题负载下反超，单题速度无法代表完整流程。
• **长期稳定的任务、有自己的标注数据：**Laya 可以继续训练，Anthus 的报告展示了这条路线；换任务之后，仍需重新验证。
• **自动分流和优先级排序：**重点检查分错队列、漏掉时限以及高分答错的案例。是否少让人工纠正，比一个漂亮的 confidence 更有实际意义。

这些研究已经比单一胜负表更接近应用，但仍以合成数据、自建样例和指定机器上的运行结果为主。真实业务里的纠错量、完整延迟和运行成本，最终决定哪种方案值得留下。

这场争论最有用的地方，是让“超过了谁”变成一个更具体的问题：哪个版本，在什么任务上，读到了多少信息，经过怎样的训练，以什么代价，做对了多少决定？

这些条件写清楚以后，Laya 的优势才更容易被用对，Jev 的成绩也才更容易被理解。