
Laya 解析:一个无需生成任何 Token 即可作答的决策模型
- openai新OpenAI: GPT-6 Luna2026-09-2237智能
- openai新OpenAI: GPT-6 Sol2026-09-2248智能
- anthropic新Anthropic: Claude Opus 5.52026-09-2258智能
- grok新Grok 4.72026-09-2146智能
- Orca新Orca: OrcaCyber Zero 1.02026-09-17$3.00 / $5.00 每百万 tokens
- orca新Orca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 每百万 tokens
- deepseek新DeepSeek: DeepSeek V4.1 Flash2026-09-1040智能
- openaiOpenAI: GPT-6 Astra2026-09-0453智能77代码
- googleGoogle: Gemini 3.8 Flash2026-09-0241智能76代码
- qwenQwen: Qwen3.8 Max (0902)2026-09-0245智能76代码
- anthropicAnthropic: Claude Fable 5.12026-09-0153智能82代码
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 每百万 tokens
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642智能72代码
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 每百万 tokens
- z-aiZ.ai: GLM 5.32026-08-1845智能75代码
- obsidianQwen3.8 27B2026-08-1534智能68代码
- deepseekDeepSeek: DeepSeek V4 Pro 08132026-08-1236智能69代码
- grokSpaceXAI: Grok 4.62026-08-1244智能77代码
- metaMeta: Muse Spark 1.22026-08-0540智能72代码
- qwenQwen: Qwen3.8 Max2026-08-0345智能76代码
Laya 最有趣的地方不在于它的速度,而在于你交给它的每一个选项都会在各自的 [MASK] token 处被打分,随后概率会在那一个问题所对应的选项上做 softmax。Convai Innovations 于 2026 年 9 月 18 日在 Hugging Face 上以 Apache 2.0 许可发布了 Laya 的权重——三个检查点,一个仓库,英文模型有 421M 参数。它没有输出 token。没有解码循环,没有需要解析的 JSON,没有会忘记闭合的花括号。你交给它一个状态和一组带类型的问题,一次前向传播之后,你就能得到对具名选项的选择、带期望等级的序数分数,或某个陈述为真的概率。这种设计有一个人们常忽略的后果:由于答案空间是按每次请求临时组装的,而不是固化在词表头里,所以你今天下午临时想出来的模式无需重新训练。它也有一个局限,项目在自己的模型卡上直言不讳:基础检查点在类型化决策基准上得分为 0.362,而随机猜测为 0.318,始终回答多数类则为 0.461。Convai 自己那句话值得你牢记——“Laya 是一个便于专业化的快速基座,而不是零样本决策引擎。”显而易见的对比对象是 TypeSafe AI 的 Jev,一个托管式的 System One 模型,没有公开权重、没有公开参数量,也没有公开基础模型。Laya 就是针对它的开放权重答案。这个答案对你是否有用,几乎完全取决于你想替换的是这条流水线的哪一半。
Laya 实际上是什么,以及它不是什么
先从否定说起,因为大多数介绍文章正是在这里出错。Laya 不是 LLM。它是非自回归的:一次前向传播就能产生答案,模型从不输出文本。把它的延迟与聊天模型的每秒 token 数相比,是在比较两种不同的操作——一种做分类,另一种做生成。如果你需要一段文字、一份摘要、一个计划或一条推理链,Laya 给不了,也无意提供。
它是什么:一个双向编码器,顶部加装了一个决策头。英文检查点是 ModernBERT-large——3.95 亿参数,完全微调——外加一个从零训练的头,由两个 Transformer 层、一个选项标记评分器和一个行动/升级头组成,总计 4.21 亿。多语言检查点将主干网络替换为 mmBERT-base,22 层、25.6 万词表,总计 3.22 亿。同一个仓库中提供三个检查点,且只下载你请求的那一个:
• convaiinnovations/laya — ModernBERT-large,4.21 亿参数,512 token 上下文,英语,磁盘占用约 808 MB。
• convaiinnovations/laya-multilingual —— mmBERT-base,3.22 亿参数,1,024 token 上下文(编码器配合 RoPE 最高支持 8,192),支持 100 多种语言,速度约快 2.2 倍,体积约 647 MB。
• convaiinnovations/laya-typed-decisions — ModernBERT-large,4.21亿参数,1,024 token 上下文,并且是三者中唯一带有那个到处被引用的 0.766 数值的模型。
一个路由器位于最前端,在每次请求时,通过检测文字系统和语言,在不到半毫秒内(纯 Python 实现)选择检查点,这一切发生在任何前向传递之前。这并非便利功能。这是正确性功能,项目自身的证据也说明了原因:英语检查点在高棉语上的准确率为 0.000,却报告了 0.952 的置信度。一个完全错误却保持自信的模型,正是置信度门控无法拯救你的情形,因此路由决策必须在模型看到输入之前做出。在覆盖 51 种语言的扫描中,路由器使 51 种语言中的 45 种变得可用——定义为超过随机三倍——而仅使用英语检查点时只有 51 种中的 23 种可用。

