Jev 价格与成本：算清一个工作流

成本页最容易让读者产生错觉：一个很小的单次金额，看起来好像已经证明整个业务便宜。实际预算需要同时包含调用次数、输入长度、失败重试和后续处理。本章提供一个可以替换数字的计算方法。

先固定计费来源和日期

截至本版核对日 2026 年 9 月 20 日，TypeSafe 模型页列出的直接 API 输入价格为每百万 token 0.042 美元，输出 token 免费。这里采用直接供应商的口径；通过其他网关使用时，另外核对该网关的价格、附加费用和额度规则。官方模型与价格

这不是价格长期不变的承诺。付款或扩大量之前重新检查当前账号的计费说明。页面更新日期、教材版本与实际调用日期可能不同，应以实际服务条款与账单为准。

请求中的材料和问题都需要传给服务。不要用文章字数简单代替 token 数，尤其不要用英文的粗略比例推算中文。真实请求以返回的 usage.input_tokens 为记录依据，并与账单核对。响应与 usage 字段

模型输入费用（美元）
= 所有实际请求的 input_tokens 总和
  ÷ 1,000,000
  × 每百万输入 token 的单价

以下都是算术示例，不是本书实际调用记录。假设平均每次输入 1,200 token，并暂按 0.042 美元/百万 token 计算：

这些数字不包含税费、其他模型、托管、外部工具和人工。它们也没有证明这些请求的判断足够准确。一个几乎免费的错误判断，如果导致大量返工，仍然可能不值得自动化。

如果 10,000 个业务任务实际产生 10,800 次请求，并且每次仍按 1,200 token 假设，则输入为 12,960,000 token，费用为 0.54432 美元。这里的 8% 额外请求只是教学设定。

真实系统应统计发送了多少请求，而不是只数最终成功了多少个业务任务。对于超时等未拿到 usage 的请求，保留“费用未知”的状态，再与供应商账单核对。缺失使用量不是免费，也不应该被填成零。

同一份材料上的多个独立判断，可以在一个请求中组织。共享材料可以减少重复传入，但问题本身仍有长度，最终以真实 usage 为准。并行回答多个问题，也不代表多个工具可以跳过权限校验并行执行。

配套程序的离线模式不发送模型请求，因此其模型使用量和模型延迟应为空或明确标为未测。不要用读取本地 JSON 的耗时替代网络推理耗时，也不要把预设 fixture 数量变成一个看似精确的账单。

先检查输入中哪些信息对判断有帮助。工单分拣通常不需要完整历史邮箱；文章检查可能需要正文与清单，却不需要全部网站模板。删减材料后，用同一组开发样本比较结果，确认没有删掉会改变判断的证据。

把业务真正需要的判断列出来。如果只需要“是否缺少操作步骤”，就不必默认再问几十个无人使用的评分。相反，如果同一份正文确实有四项独立检查，可以一起组织，减少重复请求材料的复杂度。

最后再考虑并发。更多并发可能缩短批处理墙钟时间，也可能触发限流并增加重试。分别记录总处理时间和单请求时间；不要把吞吐量、端到端延迟、模型准确率揉成一个“更快更好”的结论。

一份实用的工作流预算可以写成：模型调用 + 其他服务 + 运行环境 + 人工复核与返工。人工部分常常取决于复核比例和错误种类，而不仅是流量。

假设某阈值让更多工单自动分流，但错分增加；另一个阈值需要更多人工，却减少跨部门返工。先用评测章的方法记录两种政策，再算各自的工作量。本书不给统一的最便宜阈值，因为没有你的流程数据就无法计算它。

本章的完成标准，是你能拿一份真实运行记录换掉表中的假设数字，并明确指出仍未统计的成本。对于本版尚未进行的真实调用，保留“未实测”比填入一个漂亮的小数更有用。