揭开 Jev 的架构面纱

X 上关于 Jev 发布的热评铺天盖地，而大多数都完全没说到点子上：「一个 JSON 分类器能有 1200 万次浏览？是啊，我们确实在泡沫里。」 一个普通的 LLM 把「90% 确信」当作文本生成出来；它吐出这几个字的概率，并不等于它有 90% 的概率是对的。可我们偏偏就围绕这种模式来搭建欺诈筛查、内容审核、路由分发和风险评估：为逐 token 的生成付费，然后把一句未经验证的置信度声明，当成软件可以据以行动的概率。

Jev 的主张是：保留预训练 LLM 的知识，同时把「生成出来的置信度声明」换成「直接从其内部表征中读出的决策概率」。这些概率是针对真实结果训练出来的。给它一份共享的 state、若干 questions 以及允许的答案；它会并行返回这些分布，全程不生成文本。1 对这一整类应用而言，这同时解决了两个问题：决策信号的可靠性，以及为产出该信号而多花的算力。

只有一个问题：它不是开放权重的，而且 TypeSafe 拒绝公开他们的研究……那就由我来（尽力而为）。

证据指向一个被改造用于决策的因果 transformer（很可能用了稀疏 MoE）：共享 state 编码、彼此隔离的问题分支，以及直接的概率读出（readout）而非文本生成。在对 TypeSafe API 做了一通探测（在不同上下文长度、问题重排等条件下寻找延迟伸缩的特征信号）、用 Astra 翻遍能找到的公开文档与研究、并检索了既有工作之后，我认为自己对它的工作方式和架构已经有了一个相当准确的模型。

稀疏骨干是最不确定的一环，但它在这个场景下格外有利，负面影响也比 AR LLM 小得多，所以如果它不是稀疏的反倒奇怪。共享计算和直接输出概率这两点，证据显然扎实得多。这些当然都相当带有推测性质，所以我会尽量说清楚：哪些是 TypeSafe 公开的证据，哪些是实验中观察到的，哪些是由此推断出来的。黑箱 API 让人可以轻易地「往幽灵身上罩块布」，大致勾出架构的轮廓——这一点令人吃惊。

这个设计为什么有用

看一个示意性的客服路由请求。它用来说明 API 的结构；下面例子中的概率是编造的。

{
  "state": "My payouts have failed three times. The bank says everything is fine. Can someone please fix this?",
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "criteria": {
        "payments": "Payout failures and payment processing",
        "account": "Login and account access",
        "other": "Something else"
      }
    },
    "escalate": {
      "type": "noul",
      "instructions": "Does this message require urgent human attention?"
    }
  }
}

一个有用的回答可能给 payments 0.91 的概率，而只给「紧急升级」0.42。这是两种不同的不确定性。软件可以自动完成工单路由，同时把升级交给另一套策略去决定。

因果 transformer 本就懂得如何从左到右构建文本的表征。在普通的语言模型推理中，它处理 prompt、预测一个 token、把这个 token 再喂回去，如此循环。这建立在原始 Transformer 提出的 decoder 注意力与输出投影之上。3 但 prompt 处理阶段其实已经产出了一份丰富的表征。如果任务只是在三个队列里选一个，我们完全可以挂上一个小函数，把这份表征直接映射成三个数字。

这里有个细节能化解大半关于「并行作答」的困惑：因果注意力描述的是哪些位置可以使用哪些信息，而不是输入 token 必须按什么顺序被计算。 在 prompt 处理阶段（即 prefill）中，所有输入 token 都已经是已知的。模型可以在一层之内同时处理这些位置，同时由注意力掩码挡住对后续位置的访问；层与层之间仍然是串行的。自回归解码则多出一重依赖：在上一步的预测被选定之前，下一个 token 根本不存在。我们设想的这个模型在 prefill 与 readout 之后就结束了，因此绕开了逐 token 的依赖。

这改变了任务的计算形状。输出不再需要为 "payments": 0.91 逐字符地做一串拼写决策。JSON 格式化交给普通的应用代码去做，神经网络只负责给出概率。

