为上下文窗口付两次钱
更新于 September 1, 2026 · 首次发布 September 1, 2026
上下文窗口被宣传为容量：200,000 个 token，一百万个 token，足够装下你需要的一切。但容量不是计费单位。你付的是你发送的部分，而在多轮对话里，每一轮你几乎都要把它再发送一遍。
这就是第二次付款。在二十轮对话开始时加载的一份 30,000 token 文档，并不是 30,000 个输入 token。它更接近 600,000，因为第二轮会重新发送它，第二十轮也会。
没人去算的那笔账
成本随对话长度的平方增长，而不是线性增长。假设上下文持续累积，轮数翻倍，输入 token 大约翻两番。那些用"每条消息成本"乘以消息数来估算的团队，会严重低估长会话，而误差恰恰会落在你最想留住的用户身上。
往往还有第三笔费用：许多供应商对超过长上下文阈值的请求收取溢价。一个额外的附件就可能让一次请求越过这条线，从而重新定价整个调用，包括输入和输出，而不只是越线的那部分 token。
应该测量什么
跟踪上下文利用率：发送的 token 与模型真正需要的 token 之比。它是这个领域最接近浪费指标的东西。按对话而不是按请求跟踪输入 token，并关注 p99 — 花费达到中位数二十倍的会话，正是在那里出现的。
对超过长上下文价格阈值的请求设置告警。它是阶跃变化，不是渐变，而且在每日总量里看不出任何异常。
三种修复，按成本从低到高
缓存稳定的前缀。如果系统提示和已加载的文档在对话期间不变，提示缓存可以把重复的成本降到其中一小部分。对任何多轮产品来说，这都是回报最高的改动。
有意识地裁剪历史。较早的轮次很少值得它们的重发价格。把长对话的前半部分总结成摘要，丢弃原始轮次；你保住了上下文脉络，也不再为它付全额运费。
发送片段，而不是整个语料。检索正是为此而存在的。窗口大到能装下整份文档，并不是把整份文档塞进去的理由。
相关阅读
相关文章
想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 →