8.0
热点
AI SCORE
编程提效2026-09-24 14:07
Jev 决策模型真实成本拆解：何时省钱何时烧钱
dev.to · AI#AI成本优化#Agent#模型路由
Editor brief · 编辑速览
系统性分析模型路由、上下文过滤、输出验证三种架构下的总成本，量化 Jev 在不同场景的降本效果与边界条件。
一次 Jev 调用的费用很低，但在 AI 智能体上叠加一个低成本决策模型，并不会自动让整个任务变得更便宜。
真正的问题是：Jev 能否将部分请求路由到确定性代码或更便宜的模型、减少发送给主模型的上下文量，并通过验证结果来防止无效重试。与此同时，Jev 自身的误分类、延迟、人工审核需求以及工程维护也会产生成本。
本文拆解三种常见架构——模型路由、上下文过滤和输出验证——并提供一套完整的成本框架，来回答一个实际问题：Jev 在何时能降低智能体的总成本，又在何时只是徒增一次 API 调用？
许多 AI 智能体的成本问题看似源于昂贵的主模型。实际更深入的症结往往是：工作流没有区分不同类型的任务。
"查看我的订单状态"这样的请求，可能只需一次数据库查询。"分析过去六个月订单异常的成因"这样的请求，可能需要一个强模型来综合多个数据源。还有一些请求包含的信息不足，所以最合理的下一步不是调用任何模型，而是向用户请求澄清。
当每个请求都被直接发送到同一个强大模型时，系统确实保持简洁，但对于许多本可以由确定性代码或更小模型完成的任务，它支付了同样的价格。
Jev 提出了一种不同的思路。
它不是为聊天或长文本生成而设计的。开发者向它传入一个状态并提出一组带类型的问题；Jev 返回结构化的决策和概率，如 Choice、Score 或 Noul。业务逻辑可以据此决定是否调用某个工具、使用更便宜的模型、升级到更强的模型，或者将案例转给人工处理。TypeSafe 将 Jev 描述为第一个"系统一"模型：一个专为软件内部快速、结构化决策而设计的模型。(typesafe.ai)
从定价角度看，这类决策的成本几乎可以忽略不计。
上线之初，TypeSafe 将 Jev 定价为每百万输入 token 0.042 美元，不收取输出 token 费用。该公司还表示，端到端典型延迟为 70–500 毫秒，同时指出这些数据来自特定地区和测试条件，不应被视为任何部署环境的代表性指标。(typesafe.ai)
一次廉价的决策不会自动让整个智能体工作流更便宜。
Jev 能否省钱，取决于它是否改变了后续发生的事情，而不是仅仅取决于 Jev 调用本身的费用有多低。
真正的 AI 智能体账单远不止模型费用
完成一个智能体任务通常会产生至少六类成本：
因此，更完整的单任务成本应如下所示：
Total cost
= decision cost
+ context-processing cost
+ downstream model and tool cost
+ retry and fallback cost
+ human-review cost
+ remediation cost caused by wrong decisions
Jev 调用通常只占这个总成本的极小一部分。
它真正的价值在于减少后续的那些成本项：避免一次昂贵的模型调用、省略无关的上下文、阻止一个失败任务被重新执行，或者只让人工审核那些确实不确定的案例。
最常见的三种成本节省模式可以归纳为三类：
前置路由：先决策，再选择调用什么。
上下文过滤：在调用主模型之前移除不必要的干扰信息。
后置验证：先用更便宜的模型执行，仅在验证失败时升级。
最直接的架构如下：
User request
↓
Jev evaluates intent, complexity, and risk
↓
Deterministic code / cheaper model / stronger model / human
TypeSafe 官方路由模式遵循同样的理念：并非每个请求都必须进入同一个 LLM。有些可以走确定性代码，有些可以走专用模型，复杂或高风险的请求可以升级到更贵的模型或人工处理。(docs.typesafe.ai)
例如，一个客服智能体可以先问：
这是否仅仅是一个订单状态查询？
它是否涉及退款或拒付？
应该转给计费、技术支持还是销售团队？
它是否需要人工介入？
它是否真的需要一个前沿推理模型？
Jev 只负责做出这些决策。
数据库查询、退款操作、回复生成和人工工单处理仍然由周围系统执行。
一次路由决策有多便宜？
在原始资料中记录的一次真实 API 测试中，十张支持工单被放入单个请求。每张工单都被评估了路由需求以及是否需要人工审核，共产生了 20 个问题：
总输入：2,571 个 token； 调用耗时：约 405 毫秒； 按公开价格计算，总成本：约 0.000108 美元； 每张工单平均成本：约 0.0000108 美元； 按相同 token 规模推算：每百万张工单约 10.80 美元。
当同样的十张工单作为十个独立调用发送时，总耗时约 3,664 毫秒。主体路由结果保持一致，但边界案例的部分概率出现了明显偏移。这说明批量处理可以大幅降低请求开销，但并不能证明路由在所有业务领域都准确，也不能证明相同的阈值适用于所有高风险关卡。
C_high：一次强模型调用的成本； C_low：一次更便宜模型调用的成本； C_jev：Jev 决策的成本； P_code：确定性代码能够完成请求的比例； P_low：更便宜模型能够完成请求的比例； P_error：因路由错误需要修复的请求比例。
如果每个请求都直接走强模型，预期成本为：
C_direct = C_high
加上路由后，预期成本变为：
C_route
= C_jev
+ P_low × C_low
+ P_high × C_high
+ P_error × C_repair
因此，路由只有在下述条件成立时才能省钱：
强模型成本节省
>
Jev 成本 + 路由错误导致的修复成本
由于 Jev 本身非常便宜，最终的经济账通常取决于两个问题：
有多少请求确实可以绕过强模型？
路由失误的后果有多严重？
以下使用假设价格来演示逻辑，并不代表任何特定模型的实际价格：
强模型：每次调用 0.01 美元； 更便宜的模型：每次调用 0.002 美元； Jev：每次调用约 0.0000108 美元； 总请求量：100,000 条。
假设路由后产生如下分布：
20% 由确定性代码完成； 50% 走更便宜的模型； 30% 走强模型； 另有 5% 因错误或失败需要一次强模型修复调用。
在这些假设下，总成本下降约 55%。
但假设只有 10% 的请求可以使用更便宜的模型，90% 仍然到达强模型，另有 5% 需要修复。总成本变为约 971.08 美元。节省约 2.9%。
一旦加上开发、监控、阈值校准和额外延迟，路由层的成本可能不再值得投入。
因此首先要衡量的不是 Jev 的单价，而是：
你的实际流量中，有多大比例确实不需要强模型？
上下文是智能体成本的另一个主要来源。
一个长时间运行的智能体可能积累：
对话历史； 多轮工具输出； 检索到的搜索段落； 不再相关的计划和中途结果。
许多系统将所有这些都重新发送给主模型。即使当前任务只需要其中一小部分，系统仍然为每个输入 token 付费。
Jev 可以放在主模型之前来决定：
哪些搜索结果与当前问题相关； 哪些工具输出可能在后续重要； 哪些早期消息包含约束条件或未完成的工作； 哪些段落可能包含提示注入； 哪些信息可以删除或仅用摘要表示。
TypeSafe 官方用例地图也包含上下文选择、语义检索、RAG 段落过滤以及智能体 harness 内的上下文管理。(docs.typesafe.ai)
其货币效果可以近似为：
Net context benefit
= removed tokens × primary-model input price
- Jev filtering cost
- re-retrieval and retry cost caused by missing information
前两项容易计算。第三项是最常被忽略的。
去掉数十条无关日志行通常是一个明确的收益。但从早期消息中删掉一条关键用户约束，可能导致主模型生成完全错误的结果，从而引发又一次检索、又一次模型调用，甚至人工修复。
一次重跑就能消耗掉多次成功的上下文过滤操作所节省下来的成本。
因此，Jev 更适合决定哪些材料可能是相关的，而不是充当唯一的永久记忆管理器。生产系统至少应该做到：
始终保留系统指令、用户硬约束和安全规则；
保留已删除内容的索引或原始副本；
允许智能体在信息不足时检索被省略的材料；
使用下游任务完成情况来评估成功，而不是仅仅看压缩比。
对于上下文压缩，更有意义的指标是：
压缩后总 token 数
+ 重新检索的 token 数
+ 因遗漏导致的重试 token 数
——而不是"本轮删除了多少 token"。
节省成本模式 3：让更便宜的模型先行动，用 Jev 做验证
另一种常见架构不要求 Jev 选择模型，而是要求 Jev 检查另一个模型的输出。
流程如下：
更便宜的模型产生结果
↓
Jev 检查事实依据、提取字段、政策风险或完成质量
↓
通过：使用该结果
失败：重试，升级到更强的模型，或发送给人工
TypeSafe 将这类模式称为 Universal Verification。其官方材料包括 RAG 引用检查、工具调用验证、输出质量评估和结构化数据提取级联。官方 SDE Cascade 示例使用"便宜模型提取 → Jev 逐字段验证 → 仅在出现红旗时升级到推理模型"。这些是厂商手册中的成果，不应被解读为证明每个提取任务都能实现相同的成本降低。(docs.typesafe.ai)
该级联的预期成本大致为：
C_cascade
= C_low
+ C_jev
+ P_escalate × C_high
+ C_failure
最重要的变量是 P_escalate：更便宜模型的结果中仍需交给强模型处理的比例。
忽略失败成本，当以下条件成立时，级联比将所有请求直接发送到强模型更便宜：
P_escalate
<
1 - (C_low + C_jev) / C_high
使用之前相同的假设价格：
更便宜的模型：$0.002；
Jev：约 $0.0000108。
因此盈亏平衡升级率约为 80%。换言之，只要最终升级的请求少于约 80%，名义上的模型账单就可能保持在"每个请求都使用强模型"的基线以下。
但这只是价格盈亏平衡点，而非质量盈亏平衡点。
"接近强模型"和"与强模型质量相同"是不同的成本目标
一项预先注册的非关联评估在 CLINC150 样本上测试了 Jev 到强模型的级联：
当最终准确率允许比强模型低一个百分点时，Jev 需要升级约 22% 的请求；
当目标是与强模型完全相同的准确率时，该级联不得不升级每个请求，实际上退化为"始终调用强模型"。
因此研究人员强调，结果应被理解为"以更低成本接近强模型质量"，而不是"用更少调用达到相同质量"。该实验仅使用了 200 个样本、一个数据集和一条服务路径，因此不能直接推广到其他智能体。然而它确实说明了一个重要的经济模式：质量目标的微小提高可能导致升级率的大幅跳升。(github.com)
因此，级联评估不能仅报告：
避免了多少次强模型调用；
自动处理的流量百分比；
自动处理子集的准确率；
最终端到端任务成功率；
相对于将所有请求发送给强模型所损失的质量；
哪些错误会被下游执行放大。
在同一调用中提出多个问题通常比批处理请求更重要
Jev 支持对同一状态提出多个问题并并行返回答案。官方文档建议将复杂决策分解为原子问题，然后在代码中组合结果，而不是将多个判断打包到一个模糊的提示中。(docs.typesafe.ai)
例如，不要问：
应该如何处理这个工单？
它应该进入哪个业务队列？
它是否明确要求退款？
它是否提到拒付、法律诉讼或监管机构？
它属于哪个紧急程度级别？
是否需要人工处理？
值得调用更强的模型吗？
在原始材料的测量中，将单个状态从 1 个问题增加到 8 个再增加到 32 个，保持预热后延迟大致在相同的 350–400 毫秒范围内。输入 token 随问题数量增加，但网络往返时间并非线性增长。
因此一种合理的模式是：
在一次请求中提出当前步骤真正需要的所有原子问题，而不是为每个决策发送单独的 API 调用。
但批处理并不意味着将每个用户、每个文档和每个任务合并成一个巨大的状态。工单实验还发现，基于数组的批处理保留了主要分类，但会改变一些边界概率。
批处理策略仍需在应用的实际数据分布上进行验证。
四个容易被忽略的隐藏成本
1. 置信度不等于准确率
类型化输出可以保证响应符合接口，但不能保证业务决策正确。
一项独立评估发现，在 200 个样本中，Jev 对 102 个样本返回了恰好 1.0 的置信度值，其中 6 个是错误的。研究人员也没有发现 Jev 的置信度在排名自身错误方面比小型 LLM 自我报告的置信度更好。(github.com)
这意味着生产逻辑不应被简化为：
if (confidence === 1) {
executeDestructiveAction();
}
更安全的方法是：
当需要特定决策规则时，优先使用选项级概率；
在应用特定的标注集上选择阈值；
对不同风险级别使用不同阈值；
保留人工确认用于支付、删除、封禁等类似操作；
记录模型版本、概率和最终结果，以便监控漂移。
另一项预先注册的校准评估也产生了混合结果：CLINC150 上 ECE 为 0.0204，Banking77 上为 0.0936，后者存在系统性过度自信。这表明校准取决于任务和语料库；为一个数据集调整的阈值不应直接转移到另一个业务领域。(systemonemodels.org)
2. 路由错误不是免费的
如果路由器将简单请求发送到强模型，主要后果可能是错过了一个节省机会。如果它将复杂请求发送到确定性代码，结果可能是错误响应、重复工作或用户流失。
对于高风险任务，单次错误决策的成本可能超过所涉及的所有模型调用成本。
因此，分别跟踪四种错误类型是有用的：
误升级：一个本可以廉价处理的请求被发送到了强模型；
误降级：一个需要强模型的请求被分配到了更便宜的路径；
误通过：验证器未能捕捉到有缺陷的结果；
误阻止：正确的结果被迫进入重试或人工审查。
单一的总体准确率数字无法捕捉这四种成本。
3. 延迟和失败也是成本
在原始材料中，预热后的串行调用大多在 340–450 毫秒左右。在一次 24 并发请求测试中，中位延迟上升到约 1.2 秒，并发生了 3 次传输失败。这是一个小测试，仅在一种环境中进行，不能描述官方服务的一般可用性，但它足以说明生产架构不能将决策层视为一个不会出错的本地函数。
系统至少应预先定义：
超时是导致故障开放、故障关闭还是人工升级；
是否重试，重试多少次；
Jev 不可用时是否应触发直接调用主模型；
路由服务故障是否会阻塞整个智能体；
p95 和 p99 延迟是否仍符合产品的交互预算。
另一项第三方预先注册评估观察到 Jev 的中位调用时间约为 0.42–0.44 秒，同时明确指出这反映的是特定客户端、网关、区域和负载，而非纯模型推理速度。(github.com)
Jev 的一个重要优势是冷启动：当没有标注数据时，它可以从自然语言描述中进行零样本决策。
但当一个稳定的工作流已经积累了许多人工标注的示例时，传统的small model可能会更有吸引力。
在一项预先注册的 Banking77 评估中，一个冻结的 bge-small 嵌入模型加逻辑回归，在 10,003 个样本上训练后达到了 0.933 的准确率，而 Jev 达到了 0.832。编码器在测试硬件上运行约 9 毫秒，且没有按请求计费的 API 费用。研究人员还强调，信息条件是不同的：编码器看到了大量分布内的标注数据集，而 Jev 是在零样本条件下评估的。因此，这并不是同条件下的模型能力对比，而是实际部署替代方案之间的对比。(github.com)
一条实用的演进路径可能是这样的：
Jev 可能特别适合作为冷启动加速器和长尾决策层，而不是必然成为每个稳定分类任务的永久终点。
从真实应用中取一组历史任务，比较三条离线路径：
A. 将每个任务发送给强模型
B. Jev 路由 → 代码 / 更便宜的模型 / 强模型
C. 更便宜的模型 → Jev 验证 → 需要时升级到强模型
至少记录以下指标：
最有意义的指标不是"Jev 决策准确率"，而是：
每次成功完成任务所需的成本
即使一个极其便宜的决策 API，如果它产生了更多的重试、人工审核或错误的执行，也可能让智能体的经济效益变低。
以下条件满足得越多，Jev 越有可能创造实际价值：
请求量大且决策频繁；
任务边界清晰，可以分解为单步语义问题；
许多请求可以用确定性代码或更便宜的模型处理；
还没有足够的标注数据来训练专用分类器；
主模型调用的成本明显高于决策调用；
错误可以通过升级、重试或人工审核来控制；
系统可以记录概率、阈值和最终结果；
决策标准需要快速添加或更改。
反之，在以下情况下，引入 Jev 不应该是第一步：
几乎每个请求最终都需要强模型；
流量低，API 节省无法抵消工程复杂度；
任务需要多步推理、算术运算、日期比较或长文本生成；
错误的决策可以直接触发不可逆的操作；
已经存在大型、稳定的标注数据集，可以支持本地 small model；
无法建立可靠的回退和人工审核路径；
计划是将官方 demo 的阈值直接复制到生产环境。
Jev 调用确实很便宜，但这并不能决定它是否能降低 AI 智能体的成本。
它真正的价值在于，它可以将一个原本会将所有请求都发送到同一个强模型的工作流进行拆分：
简单请求走确定性代码；
常规请求走更便宜的模型；
复杂请求走强模型；
不确定的请求走人工；
冗余的上下文不会被发送；
有缺陷的结果在到达用户之前就被阻止了。
如果 Jev 被放在主模型前面，但每个请求仍然继续发送到该模型，那它只是增加了一次 API 调用。
如果它可靠地减少了昂贵的调用、上下文大小或返工，它就成为了一个真正的成本杠杆。
因此，正确的问题不是：
一次 Jev 调用有多便宜？
而是：
在这个决策之后，系统不再需要做哪些昂贵的工作？
这才是 AI 智能体应该计算的全部成本公式。