CostPerPrompt上线：算清每次AI任务成本

CostPerPrompt把模型价格换算成真实账单

CostPerPrompt近日上线了一款面向开发者的 AI API 成本计算工具，核心思路是把不断变化的模型价格，换算成具体提示词和真实业务负载下的调用成本。截至 2026 年 8 月 2 日，该产品已经通过 Show HN 对外展示，定位不是又一张模型价格排行榜，而是一台用于模型选型和预算预演的计算器。

真实工作负载成本是指完成一项实际业务任务所产生的全部模型调用费用，而不是模型价格页上的每百万 Token 单价。 两个模型即使输入价格相近，只要输出长度、工具调用次数、缓存命中率或失败重试率不同，最终每个有效结果的成本就可能相差数倍。

这正是 CostPerPrompt 值得关注的地方。过去团队比较模型，常见做法是打开多个厂商的价格页，再把输入价、输出价和预计调用量抄进表格。这个办法在单轮聊天中勉强够用，但一旦进入智能体、RAG、批量抽取或长文生成场景，表格很快就会失真。

每百万Token便宜，不等于每个任务便宜

Token 是大模型处理文本时使用的计费和计算单位。 一个 Token 并不固定对应一个汉字或一个英文单词，其数量取决于模型所使用的分词器，因此直接拿字符数乘统一系数，只能得到粗略估算。

单次提示成本由输入 Token、输出 Token及各自单价共同决定。 最基础的计算方式如下：

单次调用成本
= 输入Token数 × 输入单价 / 1,000,000
+ 输出Token数 × 输出单价 / 1,000,000

月度成本
= 单次调用成本 × 日调用量 × 30

这个公式看起来简单，真正容易被低估的是输出。多数生成式模型的输出单价高于输入单价，而客服回复、代码生成、研报撰写等任务的输出长度又很不稳定。一个提示词从 800 Token 缩短到 500 Token，未必比把平均输出从 2,000 Token 控制到 1,000 Token 更省钱。

下面用一组假设价格说明差异，数字仅用于演示计算逻辑，不代表 CostPerPrompt 当前收录模型的实时标价。

| 模型 | 输入价格 | 输出价格 | 每次输入 | 每次输出 | 1万次调用成本 | | --- | ---: | ---: | ---: | ---: | ---: | | 模型 A | 2 美元/百万Token | 8 美元/百万Token | 2,000 Token | 1,000 Token | 120 美元 | | 模型 B | 0.5 美元/百万Token | 2.5 美元/百万Token | 2,000 Token | 1,500 Token | 47.5 美元 | | 模型 C | 1 美元/百万Token | 10 美元/百万Token | 2,000 Token | 600 Token | 80 美元 |

输出更短的模型可能抵消更高的输出单价。 模型 C 的输出价格是模型 B 的 4 倍，但因为示例中的平均输出只有 600 Token，1 万次调用成本并没有扩大到 4 倍。这类差异只有把真实输入和输出分布代入后才能看清。

CostPerPrompt的价值也正在于此：它试图把用户关心的问题，从“哪个模型的百万Token价格最低”改成“我的这一类任务每次究竟花多少钱”。前者适合浏览，后者才能用于产品决策。

一次请求不是一个有效结果

有效产出成本是总调用费用除以最终通过业务验收的结果数量。 它比单次请求成本更接近企业真正承担的单位经济成本，因为失败请求、重试、兜底和人工拒收都在消耗预算。

假设一个内容生成服务每月接收 100 万个任务，主模型平均每次成本为 0.01 美元，表面月成本就是 1 万美元。如果其中 8% 的请求需要重试，5% 还要调用另一个模型兜底，那么实际计费请求至少会增加到 113 万次附近，且兜底模型可能更贵。

有效率会进一步放大隐藏成本。 如果这 100 万个任务最终只有 85 万份内容通过自动规则或人工审核，那么即使总费用仍按 1 万美元计算，每个请求成本是 0.01 美元，每个有效产出的成本却已经上升到约 0.0118 美元，增幅约为 18%。加入重试与兜底后，差距还会继续扩大。

有效产出成本
=（主模型费用 + 重试费用 + 兜底费用 + 其他模型调用费用）
  / 最终有效产出数量

