# Jeeves 让 0.3 秒的分类器思考，p90 延迟飙升至 17.1 秒

**Summary:** Jeeves 将开发集准确率从 0.775 提升至 0.825，但完整推理的 p90 延迟达到 17.1 秒。我会利用其置信度门控机制，仅在不确定的决策上启用这种延迟。

- Canonical: https://markhuang.ai/zh/news/jeeves-reasoning-17-second-tail
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-09-29
- Section: News
- Tags: Jeeves, 决策模型, AI 推理, 模型评估, 开源 AI
- Source: [PostHog Jeeves on GitHub](https://github.com/PostHog/jeeves)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![快速决策 token 走直接路径，不确定的 token 则进入更深的推理路径](https://cdn.markhuang.ai/news/jeeves-reasoning-17-second-tail/hero.webp)

*Jeeves 把路由选择摆到台面上：简单决策保持快速，只在不确定性值得的时候才投入推理时间。*

[PostHog 的 Jeeves](https://github.com/PostHog/jeeves) 给一个 9B 参数的离散决策模型加上了推理阶段。在 325 个开发问题上，完整推理把准确率从 0.775 拉到 0.825。延迟也跟着变了：不开推理大概 0.3 秒，开了之后中位数 3.3 秒，p90 飙到 17.1 秒。

在我看来，这点准确率提升足以让 Jeeves 在决策流程里占一席之地，但我不会把每个请求都扔给它。分类器之所以有吸引力，是因为它能把状态转成明确答案和校准后的概率，不用生成一大段文字。要是让每个简单决策都等一条长推理链，这个优势就打折了。

仓库里其实已经留了一个关键开关：初始置信度超过阈值时，Jeeves 可以直接跳过推理。我会围绕这个开关来设计部署，只在第一遍拿不准的时候才付出额外延迟。

## 推理提升了答案，也改变了服务形态

Jeeves 在 Qwen3.5-9B 基础上加了 LoRA 权重和指针头，训练模型通过 Jev 兼容 API 回答是/否、多选和评分问题。它能在指针头给选项分配概率之前先生成推理链。代码用 MIT 许可证，发布的权重继承 Qwen3.5 的 Apache 2.0 许可证，每个源数据集保留自己的许可证。

在作者的测试环境里，提升相当明显。开了推理之后，Jeeves 在域外和保留测试集上拿到 0.889，超过了 Kev-9B 公开的 0.822 和 Jev 的 0.857。同一个 checkpoint 上，推理把项目 2,962 条测试集的准确率从 0.804 提到 0.840。

提升确实重要，但不是所有请求都能同等受益。Jeeves 在知识密集型测试上还是落后于 Jev：MMLU 上 0.793 对 0.900，MMLU-Pro 上 0.739 对 0.840。更多的推理时间并没有弥补 9B 基础模型的局限。

## 中间档位更像产品

Jeeves 提供了三个有用的工作点。完整推理在 325 个问题的开发集上达到 0.825 准确率，平均推理 token 数 1,138，p90 延迟 17.1 秒。关闭推理则在约 0.3 秒内达到 0.775 准确率。混合设置把推理限制在 768 个 token 以内，置信度超过 0.9 时直接跳过推理；这样达到 0.806 准确率，中位数 2.0 秒，p90 5.6 秒。

我会从混合模式入手，再根据自己应用关心的决策做重新校准。不存在通用阈值。[Kev-9B 的模型卡](https://github.com/jaredpalmer/kev/blob/main/docs/model-cards/kev-9b.md)说得很清楚：它发布的温度参数适合某些外部工作负载，但换到另一个工作负载就得重新拟合，那次样本外校准把预期校准误差从 0.131 降到 0.037，准确率没变。

置信度门控的前提是，置信度在你的数据上真的有意义。我会先测有多少流量落在可接受的错误率以内，然后把拿不准的或者代价高的请求送进推理路径，简单路由继续走快通道。

> **Info:**
>
> 我的部署原则：推理应该在不确定性上花掉一个明确的延迟预算。如果团队说不出哪些错误值得走慢路径，那现在就把思考当默认还太早。

## 0.935 这个分数有公开边界

Jeeves 还报告了在 231 个公开 JevBench 项目上达到 0.935 准确率，Jev 是 0.866；在 111 个公开难题上是 0.865。这几个数字引起了我的注意。来源也明确说明，密封的评委层被排除在外。

[对同一公开子集的独立审计](https://github.com/Zefan-Cai/Open-Jev/blob/main/docs/jevbench-public.md)显示其构成是 72 个原始任务、48 个简单任务和 111 个困难任务。还指出完整基准另外包含 303 个私有或评委任务。现在的[JevBench 项目](https://github.com/fstandhartinger/jevbench)在官方评分里同时使用公开和密封决策，正是因为公开项目可能被训练或针对性选择。

我查到的内容没有显示 Jeeves 在 JevBench 上训练过。仓库把结果标为公开，没对密封层做任何声明。我把 0.935 看作一个很强的公开集结果，但生产错误率仍然未知。我在看[OpenJev 的较小比较](https://markhuang.ai/news/openjev-3-8-point-102-row-asterisk)时也做了同样的区分。可复现的接口和不错的分数足以说明值得做下一步测试，但它们替代不了测试本身。

## H100 是决策的一部分

延迟数据来自单块 H100，FP8 推理内核需要 NVIDIA Hopper 硬件。复现完整训练流程要八块 GPU。Jeeves 确实包含了权重、训练代码、数据构建脚本、SDK，还有一个扩散草稿器，项目说它在默认块大小下能把单问题链生成速度从每秒 109 个 token 提到 176 个。

开源代码让系统可检查，但团队还是得为硬件买单，在自己的环境里重新测延迟。考虑用 Jeeves 的团队需要测内存占用、并发下的吞吐量、p90 排队情况，还有保持合适 GPU 可用的成本。仓库没公布每次决策的美元成本。

在有理由公开之前，我也会把返回的推理内容排除在面向用户的日志之外。项目警告说它没针对语言一致性训练过，所以推理链不一定能可靠解释。分类答案和概率分布才是契约，推理链只是内部计算，不是审计解释。

## 我的试点会先测路由器

我会从实际工作负载里切出一批标注好的样本，三种模式都跑一遍。我想看的是：当我调整置信度阈值时，准确率、校准覆盖率、p90 延迟和 GPU 需求怎么变。然后重点看两类失败：简单决策浪费时间在推理上，以及高置信度犯错、根本没进慢路径的请求。

Jeeves 有力地证明了小型分类模型也能从刻意推理中受益。它的公开基准结果值得细看，仓库对较慢的尾部延迟和较弱的知识分数也异常坦诚。17.1 秒的 p90 没让我对这个项目望而却步，反而告诉我该怎么用它：当一个快速路由器，给那些拿不准的决策留一条推理通道。