现在设想 state 是一份冗长的事故报告，而问题有五十个。输入的绝大部分是共享的。transformer 会把已处理 token 的中间信息存放在它的 key–value 缓存里，通常简称 KV cache。在这个设想的设计中，每个问题都读取同一份 state 缓存，每个分支只额外追加自己的指令和候选答案。

对于一个 S 个 token 的 state 和 Q 个问题，若拆成一个个独立请求，state 大约要被处理 Q 遍。共享之后，重复处理的 state token 量就从 Q·S 降到 S。问题仍然必须去 attend state，这部分工作不会消失；但模型不必反复重建 state 的表征。

隔离还赋予了这套接口一层有用的语义。问「客户是不是生气了」，不应该改变工单被分到哪个队列。两个问题可以审视同样的证据，却读不到彼此的指令。分支之间没有计算上的依赖，哪怕它们的答案在统计上相关。

最后，概率让下游策略变得显式。如果一次不必要的升级代价是 1，而漏掉一个紧急个案代价是 9，那么一条简化的决策规则就是：当 p(urgent) > 0.1 时升级。这套算术有多大意义，取决于这些概率在该工作流中有多可靠。于是，训练并评估这个概率分布本身就成了产品的一部分，而不再是一个装点门面的 confidence 字段。

这一切都不需要扩散模型。并行分类已经存在几十年了。真正有意思的是这样一种组合：一个能力广博的 transformer、共享的上下文计算、一套带类型的输出接口，以及一种奖励「有用的不确定性」的训练方式。

1. 用一次读出结束推理

第一个组件最简单：用一个预测头取代解码循环。

已公开的证据。 TypeSafe 的发布公告写道：「Jev 并行输出所有概率，而不是按 token 自回归地生成。」它的文档暴露出有限选项、是/否判断，以及有序评分这几种类型。这些天然都可以用固定数量的数值输出来表示。12

观察到的证据。 API 里仍然有一个 output_tokens 字段，听上去像是在记录生成量。其实不是。对是/否问题，这个计数恰好对得上：4 个共享 token，每个答案 15 个，再加上每个问题标识符的 token 长度。TypeSafe 的文档说，这个标识符「不会发送给底层模型，也不参与推理」。一个会随着模型根本看不到的文本而变化的计数，必然是在推理之后、根据序列化的响应算出来的。返回的数值同样不影响它：答案是 0.0 和 0.01 的开销一样，尽管在别处每个数字都各算一个 token。224

这个计数背后的分词器，与我们测试过的 192 个公开分词器都对不上。它倒是与 Jev 自己的输入计数器在普通文本上吻合，只在长串空白和标点上有差异。output_tokens 是一个计费数字。它既不能说明 Jev 是否生成文本，就算生成了也测不到那些文本。延迟同样不跟着它走：一个带 200 个选项的问题（1,911 个 output token）返回得和只有两个选项时一样快，服务器耗时只随输入长度增长。2425

一个 255 选项的响应报出了 2,714 个 output token。4 若拿这个数除以请求耗时，再把结果称作模型的解码速度，那就错了。服务器完全可以在一次模型求值之后序列化出成千上万个字符。这个记账字段并不能告诉我们发生过多少次神经网络解码步。

我们设想的 readout 接受最后一层的隐藏向量 h，产出 logits：

z = Wh + b，p_i = exp(z_i) / Σ_{j=1..K} exp(z_j)

这里 K 是允许的答案个数。矩阵 W 把表征转换成各个答案的分数；softmax 再把这些分数变成一个分布。对于是/否判断，一个标量加一个 sigmoid 就够了。

这些类别不必是「payments」这样固定的概念。它们可以是选项槽位：第一个选项、第二个选项、第三个选项。每个槽位的含义由分支提供；应用代码再把它的概率映射回调用方的选项键。有序的 Score 类型同理，可以在各档位上预测概率，并返回它们的概率加权平均值。这样一来，支持新的决策就不必为每个客户的标签训练一个新的头。第 4 节里会对比的另一种主要方案是指针式打分器：它给每个选项自身的表征打分，而不是给一个编号槽位打分。

这并不能证明 Jev 里有一个单独命名的分类器模块。语言模型的词表头同样是「一个矩阵接一个 softmax」。从那个矩阵里挑出 K 行预留的标签行，能实现与专用 K 类分类头完全相同的计算。这些行可能与输入 embedding 绑定，也可能是独立训练的；从外部我们无法区分这两种安排。

