Jev 路由真能省 LLM 费用吗？算清回退成本与盈亏平衡点

只有被 Jev 省掉的工作，比 Jev 调用、放行路线、回退和额外开销更贵，加入它才会省钱。决策调用即使非常便宜，只要几乎所有请求仍要进入同一个 LLM，或者错误路由导致整条流程重跑，总账单仍可能增加。

本文提供盈亏平衡公式、三个算例和可下载的 Python 计算器，供开发者比较完整路由架构。计算在本地验证过，但示例不是 Jev 在线实测，也不是 Ofox 报价。接口和能力边界可先看 Jev API 入门指南。

先确定要和哪种架构比较

从“不加入 Jev 时你真正会部署的系统”开始。全部直调强模型可以作为基线，但规则层或廉价生成模型也可能是更经济的替代方案。

路由器把请求交给更便宜的模型，并没有消除生成环节，选中的模型仍要完成最终答案。放行分支若完全由确定性代码处理，模型费用可以为零，但运营成本未必为零。必须说清计算边界。

公开研究也提醒我们，不要只挑容易赢的对照。REFLEX 在受控 Agent 基准中报告了收益，但外部评估中，相对廉价生成模型级联的优势有限。这支持把廉价级联加入比较，不构成对 Jev 的普遍肯定或否定。参见 REFLEX 论文。

论文的 τ²-bench 验证给了一个具体例子：每个任务单元的成本分别为强模型直调 0.2111 美元、REFLEX 0.0572 美元、廉价级联 0.0411 美元；观测成功率依次为 90.0%、85.0%、91.7%。配对成功率差异在统计上尚未得到明确结论，不能据此证明质量相同或某方案普遍更好。但只宣传相对强模型的降本，隐去更便宜的级联方案，会误导购买判断。

论文另一项跨模型家族实验也区分了调用数与费用：Qwen 强模型调用减少 71.9%，核验后的实际费用减少 52.2%；Kimi 和 DeepSeek 两行没有给出经核验的费用节省。账单取决于 token 长度和费率，不只是少调用了多少次。这些是论文历史结果，不是下文计算器的假设，也不是我们的测量。

先用对 Jev 的计费单位

截至 2026 年 10 月 2 日核验，TypeSafe 官方直连模型文档列出的 jev-1.13.0 输入价格为每百万 token 0.042 美元，输出 token 免费。页面也区分了总请求预算与状态加最长问题的预算。这是 TypeSafe 直连公布价，不是 Ofox 报价，更不是所有网关都采用同价的承诺。参见 模型文档。

2026 年 10 月 2 日采集的官方英文文档原始截图。制定预算前应重新核对在线来源；下文计算保留这一日期的费率。

把请求中所有计费输入都算进去，包括状态与问题，而不只是应用代码里看得到的短指令。若多个独立请求重复发送同一状态，除非供应商明确给出其他计费规则，否则每次都应计入。价格来源没有提供缓存折扣时，不要自行假设存在。

假设每次请求有 2,000 个输入 token，仅有一次计费尝试：

Jev 费用 = 2,000 × 0.042 / 1,000,000
         = 每次请求 0.000084 美元
100,000 次这样的请求 = 8.40 美元

这 8.40 美元只覆盖上述条件下的 Jev 决策环节，不包含下游生成、重复尝试、监控，或错误操作造成的代价。

先算请求成本，再算成功任务成本

设 J 为每个进入系统的请求产生的预期 Jev 成本，包括计费尝试；a 为所有进入系统的请求中，被放行到便宜分支的比例；L 为该分支的平均下游成本；H 为回退分支的平均下游成本；X 为额外预期开销。所有费用使用同一币种和每请求口径。

简化的两分支系统可写为：

直调每请求成本 = H
路由每请求成本 = J + a × L + (1 − a) × H + X
每请求节省     = a × (H − L) − J − X
盈亏平衡放行率 = (J + X) / (H − L)，仅当 H > L

a 必须以全部符合纳入条件的请求为分母，包括路由失败的请求。它不是模型返回的置信度。例如阈值为 0.9，并不代表 90% 请求能放行。使用 置信度评估流程在有代表性的标注数据上测量覆盖率。

这个简式假定回退请求只支付 H，放行请求只支付 L。如果便宜处理器先执行，随后又升级，就要支付两边费用；应把实际条件均值带入，或建立更细的分支表。回退请求明显比普通请求长时，也不能直接使用掩盖差异的全局均值。

三种场景，结论可能完全不同

下表的下游费率均为假设值，目的是让计算可以复核，不代表任何具名供应商或模型实测。三个场景都采用 100,000 次进入系统的请求，以及上文注明日期的 Jev 决策成本。

