先看现象。在请求里传 options.num_ctx 为 8192，长文档依旧在 2000 字左右被截断，ollama ps 里显示的上下文还是 2048，模型是 qwen2.5:7b。
把日志和配置对完，能解释这个现象的基本就这几处。部分版本只认 Modelfile 里的 num_ctx。还有一种是请求参数层级写错，被当成未知字段忽略。
还有一种情况，显存不足时自动回落到更小的上下文。
另外，客户端把 options 放进了 metadata 而不是顶层。
先用 API 直接传参并观察返回
curl -s http://127.0.0.1:11434/api/generate -d '{"model":"qwen2.5:7b","prompt":"hi","options":{"num_ctx":8192}}' | jq '.context | length'接着查看运行中模型的参数
ollama ps然后在 Modelfile 里固定上下文并重建
ollama create qwen2.5-8k -f Modelfile等前面都确认过，再用长文本验证是否还被截断
python -c "print('x'*12000)" | ollama run qwen2.5-8k "统计字符数"隔了一天再看，现象没变，说明不是偶发。
那几天正好在做别的变更，先把时间线对齐才敢动手。
改完先别撤，确认这几项。ollama ps 里上下文显示 8192，长文本不再被截断，首字延迟增加但在可接受范围。
这里还有个坑。上下文调大直接吃显存，7B 模型给 8k 通常没事，再往上要同时看显存余量。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。