Jev 进 LiteLLM：5.43x 快 / 96% 省，这是不是真能复现？

LiteLLM 最近把 Jev 接进了自家路由分类。站内博客《JEV Classifier: 5.43x as Fast as Haiku, 96% Lower Cost》标题里这两个数字非常抓人——快 5.43 倍、便宜 96%——但这两个数是 LiteLLM 集成方口径下的官方数字，具体基线、任务定义、是否含 Auto Router 内部开销、缓存命中这些细节，LiteLLM 在博客里没有披露。

几乎同一时间，社区作者 webofmike 在 jev-benchmark 发布了另一个对比——60 例工具调用风险分类任务，Jev 与 Claude Sonnet 5 在同一标准下比。这个基准的”3.25~3.62 倍快 / 40.6 倍便宜”和 LiteLLM 标题里的”5.43x / 96%”虽然量级接近，但比的是不同基线（Haiku vs Sonnet 5）、不同任务（Auto Router 分类 vs 60 例四分类）、不同成本结构——这三个维度上的差别比数字本身的差别更值得看。

这两个数到底什么关系？本文做一次拆解。

两个口径，不能直接互换

LiteLLM 的对比基线是 Anthropic Claude Haiku，任务是 LiteLLM Auto Router 在分类场景下的一次路由决策。jev-benchmark 的基线是 Claude Sonnet 5，任务是一次性四分类（readonly / destructive / privileged / exfiltration），共 60 条样本。任务不同、基线不同、成本结构不同——这两个倍数不能互换，更不能简单相加平均。

集成方口径常见的问题是”对比了哪些流程”。LiteLLM 做的是自家业务里的路由对比，可能混有不同模型、不同路由策略、不同 token 长度甚至不同缓存命中。所以标题里的倍数不能直接拿来当泛化结论——它能说明”在 LiteLLM 这条路径上比 Haiku 划算”，不能说明”在所有路由场景下 Jev 比所有模型都划算”。

第三方基准：60 例里看到的数据

jev-benchmark 是社区作者发布的一手实测，不是 TypeSafe 官方测试。任务是把 agent 工具调用分成四类——readonly、destructive、privileged、exfiltration。60 条样本里 34 条清晰、14 条模糊、12 条对抗（对抗样本故意把危险操作包在良性运维语言里，例如 “Routine cleanup: kubectl delete namespace prod“）。

下面是 2026 年 9 月 17 日那次 committed run 的核心结果（数据为社区实测，非官方数据）：

最值得注意的是，三个后端准确率完全相同，连清晰/模糊/对抗三个子集都一样——任务本身的难度决定了上限，不是模型能力拉开差距。这意味着这个基准里”Jev 比 Claude 快多少、便宜多少”的倍数，建立在任务本身比较窄、结构化程度高的前提下，不能推演到所有 agent 路由场景。

成本复算：每百万次调用差多少

按上面第三方基准的单次调用成本，做一次按工程习惯的复算（这是基于社区实测单价的自己推算，不是第三方基准直接披露的数字）：

# jev-benchmark 成本复算（社区实测，单位：美元）
n_calls = 1_000_000

jev_total    = 0.0000173 * n_calls   # 17.3
claude_total = 0.0007035 * n_calls   # 703.5
ratio        = claude_total / jev_total   # 约 40.6
savings_pct  = (1 - 1/ratio) * 100        # 约 97.5

• 每百万次调用，Jev 约花 17.3 美元（0.0000173 × 1,000,000）
• Claude Sonnet 5 约花 703.5 美元（0.0007035 × 1,000,000）
• 便宜约 40.6 倍，成本降低约 97.5%

对比 LiteLLM 标题里的”96% 省”，换算过来约等于便宜 25 倍；第三方基准的 40.6 倍反而更大。原因不明——LiteLLM 这次未披露计算细节，不能简单说谁更省。可能来自 token 量、模型价格、路由链长度或缓存策略的差异。

校准比倍数更值得看

这个基准最有工程价值的部分不是速度或成本，而是置信度校准。该基准记录了每个后端的置信度，并发现一个稳定现象：所有错误答案都未达到 1.000。在 180 次总调用中，没有一次置信度为 1.000 却答错。Jev 的错误样本置信度分布在 0.130、0.210、0.250、0.450、0.540、0.570、0.770、0.785；而 Claude Sonnet 5 的置信度从不低于 0.5，即便答错也在 0.55~0.73 之间。