真正重要的区别，在于把概率读出来和生成一段描述概率的文本。生成出来的「91%」是一串 token。分类器给出的 0.91 则是其预测分布中的一项。两者都可能校准不良。也没有哪一个仅凭格式就变得可信。

受约束的文本解码仍然是搭出类似接口的一种可行办法，但 TypeSafe 明确描述的是另一条输出路径。它的这一表态，比任何延迟层面的论证都更有分量。证据指向一次直接的数值读出，也就是第 4 节对比的两种设计之一。预留标签 token 的可能性依然存在，尽管那一节的伪选项实验对它不利。

下一个设计决策关乎：计算在哪里被复用。

2. 共享 state，隔离各个问题

观察到的证据。 在小规模受控例子里，token 记账是严格可加的。一个最小的是/否问题用掉 268 个输入 token；两个则是 276 个。一个同时包含一个是/否问题、一个两选项 Choice 和一个两档 Score 的请求用了 318 个，正好等于在共享开销之上各自实测贡献之和。这符合「一段公共前缀加若干问题后缀」的形状，尽管仅凭记账并不能确定计算图。4

更有信息量的实验，是把证据在这两个区域之间搬来搬去。state 最初写的是：

The weather is nice today and the park is full of people.

一个同级问题里则写着：

The secret code for this request is ZEBRA-7741.
Is the weather described as nice?

探针问的是「另一个问题里提到的是哪个代码」，选项为 ZEBRA-7741、两个干扰项和 none。当这个密语放在同级问题里时，它报出的概率是 0.00。把那个同级问题整个删掉，结果也一样。而把这句声明改放进 state，概率就升到 0.90–0.92。每种条件重复五次（探针记录中的 visibility）。5

这是一次有用的干预：把同一句声明挪到 API 边界的另一侧，它的作用就变了。这支持问题之间在行为层面是隔离的，同时都能访问共享的 state。但它并没有暴露出确切的注意力掩码。分开的模型调用、树状掩码，或者任何别的限制信息流动的机制，都能产生同样的结果。而且探针的措辞在 state 条件下仍然在问「另一个问题」，所以它并不是一次纯粹的字面指令遵循测试。

服务端的测量又补上一块拼图。在大约 100 个问题以内，服务器耗时几乎没变化；超过之后则稳步上升，而且按 token 计，问题文本的开销大约是 state 的两倍。这与「state 只算一次、问题部分成批处理」的做法是一致的。6

Longer stateone question

More questionsshort state

这些是服务器自报的上游耗时，不是本地笔记本上的计时。它们包含上游服务内部的一切工作与等待，而且该服务是与其他用户共用的。

Jev 施加了两条限制。每个分支（state 加一个问题）上限约 32,768 个 token，整个请求上限约 65,536 个。请求级的限制只把 state 算一次：一个 23k token 的 state 配 5,000 个问题仍然放得下。假如每个问题都各自处理一份 state 副本，这个请求就会超过一亿个 token。这两条限制恰好对应一条最长 2¹⁶ token 的打包序列：state 只放一次，所有问题排在它后面，而每个分支被限制在 2¹⁵ 的上下文窗口内。22

最自然的实现方式，是一份前缀 KV 缓存加上各自独立的因果后缀。Hydragen 描述了针对共享前缀序列的高效注意力；DeFT 则发展出面向树状结构推理的注意力。它们证明这种服务模式是可行的。它们属于既有工作，而不是 TypeSafe 使用了其中任一库的证据。78

这个设计还澄清了一处表面上的矛盾：相互隔离的问题，依然可以在同一块加速器上一起求值。「并行」描述的是它们的调度方式以及答案之间没有依赖，并不意味着一个问题占一块 GPU。

3. 因果骨干

这些实验无法区分因果 decoder 与双向 encoder：两种情况下，最终的决策都能读到全部输入。但我仍然假定是因果 decoder，理由充分。Jev 的知识广度（MMLU-Pro 上 84.6%）需要前沿规模的预训练，而这个规模上的模型无一例外都是因果 decoder；况且 TypeSafe 把 RLCD 描述成对一个预训练语言模型做后训练。一个双向版本的 Jev，要么意味着底座弱得多，要么意味着额外花成本把 decoder 改造过来，同时还要放弃因果式服务所带来的共享前缀缓存。那会很令人意外，但从外部也无法排除。1215

