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

Laya 的模型卡里有一句话决定了这场比较，而这句话正是由打造 Laya 的人写下的。"Laya 是一个便于快速做专门化的基座，而不是零样本决策引擎。"Convai Innovations 于 2026 年 9 月 18 日发布 Laya，距 TypeSafe AI 推出 Jev 仅三天，采用 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，离随机比离这个平凡基线更近。

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 日推出，采用托管和早期访问模式，具有三种类型化原语——Choice（从你提供的列表中选择）、Score（在有序评分标准上打分），以及 Noul（一个带有校准概率的是/否断言）。所有问题都会针对状态的同一次共享读取进行并行评估，输出免费，因为没有输出 token，输入为每百万 token 0.042 美元。其架构、参数数量和训练算力均未披露，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，而按文档所述约 32,000 token 请求预算进行的最大规模调用，成本远低于一美分。Every 的独立测试在 37 份文档上完成了 777 项判断，成本约为四分之一美分。

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

还有第三个很容易被忽略的成本：Laya 的英文检查点有一个 512 个 token 的上下文窗口。那不是上下文预算很小的决策模型——而是一个按一段话规模设计的决策模型。Jev 约 32,000 个 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 的微调结果就是证明。

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

这两个模型都不生成文本，因此都不是任何工作流的全部。它们共同为之设计的模式是两个模型：一个做出类型化调用的决策层，以及一个处理需要散文、代码或解释的那部分内容的生成模型。OrcaRouter 不提供 Jev 或 Laya——Jev 是 TypeSafe 的早期访问端点，Laya 是你自行运行的权重——但该模式中的生成部分正是我们所覆盖的范围：通过一个 OpenAI 兼容密钥访问 200+ 个模型，按供应商标价原样传递，0% 加价，因此供应商价格变动当天就会在我们这边生效。双模型架构无需第二份供应商合同即可测试，并且借助自动故障转移，在你判断这个廉价决策层是否校准得足够好、可以据此实现自动化之前，生成路径不会成为单点故障。

裁决

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

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