常见问题

成本优化

成本优化

「换个便宜模型」这种建议只在部分情况下成立。这一页按各项手段对账单的实际影响排序。

1. 给输出设上限

几乎所有模型的输出 token 都比输入 token 贵几倍，而不设上限时，输出长度由模型决定。

1{ "model": "claude-sonnet-5", "max_tokens": 800, "messages": [...] }

对抽取、分类、路由这类本来就该短的任务，设上限几乎是白捡的钱。而且它的失败方式是显性的：被截断的响应看得见，不设上限只是默默变贵。

2. 让模型与步骤匹配

大多数管线里，只有一个步骤真的需要最强的模型，其余都不需要。路由、意图识别、打标签、格式转换，用最便宜的档位就够了。

1def model_for(step):
2    if step in ("route", "classify", "extract"):
3        return "glm-5.3-flash"
4    if step == "draft":
5        return "claude-sonnet-5"
6    return "claude-fable-5-1"

这样拆分管线，通常比单纯换某个模型省得多 —— 因为便宜的那些步骤恰恰是高频的。

3. 复用前缀，让缓存能命中

缓存输入的计价远低于新鲜输入。 稳定的系统提示词和稳定的文档前缀，放在请求开头并保持逐字节相同，就能命中缓存。

会破坏缓存的做法：在前缀里塞时间戳、请求编号，或顺序会变的列表。把会变的东西放到最后。

4. 知道哪些模型会自己变价

有两类模型会在容易被忽略的条件下涨价：

  • 高峰时段。 DeepSeek 系列在北京时间工作日高峰时段翻倍；混元 hy3 有自己的每日窗口。夜间跑的批处理很便宜，同一批放在周二 10:00 就不是了。
  • 上下文档位。 GPT-5.6 与 Grok 系列在超过阈值后按更高档位计费。长会话越线时客户端不会有任何提示。

具体时段与阈值见价目页脚注，每次响应的用量记录会显示实际适用的档位。把批处理挪出高峰窗口，只是改一行定时表达式。

5. 少发上下文

上下文是每一轮都要计费的，不是只算一次。 两个习惯影响最大：

  • 裁剪历史。 第 40 轮还把整段对话发过去，等于第 1 轮的内容被付了 40 次钱。请做摘要，或滑动窗口。
  • 只发选区，不发整个文件。 在编程工具里这是最大的一根杠杆 —— Cursor 和 Cline 你不管的话都会把整个当前文件发出去。

6. 用流式，好及时叫停

stream: true 不会改变一次完整响应的价格，但它让你能在发现跑偏时于几百 token 处中止，而不是为全文买单。它同时也让应用体感更快，所以无论如何都值得开。

7. 先测量，再优化

给每个应用、每个工具、每个环境发一把独立密钥。 GET /v1/usage 的 by_api_key 就能在你零埋点的情况下归集成本，by_model 则告诉你到底是哪个模型花的钱。

$curl https://api.beatapi.io/v1/usage \
>  -H "Authorization: Bearer $BEATAPI_API_KEY"

靠猜哪个集成费钱，基本都会猜错。 一个疯狂发小请求的浏览器翻译插件，和一个偶尔发巨型请求的智能体，在账单上完全不是一回事。

8. 对账退款

失败的任务会退款。如果你的账本只记预扣、从不读退款，内部数字会高估花费，你就会照着一个不真实的数去优化。GET /v1/usage 把 credits_settled 与 credits_refunded 分开列出正是为此。

哪些做法没用

  • 猛重试。 重试一个 400 只是把同样错误的请求按同样的价格再发一遍。只重试 429 与 5xx —— 见开发指南。
  • 加快轮询。 轮询请求消耗的是频率额度而不是余额，猛打任务接口换来的是 429，不是更快的结果。
  • 在需要跑两遍的步骤上降档。 一个便宜模型如果要重跑一次、或者要靠贵模型来纠正，总成本反而更高。请测量整条管线，而不是单价。