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

作者: Jakub Rusinowski最后更新 6 分钟阅读Intermediate

最后更新: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)

热门本地模型的上下文窗口(2026)

模型上下文窗口显存(Q4)
Phi-3.5 Mini128k3 GB
Llama 3.1 8B128k6 GB
Qwen 2.5 14B128k9.5 GB
Gemma 3 27B128k16.5 GB
DeepSeek R1 32B64k20 GB
Llama 3.3 70B128k40 GB
Llama 4 Scout128k10.5 GB
Llama 4 Maverick128k24 GB
Mistral NeMo 12B128k8 GB

大多数现代模型都支持 128k 上下文——但用满这么多上下文会消耗显存并拖慢推理。

上下文长度如何影响显存

KV 缓存(键值缓存)存储上下文信息,并随上下文长度增长。这是在基础模型显存之外的额外开销:

shell
对于 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 中设置上下文长度

bash
# 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 模型质量:权衡

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

shell
首 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 时的模型质量取决于它的训练,而不仅仅是参数量。

相关指南