Laya vs Kev：本地决策模型的两种方案

在 Laya 与 Kev 的对比中，最有用的数字是一张账单。Jared Palmer 在 Modal 上用 H100 时长训练 Kev 系列大约花了 95 美元，再加上用于评估数据的约三美分 API 调用费用，并将配方与权重一并发布。Convai Innovations 则对 Laya 采取了另一条路线：发布于 2026 年 9 月 18 日，比 TypeSafe AI 的 Jev 晚三天，Apache 2.0 许可，权重在 Hugging Face 上，一个 pip install laya 入口点，并且没有训练流程——一个 421M 的 ModernBERT-large 英语检查点、一个 322M 的 mmBERT-base 多语言检查点，以及一个在两者之间进行选择的路由器。Kev 是一个由三个小模型组成的系列，规模分别为 0.8B、4B 和 9B，每个都是冻结基座加上一个 rank-16 LoRA 适配器和一个小型指针头。两者都在一次前向传播中回答带类型的问题，且都不生成文本。在它们之间做选择，实际上是在选择你想拥有哪种产物：一个检查点，还是一份配方。

每个项目实际发布的内容

Laya 自带推理功能。英语检查点是一个双向编码器，窗口为 512 个 token；多语言检查点覆盖 100 多种语言，窗口为 1,024 个 token，运行速度约快一倍；路由器在不到半毫秒内即可检测书写系统。它回答 choice、score和noul——从列表中选择一项、在有序评分标准上给出预期等级，以及某个论断为真的校准概率。还有第三个检查点 laya-typed-decisions，它就是同一个 421M 主干模型，在 typed-decisions 基准的训练集划分上进行了微调。Convai 自家的模型卡上有这样一句话，它应当决定你如何解读每一个 Laya 数字：“Laya 是一个可供专门化的快速基座，而不是零样本决策引擎。”

Kev 发布了一种方法。该仓库记录了 decision-v7：在从十个公开数据集中抽取的 10,000 个样本、896 个生成的策略样本，以及由 60 个生成的规则结构构建的 1,680 个样本上进行两个 epoch 的训练。输出头会针对问题的 decide token 为每个提供的选项打分，并对结果做 softmax。由于 Qwen3.5 检查点将注意力与忽略注意力掩码的循环 Gated DeltaNet 层混合在一起，每个问题都作为独立的一行运行，共享状态只计算一次并缓存——模型正是借此让问题彼此隔离，而无需为每个问题付出一次全新预填充的代价。Kev 镜像了 TypeSafe 公开的 /v1/systemone 契约，因此现有的 TypeSafe SDK 客户端只需更改基础 URL，就能指向本地的 Kev 服务器。README 声明训练中未使用任何 Jev 输出。

这两种故障模式是不同的，而这才是真正的关键所在。

两个模型在需要知识储备的任务上都败给了Jev，但它们失败的方式不同，需要采取不同的缓解措施。

Laya 已公布的弱点与输入的形态有关。在 TypeSafe 的 typed-decisions 基准上，它的零样本得分为 0.362，而随机猜测为 0.318，多数类基线为 0.461——更接近随机水平，而不是那个平凡答案。当选项超过大约二十个时，它就崩溃了：在 Banking77 上为 0.425，而 Jev 为 0.870。它对顺序足够敏感，以至于在一项第三方测试中，仅仅颠倒选项顺序就让准确率下降了 13.75 个百分点，只留下 42.5% 的答案一致率。而且随附的检查点带有无效的温度参数——库在导入时会发出警告，这意味着模型卡上的校准数值，即 0.466 的预期校准误差，正是你在重新拟合之前实际得到的数字。按问题类型重新拟合会将其改善到 0.081，但那是你要做的工作，而不是下载内容会做的工作。还有一个已公布的多语言失败案例值得完整阅读：在非拉丁文字上，英语检查点灾难性地过度自信，一个高棉语示例显示准确率为 0.000，而平均置信度为 0.952。

已公布的 Kev 弱点在于知识与算术。Kev-9B 在其自身锁定的新来源测试上得分为 0.837——4B 为 0.832，0.8B 为 0.668——在开发集划分上的域外得分约为 0.822，而 Jev 为 0.857。差距在需要世界知识的地方显现：MMLU 约为 70%，而 Jev 为 90%；MMLU-Pro 为 0.515，而 Jev 为 0.840；日精度日期算术为 60%，而 Jev 为 93%。在一个窄范围的固定标签路由集上，Kev 胜出——一项支持工单路由评估显示 Kev-9B 为 0.952，而 Jev 为 0.897——但作者明确指出，这是他自己的评测框架，Jev 的训练数据未披露，因此无法构建受控比较。Kev 在新来源上也仍然过度自信；设置 KEV_TEMPERATURE=2.0在项目自身的测试中将自信错误从 8.7% 降至 4.4%，这说明默认值并非安全设置。

