企业官网建设流程全解析

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 个复刻项目按实现内核归并，其实是五条路线：

判断一个复刻是"真工程"还是"凑热闹"，看两件事就够了：第一，它有没有把概率可信度当成可验证的交付物（温度怎么定、校准怎么测、验证怎么披露）；第二，它有没有处理高基数选项和选项顺序鲁棒性——这是 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_ids=inputs["input_ids"], attention_mask=inputs["attention_mask"], use_cache=False, logits_to_keep=1).logits[:, -1, :].float() selected = logits.gather(1, inputs["candidate_ids"])

logits_to_keep=1意味着只保留最后一个位置的 logits，没有任何自回归生成循环——这正是"System 1 决策模型"的工程形态：一次前向，多个候选的概率同时得出。decision_result随后把每个候选的 logits 做softmax(logits / temperature)，并输出prediction、probabilities、logits三件套；当存在标注时还会附带nll（负对数似然）与brier（Brier 分数）——校准度量被内置为参考运行的标配输出，而不是论文里才有的概念。

字段接口同样对得上 Jev 生态的三类决策：schema_config.json的训练数据审计显示training_kinds分为choice（8080 行）、noul（2412 行）、score（1534 行），在 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." }

T=1.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，枚举必须有非空 description，choice_descriptions里的键必须严格对应合法选项；parallel_schema.py甚至逐字段校验"每个候选码在答案边界必须是单个普通 token"，BPE 合并跨边界的情况会被直接拒绝（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 且支持 BF16（torch.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，正是判断一个项目把这三件事做到什么程度的最快入口。