2023 年,32K 令牌的上下文窗口被认为“够宽敞”。如今,100 万令牌(1M)级别的窗口已是顶级模型的默认前提。截至 2026 年 9 月,Anthropic、OpenAI 和 Google 三家都在旗下顶级模型的官方规格中标注了约 100 万令牌的输入上限。具体的模型名称和数字每次发布都会更替,因此我把它们交给当前模型与知识截止日期一览以及各厂商的官方页面,本文专注于跨越代际依然适用的内容:怎么读这些数字,以及怎么与它们打交道。

“100 万令牌”大致相当于英文 8 至 10 本平装书,或数万行源代码。我们现在可以在一次会话中“看到”如此庞大的内容。但文档装得进容器,并不等于模型把它读完了。从 OpenAI 公布的多针长上下文基准(MRCR)成绩来看,同一模型的输入越长,得分越低,而下降幅度因模型和代际差异很大(详见 §1 和 §4)。

先把我的看法摆在前面:仅凭容器大小选模型的时代已经结束。真正重要的是“有效上下文 × 成本 × 投喂方式”这三点。本文将依次介绍上下文究竟是什么、如何阅读规格表、为何“大”本身并不够、如何在自己的用途中测出有效范围、长输入为何会让价格上涨,以及个人开发者和小团队今天就能上手的五条节省策略——全部基于官方数字和公开基准的实测数据。

CONTEXT WINDOW · 2023→2026

三年间,容器扩大了 250 倍

— 1M 从“奢侈品”变成“前提”的时间线

2023
4K–200K
GPT-3.5 和早期 GPT-4 只有 4K–32K,一篇论文就能塞满。11 月,Claude 2.1 推出 200K。
2024
128K–2M
GPT-4 Turbo(128K)和 Claude 3(200K)成为主流。6 月,Gemini 1.5 Pro 向开发者开放 2M。
2025
1M 普及
4 月 GPT-4.1、8 月 Claude Sonnet 4(测试版)相继支持 1M。
2026
1M = 标配
Claude、GPT、Gemini 的顶级模型都进入 100 万令牌级别(截至 9 月)。

但“支持”与“读到最后”是两回事。在 OpenAI 的长上下文基准 MRCR(8 针)中,GPT-5.5 从 4K–8K 的 98.1% 降到 512K–1M 的 74.0%。
下降幅度因模型和代际而异(OpenAI《Introducing GPT-5.5》2026 年 4 月 23 日的评测表;详见 §1 和 §4)。

1. 1M 支持已成常态——但“读到最后”是另一回事

过去两年,1M 支持迅速普及。2025 年 4 月,OpenAI 的 GPT-4.1 以约 105 万令牌的窗口发布;同年 8 月,Anthropic 的 Claude Sonnet 4(测试版)达到 100 万令牌;截至 2026 年 9 月,Anthropic、OpenAI 和 Google 的顶级模型都在官方规格中标注约 100 万令牌。2023 年时,32K 就已让人觉得宽敞——短短三年增长了30 倍以上。容器尺寸之争看起来已经到了终点。

然而,看看各厂商自己公布的长上下文成绩,情况就没那么简单了。按长度给出完整结果的,是 OpenAI 的 MRCR v2(8 针)。它在与 AI 的长对话中混入8 条同类请求(例如“写一首关于貘的诗”),然后要求准确返回其中指定的一条,比如“返回第 2 首诗”。模型必须在几乎相同的内容中连顺序都分辨清楚,因此这是一种多针 needle-in-a-haystack 测试。得分衡量返回的文本与正确文本的吻合程度。按长度的结果如下:

  • GPT-5.5:4K–8K 为 98.1%,128K–256K 为 87.5%,512K–1M 为 74.0%
  • GPT-5.4(同一张表中的上一代):在同样三个区间依次为 97.3% → 79.3% → 36.6%
  • Claude Opus 4.7(OpenAI 在同一张表中列出的数值):128K–256K 为 59.2%,512K–1M 为 32.2%
  • GPT-6 Astra(2026 年 9 月发布):256K–512K 为 100.0%,512K–1M 为 96.3%(同一张表中的 GPT-5.6 Sol 为 91.5% 和 73.8%)

来源(2026 年 9 月 26 日核对):OpenAI《Introducing GPT-5.5》(2026 年 4 月 23 日)与《GPT-6 Astra》(2026 年 9 月 3 日)中的评测表。基准的机制见 OpenAI MRCR 数据集说明。模型名称为各次发布时的名称。

