上下文窗口是模型一次能"看到"的 token 总量上限：提示词、对话历史、检索到的资料，加上模型已写出的回复，全部按顺序排进这段序列。它决定模型的工作台有多大，但不决定它有多聪明——1M token 的窗口装得下上千页文档，却不等于模型真能用好每一页。
上下文窗口里到底装了什么
窗口里装的不是文件，而是 token。提示词、对话历史、检索片段、工具返回的结果，全被切成 token 塞进同一段序列；模型靠位置编码分辨先后，没有"文件夹"的概念。1M token 约等于几十万字中文、上千页文档——但这只是"放得下"，还不是"记得住"。
注意力机制的隐藏账单
模型读懂这段序列靠自注意力机制：每生成一个新 token，都要和之前所有 token 逐一计算相关性，计算量随序列长度呈平方级增长——长度翻一倍，注意力计算就翻四倍。另一笔更大的账是 KV 缓存：推理时每个 token 的键向量和值向量都要常驻显存，避免重复计算。以 Llama-3.1-8B 为例，每个 token 约占用 128KB 缓存：128K 上下文需要约 16GB 显存，1M token 则需要约 128GB。所以"窗口翻倍"从来不是免费的：它吞掉显存、拖慢首字响应，还推高长上下文调用的计费。
装得下，为什么找不到了
账付得起，不等于用得好。注意力权重经 softmax 归一化，总和恒为 1：token 越多，每个 token 分到的注意力就越薄。斯坦福 2023 年"Lost in the Middle"实验表明：关键信息放在开头或结尾，模型找得又快又准；藏在正中间，准确率能掉 20 个百分点以上，甚至不如不给上下文。更大的落差藏在评测方式里："大海捞针"只考"找不找得到一句话"，几乎所有模型都能满分；但 NVIDIA 的 RULER 换成多跳追踪、聚合统计等真实任务后，宣称支持 32K 的模型里只有一半能在 32K 下保持合格——标称窗口和有效窗口，常常差着好几倍。
三个流传很广的误解
误解一：窗口越大，模型记得越多。 窗口是工作台，不是硬盘。窗口变大不会增加模型参数里的"长期知识"，只是让模型一次能摊开更多资料。对话结束、窗口清空，模型什么都不"记得"；跨对话的长期记忆，靠的是检索增强生成这类外部记忆机制。
误解二：长上下文让 RAG 过时了。 把整个知识库倒进窗口又贵又慢：输入 token 按量计费，超长上下文的首字延迟和显存占用都是真成本。工程主流做法恰恰相反——先用语义检索筛出最相关的几段，再放进窗口精读；需要跨多篇文档拼凑答案时，还有 GraphRAG 这类结构化检索方案。长窗口和检索是搭档，不是对手。
误解三：token 数等于有效记忆。 标称 1M token 的模型，在需要真正推理的任务上，有效长度可能只有标称值的几分之一——"装得下"和"用得好"是两回事。下次看到模型卡上的数字，多问一句：在我的任务长度下，它的准确率还剩多少。
窗口数字，到底该看什么
先看任务：读几份合同、分析一个代码仓库，几十 K 到 128K 通常够用；做全库问答时，瓶颈往往在检索质量而非窗口上限。再看有效性：查 RULER、LongBench 这类长上下文评测，看模型在目标长度下的真实表现，而不只看标称最大值。最后看成本：长上下文输入的 token 单价更高，KV 缓存还限制并发——窗口不是越大越好，而是在够用的长度里，表现最稳、成本最低的那个。
