Clawy / 指南 / 为付费 AI API 定价

如何为付费 AI API 定价而不亏钱

如果你以固定单次价格转售或封装 GPT 或 Claude，一个大 prompt 就可能让你的成本超过收费。下面是计算方法和两种解决办法。

你封装了一个 LLM，放在端点后面，收一个整齐的固定价——比如每次 $0.15。对客户清晰，易于理解。问题是：底层模型不按次计费，而是按 token 计费，token 随 prompt 和响应大小增长。小请求你赚一大笔利润，大请求你可能付出比收到的更多——而你直到供应商账单到来才会发现。

为什么固定价格会漏钱

按 token 计费的模型对输入（你发送的 prompt）和输出（模型生成的内容）分别收费。根据 Claude 的官方标价：

你一次调用的成本就是：

cost = (input_tokens × input_price + output_tokens × output_price) / 1,000,000

以 Opus 4.8 固定价 $0.15/次 为例。仅输出就是每百万 token $25——所以仅 6,000 个输出 token 就要 $0.15，在你还没算一个输入 token 之前就吃掉了全部售价。让客户发来 10 万 token 的文档作为上下文并要求长回答，这一次调用就可能花掉你售价的好几倍。再乘以几个重度用户，"盈利"的产品就在亏损运行。

上线前先算出你的盈亏平衡点

关键数字是在一次调用成本超过你收费之前，你能服务的最大 prompt。固定输出大小后，盈亏平衡的输入大小为：

break_even_input_tokens = (price × 1,000,000 − output_tokens × output_price) / input_price

对于 Opus，价格 $0.15、回答 800 token：(0.15 × 1,000,000 − 800 × 25) / 5 = 26,000 个输入 token。prompt 超过约 2.6 万 token 后，每次调用都亏钱。如果你的真实流量经常超过这个值，固定价格就是错的模型——或者你的价格定得太低。

解法 1 —— 限制输入和输出

如果你想保留固定价格（客户喜欢它的可预测性），就给两端都设界限，让最坏情况的调用也不能超过你的售价：

• 限制输入大小。对超过 token/字符上限的 prompt 拒绝或截断——并且在收费或调用模型之前就做，这样超大请求不会让你花钱。
• 限制输出（max_tokens）。即使设一个宽松的默认值，也能给昂贵的一端设界。按 $25/百万，每 1,000 个输出 token 是 $0.025。
• 用上面的计算来确定上限。选择满足 worst-case cost < price 的上限，并为重试、回退和 prompt 缓存未命中留出余量（预留约 25–40% 的空间）。
• 公开这些限制。把输入/输出上限写进你的 API schema，让客户端自我限制，而不是撞上意外拒绝。

固定价格的端点正是这样保持不亏损：价格固定，但其背后的工作量有界，所以永远不会入不敷出。

解法 2 —— 按用量定价

另一种办法是别再假装每次调用都一样，而是按实际消耗计费：按 token 计量（通常在成本上加一个倍率），或按请求大小分级收费。你放弃了一个整数的简洁，但永远不会在大请求上亏钱，因为价格随成本变动。当 prompt 大小波动很大或你服务大上下文负载时，按用量才是对的。

别忘了隐藏成本

• 重试与回退。一次失败后在第二个模型上重试的调用，可能让一个对客户可见的请求的 token 花费翻倍。
• prompt 缓存未命中。缓存能把重复前缀的成本降低约 90%，但只在命中时——一个隐形的缓存失效因素（system prompt 中的时间戳、未排序的 JSON）会让你每次都付全价。
• 思考 / 推理 token。如果你启用扩展/自适应思考，这些 token 也按输出计费。

无论你选哪个模型，纪律都一样：知道你的单次成本、知道你的盈亏平衡点，并在最坏情况触及付费客户之前就给它设界。