可以读出两点。第一,同一模型的输入越长,得分越低。第二,下降的陡峭程度因模型和代际差异很大——在最接近 1M 的区间,GPT-5.4 跌破了 40%,而 2026 年 9 月发布的 GPT-6 Astra 仍保持在 90% 以上。排名每一代都会洗牌,这些数字本身很快就会过时。长久留下来的是这条教训:标称上限和精度真正能保持的范围,是两个不同的数字。

别误会,这不是在说“Claude 或 GPT 不行”。真正需要用满 1M 的场景其实没那么多。只要能稳定读到 300K(约 2–3 本书),几乎所有编程、研究和总结任务都能完成。问题在于只看“支持 1M”这个数字来选型,就会把判断标准弄错。

2. 什么是上下文——把容器和内容分开理解

简单梳理一下术语。这个领域里,有三个词容易被混淆。

三个术语

令牌、窗口、上下文

① TOKEN — 文本单位
AI 处理文本的最小单位。英文每令牌约 4 个字符(约 0.75 个单词);中日韩等 CJK 语言每个字大约 1–1.5 个令牌。
② WINDOW — 容器尺寸
模型在一次交互中能处理的最大令牌数,是输入与输出(含推理过程)的总和。通过 API 调用时,仅输入就超出上限会直接报错;聊天应用和智能体通常会通过摘要或删除较早的部分来腾出空间。
③ CONTEXT — 容器内容
当前装入窗口的内容。包括系统提示、对话历史、附件、工具输出——全部在内。

简而言之:“窗口 = 容器尺寸”、“上下文 = 内容”、“令牌 = 单位”。
容器再大,内容杂乱,得到的回答也只会杂乱。

另外:不要把“上下文”和“记忆”混为一谈。上下文存在于会话内部——关闭聊天就消失。而 ChatGPT Memory 或 Claude Memory 这类功能则是另一种跨会话保留机制。记忆的内容最终也会被注入到上下文窗口中,但从用户的角度看,这是持久存储 vs. 临时工作区的区别。

常见误解:“上下文窗口越大 = AI 越聪明”是错的。窗口大小只是能装入视野的内容上限。推理能力、知识深度、指令遵循精度都是单独度量的。每次模型发布都把“1M 上下文!”作为标题,但那只是能力的一个侧面而已。

3. 容器尺寸要看三个数字

查看模型规格表时,与上下文相关的只需确认三项。掌握这三项,无论出现什么新模型,都能用同一套方法比较。

① 输入上限

规格表里最醒目的数字。但这是“装得下多少”,不是“读得进多少”——如下一章所述,实际有效量要小得多。

② 输出上限

常被忽视,但它比输入上限小一个数量级。即使是 2026 年 9 月的主流模型,也是能输入 100 万令牌,却只能返回约 6.5 万–12.8 万。在“把整份长文档改写一遍”这类用途中,先卡住的是它。

③ 计费模式

是全区间统一价,还是超过某个阈值单价就跳涨。这一项在实际运营中影响最大,规格表上却往往看不到。第 5 章会算给你看。

以下是截至 2026 年 9 月 29 日各厂商官方页面上的数值。数字会随代际变化,请把它当作上述三个维度如何转化为实际差异的示例来读。当前的具体模型名称请看当前模型与知识截止日期一览,数字请到各厂商的官方页面确认。

系列(2026 年 9 月的示例)输入上限输出上限长输入计费
Anthropic 高端(Claude Fable 5.1、Opus 5.5、Sonnet 5.5)1,000,000128,000直到上限都是同一单价
Anthropic 轻量(Claude Haiku 4.5)200,00064,000—
OpenAI(GPT-6 Astra、Sol)1,050,000128,000输入超过 272K 时,整个请求按输入 2 倍、输出 1.5 倍计费
Google(Gemini 3.1 Pro,预览版)1,048,57665,536超过 200K:输入 $2→$4,输出 $12→$18

出处(2026 年 9 月 29 日确认):Anthropic Models overview、Pricing/OpenAI GPT-6 Astra、GPT-6 Sol 模型页面/Google Gemini 3.1 Pro Preview、Gemini API pricing

从表中可以看到,各家的输入上限几乎持平,差异在于输出上限和计费方式。上限相同时,窗口大小就不再是选型理由。真正的不同在于:Anthropic 直到上限都保持同一单价,而 OpenAI 和 Google 超过一定长度就会涨价——同样挂着“支持 1M”,能多放心地投入长文本却不一样。这不仅是定价细节,更体现了“如何对待长上下文工作负载”的思路差异。具体将在成本一章中试算。

