报错 context_length_exceeded / 上下文超限?四种真正有效的处理方式(2026)
上下文超限不是「换个更大窗口的模型」就完了。先搞清楚是输入超了还是输入+输出一起超了,再决定该裁剪、该切分、还是该换模型——顺序反了会白花钱。
先算清楚,别估
绝大多数人报这个错时,并不知道自己实际发了多少 token。粗略的换算(英文一个词约 1.3 token、中文一个字约 1.5-2 token)只够用来判断量级,真要定位就看接口返回里的 `usage.prompt_tokens`,或者本地跑一次 tokenizer。**没有这个数字,后面每一步都是猜。**
记住是「输入 + 输出」一起算
这是最常见的误解。上下文窗口容纳的是输入加上模型将要生成的输出,所以 `max_tokens` 设得过大会直接吃掉可用空间。一个输入并不长的请求,配上一个夸张的 `max_tokens`,照样会超限。遇到这个错先看一眼 `max_tokens` —— 有时候把它从 4096 调到 1024 就解决了,而且顺带省钱。
对话类:历史不能无限往上堆
多轮对话默认把全部历史带上,第五十轮的单次成本是第一轮的几十倍,而且迟早撞窗口上限。两种处理:**滑动窗口**(只保留最近 N 轮)最简单;**摘要压缩**(把早期历史压成一段摘要)保留更多信息但要多一次调用。选哪个取决于早期上下文对当前回答有多重要——大多数客服类场景用滑动窗口就够。
长文档:切分几乎总是比换模型划算
把十万字的文档整篇塞进去,即使模型吃得下,你也在为大量用不到的内容付钱。更好的做法是切成段各自处理再汇总,或者先检索出相关片段只发那几段。**多次小调用的总成本通常低于一次巨大调用**,而且哪一段出错只需重跑那一段。
什么时候才真该换长窗口模型
前三条都做完了仍然不够,才轮到换模型——比如需要模型同时看到整个代码库做全局判断,任何切分都会丢掉必要的关联。这种情况确实存在,但比大多数人以为的少。先换模型的问题在于:它把成本抬上去了,却没改变「上下文会持续增长」这个事实,过一阵照样撞墙。
怎么快速试不同模型的窗口
如果你需要横向比较几个模型在同一份输入下的表现和成本,走 OpenAI 兼容接口最省事:模型名换一个字符串就能切,不用改 SDK、不用重新申请 key。各模型的上下文上限和单价可以逐个对照,详见 cocodot.co/pricing#models。
四种解法的代价对比
| 做法 | 成本变化 | 什么时候用 |
|---|---|---|
| 裁剪历史 / 精简提示 | **降低** | 任何时候,先做这个 |
| 切分 + 汇总 | 略增(多次调用) | 长文档、批处理 |
| 调小 max_tokens | 降低 | 输出用不了那么长时 |
| 换长窗口模型 | **显著上升** | 前三条都做完仍然不够 |