理解 上下文

#上下文窗口包含的内容

根据 Ollama 的文档，上下文长度是模型在内存中可访问的最大 token 数量。所有内容都计入这一个总额度：系统消息、对话历史、您粘贴的文件或文档片段、您最新的问题，以及模型正在生成的回复。对于推理模型，思考 token 也计入其中。当总量超过上下文窗口时，就必须舍弃一些内容：工具通常会截掉开头的内容，或者拒绝请求。模型在这个窗口之外没有任何记忆，除非外部系统（摘要、RAG）重新向它注入信息。

#Token：占用上下文窗口的单位

一个标记（token）不是一个单词：它是模型 tokenizer 定义的文本片段，通常是一个音节或常见单词。罕见或较长的单词会占用多个标记。法语在同等内容下通常比英语消耗更多的标记，因为大多数 tokenizer 都主要基于英语进行训练。具体比例因模型而异：不要依赖经验法则，应实际测量。Ollama 的 API 每次请求都会返回 prompt_eval_count，即提示词的标记数量。

curl http://localhost:11434/api/generate -d '{"model":"qwen3:8b","prompt":"Bonjour le monde","stream":false}'
# lisez prompt_eval_count et eval_count dans la réponse JSON

经验法则

一页密集的法语A4文本大约相当于一千个token，具体取决于分词器：请在您自己的文档上使用prompt_eval_count进行验证。

一本图书

数十万tokens：在不进行分块的情况下，32,000或64,000 tokens的上下文窗口无法容纳。

一个回答

一个推理模型可能在生成可见响应前产生数千个思考 token，从而消耗可用窗口。

#应选择多大的上下文窗口

Ollama 根据显存容量设置默认值：显存低于 24 GiB 时约为 4000 个 token（4k），在 24 至 48 GiB 之间时为 32k，从 48 GiB 起为 256k。同一页面建议，对于需要大上下文的任务，例如网页搜索、智能体和编码工具，至少使用 64000 个 token。近期模型公布的最大上下文长度要高得多：例如，QuelLLM 目录列出的 Kimi K2.5 约为 256000 个 token，而 Kimi K3、DeepSeek V4 Flash 和 GLM 5.2 均约为 100 万个 token。但公布的最大值并不等于您机器上实际可用的上下文长度：内存容量，有时还有质量问题，会成为限制。

确定上下文窗口大小时，经常会遇到两个陷阱。首先，窗口必须留出容纳回答的空间：如果一份文档占用了 32 000 个 token 中的 31 000 个，就几乎没有空间用于回答，推理模型也会在思考到一半时停止。其次，在对话中，历史记录会随着每一轮不断增长：第一条消息时够用的窗口，到第二十轮时可能就满了。因此，请按您实际使用中的最坏情况规划，而不是按平均情况，并保留约五分之一的窗口作为余量。

#上下文消耗多少内存

上下文窗口中的每个 token 都会在模型的每一层留下一个键和一个值，存储在 KV 缓存中。每个 token 的内存开销可根据架构中的四个数值计算：层数、键值头数量、每个头的维度，以及每个数值占用的字节数（FP16 为2字节）。公式为：2（键和值）× 层数 × KV 头数量 × 头维度 × 2字节。注意：应计算键值头数量，而不是注意力头数量，因为较新的模型会让多个注意力头共享键值头（grouped-query attention，分组查询注意力）。对于下方的模型，如果使用注意力头数量计算，估算出的缓存大小会是实际值的四倍。

以 Qwen3-8B 为例，其官方规格表注明有 36 层和 8 个键值头（查询头则有 32 个），公开配置将每个头的维度设为 128。每个 token 的内存开销为 2 × 36 × 8 × 128 × 2 = 147 456 字节，即 144 KiB。

两个杠杆可以减少缓存。第一个是缓存的量化：Ollama 的 FAQ 指出，q8_0 类型消耗的 FP16 内存大约为一半，且损失极小，而 q4_0 消耗约四分之一，但在大上下文场景下损失更明显；两者均要求启用 Flash Attention。第二个是将窗口缩小到实际所需范围。我们的 KV 缓存指南详细说明了相关设置。