实际选型可以这样做。以日常处理的文档大小为准——如果在 200K 以内,就别看窗口大小,而是看该区间内精度是否稳定,以及能否停在计费阈值之内。只有经常处理超过 300K 的巨型文档时,有效范围的宽度和长输入的单价才会成为选型理由。不要只押一款,按用途分工使用才是现实的做法,而这种判断方式本身不会随代际改变。

上限去哪里确认

数字不要看汇总网站或文章里的表格(包括本文),而要到各厂商的官方页面确认。查看的位置基本固定:

  • Anthropic:模型概览页的对比表中有“Context window”“Max output”两行。长输入的计费见价格页的“Long context pricing”一节
  • OpenAI:API 文档中每个模型的页面都列有“context window”“max output tokens”,以及关于长提示词计费的说明
  • Google:Gemini API 的模型页面列有“Input token limit”“Output token limit”,价格页中有“prompts > 200k tokens”这一档

另一个容易忽略的点是:同样的上限,不同模型能装下的文字量并不相同。上限按令牌计算,分词器(把文字切分成令牌的机制)一变,同一份文档的令牌数也会变(见 §5 的补充)。换模型后,最好用自己的文档重新数一遍,确认相对上限还有余量。

4. “越大越好”不成立的三个理由

上一章的规格表只展示了容器的物理尺寸。那么,模型真的能用满它所宣称的容器吗?先说结论:不要以为它能以同样的精度一直读到上限。原因有三个。

理由①:Lost in the Middle(中间迷失)

这是斯坦福大学等机构的研究者(Liu 等人)在 2023 年的论文“Lost in the Middle”中报告的现象。在从多份文档中寻找答案等任务里,答案位于输入的开头或结尾时模型答得最好,位于中间时精度则明显下降——即使是主打长上下文的模型也呈现同样的趋势。

直观感受是:“把一整份长 PDF 贴进去,问‘某某的数字是多少?’,结果恰好把中间那部分的数字弄错。”这就是 Lost in the Middle。程度因模型而异,但更稳妥的做法是默认长文中间的信息容易被漏掉,并据此调整投喂方式。

理由②:Context Rot(上下文腐败)

对话越长,一开始给出的指示就越淡。开头明明要求“用正式语气回答”,20 轮之后却又变回了随意的口吻——这就是 Context Rot。

原因有两个。① 初始指示在对话历史中被相对视为较旧、较轻。② 历史变长导致注意力分散,更难参照特定的令牌。Anthropic 在开发者文档中,把令牌数增加时准确性和召回能力下降的现象称为 context rot,并指出“放什么进去”与“能放多少”同样重要。2025 年 9 月,它又在题为“Effective context engineering for AI agents”的技术文章中,把应对这一问题整理成一项需要有意识掌握的技能。

理由③:公称上下文 ≠ 有效上下文

只取 §1 数值中最接近 1M 的区间(512K–1M)排在一起,结果如下。全部来自 OpenAI 发布文章中的评测表,使用的是同一个基准 OpenAI MRCR v2(8 针)。

OpenAI MRCR v2(8 针)× 512K–1M

接近 1M 时,能否准确取出指定的那一条

GPT-6 Astra 2026 年 9 月 96.3%
GPT-5.5 2026 年 4 月 74.0%
GPT-5.6 Sol 2026 年 9 月 73.8%
GPT-5.4 2026 年 4 月 36.6%
Claude Opus 4.7 2026 年 4 月,OpenAI 的表 32.2%

来源:OpenAI《Introducing GPT-5.5》(2026 年 4 月 23 日;GPT-5.5、GPT-5.4、Claude Opus 4.7)与《GPT-6 Astra》(2026 年 9 月 3 日;GPT-6 Astra、GPT-5.6 Sol)中的评测表。模型名称为各次发布时的名称。
在同一张表的短区间(4K–8K),GPT-5.5 为 98.1%,GPT-5.4 为 97.3%。以上均为 OpenAI 在自家发布中给出的数值,并非第三方测量。

这并不是说“得分低的模型不行”。在同一张表的短区间,GPT-5.5 和 GPT-5.4 都超过 97%,而绝大多数实际工作(代码审查、长文写作、会议纪要总结、研究整合)远在 1M 之前就能完成。问题在于“既然有 1M,就全扔进去”的用法。另外要注意,这些是 OpenAI 在自家发布中给出的数值,只有在同一张表内才能比较。Google 也在 Gemini 3.1 Pro 模型卡(2026 年 2 月)中列出了 MRCR v2(8 针)的成绩——128K(平均)为 84.9%,1M 为 26.3%——但长度区间的划分方式不同,所以没有放进上面的柱状图。Anthropic 关于 Claude Opus 5.5 等现行模型的发布页面上,没有这类按长度划分的成绩。你现在所用模型的真实能力,最好按下面的方法,在自己的用途中确认。

