接入大模型时，第一个卡住团队的往往不是技术，而是"这东西一个月要花多少钱"。这个问题拆开看只有几个变量，本文把它们串成一条可计算的链条：计费单位 → 单次成本 → 月度预算 → 用实测校准。

一、计费单位是 Token，不是调用次数

大模型 API 按 Token 计费。一个 Token 大致对应英文的一个词根，中文里通常是一到两个字。每次请求的费用由两段组成：

• 输入 Token：你发过去的 system prompt、历史上下文、用户问题
• 输出 Token：模型返回的内容

两者单价不同，输出通常明显贵于输入。这就带来一个直接推论：同样一次"问答"，提示词越长、回答越长，成本越高。很多团队第一个月账单超预期，原因就是只估了调用次数，没估每次调用背后的 Token 体量。

想知道自己的真实 Token 数，不要靠猜。多数 SDK 的响应里都带 usage 字段：

resp = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": prompt}],
)
u = resp.usage
print(u.input_tokens, u.output_tokens)

先跑一批真实请求把 usage 记下来，后面所有估算都建立在这组数字上。

二、单次成本公式

单次成本 = 输入Token × 输入单价 + 输出Token × 输出单价

举个客服问答的例子：平均输入 800 Token、输出 400 Token，输入单价每百万 15 元、输出每百万 60 元。

800 × 15 / 1_000_000 + 400 × 60 / 1_000_000 ≈ 0.036 元

单看是三分钱，乘上调用量数字就起来了。

三、推到月度

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

接着上面的例子，日均 2 万次调用：

0.036 × 20000 × 30 ≈ 21,600 元/月

这个数字才是要交给财务的结果。估算时有三处容易被系统性低估：

1. 重试与失败调用照样烧 Token。超时重试、格式校验失败重新生成，都要算进去。给自己留 10%~20% 的重试余量。
2. 多轮对话的上下文会滚雪球。第 N 轮请求会把前 N-1 轮都带上，输入 Token 随轮次近似线性增长，长会话的实际输入远高于单轮均值。用滑动窗口或摘要压缩历史能明显压平这条曲线。
3. 模型选型直接决定量级。同一套业务逻辑，换个型号成本可能差一个数量级。

四、按任务分层，而不是一个模型走到底

成本优化最有效的一步不是砍提示词，是分流：高频的分类、抽取、路由这类轻任务交给小模型（如 claude-haiku-4-5），主力对话用 claude-sonnet-4-6，只有真正需要复杂推理的才动 claude-opus-4-8。

另一个杠杆是提示缓存。如果你的 system prompt 或知识片段在大量请求间是复用的，把这部分标记为可缓存，命中后这段输入的计费会显著低于原价。对"长固定前缀 + 短用户输入"的场景，这一项往往比换模型省得更多。

五、用小样本实测校准

纸上算出来的终归是估算。可靠做法是"小样本实测再等比放大"：先用小额度跑一批贴近真实分布的请求，从用量数据里读出实际平均 Token 和单次成本，再按业务规模放大。

按量计费的平台在这一步比较合手，比如 jiekou.vip 支持小额起充、用量看板能看到实时消耗，适合先跑一轮校准再决定预算规模。调用方式上它兼容 Anthropic 的接口格式，把 base_url 指过去即可：

from anthropic import Anthropic

client = Anthropic(
    base_url="https://api.highwayapi.ai/anthropic",
    api_key="YOUR_KEY",
)

跑完一轮把实测的 input/output 均值代回第二节的公式，估算精度会比拍脑袋高一个档次。

小结

成本估算的底层逻辑就一句话：按 Token 计费，不按次数。沿着"单次成本 → 日均量 → 月度预算"往下推，把重试余量和上下文增长算进去，再用小样本实测校准一次，就能给出一个财务愿意签字的数字。