底座究竟是哪个预训练模型，我们不知道，分词器也没能给出答案。在 415 次探测中，Jev 的 token 计数与我们测试的 192 个公开分词器全都对不上。它把每个数字单独切开，并且会先整块查表再做合并：8 个 a 算作一个 token，16 个却算四个。它的词表与 OpenAI 的 o200k 高度贴近——凡是 Jev 算作单个 token 的字符串，在 o200k 里也都是单个 token——但数字切分和若干处合并方式又排除了 o200k 本身。最接近的公开分词器是 Qwen，在 415 次探测中有 348 次吻合。这排除的是「未经改动的公开分词器」，而不是「公开的基础模型」：换过词表、继续预训练或蒸馏，都能解释这一点；API 的 token 计数方式与模型本身不同，同样能解释。18

不过实验确实揭示了决策能够读到什么。我在一个问题的选项中间塞进一张「参考卡」，然后让 Jev 挑出那个条件被这张卡满足的选项。下面是其中一组确切的选项：

alpha: Reference card: status = amber. Reference-only option.
       Never select this option.

beta: Select this option if the reference card's status is amber.

gamma: Select this option if the reference card's status is indigo.

指令是：「读取参考卡，选出唯一一个条件被满足的选项。」把参考值改成 indigo，正确答案就换了一个，而可选项本身纹丝未动。

我测试了两种取值、全部六种选项排列，以及第二套使用 route = east/west 的模板，每组重复两次。配对的对照组则把参考卡改放进共享 state。这样一共得到 48 次「参考卡在选项中」的试验和 48 次「参考卡在 state 中」的对照。20

参考选项所在位置	答对次数
首位	12 / 16
中间	11 / 16
末位	16 / 16
参考卡移入 state	48 / 48

Jev 能够利用排在候选描述之后的信息。 当参考卡放在最后时，它在每一次试验中都选中了正确选项，正确答案的平均概率约为 0.88。

α Reference cardβ · γ Candidate answers

Card first12/16 correct

0.50 6/8

0.56 6/8

Card in the middle11/16 correct

0.49 4/8

0.56 7/8

Card last16/16 correct

0.89 8/8

0.87 8/8

Card in the shared state48/48 correct

1.00 48/48

取值切换这个对照，和位置一样重要。卡片放在最后时，仅仅把 amber 改成 indigo，胜出的就换成了另一个靠前的选项——尽管那些靠前选项的描述和 state 完全没变。如果一个模型只是根据每个选项自己的文本加上 state 独立打分、随后简单归一化，那么这个事实根本没有渠道去改变靠前选项之间的相对排序。这些结果支持存在一条让选项影响联合决策的通路。20

这与任何「在整份列表之后才计算」的 readout 都相容，包括第 4 节对比的两种设计，也包括一个单独的选项混合阶段。剩下的那些错误说明，在这两套模板上处理是位置敏感的；但它们并不能指认出唯一的成因。

这种计算并不需要扩散，实验中也没有任何东西要求迭代去噪。站得住脚的架构推断要窄得多：答案的计算能够访问完整的选项列表。下一个实验要检验的是：它是否真的用上了这份联合上下文。

4. 让选项在选出之前先相互作用

在单个问题内部，证据指向另一条信息边界：各个候选项作为一份有序列表被一并读入，其后跟着一个决策位置。

为什么要允许这种相互作用？像「以上都不是」这样的选项，本就依赖于其他候选项。即便是普通的候选项，也能让问题本身变得更清楚。「支付」「账户访问」「其他」所定义的决策，与「银行」「支付服务商」「客户」所定义的并不相同。列表式（listwise）的表征，让模型在产出分布之前就能读懂这种区别。

最有力的证据来自一个「加入无关多余选项」的实验。

先给出打款失败的四个可能原因：bank、provider、customer 和 unknown。然后追加一个 weather: Bad weather caused it。如果每个原有选项都拿到一个独立且不变的 logit，而服务端又用同样的 softmax 温度，那么增加第五个选项只会改变归一化，却不可能改变两个既有选项之间的几率比：

