LLM 做决策又慢又贵？System One 模型 JEV、kev、laya 直接算概率
LLM 做决策又慢又贵？System One 模型 JEV、kev、laya 直接算概率
先别看热闹，这里有一条 Agent 基础设施的新分支。
你让 LLM 干的最多的事，可能不是写文章，而是做判断：这条消息该进哪个客服队列、这个请求该不该升级、这段文本是好评还是差评、这份工单属于哪个部门。这些任务不要求"生成"，只要求"选一个"，但主流 LLM 是为生成文本设计的——逐字逐 token 地写，慢、贵，还经常一边编一边错。
TypeSafe AI 最近提出了一类新模型，叫 System One（取自卡尼曼《思考，快与慢》）：不做开放生成，只做快速、结构化的决策，软件可以直接使用结果。它的第一个公开模型 JEV 宣称 70ms 就能出结果、永远不会产生类型错误、每个答案自带置信度。更热闹的是，社区已经有两个开源项目在复刻这条路：kev（Jared Palmer 用 Devin 写的 JEV 开源复刻）和 laya（多语言非自回归决策引擎）。这篇文章把四条来源的信息串起来，讲清楚 System One 到底是什么、JEV 的内部架构怎么被逆向出来、以及 kev 和 laya 各走到哪一步。
本文提纲
- 为什么 LLM 不适合做"决策"
- System One：来自《思考，快与慢》的新模型类别
- JEV 是什么：70ms、类型安全、永不幻觉
- JEV 架构逆向：共享状态 + 并行问题分支
- kev：Qwen3.5 上的开源复刻
- laya：多语言非自回归决策引擎
- 横向对比与适用边界
为什么 LLM 不适合做"决策"
先把问题说清楚。
分类、路由、打分、抽取、护栏——这些是 AI 工作流里出现频率最高的"小决策"。它们的共同点是：输入是一段状态（工单、邮件、JSON、对话），输出是从一组预先定义的选项里选一个，附上概率。这类任务不需要模型创造新内容，只需要它做对选择题。
但主流 LLM 是自回归文本生成器：你要一个答案，它得先把答案逐字"写"出来，写到一半还可能改主意。三个代价随之而来：
- 慢。一次决策要生成几百个 token，端到端几秒起步。
- 贵。输出 token 按量计费，而决策任务里大部分 token 都是格式和铺垫。
- 不可靠。它可能把
"payments"写成"pyaments"，可能输出不在选项里的值，也可能对根本没有依据的问题给出一个自信满满的概率——也就是幻觉。
最后一个问题最要命。在 Agent 工作流里，下游代码要靠模型输出做分支判断，一个编造的结构或跑偏的答案会让整条链路静默出错。你需要的不是"会写字的模型"，而是"会做选择题的模型"，它得保证：答案一定在选项里，且概率是诚实的。
System One：来自《思考，快与慢》的新模型类别
TypeSafe AI 把这类模型命名为 System One，直接引用卡尼曼（Daniel Kahneman）《思考，快与慢》里的双系统理论：System 1 是快速、直觉、自动的判断，System 2 是缓慢、审慎的推理。用在这里很贴切——LLM 那种反复斟酌、逐字推敲的生成，是 System 2；而路由、分类、打分这些毫秒级直觉判断，是 System 1。
官方定义是"a new class of frontier models built to make fast, structured decisions that software can use directly"——为自动化而建、做快速结构化决策、软件可直接使用的模型。它不做聊天、不做开放文本生成，只做软件能直接消费的类型化概率决策。
JEV 是 TypeSafe 的第一个 System One 模型，定位一句话："unstructured state in, typed probabilistic decisions out"——非结构化状态进，类型化概率决策出。
这里的关键词是概率，不是文字。JEV 的每个答案都带置信度，而且它"cannot hallucinate"——官方说法是它不生成自由字符串，所以没有可幻觉的空间。它用一套不同的训练方法 RLCD（Reinforcement Learning for Calibrated Decisions，校准决策强化学习），区别于 LLM 的 RLHF/RLVR——优化目标不是"符合人类偏好"或"通过可验证奖励"，而是"输出的预测分布足够诚实"。
JEV 是什么：70ms、类型安全、永不幻觉
TypeSafe 在发布博客里给了一组关键事实：
- 快：端到端响应 70ms-500ms，而前沿 LLM 做同样的事要几秒。
- 便宜：输入 token 极便宜，输出 token 近乎免费——因为输出不是生成出来的，是算出来的。
- 类型安全：所有可能输出预先定义，模型"绝不产生类型错误"，且每个答案带置信度分数。
- 架构：新模型架构加并行采样器（parallel sampler），一次查询把全部输出一次给出，而不是逐个 token 吐。
适用场景是 AI 工作流里那些高频决策：classification（分类）、routing（路由）、scoring（打分）、extraction（抽取）、guardrails（护栏）、实时应用。
证据方面，TypeSafe 给了跟 GPT-5.6 Terra 在简化结构化查询上的对比，以及 workflow eval（拿 Jev 和 Astra、Fable 对比作为参考概率，声称 Jev 在 Pareto 前沿领先）。还有两个 demo：一个 Doom bot 用实时结构化状态玩游戏，一个 Wikipedia racing agent 在链接之间做选择。JEV 支持最高 255 个候选（cardinality up to 255），高基数场景用两阶段流程处理。
命名细节很有意思：JEV 取自 19 世纪经济学家 William Stanley Jevons，他研究过"生产成本下降"的问题，TypeSafe 用它暗指"智能成本下降会催生更多使用场景"。
JEV 架构逆向：共享状态 + 并行问题分支
TypeSafe 没有公开 JEV 的技术细节，但 Archer Hume 写了一篇很扎实的逆向工程文章，基于约 1 万次 API 调用、延迟测量和 token 计费分析，把 JEV 的架构黑盒还原了出来。核心主张：
JEV 不是一个"陈述置信度的文本生成器"，而是一个被改造成决策引擎的 transformer——它直接从内部表征里读概率。
一幅图看懂
graph TB
subgraph "Shared State Prefix"
A[Ticket Text] --> B[Transformer Layers]
B --> KV[(Key-Value State)]
end
subgraph "Question Branch 1"
C["Q1 Queue + Options"] --> D[Attend to Shared State]
D --> E[Readout Head: Probabilities]
end
subgraph "Question Branch 2"
F["Q2 Escalation + Options"] --> G[Attend to Shared State]
G --> H[Readout Head: Probabilities]
end
subgraph "Question Branch 3"
I["Q3 Urgency + Options"] --> J[Attend to Shared State]
J --> K[Readout Head: Probabilities]
end
KV -.-> D
KV -.-> G
KV -.-> J整个设计一句话：一段共享的状态前缀 + 许多互相隔离的并行问题分支。输入文本（比如工单）只被编码一次，产生 key-value 表征；每个问题（它的指令、允许的答案、评判标准）并行构建自己的表征，只去 attention 那段共享状态，互不干扰；最后每个分支用一个 readout head 把隐向量投影成对允许答案的概率分布（z = Wh + b 再过 softmax）。全程没有自回归 token 生成，JSON 格式化发生在应用代码里。
七个设计组件
文章给出七个组件，可信度从高到低：
用 readout 结束推理，而不是解码。
output_tokens字段是按序列化响应计算的计费产物，不是生成记录——它随选项数量和问题 ID 长度增长，但不随返回值增长，延迟也不随它变化。共享状态、隔离问题。 token 数可加：一个问题 268 input tokens，两个 276。每个分支上限约 32k token，整个请求约 65k——符合"状态存一份、问题并排"的打包序列。一个 2.3 万 token 的状态带 5000 个问题，如果每个问题都复制一份状态，会超过 1 亿 token，所以状态必须只存一份。可见性实验更直接：放在"兄弟问题"里的信息完全不可见（概率 0.00），同样的内容放进共享状态则拿到 0.90-0.92。
因果骨干（推断）。 作者承认实验分不清 causal decoder 和 bidirectional encoder，假设基于"前沿预训练基本都是 causal decoder"加上共享前缀服务的效率考虑（Hydragen/DeFT 这类技术）。
选项在选择前会互相影响。 决定性实验：在四选项的"付款失败"任务里追加一句"坏天气导致的"，现有选项之间的 log-odds 从 +0.38 移到 +0.11（十组随机块，95% 区间 -0.36 到 -0.19）。如果每个选项的 logit 独立且 softmax 不变，这个比值应该不变——所以这是 listwise（列表级）处理的证据。参考卡测试也证明模型能用到选项描述之后的信息，且改一个值会改变更早选项的排名。
训练分布，再算置信度。 TypeSafe 的方法 RLCD 用 proper scoring rule（对数损失或 Brier 损失）做优化目标。MMLU 校准：ECE 0.0313，1200 个样本里 990 个落在 0.9-1.0 置信区间。API 的
confidence字段不是学出来的，是算术：c = (p_max − 1/K) / (1 − 1/K)，K>1。稀疏容量（推测）。 因为 prefill-only 推理是计算密集型的，而 MoE 在不解码时服务成本几乎消失，且延迟数据（约 30k token 约 160ms）指向约 10B 活跃参数——推测稀疏 MoE 骨干。作者自己说"重建的其它部分都不依赖这个假设"。
批调度。 问题分支是独立的可批处理工作项，模型不会写完一个答案才开始下一个。重复请求之间的小概率差异说明不要假设确定性。
作者也交代了 tokenizer 和 192 个公开 tokenizer 都匹配不上（最接近 Qwen，348/415 probes），说明词汇表被改过或做了继续预训练。
最佳重建：一个有共享状态前缀、隔离问题后缀、列表级选项处理、类型化数值读出、面向预测分布训练的 causal transformer，稀疏 MoE 作为可能的骨干。文章结尾还给了几个可证伪的实验，包括一个用约 200 个选项区分"固定 slot head"和"pointer-style scorer"的实验。
kev：Qwen3.5 上的开源复刻
kev 是 Jared Palmer 用 Devin 写的开源项目，自称"a family of small decision models built on Qwen3.5"，目标就是在本地复刻 JEV 背后的架构——README 直接引用了上面那篇逆向文章作为设计依据。Apache-2.0，1.7k stars。
一个请求支持三种问题类型：
| 类型 | 说明 |
|---|---|
| noul | yes/no，返回"是"的概率 |
| choice | 1-255 个选项里选，每个选项给概率 |
| score | 2-255 级评分量表，返回均值级别索引和概率 |
API 镜像 TypeSafe 的 System One，所以官方 TypeSafe Python SDK 可以直接指向本地 kev server。
模型有三个尺寸：Kev-0.8B / Kev-4B / Kev-9B，都基于 Qwen3.5。每个 checkpoint 是"一个 rank-16 LoRA adapter + 一个小 pointer head"，Qwen base 冻结。head 用问题里的 "decide" token 对每个选项的 hidden state 打分，softmax 成概率。问题共享输入文本但互相隔离：attention-only 的 base 上，问题放在一个序列里用 attention mask 隔开；Qwen3.5 的 DeltaNet 层上，每个问题跑自己独立的一行。
精度数据（hold-out 新来源）：Kev-9B 约 0.822（dev）/ 0.852（test），Jev 托管 dev 0.857——但作者明确说这不是受控对比，因为 Jev 的训练数据未知。已知差距：知识类问题（MMLU-Pro 0.52 vs Jev 0.84）和新来源上过度自信（用 KEV_TEMPERATURE=2.0 缓解，confident errors 从 8.7% 降到 4.4%）。
快速开始：
git clone https://github.com/jaredpalmer/kev.git && cd kev
uv sync --extra serve
KEV_DTYPE=bf16 uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b --port 8009然后 POST 到 localhost:8009/v1/systemone，body 是一段 state 文本加一个 questions 对象。有个 web playground（cd playground && npm install && npm run dev -- -p 3001），可以自己输入、对比"打包 vs 分开跑问题"、打乱选项顺序看答案怎么变。还有个 chess demo——棋盘是 state，合法走法是选项。
训练方面：发布模型在 decision-v7 上训练（1 万个示例，来自 10 个公开数据集加生成的策略/规则结构示例，两轮，LoRA rank 16）。可以拿自己的 JSONL fine-tune（形状跟 API 请求一致，每个问题加一个 "label"），用 --init_from 从发布 checkpoint 起步保留已有知识——社区测试从 base 起步只有 0.33，用 --init_from 能到 0.84。服务性能：CUDA H100 上 5 个问题的请求几十毫秒；Apple Silicon 上慢（Qwen3.5 模型没有快速 DeltaNet kernel，Kev-9B 在 M5 上约 2 秒，旧 Qwen3 模型在 Mac 上约快 6 倍），MLX 后端在计划里。
README 自己列的局限很实在：新来源上概率过度自信；选项顺序会影响答案；训练时最多 384 state tokens（serving 支持 8192）；server 一次只处理一个请求；知识密集型 benchmark 上落后 Jev。
laya：多语言非自回归决策引擎
laya 走的是同一条路线但技术路线不同。官方定位："Multilingual, non-autoregressive System 1 decision engine"——多语言、非自回归的 System 1 决策引擎，来自 Convai Innovations，Apache 2.0。
它不生成文本，对文本/邮件/工单/JSON 做类型化问答（choice、score、noul），single forward pass 一次前向出结果：单问题约 33ms，批处理每问题 7.2ms（T4 GPU 上）。训练也用 RLCD（对 proper scoring rules 做强化学习）。
三个 checkpoint 加一个 Router：
| Checkpoint | Base | 参数量 | 上下文 | 覆盖 |
|---|---|---|---|---|
| laya | ModernBERT-large | 421M | 512 | 英文 |
| laya-multilingual | mmBERT-base | 322M | 1024 | 100+ 语言 |
| laya-typed-decisions | - | - | - | 结构化工作流 |
Router 亚毫秒级自动检测 script/语言，按请求选 checkpoint——官方明确说这是因为英文模型在非拉丁文字上会挂："confidence gating cannot save you"。
from laya import Router
router = Router(preload=True)
res = router.predict(state, questions)或者直接加载某个 checkpoint：
import laya
model = laya.load("convaiinnovations/laya", subfolder="multilingual")还有自动化置信度门控（高/低置信动作分流）、内置工作流预设（router/guardrails/moderation/triage）、preload 模式避免语言切换时 7-10 秒重载、attach() 跟已有 agent 共享 VRAM。
性能对照（对 Jev 1.13.0 的公开数字）：routed 模式 p50 32.8ms，Jev 236-276ms，约 7.8× 快；typed-decisions 上 argmax 准确率 0.766 vs 0.727；温度拟合后校准 ECE 0.081 vs 0.246，约 3× 更好。
但作者对局限非常坦白：base checkpoint 在 typed-decisions 上零样本接近随机（0.362 vs majority-class 基线 0.461）——能力来自 fine-tune 而不是 base 模型。Jev 在高基数标签集上仍然领先（Banking77：0.870 vs 0.425），soft distribution 匹配也是 Jev 更强。
横向对比与适用边界
把三者放一起：
| 维度 | JEV (TypeSafe) | kev | laya |
|---|---|---|---|
| 形态 | 托管 API | 本地开源 | 本地开源 |
| 骨干 | 未公开（推测稀疏 MoE ~10B active） | Qwen3.5 + LoRA + pointer head | ModernBERT / mmBERT |
| 训练 | RLCD | RLCD 风格 + decision-v7 | RLCD |
| 延迟 | 70-500ms | H100 上几十 ms | 33ms / 每问题 7.2ms (T4) |
| 最大基数 | 255 | 255 | 取决于 checkpoint |
| 语言 | 英文为主 | 英文为主 | 100+ 语言（Router） |
| 许可证 | 商业 | Apache-2.0 | Apache-2.0 |
几点实在的判断：
这条路真的成立吗？ 从两个独立开源复刻都做出了能用的精度看，System One 不是一个营销概念——它的核心洞察（决策不需要生成、概率直接读出）已经被社区独立验证了两遍。JEV 的逆向文章和 kev 的实现互相印证了"共享状态 + 隔离问题 + 直接读出"这个架构轮廓。
别神话它。 三个来源共同指向的边界很清楚：知识密集型任务（MMLU 类）还是 LLM 的地盘，JEV 领先也是靠类型化结构而非知识量；高基数、需要 soft distribution 的任务 JEV 仍领先开源复刻；选项顺序敏感、新来源过度自信，是当前所有实现（包括 JEV）的共同弱点。
什么时候值得用？ 你的工作流里如果有大量"给定一段状态，从固定选项里做判断"的调用——客服路由、内容审核、意图分类、打分、护栏——把这些从 LLM 换成 System One 模型，延迟和成本会掉一个数量级，还能拿到诚实的置信度做门控。TypeSafe 官方 SDK 直接支持指向本地 kev，意味着你可以先在本地把流程跑通，再决定要不要上托管 API。
什么时候别用？ 需要生成内容、需要开放性推理、需要世界知识的时候，别用。它是选择题模型，不是答题模型。
参考链接
- TypeSafe AI: Introducing System One Models and JEV - JEV 官方发布博客：System One 定义、RLCD、延迟与定价
- Archer Hume: JEV's Architecture, Unmasked - 基于约 1 万次 API 调用的 JEV 架构逆向工程，核心一手来源
- GitHub: jaredpalmer/kev - JEV 开源复刻，Qwen3.5 + LoRA + pointer head，Apache-2.0
- GitHub: NandhaKishorM/laya - 多语言非自回归 System 1 决策引擎，ModernBERT，Apache-2.0
- Thinking, Fast and Slow（卡尼曼） - System 1 / System 2 概念出处，模型命名的思想源头
你会在哪个场景把这类"决策模型"接进工作流？评论区聊聊你的选择。觉得有用点个赞，让更多人看到 System One 这条新分支。
作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。
