LLM 上下文窗口是什么？一文搞懂 Token 限制与长文本策略
用最直白的方式讲清楚上下文窗口｜GPT-5 400K、Gemini 1M、Claude 200K 实际能塞多少内容？附 RAG、分块、滑动窗口等 5 种长上下文处理方案，含代码示例。
每次调用大语言模型 API 时，你的请求都在一个看不见的边界内运行——上下文窗口（Context Window）。它决定了模型一次能”看到”多少内容：你的 prompt、系统指令、检索到的文档、对话历史，以及模型自身的回复，全部要在这个窗口内放下。超出限制，模型要么拒绝请求，要么静默丢弃最早的内容。
如果你正在基于 LLM 构建应用，理解上下文窗口不是”了解即可”——它直接影响你的系统架构、API 成本和用户体验质量。
什么是上下文窗口？
上下文窗口是大语言模型在单次请求-响应周期中能处理的 token 总量。Token 是模型读取和生成的最小单位——在英文中大约等于 0.75 个单词，在中文中通常 1-2 个汉字对应一个 token（取决于具体的 tokenizer 实现）。
调用 LLM API 时，你发送输入（prompt + 系统消息 + 上下文），接收输出（模型的回复）。上下文窗口覆盖的是 输入 + 输出 token 的总和。例如一个 128K 上下文窗口的模型，如果你的输入占了 100K token，模型只剩 28K token 用于生成回复。
可以把上下文窗口想象成一块固定大小的白板。模型关于当前对话所知道的一切都必须写在这块白板上。白板写满了，就必须擦掉旧内容才能写新内容。
Token、字符、单词的换算关系
开发者经常混淆这三个单位。以下是实用的换算参考：
| 单位 | 英文近似比例 | 中文近似比例 |
|---|---|---|
| 1 token | ~4 个字符 / ~0.75 个单词 | ~1-2 个汉字 |
| 1,000 tokens | ~750 个英文单词 | ~500-700 个汉字 |
| 100K tokens | ~75,000 英文单词（~150 页） | ~50,000-70,000 汉字（~100 页） |
中文开发者注意：由于 CJK 字符的 token 效率通常低于英文，同样大小的上下文窗口在处理中文时能容纳的内容约为英文的 65-75%。这在做上下文预算时需要额外注意。
想知道你的文本精确占用多少 token？使用我们的 AI Token 计数器 即可跨模型即时测量。
2026 年各主流模型的上下文窗口
上下文窗口经历了爆发式增长。2023 年初 GPT-3.5 仅有 4K token，如今头部模型已经达到百万级别。
主流模型 Token 限制对比（2026）
| 模型 | 厂商 | 上下文窗口 | 最大输出 |
|---|---|---|---|
| GPT-5 | OpenAI | 1,000,000 tokens | 32,768 tokens |
| GPT-4.1 | OpenAI | 1,000,000 tokens | 32,768 tokens |
| Claude Opus 4 | Anthropic | 200,000 tokens | 32,000 tokens |
| Claude Sonnet 4 | Anthropic | 200,000 tokens | 16,000 tokens |
| Gemini 2.5 Pro | 1,000,000 tokens | 65,536 tokens | |
| Gemini 2.5 Flash | 1,000,000 tokens | 65,536 tokens | |
| DeepSeek V3 | DeepSeek（深度求索） | 128,000 tokens | 8,192 tokens |
| Llama 4 Maverick | Meta | 1,000,000 tokens | 16,384 tokens |
| Mistral Large | Mistral | 128,000 tokens | 8,192 tokens |
几个关键观察：
-
百万 token 俱乐部持续扩大。 GPT-5、Gemini 2.5 Pro、Llama 4 Maverick 都支持 100 万 token 上下文，足够放下一个中等规模的完整代码库或好几本书。
-
输出限制远小于输入。 即使模型支持 100 万 token 输入，输出通常上限在 8K-65K。上下文窗口是不对称的——你可以喂给模型大量内容，但模型不会一次写出一本书。
-
国产模型表现亮眼。 DeepSeek V3 提供 128K 上下文，价格仅为 GPT-5 的 1/7，对于成本敏感的场景是非常有竞争力的选择。
上下文窗口的底层原理
上下文窗口与模型的注意力机制（Attention Mechanism）直接相关。基于 Transformer 的 LLM 使用自注意力让序列中的每个 token 都能”关注”其他所有 token。注意力层的计算复杂度随序列长度呈二次方增长——上下文窗口翻倍，注意力层的计算量大约翻四倍。
这就是大上下文窗口昂贵的根本原因。模型厂商通过稀疏注意力、环形注意力、KV-Cache 优化等架构创新让百万级上下文成为可能，但底层的成本关系并未改变。
滑动窗口注意力 vs 全注意力
部分模型使用滑动窗口注意力（Sliding Window Attention）——每个 token 只关注最近 N 个 token，而非整个上下文。Mistral 早期模型就采用了这种方式，滑动窗口为 4,096 token。优点是效率高，缺点是距离较远的 token 之间的关联会减弱。
2026 年大部分前沿模型使用全注意力机制覆盖整个上下文窗口，但通过 GQA（分组查询注意力）等技术降低显存占用。
“中间遗忘”问题
这是很多开发者忽略的关键问题：LLM 对上下文各部分的关注度并不均匀。
Liu 等人 2023 年的一篇重要论文证明，LLM 在相关信息位于上下文的开头或结尾时表现最好，而当信息埋在中间位置时，性能显著下降。这被称为 “Lost in the Middle”（中间遗忘） 问题。
对实际开发的影响
假设你在构建一个 RAG 管道，检索了 20 个文档块并全部塞进 prompt。如果最相关的内容恰好排在第 8-12 位，模型可能会有效地忽略它——即使它确实存在于上下文中。
新一代模型（Claude Opus 4、GPT-5）对中间位置的处理能力有所改善，但这个效应并未完全消失。实践中仍然需要注意：
- 最重要的信息放在最前面（紧跟系统 prompt 之后）。
- 指令放在最后，靠近模型开始生成回复的位置。
- 不要为了”填满”上下文而塞入边缘相关的内容。
- 使用显式标记（如 XML 标签、编号标题、分隔符）帮助模型定位信息。
“更多上下文不等于更好结果”
模型支持 100 万 token 并不意味着你应该全部用完。研究持续表明，即使相关信息存在于上下文中，随着上下文长度的增加，模型准确率也可能下降。上下文越长，模型在”大海”中找”针”的难度越大。
在 Needle-in-a-Haystack 基准测试中，大多数模型在短上下文下接近完美，但在上下文窗口的极限处出现明显退化。生产环境中，使用任务所需的最小上下文往往比最大化上下文利用率效果更好。
成本影响：大上下文有多贵？
上下文大小直接影响 API 账单。LLM API 按 token 计费——输入和输出都收费。以下是”填满”上下文窗口的单次请求成本：
填满完整上下文的成本（仅输入）
| 模型 | 上下文大小 | 输入价格（每百万 token） | 填满一次的成本 |
|---|---|---|---|
| GPT-5 | 1M tokens | $2.00 | $2.00 |
| Claude Opus 4 | 200K tokens | $15.00 | $3.00 |
| Claude Sonnet 4 | 200K tokens | $3.00 | $0.60 |
| Gemini 2.5 Pro | 1M tokens | $1.25 / $2.50 | ~$2.25 |
| DeepSeek V3 | 128K tokens | $0.27 | $0.035 |
一次填满 GPT-5 的 100 万 token 上下文窗口，仅输入就要花 $2.00（约 ¥14.5）——还没算输出费用。对比之下，DeepSeek V3 填满 128K 上下文仅需 $0.035（约 ¥0.25），差距超过 50 倍。
部分厂商提供 Prompt Caching（如 Anthropic 的缓存机制、OpenAI 的 cached pricing），对重复发送的上下文可降低 50-90% 的费用。如果你的应用中系统 prompt 或文档集在多次请求间保持不变，这是必须开启的优化。
想要精确估算不同模型、不同用量下的 API 成本？使用我们的 AI 模型价格计算器 进行对比。
长上下文管理策略
当你的数据超出上下文窗口，或者填满窗口成本过高、质量反而下降时，你需要合理的管理策略。以下是五种最核心的方法。
1. 分块 + 检索增强生成（RAG）
RAG 是最常用的模式。核心思路是不把所有内容塞进上下文，而是：
- 将文档拆分为小块（通常 256-1024 token/块）。
- 为每个块生成向量嵌入（embedding）。
- 用户查询时，只检索最相关的 Top-K 个块。
- 将这些块（而非全部语料）放入 LLM 的上下文窗口。
这样可以处理任意规模的数据集，同时只使用上下文窗口的一小部分。一个调优良好的 RAG 管道（5-10 个检索块）往往比”全部塞进去”的效果更好——即使模型的上下文窗口理论上放得下所有数据。
国内开发者建议：向量数据库方面，如果追求性价比，可以考虑 Milvus（开源，国产）或 Tencent Cloud VectorDB；如果追求简单快速上手，Pinecone 和 Weaviate 也是主流选择。
2. 摘要链（Map-Reduce Summarization）
对于必须完整处理的长文档，使用分而治之的摘要策略：
- 将文档拆分为适合上下文窗口的块。
- 分别对每个块生成摘要（map 步骤）。
- 将所有摘要合并，生成最终总结（reduce 步骤）。
这会增加延迟和成本（多次 LLM 调用），但能处理任意长度的文档。特别适合”总结这份 500 页报告”这类任务，需要全文的核心内容但不需要每个细节。
3. 滑动窗口 + 重叠
对于需要顺序处理的任务（如分析长对话日志或大型代码库），使用带重叠的滑动窗口：
- 处理 token 0-100K，生成中间结果。
- 窗口滑动：处理 token 80K-180K（20K 重叠保持连续性）。
- 合并各窗口的结果。
重叠区域确保窗口边界处的内容不会被遗漏。这种方法适合具有一定局部性的任务——比如在代码库中查找 bug，每个 bug 通常局限在较小的代码段内。
4. 上下文压缩
在发送给 LLM 之前，先压缩文本以减少 token 占用：
- 去除样板内容、页眉页脚、重复段落。
- 用更小、更便宜的模型预先摘要冗长部分。
- 通过关键词匹配或轻量级检索器仅提取相关章节。
- 移除 HTML 标签、Markdown 格式等非必要标记。
一份 10 万 token 的文档经过压缩后可能缩减到 2 万 token，信息损失极小。这同时节省了费用和模型的注意力。
5. 分层上下文管理
对于复杂应用（如编程 Agent 或多轮对话助手），使用分层策略：
- 第一层（始终存在）：系统 prompt、核心指令、用户偏好。约 2-5K token。
- 第二层（会话上下文）：当前对话摘要、活跃任务状态。约 5-20K token。
- 第三层（按需加载）：检索的文档、代码文件、数据库查询结果。仅在相关时加载。
这确保了最重要的上下文始终存在，而昂贵的、易变的上下文仅在需要时加载。大多数生产级 AI 应用都采用这种模式来平衡质量和成本。
本地推理场景下的上下文窗口
如果你在本地运行模型（通过 llama.cpp、vLLM、Ollama 等），上下文窗口大小直接影响 显存（VRAM）需求。存储上下文的 KV-Cache 随序列长度线性增长，对于大型模型，它可能消耗数十 GB 的 GPU 显存。
举个例子：以完整 128K 上下文长度运行一个 70B 参数的模型可能需要 80GB 以上的显存——远超单张消费级 GPU 的容量。实际上，大多数本地部署会将上下文限制在 4K-16K token 以适配硬件条件。
国内常见硬件参考：
- RTX 4090（24GB VRAM）：可运行 7B-14B 模型，4K-8K 上下文
- 双 RTX 4090：可运行 70B 模型（量化后），8K-16K 上下文
- A100 80GB：可运行 70B 模型，32K+ 上下文
计划本地部署？使用我们的 VRAM 计算器 估算你的模型、量化级别和期望上下文长度所需的显存。
如何选择合适的上下文窗口
并非每个应用都需要百万 token 上下文。以下是实用的决策框架：
小上下文（4K-16K tokens）
适用场景：简单聊天机器人、文本分类、短内容生成、单轮问答。 原因：成本低、速度快，模型的注意力集中在少量高度相关的数据上。
中等上下文（32K-128K tokens）
适用场景：单文档问答、单文件代码审查、多轮对话、文章摘要。 原因：足够容纳一份完整文档或一段合理长度的对话历史，成本可控。
大上下文（200K-1M tokens）
适用场景：整个代码库分析、多文档推理、长篇论文分析、法律合同审查、书籍级内容处理。 原因：当任务确实需要跨大量文本进行推理，且内容无法被轻松分块时才需要。
决策原则
问自己一个问题：“模型是否需要同时看到所有这些数据来推理，还是任务可以被分解？”
如果可以分解，用 RAG 或分块 + 较小的上下文。如果模型确实需要同时看到所有内容（比如”找出这 50 条法律条款之间的矛盾”），使用大上下文——但要做好成本和质量权衡的准备。
未来趋势
上下文窗口将继续增长。Google 已经在研究中展示了 1000 万 token 的上下文，架构创新正在降低长上下文的成本。值得关注的趋势：
-
通过记忆系统实现”无限”上下文：与其无限扩大原始上下文窗口，一些方案让模型拥有可跨轮次读写的外部记忆，从而实现事实上的无限上下文。
-
长上下文成本持续下降：Prompt Caching、投机解码、高效注意力机制正在大幅降低长上下文的单 token 成本。预计一年内百万 token 请求的费用将降至目前的几分之一。
-
中间位置检索能力提升：新一代模型架构正在显式训练跨全上下文窗口的信息检索能力，“中间遗忘”效应正在减弱。
-
RAG 与长上下文的融合：RAG 和长上下文之间的界限正在模糊。未来的系统可能会用长上下文窗口作为”工作记忆”，同时从更大的知识库中检索补充信息。
总结
上下文窗口是 LLM 应用开发中最具实际影响力的核心概念之一。关键要点：
- 上下文窗口是模型单次请求中能处理的 token 总量（输入 + 输出）。
- 更大并不总是更好——成本、延迟和”中间遗忘”问题都表明，使用任务所需的最小上下文通常是最优策略。
- 各模型 token 限制差异巨大：从 128K（DeepSeek V3）到 1M（GPT-5、Gemini 2.5 Pro）。
- RAG、摘要、分块等策略让你能处理超过任何上下文窗口的数据集。
- 成本随上下文使用量线性增长——务必监控 token 消耗。
使用 AI Token 计数器 测量你的 prompt 长度，用 价格计算器 估算 API 成本，用 VRAM 计算器 规划本地部署。深入理解上下文窗口，是构建可靠、经济的 AI 应用的基础。