长上下文任务成本为什么突然翻倍？三个叠加原因讲透

很多人第一次跑长文档任务都遇到过：明明参数没改、模型没换，账单一出来就是上次的好几倍。这时候容易先怀疑站点涨价或偷偷调了倍率，其实多半是上下文在一轮轮累积、整段重发、多轮叠加三件事同时发生。这篇按这个顺序讲清钱花在哪，并给出一套从日志和用量记录自查的动作。价格与倍率请以站内当时数字为准。

很多人第一次跑长文档任务都遇到过：参数没改、模型没换，账单一出来就是上次的好几倍。这时候第一反应往往是站点涨价了，或者偷偷调了倍率。其实先去站内价格变动追踪核对当时的报价，如果单价没动，那多半是上下文在一轮轮累积、整段重发、多轮叠加三件事同时发生了。

这篇不讲概念，只讲钱花在哪、怎么从自己的日志和用量记录里查出来。顺序很重要：先分清是单价变了还是量变了，再按累积、重发、叠加三条线逐个排除。价格与倍率一律到站内核对当时的数字，别用记忆里的印象做判断。

先分清：是单价变了，还是量变了

成本就是单价乘用量，账单跳变先拆这两项。单价去站内价格变动追踪和当期报价单核对当时的数字；用量看你自己的调用记录。大部分人跳过这一步直接下结论，结果方向从一开始就错了。

• 把本次任务和上次任务各自的输入、输出 token 分别拉出来对比，不要只对比总金额
• 确认模型、分组、计费模式有没有变，这三项任一变都会动单价
• 不适用的情况：如果确实换了模型或从按次转按量，先排除这一层再谈其他原因
• 量变和价变同时发生时，先锁定价变，否则后面所有推算都是错的

原因一：上下文是累积的，不是每轮只算新内容

多轮对话里每一轮请求都要把之前的对话历史重新带上。第 N 轮的输入大致是前 N-1 轮的总和，所以轮数越多，单轮成本涨得越快，整条成本曲线更像加速上升，而不是平缓上升。这是长文档任务最容易被忽略的一块。

典型场景：把一份长文档贴进去，然后连续追问若干轮。最后一轮的开销可能是第一轮的好几倍，而用户的主观感受只是「多问了几句」。判断标准很简单：轮数偏多、且每轮都带着同一份大材料，累积效应一定在起作用。

1. 数轮数统计这个任务一共几轮对话，把轮数和单轮输入 token 并排列出来，看增长斜率
2. 看首尾差对比第一轮和最后一轮的输入 token，差多少倍就是累积贡献了多少
3. 做减法验证把同一问题在新会话里只问一轮，和带历史的版本比输入 token，差值就是累积的量

原因二：整段重发，长前缀每次都重算一遍

上下文里不变的那部分——系统提示、文档正文、示例——每一轮都会被重新送进模型，除非命中缓存机制。同一份材料被重发多次，等于为它反复付费。这是长文档任务最常见的浪费点，也是三条原因里最容易优化的一条。

前缀缓存

把开头不变的部分缓存起来，后续请求直接复用，前提是前缀逐字一致

缓存失效

前缀里插了内容、改了标点、换了顺序，缓存就命中不了

有效窗口

缓存有存活时间，请求间隔太长会失效，需要重新计算

缓存能不能命中，取决于前缀是否逐字一致、有没有内容插在前面、请求间隔是否在有效期内。要先确认自己的请求到底有没有走缓存口径，做法参考站内缓存成本相关文章，不要凭空假设省下了。前缀频繁变化的任务，缓存收益几乎为零。

原因三：单个任务变成多条支线，重复付费

常见形态是一份文档既要摘要、又要抽表格、又要生成问答，每条支线各自带一遍原文。Agent 或工具调用场景更明显：每一步都要把已有上下文再带上一次，步数越多叠加越重。三条原因叠在一起时，成本就不是加法，而是接近乘法的增长。

• 先数这次任务一共发了几次请求、每次平均输入多大，用这个粗算和账单对一遍
• 把支线任务合并成一次请求能带多个输出时，优先合并，减少原文重复
• 不适用的情况：任务本身就是多文档汇总，叠加属于必要成本，重点应转到怎么减少重复部分
• 工具调用型任务重点看步数，步数每多一步，前面所有上下文都要再带一次

按这个顺序排查，别一上来就问客服

顺序颠倒会浪费一轮沟通，也会把正常成本当成异常。下面这套顺序是先量化、再定位、最后才怀疑平台。走完前四步仍然对不上的，才值得带着数据去问。

1. 量化拉出本次任务的请求条数和单条平均输入 token，先有个数
2. 查缓存确认有没有走缓存、前缀有没有变动、请求间隔是否超窗口
3. 拆任务把同样的长文档任务按不同做法拆开比对，选成本更低的路径
4. 看平台以上都对不上，再去站内报价页和价格变动追踪核对有没有调整、分组有没有变

账单翻倍先别怀疑涨价，先把输入侧 token 的账算一遍。