一个人用 10000 次 API 调用，扒出 Jev 的底层架构

中文旁白 · 720p · 字幕轨道 · MP4

文章：1 万次 API 调用，从外部拆解 Jev 的架构

假设你让一个大模型判断「这条客户投诉该转给哪个团队」，它回答「我 90% 确定应该转给支付团队」。这个 90% 听起来很可靠，但它其实只是模型逐字生成的一段文本，和人在聊天框里随手打出「我觉得有九成把握」没有本质区别。它不是经过训练的数字，下游系统不能把它当作真实概率来用。

Jev 想解决的正是这个问题。Jev 是 TypeSafe 发布的决策模型：它不生成文本，而是直接返回经过训练的概率分布。模型发布后，X 上出现了大量分析，但 Archer Hume 认为其中多数都说错了。于是他花了约 10000 次 API 调用，从延迟曲线、token 计数、选项顺序敏感性等角度做实验，试图从外部把 Jev 的架构「摸」出来，并写成了文章《Jev's Architecture Unmasked》。本文按视频的顺序整理他的发现。需要先说明的是，这些结论的可信程度并不相同：有的是 TypeSafe 官方的说法，有的是可以复现的实验结果，还有的只是作者的推测，下文会逐一标明。

Jev 怎么用：一段共享状态，加一组问题

调用 Jev 时，请求由两部分组成。第一部分是「共享状态」，即所有问题都要参考的背景信息，例如客户投诉的原文。第二部分是一组问题，例如「该转给哪个团队？选项：支付 / 账户 / 其他」，以及「是否需要紧急升级？是 / 否」。

Jev 不会回一段话，而是为每个问题返回一个概率分布，例如「支付」91%、「账户」6%、「其他」3%，「升级：是」42%、「否」58%。业务代码拿到这些数字就能直接决策：支付的概率超过阈值就自动分配，升级的概率不够高就走普通流程。

按照 TypeSafe 官方的说法，Jev 的输出是「并行的概率」，而不是逐个 token 自回归生成的。它支持的问题类型有三种：有限选项、是非判断和有序评分。这些类型天然对应固定数量的数值输出，不需要一个字一个字地「写」出来。

证据：它确实不生成文本

作者首先检查了 API 响应里的 output_tokens 字段。这个名字听起来像是在记录模型生成了多少 token，但数字的规律很奇怪：对于是非题，它恰好等于 4 个共享 token，加上每个答案 15 个 token，再加上问题标识符的 token 长度。而 TypeSafe 的文档明确写着，问题标识符「不会发送给底层模型，也不参与推理」。一个会随着模型根本看不到的文本而变化的计数，只能是推理结束后从序列化的响应里算出来的，它是账单用的数字，而不是生成长度。

更有说服力的是延迟实验。一个有 200 个选项的问题（按上述方式算出 1911 个 output_tokens）和一个只有 2 个选项的问题，返回速度几乎一样。服务器耗时只随输入长度增长，而不随选项数增长。如果模型真的在逐字写出答案，200 个选项的回复不可能和 2 个选项一样快。

概率从哪里来：readout（作者推测）

TypeSafe 只说了「并行输出概率」，没有公开具体机制。作者推测的机制叫 readout，也就是「读出」：模型处理完输入后，取最后一层的隐藏向量，乘以一个权重矩阵、加上偏置，再经过 softmax，直接得到每个选项的概率。softmax 是把一组原始分数变成总和为 1 的概率分布的标准运算。是非题更简单，一个标量加 sigmoid 就够了。整个过程里没有「下一个词是什么」的循环。

共享状态和互相隔离的问题分支

假设共享状态是一份很长的事故报告，后面跟着 50 个问题。如果每个问题都单独处理，模型就要把这份报告重复理解 50 遍；如果状态只编码一次，每个问题只处理自己的指令和选项，再去参考已经编码好的状态，计算量就会大幅减少。

Transformer 模型处理文本时会留下一种缓存，叫 KV cache，存放的是已处理 token 的中间信息。作者推测，Jev 先把共享状态编码进 KV cache，再让每个问题作为独立的「分支」复用同一份缓存，只额外计算自己那一部分。

