大模型上下文窗口（Context Window）怎么选？128K与1M超长文本处理实测

处理一份几十页的合同、一整本手册、几百页的会议记录，第一反应往往是「找个窗口最大的模型」。但窗口大不等于好用：钱花得更多、速度可能更慢、模型对中间段落的注意力也会打折。这篇不报具体数字，只给你一套判断顺序——先量文档、再看模型库当时的规格、最后按任务切分，让每一次长文本调用都花在刀刃上。

手头一份几十页的合同、一整本产品手册、几百页的会议转写稿，很多人的第一反应是「找个窗口最大的模型丢进去」。真上手会发现：钱花得更多，首字等得更久，模型还经常只记住开头和结尾，中间那段最关键的话偏偏漏了。窗口大不等于好用，它买的是容量，不是准确率。

这篇不报具体数字——模型规格和价格变化太快，写死就是误导。给你一套判断顺序：先量文档，再看模型库当时的窗口规格，最后按任务决定是整篇塞还是切分。每一步该去哪儿核对当时的真实数据，我都会给出站内路径。

上下文窗口到底是什么，别再和「记忆」混为一谈

上下文窗口指的是单次请求能塞进去的 token 总量上限，输入和输出都算在里面。它不是模型的长期记忆，下一次请求不会自动带上上一次的内容。这一点搞清楚，后面很多选型纠结会自动消失：你付的是「这一次能看多少字」的钱，不是「模型记住了多少」的钱。

• 窗口是单次容量，不是会话长度上限，会话能开多长是另一回事；
• 超长输入超出窗口时，表现可能是报错，也可能是静默截断，还可能只抓住头尾、丢掉中间，具体哪种取决于调用方式；
• 对话轮次越多，历史累积越容易撑爆窗口，这属于会话管理的范畴，站内工程类文章已经讲透，这里只做区分；
• 训练上下文、最大输出长度、上下文窗口是三个不同的口径，容易混，到 /ai-dict/category/basics 逐个对照定义再上手

第一步永远是先量，不是先挑模型

绝大多数人跳过了量这一步，凭感觉觉得「这文档挺长的，得上超长窗口」。实际上很多所谓长文档，切掉附录和重复内容后，核心正文只有想象的一半。量一下再决定，比直接换模型省得多。

1. 粗算 token 量中文按字数量级估，英文按词量估，具体换算系数到 /tools/token-price-calculator 用当时的工具算一遍，别背公式。
2. 把三部分加总文档本身、你要问的问题、以及你希望它输出的格式要求，三块都占 token。很多人只算了文档，输出要求写了一大段结构化格式，最后一超限就报错。
3. 算清问答轮次同一份资料要反复回答十几个问题，单次全塞和分次处理的账完全不同。轮次多的时候，检索式方案的成本优势会迅速放大。
4. 先问自己一个问题如果只需要问一两个点，能不能先检索定位到那几段，再决定要不要动用整份文档？

把窗口分成几档看：够用档、舒适档、超长档

与其记住哪个模型窗口多大，不如按需求分档。分档的好处是：就算模型换代、规格变了，你的判断逻辑不用改，只需要到站内模型库核对当下的规格落在哪一档。模型窗口字段和当时的价格，去 /models 按窗口筛一遍即可。

判断自己落在哪一档，标准很简单：把「文档 + 问题 + 期望输出」的总量算出来，乘上一个安全系数（比如再留出多轮追问的空间），看它落在哪一档。别拿单个模型的最大窗口当目标，那是最坏情况的下限，不是日常该用的配置。

超长窗口的代价：贵、慢、还不一定准

超长窗口不是免费的升级项，它带来三笔账单：钱、时间、准确率。三笔都要算进去，只算钱会踩坑。

价格分档

长输入的单价通常和常规输入不同档，有的平台还设了「超过某个长度就整体升价」的规则，具体以 /official-api 当时页面为准

缓存收益

同一份长文档反复喂给模型时，有没有提示词缓存，成本差异可能非常明显，先看该平台是否支持、命中条件是什么

注意力稀释

窗口越大，模型对中间位置的注意力越容易打折，关键条款挪到开头或结尾，往往比换更大窗口更有效

首字延迟

长输入的首字等待明显更久，超时设置要跟着调，分档调整思路参考站内 /api-timeout-tuning 相关章节

「大海捞针」型任务最能暴露问题：答案确实在文档里，模型也说读到了，但就是答不对。这种情况先别急着加预算换模型，把关键段落的位置调整一下，很多时候立刻就好了。真正需要跨全文做整体推理的任务，才值得为超长窗口付溢价。

窗口买的是容量，不是理解力；把关键信息放对位置，比换一个更大的模型便宜得多。

什么时候别硬塞：三种切分策略的适用场景

切分不是「省钱版方案」，很多任务上切分的准确率反而更高。判断标准就一条：这个任务需不需要跨段落的整体推理。需要，才考虑整篇塞；不需要，切分几乎总是更划算。

• 检索式：文档进向量库，按问题取相关段落。适合问答型任务，成本和准确率通常都更优，缺点是依赖检索质量；
• 摘要压缩式：先分段摘要再逐层汇总。适合写综述、写报告，缺点是层层压缩会丢细节，不适合要求精确引用的场景；
• 分块处理式：按章节切开逐块调用，最后人工或模型合并。适合翻译、校对、格式转换这类规则明确的任务；
• 不适用的情况：任务需要把文档不同位置的信息交叉比对得出结论，切分后各块互相看不到，这种就别硬切

还有一种折中做法：检索粗筛出相关章节，再把这几个章节一次性塞进一个不算太大的窗口里做联合推理。既保留了跨段落视野，又没有把整本书都喂进去。多数文档分析任务，这个组合的性价比最高。

选型落地：怎么确认这个窗口真的够用

参数表上写的窗口规格，和模型在你的文档上实际能不能用，是两回事。上线前做一轮小样本测试，比看任何规格都靠谱。

1. 埋一个明确答案拿一份真实文档，问一个答案明确写在某处的问题，看它找不找得到。找不到，说明这个方案连基础召回都不过关。
2. 问一个跨章节问题再问一个需要汇总不同章节才能回答的问题。这一步是区分「能读进去」和「用得上」的关键：前者答得出，后者往往只答其中一段。
3. 跑多次看稳定性同一份输入跑两三次，观察结果是否一致。抖动大的任务，不要靠单次结果拍板，要么换方案，要么把输出约束得更死。
4. 批量前做对照正式批量上线前，用 /tools/verify 一类实测思路横向跑一轮，把参数表和实测结果摆在一起看，别只信宣传页上的窗口数字。

按场景对号入座：一张选型对照表

下面这张表把常见长文档任务和推荐策略对应起来，可以直接当上手清单用。每个模型当时的价格和窗口规格，一律到 /models 和 /official-api 核对，别记死数字。

这张表不是绝对的。同一类任务，文档质量和结构差异会大幅改变结论：结构清晰、有小标题的文档，切分后效果通常好很多；格式混乱、逻辑跳跃的文档，切分反而更糟。所以最终判断还是要回到那份小样本测试上。

最后一句提醒：模型规格、价格、窗口大小都在变，这篇文章给的是判断顺序，不是具体答案。每次真正选型前，花几分钟到站内页面核对当时的数字，再走一遍量文档、分档、测小样本的流程，比记住任何结论都管用。