上下文长度怎么选？窗口越大越好是个误会

上下文窗口是能力上限，不是使用建议。把窗口塞满既贵又慢，模型在超长上下文里定位关键信息的稳定性通常还不如短上下文。合理的做法是把大窗口当安全余量，日常只用其中一小部分。

这篇讲窗口怎么选、超了怎么办。想边看边换算，开上下文长度计算器，它能把 token 数换成中文字符和英文单词量，顺带算单次调用成本。

先把「多长」变成有体感的量

128K、256K、1M 这些数字对多数人是没有直觉的。换算一下就清楚：几万 token 大约是一本小册子，十几万 token 能装下一部长篇的主要章节。

换算规则粗糙但够用：中文大致一个字一个 token 上下，英文平均三到四个字符一个 token，代码因为符号密集介于两者之间。各家分词器不同，需要更贴近的数字就把文本粘进 token 计算器。

有了体感之后，很多选型问题会自己消解。比如「我要处理一份三十页的合同，需要多大窗口」——换算完发现远没有想象中大，真正该纠结的其实是要不要整份塞进去。

大窗口的两个代价

代价一是钱。 上下文里每个 token 都按输入价计费，而且不少厂商按上下文长度分档，超过阈值单价直接跳一档。把三十页文档整份塞进去问一句话，成本可能是检索出三段再问的十几倍。这还没算多轮——如果每轮都带着这三十页，成本是线性叠加的。

代价二是效果。 超长上下文里，关键信息被埋在中间位置时，模型的召回准确率通常不如短上下文稳定。这不是某一家的问题，是长上下文的共性挑战。与其赌模型能从十万 token 里精准捞出那一句，不如自己先把范围缩到几千 token——你对自己的数据比模型更懂。

还有第三个隐性代价：延迟。输入越长，首 token 返回越慢。做交互式产品时，这直接影响体感。

那窗口大有什么用

有用，但用法是「余量」而不是「目标」。

一是避免硬失败。偶尔遇到超长输入时不至于直接报错中断，有窗口顶着能降级处理。

二是简化工程。窗口宽裕时，历史裁剪的策略可以做得粗一点，不用把精力花在压缩上。

三是特定场景确实需要。整本代码库分析、超长会议记录、需要全局视野的任务，检索会切断上下文关联，这时长窗口是刚需。

判断标准很简单：你的任务是否需要跨越全文的关联？ 需要就用长窗口，不需要就检索。

超出上下文限制会怎样

两种表现，都不好。

多数 API 会直接报错拒绝请求，功能中断，用户看到的是一个失败提示。

少数客户端会自动截断最早的历史，请求成功了，但模型「忘了」前面说过什么却不告诉你。这个更危险，因为它是静默的：用户以为模型记得，模型其实已经丢了上下文，输出开始前后矛盾。

所以稳妥做法是在发请求前自己估长度，超了就主动处理，而不是等 API 报错或客户端偷偷截断。

三种处理办法，按这个顺序上

第一，裁剪历史。 只保留最近几轮完整对话，更早的部分压成一段摘要。摘要可以用便宜的小模型生成，成本几乎可以忽略。这是最简单也最有效的一步。

第二，换成检索。 把长文档切片建索引，每次只把相关的几片送进上下文。这一步顺带解决了「文档超过窗口上限根本塞不下」的硬约束，而且往往还提升了准确率——因为噪声少了。

第三，用提示缓存复用固定前缀。 如果每次请求前半截都一样，缓存命中后这部分按很低的折扣价计费。长 system prompt 的项目收益最明显。注意缓存优化的是钱和延迟，不解决窗口装不下的问题，所以它排在前两步之后。

三种手段可以叠加：先裁剪、再检索、最后缓存。

四类任务的窗口选择建议

客服 / 问答类。 单次问题短、知识来自检索。窗口够放下 system prompt 加几段检索片段加几轮历史即可，通常几千到一两万 token 就绰绰有余。这类场景把钱花在长窗口上基本是浪费，把同样的预算花在提升检索质量上收益大得多。

文档处理类（摘要、抽取、审阅）。 取决于单份文档大小。如果文档普遍能装进中等窗口，直接整份处理最省事；如果经常超出，与其换更大窗口的模型，不如做分段处理再汇总——分段之后每段都落在更便宜的计费档，总成本往往更低，而且每段的处理质量更稳定。

代码类（阅读、重构、补全）。 代码的 token 密度高，且经常需要跨文件关联，是真正吃窗口的场景。但也别一次性把整个仓库塞进去——更实际的做法是把相关文件加上依赖关系图塞进去，让模型知道有什么、需要时再要。

长会话陪伴类。 窗口大小决定了「能记多久」，但硬撑长窗口的成本会随会话长度线性上升。更可持续的做法是分层记忆：最近几轮保留原文，更早的压成摘要，关键事实单独存成结构化记忆随请求带上。

窗口还会影响延迟

成本之外，长输入会拖慢首 token 返回时间。交互式产品里，这个体感比省几分钱重要得多。

如果你的产品是同步等待型（用户点了按钮盯着屏幕等），建议把首 token 延迟当成硬指标，反过来约束上下文长度：先定「用户最多等几秒」，再倒推「上下文最多能塞多少」。异步型任务（后台批处理）就没这个约束，可以放开塞。

一个容易被忽略的点：长上下文的延迟不只影响体验，还会放大重试成本。请求越慢越容易超时，超时重试是全额重跑。所以控制长度既省钱又降低失败率，两头都赚。

选型时怎么看窗口这一栏

在价格对比表里，上下文是一列参数，但它不该是排序依据。建议这样看：

• 先按硬约束筛：你的最长输入是多少，窗口不够的直接出局。
• 再看分档规则：这个模型在你的常用长度区间是哪一档价，而不是它宣传的最低价。
• 最后看长上下文的实际表现：拿你自己的长文档跑几条测试，看它能不能稳定找到中间位置的信息。

参数表能筛掉不合格的，选不出最合适的。剩下的候选并排放进模型横向对比看，再拿真实任务盲评。

想把成本这一侧算清楚，接着看大模型 API 月成本怎么算。