它想补的是 Jev 的哪块短板
Jev 发布两周以来，独立测试的共识是：快、便宜、给概率，但准确率只和中等价位的大模型持平，很多团队要在后面挂一个推理模型兜底。我们在 《Jev 是什么》 里也建议把它当第一道关，拿不准的升级给大模型。
Jeeves 的思路是把这一步放回模型内部：让同一个模型先想一想再选。仓库里给了一组对照：同一个检查点在测试集上，关掉推理是 0.804，打开推理是 0.840。推理链生成用了一个适配 Qwen3.5 结构的扩散草稿模型做加速，作者称提速约 1.6 倍。
数字要怎么看
几点值得注意：
- 全部是自报成绩。 测试集、JevBench 题目和评测脚本都来自 PostHog 自己的仓库，与 Jev、Kev-9B 的对比用的题目也不完全相同，仓库自己写明了这一点。
- 赢在判断题，输在知识题。 MMLU 落后 Jev 约 10 个百分点，说明 9B 底座的知识量是硬上限。
- 延迟换了一个量级。 Jev 官方称 70–500 毫秒；Jeeves 开推理后中位 3.3 秒、长尾 17 秒，适合离线批处理和审核复核，不适合放进用户等待的实时链路。
对开发者的实际意义
Jeeves 最大的价值不在于分数，而在于可以自己部署。Jev 目前只有托管 API，数据要发到 TypeSafe 的服务；Jeeves 权重和训练代码都公开，可以在自己的 GPU 上跑，也能用自己的数据继续训练。对数据不能出境、或者需要审计推理过程的团队，这是现在唯一的类 Jev 选项。
门槛也很实际：需要 CUDA 显卡，FP8 加速要求较新的架构；权重必须用 Jeeves 自己的代码加载，不能直接用 transformers。
边界说明：所有准确率与延迟数据均来自 Jeeves 仓库和模型卡，尚无第三方复现；Kev-9B 的来源与设置以仓库说明为准。