什么是上下文长度，它为什么对本地LLM重要？
上下文长度是模型在一次请求中最多能容纳的token数：你的提示词、所有文档、此前的对话以及它写出的回答加在一起。 一个token约等于0.75个英文单词，因此128K token约10万词，256K token约20万词。
标称窗口是模型架构支持的最大值。实际可用窗口是回答对你的任务仍然准确的长度，它更短。
长窗口对整个代码库、合同、长篇转录、书籍章节以及工具输出不断累积的智能体会话很重要。Ollama文档建议智能体、网页搜索和编程工具至少使用64,000 token。
在你自己的机器上，上限由三点决定：模型的窗口、该长度下KV缓存所需的内存，以及模型在该长度下使用文本的可靠程度。接下来的各节依次说明。
2026年哪些本地LLM支持超过128K token？
有好几个：在Ollama模型库中，Qwen3.5、Qwen3.8和Gemma 4（12B及以上）列出256K窗口，NVIDIA Nemotron 3 Nano 30B列出1M，Llama 4 Scout列出10M。 2026年之前发布的模型大多止步于128K。
表中是模型卡或Ollama模型库列出的窗口。YaRN等更长上下文的扩展是厂商文档中的选项，需要额外的配置和内存。
Llama 4 Scout列出10M token，但其模型卡在128K窗口下报告长上下文基准测试，而且Ollama下载为67 GB。Llama 4 Maverick列出1M，但下载达245 GB，需要服务器级硬件。
Ollama标签的窗口大小可能不同：qwen3:8b和qwen3:14b列出40K，而qwen3:4b和qwen3:30b列出256K。规划之前，请在模型的Ollama页面上查看上下文数值。
模型 | 列出的窗口 | 更长上下文 | Ollama标签 |
|---|---|---|---|
| Nemotron 3 Nano 30B-A3B | 1M（默认256K） | — | ollama run nemotron-3-nano:30b |
| Qwen3.8 27B | 256K | 最高1M（YaRN） | ollama run qwen3.8:27b |
| Qwen3.5 9B / 27B | 256K | 最高1.01M（YaRN） | ollama run qwen3.5:9b |
| Qwen3 30B-A3B-2507 | 256K | 1M（DCA，约240 GB GPU） | ollama run qwen3:30b |
| Gemma 4 12B / 26B / 31B | 256K | — | ollama run gemma4:26b |
| Gemma 4 E2B / E4B | 128K | — | ollama run gemma4:e4b |
| Llama 4 Scout 109B | 列出10M | 基准测试在128K | ollama run llama4:16x17b |
| Mistral Small 3.2 24B | 128K | — | ollama run mistral-small3.2 |
| gpt-oss 20B | 128K | — | ollama run gpt-oss:20b |
| Llama 3.1 8B | 128K | — | ollama run llama3.1:8b |
| Qwen3 8B / 14B | 40K | — | ollama run qwen3:14b |
长上下文需要多少内存？
长上下文所需的内存是模型权重加KV缓存，而KV缓存取决于架构，不只取决于窗口。 KV缓存保存上下文中每个token的注意力键和值，并在权重之外另行分配。
每token的KV字节数 = 2（键和值）× 全注意力层数 × KV头数 × 头维度 × 每个值的字节数（默认f16缓存为2）。Llama 3.1 8B：2 × 32 × 8 × 128 × 2 = 131,072字节（128 KiB）/token，128K token时为16 GiB，是其4.9 GB下载大小的三倍多。
较新的架构降低了这一成本。Gemma 4在大多数层使用滑动窗口注意力（12B、26B和31B的窗口为1,024 token），gpt-oss每隔一层使用（128 token），Qwen3.5和Qwen3.8在每四层中的三层使用Gated DeltaNet线性注意力，Nemotron 3 Nano在52层中只有6层注意力层。只有全注意力层会随窗口增长。
以下数值根据各模型公开的配置计算，并非实测。运行时会增加计算缓冲区，缓存的实现也有差异，因此请用ollama ps确认实际占用。
量化KV缓存可以缩小它：根据Ollama文档，q8_0占用的内存约为f16的一半，q4_0约为四分之一，其中q4_0会带来小到中等程度的精度损失。
模型 | 下载 | 32K时KV | 128K时KV | 最大窗口时KV |
|---|---|---|---|---|
| Llama 3.1 8B | 4.9 GB | 4 GiB | 16 GiB | 16 GiB (128K) |
| Mistral Small 3.2 24B | 15 GB | 5 GiB | 20 GiB | 20 GiB (128K) |
| gpt-oss 20B | 14 GB | 0.8 GiB | 3 GiB | 3 GiB (128K) |
| Qwen3.5 4B | 3.3 GB | 1 GiB | 4 GiB | 8 GiB (256K) |
| Qwen3.5 9B | 6.6 GB | 1 GiB | 4 GiB | 8 GiB (256K) |
| Gemma 4 12B | 7.7 GB | 0.8 GiB | 2.3 GiB | 4.3 GiB (256K) |
| Gemma 4 26B-A4B | 16 GB | 0.8 GiB | 2.7 GiB | 5.2 GiB (256K) |
| Gemma 4 31B | 19 GB | 3.3 GiB | 10.8 GiB | 20.8 GiB (256K) |
| Qwen3.8 27B | 18 GB | 2 GiB | 8 GiB | 16 GiB (256K) |
| Qwen3.5 35B-A3B | 22 GB | 0.6 GiB | 2.5 GiB | 5 GiB (256K) |
| Qwen3 30B-A3B-2507 | 19 GB | 3 GiB | 12 GiB | 24 GiB (256K) |
| Nemotron 3 Nano 30B-A3B | 18 GB | 0.2 GiB | 0.8 GiB | 6 GiB (1M) |
哪个长上下文模型适合你的机器？
先按内存选择：所需上下文下的权重加KV缓存必须放得下，并为操作系统和运行时留出2到3 GB余量。 以下建议是根据上表算出的，不是质量排名；我们没有对长上下文准确率做基准测试。
- 8 GB： Qwen3.5 4B（下载3.3 GB）。KV缓存在32K时为1 GiB，64K时为2 GiB；128K需要4 GiB，在8 GB机器上比较紧张。
- 16 GB： Qwen3.5 9B（6.6 GB）加约4 GiB的KV缓存即可容纳128K。Gemma 4 12B（7.7 GB）加约4.3 GiB即可容纳完整的256K窗口。
- 24至32 GB： Gemma 4 26B-A4B（16 GB）在256K时约需5.2 GiB。Qwen3.8 27B（18 GB）在128K时约需8 GiB。gpt-oss 20B（14 GB）在其128K上限时约需3 GiB。
- 48 GB及以上： Gemma 4 31B（19 GB）在256K时约需21 GiB。Mistral Small 3.2 24B（15 GB）在128K时，f16缓存需要20 GiB，q8_0约需10 GiB。
- 1M token： 按配置计算，Nemotron 3 Nano 30B在18 GB下载之外，1M时还需要约6 GiB的KV缓存，因此仅凭内存并不能排除它在32 GB机器上运行。NVIDIA默认提供256K，并将H100和A100 GPU列为支持的硬件，Unsloth则警告1M时可能因内存不足而崩溃，所以请把它当作实验。Qwen表示，Qwen3-30B-A3B-Instruct-2507处理1M token大约需要240 GB GPU内存。
为什么实际可用上下文比标称最大值更短？
标称窗口是架构上限，不是质量保证。 Liu等人（2023）发现，当相关文本位于输入的开头或结尾时，语言模型回答最准确，位于中间时准确率较低，这就是“中间丢失”效应。
RULER（Hsieh等人，2024）测试了17个都标称32K token或更多的模型，只有约一半在32K时保持了令人满意的表现。NoLiMa（Modarressi等人，2025）测试了13个标称至少128K的模型，在32K时其中11个低于其短上下文得分的50%，GPT-4o从99.3%降到69.7%。
这些研究早于本指南中的大多数模型，请把它们当作这一规律的证据，而不是这里所列任何模型的得分。要自己验证某个模型，请把一个事实藏在长提示词的10%、50%和90%位置，换一种说法提问，并在32K、64K和128K下重复。
当准确率很重要时，请把关键指令和事实放在提示词的开头或结尾，只检索相关段落（见下面的RAG一节），或把长文档分成有重叠的片段处理。
如何在Ollama、LM Studio和llama.cpp中设置上下文长度？
Ollama根据你的VRAM选择默认上下文：低于24 GiB为4K token，24至48 GiB为32K，48 GiB及以上为256K。 超出当前上下文的输入会被截断，模型因此永远看不到长文档的开头。
你可以通过Ollama应用的滑块、环境变量OLLAMA_CONTEXT_LENGTH、ollama run中的/set parameter num_ctx、Modelfile或API的num_ctx选项来设置上下文。请用ollama ps确认结果。
在LM Studio中，打开My Models，点击模型的齿轮图标，设置上下文大小和Flash Attention。在llama.cpp中，-c设置上下文大小（0表示从模型加载），-fa控制Flash Attention，--cache-type-k和--cache-type-v用于量化KV缓存。
Ollama只有在启用Flash Attention时才会量化KV缓存，而且该设置对所有模型全局生效。OLLAMA_KV_CACHE_TYPE=q8_0占用的内存约为f16的一半，q4_0约为四分之一。
# 1. Check what a loaded model really uses (see the CONTEXT column)
ollama ps
# 2. Server-wide default (the Ollama app has a context slider instead)
OLLAMA_CONTEXT_LENGTH=65536 ollama serve
# 3. One interactive session
ollama run qwen3.5:9b
>>> /set parameter num_ctx 65536
# 4. A persistent custom model
cat << EOF > Modelfile
FROM qwen3.5:9b
PARAMETER num_ctx 131072
EOF
ollama create qwen3.5-9b-128k -f Modelfile
ollama run qwen3.5-9b-128k
# 5. Optional: shrink the KV cache (global setting, needs Flash Attention)
OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve
# llama.cpp equivalent
llama-server -m model.gguf -c 131072 -fa on --cache-type-k q8_0 --cache-type-v q8_0
非英文文档会占用更多上下文窗口吗？
可能会：Petrov等人（2023）发现，取决于分词器，同样的文本在一种语言中所需的token最多可达另一种语言的15倍。 日文、中文、韩文或阿拉伯文文本是否受影响，取决于模型的分词器。
不要用英文“每token约0.75个单词”的规则把页面换算成token。请用你打算使用的模型来计数：ollama run <model> --verbose会在回复后输出提示词的token数。
请按语言和模型系列分别规划窗口预算，因为不同模型系列的分词器各不相同。
处理文档时用长上下文还是RAG？
长上下文本地LLM的常见错误
- 相信默认上下文： 无论模型支持多少，Ollama在VRAM低于24 GiB时默认只有4K token，因此一份100页的文档在模型读到之前就被截断了。请明确设置上下文，并在ollama ps的CONTEXT列中确认。
- 按下载大小估算内存： KV缓存可能比权重还大。Llama 3.1 8B下载只有4.9 GB，但128K时需要约16 GiB的KV缓存。提高上下文之前，请先用公式或上表计算。
- 以为每个标签都有长窗口： 在Ollama模型库中，qwen3:14b列出40K，而qwen3:30b列出256K。规划之前，请先在模型页面查看上下文数值。
- 把标称窗口当作可用窗口： RULER和NoLiMa发现，许多标称128K或更高的模型在32K时准确率急剧下降。请在你打算使用的长度下，用自己的文档测试。
- 默认就用1M token： 预填充时间和内存随提示词增长，Unsloth警告Nemotron 3 Nano在1M时可能因内存不足而崩溃。1M只用于偶尔的任务，日常工作优先用RAG或分块。
- 未经测试就把KV缓存设为q4_0： Ollama文档说明q4_0会带来小到中等程度的精度损失，在更长的上下文中可能更明显，而且该设置对所有模型生效。请先从q8_0开始。
常见问题
2026年本地LLM能使用的最长上下文窗口是多少？
Llama 4 Scout列出10M token，但其模型卡在128K下报告基准测试，而且Ollama下载为67 GB。在能在一台普通机器上运行的模型中，NVIDIA Nemotron 3 Nano 30B-A3B支持1M token（默认配置为256K），Qwen3.8和Qwen3.5原生支持256K，通过YaRN最高可达约1M。长窗口是否可用，取决于内存，以及模型读取长输入的准确程度。
128K的上下文窗口还够用吗？
128K token约10万词，足够大多数单个文档。一本300页的书通常有7.5万到10万词，约100K到135K token，因此通常会超出128K窗口，或者几乎占满而没有余量留给问答。256K窗口可以容纳整本书和回答；再长就用RAG或分块。
1M token的上下文需要多少内存？
取决于架构。根据公开的配置，1M token时的f16 KV缓存在Qwen3.5 9B上约32 GiB，在Qwen3.8 27B上约64 GiB，在Nemotron 3 Nano 30B-A3B上约6 GiB，这还在权重之外。Qwen表示，Qwen3-30B-A3B-Instruct-2507处理1M token大约需要240 GB GPU内存。q8_0缓存可把KV数值减半，而读取1M token的提示词所需时间随长度增长，因此请把它留给偶尔的任务。
为什么上下文窗口相同的模型所需内存差别很大？
KV缓存随全注意力层数 × KV头数 × 头维度 × token数增长。Llama 3.1 8B每token需要128 KiB，Gemma 4 26B-A4B约20 KiB（30层中只有5层使用全注意力），Nemotron 3 Nano约6 KiB（52层中只有6层是注意力层）。滑动窗口层、线性注意力层和Mamba层保持固定大小的状态，而不是随窗口增长。
什么是KV缓存，如何让它变小？
KV缓存保存上下文中每个token的注意力键和值，使模型不必为每个新token重新计算。它在权重之外另行分配，并随上下文长度增长。要缩小它，可以降低num_ctx，启用Flash Attention并把OLLAMA_KV_CACHE_TYPE设为q8_0（约为f16内存的一半）或q4_0（约四分之一，长上下文下精度损失更大），或者选择每token缓存更小的模型。在Ollama中，缓存类型是全局的，对所有模型生效。
为什么我的本地模型会忘记文档的开头？
最可能是当前生效的上下文比你的文档小。无论模型支持多少，Ollama在VRAM低于24 GiB的GPU上默认4K token，24至48 GiB为32K，48 GiB及以上为256K，超出上下文的输入会被截断。请检查ollama ps的CONTEXT列，并通过OLLAMA_CONTEXT_LENGTH、/set parameter num_ctx、Modelfile或API的num_ctx选项提高它。
如何在Ollama中设置128K上下文？
创建包含FROM qwen3.5:9b和PARAMETER num_ctx 131072的Modelfile，运行ollama create qwen3.5-9b-128k -f Modelfile，然后ollama run qwen3.5-9b-128k，并用ollama ps验证。也可以用OLLAMA_CONTEXT_LENGTH=131072 ollama serve启动服务器。请先确认权重加KV缓存能放进内存；对Qwen3.5 9B来说，约为6.6 GB加4 GiB。
上下文越长，本地LLM会越慢吗？
会。模型必须先读完整个提示词（预填充）才能写出第一个token，因此首个token的等待时间随提示词长度增长，而且对更大缓存做注意力计算也会降低生成速度。线性注意力层和Mamba层会减缓这种增长，但不会消除。请在你的硬件上用ollama run <model> --verbose测量，它会输出提示词评估和生成的速率。
什么是“中间丢失”问题，它现在还适用吗？
Liu等人（2023）发现，当相关文本位于输入的开头或结尾时，语言模型回答最准确，位于中间时准确率较低。RULER（2024）和NoLiMa（2025）随后表明，许多标称32K到128K窗口的模型在远未达到上限时就已经丢失准确率。这些研究测试的是较早的模型，因此请自己验证：把一个事实藏在长提示词的10%、50%和90%位置并提问。把关键指令放在开头或结尾，或只检索相关段落。
回答文档问题时，长上下文和RAG哪个更好？
当答案只在大型集合的少数段落中时，RAG通常更省内存、更省时间，因为它把提示词控制在几千token。当模型必须对单个完整文档做推理时，长上下文更好，例如合同、代码库或书籍章节，分块会切断其中的交叉引用。许多方案两者结合，把检索到的整段章节放入32K到128K的窗口。
我能用本地LLM总结一整本书吗？
一本300页的书约100K到135K token，因此可以放进256K窗口（Qwen3.5、Qwen3.8、Gemma 4的12B及以上），但把摘要计算在内后，可能放不进128K窗口。如果用128K模型或内存较少，请逐章总结，再总结这些摘要。请明确设置num_ctx，让整本书都在当前上下文中。
非英文文档会占用更多上下文窗口吗？
可能会。Petrov等人（2023）发现，取决于分词器，同样的文本在一种语言中所需的token最多可达另一种语言的15倍。请用你的模型来计算token，而不是使用英文“每token约0.75个单词”的规则：ollama run <model> --verbose会输出提示词的token数。
哪些长上下文模型能在16 GB的机器上运行？
按内存计算，Qwen3.5 9B（下载6.6 GB，128K时再加约4 GiB KV缓存）和Gemma 4 12B（7.7 GB，完整256K窗口时再加约4.3 GiB）都能放进16 GB并留出几GB余量。这些是根据公开配置算出的，并非实测；请用ollama ps确认。
来源
- Ollama. (2026). "Context length" documentation. docs.ollama.com -- 按VRAM档位划分的默认上下文、OLLAMA_CONTEXT_LENGTH、智能体建议64,000 token。
- Ollama. (2026). "FAQ". docs.ollama.com -- /set parameter num_ctx、OLLAMA_FLASH_ATTENTION、OLLAMA_KV_CACHE_TYPE（f16、q8_0、q4_0）。
- Ollama. (2026). "qwen3.8" library page. ollama.com -- 27B，18 GB，256K上下文。
- Ollama. (2026). "qwen3.5" library page. ollama.com -- 0.8B至122B标签，256K上下文。
- Ollama. (2026). "qwen3" library page. ollama.com -- 8B/14B/32B为40K，4B/30B为256K。
- Ollama. (2026). "gemma4" library page. ollama.com -- E2B/E4B为128K，12B/26B/31B为256K。
- Ollama. (2026). "nemotron-3-nano" library page. ollama.com -- 30B标签列出1M上下文，18 GB。
- Ollama. (2026). "llama4" library page. ollama.com -- Scout 67 GB和10M，Maverick 245 GB和1M。
- Ollama. (2026). "mistral-small3.2"、"gpt-oss"和"llama3.1" library pages. ollama.com -- 128K窗口，下载15 GB、14 GB和4.9 GB。
- Qwen Team. (2026). "Qwen3.8-27B" model card. huggingface.co -- 原生262,144，YaRN最高1,000,000，Apache-2.0。
- Qwen Team. (2026). "Qwen3.5-9B" model card. huggingface.co -- 原生262,144，YaRN最高1,010,000；Gated DeltaNet混合布局。
- Qwen Team. (2025). "Qwen3-30B-A3B-Instruct-2507" model card. huggingface.co -- 原生262,144，Dual Chunk Attention可达1M，约240 GB GPU内存。
- Google. (2026). "Gemma 4 31B" model card. huggingface.co -- E2B/E4B为128K，较大尺寸为256K。
- NVIDIA. (2025). "NVIDIA-Nemotron-3-Nano-30B-A3B-BF16" model card. huggingface.co -- 23层Mamba-2和MoE加6层注意力层，支持1M，默认256K。
- Meta. (2025). "Llama-4-Scout-17B-16E-Instruct" model card. huggingface.co -- 总参数109B，列出10M，长上下文基准测试在128K。
- Unsloth. (2026). "NVIDIA Nemotron 3 Nano -- How To Run Guide". unsloth.ai -- 1M上下文可能耗尽内存，默认262,144。
- Liu et al. (2023). "Lost in the Middle: How Language Models Use Long Contexts". arxiv.org -- 输入开头和结尾的准确率最高。
- Hsieh et al. (2024). "RULER: What's the Real Context Size of Your Long-Context Language Models?". arxiv.org -- 17个标称32K以上的模型中，只有约一半在32K时仍令人满意。
- Modarressi et al. (2025). "NoLiMa: Long-Context Evaluation Beyond Literal Matching". arxiv.org -- 13个模型中有11个在32K时低于短上下文得分的50%。
- Petrov et al. (2023). "Language Model Tokenizers Introduce Unfairness Between Languages". arxiv.org -- 同一文本最多相差15倍token。
- llama.cpp. "llama-server" README. github.com -- --ctx-size、--flash-attn、--cache-type-k、--cache-type-v。
- LM Studio. "Per-model default parameters". lmstudio.ai -- 按模型设置上下文大小和Flash Attention。
- 本指南中的KV缓存大小根据Hugging Face上各模型仓库的config.json（层数、KV头数、头维度、注意力层类型）计算得出，并非实测。