#设置上下文长度

#在 Ollama 中

Ollama 允许在服务器启动时设置默认长度，也可以为某个会话更改长度，或通过 API 为每次请求单独指定长度。

# Valeur par défaut pour tout le serveur
OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# Pour une session interactive
>>> /set parameter num_ctx 16384

# Pour un modèle personnalisé (Modelfile)
FROM qwen3:8b
PARAMETER num_ctx 16384

加载完成后，执行 ollama ps：CONTEXT 列显示分配的上下文长度，PROCESSOR 列显示GPU与CPU之间的计算分配比例。若部分计算负载落在CPU上，建议减少上下文长度或选择更小的模型。

#在 LM Studio 中

在LM Studio中，上下文长度在加载模型时通过加载参数设置，更改值需要重新加载模型。在确认前，请注意内存估算值。

#四步配置流程

1. 01
   测量实际需求

   发送您的文档或典型对话历史，并查看 prompt_eval_count。再加上预期回复的长度；如果模型还会生成思考内容，也要加上这部分的长度。
2. 02
   选择上下文窗口

   选择能够容纳这一总量并留出 20% 余量的最小值；如果使用智能体或编程工具，则按照 Ollama 的建议，至少选择 64,000 个 token。
3. 03
   检查内存

   按这个上下文窗口大小加载模型，然后运行 ollama ps。处理器一栏应显示 100% GPU；否则，请缩小上下文窗口、量化缓存或更换模型。
4. 04
   测试召回功能

   在一段长文本的中间放入一个具体事实，然后向模型询问这个事实。如果模型未能找出它，说明宣称的上下文窗口大于模型实际能利用的范围，需要采用文本切分或 RAG。

#上下文窗口大，并不意味着能准确理解内容

2023 年的一项研究《Lost in the Middle》表明，模型性能可能会因信息在上下文中的位置而明显下降：信息位于开头或结尾时，性能通常更好；位于中间时，性能则会下降，即使是宣称支持长上下文的模型也不例外。2024 年发布的 RULER 基准测试进一步表明：随着上下文长度增加，几乎所有受测模型的准确率都会大幅下降，只有一半模型在 32,000 个 token 时仍能保持令人满意的水平，而它们全都宣称支持 32,000 个或更多 token。

这些研究针对的是各自时代的模型，无法说明 2026 年模型的表现，其中多个模型专门针对长上下文进行了训练。但操作原则仍然适用：将指令和关键事实放在开头，在结尾重申问题，并先用您自己的文档进行测试，再相信所宣称的数十万 token 上下文窗口。最简单的测试是，在您所在领域的一篇长文本中间插入一条具体信息，然后让模型再次提供这条信息：如果模型每次测试都能找到它，这个窗口就能用于您的使用场景；如果找不到，就缩短发送的文本，或采用分段处理。

#当内容溢出时

随对话推进逐步总结

每隔几轮让模型生成一次对话摘要，再以该摘要作为上下文的开头重新开始：会丢失一些细节，但能保持对话主线。

分割文档

长 PDF 按章节逐一处理，再汇总各部分的回答。分块指南详细介绍了适用的分块大小。

切换到RAG

当语料库远超窗口范围时，只提取少量相关片段，而非全部发送。

选择上下文更长的模型

只有内存足够时才可以：将上下文窗口扩大一倍之前，请先参阅上文的KV缓存计算。

#深入了解

• 量化 KV 缓存：节省 VRAM
• Token 与分词：理解 LLM 处理的输入
• 选择量化方案（Q4、Q5、Q8、FP16）
• RAG 是什么？它如何工作？
• 分块策略
• VRAM 计算器

• 来源：Ollama 文档，上下文长度
• 来源：Ollama 常见问题（KV 缓存、Flash Attention）
• 来源：Lost in the Middle（arXiv 2023）
• 来源：RULER，长上下文基准测试（arXiv 2024）