上下文窗口指南 2026：4K vs 32K vs 128K token

作者： Jakub Rusinowski · 最后更新： 2026年7月12日

最后更新：2026 年 5 月 —— 上下文窗口是本地 AI 中最容易被误解的规格之一。本指南解释它的含义、它如何影响显存，以及不同任务你实际需要多大的上下文。

本指南内容

什么是上下文窗口？
热门本地模型的上下文窗口（2026）
上下文长度如何影响显存
上下文窗口的使用场景
上下文长度与 RAG：一个重要的细微差别
上下文窗口 vs 模型质量：权衡
按任务的实用配置
常见问答

最后更新：2026 年 5 月 —— 上下文窗口是本地 AI 中最容易被误解的规格之一。本指南解释它的含义、它如何影响显存，以及不同任务你实际需要多大的上下文。

什么是上下文窗口？

上下文窗口是模型一次能"看到"的最大文本量——包括你的整段对话历史、系统提示、你粘贴进来的文档，以及模型自身的回复。

可以把它看作短期记忆：上下文窗口之外的一切都会被遗忘。

Token 换算指南：

1 token ≈ 0.75 个英文单词
1 页文本 ≈ 500–750 token
一本书的 1 章 ≈ 3,000–5,000 token
整篇本指南 ≈ 2,500 token

上下文大小	约合词数	能容纳什么
4,096 token	~3,000 词	简短对话、简单问答
8,192 token	~6,000 词	中等对话、短文章
32,768 token	~24,000 词	长文档、书籍章节
128,000 token	~96,000 词	整本书、大型代码库
1,000,000 token	~750,000 词	多本书（仅 Gemini Ultra）

上下文长度如何影响显存

KV 缓存（键值缓存）存储上下文信息，并随上下文长度增长。这是在基础模型显存之外的额外开销：

对于 Llama 3.1 8B（Q4_K_M，基础 6GB）：
- 4k 上下文：   +0.3 GB → 共约 6.3 GB
- 8k 上下文：   +0.6 GB → 共约 6.6 GB
- 32k 上下文：  +2.5 GB → 共约 8.5 GB
- 128k 上下文： +10 GB  → 共约 16 GB（！）

以 128k 上下文运行一个 7B 模型，所需显存和一个 8k 上下文的 13B 模型相当。

实用启示： 不要"以防万一"就把上下文设为 128k——设成你实际需要的值。对大多数聊天用例，Ollama 的默认值（2k–4k）就够了。

在 Ollama 中设置上下文长度

# Set context length for a session
ollama run llama3.1 --context-length 32768

# Or in a Modelfile for permanent configuration
FROM llama3.1:8b
PARAMETER num_ctx 32768

# Build and use
ollama create my-llama -f Modelfile
ollama run my-llama

上下文窗口的使用场景

何时 4k–8k 就够

随意对话 —— 聊天会话自然情况下很少超过 4k token
代码片段 —— 审查一个函数或类
简单问答 —— 单个问题的回答
邮件起草 —— 大多数邮件不足 500 token

何时你需要 32k

审查整个文件 —— 大多数源文件为 500–3,000 行
总结一篇文章 —— 典型长文为 5–15k 词
多轮编程会话 —— 保持一次调试会话的上下文
会议记录 —— 一小时会议 ≈ 15,000–25,000 token

何时你需要 128k

完整文档分析 —— 法律合同、研究论文、技术规格
代码库审查 —— 一个项目的多个文件
书籍篇幅的摘要 —— 小说章节、报告
复杂 RAG —— 大块检索到的上下文

上下文长度与 RAG：一个重要的细微差别

许多用户以为："上下文越多 = 越不需要 RAG。"这部分成立，但：

检索仍然更高效 —— 在一个 10GB 的文档集合中搜索并检索出 5k 相关 token，胜过塞入 128k 个无关文本 token
长上下文在极端处会退化 —— 模型往往会"丢失"极长上下文中间部分的信息（"迷失在中间"问题）
混合方案胜出 —— 用 RAG 检索相关块，再用长上下文对其推理

对大多数实际应用而言，8k–32k 上下文 + 良好检索，胜过单靠 128k 上下文。

上下文窗口 vs 模型质量：权衡

更长的上下文通常伴随更慢的响应：

首 token 耗时（Llama 3.1 8B，RTX 4090）：
- 提示长度 500 token：   0.3 秒
- 提示长度 4,000 token： 2.1 秒
- 提示长度 32,000 token：18 秒
- 提示长度 128,000 token：70+ 秒

对于交互式使用，把提示保持在 8k token 以内。对于批处理（摘要、分析），更长的上下文可以接受。

按任务的实用配置

任务	推荐上下文	理由
日常聊天助手	4k–8k	高效，大多数对话都装得下
代码助手（文件级）	16k–32k	一个或几个文件
文档摘要器	32k–64k	大多数文档都装得下
完整代码库助手	64k–128k	多个文件、项目上下文
书籍分析	128k	完整书籍章节
研究论文审阅	32k	典型论文 ≈ 8,000–15,000 token

常见问答

超出上下文时会发生什么？ 模型会截断最旧的内容（通常是对话的开头）。你会注意到 AI"忘记"了对话早期的部分。

上下文窗口会影响模型质量吗？ 不直接影响——但针对更长上下文微调过的模型往往更擅长处理长距离依赖。一个宣称支持 128k 上下文的模型，若未专门为此训练，在 100k 时可能仍表现不佳。

我能把上下文窗口扩展到超出模型支持的范围吗？ 不可靠。一些技术（RoPE 缩放、YaRN）能在一定程度上扩展上下文，但会有质量下降。更好的做法是选一个为你所需上下文长度而设计的模型。

为什么小模型也支持 128k 上下文？ 模型权重和上下文窗口是相互独立的。一个 4B 模型可以有 128k 上下文——这只是意味着你需要为 KV 缓存准备额外显存。128k 时的模型质量取决于它的训练，而不仅仅是参数量。

模型	上下文窗口	显存（Q4）
Phi-3.5 Mini	128k	3 GB
Llama 3.1 8B	128k	6 GB
Qwen 2.5 14B	128k	9.5 GB
Gemma 3 27B	128k	16.5 GB
DeepSeek R1 32B	64k	20 GB
Llama 3.3 70B	128k	40 GB
Llama 4 Scout	128k	10.5 GB
Llama 4 Maverick	128k	24 GB
Mistral NeMo 12B	128k	8 GB