成本

两种账单，两种形状 主机账单是容量。你加 CPU、带宽、存储，表针跟着流量曲线走；看过一个月，下个月能猜到几个百分点以内的误差。 token 账单是行为。两个流量完全一样的团队，账单可以差 20 倍——因为一个团队每次请求带 12,000 token 的检索上下文，另一个只缓存了 400 token 的系统提示、其余什么都不带。同样的用户、同样的功能，账单天差地别。 这不是定价的猫腻，而是计量方式决定的：你按 token 付费，而 token 数量是设计决策。 让花费变跳的三个效应 1. 输入通常远多于输出，两者单价还不一样。 在多数对话与检索功能里，输入 token 是输出的 5～20 倍，而输出 token 的单价往往是输入的几倍。所以「我们只生成一小段回答」这句话，对成本没有任何说明力。 2. 缓存输入是另一套费率。 供应商对重复出现的输入给更便宜的价格——固定的系统提示、不变的长文档、大段指令。忽略缓存，就等于每次请求都为同样的 3,000 token 付全价。 3. 每次请求的上下文能差一个数量级。 一个每轮都追加对话历史的总结任务，等于每次都把整份记录重新发一遍。成本增长比轮数更快：第 20 轮很贵，是因为第 1 到 19 轮又在账单上出现了一次。 重试和工具调用还会再加一个在任何用量图表里都看不见的乘数：一次失败后重试的调用会计费两次；每轮调四个工具的 Agent，每轮计费五次。 杠杆，按收益排序 团队的第一反应通常是去换模型。那很少是最大的杠杆。建议按这个顺序试： 先砍上下文。 删掉检索到却不影响答案的文档、限制回溯的历史长度、把永不变的部分放进缓存。这往往是单项收益最大的一步。 限制输出长度。 直接要求形状（「三条要点，不要前言」），而不是给一个宽松的 token 上限。模型生成的那 900 token 客套话，是你在付费。 不紧急的走批次。 夜间补数、回填、评测这类任务通常可以接受更慢但更便宜的路径。 最后才换模型。 把摘要任务降级到更小的模型确实是省钱——但这是在前面三步已经压小的那个数字上，再省一次。 上线前先估一遍 你需要每次请求的两个数字：输入 token 与输出 token。功能已经上线，就直接从 API 返回里读，不要估。还没上线，只能先猜： 每月成本 ≈ 每天请求数 × 30 × (输入 ÷ 1M × 输入单价 + 输出 ÷ 1M × 输出单价) 猜的时候有两个坑：一是平均数会掩盖最贵的那次请求（一份长文档的 p95 请求可能是中位数的 30 倍，而账单正是它决定的）；二是多轮功能让平均数失去意义，因为每一轮都拖着完整历史。 ...