有人只用一万次接口调用，就把一家AI公司的架构秘密扒了个底朝天！
不开源、不发论文，照样藏不住底裤，这才是真正的黑箱破解术！
一位独立研究者花两周时间，对TypeSafe公司刚发布的Jev模型发起一万次API探测，仅凭延迟曲线、token计数和拒绝规则，就复原出这个闭源模型的完整架构骨架，直接把"闭源等于安全"的行业迷信按在地上摩擦。
一个叫Jev的黑箱模型突然火了
事情要从2026年9月说起，一家名叫TypeSafe的公司发布了一款叫Jev的模型，官方定位是"System One决策模型"，专门用来做分类、路由、风控这类结构化判断。
它跟ChatGPT、Claude这些聊天机器人长得完全不一样，不聊天，不写代码，不写作文，你给它一段文字加几个问题，它直接吐出概率数字。比如你问"这个工单该转给支付团队还是账户团队"，它不会跟你解释半天，直接告诉你：支付91%，账户6%，其他3%。
有意思的地方在这里，TypeSafe拒绝公开模型权重，也不发技术论文，官网上只有一篇宣传博客和一份API文档。X（推特）上一堆人开始阴阳怪怪，说什么"一个JSON分类器凭啥值1200万播放量""这就是AI泡沫的证据"。
ChatGPT说九成确定时它到底在干什么
你问ChatGPT这封邮件是不是钓鱼邮件，它回你一句九成确定是钓鱼邮件，这个九成是它编出来的文字，不是数学意义上的概率！自回归语言模型（Autoregressive Language Model）逐token生成，每个token都是基于前文采样，它输出“九成”只是因为训练语料里类似语境常跟这个数字，而不是内部算出了0.9这个概率值。
这类模型天生适合聊天，它逐字往外吐，拼出自然语言，但结构化决策需要的是可计算的概率分布，不是一段看起来像概率的文本。你把这串文字抠出来喂给风控系统，就是拿语言模式冒充数学，垃圾进垃圾出。
TypeSafe的Jev走另一条路，它不生成任何文字，输入状态和问题后，直接在前向传播最后一层接一个线性层加softmax，输出每个选项的概率，这个动作叫分类头（classification head），存在了十几年，但在Jev这里成了核心差异！
一万次API调用揭开黑箱底裤
一位署名archerhume的研究者不服这个邪，他做了一件很硬核的事：用一万次API调用，反推Jev的内部架构。
方法说起来很朴素，就是变着花样发请求，观察三个东西：延迟变化、token计数、拒绝规则。你把状态文本加长100倍看响应时间怎么变，把问题数量从1个加到1500个看服务器怎么反应，把选项顺序打乱看概率怎么飘，一点一点拼出模型的形状。
黑箱探测（black-box probing）这套路本身不新鲜，早期研究人员就是靠数token拒绝率来猜GPT-3的tokenizer，靠观察响应延迟来推测模型层数。但把这套方法系统化地用在一个刚发布的商业模型上，还写出完整的架构复原报告，这就有点狠了。
大语言模型的一个根本性设计缺陷
要看懂这次破解的价值，得先搞明白当下大语言模型在做决策时的一个根本性设计缺陷。
你去问ChatGPT"这封邮件是不是钓鱼邮件，给个置信度"，它会回你一句"我90%确定这是钓鱼邮件"。看起来很清楚对吧？但这个90%完全是它编出来的文字，不是数学意义上的概率！
它内部并没有真的算出0.9这个数字，只是根据语言模式，觉得在这个语境里说"90%"比说"70%"或"99%"更顺口。你把这个90%当成概率喂给下游系统去做风控决策，就是把一段文字冒充成数学，这在工程上叫垃圾进垃圾出。
autoregressive（自回归）生成，就是这个问题的根源。模型一个字一个字往外吐，每个字都是基于前面所有字的概率采样，最后拼出一句自然语言。这种机制天生适合聊天，但根本不适合做结构化决策。
Jev的做法非常反直觉：干脆不生成文字，直接从模型内部读概率。
具体是这么干的：你给它一段状态文本，比如客户的投诉内容；再给它几个问题和允许的答案，比如"该转给哪个团队：支付、账户、其他"。模型走完前向传播，在最后一个位置直接接一个线性层加softmax，输出三个数字：0.91、0.06、0.03。
一个可以反过来验证的实验
archerhume怎么证明Jev真的没在生成文字？他抓住了一个细节：API返回值里有个字段叫output_tokens，看起来像是记录生成了多少token。
但他做了个实验，问了个有200个选项的问题，返回output_tokens是1911。按正常大模型的生成速度算，输出1911个token至少要几秒钟，但Jev返回时间跟只有2个选项的问题一样快，都是几十毫秒。
再来一个更狠的：他改变返回值本身，让某个选项的概率从0.0变成0.01，按理说多一个字符就多一个token，但output_tokens纹丝不动。这就说明这个数字是服务器根据某种规则算出来给你收费用的，跟模型实际生成没关系。事情已经很清楚，模型压根没在decode（解码）！
Jev的API返回值里有个字段叫output_tokens，看起来像记录生成了多少token，但200个选项的问题返回1911，返回时间跟2个选项的问题一样快，都是几十毫秒！你改变某个选项概率从0.0到0.01，output_tokens纹丝不动，说明这个数字是服务器根据序列化响应算出来的计费字段，跟模型实际解码无关。
这直接导致一个判断，Jev在prefill（预填充）阶段就结束推理，不做自回归解码，所以它没有token-by-token依赖，输出概率不需要逐字拼写！分类头从隐藏向量h直接算z=Wh+b，再softmax，得到概率分布。
一万次请求怎么摸出共享状态
状态共享才是真正的杀手锏
搞清楚了输出机制，下一个问题是：如果你要问同一段文字20个问题，模型是重复处理20次，还是只处理1次？
大模型内部有个东西叫KV cache（键值缓存），存的是每个token在每一层的中间表示。正常情况下你发一个新请求，KV cache就要重新算一遍。但Jev发现了一个巧妙的做法：把共享的状态文本放前面，KV cache只算一次，后面每个问题分支都能读这份缓存。
archerhume用延迟曲线验证了这件事。他固定状态文本，把问题数量从1个加到1500个，服务器时间从86毫秒涨到610毫秒。什么概念呢，一次性回答1500个独立问题，只要半秒多。如果每个问题都独立处理一遍状态，那这个请求得跑好几分钟。
更硬的证据是token上限：Jev允许单个请求最多65536个token，但每个分支只能用32768个token。这个数字对不上单一序列，却完美对应"状态共享+分支隔离"的架构。你可以塞一个23000 token的状态，后面挂5000个问题，全部装进一个请求里。
Jev的请求分两层，状态（state）是共享上下文，问题（questions）是一组结构化问题，状态只编码一次，所有问题并行基于同一个状态表示计算概率分布，问题之间不能读对方指令！KV cache（键值缓存）只算一份，每个问题分支读共享缓存，这在大模型推理里叫共享前缀推理（shared-prefix inference）。
延迟曲线验证了这件事，固定状态文本，问题从1个加到1500个，服务器时间从86毫秒涨到610毫秒，一次性回答1500个独立问题只要半秒多！如果每个问题独立处理状态，这个请求得跑好几分钟。
更硬的证据是token上限，Jev允许单个请求最多65536个token，每个分支只能用32768个token，这个数字完美对应状态共享加分支隔离，你可以塞一个23000 token的状态，后面挂5000个问题，全部装进一个请求！Hydragen和DeFT在2024年提出共享前缀和树形结构推理优化，Jev的生产行为跟这些理论预期吻合。
一个只有做过工程才懂的巧思
有人可能会说，这不就是batch inference（批量推理）吗？有啥新鲜的。
区别在这里：普通批量推理是几个独立请求打包一起算，每个请求都有自己完整的上下文。Jev是几千个问题共用一份上下文，只有各自的后缀不同。
这种模式在学术界叫shared-prefix inference（共享前缀推理），2024年才有两篇论文正式提出优化方案，一篇叫Hydragen，一篇叫DeFT。
- Hydragen做的事情是把共享前缀的attention（注意力）计算重构成矩阵乘法，能吃满GPU的算力；
- DeFT则是针对树形结构的推理路径做flash attention优化。
这两套东西刚出来一年多，Jev已经用上生产环境了。
TypeSafe没说自己用了哪个，但延迟曲线的形状跟这类系统的理论预期完全吻合。这就是黑箱探测的威力：你不需要看源代码，只需要看性能曲线的斜率，就能倒推出人家用了什么技术栈。
让选项之间互相打架的设计
Jev还有一个特别有意思的地方：选项之间会互相影响。
举个例子，你问"这次支付失败的原因是什么"，给四个选项：银行、服务商、客户、未知。模型给出概率分布，客户和未知的log-odds比值是+0.38。
现在你加一个明显不相关的第五个选项："天气不好导致的"。按数学理论，加一个新选项只影响归一化系数，不该改变原有两个选项之间的相对概率。但实验结果是，客户和未知之间的log-odds从+0.38降到了+0.11！
如果每个选项的分数是独立计算的，这个比值应该跟其他选项无关。现实中它变了，说明选项之间会通过attention机制互相"看到"，然后共同决定最终分布。
这在ranking（排序）领域叫listwise scoring（列表式打分），跟pointwise（逐点打分）是完全两种范式。
也就是说：Jev处理选择题时，选项之间会互相影响，你问付款失败原因，给四个选项银行、服务商、客户、未知，客户和未知的log-odds比值是+0.38！你加一个不相关的第五选项“天气不好导致的”，按独立打分理论，加新选项只影响归一化系数，不该改变原有两个选项的相对概率，但实验结果是log-odds从+0.38降到+0.11，十个随机分组每一组都下降，平均变化-0.28。
这说明最终决策看到完整列表后才做出，不是每个选项独立评分，这在排序领域叫listwise scoring（列表式打分），跟pointwise（逐点打分）是两种范式！选项通过attention机制互相看到，共同决定最终分布。
位置敏感也很明显，把参考卡片放在选项列表第一个位置，正确率12/16；放中间，11/16；放最后，16/16；把参考信息移到共享状态里，正确率48/48！你部署自动分流时，选项顺序随便调换，阈值可能就要重设，这是一个必须测试的风险点。
校准这件事比准确率重要一万倍
聊模型质量，绝大多数人只看accuracy（准确率），但对决策系统来说，calibration（校准）比准确率重要一万倍。
校准是啥意思呢？你给100个案例打了0.8的概率，如果这100个里真的有80个是对的，那就是完美校准。如果只有50个对，那这个0.8就是虚高的，不能用来做决策。
archerhume用1200个MMLU（大规模多任务语言理解）题目测了Jev，算出expected calibration error（预期校准误差）是0.0313。这个数字有多离谱呢？大部分开源模型在这个指标上都是0.1到0.3的水平，Jev直接把误差压到了3%。
TypeSafe自己给他们的训练方法起了个名字叫RLCD（Reinforcement Learning for Calibrated Decisions，用于校准决策的强化学习）。虽然具体recipe没公开，但从原理上讲，只要在训练时用proper scoring rule（正规评分规则）作为损失函数，理论上就能得到校准良好的输出。Brier score和log loss都属于这类损失，数学上早就证明过：只有报告真实概率分布，期望损失才最小。
但是校准不是万能保证，有限数据、模型限制、分布偏移都会让校准退化，Guo等人在2017年证明现代神经网络即使准确率高，校准误差也可能很大！Jev在三位数乘法上准确率86.7%，平均最高概率0.83，看起来不错；在两步应用题上准确率只有32%，平均最高概率0.30，它在困难任务上更不确定，但这个任务族整体概率仍然偏乐观。
有个叫置信度的字段不是置信度
Jev的API返回里有个字段叫confidence，很多人以为这是模型对自己判断有多确信的另一个学习指标，但TypeSafe公开的Python adapter源代码显示它是纯数学计算出来的！公式是c=(pmax-1/K)/(1-1/K)，pmax是最高概率，K是选项数量，这个公式测的是最高概率跟均匀分布相比高多少。
三个选项里最高是0.8，均匀分布是0.33，confidence就是(0.8-0.33)/(1-0.33)=0.7，这个0.7不代表“70%的概率是对的”，它只描述分布形状有多集中！一个集中的分布可能非常自信地错，一个平坦的分布可能诚实地承认不知道。
这就把两个东西分得清清楚楚，概率分布是学出来的，confidence是算出来的！你可以把confidence当内部阈值判断的输入，但不能把它当成模型对用户做出的正确率承诺来展示。
底层可能是稀疏专家但没人能证明
前面所有推测都有实验证据，但有一个部分是纯推理：archerhume认为Jev的底层是sparse Mixture-of-Experts（稀疏混合专家）架构。
Mixture-of-Experts/MoE是啥？就是模型里有很多个"专家"子网络，每个token进来的时候有个路由器决定送到哪几个专家那里去处理。这样模型可以塞很多参数，但每次推理只激活一小部分。2017年Google的Shazeer那篇论文首次证明这个思路可行，现在DeepSeek-V3、Qwen3、GLM-4.5、Kimi K2这些新一代模型全在用。
推理链是这样的：Jev在30000个token的输入上大概160毫秒返回，一个稠密的70B模型在8张H100上跑这么多token至少要一秒；同时Jev在MMLU-Pro上跑出84.6%的准确率，说明它肯定不是小模型。速度快加上知识量大，最合理的解释就是激活参数10B左右的MoE。
而且MoE有个天生适合Jev这种场景的特点：它平时的最大缺点是自回归解码时memory bandwidth（内存带宽）成瓶颈，大部分专家最后都会被激活；但Jev根本不做自回归解码，只做prefill（预填充），这个缺点直接消失了。
MoE是模型里有很多专家子网络，每个token进来时路由器决定送到哪几个专家处理，这样模型可以塞很多参数但每次推理只激活一小部分！2017年Shazeer等人的论文首次证明这个思路可行，现在DeepSeek-V3、Qwen3、GLM-4.5、Kimi K2这些新一代模型全在用。
MoE平时最大缺点是自回归解码时内存带宽成瓶颈，大部分专家最后都会被激活，但Jev根本不做自回归解码，只做prefill，这个缺点直接消失！不过这个推测无法从外部观测证实，除非TypeSafe公开技术报告，或者有下一个更狠的研究者用十万次调用去逼近答案。
它不能聊天所以别拿它当GPT
一个被大家忽视的关键限制
聊了这么多Jev的好处，也得说说它的边界。
Jev不能对话，不能生成文字，不能做需要多步推理的任务。你让它写代码它不行，你让它总结长文档它也不行。它就是个纯粹的判断机器，输入是状态和问题，输出是概率。
这意味着Jev跟GPT-4、Claude这类通用模型是完全不同的物种，根本不构成竞争关系！你的产品里如果有分类、路由、风控、审核这类需求，用Jev可能比用GPT-4便宜十倍还准确；但如果你要做客服聊天机器人，Jev一点用都没有。
技术选型时别只看benchmark分数，Jev在MMLU-Pro上84.6%听起来很吓人，但真正让它有工程价值的是65536 token的批量处理能力、0.0313的校准误差、几百毫秒的响应时间这些非明星指标！你评估任何AI工具，把响应时延、吞吐量、校准度这三个数字量出来，比看任何跑分都实在。
逆向工程给普通人的三条启示
看完这个破解案例，你能带走什么？
第一条：面对任何声称"AI能做决策"的产品，先问一句"你给的概率是学出来的还是编出来的"。如果供应商答不上来，或者答"我们的模型很聪明会自己判断"，那就是在把语言模型的文本输出冒充成概率。你在采购AI决策工具时，把calibration测试写进合同，1200个样本跑一遍就能验证，别信市场话术！
第二条：闭源不等于黑箱，黑箱不等于安全。TypeSafe不发论文不开源，一样被一万次API调用扒了个底朝天。你自己公司要是有想藏起来的技术护城河，别指望"不公开就没人知道"，真正的护城河是数据、场景、迭代速度这些黑箱探测测不出来的东西！
第三条：技术选型时别只看benchmark分数。Jev在MMLU-Pro上84.6%的准确率听起来很吓人，但真正让它有工程价值的是65536 token的批量处理能力、0.0313的校准误差、几百毫秒的响应时间这些"非明星指标"。你评估任何AI工具，把响应时延、吞吐量、校准度这三个数字量出来，比看任何跑分都实在！
一个还没被回答的问题
archerhume在文章最后留了个悬念：他用445次tokenizer探测请求，对比了192个公开tokenizer，没有一个能完全匹配Jev的行为。
最接近的是Qwen系列，415个探测里对上了348个，但digit splitting（数字切分）规则和几个merge（合并）规则又对不上。OpenAI的o200k tokenizer词表方向对得上，但也不完全一样。这就意味着TypeSafe要么用了自己训练的tokenizer，要么在某个开源tokenizer基础上做了魔改。
这个悬念现在还没解，也可能永远解不了。除非TypeSafe哪天心血来潮公开一份技术报告，或者有下一个更狠的研究者用十万次调用去逼近答案。黑箱破解这门手艺，看起来才刚刚开始热闹起来。