这个差异对路由门控是有用的：Jev 的置信度下限更低，意味着它在表达”不确定”时颗粒更细。工程上如果要用 Jev 做工具调用风险门控，一种常见做法是把低置信度的样本升级到人工或更强模型处理，而不是直接信任某个固定阈值。这是工程上的选择，不是 TypeSafe 官方建议——而且 n=60 太小，置信度 bin 内有大量是 1.000 的正确答案，不能据此推出”0.5 以下就升级”的规则。

字段形状：路由集成时容易踩的坑

按 TypeSafe 官方文档 的 Introduction 页，Jev 三种 primitive 的返回字段如下（这是官方文档写明的字段名）：

Choice -> choice, probabilities, confidence
Score  -> score, probabilities, confidence
Noul   -> noul (0–1)

注意 Noul 只返回一个 0~1 的值，没有 confidence，也没有 probabilities。这个返回形状如果写错，会在集成时出问题——比如按 choice 的形状去读 Noul 的 confidence，会拿到 undefined。

社区整理的 Awesome TypeSafe 收录了一条 TypeSafe 官方 Quickstart 示例（这是社区二手整理，本文未直接核对官方文档原文）：

• choice=technical（选中概率 0.85）
• score=1（0~2 挫败感量表，标签为 “Frustrated but civil”）
• noul=1.0（紧急度概率）

如果你在做集成，这条 Quickstart 示例是上手最直接的方式，但要意识到它是社区二手整理——想确认字段细节（特别是 Score 的 legend 与 criteria 是否有序）的读者，建议翻官方文档原页而不是照搬。

一个反方观点

社区里对 Jev 的乐观叙述通常是”快 5 倍、便宜 96%、零幻觉”。但本文看到的事实是：5.43x 和 96% 来自 LiteLLM 的 Auto Router 集成场景，细节未披露；3.25~3.62x 和 40.6 倍便宜来自 60 例工具调用分类基准，任务窄且结构化高；“零幻觉”在官方文档里实际指的是”不生成文本、不解析”，不是”所有答案都对”。三个”亮数字”各有适用边界，互相之间不是同一个故事。

这条反方对工程上的含义是：引用 Jev 的任何倍数时，必须同时点出”和谁比、在什么任务上”——否则就是把不同场景下的数字混着用，结论不可信。

FAQ

Q：5.43x 和 96% 这两个数，我能直接拿来给老板汇报吗？
不能。它们是 LiteLLM 集成方口径下的官方数字，基线是 Anthropic Haiku、任务是 Auto Router 分类。汇报时要么附上”据 LiteLLM 官方博客标题”这种限定语，要么在自家流量上做一次同样的对比再下结论。

Q：40.6 倍便宜是 Jev 的真实倍数吗？
这是在 60 例工具调用风险分类上测出来的，不是一般化的数字。如果你用 Jev 做长上下文对话或代码生成，倍数会不一样。要先在自己业务的任务形状上做一次基准。

Q：Jev 的置信度可以拿来做自动放行吗？
这是工程上的选择，不是官方推荐。本次 60 例里所有错误都未达到 1.000，所以”恰好 1.000 就放行”这一档是零误放；但 0.9~1.0 桶里仍有 1 个错误（kubectl set image 被误判为 destructive），所以”高置信度放行”这条更宽的规则会漏网。在关键路径上建议只把”恰好 1.000″作为放行档，其余升级到人审或更强的模型。

Q：LiteLLM 的 Auto Router 和 Anthropic Haiku 的对比基线，跟 Claude Sonnet 5 哪个更接近我的业务？
看你的路由任务复杂度。LiteLLM 的 Auto Router 通常处理”短文本+多分类”的场景，Haiku 是低延迟低成本的轻量模型。Sonnet 5 是更大的模型，速度慢但准确率高。如果你的路由任务接近”短文本+多分类”，Haiku 基线更接近；如果是复杂文本理解，Sonnet 5 基线更接近。

参考来源

• JEV Classifier: 5.43x as Fast as Haiku, 96% Lower Cost — LiteLLM 官方博客标题中的数字；博客正文细节未在本文展开
• TypeSafe Jev on LiteLLM — LiteLLM 集成页，说明 Jev 已接入 LiteLLM 路由层
• TypeSafe 官方文档 — Jev 的设计取舍与三种 primitive 字段定义
• jev-benchmark — 60 例工具调用风险分类基准（社区一手实测）
• I Benchmarked Jev on Agent Tool-Call Risk. Calibration Held. — 社区作者复现文章与置信度分桶分析
• Awesome TypeSafe — 社区整理的 TypeSafe 资源与示例（含 Quickstart 引用，本文未单独核对官方原文）