实验结果支持这个推测。只有一个问题时，把状态逐渐加长，服务器耗时从几十毫秒缓慢上升，到约 30000 个 token 时约为 218 毫秒。反过来，固定一个很短的状态，把问题数从 1 增加到 1500，耗时也只涨到几百毫秒。如果每个问题都要重新处理一遍状态，1500 个问题不可能这么快。

另一个巧妙的实验是「秘密代码」测试。作者在一个问题里写入「这个请求的秘密代码是 ZEBRA-7741」，再在另一个问题里问「刚才提到的秘密代码是什么」。结果另一个问题完全看不到这个代码，给出的概率是 0.00；而把同一句话放进共享状态后，概率跳到 0.90 到 0.92。每个条件重复五次，结果一致。可见问题之间彼此隔离，但都能看到共享状态。这在产品上也说得通：「客户是不是在生气」这个问题不应该影响「工单该分给哪个团队」的判断，两个问题看同样的证据，却互不干扰。

Jev 还有两个硬性上限：每个分支（状态加一个问题）最多约 32768 个 token，整个请求最多约 65536 个 token。计算请求上限时状态只算一次，所以 23000 token 的状态加上 5000 个问题也能放下。作者推测，这对应一个最长 2 的 16 次方个 token 的打包序列：状态放在最前面一次，所有问题排在后面。

选项之间会互相影响

这部分实验最有意思。如果模型对每个选项独立打分，再用同一个 softmax 温度归一化，那么加入一个不相关的选项，不应该改变原有两个选项之间的概率比，因为分母是公共的，相除时会被消掉。这是一个可以精确检验的预测。

作者的原始问题是分析一笔支付失败的原因，有四个选项：银行、服务商、客户、未知。然后加入第五个完全无关的选项「坏天气导致的」。他做了十个随机化区组，每个区组包含四选项基线、五选项版本以及各自的对照组。汇总结果是：「客户」对「未知」的 log-odds（两个概率之比的对数）从 +0.38 降到 +0.11，平均变化 −0.28，十个区组全部下降，95% 配对 t 区间约为 −0.36 到 −0.19。

这说明选项并不是被独立打分的，模型在给出分布之前，把整个选项列表当作一个整体来读。作者推测 Jev 采用 listwise（列表式）的处理方式：整个选项列表构成一个上下文，模型在最后一个位置综合所有信息后再输出分布。

「参考卡片」实验进一步佐证了这一点。作者在选项中混入一张写着「状态 = 琥珀色」的卡片，让模型选出条件被满足的选项。卡片放在列表最后时，16 次全部正确，平均概率约 0.88；放在最前面时只对了 12 次，放在中间只对了 11 次；而把参考信息移到共享状态里，48 次全部正确。更关键的是，只把卡片上的值从「琥珀色」改成「靛蓝色」，前面那些文本完全没变的选项中，胜出者就会改变。这意味着存在一条信息通路，让后面选项的内容影响前面选项的相对排名。不过作者也指出，这个实验存在位置敏感性，不能唯一确定背后的注意力掩码结构。

校准：这个概率可信吗

输出概率本身不难，难的是让概率真正可信，这就是「校准」：如果模型对一批案例都给出 80% 的概率，那么这批案例里应该真的有大约 80% 是对的。TypeSafe 把自己的训练方法称为 RLCD（Reinforcement Learning for Calibrated Decisions，基于强化学习的校准决策）。官方说法是在预训练语言模型的基础上做后训练，优化目标是「具有认知诚实概率的 System One 任务答案」，但具体训练方案没有公开。

作者在 1200 题的 MMLU 样本上检验了校准效果（MMLU 是覆盖多个学科的大型基准测试）。他把模型给出的最高概率分成十个区间，看每个区间的实际正确率是否匹配。整体的期望校准误差 ECE 为 0.0313，算是不错的数字。但 1200 题中有 990 题落在 0.9 到 1.0 这个区间，也就是说模型对大部分题目都非常自信。