在自己的用途中测出“有效范围”

基准测试的文档类型和提问方式都与你的用途不同。最可靠的办法是用自己的文档做一个小型 needle-in-a-haystack 测试。

  1. 准备实际要用的那类文档(代码、会议纪要、合同等),把 3–5 个答案明确的事实分散放在开头、中间和结尾(也可以直接用文档中原有的事实)
  2. 要求模型“全部列出,并说明各自出现在哪里”,让它同时取出多个事实。只问一个会让模型看起来比实际更强(单针与多针的差距)
  3. 用 50K、200K、500K 等不同长度重复同一问题,记录答案开始出错的长度
  4. 除了取出,还要加入“比较 A 和 B”这类需要组合事实的问题。越需要整合的问题,越容易更早崩溃

开始出错的长度稍前一点,就是该模型在该用途下的“有效上下文”。换模型后要重新测。这是几十分钟就能完成的确认,却比规格表上的数字更能指导实际决策。

5. 成本陷阱——长输入会涨价的模型与不涨价的模型

上一章说过“有效范围比上限更靠前”。在此之上还叠加着另一个陷阱:投入长文本会让计费上涨。在这一点上,各厂商的设计各不相同。

模型(截至 2026 年 9 月)标准单价(输入 / 输出,每 100 万令牌)长输入时
Claude Opus 5.5$4 / $201M 全域同一单价
GPT-6 Sol$2 / $10输入超过 272K 时,整个请求按输入 2 倍、输出 1.5 倍计费
GPT-6 Astra$10 / $50同上
Gemini 3.1 Pro(预览版)$2 / $12超过 200K:输入 $4、输出 $18

来具体算一笔账。假设投入一份 500K 令牌的文档,得到一次 50K 的回复——这是一次性总结大型代码库或年度报告的典型场景。

  • Claude Opus 5.5(统一单价):$4.00 × 0.5 + $20.00 × 0.05 = $3.00
  • GPT-6 Sol(超过 272K 加价):$4.00 × 0.5 + $15.00 × 0.05 = $2.75(不加价时为 $1.50)
  • Gemini 3.1 Pro(超过 200K 的单价):$4.00 × 0.5 + $18.00 × 0.05 = $2.90(按 200K 以内的单价为 $1.60)
  • GPT-6 Astra(超过 272K 加价):$20.00 × 0.5 + $75.00 × 0.05 = $13.75

可以从两个角度解读。其一,一旦越过阈值,同一模型的费用就会变成约 1.8 倍。短输入时 GPT-6 Sol 只要 Claude Opus 5.5 的一半,但到 500K 时差距几乎消失——“哪个模型更便宜”会随输入长度而逆转。其二,单价本就高的旗舰模型再叠加加价,费用就会跳到另一个量级(GPT-6 Astra 是 Opus 5.5 的 4 倍多)。请用你要比较的模型和自己的平均输入长度重新算一遍再做选择。

对于有阈值的计费,能拆分的工作就拆到阈值以内。把 500K 拆成两次 250K 的请求,GPT-6 Sol 就不会加价,总共只要 $1.50(但需要一次性通览全文的任务不适用)。这与“AI 令牌与会话成本节约”中提到的结构相同。

注:同一份文档,在不同模型上的令牌数可能不同。上限和计费都按令牌计算,所以分词器一换,同一份文档的费用和余量都会变化。Anthropic 在官方模型概览中写道:自 Claude Opus 4.7 引入、此后模型沿用的分词器,100 万令牌约可容纳 55.5 万个单词,而此前的模型约为 75 万个单词——相当于同样的英文文本要多用约 1.35 倍的令牌。即使单价不变,换模型后也应以实际账单来比较。

6. 五条节省策略——按个人开发者的实际效果排序

“容器是 1M,但有效范围在那之前就结束了,长时间使用还会变贵。”我们已经梳理过了。那么在现场实际能做什么?下面是我日常使用的五条策略,按收益最大的顺序排列。

五条实用策略

上下文节省——优先级顺序

