Jev架构黑箱破解：万次API调用蒸馏出逆向工程完整报告
内容提要
独立研究者通过一万次API调用，利用延迟、token计数和拒绝规则，逆向分析了闭源模型Jev的架构。Jev不采用自回归生成，而是直接输出概率，使用共享前缀推理和列表式打分，校准误差仅0.0313，疑似稀疏MoE架构。文章强调校准比准确率更重要，闭源不等于安全，技术选型应关注时延、吞吐和校准度。
延伸解读
校准误差0.0313的工程意义
文章指出Jev的预期校准误差仅0.0313，远低于多数开源模型0.1到0.3的水平。这意味着当Jev输出0.8的概率时，实际正确率接近80%，概率值可直接用于风控阈值设定。对于决策系统，校准比准确率更重要，因为下游规则依赖概率的可靠性。但文章也提醒，校准会因数据有限、模型限制和分布偏移而退化，需持续监控。
共享前缀推理带来的吞吐优势
Jev采用共享前缀推理，状态文本只编码一次，多个问题分支复用KV缓存。实验显示，固定状态文本，问题数从1增加到1500，响应时间仅从86毫秒升至610毫秒。这种设计让单次请求可处理大量独立问题，显著提升吞吐。但文章也指出，问题之间不能互相读取指令，分支隔离，因此不适合需要多轮交互或依赖上下文的复杂任务。
列表式打分对选项顺序的敏感性
Jev使用列表式打分，选项之间通过注意力机制相互影响。实验表明，加入不相关选项会改变原有选项的log-odds比值，且选项位置影响正确率：参考卡片放最后时正确率16/16，放中间仅11/16。这意味着在实际部署中，选项顺序或列表构成的变化可能导致概率分布偏移，需要重新校准阈值。文章建议将选项顺序作为必须测试的风险点。
MoE推测的合理性与局限
文章推测Jev底层是稀疏混合专家架构，依据是其在30000 token输入上约160毫秒返回，且MMLU-Pro准确率达84.6%，速度快且知识量大，符合激活参数约10B的MoE特征。MoE在自回归解码时受内存带宽瓶颈，但Jev只做预填充，规避了该缺点。然而，这一推测无法从外部观测证实，除非TypeSafe公开技术报告或进行更深入的探测。
Q&A
Jev模型和ChatGPT这类自回归模型在输出概率上有什么本质区别？
ChatGPT等自回归模型逐token生成文本，输出的“90%确定”只是语言模式，不是数学概率；而Jev不生成文字，直接在前向传播最后一层通过线性层加softmax输出每个选项的真实概率分布。
研究者是如何通过API调用逆向分析Jev架构的？
研究者通过一万次API调用，观察延迟变化、token计数和拒绝规则，例如加长状态文本、增加问题数量、打乱选项顺序，从而推断出Jev的共享前缀推理、列表式打分等架构特征。
Jev的共享前缀推理是如何工作的？有什么证据支持？
Jev将共享状态文本放在前面，KV cache只计算一次，后续每个问题分支读取同一份缓存。证据包括：固定状态文本，问题从1个加到1500个，服务器时间仅从86毫秒涨到610毫秒；且单请求token上限65536，每分支32768，符合状态共享加分支隔离。
为什么说校准比准确率更重要？Jev的校准表现如何？
校准反映概率输出的可靠性，对决策系统至关重要。Jev在1200个MMLU题目上预期校准误差仅0.0313，远低于开源模型常见的0.1-0.3，说明其输出的概率更可信。
Jev的confidence字段代表什么？它是如何计算的？
confidence字段不是模型的学习指标，而是纯数学计算：c=(pmax-1/K)/(1-1/K)，其中pmax是最高概率，K是选项数量。它描述概率分布的集中程度，不代表正确率。
Jev可能采用稀疏混合专家（MoE）架构的依据是什么？
依据包括：Jev在30000 token输入上约160毫秒返回，远快于稠密70B模型；同时在MMLU-Pro上达到84.6%准确率，表明知识量大。速度快加知识量大，最合理的解释是激活参数约10B的MoE，且MoE在prefill阶段无内存带宽瓶颈。
Jev有哪些使用限制？它适合哪些场景？
Jev不能对话、不能生成文字、不能做多步推理，只适合分类、路由、风控等结构化判断。它不适合客服聊天机器人等需要生成文本的任务。
从Jev的逆向工程案例中，普通人能获得哪些启示？
启示有三：1. 询问AI决策产品时，要区分概率是学出来的还是编出来的，并将校准测试写入合同；2. 闭源不等于安全，真正的护城河是数据、场景和迭代速度；3. 技术选型应关注时延、吞吐量和校准度，而非仅看benchmark分数。