值得理解的设计事实:每个选项对应一个 [MASK] token
如果这篇文章你只能带走一件事,那就带走这一点。在普通的分类头中,标签集在训练时就是固定的:最后一层为每个类别输出一个结果,而要新增一个类别就意味着重新训练。Laya 并非如此。它把每个选项渲染成带有标记的文本,选项标记评分器则从该选项自身的[MASK] 位置读取得分。随后,它在该问题所对应的各个选项之间做 softmax。
因此,答案空间是在请求时定义的。你编写选项,模型对它们进行评分。新的模式不需要重新训练,也不需要微调,因为权重中没有任何东西将“计费”或“技术”编码为一个类别——只有用于在状态上下文中将一个渲染后的选项与另一个进行比较的机制。
有两个预算共同决定着它的效果好坏,而且这两个预算是共享的。每条序列都会拆分成一个选项提示预算(head_max_len,在英语检查点上为 192 个 token,在另外两个检查点上为 256)以及一个文档预算(即 max_len 的剩余部分)。一次调用中的每个问题都在同一次前向传播中作答,所以一次包含六个问题的调用并不是六次模型调用。但所有选项共享同一个选项预算,这正是为什么像 Banking77 这样一个有 77 个选项的问题,每个标签大约只能分到三到四个 token,准确率随即断崖式下跌——0.425,而 Jev 公布的成绩是 0.870。修复方法是有文档记录的,而不是被隐藏起来的:调高 head_max_len 和 max_len,或者把庞大的选项集拆分成两步式的由粗到细选择。
三个原语
Laya 所做的一切都属于三种问题类型之一,并且每种都会返回不同的形状:
• 选择 — 为每个命名选项提供一个概率,并附带最高标签和置信度。这是路由与意图分类的基础原语。
• 分数——在有序评分标准上的分布,外加一个预期等级。这是有序型原语:紧迫性、挫败感、严重程度。
• noul —— 一个经过校准的概率,表示某一陈述为真的可能性,取值从 0.0 到 1.0。网络钓鱼、流失风险、提示注入。
这些类型很严格,而且这种严格在运营上很重要。一个选择题不可能返回你未提供的选项,因为它唯一能评分的选项就是你渲染出来的那些。这消除了一整类生产故障——凭空捏造的枚举值、被截断的 JSON、围绕解析器的重试循环。它并不能消除语义错误。一个模型若返回 billing: 0.94,而这张工单本应转到技术支持,那就是错的,而且错得很自信。类型化输出保证的是答案的形状,而绝不是其正确性。
RLCD,或者说为什么概率本应是有意义的
大多数分类器的训练目标是追求正确。Laya 的训练目标则是诚实面对自己有多正确,而这一点正源自其训练方法。
该方法名为 RLCD——校准决策强化学习。策略输出的是分布,而不是 argmax;探索会向 logits 中加入零均值高斯噪声;奖励则是一个严格适当评分规则——对数评分加球面评分,对于有序问题还会加入排序概率评分。“适当”这个词才是关键。严格适当评分规则只有在报告真实信念时,其期望才最大,因此,含糊其辞或过度断言会因机制本身而非指令而损失奖励。更新采用带组均值基线的 REINFORCE,风格类似 GRPO;多轮对话则在前缀切片上使用 TD(λ=1.0)。
实际结果是,置信度阈值是一个可以基于其构建应用逻辑的有意义依据——而这是你不能对来自交叉熵训练分类器的 softmax 作出的断言。这个说法也有一个项目坦承的注意事项:随附的检查点过于自信,在信任这些数字之前,你应该在自己的数据上重新拟合温度。按问题类型和选项数量分别重新拟合一个温度后,英语检查点上的平均 ECE 从 0.466 降到 0.081,多语言检查点上的平均 ECE 从 0.314 降到 0.106。项目建议的自动批准与人工审核之间的起始阈值约为 0.85。
运行成本是多少
这些延迟数据均来自项目自身,是在 Tesla T4 上测得的;在同一次运行中,每个检查点回答的都是字节完全相同的问题:
• 一个问题 —— 39.5 ms,在 laya 上;32.8 ms,在 laya-multilingual 上。
• 五个问题——84.5 毫秒和 40.1 毫秒。
• 批量处理十个问题——158.6 毫秒(每个问题 15.9 毫秒)和 72.3 毫秒(每个问题 7.2 毫秒)。
• 五十个问题——771 毫秒和 337 毫秒,即多语言检查点上每个问题 6.8 毫秒。
• 单块 T4 上的批量吞吐量——每秒 103 到 332 个问题。
如果你看到过流传的“比 Jev 快 50 倍”的说法,那不是该项目的数字,而且该项目自己的基准测试也不支持它。Convai 公布的对比结果是,针对一个问题,其 p50 延迟为 7.8 倍:32.8 毫秒对 236–276 毫秒。这个对比也需要仔细阅读,因为 Laya 的卡片将 Jev 一方标记为 Convai 从未测量过的第三方公布数据——它没有 TypeSafe API 访问权限——并且因为它将本地 GPU 前向传递与包含网络往返和排队的托管 API 调用进行了对比。这一差距中的架构部分是真实存在的。其中的基础设施部分并非模型本身的属性。
在内存方面,每个检查点的占用为几百兆字节,在确定主机规格之前,部署表值得先了解一下。默认的惰性策略会让两个检查点常驻内存(英语和多语言,这是路由器会自动在两者之间进行选择的仅有两者),因此在每种语言首次加载后,切换只需付出检测的开销。在内存受限的机器上,Router(max_loaded=1) 会在每次切换语言时重新加载,在 CPU 上测得中位数为 7.4 秒,在 T4 上为 10.3 秒。Router(preload=True) 是服务器配置:不会重新加载任何内容,每请求延迟为 GPU 上的 32.8 毫秒,或 CPU 上的 193–464 毫秒。
诚实的那一半
这正是它体现价值之处,因为 Laya 周边的面板足够喧闹,而其局限也十分具体。
首先,最显眼的数字是一个微调后的数字。0.766 的准确率属于 laya-typed-decisions,那个在该基准自身训练划分上微调过的检查点。基础检查点零样本得分为 0.362 和 0.342,而随机基线为 0.318,多数类基线为 0.461——换句话说,低于最朴素的基线。项目在自己的局限性清单中说明了这一点,而不是把它埋起来;而且微调后的检查点突破了 0.735 的教师自一致性上限,对于一个在四个狭窄工作流上运行的 421M 编码器来说,这确实是很强的结果(发票处理 0.804,安全事件 0.766,客户服务 0.764,智能体轨迹可观测性 0.730)。但这是一个关于专业化、而非关于基础模型的结果;任何把 0.766 引用为通用能力的人,都是在误读模型卡。
其次,这些原语并非同样出色。就微调检查点上的准确率而言:noul 0.857,choice 0.733,score 0.723。该项目直接把序数 score 称作“最弱的原语”,其 SST-5 仅为 0.372。如果你的决策面是 1 到 5 的严重程度评分,那么它就是你开箱即用时最没有理由信任的那个原语。
第三,有两种行为在项目自己的 issue 跟踪器中被记录为 bug,如果你不读它们,两者都会在生产环境中把你坑惨。action.act_probability 目前还无法携带可用的信号——issue #185——因为决策头的输出未归一化,其尺度约为编码器的 300 倍,这会使 act 头饱和,从而对几乎每个输入都读出 1.0。它的原始 logit 与正确性背道而驰,在 396 个带标签的决策上 AUROC 仅为 0.30。请改为以 confidence 为准,它在同样的条目上能达到 0.77 的 AUROC。另外,noul 可能会跟随自己的选项标签,而不是状态——issue #156——因为 render_options 把 noul 的标签硬编码为 false: / true:,而这对标签可能会主导答案,对明显为正的输入返回一个自信的 "no"。文档中记录的变通方法是,把同一个问题作为一个双选项的 choice 来提问,使用中性的键,并把你的 yes/no 措辞作为描述。
第四,还有一个容易忽略、值得精确说明的校准细节。检查点针对 choice:11+ 分桶附带的拟合温度为 0.1006,而加载器会把所有温度强制夹取到 [0.5, 5.0] 区间内。这个夹取其实是在帮你。如此尖锐的温度,可能会把一个真正存在分歧的分布报告成近乎确定;有了夹取,最坏情况也只是给出比拟合本意更温和的答案,同时加载器会发出警告,指明受影响的桶,并告诉你把该置信度视为未经校准。加载时请阅读这些警告,而不是把它们屏蔽掉。
第五,仓库根目录仅支持英文,而在非英语环境下的失败模式并不优雅——因此才有了路由器,也因此建议对任何非英语散文使用laya-multilingual。
独立评测所呈现的图景(在存在的情况下)比厂商自己的描述更窄,且并不与后者相矛盾。一项独立的正面较量——sysone-bench,覆盖九个套件、751 个状态,日期为 2026-09-21,在字节完全相同的输入上运行,比较前已验证问题哈希完全一致——结果显示,Jev 在 triage、guardrails、moderation、banking77 和多语言意图上领先,Laya 则在 AG News(0.940 对 0.910)和 MNLI(0.983 对 0.867)上领先。其置信度门控的结果才是我真正会据此规划的:以 0.85 置信度进行门控时,Laya 以 0.878 的准确率保留了 58% 的流量,而 Jev 则以 0.917 的准确率保留了 78%。这就是这笔权衡的形态——Laya 自动处理的流量更少,且在其保留的那部分流量上准确率更低;而它自家的路由器运行将多语言意图从 0.360 提升至 0.840。
它周围的表面,异常宽阔
对于一个权重只有几天历史的项目来说,集成接口才是令人意外的地方。NandhaKishorM/laya 中,撰写本文时它在 GitHub 上已有 19,871 颗星,并且全程采用 Apache 2.0 许可:
• laya-serve — 一个 HTTP 服务器,它暴露 Router,并使用与 TypeSafe 托管的 Jev API 相同的 POST /v1/systemone 请求和响应结构,因此现有 TypeSafe 客户端只需更改其基础 URL 即可迁移。诚实说明安全默认设置:它绑定 0.0.0.0,且不进行身份验证,除非 设置了 LAYA_API_KEY,此时它要求 bearer 令牌。存在一个加固的 NixOS 模块变体,它运行在 DynamicUser systemd 单元下,并通过 LoadCredential 传递令牌,而不是将其放入存储中。
• 完整的 TypeScript 移植版本,位于 laya-ts/ 中,适用于 Node 和浏览器,另有一条 ONNX 智能体路径(laya.onnx_agent.ONNXAgent),用于在运行时无需 PyTorch 即可在 ONNX Runtime 上运行导出的模型。
• 一个位于可选附加组件之后的 MCP 服务器,将laya_predict、laya_route、laya_preset 和 laya_status 作为工具公开。
• LangChain 和 LangGraph 集成 — 用于带置信度阈值和回退机制的条件边路由的 LayaRouter,以及 LayaGuardrail。
• 一个 Nix flake,包含 nix run .#laya-serve 以及一个 services.laya-serve 模块、四个 compose 文件、一条附有文档化快速入门的 Docker 镜像路径,还有一个 Kaggle notebook,可在免费的 2xT4 GPU 上,用四到五个小时,针对约 3 万个问题运行完整的 RLCD 微调循环。