这套算法对图片、视频和智能体产品尤其重要。图片生成经常出现构图不合格或文字错误，视频生成可能因时长、清晰度和审核规则被丢弃，而智能体完成一次用户任务往往会连续调用规划模型、检索服务、重排序器和总结模型。

智能体会把一个按钮变成十几次计费

智能体工作负载是由模型推理、工具调用、检索和多轮状态更新共同组成的复合任务。 用户看到的可能只是点击一次“生成报告”，后台却可能先拆解问题，再执行三次搜索、两次重排序、一次代码运行和一次最终总结。

这种链式调用会让按请求估算彻底失效。假设一个研究型智能体每轮执行 6 次模型调用，每次平均成本为 0.004 美元，单轮模型费用就是 0.024 美元；如果规划器判断失败并重新执行一次，成本会直接接近 0.048 美元，而不是产品经理表格里写的 0.004 美元。

微软在 AI 工作负载成本优化指南中也提醒，每个代理步骤触发的检索都可能成为可计费查询，并建议记录每个用户轮次的检索调用次数，将中位数控制在两次或更少。这个判断很实际：真正烧钱的往往不是某个模型贵了 20%，而是流程在无人察觉时多跑了两遍。

CostPerPrompt目前最有用的场景，因此不是替财务核对发票，而是在上线前回答三个工程问题：

1. 当前提示词和预期输出长度下，每次任务的基础成本是多少；
2. 日调用量从 1 万增长到 10 万后，月度预算会增加多少；
3. 更换模型后，单价下降能否覆盖输出变长或调用次数增加带来的成本。

怎么用它做一次靠谱的成本预演

成本预演是用生产流量样本和实际调用链，在上线前模拟一段时间内的模型支出。 最可靠的方法不是手填一个“平均提示词”，而是从日志中抽取一批有代表性的任务，再按业务分位数分别计算。

第一步是准备真实样本。团队可以从脱敏后的生产日志中抽取至少 200 至 500 条请求，覆盖短问答、长上下文、异常输入和高价值用户任务。若产品尚未上线，则应使用评测集，而不是临时写三条看起来规整的演示提示词。

第二步是统计输入与输出分布。平均值很容易掩盖长尾，因此至少要记录 P50、P90 和 P99。一个任务的平均输入可能只有 2,000 Token，但 P99 达到 30,000 Token；当产品支持上传长文档时，这部分长尾可能决定峰值预算和超时率。

第三步是按模型填写价格与工作负载。CostPerPrompt主打实时价格和工作负载换算，但“实时”并不意味着绝对不会过期，特别是模型厂商可能调整缓存、批处理、推理档位或区域定价。准备采购预算时，仍然需要回到模型官方价格页复核计费单位和生效日期。

第四步是加入生产损耗。推荐至少单独记录重试率、兜底率、平均调用步数和有效产出率。如果计算器暂未覆盖某个变量，可以在导出的结果外再乘对应系数，不要假设一次业务任务永远只产生一次模型调用。

第五步是同时跑质量评测。成本优化不能脱离准确率、任务成功率和延迟单独讨论；一个便宜 60% 但通过率从 90% 降到 65% 的模型，通常不是节省预算，而是把费用转移给重试、人工审核和客户支持。

CostPerPrompt与常见成本工具有什么区别

模型价格目录是汇总公开单价的索引，而工作负载计算器会把单价映射到具体业务用量。 两者并不互相替代：价格目录负责回答“多少钱”，工作负载工具负责回答“我要花多少钱”。

| 工具类型 | 主要输入 | 主要输出 | 优点 | 局限 | | --- | --- | --- | --- | --- | | 厂商价格页 | 模型和计费档位 | 官方单价 | 权威、条款完整 | 难以跨厂商比较 | | 静态价格聚合页 | 模型名称 | 多模型单价 | 浏览效率高 | 容易忽略真实Token分布 | | CostPerPrompt | 模型、提示词和工作负载 | 单次及规模化成本 | 更接近实际任务 | 仍依赖输入假设和价格更新 | | 自建电子表格 | 自定义参数 | 团队预算模型 | 灵活、可纳入内部指标 | 维护成本高，容易引用旧价格 | | 云账单系统 | 已发生的调用 | 实际消费 | 最接近结算结果 | 只能看到已经花掉的钱 |

