Jev vs Laya：在 T4 上的 33 毫秒，以及一个随机基线

Laya 的模型卡中包含一句决定这场对比的话，而这句话正是由打造 Laya 的人写下的。"Laya 是一个可快速专门化的基础模型，而不是一个零样本决策引擎。"Convai Innovations 于 2026 年 9 月 18 日发布 Laya，比 TypeSafe AI 推出 Jev 1.13（typesafe/jev-1.13）晚三天，采用 Apache 2.0 许可，权重托管于 Hugging Face，并提供 pip install laya 这一入口。它通过单次前向传播回答带类型的问题，无需逐 token 解码，这与 Jev 所做的架构押注如出一辙。其主打宣称是在 Tesla T4 上每次决策的 p50 延迟为 32.8 毫秒，被表述为比 Jev 通过其托管 API 公布的 236–276 毫秒 p50 快约 7.8 倍。这一宣称是真实的，但它同时也衡量着两件不同的事——本地 GPU 与一次网络调用——而它背后的准确率情况，才是决定你是否该下载它的关键。在零样本设置下，Laya 在 TypeSafe 的带类型决策基准上得分为 0.362。随机猜测得分为 0.318。多数类基线得分为 0.461。开箱即用的 Laya，离随机猜测比离这个平凡基线更近。新的东西既不是这两个模型中的任何一个，而是其中一个可以在哪里被调用：2026 年 9 月 24 日，OrcaRouter 将 typesafe/jev-1.13 加入了其目录——模型本身属于 TypeSafe，出自 9 月 15 日——这是这场对比中近期唯一发生变化的一点。

Laya实际上是什么

Laya 以两个检查点的形式交付，背后是一个内置路由器，将每个输入分派到正确的那个。英语检查点是 ModernBERT-large，拥有 4.21 亿参数和 512 个 token 的上下文。多语言变体是 mmBERT-base，拥有 3.22 亿参数，支持 100 多种语言，窗口为 1,024 个 token。两者都是非自回归的：一次前向传播就返回答案，因此没有解码循环，没有需要解析的 JSON，也没有任何空间去输出所声明类型之外的文本。最后这一特性正是 Jev 所提供的同一种结构性保证，只是从不同方向达成，而且对于任何曾围绕一个偶尔忘记闭合花括号的模型编写重试逻辑的人来说，它都确实很有价值。

Jev 是闭源的对应方案，而两者之间真正重要的区别在于谁运行模型，不在于哪一个得分更高。TypeSafe AI 的首个 System One 模型于 2026 年 9 月 15 日发布，采用托管方式——没有可下载的权重——并且可以通过我们以 typesafe/jev-1.13 进行路由，经由 POST /v1/systemone 调用，非流式，上下文长度为 65,536 个 token。Laya 则是另一种安排：开放的 Apache 2.0 权重由你自己运行，在你已经拥有的硬件上，路径中完全没有端点。Jev 接收三种类型化原语——从你提供的列表中进行 Choice、按有序评分标准进行 Score，以及 Noul，一种带有校准概率的是/否主张。所有问题都会基于对状态的一次共享读取并行评估。定价为每百万输入 token 0.042 美元，输出计费为零，因为没有可计量的输出 token。其架构、参数数量和训练算力均未披露，TypeSafe 表示细节暂时保密，可能稍后发布论文。

关于延迟的说法，经过正确测量

Laya 在 T4 上 p50 为 32.8ms 是一个真实且不错的数字。与 Jev 的 236–276ms 进行的 7.8 倍对比，才是需要谨慎对待的地方，而 Laya 自己的模型卡对其中原因异常坦诚：Jev 的那些数字是第三方公布的数值，Convai 自己从未测量过；而且这一比较是把本地 GPU 前向传播与包含网络往返和排队的主机 API 调用放在一起比。把网络因素剥离后，架构上的比较就是两个单遍模型之间的比较：一个为 421M 参数，另一个的规模 TypeSafe 从未公布过。

还有一个值得了解的批处理数字：当批大小为十时，Laya 报告每道题耗时 7.2 毫秒。这就是这款产品的形态。Laya 旨在本地大规模运行，而诸如 laya-mlx 这类设备端社区移植版将其扩展到 Apple Silicon。病毒式传播的“比 Jev 快 50 倍”的说法，并未得到该项目自己发布的基准测试支持；诚实的表述是，本地与云端之间存在巨大差距，这部分源于架构，部分则仅仅是你自己的 GPU 和别人家的 API 之间的差异。

准确率数字按顺序说明了什么

这正是这种比较不再讨喜的地方，而它值得按顺序逐一列出，因为次序本身就有讲究。

• 在 TypeSafe 的 typed-decisions 基准上的零样本表现——Laya 0.362，随机 0.318，多数类 0.461，Jev 0.727。Laya 高于随机水平，低于平凡基线。

• 在基准测试自身的训练划分上进行了微调——Laya 0.766 对 Jev 的 0.727。Laya 胜出，而这一胜利来自一个已经见过该基准测试训练数据的检查点，因此它说明的是微调，而不是基础模型。

• Banking77 意图分类，其中选项集很大——Laya 为 0.425，而 Jev 为 0.870。当选项超过大约 20 个时，Laya 的性能急剧下降，而据文档记载，Jev 的 Choice 字段最多可处理 255 个选项，之后才需要采用两阶段评分模式。

