8 个 Jev 开源复刻同台谁在真校准、谁在凑热闹2026 年 9 月OpenAI 前研究员创办的 TypeSafe AI 发布了 Jev——一个放弃生成、专精多选项概率判断的System One 决策模型。社区传播最快的一组数字是端到端响应 70–500 毫秒、比传统自回归推理快 193.6 倍、输入成本低至每百万 Token 0.042 美元。三天之内开源社区就交出了第一批复刻有人冻结大模型直接读 logits有人训练专用编码器有人把 Qwen 改造成决策头甚至有人用离散扩散做概率输出。本文以社区盘点的 8 个开源项目SemIf、Simple Jev、Laya、Von、Verdict、Kev、Nimble、OpenJev为对象以仓库中真实存在的 Bespoke-Nimble-9B 为解剖样本回答一个核心问题在接口长得像 Jev之外哪些项目把概率校准当成了工程交付物哪些只是把分类任务的 logits 换个壳一、八份答卷五条技术路线把 8 个复刻项目按实现内核归并其实是五条路线路线代表项目内核典型代价冻结大模型读 logitsSimple Jev、OpenJev复用通用 LLM对答案 token 位置取 logits 再 softmax延迟高、概率未经校准训练必须后置温度拟合专用编码器决策模型LayaModernBERT-large 单次前向输出多选项概率分布快社区实测 32.8ms但高基数分类如 77 类 Banking77泛化受限校准优化小模型Von以概率校准为核心目标训练小模型基准规模小跨任务泛化证据不足Qwen 改造微调NimbleQwen3.5-9B LoRA 适配直接对候选 token 打分依赖 9B 基座与 GPU部署门槛最高离散扩散生成Kev以扩散方式生成概率分布延迟理论最低接口与校准成熟度最弱判断一个复刻是真工程还是凑热闹看两件事就够了第一它有没有把概率可信度当成可验证的交付物温度怎么定、校准怎么测、验证怎么披露第二它有没有处理高基数选项和选项顺序鲁棒性——这是 Jev 与普通分类模型最本质的差别。下面用 Nimble 的源码逐一对照。二、Nimble 的 Qwen 改造把决策做成了可审计的适配器仓库根目录的 README.md 明确写着这是一个 Qwen3.5-9B 的LoRA 适配器约 165 MiB不是完整模型。adapter_config.json显示peft_type: LORA、r: 16、lora_alpha: 32仅训练了 up/down/gate/q/k/v/o 等投影层权重文件即 adapter_model.safetensors。关键是推理方式。通用 LLM 做分类是生成答案Nimble 是对候选 token 直接打分。参考推理代码 inference.py 中candidate_logits的实现logits model(input_idsinputs[input_ids], attention_maskinputs[attention_mask], use_cacheFalse, logits_to_keep1).logits[:, -1, :].float() selected logits.gather(1, inputs[candidate_ids])logits_to_keep1意味着只保留最后一个位置的 logits没有任何自回归生成循环——这正是System 1 决策模型的工程形态一次前向多个候选的概率同时得出。decision_result随后把每个候选的 logits 做softmax(logits / temperature)并输出prediction、probabilities、logits三件套当存在标注时还会附带nll负对数似然与brierBrier 分数——校准度量被内置为参考运行的标配输出而不是论文里才有的概念。字段接口同样对得上 Jev 生态的三类决策schema_config.json的训练数据审计显示training_kinds分为choice8080 行、noul2412 行、score1534 行在 inference.py 中分别对应kind choice / noul / score的分支——选择、是否、评分三类任务各有一条独立的输出路径评分字段还会计算概率加权期望值expected_score。三、标尺一概率校准是交付物还是装饰品这是全行业复刻 Jev 时最容易糊弄的一环。Jev 的卖点之一是 RLCD 强化学习校准——让模型输出的置信度在统计意义上是可信的。复刻项目可以轻易复现多选项概率分布但概率分布有没有被校准过是另一回事。三条可以立刻查验的证据线1. 温度是否经过拟合、是否诚实披露。仓库根目录的 temperature_config.json 写得很直白{ temperature: 1.0, temperature_fitted: false, note: Checkpoint-specific evaluated default; prior releases calibration does not apply. }T1.0 是当前 checkpoint 的评估默认值没有做过独立的温度拟合README 还专门警告不要复用旧版本拟合出的 2.179 校准值。对比之下许多冻结大模型读 logits的复刻默认 softmax 输出而通用模型的 logits 未经校准训练置信度普遍过度自信——如果项目没有给出温度拟合报告它的概率就只是分类输出的装饰品。Nimble 至少把未拟合这一事实写进了配置而不是假装概率天生可信。2. 验证数据是否诚实披露。schema_config.json的data_audit是全仓库信息密度最高的部分12,026 训练行、8,468 个训练组、5,370 个训练族、324 个验证行验证顺序明确标注为original inference choice order; no shuffling不洗牌组件列表包含 Banking77、MultiNLI、BoolQ、AG News、DBpedia、TREC 等公开基准。两个值得注意的细节一是heldout_family_overlap: false训练族与验证族不重叠堵住了背题式评估二是test_split_used: false测试集未被用于调参。这种披露粒度在 8 个项目里属于稀缺品。3. 选项顺序鲁棒性有没有被正视。候选编码采用 A–Z 单 token 大写字母宽候选则扩展为 AA、AB 直至 JT 共 255 个见 extended_schema.py 与 serving_config.json 中的candidate_codes。这意味着选项的位置由调用方 schema 里的顺序决定模型对选项排列顺序天然敏感同一个问题把选项顺序打乱A 位置的 token 变了概率分布理应跟着变。Nimble 的验证集明确不洗牌等于向用户披露本模型没有做过选项顺序增强顺序敏感性未被评估。这是诚实的短板披露而大量复刻项目根本不会提这件事——排序鲁棒性恰恰是 Jev 类模型在生产中翻车的高频区。四、标尺二接口兼容性与部署门槛接口层面Nimble 的 schema 契约是严格的字段类型只接受enum和boolean枚举必须有非空 descriptionchoice_descriptions里的键必须严格对应合法选项parallel_schema.py甚至逐字段校验每个候选码在答案边界必须是单个普通 tokenBPE 合并跨边界的情况会被直接拒绝Choice code is not one ordinary token at the answer boundary。前缀复用也不是粗暴的字符串截断——代码会Use only the exact common token prefix求公共 token 前缀防止 BPE 边界错位。这是把提示词工程做成了可验证的合约而不是手写字符串拼接。供应链层面inference.py 的validate_serving_config对 serving_config.json、schema_config.json 中的源码做 SHA-256 比对训练提示词源码与运行时代码必须逐字节一致否则直接抛错SHA256SUMS为仓库每个文件提供了完整哈希清单。训练与服务两侧的 255 候选码本candidate_codes/candidate_token_ids必须逐项一致。换言之你跑到的提示词就是训练时的提示词——这在复刻生态里是少见的可追溯性设计。部署门槛则是它的代价。参考运行器硬性要求 CUDA GPU 且支持 BF16torch.cuda.is_bf16_supported()不通过直接 RuntimeError依赖链是 PyTorch 2.8.0 transformers 5.17.0 peft 0.21.0见 requirements.txt超过 8,192 token 的输入是拒绝而非截断。相比之下社区情报显示 Ollama 0.35 已支持 Jev 风格决策模型的本地运行Nimble 等三款模型社区报告单次决策中位延迟 33ms、典型值 91ms零 API 成本走的是推理层本地化的路子。因此选择 Nimble 基本等于选择了需要一块支持 BF16 的 GPU 愿意接纳 Qwen3.5-9B 基座这一前提。五、生产选型跟哪个项目走把五条路线放到校准可信度 × 部署成本两个轴上结论是分层的要概率可信度、且已有 GPU 与 Qwen 生态Nimble 是当前复刻里校准透明度最高的——温度政策白纸黑字、验证数据审计到行、内置 nll/Brier 计算、训练/服务合约哈希锁定。它明确不承诺自己做不到的事未做温度拟合、未做顺序增强这种如实披露本身就是选型时的确定性。要极致延迟、选项规模在 25 类以内专用编码器路线Laya 一类胜出社区实测约 32.8ms但高基数分类如 77 类 Banking77是其明确短板不要把宽候选任务交给它。通用 LLM 冻结读 logits适合原型验证但概率不可信、延迟未根治生产前至少需要自建温度拟合与 ECE/Brier 基准否则属于接口凑合。离散扩散路线方向新颖但目前校准与接口成熟度最低不建议进入核心链路。最后给出一份可操作的真校准检验清单拿去审任何声称兼容 Jev 的开源项目温度是否报告了拟合方法与数值、验证集是否披露组成与顺序策略、ECE/Brier 是否在统一基准如社区提及的 bespoke-eval、jevbench-eval上可复算、选项打乱后结果是否稳定、255 类高基数是否真实支持。五个问题能答出三个以上的项目屈指可数——多数复刻做的是接口模仿少数在做概率工程。校准不是宣传词是配置、审计和测试三件事的合称而仓库里的 provenance.json 和schema_config.json的data_audit正是判断一个项目把这三件事做到什么程度的最快入口。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/11/3 2:27:47 · 阅读 1.2k 8 个 Jev 开源复刻同台：谁在真校准、谁在凑热闹
8 个 Jev 开源复刻同台谁在真校准、谁在凑热闹2026 年 9 月OpenAI 前研究员创办的 TypeSafe AI 发布了 Jev——一个放弃生成、专精多选项概率判断的System One 决策模型。社区传播最快的一组数字是端到端响应 70–500 毫秒、比传统自回归推理快 193.6 倍、输入成本低至每百万 Token 0.042 美元。三天之内开源社区就交出了第一批复刻有人冻结大模型直接读 logits有人训练专用编码器有人把 Qwen 改造成决策头甚至有人用离散扩散做概率输出。本文以社区盘点的 8 个开源项目SemIf、Simple Jev、Laya、Von、Verdict、Kev、Nimble、OpenJev为对象以仓库中真实存在的 Bespoke-Nimble-9B 为解剖样本回答一个核心问题在接口长得像 Jev之外哪些项目把概率校准当成了工程交付物哪些只是把分类任务的 logits 换个壳一、八份答卷五条技术路线把 8 个复刻项目按实现内核归并其实是五条路线路线代表项目内核典型代价冻结大模型读 logitsSimple Jev、OpenJev复用通用 LLM对答案 token 位置取 logits 再 softmax延迟高、概率未经校准训练必须后置温度拟合专用编码器决策模型LayaModernBERT-large 单次前向输出多选项概率分布快社区实测 32.8ms但高基数分类如 77 类 Banking77泛化受限校准优化小模型Von以概率校准为核心目标训练小模型基准规模小跨任务泛化证据不足Qwen 改造微调NimbleQwen3.5-9B LoRA 适配直接对候选 token 打分依赖 9B 基座与 GPU部署门槛最高离散扩散生成Kev以扩散方式生成概率分布延迟理论最低接口与校准成熟度最弱判断一个复刻是真工程还是凑热闹看两件事就够了第一它有没有把概率可信度当成可验证的交付物温度怎么定、校准怎么测、验证怎么披露第二它有没有处理高基数选项和选项顺序鲁棒性——这是 Jev 与普通分类模型最本质的差别。下面用 Nimble 的源码逐一对照。二、Nimble 的 Qwen 改造把决策做成了可审计的适配器仓库根目录的 README.md 明确写着这是一个 Qwen3.5-9B 的LoRA 适配器约 165 MiB不是完整模型。adapter_config.json显示peft_type: LORA、r: 16、lora_alpha: 32仅训练了 up/down/gate/q/k/v/o 等投影层权重文件即 adapter_model.safetensors。关键是推理方式。通用 LLM 做分类是生成答案Nimble 是对候选 token 直接打分。参考推理代码 inference.py 中candidate_logits的实现logits model(input_idsinputs[input_ids], attention_maskinputs[attention_mask], use_cacheFalse, logits_to_keep1).logits[:, -1, :].float() selected logits.gather(1, inputs[candidate_ids])logits_to_keep1意味着只保留最后一个位置的 logits没有任何自回归生成循环——这正是System 1 决策模型的工程形态一次前向多个候选的概率同时得出。decision_result随后把每个候选的 logits 做softmax(logits / temperature)并输出prediction、probabilities、logits三件套当存在标注时还会附带nll负对数似然与brierBrier 分数——校准度量被内置为参考运行的标配输出而不是论文里才有的概念。字段接口同样对得上 Jev 生态的三类决策schema_config.json的训练数据审计显示training_kinds分为choice8080 行、noul2412 行、score1534 行在 inference.py 中分别对应kind choice / noul / score的分支——选择、是否、评分三类任务各有一条独立的输出路径评分字段还会计算概率加权期望值expected_score。三、标尺一概率校准是交付物还是装饰品这是全行业复刻 Jev 时最容易糊弄的一环。Jev 的卖点之一是 RLCD 强化学习校准——让模型输出的置信度在统计意义上是可信的。复刻项目可以轻易复现多选项概率分布但概率分布有没有被校准过是另一回事。三条可以立刻查验的证据线1. 温度是否经过拟合、是否诚实披露。仓库根目录的 temperature_config.json 写得很直白{ temperature: 1.0, temperature_fitted: false, note: Checkpoint-specific evaluated default; prior releases calibration does not apply. }T1.0 是当前 checkpoint 的评估默认值没有做过独立的温度拟合README 还专门警告不要复用旧版本拟合出的 2.179 校准值。对比之下许多冻结大模型读 logits的复刻默认 softmax 输出而通用模型的 logits 未经校准训练置信度普遍过度自信——如果项目没有给出温度拟合报告它的概率就只是分类输出的装饰品。Nimble 至少把未拟合这一事实写进了配置而不是假装概率天生可信。2. 验证数据是否诚实披露。schema_config.json的data_audit是全仓库信息密度最高的部分12,026 训练行、8,468 个训练组、5,370 个训练族、324 个验证行验证顺序明确标注为original inference choice order; no shuffling不洗牌组件列表包含 Banking77、MultiNLI、BoolQ、AG News、DBpedia、TREC 等公开基准。两个值得注意的细节一是heldout_family_overlap: false训练族与验证族不重叠堵住了背题式评估二是test_split_used: false测试集未被用于调参。这种披露粒度在 8 个项目里属于稀缺品。3. 选项顺序鲁棒性有没有被正视。候选编码采用 A–Z 单 token 大写字母宽候选则扩展为 AA、AB 直至 JT 共 255 个见 extended_schema.py 与 serving_config.json 中的candidate_codes。这意味着选项的位置由调用方 schema 里的顺序决定模型对选项排列顺序天然敏感同一个问题把选项顺序打乱A 位置的 token 变了概率分布理应跟着变。Nimble 的验证集明确不洗牌等于向用户披露本模型没有做过选项顺序增强顺序敏感性未被评估。这是诚实的短板披露而大量复刻项目根本不会提这件事——排序鲁棒性恰恰是 Jev 类模型在生产中翻车的高频区。四、标尺二接口兼容性与部署门槛接口层面Nimble 的 schema 契约是严格的字段类型只接受enum和boolean枚举必须有非空 descriptionchoice_descriptions里的键必须严格对应合法选项parallel_schema.py甚至逐字段校验每个候选码在答案边界必须是单个普通 tokenBPE 合并跨边界的情况会被直接拒绝Choice code is not one ordinary token at the answer boundary。前缀复用也不是粗暴的字符串截断——代码会Use only the exact common token prefix求公共 token 前缀防止 BPE 边界错位。这是把提示词工程做成了可验证的合约而不是手写字符串拼接。供应链层面inference.py 的validate_serving_config对 serving_config.json、schema_config.json 中的源码做 SHA-256 比对训练提示词源码与运行时代码必须逐字节一致否则直接抛错SHA256SUMS为仓库每个文件提供了完整哈希清单。训练与服务两侧的 255 候选码本candidate_codes/candidate_token_ids必须逐项一致。换言之你跑到的提示词就是训练时的提示词——这在复刻生态里是少见的可追溯性设计。部署门槛则是它的代价。参考运行器硬性要求 CUDA GPU 且支持 BF16torch.cuda.is_bf16_supported()不通过直接 RuntimeError依赖链是 PyTorch 2.8.0 transformers 5.17.0 peft 0.21.0见 requirements.txt超过 8,192 token 的输入是拒绝而非截断。相比之下社区情报显示 Ollama 0.35 已支持 Jev 风格决策模型的本地运行Nimble 等三款模型社区报告单次决策中位延迟 33ms、典型值 91ms零 API 成本走的是推理层本地化的路子。因此选择 Nimble 基本等于选择了需要一块支持 BF16 的 GPU 愿意接纳 Qwen3.5-9B 基座这一前提。五、生产选型跟哪个项目走把五条路线放到校准可信度 × 部署成本两个轴上结论是分层的要概率可信度、且已有 GPU 与 Qwen 生态Nimble 是当前复刻里校准透明度最高的——温度政策白纸黑字、验证数据审计到行、内置 nll/Brier 计算、训练/服务合约哈希锁定。它明确不承诺自己做不到的事未做温度拟合、未做顺序增强这种如实披露本身就是选型时的确定性。要极致延迟、选项规模在 25 类以内专用编码器路线Laya 一类胜出社区实测约 32.8ms但高基数分类如 77 类 Banking77是其明确短板不要把宽候选任务交给它。通用 LLM 冻结读 logits适合原型验证但概率不可信、延迟未根治生产前至少需要自建温度拟合与 ECE/Brier 基准否则属于接口凑合。离散扩散路线方向新颖但目前校准与接口成熟度最低不建议进入核心链路。最后给出一份可操作的真校准检验清单拿去审任何声称兼容 Jev 的开源项目温度是否报告了拟合方法与数值、验证集是否披露组成与顺序策略、ECE/Brier 是否在统一基准如社区提及的 bespoke-eval、jevbench-eval上可复算、选项打乱后结果是否稳定、255 类高基数是否真实支持。五个问题能答出三个以上的项目屈指可数——多数复刻做的是接口模仿少数在做概率工程。校准不是宣传词是配置、审计和测试三件事的合称而仓库里的 provenance.json 和schema_config.json的data_audit正是判断一个项目把这三件事做到什么程度的最快入口。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考