Jev 上手：怎样用最低成本换到最高质量（含确切配置）

Jev 配置指南：如何用最低成本拿到最高质量

作者：darkzodchi（@zodchiii，写 Substack 的技术作者）

这篇的核心论断很锋利：Jev 的成本算术是反着来的。你会亏钱的地方不是 API 账单，是架构。

一、先看价格表

• $0.042 / 百万输入 token，输出 token 免费

• 速率限制：250,000 token/秒，1,200 请求/分钟（TypeSafe 说在扩容期间这两个数字可能随时变）

• 上下文：每个请求总共 64k token，其中 32k 给 state 加上你最长的单个问题

• 输入：只有文本。字符串、JSON、文本数组。不支持图像和音频

算一下就知道账单不是问题：

1 万 token 的 state × 1000 次决策

Astra: 10M token × $10.00/M = $100.00

Jev: 10M token × $0.042/M = $0.42

这个比例说明：API 账单不是你亏钱的地方。你会在架构上亏。

二、决定你账单的那个设置：每次调用放几个问题

这是全文最有价值的一段：

一个请求里的每个问题，都是并行地对同一个 state 求值的。加问题几乎不影响延迟，而且 state 只计费一次，不是每个问题一次。

所以那个昂贵的错误是：一个问题一次调用。

TypeSafe 自己的 cookbook 把一个 13 个问题的简报两种方式都跑了一遍：打包成一次调用便宜 12.2 倍、快 10.0 倍，而答案没有任何变化。

直接可用的代码：

from typesafe_sdk import TypeSafeClient, Choice, Score, Noul

client = TypeSafeClient(model=“jev-1.13.0”) # 锁版本号，不要用别名

response = client.system_one(

state=ticket_text,

questions={

“category”: Choice(

instructions=“Determine the broad category of this support ticket”,

criteria={

“bug_report”: “Something is broken or producing errors”,

“billing”: “Charges, invoices, refunds, subscriptions”,

“feature_request”: “The user is requesting new functionality”,

“account”: “Login, permissions, profile, security”,

},

),

“bug_severity”: Score(

instructions=“How severe is the reported issue”,

criteria=[

“Cosmetic, no impact to functionality”,

“Broken or degraded feature, workaround exists”,

“Blocking issue, no workaround”,

],

),

“refund_requested”: Noul(

instructions=“The user is explicitly asking for a refund or credit”,

),

“frustration”: Score(

instructions=“How frustrated the user appears”,

criteria=[“Calm”, “Frustrated but civil”, “Very angry”],

),

},

)

注意 model 那一行：作者强调要锁版本号（jev-1.13.0），不要用别名。

然后是那条关键模式：

把可能用得上的问题都问出来。 如果这张工单最后是功能请求，bug_severity 没花你钱，你在代码里忽略它就行。

这就是那个模式：把所有问题扇出，之后在代码里路由。

三、置信度是第二根轴

每个 Choice 和 Score 的答案都带一个 confidence，一个 0 到 1 的数字，来自概率有多集中。分布越平，置信度越低。

答案告诉你「是什么」。置信度告诉你「要不要据此行动」。

而且分三档，阈值随风险高低移动。

四、作者说他会覆盖的其他内容

从推文看，这篇还包含：

• 那个便宜 12.2 倍的请求模式（上面已展开）

• Jev 自己的文档里说它做不到的九件事

第二点值得特别留意——大多数人读模型介绍只看它能做什么，而作者专门去读了它不能做什么。这是判断一个模型能不能上生产时更该看的部分。

五、我的判断

这条和上面那条是完美的一对：那条教你怎么训一个自己的，这条教你怎么把已有的用对。

而且它给出的那个洞察，适用范围远超 Jev：

当你在用一个「state 计费一次、问题并行求值」的东西时，「一个问题一次调用」就是纯粹的钱浪费。 这个坑很多人在第一次接入这类 API 时都会踩，因为大家习惯了 LLM 的那种「一次调用一个问题」的形态。

一个要提醒的边界：文章里那些数字（12.2 倍、10.0 倍）来自 TypeSafe 自己的 cookbook，是厂商自测。方向肯定对（state 只算一次是定价规则本身决定的），但具体倍数要自己在自己的请求形态上量。

链接

推文（117 万浏览）：https://x.com/zodchiii/status/2101243146596384854

作者的 Substack：https://zodchiii.substack.com/

#Jev #成本优化 #Agent工程