p(customer) / p(unknown) = exp(z_customer − z_unknown)

公共分母被约掉了。这给了我们一个具体且可证伪的预测。

最初那项研究发现它从大约 +0.49 变成了 +0.08。10 为了检验这是否扛得住普通的请求波动，我把实验重做了十个随机化区组。每个区组包含：四选项基线、一个完全相同的四选项对照、追加了 weather 的五选项版本、一个完全相同的五选项对照，以及一个把新增描述由「Bad weather caused it」改成「Wild birds caused it」的五选项版本。每个请求只含一个问题。21

扩充选项这一结果复现了。把每个区组内每种条件下两个相同请求合并后，平均对数几率从 +0.38 降到 +0.11。每个区组都出现了下降；平均变化为 −0.28，描述性的 95% 配对 t 区间约为 −0.36 到 −0.19。这里的合并是用对照请求来削减普通的请求噪声，而不是把重复输出当成彼此独立的实验。21

4 options5 optionsAdd “bad weather caused it”

1 −0.02

2 −0.36

3 −0.26

4 −0.46

5 −0.26

6 −0.21

7 −0.28

8 −0.35

9 −0.33

10 −0.25

Mean −0.28

Fixed scores + fixed temperature

The dots would coincide

Observed

Lower in all ten blocksMean change −0.28 · 95% interval −0.36 to −0.19

这是对「固定独立 logit 加上不变 softmax」这一假设的反证。但它并不能唯一地指认机制。在保持五个选项的前提下改动新增描述，带来的偏移更小，且不具结论性：它的配对区间包含零。除了依赖内容的混合之外，一个随选项集合而变的温度依然是可能的。

一个能看到完整列表的 readout 可以自然地解释这一点：加一个选项，就改变了它所读取的上下文。FIRST 这套列表式排序方法也是同样的做法——从首个 token 的 logits 里抽取排序，而不是逐 token 生成出来。11

有两种 readout 与证据相容。一种是末位置分类头：从决策 token 的表征出发，给每个选项槽位打分；另一种是指针式打分器：把那份表征与每个选项自己的最后一层隐状态做比较。两者都允许选项彼此影响。API 最多接受 255 个选项（2⁸ − 1），这与一个固定 256 槽位的分类头很吻合，但该限制是由请求校验强制的，而非模型。而在 200 个选项时，一个被复制的答案在任意位置都拿到 1.00 分，错误也没有溢到相邻选项上，这又更像指针式。两个结果都不具决定性。26

注入的伪选项从未挤掉过真选项，可见选项边界是以文本无法伪造的方式标记的；而一个条件在列表别处被重复的选项，会把概率输给它的竞争者。23

这种代价在普通任务里同样可见：把选项顺序倒过来，一个技术支持分类的概率就从大约 0.84–0.89 挪到了 0.93–0.96。这来自 option_order 探针。9 对一套已上线的决策策略来说，这很要紧。哪怕标签和证据完全一样，一个设在 0.9 附近的阈值就可能改变最终动作。任何按这一设计做出的实现，在评估时都应当包含排列检验。

5. 先训练分布，再计算 confidence

第五个组件是训练目标。直接输出数值省下了解码的工作量，但便宜的概率照样可以是糟糕的概率。

设想一批被判定为「紧急概率 0.8」的个案。校准问的是：其中是否真的有大约 80% 属于紧急。这是一批预测在整体上的性质。我们没法凭某一个个案的结果好坏，去判断那一条预测是否校准。

TypeSafe 把自己的训练方法称作 Reinforcement Learning for Calibrated Decisions（RLCD，面向校准决策的强化学习）。发布公告说它优化的是「在 System One 任务上给出认知上诚实的概率的答案」；公司的入门材料则把 RLCD 描述成一条从预训练语言模型出发的后训练路径。112 确切的配方并未公开。我所设想的训练配方，是用一个基于结果的目标函数，把 transformer 和 readout 适配到带类型的决策任务上。这让骨干有机会去构建对可靠决策有用的表征，而不只是流畅的续写。

