我一开始也当成普通的新模型发布划过去了，直到看到一个数据：Vercel 公布 Jev 接入 AI Gateway 后 24 小时内，13% 的付费团队用过它，这是平台历史上采用最快的模型发布。一周之内，掘金、36氪、KDnuggets 全在讨论，GitHub 上冒出一整片衍生项目。一个"不生成文本"的模型做到这个声量，总有点东西，我决定花点时间把它扒开看看。
它到底在省什么钱
跑过 agent 的人应该有体感：一个 agent 执行任务时，真正花时间的大模型调用，大部分不是"写一段漂亮的代码"，而是"这个报错归网络还是归磁盘""用户这句话是不是在威胁退订""下一步该点哪个按钮"这种小判断。每一次都用 8B、70B 甚至旗舰模型去生成一段解释、再 parse 出一个标签，慢、贵，还有个更隐蔽的问题——
Laya 的 README 里有一句话让我印象很深，大意是：当 LLM 回答 "confidence": 0.95 时，它是在预测听起来自信的 token，不是在计算一个校准过的概率。这两个东西在流水线里完全是两回事：前者是生成，后者是统计。你拿生成的数字去决定"要不要自动执行这个操作"，等于把方向盘交给了一个很会说话的家伙。
System One 模型的解法是把输出钉死：非自回归，一次 forward pass，直接输出类型化结果——从给定选项里选一个（choice）、按评分档打分（score）、或者输出一个真实的 P(true)（noul）。没有 token 生成，就没有东西可解析，也没有东西可幻觉。Jev 官方定价 0.042 美元每百万输入 token，宣称延迟 70-500ms；第三方独立测出来的 p50 在 236-276ms。 顺带一提，Jev API 在 Vercel AI Gateway 上免费开放到 9 月 25 日，想赶这波热度的可以趁这几天。
一周冒出来的克隆家族
有意思的不只是 Jev 本身，是它周围一周内长出来的生态。9 月 20 日的 GitHub 日榜上，browser-use 的 jev-ultrafast 一天涨了 2725 星——它把 Jev 接进浏览器代理，Jev 负责每次"点哪个、选什么"，只有需要打字时才叫文本模型，官方演示里 7 秒找到一张 Google Flights 行程，17 次 Jev 请求，中位延迟 178ms。
极简派的玩法更野：一个叫 jevlike 的项目，纯 embedding 实现，整个项目 40KB；还有给 Apple 芯片写的 laya-mlx，本地推理，单次决策 7-14ms，零 output token。解释一下这个数字的含金量——普通聊天模型"选一个选项"要生成几十上百个 token，它一个都不生成。
而这里面做得最正式的，是 Laya：Apache 2.0 协议，三个 checkpoint，配套 benchmark 工具，pip 直接装。它的作者是 ConvAI Innovations 的 Nandakishor Mukkunnoth，这位的发布故事比模型本身还有戏剧性——他在 Dev.to 上写了篇文章，标题大意是"我一年前就做了非自回归决策模型，然后一个前沿实验室管它叫（新品类）"。按他的说法，2025 年 3 月和 9 月他就发过同思路的 paper，权重和数据集都开在 Hugging Face 上，结果 Jev 一出，最先被想起来的不是他。Laya 算是他的正面回应：一样的思路，全套开源。 9 月 18 日首发，我写稿这天刚更到 0.3.5。我把它装进了本地。
装包就先给我上了一课
得交代下环境：一台 2GB 内存、单核 CPU 的 Linux 容器，Python 3.13。 装包本身没费什么劲，坑都在后面。 pip 默认走的国内镜像，直接报 Could not find a version that satisfies the requirement laya——不是包不存在，是镜像还没同步今天刚发的 0.3.5，一个热度爆表的项目，国内镜像落后了一天。换官方源才装上。
依赖链也卡了我一下。Laya 的 README 写明 Python 3.10 起步，原因很硬：huggingface_hub 1.x、transformers 5.x、torch 2.14 这几个依赖全都要 3.10+。我镜像源拉到的 torch 是 2.12.1，比 README 声明的低了一档（后面会说我为什么先记着这个差异没重装），transformers 5.12.1。装完一看磁盘，CUDA 版 torch 顺手拖下来 6.5GB 的 NVIDIA 库——在一台没有 GPU 的机器上。
laya 0.3.5
torch 2.12.1 transformers 5.12.1 huggingface_hub 1.24.0 python 3.13.15
包本身倒是很轻，wheel 只有 41.7KB——模型权重全在 Hugging Face 上按需拉。
路由层先给我吃了个定心丸
Laya 有三个 checkpoint：英文版（ModernBERT-large，421M）、多语言版（mmBERT-base，322M，覆盖 100+ 语言）、还有一个在客服场景微调过的 typed-decisions 版。三个怎么选？它内置了个 Router，官方说每次请求前先用纯 Python 做脚本和语言检测，亚毫秒级，然后把请求派给对的 checkpoint。
我实测了一下。英文、中文、德文、日文、高棉语各来一条，看它怎么路由：
route<span>[en]</span> 0.149ms -> english <span>reason</span>=<span>'English Latin text'</span>
route<span>[zh]</span> 0.389ms -> multilingual <span>reason</span>=<span>'non-Latin script (han, 100% of letters);
the English checkpoint cannot read it'</span>
route<span>[de]</span> 0.130ms -> multilingual <span>reason</span>=<span>"Latin script but language looks like 'de', not English"</span>
route<span>[ja]</span> 0.348ms -> multilingual <span>reason</span>=<span>'non-Latin script (kana, 100% of letters)'</span>
route<span>[km]</span> 0.351ms -> multilingual <span>reason</span>=<span>'non-Latin script (khmer, 100% of letters)'</span>
五种语言全部路由正确，单次 0.13 到 0.39ms，官方"亚毫秒"的宣称实测成立。reason 字段写得相当直白，"英文 checkpoint 读不了它"——这是说给调用方听的日志，不是论文腔。 为什么路由要在 forward pass 之前做？这里埋着整篇最值得记住的一个数字，后面细说。
然后 322M 的权重把我机器干爆了
路由验证完，该来真的了：加载多语言版权重，跑一次真实的中文工单分诊。 下载很顺利，644MB 的 safetensors（bf16 存储），82 秒拉完。torch 导入后容器可用内存还剩 911MB，权重 644MB，账面上装得下。我等着它跑出官方文档里"CPU 单问 193-464ms"那个级别的数字。 然后进程没了。没有报错，没有 traceback，就这么消失了。dmesg 里躺着一行：
<span>Out of memory:</span> <span>Killed</span> <span>process</span> <span>1380</span> <span>(python3)</span> <span>total-vm:5186348kB,</span> <span>anon-rss:1256140kB</span>
RSS 1.26GB——权重本身 644MB，加载过程中的峰值（拷贝、类型转换、运行时开销）把余量吃穿了，OOM killer 直接击杀。我试着加 2GB swap 硬闯，容器里 swapon 返回 Operation not permitted，没这个权限。装好的 2GB swapfile 又删掉，这条路在容器里走不通。
所以先泼自己一盆冷水：官方那个 CPU 延迟数字，前提是你的机器先装得下它。421M 参数的 fp32 权重要 1.7GB 内存，多语言版 bf16 也要 644MB 加载峰值超 1.2GB——"本地跑"三个字对 8GB 内存以下的机器并不友好。我最终没能跑出推理数字，路由层实测加上官方 benchmark 交叉复核，就是这篇的实测部分了，这点如实交代。 顺带把装包时记着的那个差异兑现了：torch 2.14 我后来没重装。一是路由层实测证明包本身的逻辑没踩版本坑，二是重装也救不了我——瓶颈根本不在 torch 版本，在内存。
官方文档比评论区诚实
真正让我对 Laya 好感上升的，是它的 BENCHMARKS.md 里一节叫 Honest limits——官方自己写的局限性清单，每一条都比社区帖子狠。
最扎心的一条：基础 checkpoint 的 zero-shot 能力接近随机。在 2000 条决策的 typed-decisions 基准上，英文版和多语言版分别 0.362 和 0.342，随机基线 0.318，连"无脑选多数类"的 0.461 都不到。那个广为流传的 0.766（超过 Jev 公布的 0.727），来自在这个基准训练集上微调过的专用 checkpoint。原话是"Laya 是一个用来做专门化的快底座，不是一个开箱即用的决策引擎"。一个开源项目把"我的基础模型接近随机"写进 README，这个坦白程度，比多少"全面领先"的发布会都值钱。
另一个数字更值得记：英文 checkpoint 在非拉丁文字上崩溃，高棉语测试集准确率 0.000，置信度 95.2%。错得明明白白，还自信满满。官方的原话是"模型自己的置信度不会给你警告"——所以路由必须在 forward 之前完成，语言检测那 0.3ms 不是性能优化，是安全设计。我实测的高棉语请求确实被稳稳送去了多语言版，这个设计闭环是真实生效的。
对想直接拿来用的人，还有一条要紧的：多语言版出厂没做温度拟合，ECE 0.314，意思是它报出来的置信度数字不能直接当概率用，得先在自己领域的数据上 fit 一遍温度，官方拟合后能到 0.106。另外 score 这类序数打分是三种原语里最弱的（SST-5 上 0.372），别把关键分支押在它上面。
也替 Jev 说句公道话：两边数据放一起看，超过 20 个选项的高基数场景 Jev 明显更强，Banking77 上 Jev 0.870、Laya 只有 0.425——encoder 的 token 预算摊到每个选项上只剩三四个 token，文字都糊了，而 Jev 开箱就支持最多 255 个选项。各家的甜区不一样，不是谁替代谁的关系。
什么场景该用它，什么场景别碰
一个多小时折腾下来，我的结论大概是这样的。 如果你在给 agent 流水线找"分诊台"——工单归类、意图识别、风险打标、路由判断，输入是明确的，选项是固定的，每秒要判断很多次——这个品类值得认真看。单次 forward 的延迟和成本优势是数量级的，置信度还是校准过的统计量而不是生成的文本，可以放心拿去做分支条件。本地零成本跑开源版，省下的是每次调用 70ms 起步的网络往返。
反过来，选项超过二十个、需要模型解释理由、或者输入是开放生成的场景，现在就别硬上，老老实实用生成式模型。以及，给 2GB 内存的容器装 322M 模型这种事，就别学我了。 至于这个品类会不会真的立住，一周的数据说明不了什么。但"把决策从生成里拆出来"这个思路，我反正是不讨厌——agent 跑得越多，这种小判断就越密集，而账单是真实会疼的。后面 Laya 或者 Jev 有什么新进展，我再更新。
把决策从生成里拆出来，是 agent 账单焦虑下的真需求。Laya 适合选项固定、需高频判断的意图识别与风险打标，前提是先备足内存并做领域微调。