① 切断会话
话题转变时,开新聊天。仅仅是阻止旧上下文延续,就能消除 Context Rot。在 Claude Code 中,使用 /compact 或开启新会话。
② 发摘录而非全文
把整份 100 页的 PDF 粘进去是最坏的做法。用 grep / 搜索提取相关段落,压缩到 3–5 页再发送。这是把RAG思维独自实践的方式。
③ 在末尾重述关键指令
应对 Lost in the Middle 的策略。在末尾用一行重申开头的规则:“基于上述内容,按 X 格式输出。”
④ 提示词缓存
如果反复使用同一个系统提示词或资料,Anthropic/OpenAI 的提示词缓存能让从缓存读取部分的输入单价降到基础单价的 10% 以下(2026 年 9 月的官方价格)。只要在调用 API,就先把它设置好。
⑤ 明示文件地址
明确指出“第 N 个文件,第 X 行”能提升长上下文中的检索精度。可以理解为给 AI 递上一份带索引条目的目录。

五条之中,策略①“切断会话”带来的可见收益最大。仅仅切断聊天就能明显减少幻觉。
策略④面向 API 开发者——UI(claude.ai / ChatGPT)会自动处理缓存。

我个人的最佳实践是:仅仅持续做①和②,感知到的精度就会显著提升。即便用 Claude Code,与其推动一个长会话,不如在每次话题转变时按 /compact 或开启新会话——这样最终输出的质量会更稳定。

总结

本文要点整理如下。

  • 上下文窗口 = AI 在一次交互中能处理的最大令牌数,即容器的尺寸
  • 截至 2026 年 9 月,Anthropic、OpenAI 和 Google 的顶级模型都在 100 万令牌级别。输入上限差别不大,差异在于输出上限和长输入的计费
  • 标称上限与有效范围是两回事。在 OpenAI 公布的多针基准 MRCR(8 针)中,同一模型的输入越长得分越低,接近 1M 时的数值从 Claude Opus 4.7 的 32.2%(OpenAI 的表)到 GPT-6 Astra 的 96.3% 不等
  • 要找出有效范围,最可靠的办法是在自己的文档中分散放置事实,并改变长度来测试。换模型后要重新测
  • 长输入的计费分两种:直到上限都是同一单价(Anthropic),以及超过阈值就加价(OpenAI 为 272K,Google 为 200K)。便宜与否会随输入长度而逆转
  • 节省靠“切断会话、给摘录、末尾重申、缓存、明示地址”五招,其中①②最有效

容器变大了,但我们真正在做的,依然是“给什么、不给什么”的取舍。如今的 AI 运用能力早已不是“全部塞进去的能力”,而是只把必要内容准确交付的判断力——无论模型更替多少代,这都是长久有用的技能。这就是在 1M 已成常态的当下,我的结论。

FAQ

Q1. 如何提前测量令牌数?

OpenAI 有 tiktoken 库,Anthropic 的 API 提供计算令牌数的功能(token counting)。大致参考:1 个日文字符 ≈ 1–1.5 个令牌,1 个英文单词 ≈ 1.3–1.8 个令牌,但会随分词器的代际而变化(见 §5 的补充)。代码也因种类差别很大,投入长文本前先实测最稳妥。

Q2.“记忆”和上下文有什么不同?

上下文只存在于会话内部——关闭聊天就消失。记忆(ChatGPT Memory / Claude Memory)是另一种跨会话保留机制。记忆内容最终会被注入到上下文窗口,但从用户角度看,是持久 vs. 临时的区别。

Q3. RAG 与上下文窗口有什么关系?

RAG 是“动态地只把必要信息取入上下文”的模式。即便有 1M 窗口,把一切都塞进去会让响应变慢、变重、变贵,所以“先检索再加载”(RAG)仍是主流方法。详见什么是 RAG。

Q4. 为什么支持 1M,精度却在远未填满时就下降?

多种因素叠加:训练时主要见到的序列长度与推理时序列长度不匹配、注意力机制中位置编码的局限,以及整合多条信息所需计算量的急剧增加等。“支持”和“全域保持精度”是两个不同的问题。从哪里开始下降因模型和用途而异,最可靠的是按 §4 的方法用自己的文档来测。

Q5. MCP 服务器能节省上下文吗?

能。MCP 是通过工具按需获取的机制,因此无需事先把所有内容都加载进上下文。把心智模型从“粘贴整份文件”切换到“让它去读文件”。

Q6. 超出有效范围的长文档,该如何拆分和总结?

按目的区分。① 想要全文摘要时,先逐章总结,再把各章摘要汇总,分两步进行。② 想找特定答案时,不要投入全文,而是用检索只抽取相关部分(RAG)。③ 只有需要横跨全文进行比较时,才以有效范围内的长度一次性投入。拆分时按标题切分,并让前后各重叠几段,这样切口处的内容不容易断掉。