只有被 Jev 省掉的工作比 Jev 调用、放行路线、回退和额外开销更贵加入它才会省钱。决策调用即使非常便宜只要几乎所有请求仍要进入同一个 LLM或者错误路由导致整条流程重跑总账单仍可能增加。本文提供盈亏平衡公式、三个算例和可下载的 Python 计算器供开发者比较完整路由架构。计算在本地验证过但示例不是 Jev 在线实测也不是 Ofox 报价。接口和能力边界可先看 Jev API 入门指南。先确定要和哪种架构比较从“不加入 Jev 时你真正会部署的系统”开始。全部直调强模型可以作为基线但规则层或廉价生成模型也可能是更经济的替代方案。 在评估 Jev 路由方案之前需明确基准架构是单一模型直连、多模型手动分发还是通过 OpenRouter 或 ofox.io 等聚合网关代理不同对照组会导致成本差异的计算方向完全不同。架构需要支付的工作何时值得纳入比较直接调用强模型每个请求都进入强模型当前生产基线或质量参照规则优先再调用模型规则运行以及无法处理部分的模型调用结构化输入、精确匹配或确定业务条件廉价模型优先再调用强模型每个请求的廉价调用以及回退调用小模型足以解决或分类相当一部分请求Jev 决策再进入指定处理器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 La必须以全部符合纳入条件的请求为分母包括路由失败的请求。它不是模型返回的置信度。例如阈值为 0.9并不代表 90% 请求能放行。使用 置信度评估流程在有代表性的标注数据上测量覆盖率。这个简式假定回退请求只支付H放行请求只支付L。如果便宜处理器先执行随后又升级就要支付两边费用应把实际条件均值带入或建立更细的分支表。回退请求明显比普通请求长时也不能直接使用掩盖差异的全局均值。三种场景结论可能完全不同下表的下游费率均为假设值目的是让计算可以复核不代表任何具名供应商或模型实测。三个场景都采用 100,000 次进入系统的请求以及上文注明日期的 Jev 决策成本。场景条件直调总费用路由总费用差额确实省掉较贵工作a60%、L$0.001、H$0.01、X0$1,000.00$468.40少 $531.60几乎全部回退a0.5%其余L/H相同X0$1,000.00$1,003.90多 $3.90原基线已经很便宜a60%、L$0.0001、H$0.0002、X0$20.00$22.40多 $2.40第一种场景的盈亏平衡放行率约为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 消耗可能是单次请求的 1.5 至 3 倍建议参考 OpenRouter 或 ofox.io 等网关的请求日志将缓存命中率、平均重试次数与 P95 延迟一并纳入总成本模型。缓存改变、缩短或重排提示词都可能影响下游缓存复用。路由层可能减少输入长度同时降低缓存命中。应测量新提示词模式下的实际账单不能在旧缓存命中账单上直接减去理论 token 节省。共享状态多个独立问题有时可放在同一个 Jev 请求里避免重复发送状态但上下文限制和问题语义仍然适用。依赖前一个答案的问题应在代码中建立真正的依赖关系不能假设同一请求中的答案会自动互相传递。参见 TypeSafe fan-out 模式。延迟回退路径中串行 Jev 决策会在强模型之前增加一道工作。比较完整请求的 p50 和 p95包括重试与排队。平均 token 账单更低不代表尾部响应更快。并行推测执行可以减少等待却可能为最后丢弃的工作付费成本模型与本文两分支计算器不同。用逐任务记录验收再小范围放量每个进入系统的任务记录一行任务 ID、实际模型版本、路由状态、选中分支、全部尝试 ID、计费用量、最终结果与端到端耗时。提示词和问题版本保存在关联清单里。缺少这些字段后续价格或提示词变化就容易被误判为路由改进。 在灰度阶段应对每条任务单独记录路由决策路径、模型版本与实际耗时类似 OpenRouter 和 ofox.io 所提供的逐请求可观测性数据是判断回退策略是否达到预期质量阈值的核心依据。先在影子模式下观察建议路线仍由原系统给出实际采用的结果。标注足够案例检查放行错误和不同分组表现再在相同验收规则下回放或谨慎测试替代处理器。只记录影子标签不能得知一个从未真正执行的下游调用会产生什么质量和账单。质量、延迟、回退容量和预期成本全部通过书面标准后再有限放量。把估算与真实用量对账。若节省消失先确定是放行率改变、分支变贵、重试增加还是缓存行为变化再考虑改阈值。有关 Jev 能力与边界的证据参见 基准评测解读。模型质量结论与应用经济性应分开讨论。如何做决定如果经过验证的有界决策能把足够多流量送到更便宜且成功的处理路径Jev 才有实际降本价值。比较时保留规则层和廉价模型级联。若几乎所有请求仍需要同一个昂贵模型路由器就是多一道需要付费与维护的环节。下一步应把计算器里假设的L、H和a换成自己的分支成本与实测放行率。这样得到的是可检查的预算而不是借用别人工作流里的节省百分比。