• 校准——Laya 出厂时的平均期望校准误差为 0.466，只有在按问题类型分别进行温度重拟合后，才改善至 0.081。Jev 使用一种 TypeSafe 称为 RLCD 的方法进行训练，即 Reinforcement Learning for Calibrated Decisions（用于校准决策的强化学习），并为每个答案附带概率分布——不过 TypeSafe 也告诉用户要在自己的标注数据上验证阈值，而一项独立审计发现，Jev 的校准情况会因任务不同而出现剧烈变化。

这个模式毫不含糊。Laya 是一个强大的微调基础，却是一个薄弱的零样本决策引擎，而且它自己也这么说。Jev 是一个强大的零样本决策引擎，但其校准仍需按每次部署进行检查。它们是具有不同价格结构的不同产品，在二者之间做选择，主要取决于你是否有标注数据和训练循环。

成本运算的形态与 Jev 的不一样

Jev 每百万输入 token 收费 $0.042，输出免费，也就是每十亿 $42；按照文档所述 64K token 请求预算进行的最大规模调用，成本远低于一美分。通常被引述为大约 32,000 token 的那个数字，是状态加上单个最长问题的上限，而不是请求的上限——TypeSafe 的文档说明，每个请求中状态与所有问题合计为 64K token，而我们自己的 typesafe/jev-1.13 模型卡列出的上下文长度为 65,536 token。Every 的独立测试在 37 份文档上做出了 777 项判断，成本约为四分之一美分。

Laya 的每次调用成本在边际上为零，在总量上则非零，而且这个总量并不小。在 T4 上运行一个 4.21 亿参数的模型成本很低，但仍要占用一块 GPU；而让 Laya 具备竞争力的微调环节才是真正花钱的地方——数据标注、训练运行、评估工具链，以及按问题类型重新拟合温度参数，这将其校准误差从 0.466 降到 0.081。对于永不变化的固定分类体系，这是一次性成本，会在规模化时收回。对于会漂移的分类体系，它则是经常性成本，而 Jev 的零样本基线 0.727 就变得划算得多。

还有第三项成本很容易被忽略：Laya 的英文检查点只有 512 token 的上下文窗口。它不是一个上下文预算很小的决策模型——它是一个按段落规模设计的决策模型。Jev 的 64K token 请求预算要大上一百多倍，而即便如此，它仍比二者在定价时对标的生成式模型低一个数量级。如果你的状态是一个支持会话串，而不是一条支持消息，那么这两个模型的窗口都不是你应当针对其进行优化的约束。

部署问题才是真正的区别所在

Laya 最有力的论据不是延迟。而是 Hugging Face 上的 Apache 2.0 权重意味着决策永远不会离开你的基础设施，端点也永远不会有速率限制。对于基于病历、法律文件或客户账户历史做出的路由决策而言，这不是一种偏好——而是决定性因素，任何价格的托管端点都无法在这场论证中胜出。TypeSafe 自己的主页仍将 Jev 描述为处于早期访问阶段，而该供应商的文档指出，其速率限制正在动态调整，并且可能在不另行通知的情况下发生变化。

反方的论点在于你要放弃什么。Jev 那套未披露的更大架构，正在完成 Laya 的 4.21 亿参数做不到的事：0.727 对 0.362 的零样本差距，以及 0.870 对 0.425 的 Banking77 差距，衡量的都是在训练之前模型内部沉淀了多少知识。Laya 的回应是：这些知识由你自己通过微调来提供，而在一个狭窄的固定领域里，这个答案行得通——0.766 的微调结果就是证明。

决策层在真实技术栈中的位置

这两个模型都不生成文本，因此任何一个都不是完整的工作流。二者共同面向的模式是双模型：一个做出类型化调用的决策层，以及一个处理需要散文、代码或解释那部分内容的生成模型。过去这种拆分意味着要再签一份供应商合同，因为决策那一半无法与生成那一半用同一个密钥调用。现在可以了。Jev 可通过我们以 typesafe/jev-1.13 经由 POST /v1/systemone 路由——非流式，65,536 token 上下文，每百万输入 token $0.042，输出计费为零。我们自己对这条路由为期七天的服务记录显示 p50 为 151 毫秒，这是我们自己硬件上自己流量的数据，而非基准测试。这是网络测量，与上文 32.8ms 的本地前向传播不同。Laya 保持另一种安排：你自己运行的开源权重，我们不托管，也无需托管。该模式中的生成那一半正是我们所覆盖的：200+ 模型位于一个兼容 OpenAI 的密钥之后，以 0% 加价按供应商标价透传，因此供应商调价当天就会在我们这边生效。双模型架构无需第二份供应商合同即可验证——决策那一半与生成那一半同样如此——并且凭借自动故障转移，在你判断这个廉价的决策层是否已校准到足以据此自动化之前，生成路径不会变成单点故障。

裁决

如果你有一个固定、狭窄的分类体系，有标注样本，并且有排除托管 API 的隐私或延迟要求，那么 Laya 是更站得住脚的选择，微调后的数字也支持这一点。如果你需要决策开箱即用，如果你的选项集超过二十个类别，或者如果状态长度超过一段，Laya 自己的模型卡会告诉你它不是适合该任务的产品——而当有人向你引用 7.8 倍延迟数字时，相对于 0.461 的多数基线，0.362 的零样本得分才是你应该牢记的数字。

这两者的共同点比它们之间的差异更有用。两者都能消除源自输出格式的那一类错误，却对源自判断的那一类错误无济于事。两者都会输出概率，而且都没有一份不经核实就可信任的公开可靠性图。在针对二者中的任何一个进行自动化之前，先在你自己的已标注案例上测试其校准——延迟已经商品化了，而置信度值才是每次部署都必须靠自己挣来的那部分。