Apache 2.0 正是决定你能否将其作为产品的一部分进行发布的关键许可细节:它允许商业使用、修改和再分发,且不要求你公开自己的改动或微调后的权重。其义务就是通常的署名与保留声明义务,此外还有一点很明确:除许可证本身所声明的内容之外,不授予任何专利或商标许可。对于一个位于客户流量之前的决策层而言,这与一个抢先体验版的托管端点有着实质性的不同——后者的权重、架构和训练配方全部未公开,而这正是今天的 Jev:每百万输入 token 收费 0.042 美元,输出免费,且输入界面仅支持文本。
它实际适合的位置是:前面一个决策头,后面一个路由式 LLM
值得内化的模式并不是“用决策模型取代 LLM”。它是一条两阶段流水线,而两个阶段之所以都存在,是因为另一方在某件事上表现不佳。
把 Laya 放在前面,处理高频、狭窄、机器可处理的判断:路由工单、分类意图、对紧急程度打分、判断这份文档是否与查询相关、检查这份草稿是否违反策略。这些调用有固定的答案集,每小时发生数千次,而一次 33 毫秒、零输出 token 的本地前向传递比生成式往返更适合它们。然后在其后放置一个生成式模型,用于真正需要成文、综合或长上下文推理的调用——起草、解释、升级摘要。
这正是 OrcaRouter 所处的位置,而这里的边界值得说清楚。我们不提供 Laya;它是一个你自己运行的 421M 编码器,其全部意义就在于它运行在你的数据已经所在的地方。我们也不提供 Jev——它是 TypeSafe 的抢先体验端点。我们覆盖的是同一条流水线的生成那一半:一个 OpenAI 兼容密钥背后的 200+ 个模型,价格按提供商标价透传,0% 加价,并支持跨提供商自动故障转移。这里真正重要的实际原因,是两半之间的接缝。一旦你开始把决策头拒绝处理的情况路由到生成式模型,你就会多出第二个集成、第二份账单和第二种故障模式。生成侧只需一个密钥,并在提供商降级时进行故障转移,这意味着决策层的升级路径只是一次配置变更,而不是建立第二段供应商关系。这是个很小的说法,而它是真的。
谁应该采用它,谁应该等待
如果你有标注数据和训练循环,并且决策面足够稳定、值得专门化,那就现在就采用 Laya。Kaggle notebook 的存在正是为了让微调步骤不是一个研究项目,基础检查点在 CPU 上大约两秒即可加载,而且许可证允许你商业化发布结果而无需公开权重。最合适的工作负载是项目已经做过基准测试的那些:工单分诊、发票处理、安全事件分类、护栏与审核,以及智能体轨迹可观测性。将选择题保持在约 20 个选项以内,在生产环境中设置阈值之前,用自己的留出数据校准温度,并基于 置信度,而绝不基于 act_probability。
如果你的决策必须开箱即用,且没有标注数据,那就要先等等。一个基础检查点在其发布所对照的基准上还低于多数类基线,这不能算零样本引擎;而对厂商与独立评测数字的诚实解读是,目前运行良好的托管决策 API 才是更强的零样本选择。如果你的选项集很大,而你又不愿意调整头部预算,如果你的序数评分需要立即可信,或者如果你需要图像、音频或长文档输入,也同样先等等——Laya 仅支持文本,其上下文预算默认是 512 到 1,024 个 token,这只能选取证据片段,而无法容纳整份文档。
决定这个类别的不会是延迟数字——它们已经足够好,不再是争论点。关键在于:一个小模型,能在你定义的决策面上报告诚实的概率,并且你能用自己的标签重新训练它,这是否胜过调用一个大生成模型再解析其输出。Laya 是对这个问题的开放权重版本的一次可信的、首次严肃尝试——而它最多只有几天大,这正是理解以上全部内容的正确方式。基座是起点,不是产品。