Crazyrouter在 2026 年 6 月更新的成本计算指南也采用了类似的生产化思路，将重试率、兜底占比和有效产出率纳入图片与视频任务估算。这说明成本工具正在从“Token乘单价”走向“业务流程乘成功率”，CostPerPrompt并不是孤立产品，而是顺应了 AI 应用进入规模化运营后的需求变化。

不过，CostPerPrompt仍不能解决所有成本问题。图片通常按张数、质量或尺寸计费，视频可能按秒、分辨率或生成档位计费，语音涉及输入和输出时长，托管开源模型还可能按 GPU 时间收费。一个以文本提示成本为中心的通用计算器，想覆盖所有模态并保持准确并不容易。

价格之外，还要看缓存、批处理和路由

提示缓存是复用重复输入计算结果，从而降低延迟或输入费用的机制。 对拥有稳定系统提示词、固定知识前缀和长对话历史的应用，缓存命中率可能比更换模型更能影响账单，但不同厂商的缓存写入、读取和有效期规则并不一致。

批处理是将非实时请求集中提交，以较低价格或较高吞吐完成推理的执行方式。 摘要、嵌入、离线评估和内容分类通常不要求秒级响应，这些任务如果仍走实时链路，相当于为并不需要的低延迟支付溢价。

模型路由是根据任务难度、风险和上下文长度，把请求分配给不同模型的策略。 一个更实际的架构是让较便宜的模型处理分类、改写和简单问答，把高价模型留给复杂推理或低置信度样本，而不是让所有流量统一进入最强模型。

微软给出的工程建议是，在不发生评估回归的前提下，让路由器至少把 60% 的流量发往更便宜的模型。这个数字不是通用标准，但揭示了正确的优化顺序：先划分任务，再选择模型，最后才是压缩几个提示词。

真正的成本单位应该是“完成一个任务”

任务成本是完成用户目标所消耗的模型、检索、工具和失败恢复费用总和。 这是 CostPerPrompt带来的最重要提醒：AI 产品不应该只追踪 Token 单价，而应该追踪每份合格报告、每次解决的客服工单、每段可用视频或每个成功完成的智能体任务花了多少钱。

对于个人开发者，CostPerPrompt可以快速判断一个创意是否承担得起首批流量。对于已经上线的团队，它更适合作为模型切换前的预算沙盘，与评测集、流量回放和真实账单一起使用。

CostPerPrompt目前最大的优点是降低了跨模型估算的操作成本，最大的风险则是让人误以为输入几个平均数就等于得到了真实预算。任何成本计算器都只能对假设负责；如果团队没有记录重试、长尾上下文、智能体步数和有效率，再精确的小数点也只是精确地算错。

一套可直接执行的成本治理清单

成本治理是用可观测、预算和质量门禁持续控制 AI 工作负载支出的工程流程。 团队可以从下面六项开始：

• 按 workload、tenant、model 和 env 标记每笔模型调用；
• 同时记录输入Token、输出Token、缓存Token、延迟和任务结果；
• 为月预算设置 50%、80% 和 100% 三档告警；
• 将每次用户任务的模型调用数、检索数和重试数纳入监控；
• 在更换模型、提示词或路由策略前运行固定评测集；
• 每周用实际账单校准 CostPerPrompt或内部表格中的预测参数。

成本下降但质量回归的改动不应被视为优化。 如果新路由让单次调用成本下降 30%，却使有效产出率从 90% 降到 70%，那么每个有效结果的相对成本只下降约 10%，还没有计算新增的人工审核和用户流失。

CostPerPrompt的上线说明，AI API 成本管理正在从价格比较阶段进入工作负载核算阶段。对开发者来说，这不是一个华丽的新概念，却是 AI 产品从 Demo 走向规模化经营时必须补上的基础设施。

参考来源

• OpenAI tiktoken：OpenAI开源的分词器项目，可用于理解和统计不同编码下的Token数量。
• Hugging Face Inference Providers定价文档：介绍托管推理服务的计费与价格核算方式，可用于交叉理解不同推理计费模式。