本文是「术语解构」系列之一。上一篇《Token 到底是什么》我们搞清楚了大模型的计量单位，这一篇来拆它最常被吹的参数：上下文窗口。
厂商发布会说：支持 100 万 token 上下文。
学术测试说：32K 的时候，12 个主流模型里有 11 个能力已经腰斩。
窗口只用了 3%，模型就开始变笨——这中间发生了什么？
这篇把近两年最关键的几组公开测试数据摆在一起，讲清楚标称窗口和有效窗口之间隔着什么。
一、1M token 到底有多大
先建立体感。按 Qwen 系列 tokenizer 处理中文的大致压缩率（1 个 token 约对应 1～1.5 个汉字）估算：1M token 大约能装下 100 万～150 万字中文。《三体》三部曲全文约 88 万字——也就是说，一整套《三体》塞进去，窗口还有富余。
听起来很美好。但有三笔账，发布会不会告诉你。
第一笔：输入和输出是不对称的。
窗口 1M 指的是模型一次能“读”多少。它一次能“写”多少？主流模型的输出上限普遍只有 8K～65K token。你可以把三本书塞进去，但它没法给你写出一本书来。上下文窗口是个漏斗，进去的多，出来的少。
第二笔：厂商用定价告诉你，长上下文有多贵。
看两个 2026 年的真实定价规则：
- Gemini 3 Pro：上下文超过 200K，按阶梯涨价
- GPT-5.5：输入超过 272K token，价格直接翻倍
如果长上下文是白捡的能力，厂商为什么要在这个位置设收费闸门？因为注意力机制的计算成本随序列长度平方增长——窗口翻倍，注意力层的计算量大约翻四倍。这笔账最终会转嫁到你的账单上。
第三笔：显存账。
这个系列的老读者应该有条件反射了：任何“能力”最终都要落到显存上。一个 32B 模型，在 1M 上下文满载时，仅 KV Cache（模型推理时的“草稿纸”，后面会单独写一篇）就需要 64GB 以上显存（FP16）。什么概念？一台 24GB 的 MacBook Pro，连这张“草稿纸”的一半都装不下，模型本体还没算。这也是为什么你在本地部署时，把上下文长度往大了调，内存占用会肉眼可见地飙升。
所以 1M 窗口的真实含义是：技术上能读这么多，但读得越多，越贵、越慢、越吃硬件。
而且，还越笨。
二、大海捞针：怎么测一个模型“读没读进去”
“大海捞针”（Needle in a Haystack，NIAH）是测试长上下文最经典的方法，原理简单粗暴：
- 找一大堆无关文本当“干草堆”（haystack）
- 在某个位置插入一句捏造的、无法靠常识推断的事实，这就是“针”（needle）——比如“某某咖啡馆的会员密码是 7382”
- 把整堆文本喂给模型，问它针的内容
- 改变两个变量反复测：干草堆的总长度、针埋的深度（开头 / 中间 / 结尾）
测试结果通常画成一张热力图：横轴是上下文长度，纵轴是针的深度，绿色代表捞到了，红色代表没捞到。如果模型真的“均匀地”利用了整个窗口，这张图应该通体全绿。
实际情况是——几乎没有模型能做到全绿。而且红色出现的位置非常有规律：长度越长越红，中间深度比两头更红。
三、公开数据：从“捞不到针”到“能力腰斩”
把近两年几组关键测试按严重程度排一下。
第一组：NoLiMa 基准——32K 就腰斩。
NoLiMa 是一个刻意提高难度的长上下文测试：它的“针”和问题之间没有字面上的关键词重叠，模型不能靠词汇匹配作弊，必须真正理解语义。结果：在 32K token 长度下，12 个被测主流模型中有 11 个的表现跌到其短上下文性能的 50% 以下。
注意这个数字的含义：32K 只是那些标称 1M 窗口的 3%。窗口还剩 97% 没用，能力已经腰斩。
第二组：RULER 基准——标称值普遍虚。
RULER 比经典捞针更全面，覆盖检索、聚合、追踪等多种任务。它给出的结论是：在声称支持 32K 以上上下文的模型中，只有一半能在该长度下维持令人满意的表现。
标称窗口和有效窗口，是两个东西。这就像显示器标称 100% sRGB 和实测 100% sRGB 的区别——只不过大模型这边，虚标是行业默认操作。
第三组：Chroma《Context Rot》报告——无一幸免。
2025 年，向量数据库公司 Chroma 发布了目前最系统的一份研究，标题起得很形象：Context Rot，上下文腐烂。他们评测了 18 个主流模型——GPT-4.1、Claude 4、Gemini 2.5、Qwen3 全在列。结论只有一句话：没有一个模型能均匀地利用上下文，全部随输入变长而性能下降——连“原样复述一段文本”这种最简单的任务都会退化。
更要命的是，这份报告测的还只是简单任务。报告原文的判断是：真实场景需要综合信息、多步推理，性能退化只会更严重。
第四组：复杂任务上的极端案例——从 29% 到 3%。
上面的判断有数据支撑：LongCodeBench 基准（真实代码任务）里，Claude 3.5 Sonnet 随上下文增长，性能从 29% 一路跌到 3%。不是打折，是归零。
四组数据放在一起，规律很清楚：任务越接近真实使用（从捞针→语义理解→综合推理→写代码），长上下文的退化越狠。
四、为什么越长越笨：三个机制
现象摆完了，说原因。模型变笨不是玄学，主要是三个机制叠加。
机制一：U 形注意力，中间是盲区。
斯坦福 2023 年那篇著名的《Lost in the Middle》发现：同样的事实，放在输入的第 1 位，回答准确率约 75%；放到第 10 位（约 4000 token 的检索场景），掉到 55%。整体呈 U 形曲线——开头和结尾记得牢，中间位置的准确率能低 30% 以上。
这和人看文档的习惯出奇地像：认真读开头，翻到结尾看结论，中间靠扫。区别是人知道自己扫过去了，模型不知道——它会基于没读进去的内容，自信地作答。
机制二：计算量平方增长，注意力被稀释。
Transformer 的自注意力机制里，每个 token 都要和其他所有 token 计算关联度。序列长度翻倍，这部分计算量翻四倍。当 100 万个 token 互相争夺注意力时，每个 token 分到的“关注度”被摊薄——你的那根针，只是百万分之一。
机制三：干扰项越多，错得越自信。
Chroma 报告里最有实用价值的一个发现：当干草堆里存在和针语义相似但不相同的干扰内容时，性能退化明显加速；针和问题的语义相似度越低，长上下文下掉得越快。
这直接解释了一个常见的真实翻车场景：你把 10 份格式相近的合同/日志/代码文件一起丢给模型，问其中一份的细节——满屏都是“长得像针的草”，这正是模型最容易出错、而且错得最自信的配置。它往往不会说“找不到”，而是从某个相似段落里一本正经地编一个答案给你。
五、说句公道话：新模型的“捞针”已经不差了
为了不变成一边倒的批判，补充一组反方向的数据。
Llama 4 Scout 标称 10M token 窗口（目前开源模型的天花板），在 8M token 以内能保持 95% 以上的检索准确率，到 10M 极限才降到 89%。单针检索这个动作本身，新一代模型确实练出来了——毕竟大海捞针测试已经公开了两年多，厂商完全可以针对性优化（这也是 NIAH 这个测试的局限：它只测“词汇级检索”这一个狭窄能力，模型可以应试）。
所以更准确的说法是：
- 捞一根针：新模型基本能做到，发布会演示的就是这个
- 在长上下文里做理解、综合、多步推理：所有模型都在退化，退化幅度远大于捞针测试显示的（回看第三节那个从 NoLiMa 到 LongCodeBench 的梯度）
这个差距，就是发布会数字和你实际使用体验之间的落差来源。
六、实用结论：窗口是资格题，不是打分项
最后落到怎么用。三条建议：
1. 把窗口当“资格题”看。 你的任务如果真需要一次塞进一整个代码仓库、一本书，那 1M 窗口是硬性门槛，不满足直接淘汰。但如果你的输入本来就几千 token，纠结谁家窗口更大毫无意义——该花力气的是喂进去的内容质量，不是窗口数字。
2. 精心准备的短上下文，胜过偷懒的长上下文。 与其把 50 万 token 一股脑塞进去指望模型自己找重点，不如先筛选、先摘要，只喂相关的部分。省钱、省时间，而且——根据本文所有数据——更准。尤其注意第四节机制三：格式相近的多份材料混在一起，是最容易诱发自信幻觉的用法，能拆开问就拆开问。
3. 重要信息放两头，别放中间。 如果必须用长上下文，把关键指令和关键材料放在输入的开头或结尾。U 形曲线是客观规律，顺着它用。
一句话总结这篇：上下文窗口的标称值是“能装多少”，不是“能懂多少”。装得下和读得懂之间，隔着一条 U 形曲线。
下一篇预告：这篇里 KV Cache 出场了一次，就吃掉了 64GB 显存。这张随上下文线性膨胀的“草稿纸”到底是什么？为什么它才是长上下文真正的硬件瓶颈？下期拆它。
如果这篇的数据梳理对你有用：
- 点个在看，让更多被“1M 窗口”广告词困惑的人看到
- 星标本号，「术语解构」系列每篇都用数据说话，不做通稿复读
- 你在实际使用中遇到过模型“读了后面忘了前面”的翻车现场吗？评论区聊聊，典型案例我会在下篇里分析
（本文为原创内容。文中数据来源：Chroma《Context Rot》技术报告、NoLiMa 与 RULER 长上下文基准、斯坦福《Lost in the Middle》论文、LongCodeBench 基准及各厂商官方定价页，均为公开可查资料。）