开源决策模型 Laya：33 毫秒出结论、零成本且数据不出域

工单分流这种事，为什么还在请大模型出场

先还原一个每天都在发生的场景：客服工单进来，系统要判断分给账单组还是技术组；用户邮件进来，要判断紧不紧急、有没有流失风险；请求进来，要先过一遍提示注入检查。这些判断的共同点是——答案就在一个固定的小集合里，不需要任何创作。

但多数团队的现状，是把这类判断一股脑丢给几十亿参数的大模型：模型逐字生成一段答复，你再从答复里把标签抠出来。一笔「是不是重复扣款」的判断，等几百毫秒；偶尔模型还自由发挥，吐出带解释的废话或半截 JSON，逼你在下游再写一堆防御性解析。

2026 年 9 月，GitHub 上一个叫 Laya 的开源项目五天冲到两万多 Star，就是因为它把这件事做对了：4 亿参数的小模型，不生成任何文字，一次前向传播直接返回结构化结论和校准概率，T4 显卡上单次判断约 33 毫秒，权重 Apache-2.0 随便部署在自己机房——而它对标的闭源商业产品 Jev，单次判断要两三百毫秒，还按 token 计费、数据要出域。

这篇文章把 Laya 的原理、部署、微调、坑点一次讲透，最后给你一张「该不该用」的决策表。

项目档案：先把关键事实摆清楚

背景多说一句：TypeSafe 的商业产品 Jev 是这类「毫秒级判断器」的开创者，但只提供云端付费 API、权重不开放。Laya 的作者声称自己更早提出过同类构想，9 月 18 日把完整权重开源出来，一周内在 Hacker News 冲上首页并收获两万多 Star——社区最买账的一点是：这个概念从此没法被专利锁起来了。

凭什么 33 毫秒：不生成文字，直接打分

要理解 Laya 快在哪，得先看清大模型慢在哪。Qwen、DeepSeek、GPT 这类模型是自回归的：推理时一个 token 接一个 token 串行生成，哪怕答案只是一个类别词，也要走完整个生成周期。而 Laya 走的是判别式路线：

• 骨干是 ModernBERT 这样的双向编码器，输入文本（状态）和待判定的问题一起喂进去，每个 token 同时可见前后文；
• 每个候选选项在末层各占一个独立打分位，一次前向传播输出所有选项的分数，Softmax 归一成概率分布——这就是 33ms 的来源；
• 没有逐字生成，自然没有「等第一句话吐出来」的等待，也没有幻觉和解析问题。

官方把它叫 System 1（系统一）：快、直觉、专门做判断。需要推理、写方案、写代码的活儿，仍然交给大模型——Laya 的位置是在大模型前面，先把能秒判的事拦下来。

三种决策原语：choice、score、noul

Laya 的问题格式只有三种，但覆盖了绝大多数业务判断：

同一个状态下可以塞多个问题，走同一次前向全部算完——多语言版 10 个问题约 72ms，摊到每题 7ms 左右，这是它在大模型面前最碾压的场景。

和 Jev 的真实对比：快是真的，但要看条件

「快 7 倍」是怎么来的：第三方实测 Jev 1.13 单题延迟中位数约 236~276ms，Laya 单题约 33ms，同一口径下大约快 6~8 倍。注意这是不同机器、不同网络下的公开数字，不是同卡对测。更完整的对比表：

三个 Laya 落后于 Jev 的场景必须记牢：高基数标签（超过 20 个选项准确率明显下滑，Banking77 就是例子）；多问题大批量（Laya 延迟线性涨，Jev 摊薄后每题 3ms）；并发吞吐（32 路并发时 Jev 约 72 条/秒，Laya 顺序约 24 条/秒）。

60 秒跑起来：安装与最小示例

硬件门槛不高：建议 6GB 以上显存显卡 + 16GB 内存，Linux/macOS 均可，CPU 也能跑（但单问约一秒，只适合批处理）。安装一行：