第一种场景的盈亏平衡放行率约为 0.933%，因为每次放行能省掉较大的成本差；第三种则需要 84%，因为两条分支本来就只差很少。这两个数值都不是建议阈值，也不是对真实放行率的预测。

第一种场景看起来很划算，仍须通过质量验收。如果便宜分支交付的结果不可用，你就没有以更低成本完成同样服务。除每个进入系统的请求成本外，还应比较每个通过验收、正确完成的任务成本，而且两套系统要沿用相同成功定义。

用第一种场景再做一个示意：假设直调在 100,000 次请求中成功完成 95,000 次，路由只成功 40,000 次。直调每次成功成本为 $1,000 / 95,000 = $0.01053；路由为 $468.40 / 40,000 = $0.01171。总账单虽然更低，每个成功结果却更贵，失败也更多。这里的成功数是专门说明分母作用的虚构算例，不是观测结果；附件计算器不建模质量，也不会自动计算这一指标。

真实成功数应来自逐任务追踪的验收测试。未解决和错误任务都要报告，已经支付的返工也要计入。若失败损失或人工复核费用对业务重要，应在两套系统中保持相同核算范围；单看 API 每成功任务成本，仍不能为所有后果定价。

运行计算器，并替换参数

下载 离线决策工具包，解压后在目录内执行：

python3 cost.py
python3 cost.py --accepted 0.005
python3 cost.py --cheap 0.0001 --strong 0.0002

默认运行返回 direct_total: 1000.0、routed_total: 468.4、savings: 531.6，我们已在本地执行验证。脚本仅用 Python 标准库，不调用 API，也不需要 Key。

用观测参数替换假设：

python3 cost.py --requests 100000 --tokens 2000 \
  --rate 0.042 --attempts 1.2 --accepted 0.6 \
  --cheap 0.001 --strong 0.01 --extra 0.0001

--attempts 1.2 表示假设平均有 1.2 次 Jev 计费尝试，并不是说每次重试必然收费。应以供应商用量记录核对。--extra 是每个进入系统的请求产生的额外预期成本，例如付费验证，或简单分支模型之外实际增加的升级成本。已经计入 cheap 或 strong 的费用，不要再算一次。

强分支不比便宜分支贵时，计算器不会返回普通意义的盈亏平衡比率。这是在提醒你检查架构，不是需要绕过的算术错误。脚本也拒绝负数、非有限值，以及不在 0–1 之间的放行率。

把重试、缓存与延迟算进去

重试：区分传输尝试、计费请求和完成任务。发生超时，不代表上游没有处理或收费，应通过请求 ID 和用量记录核对。限制重试次数，重试下游副作用之前保留幂等控制。

缓存：改变、缩短或重排提示词，都可能影响下游缓存复用。路由层可能减少输入长度，同时降低缓存命中。应测量新提示词模式下的实际账单，不能在旧缓存命中账单上直接减去理论 token 节省。

共享状态：多个独立问题有时可放在同一个 Jev 请求里，避免重复发送状态，但上下文限制和问题语义仍然适用。依赖前一个答案的问题，应在代码中建立真正的依赖关系，不能假设同一请求中的答案会自动互相传递。参见 TypeSafe fan-out 模式。

延迟：回退路径中，串行 Jev 决策会在强模型之前增加一道工作。比较完整请求的 p50 和 p95，包括重试与排队。平均 token 账单更低，不代表尾部响应更快。并行推测执行可以减少等待，却可能为最后丢弃的工作付费，成本模型与本文两分支计算器不同。

用逐任务记录验收，再小范围放量

每个进入系统的任务记录一行：任务 ID、实际模型版本、路由状态、选中分支、全部尝试 ID、计费用量、最终结果与端到端耗时。提示词和问题版本保存在关联清单里。缺少这些字段，后续价格或提示词变化就容易被误判为路由改进。

先在影子模式下观察建议路线，仍由原系统给出实际采用的结果。标注足够案例，检查放行错误和不同分组表现，再在相同验收规则下回放或谨慎测试替代处理器。只记录影子标签，不能得知一个从未真正执行的下游调用会产生什么质量和账单。

质量、延迟、回退容量和预期成本全部通过书面标准后，再有限放量。把估算与真实用量对账。若节省消失，先确定是放行率改变、分支变贵、重试增加，还是缓存行为变化，再考虑改阈值。

有关 Jev 能力与边界的证据，参见 基准评测解读。模型质量结论与应用经济性应分开讨论。

如何做决定

如果经过验证的有界决策，能把足够多流量送到更便宜且成功的处理路径，Jev 才有实际降本价值。比较时保留规则层和廉价模型级联。若几乎所有请求仍需要同一个昂贵模型，路由器就是多一道需要付费与维护的环节。

下一步应把计算器里假设的 L、H 和 a，换成自己的分支成本与实测放行率。这样得到的是可检查的预算，而不是借用别人工作流里的节省百分比。