实际解读是：Laya 的失败由你的选项集和提示词格式触发，靠微调和重新拟合来修复。Kev 的失败由需要事实的问题触发，靠把模型限定在路由和分类上、把依赖知识的调用放到别处来修复。这两种修复都不是一个配置开关。

为他们服务需要什么

• 硬件 — Laya：421M/322M 编码器，在低吞吐量的 CPU 场景下表现可信，且 Apple 芯片上的 MLX 移植版常驻内存不到 1GB。Kev：0.8B 到 9B，其中 9B 需要 BF16 CUDA GPU，而 Qwen3.5 架构需要 flash-linear-attention在 CUDA 和 ROCm 上。

• 延迟 — Laya：在 Tesla T4 上，每次决策的 p50 为 32.8 毫秒，批次大小为 10 时每个问题为 7.2 毫秒。Kev：在 32GB Mac 上以 bf16 运行 4B 模型，处理五个键入的问题约需 300 毫秒，在 H100 上大约为 40 毫秒。

• 上限 — Laya：512 个 token 的英文窗口，多语言为 1,024 个。Kev：可从 1–255 个选项中选择，可对 2–255 个级别评分，训练状态为 384 个 token，服务时为 8,192 个。

• 服务器 — Laya：进程内 Python，以及社区维护的 ONNX、Go 和 Apple MLX 移植版本。Kev：一个绑定到 127.0.0.1、无需身份验证的本地服务器，带 npm SDK，以及 LangChain 和 LlamaIndex 适配器。

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

两条未出现在核心数字中的运维说明。Kev 的服务器按设计仅支持单请求且无认证——它是一个本地 sidecar，不是你应该对外暴露的东西。而且 Kev 的 Mac 延迟明显比其 H100 延迟更差，因为快速的 DeltaNet 内核目前还没有针对 MLX 的实现，而这正是那种会把“本地就能运行”的说法变成“在合适硬件上本地就能运行”的说法的细节。

模式中生成性的一半

这两种模型的存在，都是为了替代一个特定调用：你纯粹为了拿回一个标签或一个概率而进行的 LLM 调用。它们并不能替代那些你确实需要成段文字的调用。一个使用 Kev-9B 来路由工单的支持系统，仍然需要一个模型来总结讨论串并起草回复，而那个模型不会是带指针头的 9B LoRA。

这正是 OrcaRouter 所处的那道接缝，而不是关于托管这两者中任何一个的说法。Laya 和 Kev 都不在我们的模型列表上——它们是你自行下载的权重——如果文章暗示并非如此，那就会产生误导。列表上的是 200+ 个生成式模型，它们都位于一个 OpenAI 兼容密钥之后，以供应商目录价原样透传、0% 加价。如果你用 Kev 来判断一个请求属于三个摘要层级中的哪一层，或者用 Laya 来评估一份草稿答案是否可接受，那么这两个回路中生成侧的部分就只是一个带自动故障转移的端点，而无需再签一份合同、再接入一个 SDK。路由 DSL 是最自然契合决策模型架构的那一环：把便宜模型和昂贵模型组合进一次调用，让决策模型的输出来选择分支。

接下来看什么

证据上的缺口对两者而言是一样的，而且两个项目都不会把它补上。没有人用逐字节完全相同的输入、相同的提示词、相同的选项顺序和相同的置信度阈值扫描来运行 Laya 和 Kev。Laya 的主要胜绩来自它自己的评测框架；Kev 的接近持平的说法来自其作者自己的评测框架；而那项发现 Jev 的校准随任务急剧变化的校准审计——在隐藏策略优先级任务上准确率为 44.7%，期望校准误差为 0.325——是由第三方完成的，Laya 和 Kev 都没有接受过这种检验。在有人这样做之前，上面的数字是现有最好的，但它们彼此之间不可比较。

如果你今天就要做决定：如果你希望本周就能在你已经租用的 GPU 上跑起一个可用的路由模型，那就选 Kev，并接受它会有不知道的事情。如果你的输入是多语言的，或者你的硬件预算只是一台笔记本电脑，那就选 Laya，并把微调作为项目的一部分来规划预算，而不是把它当作事后的优化。无论选哪个，在把置信度阈值放到生产流量之前，都要先在你自己的标注数据上进行测量——这两个项目在各自的文档里都这样告诉你。