本文摘要Ollama 默认num_ctx为 4096长文档超窗部分被静默截断后半段无法引用。对比prompt_eval_count与预期 token 数即可发现截断显式调大窗口即可修复。一、问题与结论可复现环境Ollama 0.11.4 模型llama3.2ollama show llama3.2 → context length 131072 接口POST http://localhost:11434/api/generate现象50 页、约 11000 token 的工程规范 PDF问第 3 章前 10 页能准确引用条款号问第 7 章后 40 页回答文档中未提及或给出无关条款。接口返回done: true中间层与前端均未提示输入被丢弃。根因num_ctx默认 4096超出部分被静默截断后返回体没有truncated之类的告警字段模型基于残缺上下文作答。二、排查与选择依据判断是否截断只看一个字段prompt_eval_count——模型实际处理的输入 token 数。# 1. 估算完整 prompt 的 token 数用 Ollama 自带的分词接口curl-shttp://localhost:11434/api/tokenize\-d{model:llama3.2,prompt:$(catlong_doc.txt)} \ | python3 -c import json,sys; print(tokens, len(json.load(sys.stdin)[tokens])) # 2. 默认参数发请求 curl -s http://localhost:11434/api/generate \ -d {model:llama3.2,prompt:$(catlong_doc.txt) 第7章的验收标准是什么,stream:false}预期输出tokens约 11000响应中prompt_eval_count接近 4096。实际输出tokens 11004 prompt_eval_count 4096 done true response 文档中未提及该章节的验收标准。prompt_eval_count精确停在 4096done仍为true——这就是静默截断。4096 11004差值 6908 token 全部丢失正好覆盖文档后 60%。常见失败及修复把num_ctx设到 32768 后若prompt_eval_count仍停在 4096原因是请求体options拼写错误或被中间层丢弃或环境变量OLLAMA_CONTEXT_LENGTH未生效——修复方法是确认 JSON 中options.num_ctx存在或重启 Ollama 时带上OLLAMA_CONTEXT_LENGTH32768。替代方案与取舍方案选择条件代价边界本方案调大num_ctx单机、文档 ≤ 数万 tokenKV cache 随窗口线性增长挤占显存不得超过模型自身窗口RAG 分块 top-k 检索文档远超窗口、多文档知识库需维护分块与召回可能漏检后半段答案依赖召回质量换长上下文原生模型单文档必须整段入窗重新 pull 模型推理显存与延迟上升仍受显存与模型上限约束Open WebUI 前端的 context 设置非开发者、轻量对话与 Ollama 侧num_ctx是两套独立配置取两者较小值界面调高不等于服务端生效不该用本方案的情况文档量大到需要跨文档检索或显存不足以支撑目标窗口——此时应走 RAG 分块而不是硬拉num_ctx。三、关键原理KV cache 是每个 token 的 K/V 张量缓存占用 ≈ 层数 × 注意力头数 × 头维度 × 2 × 每 token 字节数 ×num_ctx。层数与头维度由模型架构固定因此占用与num_ctx近似线性。窗口翻 8 倍cache 也接近翻 8 倍这部分显存从模型权重和生成批次里扣。截断发生在 prompt 评估阶段Ollama 按num_ctx截取输入尾部丢弃再进入预填充——后半段文档从未参与注意力计算模型自然没见过。四、可运行示例环境本地已启动 Ollama默认端口11434已 pullllama3.2准备一份long_doc.txt约 11000 token 的测试文档。MODELllama3.2PROMPT$(catlong_doc.txt)第7章的验收标准是什么run(){curl-shttp://localhost:11434/api/generate\-d{\model\:\$MODEL\,\prompt\:\$PROMPT\,\stream\:false,\\options\:{\num_ctx\:$1,\num_predict\:256}}\|python3-cimport json,sys; rjson.load(sys.stdin); \ print(num_ctx$1prompt_eval_count , r[prompt_eval_count], \ answer , r[response][:80])}run4096run32768num_predict限制生成长度避免大窗口下输出失控变慢。预期输出两次prompt_eval_count分别为 4096 与 11004第二次能引用第 7 章原文。实际输出num_ctx4096 prompt_eval_count 4096 answer 文档中未提及该章节的验收标准。 num_ctx32768 prompt_eval_count 11004 answer 第7.2条规定验收需在到货后15个工作日内...五、验证结果与边界覆盖范围验证按文档章节顺序逐章提问统计能准确引用原文的章节数。num_ctx4096时可答章节止于约第 3 章num_ctx32768时全部章节可答。两者差异来自窗口而非模型能力。显存增量窗口从 4096 提到 32768KV cache 增量 ≈ 8 倍的每 token 占用。具体 MB 数未在本机实测标注为未验证建议用nvidia-smi或ollama ps在切换前后各采样一次。按显存分档的参数建议可用显存num_ctxnum_predict说明≤ 6 GB4096–8192512配合 RAG 分块别硬拉窗口8–12 GB16384512单文档长问答的常用档≥ 16 GB32768256整段入窗注意生成延迟边界num_ctx超过模型自身窗口会引发推理异常本节数值仅在llama3.2 Ollama 0.11.4 下验证其他模型未验证。参考资料ollama/ollamaopen-webui/open-webui