pip install laya
# 国内拉权重前先配镜像
export HF_ENDPOINT=https://hf-mirror.com
export HF_HUB_DISABLE_XET=1

官方推荐入口是 Router——它自动识别输入语种并调度到对应权重，不用手动挑模型：

from laya import Router

router = Router(device="cuda", preload=True, max_loaded=3)

state = "Hi, we were billed twice for March. Please refund the duplicate today or we will cancel our plan."

questions = {
    "department": {
        "type": "choice",
        "instructions": "Which department should handle this?",
        "criteria": {
            "billing": "invoices, payments, refunds",
            "technical": "bugs, outages, system errors",
            "other": "everything else",
        },
    },
    "urgency": {
        "type": "score",
        "instructions": "How urgent is this?",
        "criteria": ["not urgent", "soon", "blocking"],
    },
}

result = router.predict(state, questions)
print(result["answers"]["department"]["choice"])   # billing
print(result["answers"]["department"]["probabilities"])  # 各项概率
print(result["routing"]["model"])                  # 走了哪个分支

返回是标准 Python 字典：choice 直接可读、probabilities 是归一化概率、confidence 是校准后的置信度——没有半截 JSON，没有要抠的正则。

部署到 1Panel / Docker：放进你的内网

视频里演示的 1Panel 路线很简单：仓库自带 docker compose 文件，在 1Panel 的「容器 → 编排」里新建项目、粘贴 compose 配置启动即可，服务起来后就是标准 HTTP 接口。想用现成镜像的也可以直接起容器：

docker compose up -d   # 用仓库自带的 compose 文件
# 服务暴露 POST /v1/systemone，报文与 Jev 托管接口一致

关键点是 Jev 兼容：HTTP 服务返回结构与 Jev 的 choice/score/noul 完全一致，官方称现有 Jev 客户端把地址指到自己服务器上，几乎零迁移就能切换。对已经在付 Jev 账单的团队，这是一条成本几乎为零的评估路径。量化一下省多少：Jev 输入约 0.042 美元/百万 token，高流量分诊场景一个月几百美金的调用费，换成本地一张 T4 的电费——这笔账我们在自建显卡大模型 vs 收费大模型里算过，决策层场景自建的优势比生成类场景大得多。

零样本接近瞎猜：微调才是分水岭

这是全文最重要的一节，也是宣传数字里最大的坑。官方模型卡写得很直白：底模零样本在 typed-decisions 上准确率只有 0.362，接近随机基线 0.318，甚至低于「永远猜最常见的类」的 0.461。网上流传的 0.766 是在基准训练集上微调之后的成绩。

换句话说：Laya 出厂时是一个「很快的、值得微调的底座」，不是开箱即用的决策引擎。好在微调路径是铺好的：官方提供 Kaggle 免费 2×T4 的全流程 notebook，大约 4~5 小时跑完：

• 用自有数据构造训练集（几千条标注即可起步）；
• 训练 4 个 epoch（约 3 万道题）；
• 温度重拟合——这一步别省，底模出厂置信度偏自信（校准误差 ECE 0.213），按问题类型拟合温度后可降到 0.081；
• 评估、推送 HuggingFace，形成自己的私有 checkpoint。

微调后的提升是实打实的：发票处理 0.804、安全事件 0.766、客服分诊 0.764、智能体轨迹观测 0.730，四个流程全部超过 Jev。

置信度门控：让 33ms 真正省下大模型的钱

Laya 的训练方法叫 RLCD（面向校准决策的强化学习），奖励来自严格恰当评分规则——模型想拿高分，唯一的方式是报出接近真实频率的概率。所以它的 confidence 是有统计意义的，可以拿来当门控：

• 置信度高于阈值（如 0.90）→ 自动执行，33ms 完事，零成本；
• 中间区间（如 0.70~0.90）→ 升级给大模型兜底判断；
• 低于阈值 → 转人工复核。