一个自然的目标函数是对数损失，即对观测到的结果 y 取 −log p(y)。另一个是 Brier 损失，即预测分布与观测到的 one-hot 结果之间的平方距离。两者都属于恰当评分规则（proper scoring rules）：在期望意义上，报告真实的条件分布能使损失最小。Gneiting 与 Raftery 给出了形式化定义与理论。13 这解释了这类训练想要达成什么，但并不能确定 TypeSafe 用的是哪种损失、其流水线是否属于狭义算法意义上的强化学习，也不能确定骨干的每一个权重是否都参与更新。

「恰当性」同样不是上线后的保证。有限的数据、模型自身的局限、优化误差以及分布漂移，都会让校准留有缺口。Guo 等人既展示了现代神经网络的校准问题，也展示了事后调整的用处。训练与事后校准是可以并存的机制；而从 API 外部无法区分二者各自的贡献。14

观察到的证据。 基准测试记录让我们能把预测概率与实测准确率对照起来看——既看总体，也看各个概率分箱。图中展示的就是这些检查。只看平均值的吻合，其证据强度弱于分箱内的吻合：一组里的过度自信可能被另一组里的信心不足抵消掉。在 1,200 题的 MMLU 样本上，十分箱的期望校准误差为 0.0313（分箱定义与逐题预测）。绝大多数预测都集中在接近确定的一端：有 990 条落在 0.9–1.0 这一箱里。15

MMLU sample1,200 items · ECE 0.031

Fresh maths8 generated families · 20–30 items each

那项小规模的新鲜数学题研究补上了有用的变化。在生成的三位数乘法题上，准确率为 86.7%，平均最高概率为 0.83。在两步应用题上，准确率降到 32%，平均最高概率降到 0.30。模型在更难的任务上确实更不自信（fresh_math_results，含 30 道乘法题与 25 道应用题）。15 这是个积极的信号，尽管小样本的类别级平均值，并不能证明它对各种没见过的题目都能保持校准。

这些结果也说明，为什么公开基准分数并不能很好地衡量模型到底知道什么。MMLU-Pro 上的准确率是 84.6%；而新生成的应用题要难得多。15 任务结构、干扰项、难度以及训练时的接触程度，都可能是原因。这个落差并不能证明基准被污染了。 换一套新说法，也并不会让底层的数学技能或事实知识变成「没见过」。

关于 API 里那个叫 confidence 的字段，还有一个独立而异常清晰的发现。官方适配器在 K > 1 时，按下式从归一化后的分布计算 Choice 的 confidence：

c = (p_max − 1/K) / (1 − 1/K)

三个选项、最大概率为 0.8 时，算出来是 0.7。单选项的情形由适配器单独处理，直接返回 1。它衡量的是领先答案比均匀分布高出多少，而不是另一个「该答案正确」的学习估计值。Score 类型用的是另一个公式，反映的是与众数档位之间的距离。16

在这套设想的系统里，训练产出的是预测分布；而这个汇总字段只是普通算术的产物。把这两样东西分开，可以避免一个常见的概念错误：一个高度集中的分布，照样可以是自信地错着。

6. 稀疏容量

我预计 Jev 用的是稀疏 mixture-of-experts transformer。在选定的层上，一个路由器把每个 token 只送进一小部分前馈网络，于是模型可以存下大量参数，却只为每个 token 激活其中一部分——这正是 Shazeer 等人用稀疏门控 MoE 层验证过的条件计算思路。17

稀疏专家从外部观察不到，但它是更可能的选择。一个只做 prefill 的模型受限于算力，而稀疏路由省下的恰恰就是算力。MoE 通常的服务开销在这里大多消失了：没有逐 token 的解码——那正是内存带宽占主导、且多数专家最终都会被激活的场景——也没有长期驻留、与专家权重争抢显存的 KV 缓存。测量结果也指向同一方向。Jev 处理约 30k token 用了大约 160 毫秒；一个稠密的 70B 模型在 8×H100 节点上大概需要一秒，而一个约 10B 激活参数的 MoE 正好对得上。何况近期最强的基础模型大多是 MoE（DeepSeek-V3、Qwen3、GLM-4.5、Kimi K2、gpt-oss）。专用硬件也可能让稠密模型达到同样的速度，而基准分数又可能高估了模型实际掌握的知识量，所以这仍然是推断，而非测量。615