作者还用新生成的数学题做了测试，结果如下：

前两类的预测和实际很接近，两步应用题上模型也确实「知道自己不太行」；模幂运算则是例外，模型明显低估了自己。

另一个容易误解的地方是 API 返回的 confidence 字段。它并不是模型的「第二层把握」，而是按公式算出来的：对选择题，confidence =（p_max − 1/K）/（1 − 1/K），其中 p_max 是最高概率，K 是选项数。三个选项、最高概率 0.8 时，confidence 为 0.7。它衡量的只是最高概率比均匀分布高出多少，不是另一个独立训练的可信度指标。

骨干网络是 MoE 吗（最不确定的推测）

作者推测 Jev 的骨干用了 MoE（Mixture of Experts，混合专家）架构：模型总参数量很大，但每次推理只激活其中一小部分专家网络，由路由器决定每个 token 交给哪些专家处理，这样既有大模型的知识容量，又不必每次跑完全部参数。

他的理由是，Jev 只做 prefill（一次性读入输入的预填充阶段），不做逐 token 解码。prefill 的瓶颈是计算量，而 MoE 恰好省计算；MoE 在自回归解码时的劣势，即内存带宽瓶颈和大部分专家最终都会被激活，在这里都不存在。数字也对得上：文中提到 Jev 处理约 30000 个 token 只用约 160 毫秒，一个 700 亿参数的 dense（密集）模型在 8 块 H100 上大约需要一秒，而激活参数约 100 亿的 MoE 模型就能达到这个速度。此外，最近最强的基座模型如 DeepSeek-V3、Qwen3、GLM-4.5 基本都是 MoE。

但作者自己也承认，这是整个推测中最不确定的部分：稀疏专家从外部根本观测不到，专用硬件也可能让密集模型达到同样的速度。好在其他所有推测都不依赖 MoE 这个假设，换成密集模型，接口、共享状态、隔离分支和概率读出都不受影响。

调度方式与结果的微小波动

最后一个组件是服务引擎。作者认为，Jev 把问题分支当作独立的工作单元来调度，而不是当作一轮对话；各分支的后缀可以打包成一个批次，共享同一份状态表示，再由应用层代码把数值结果和问题标识符对应起来，序列化成 JSON 返回。

实验中还发现，完全相同的请求重复发送，返回的概率会有微小差异，甚至同一个请求里重复的问题也会给出略有不同的答案。因此不能假设 API 是完全确定性的。但这并不说明模型在「生成」或「采样」文本，数值精度、动态批处理和路由策略都可能带来这种波动。

结论的边界与尚未解开的问题

这项分析基于对 jev-1.13.0 版本的测试，共约 10000 次 API 调用，包括 1029 条探针记录、6800 条基准测试记录，以及后续数百次专项实验，所有请求和脱敏后的响应都已公开。作者也清楚地划出了边界：直接输出概率是 TypeSafe 官方公开的说法；问题隔离和选项顺序效应是可观测的行为；KV cache 共享、因果注意力、读出头的具体形式和 MoE，每往后一步，确定性就低一层。

还有一些问题目前无法回答。Jev 的基座模型是哪个？它的 tokenizer 与 192 个公开 tokenizer 都不完全匹配，和 OpenAI 的 o200k 最像但仍有差异；最接近的是 Qwen 系列，415 个测试探针中匹配了 348 个，但也不完全一致。另外，MMLU-Pro 上 84.6% 的准确率与新生成数学题上的明显落差，究竟来自训练数据暴露还是任务结构不同，也说不清。

如果你在做分类、路由、风控、内容审核这类决策任务，Jev 这种「不写文字、直接给概率」的思路值得关注。这次外部拆解说明，它确实不逐字生成，问题之间相互隔离、共享同一份状态，而选项之间并不独立。但校准只在训练分布附近有效，用到自己的业务场景时，一定要用自己的数据重新验证。

视频里每节都区分了「官方 / 实验 / 推测」。原文：Jev's Architecture Unmasked。日文新版在 /ja/。