2026-09-15，TypeSafe AI 发布了一个自称「不是 LLM」的模型 Jev，和一个新的模型类别名字：System One 模型。卖点是一句很有煽动性的话——它不生成字符串，只吐类型安全的决策和概率，因此「不可能幻觉」，而且比现有模型快 40–200 倍、便宜 40–400 倍。
这些数字全是厂商自己在自己笔记本上跑的（他们在发布页里主动标注了这一点）。Jev 还在 waitlist 早期访问阶段，我拿不到 API key。所以我做了另一件事：用本机同一个 7B 模型，同时扮演「生成派」和「概率派」，把「放弃字符串」这个机制单独拎出来测一遍。结论比厂商的宣传更有意思，也更能告诉你这东西的用武之地在哪。
名词速查
| 术语 | 一句话解释 |
|---|---|
| System One 模型 | TypeSafe 起的类别名（借 Kahneman 的「快思考」）：只做快速结构化判断、不写文字的模型 |
| Choice / Score / Noul | Jev 的三个提问原语：多选一 / 按有序档位打分 / 是非题返回「是」的概率 |
| 自回归 | 一次只产出一个 token，下一个要等前一个算完——LLM 生成文字的方式 |
| prefill / decode | 推理的两个阶段：一次性读完输入（prefill）vs 逐 token 写出答案（decode），详见站内旧文 |
| logprobs | 模型对「下一个 token 是什么」给出的概率分布；采样前就已经算好了 |
| 校准（calibration） | 说 80% 的那一批里，真的有约 80% 是对的。校准是一批预测的性质，不保证单条 |
| RLHF / RLVR / RLCD | 三种后训练目标：让人类喜欢 / 让程序可验证 / 让决策概率校准（RLCD 是 TypeSafe 自己起的名） |
| prefix cache | 服务端把已算过的输入前缀的中间结果留着，下次同前缀的请求不用重算 |
一、先说结论
我这篇要回答两个问题：System One 模型到底是什么形状，以及它值不值得你在生产里换掉一次 LLM 调用。三句话版本：
- 它的根本约束是 decode 比 prefill 贵得多。 我本机实测这个比值是 26–28 倍（见第三节）。一个「8 选 1」的决策只有 3 bit 信息量，但走字符串接口要付几十个 token 的 decode——这笔钱是纯浪费。放弃字符串，就是不付这笔钱。
- 但「放弃字符串」单独能省的，是一个位数，不是两个位数。 我本机同模型对照：1.8–4.1 倍，不是 40–200 倍。厂商那两个数量级里，很大一块来自另外两件事：把 N 个问题塞进一次调用，以及跟更贵价位档的模型比价。
- 真正的架构关键是「state 读一次，问题问一堆」。 如果你按直觉写成「一个问题一次调用」，在 650 token 的 state 上它比生成 JSON 还慢 2.4 倍（4973ms vs 2041ms）。这是这套接口最容易踩的坑，也是它设计成这样的真正理由。
二、这个模型长什么形状
先把二手信息压缩完，好腾地方讲测出来的东西。以下均出自 TypeSafe 官方发布页与文档（我当场读的原文，带链接在文末）：
发布者是 Diogo Almeida，RLHF 的共同发明人之一，做过 InstructGPT / ChatGPT 背后的方法（他自己在官方 AI primer 页里挂了 Google Scholar 链接佐证）。他的判断是：行业把所有力气花在做 System 2（慢想、会推理、能写字）上，而软件里 99% 的判断要的是 System 1——一个快速、稳定、能被 if 语句直接用的结论。
API 只有三个提问原语。这张表我加了一列「用错会怎样」，因为这三个原语最容易被当成同一个东西：
| 原语 | 问什么 | 返回 | 用错会怎样 |
|---|---|---|---|
| Choice | 从你给定的选项里选一个（上限 255 个选项） | 选中项 + 每个选项的概率 + confidence | 把有序的东西（严重度 1/2/3）塞进 Choice，你就拿不到「介于 1 和 2 之间」这个信息 |
| Score | 按你写的有序档位打分 | 期望分（如 1.035）+ 各档概率 + confidence | 官方明确警告：别拿档位之间的插值当真实数值，它的数值校准很弱 |
| Noul | 一道是非题 | 一个数：「是」的概率 | 它不另外返回 confidence——0.5 的意思是「五五开」，不是「中等程度」 |
请求长这样（官方 quickstart 原文，我原样引用）：state 是你程序里已有的任意非结构化状态，questions 是一个字典：
{
"state": "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP.",
"model": "jev-latest",
"questions": {
"department": { "type": "choice", "instructions": "Which team should handle this",
"criteria": { "billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions" } },
"frustration": { "type": "score", "instructions": "How frustrated the customer appears",
"criteria": ["Calm, just stating facts", "Frustrated but civil", "Very angry, strong language"] },
"is_urgent": { "type": "noul", "instructions": "The message conveys urgency or time-sensitivity" }
}
}返回里 department 带着 {"billing":0.159,"technical":0.84,"sales":0.001} 和 confidence: 0.596。这个 confidence 不是模型另外「自我评估」出来的，文档写得很清楚：它是从概率分布的形状算出来的一个统计量，分布越尖就越高。你也可以不用他们的定义，自己拿 probabilities 算——这一点我觉得是文档里最诚实的一段。
价格与限制（官方 models 页，2026-09）：输入 $0.042/MTok，输出免费；一次请求里问题数量不受条数限制，只受 token 预算约束（state + 最长问题 32k，全部加起来 64k）。
三、根本约束：decode 比 prefill 贵 26–28 倍
这一节是全文的地基。「System One 模型之所以必须放弃字符串，是因为自回归解码把「答案的信息量」和「要付的 token 数」绑死了。」 这句话可反驳——如果 decode 和 prefill 一样便宜，或者输出 token 数能和语义信息量解耦，那 Jev 的速度优势就只剩下批处理那一份。
我这台机器（Apple M5 Pro，20 核 GPU，24 GB 统一内存）上这个比值是实测过的：Qwen2.5-7B-Instruct Q4_K_M 在 llama-bench 下 prefill 1602.89 ± 24.16 t/s、decode 56.56 ± 2.87 t/s（2026-09-08 实测，带冷却，我在KV cache 那篇里用过同一组基线）。读比写便宜 28 倍。
把这个比值套到本文的实验上，能反过来预测墙钟时间。下面三行是我用 python3 算的（prefill = prompt_tokens / 1602.89，decode = completion_tokens / 56.56）：
| 实测场景 | prompt / output token | 预测 prefill | 预测 decode | 预测总和 | 实测墙钟 | decode 占比 |
|---|---|---|---|---|---|---|
| 短 state + 生成 JSON | 259 / 80 | 162 ms | 1414 ms | 1576 ms | 1609 ms | 90% |
| 长 state + 生成 JSON | 878 / 80 | 548 ms | 1414 ms | 1962 ms | 2041 ms | 72% |
| 长 state + 先想再答 | 894 / 178 | 558 ms | 3147 ms | 3705 ms | 3726 ms | 85% |
三行的预测值都落在实测的 2–4% 以内。这不是巧合，是说这类任务的墙钟时间 72%–90% 花在「把答案一个字一个字写出来」上，而不是花在理解输入上。
所以 Jev 的设计不是审美选择，是顺着这个约束往下推的唯一解：如果输出只有几个比特，就不要走那条每比特都要一次前向传播的通道。这件事的共同祖先有两个——一个是非自回归生成的老账（我写过扩散语言模型买到了什么、亏在哪里，那篇的结论是「自回归不是物理定律」，Jev 是同一句话的另一种兑现方式）；另一个更老，是神经符号 AI 的梦想——神经网络做感知、代码做逻辑。TypeSafe 的 manifesto 自己承认了这一点，还引用了那个戏称：smart if-statements。
四、我在本机搭了个「穷人版 System One」
拿不到 Jev 的 key，但「放弃字符串」这个机制不需要他们的模型也能测。核心观察：一道是非题的答案，在自回归模型里其实早就算好了——就是第一个 token 位置上 Yes 和 No 的概率。你只要不让它继续往下写，把 logprobs 读出来归一化，就得到了一个 Noul。
llama-server 的 /completion 接口直接支持：n_predict: 1 只前向一步，n_probs: 40 把 top-40 的 logprobs 带回来。归一化的代码就五行：
# 伪代码骨架，对应本文实验脚本 sysone_bench2.py 的 noul()
r = post("/completion", {"prompt": chat_template(state, question),
"n_predict": 1, "temperature": 0.0, "n_probs": 40})
p = {} # token 字面量 -> 概率
for d in r["completion_probabilities"][0]["top_logprobs"]:
p[d["token"].strip().lower()] = p.get(...) + math.exp(d["logprob"])
yes = p.get("yes", 0) + p.get("true", 0) # 同义 token 合并
no = p.get("no", 0) + p.get("false", 0)
return yes / (yes + no) # 省略：yes+no 质量过低时的兜底这个 5 行的东西已经具备 Jev 的两个关键性质：类型安全（返回值只能是 [0,1] 的浮点，不可能吐出一句「作为一个 AI 助手…」）和概率输出（不是硬 true/false）。它不具备的是 Jev 的并行采样——我这个版本每个问题还是要发一次 HTTP 请求。这个差别在第六节会变成主角。
我在这里翻的第一个车：我照着直觉写了 r["completion_probabilities"][0]["top_probs"]，直接 KeyError。llama.cpp 这个字段叫 top_logprobs，里面装的是 logprob 不是 prob，得自己 math.exp。五分钟的事，但如果你也想跑这个实验，记住是 top_logprobs。
实验配置（都写出来，方便你复现）：llama-server -c 4096 -ngl 99，模型 Qwen2.5-7B-Instruct Q4_K_M，temperature 0，10 个是非题，两种 state：
- 短 state：一条 Stripe 连接失败的工单（259 prompt token 含 system prompt）
- 长 state：同一件事展开成 15 轮客服对话（648 token 正文，878 prompt token），里面埋了「年付 $4800」「手工对账 214 单」「合伙人想换供应商」「错误页 URL 里带 access token」这些细节
四条路径做对照，其中前两条代表 System Two 的两种常见写法：
| 路径 | 做法 |
|---|---|
terse | 一次 chat 调用，直接生成 10 个字段的 JSON（最省的生成式写法） |
think | 一次 chat 调用，先写一段 Reasoning 再给 JSON（现实里更常见的写法） |
noul | 10 个是非题，一题一次请求，关掉 prefix cache |
noulc | 10 个是非题，一题一次请求，开 prefix cache（state 只 prefill 一次） |
每种配置跑 3 轮，每轮 22 次请求（1+1+10+10），四种配置合计 264 次请求。按我之前踩过的热节流坑的规矩，每次调用之间插 6 秒冷却，并且把四条路径的顺序倒过来重跑一遍——两轮不一致就全部作废。
五、实测结果：1.8–4.1 倍，不是 100 倍
| 路径 | 短 state 正序 | 短 state 倒序 | 长 state 正序 | 长 state 倒序 |
|---|---|---|---|---|
terse（生成 JSON） | 1609.0 ± 9.3 | 1647.0 ± 34.9 | 2041.0 ± 21.2 | 2035.5 ± 0.9 |
think（先想再答） | 2210.2 ± 3.0 | 2246.0 ± 37.9 | 3726.3 ± 5.6 | 3721.9 ± 2.0 |
noul（无缓存） | 947.0 ± 4.9 | 949.3 ± 7.9 | 4972.7 ± 2.5 | 4971.7 ± 9.9 |
noulc（有缓存） | 898.5 ± 4.1 | 900.1 ± 8.0 | 918.7 ± 8.2 | 906.5 ± 11.3 |
单位 ms，10 个问题的总耗时，n=3。倒序重跑全部落在噪声内，数据可用。
第一个反直觉的地方：noulc 对 terse 的加速只有 1.8 倍（短 state）到 2.2 倍（长 state）；对更现实的 think 是 2.5 倍和 4.1 倍。我原本预期能看到一个数量级——毕竟按第三节的账，decode 占了 72%–90% 的墙钟，砍掉它应该能快 3–10 倍。
差额去哪了？我又量了一次单次调用的地板：同一个问题重复问（输入完全命中缓存）是 27 ms，换一个新问题（要 prefill 十几个 token 的问题文本）是 112 ms。也就是说 noulc 那 900 ms 里，九成是「发 10 次 HTTP 请求」的固定开销，跟模型算得多快无关。
这正好解释了 Jev 为什么把 API 设计成「一个 state + 一个问题字典」而不是「一个 state + 一个问题」：他们把我这 10 次调用压成了 1 次。而单次前向里多塞几个问题几乎不要钱——这一点我在同一台机器上量过：batch 内 token 数从 1 涨到 8，单次前向延迟只从 18.15 ms 涨到 44.77 ms，第 9 个 token 才跳到 78.98 ms（根因是 ggml Metal 后端里 ggml/src/ggml-metal/ggml-metal-common.cpp:16 那行 ne11 > 8，详见投机解码那篇）。「十个问题按一个问题的价钱算」在物理上是成立的，前提是它们真的在同一次前向里。
所以厂商那 40–200 倍，我的分解是（这一段是我的推断，不是他们公布的口径）：一份来自放弃 decode（我测到 1.8–4.1 倍），一份来自把 N 个问题合并成一次调用（他们自己的 cookbook 量到 10 倍，见下节），剩下的来自跟带思维链的推理模型比——think 那一列比 terse 又慢了 1.8 倍，而真正的前沿推理模型的思维链比我这 178 token 长得多。
六、崩点：「一问一次调用」比它要取代的东西还慢
这是全文我最想让你带走的一格数据。看 noul（关掉 prefix cache）在长 state 上的那个 4972 ms：
- 它比生成 JSON 的
terse（2041 ms）慢 2.4 倍 - 它比开了缓存的
noulc（919 ms）慢 5.4 倍 - 原因很朴素：10 个问题各自把 878 token 的 state 重新 prefill 了一遍，总共读了 6950 个 prompt token，而生成式写法只读了 878 个——7.9 倍的冗余
换句话说，如果你拿到一个 System One 风格的 API，按最自然的直觉写成「循环里一题一调用」，你会得到一个比 LLM 更慢的 LLM 替代品。这个崩点随 state 大小和问题数量的乘积增长：短 state 上它还看不出来（947 vs 899，几乎没差），长 state 上就翻倍了。
TypeSafe 自己也量过这件事，口径不同但方向一致：他们的 parallel-questions cookbook 拿 GDPR 的维基百科条目问 13 个问题，一次性打包 vs 一题一次调用，便宜 12.2 倍、快 10.0 倍，答案没有变化（他们的数字，我没有 key 无法复现；我本机用 prefix cache 复现出的是 5.4 倍）。
这就是这套东西的本质：不是「模型更快」，是把「读状态」和「做判断」解耦——状态读一次，判断随便问多少个。他们文档里那条容易被当成琐碎限制的说明（state + 最长问题 ≤ 32k，全部 ≤ 64k）其实是这个架构的直接后果：state 是共享前缀，所有问题在它之上并行展开。
七、同一个模型、两种接口，答案在哪里分叉
速度只是一半。另一半是 Jev 最有争议的主张：「它不可能幻觉」。
HN 上最高票的那条评论（jacobgold，1833 分那个帖子）把这话拆得很准，我同意他的拆法：「它确实不能吐出非法的类型，但它照样能吐出一个完全错误的合法值。」——类型安全 ≠ 事实正确。
但我的实验里出现了一件比「类型安全」有意思得多的事。注意：下面两组答案出自同一份权重、同一段 state，只是接口不同。
短 state（那条只有两句话的工单）：
| 字段 | terse 生成的 JSON | noulc 读出的概率 |
|---|---|---|
| is_urgent | true | 1.00 |
| is_bug | true | 1.00 |
| needs_human | true | 1.00 |
| wants_refund | false | 0.00 |
| has_repro | false | 0.00 |
| is_blocked | true | 0.12 |
| is_paying | true | 0.00 |
| is_angry | true | 0.02 |
| is_churn | true | 0.00 |
| is_security | false | 0.00 |
10 个字段里分叉了 4 个。而且分叉的位置不随机：恰好全是那条短工单里没有明说的东西。工单说的是「连不上 Stripe，三天了，在丢单，尽快」——它没说自己在付费、没说要取消订阅、没说完全不能用、也没有说任何愤怒的话。生成式接口把这些空白补成了一个前后一致的故事（一个丢单的客户”当然”是付费的、愤怒的、要流失的）；概率接口把它们报成了接近 0。
到底谁对？我没有标注答案，而且这几条本来就是可以争的（丢了三天单，算不算 blocked？）。所以我不打算说「概率接口更准」——我要说的是：生成式接口没有给你任何办法知道这几条是可以争的。同一个模型，一边给你四个斩钉截铁的 true，一边给你 0.12 和 0.02。is_blocked 那个 0.12 至少在告诉你「这条我拿不准，别拿它自动关单」。
换成信息更全的长 state（15 轮对话，明写了年付 $4800、明写了可能不续约、明写了 URL 里泄漏 token），两个接口的答案就收敛了——10 个字段只差 1 个（has_repro：terse 说 true，noulc 说 0.00）。结论很朴素：分歧量是「state 里证据不足」的一个指示器。
顺带一个副产品，也是反直觉的：think（先写 Reasoning 再给 JSON）在短 state 上把 is_bug 翻成了 false——而这明显是个技术故障。多想了 115 个 token，多花了 601 ms，答案还退步了。 单样本，我没做统计显著性，但它至少说明「加思维链总会更好」在这类窄判断上不是白拿的。
八、那么用武之地到底在哪
前面七节都在测机制，这节讲落地。我把官方 patterns / cookbooks 读完之后，按「我会不会真的这么用」重排了一遍——括号里标了证据档位：
值得换掉一次 LLM 调用的场景：
- 意图分流（smart if-statement）。先用一次便宜判断把请求分成三类：能走确定性代码的、要走专家 LLM 的、要走人的。这是他们文档里的 intent-routing 模式，也是我见过最多 LLM 被浪费的地方——用一个 $10/MTok 的模型只为了知道「这条是不是退款请求」。
- 按风险分档的置信度门控。他们的例子我觉得写得很好：查余额这种读操作 confidence > 0.6 就自动执行，批准转账这种写操作要 > 0.9，低于 0.5 直接转人工。阈值不是一个数，是每个动作一个数——这个心智模型可以直接搬到你现有的 LLM 调用上，不需要 Jev。
- 投机式 fan-out。既然十个问题跟一个问题差不多贵，那就把「万一用得上」的问题一起问了：先问类别，同时把「如果是 bug，严重度多少」也问出来，不是 bug 就丢掉这个答案。这是第五节那个「多塞 token 几乎免费」的直接应用。
- 复合打分。把一个复杂判断拆成若干原子分数（简历筛选：Python 深度 / 带团队 / 系统设计各打一分），权重留在你的代码里。好处是权重可审计、可 A/B，而不是埋在 prompt 里。
- 护栏与验证。给 LLM 的输入输出做一次筛：是不是越狱尝试、检索回来的段落里有没有藏指令、引文和原文对不对得上。他们有四个 cookbook 专门做这个。这一格我觉得最实在——护栏本来就该比被护的东西便宜，用同档模型做护栏在经济上说不通（对照Llama Guard 那篇的思路：把政策变成可编程门卫）。
- 重排与海量打标。他们的 CLERC 法律检索 cookbook 报告 top-1 从 5% 提到 18%、top-10 从 38% 到 62%（他们的数字，我未复现）。这类「对 1000 条各打一分」的活，成本结构跟单次调用完全不同——我压 embedding 那篇里的重排步骤就是这个形状。
- 实时循环。他们放了个让模型玩 Doom 的 demo，每秒 10 次查询，自称约 $7/小时（厂商 demo，我未复现）。真正的意义不是打游戏，是在 100ms 级别的循环里第一次能塞进语义判断。
注意这里有个容易搞错的边界：上面这些模式，没有一条需要等 Jev 的 waitlist。confidence 门控、fan-out、复合打分，你今天用任何支持 logprobs 或结构化输出的模型都能做，只是贵一些慢一些。Jev 改变的是这些模式的经济性，不是可行性——第四节那 5 行代码就是证据。
九、它明确不适合什么
TypeSafe 有一个我很少在厂商文档里见到的页面：model-jaggedness/jev-1.13，标题直译是「Jev 1.13 的毛刺」，逐条列自家模型的失败模式。这页比发布公告有用得多，我把它压成一张表（全部出自官方原文，最后复核日期 2026-09-16）：
| 失败模式 | 官方给的替代做法 |
|---|---|
| 字面理解：它回答你写下的问题，不是你想问的问题；否定、限定词都按字面读 | 把确切条件写进 instructions，边界情形写进 criteria；要解释的地方拆成两个字面问题，在代码里合并 |
| 数学与计数：不可靠，而且误差随规模变大 | 算术全部留在代码里；要数个数就一项一个 Noul，自己求和 |
| 日期时间比较：它把日期读成文本，不是有序量 | 抽取交给模型（每个部分都是小的闭集合），排序/区间/时长全部交给代码 |
| 多层间接：双重否定、「属性的属性」要跳几跳的问题 | 减少跳数，直接点名 state 里的相关字段 |
| 大而杂的 state：无关细节是干扰源，准确率随 state 变大下降 | 先在代码里检索过滤，只送问题需要的字段 |
| 对抗性内容：state 里被当数据处理，不默认敌对；注入的指令能移动答案 | criteria 写死，上线前测边界情形 |
| 指令与 criteria 冲突：比如 Noul 的 true 映射到「否」 | 把 criteria 当成 instruction 的延伸，语言对齐 |
| 生成：它不是干这个的 | 用生成式模型；要抽取就先用正则或生成式模型列候选，让它挑 |
官方还有一句总结性的提醒我原样搬过来：避免「问模型一件代码能精确算出来的事」。这句话配上第三节的账，构成了这类模型的完整定位：它是个语义判断原语，不是一个便宜的小 LLM。
另外两条来自 HN 的质疑我认为站得住，也补在这里：
- 「不可能幻觉」被过度包装：类型安全只保证 schema 匹配。他们发布页里对这条的原话很有意思——「一个反例就能推翻它，但这在数学上不可能发生」，也就是说这是结构保证、不是实测结论，所以那张幻觉率图里他们给自己填的 0% 也不是测出来的（官方原文自己标注了这点）。schema 对了不等于值对了。第七节我的数据其实提供了一个更弱但更真的版本：概率接口让「证据不足」这件事变得可见。
- 「这不就是 encoder 分类器吗」：有评论指出 BERT 式 encoder 早就能做「非结构化输入进、概率出、不幻觉、快」这套。我认为这个质疑基本成立，Jev 的增量在于输出形状由你在请求里现场定义（选项、档位、criteria 都是运行时参数），不需要为每个新标签集重新训一个分类头。这是「把训分类器的门槛降到写 JSON」，而不是发明了一种新的可能性。
小结
- 根本约束：decode 比 prefill 贵 26–28 倍（本机实测），而一个窄决策只有几比特信息量。走字符串接口，72%–90% 的墙钟花在把答案打字出来（本机三组实测，预测误差 2–4%）。
- 崩点：按直觉写成「一问一次调用」，在 650 token 的 state 上比生成 JSON 慢 2.4 倍、比带缓存的批量慢 5.4 倍，因为 state 被重复 prefill 了 7.9 倍。这套接口的价值全在「state 读一次、问题问一堆」，不在「模型更快」。
- 可带走的动作：不要等 waitlist。挑你系统里最贵的那次「只为拿一个分类结果」的 LLM 调用，把它换成读 logprobs 的五行代码，先看两件事——快了多少，以及概率落在 0.2–0.8 之间的比例有多高。后者是这次改造能不能成立的真正判据：如果一大半请求都在这个区间，说明你的问题本来就不是 System One 形状的，换接口只会把不确定性从「一句自信的错话」变成「一个尴尬的 0.5」。
通俗总结
把大模型想成一个很聪明但只会用嘴回答的同事。你问他「这张单子该转给哪个组」，他不会伸手指一下，他会清清嗓子说「根据您提供的信息，我认为应该转给技术组」——一句话说完，指的那一下早就做完了。你付的钱和等的时间，大部分花在那句话上，不是花在那一下上。
System One 模型就是把那个同事换成一个只会伸手指的同事。他不会说话，但他指得极快，而且会同时告诉你「我有多确定」——手会抖。手抖的时候，你的代码知道该找人来看一眼。
一句能讲给同事听的话：这类模型省的不是「思考的钱」，是「说话的钱」——而对一个只需要在三个选项里选一个的判断来说，说话的钱占了九成。所以判断它值不值，只要问一句：我这次调用，是真的需要它说话，还是只需要它指一下？
我接下来想补的是校准那一半。这篇只测了速度和分歧位置，没测「说 0.8 的那批里到底有没有 80% 是对的」——那需要一个带标注的判断集，本机能做，但要先攒数据。拿到 Jev 的 key 或者攒够标注之后我会回来更新这一篇。
参考来源
工程实践（一手，本次实测）
- 实验脚本
sysone_bench2.py：llama-server -c 4096 -ngl 99+ Qwen2.5-7B-Instruct Q4_K_M，四条路径 × 两种 state × 正倒序，各 3 轮，合计 264 次请求 - prefill / decode 基线（2026-09-08 本机
llama-bench -p 512,2048 -n 128 -r 3，带冷却）：pp512 = 1602.89 ± 24.16 t/s，tg128 = 56.56 ± 2.87 t/s ggml/src/ggml-metal/ggml-metal-common.cpp:16（ggml-org/llama.cpp）——ne11 > 8那行内核切换，是「一次前向多塞问题几乎免费」的上界- llama.cpp
/completion的字段名是top_logprobs（装logprob，要自己math.exp），不是top_probs
官方文档与发布（二手，本次当场读取原文）
- Introducing System One Models & Jev —— 发布公告，含对照表、价格、demo 与他们自己标注的 nuance
- TypeSafe Manifesto —— 「Build Prod, Not God」与 neuro-symbolic / smart if-statements 的自我定位
- Jev 1.13 jaggedness —— 官方逐条列出的失败模式（第九节那张表的来源）
- Primitives / Confidence / AI primer —— 三原语定义、confidence 是分布统计量、RLHF→RLVR→RLCD 的三条后训练路线
- Parallel questions cookbook —— 13 问打包 vs 逐条调用：便宜 12.2×、快 10.0×（他们的数字）
- Hacker News 讨论 —— 1833 分 / 482 条，第七、九节引的两条质疑出处
站内相关
- 自回归不是物理定律：扩散语言模型买到了什么，亏在哪里 —— 「放弃自回归」这笔账的上一种算法
- 投机解码的四种变体，和我笔记本上那道 8 个 token 的悬崖 ——
ne11 > 8悬崖的完整测法与热节流的坑 - KV cache 的 12 种省法 —— prefill / decode 两阶段与本文用的同一组基线
- 安全策略不是一串 if：Llama Guard 如何把政策变成可编程门卫 —— 护栏该比被护的东西便宜
- 主模型在思考，谁在打下手？ —— Agent 循环里哪些岗位本来就该交给小模型
- 站在 AI 的山巅：12 条原理 —— 本文用到的「瓶颈塑造设计」那面镜子