整个复原方案中再没有别的部分依赖它。换成一个稠密 transformer，接口、共享 state、隔离分支和 readout 都还是前面描述的样子。

7. 把分支当成批处理来调度，而不是当成一场对话

最后一个组件是服务引擎：它把问题分支当作彼此独立的工作项。这些后缀可以被打包成批，同时读取共享的 state 表征。之后由应用代码把数值输出与问题标识符对应起来，再序列化成响应。

测量显示，重复的相同回答之间存在微小差异，包括同一个请求内重复问题之间的差异。这意味着不应假定 API 层面是确定性的（noise、dup 和 determinism）。19 但这并不表示模型在生成或采样文本：数值内核、动态批处理、路由，乃至刻意引入的随机性，都会影响一次直接读出。

响应中键的顺序也会变化，呈现出少数几种反复出现的模式。19 一个合理的解释是：存在多个 worker，各自的哈希顺序不同。不过这条侧信道既不能确定 worker 的数量，也说不清 KV 缓存放在哪里，更无法告诉我们用的是什么数值精度。这些都是现有观测无法解决的实现细节。

对这套设想的架构而言，真正重要的是答案之间不存在依赖链。模型不需要先把队列分类写完，才开始估计紧急程度。两者都依赖 state，谁也不消费对方生成的答案。

当然也还有依赖上的边界。如果后一个问题确实需要前一个问题的答案，应用就必须再引入一个决策阶段，或者把这个联合决策表达成一个问题。共享上下文并不会消解工作流本身的逻辑结构。

什么会让我改变看法？

这套复原方案里的各项主张，可靠程度并不相同。直接输出概率是公开说明过的。问题隔离与选项顺序效应是可观察到的行为。而 KV 共享、因果注意力、末位置或指针式 readout，以及稀疏专家，则是层层递进、越来越具体的解释。

参考卡实验敲定了一件事：决策能够用到排在最后的选项。伪选项实验则表明，在输入格式上做手脚伪造不出选项边界。更广泛的关系型任务可以进一步约束对表征的猜测，不过仅凭行为上的成功，仍然无法唯一确定一个注意力掩码。

在选项处理方面，随机化的后续实验复现了选项集合效应，但「保持选项数不变、只改描述」那一项干预仍无定论。更多模板和相互独立的请求区组，才可能把「共享温度的变化」与「依赖内容的交互」区分开。而一个在 200 选项下具有中等难度的任务，或许能把槽位分类头和指针式打分器分辨开来。至于校准，留出的真实工作流数据和在分布漂移下的重复评估，都比再来一个总体基准分数更有意义。要确认稀疏专家，大概得等一次披露，或者依靠这套 API 之外的证据。

我对 Jev 最好的复原，仍然是开头那张图：一个因果 transformer，带有共享的 state 前缀、彼此隔离的问题后缀、列表式的选项处理、带类型的数值读出，以及面向预测分布的训练。稀疏专家很可能就是它的骨干，尽管设计中其余部分并不依赖于此。

它的价值来自让计算图贴合任务本身。一个决策服务需要读取证据、比较被允许的结果，并把不确定性暴露出来。transformer 完全可以做到这些，而不必先把每一个决策变成一个句子。

方法

本文基于 2026 年 9 月 17 日对 jev-1.13.0 的一次调查，使用了一个早期访问账号和一个可观察到的服务区域。原始研究包含 1,029 条带埋点的探针记录（含 190 道生成的数学题）、6,800 条基准测试记录，以及若干独立的事实性核查。后续研究又补充了 146 个关系型与选项交互请求（试验、汇总）、311 个 token 记账请求、445 个分词器指纹请求、192 个延迟请求、148 个选项数量延迟请求、181 个选项位置请求、105 个伪选项请求和 35 个上下文上限请求。每一项都在参考来源中给出链接，并附有确切的请求与脱敏后的响应。重复的基准配置共用同一批底层题目；这些数字不是独立题目的数量。

可下载的证据包记录了本文所用的观测。开头那节的 API 示例是示意性的。文中引用的 visibility 与参考卡 prompt 来自探针脚本和保存下来的后续请求。数值层面的观测只对这个模型版本和这轮测试成立。