注意上面是示意阈值，必须在自己的标注集上回归，别照抄。另外官方提醒：返回体里的 action.act_probability 字段目前几乎恒为 1.0，做门控请只认 confidence。这套「快模型放行 + 大模型兜底 + 人工收尾」的分层，正是把大模型调用成本压下来的标准架构。

五个官方点名的失败模式，上线前必测

• 否定句不保险：一组明确写「不要取消账户」的请求，英文检查点全部判成「取消」，其中一条概率 0.9998——错得很自信。上线前用你自己的否定句测一遍；
• 单选标签别用 yes/no/true/false：模型可能跟着标签走而不是跟说明走，用有语义的标签或 A、B；
• 是非题标签陷阱：noul 的 false/true 标签有时压过正文，明明肯定句也报「否」，可改用两个中性标签的单选题；
• 打分题最弱：SST-5 情感五级只有 0.372，序数打分普遍不如类别选择可靠，能用 choice 就别用 score；
• 长文本要显式加预算：多语言版默认只看 1024 token，长文要传 max_len=8192 或先摘要切片，正文约 4000 token 时 20 条能对 16~18 条。

中文场景要额外当心的一件事

Laya 宣称支持 100+ 语言，但中文不能直接外推。仓库的合成评测（64 个场景、4 个均衡标签）里，零样本多语言底模单选只对 20/64，Jev 是 64/64。输入是合成句、硬件也不同，这个数字说明的是「零样本中文分流先别当真」，不是「不支持中文」——真要用，走微调。另外 Router 的语言检测必须在进模型前完成是有原因的：英文检查点在高棉语上准确率为 0、置信度却有 0.95，它错得很自信，靠置信度门槛拦不住，所以别手动绕过 Router 硬指定英文分支处理中文。

如果你要的是中文生成类任务的本地部署，Laya 不是那类工具，看这篇本地大模型选型与硬件配置更对路；生成 + 判断混合的场景，正确姿势是 Laya 做前置分流、大模型做后端生成，接入方法参考OpenClaw 配置大模型 API 指南。

什么场景值得上，什么场景别碰

给企业 IT 团队的落地建议：拿 50 条真实工单先跑一遍零样本看差距，再决定要不要投入标注和微调——这一步不花钱（Kaggle 免费 GPU），但能避免为错误的场景搭整套管线。评估中遇到数据合规、内网部署或阈值设计的问题，可以直接找我：17712677007（峰哥）。

FAQ

Q：33 毫秒是所有硬件都能达到吗？
A：不是。32.8ms 是 Tesla T4 上多语言检查点单问题 p50，项目方公布的基准数字。CPU 上单问约 0.8~1.3 秒，浏览器 ONNX 版也差不多，无 GPU 只能做批处理。

Q：它会不会取代大模型？
A：不会，它们是分工关系。Laya 只做有界判断（选择、打分、是非），生成类任务（写回复、做摘要）仍然是大模型的领地。正确的架构是 Laya 在前分流，把大模型的调用量砍到只剩真正需要的部分。

Q：准确率 0.766 我能直接期待吗？
A：不能。那是微调版在特定基准上的成绩。你的场景要从微调开始，且阈值、温度都要在自己的数据上重新校准。

Q：显存不够怎么办？
A：Router 三套权重常驻约 4.4GB；如果业务只用单一语言分支，改用 Agent 直调锁定单分支，实测显存降到约 1.25GB。

Q：可以商用吗？
A：Apache-2.0，可以商用、可以修改后闭源分发，保留协议声明即可。这也是它和 AGPL 系项目的关键区别。

最后总结一句：Laya 的价值不在「快 7 倍」这个数字，而在它把判断和生成拆开了——判断这件事本来就不该逐字生成。33 毫秒、本地部署、概率可校准，让它第一次成为大模型前面那道便宜又可靠的分流闸门。当然，先微调，再上线。