延迟数据取自 x-envoy-upstream-service-time 响应头。它们是上游服务的耗时，排队与执行的边界未知，并不是孤立的模型计时。延迟图的扫描是以打乱顺序、一次一个请求跑出来的；所有研究都没有控制服务器负载。本地的墙钟计时没有被用作架构证据。

概率通常以两位小数精度返回。同一请求内的重复问题共享条件，误差之间可能相关。MMLU 校准图采用十个等宽分箱：[0, 0.1)、[0.1, 0.2)，依此类推，1.0 归入最后一箱。期望校准误差是各箱内准确率与平均最高概率之差的绝对值、按样本量加权求和。这些估计依赖于样本选取、分箱方式与响应的舍入。证据支持的是关于所测分布的结论，而不是对未来客户工作流的校准保证。

来源与相关工作

实验类引用标出了原始脚本的标签，以便在证据包中定位每一条观测。论文引用用于说明所提机制及其先例；它们并不能证明 Jev 使用了这些方法。

参考来源

1. TypeSafe (2026)：Introducing System One Models and Jev。并行输出主张与 RLCD 目标表述的第一手来源。
2. TypeSafe：完整 API 文档，访问于 2026 年 9 月 17 日。带类型的问题、响应分布与 API 契约。
3. Vaswani et al. (2017). Attention Is All You Need。decoder 掩码、注意力，以及线性/softmax 输出层。
4. API 实验：type_preamble 与 outputs。token 记账的可加性、标识符变化，以及 255 选项响应。
5. API 实验：visibility。密语分别放在同级问题中、从该同级问题移除、以及放入 state，每种条件各重复五次。
6. 延迟扫描（192 个顺序请求）。state 长度与问题数量，各 8 次打乱重复；服务器自报的上游耗时。
7. Juravsky et al. (2024). Hydragen: High-Throughput LLM Inference with Shared Prefixes.
8. Yao et al. (2024). DeFT: Decoding with Flash Tree-attention for Efficient Tree-structured LLM Inference.
9. API 实验：option_order。普通工单场景下的顺序敏感性。
10. API 实验：iia。每种条件三个请求，每个含四十个重复问题；原始、追加与前置三种选项集。
11. Reddy et al. (2024). FIRST: Faster Improved Listwise Reranking with Single Token Decoding.
12. TypeSafe：机器学习入门材料。RLCD 后训练路径与校准契约的第一手描述。
13. Gneiting and Raftery (2007). Strictly Proper Scoring Rules, Prediction, and Estimation. Journal of the American Statistical Association 102(477):359–378.
14. Guo et al. (2017). On Calibration of Modern Neural Networks.
15. 基准测试与生成数学题记录：准确率与平均预测概率。 ; MMLU 可靠性分析：分箱定义、ECE、Wilson 区间与 1,200 条逐题预测。
16. TypeSafe：官方 Python 适配器 confidence_metrics.py，修订版 fb52b103。Choice 与 Score 的 confidence 公式（读取于 2026 年 9 月 17 日）。
17. Shazeer et al. (2017). Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer.
18. 分词器指纹实验（445 个请求）。游程长度、词表与预分词探针，与 192 个公开分词器比对。
19. API 实验：noise、dup 与 determinism。重复概率与响应键顺序。
20. 后续关系型实验（96 个请求）。两套模板、两种参考取值、六种排列、两个放置位置，各重复两次；附确切请求与脱敏响应。
21. 后续选项交互实验（50 个请求）。十个随机化区组，含 base4、null4、append5、replace5 与 null5；配对变化与标准误。
22. 上下文上限实验（35 个顺序请求）。分支级与请求级 token 上限，含被接受与被拒绝的边界样例。
23. 伪选项注入实验（105 个请求）。七种分隔符格式、饱和与含混的基础任务，以及完整概率向量。
24. token 记账实验（311 个请求）。问题 ID 长度、批大小、state 难度、词形 ID，以及等长的 state 与 ID 字符串对照。
25. 选项数量延迟实验（148 个请求）。1 个或 20 个问题，选项 2–200 个，长短标签，外加输入/输出解耦对照。
26. 选项位置实验（181 个请求）。选项数量上限，以及正确答案在 10、50、200 与 255 选项列表中的位置移动。

---

— Archer