本文摘要大模型回答总在 4096 处截断改了num_ctx却不生效。用curl对照请求定位参数覆盖层级追查谁在覆盖它。一、问题与结论环境是个人工作站上ollama serve默认端口11434加一个 Open WebUI 前端跑qwen2.5:7b这类 GGUF 量化模型。让模型写长文回答总在约 4096 token 处停住不报错、不提示。你已在Modelfile里写了PARAMETER num_ctx 8192并用ollama create重建ollama show也能看到这一行但走 Open WebUI 对话仍被截断。结论先给三条num_ctx有三层生效位置请求级optionsModelfilePARAMETER 内置默认值。改Modelfile只改了中间层任何一端传了请求级参数都会盖掉它。先分清上下文不够和生成长度不够。后者由num_predict卡住此时调num_ctx不会有任何变化。截断是静默的只有响应里的done_reason、eval_count能佐证到底卡在哪一层。二、排查与选择依据结论按单请求对照 → 单入口对照 → 跨入口对照三层推进每层只变一个变量。第一步确认模型里到底有没有num_ctxollama show qwen2.5:8k--modelfile看输出里有没有PARAMETER num_ctx 8192。没有说明用的是内置默认值有进入第二步。第二步同模型、同提示词只变optionscurl-shttp://localhost:11434/api/generate-d{ model: qwen2.5:8k, prompt: 写一篇约3000字的技术短文主题是GPU显存管理, stream: false }|jq{eval_count, done_reason}再发一次请求体里加options: {num_ctx: 8192}同样取eval_count与done_reason对照两次都截断且done_reason为length先查num_predict这不是num_ctx的问题。默认请求截断、带options的不截断Modelfile层没被应用或某处用请求级参数覆盖了它。第三步跨入口对照把第二步的请求原样通过 Open WebUI 发一次。若 curl 不截断而 Open WebUI 截断问题在前端请求体。用OLLAMA_DEBUG1 ollama serve重启服务观察它实际收到的 JSON重点看options字段和model名是否与重建后的模型一致。同时确认 Open WebUI 是否提供了会话参数设置入口——它可能按请求塞入了自己的上下文或生成长度配置。替代方案与取舍做法选择条件代价边界本文路径分层对照定位参数覆盖单机、多入口curl/ Open WebUI混用需逐层发请求排查耗时多实例、多卡调度问题不适用绕过前端直接调 API程序化调用、批量任务要精确控参放弃现成对话界面需自建或写脚本不解决前端体验需求改num_predict而非num_ctxdone_reason明确为length无法扩大可容纳的输入输入本身超长时不解决问题不该用本文方案的情形截断点与 token 计数无关如前端主动终止流、或问题发生在模型 chat template 层面——这两类即使把num_ctx调大也不会有变化。三、关键原理参数覆盖是一条单向优先链API 请求options覆盖ModelfilePARAMETER后者覆盖内置默认值。因此改了没用通常不是参数写错而是改错了层级——中间层被更高层覆盖或中间层压根没被加载。代价在于显存。num_ctx直接决定 KV cache 的槽位数量KV cache 随上下文长度近似线性增长层数、KV 头数越多单份 cache 越大。把 4096 提到 8192等于给同一份模型多留一倍的 cache 空间多模型并发拉起时这部分会先撞显存上限触发 Ollama 把旧模型挤出。ollamapsnvidia-smi --query-gpumemory.used,memory.total--formatcsv,noheaderollama ps的 CONTEXT 列应显示新值以下输出为未验证示例实际数值取决于模型与硬件NAME PROCESSOR CONTEXT UNTIL qwen2.5:8k 100% GPU 8192 4 minutes from now若 CONTEXT 仍是 4096说明当前驻留的是旧模型版本若nvidia-smi显示显存吃紧说明 8192 在这张卡上已经接近可用上限。四、可运行示例环境Linux NVIDIA 单卡Ollama 已安装并能ollama pull qwen2.5:7b默认监听11434。catModelfileEOF FROM qwen2.5:7b PARAMETER num_ctx 8192 EOFollama create qwen2.5:8k-fModelfile ollama show qwen2.5:8k--modelfile预期输出Modelfile段落中出现PARAMETER num_ctx 8192。随后发两条对照请求不带 / 带options.num_ctx取eval_count与done_reason。预期输出带options的那条eval_count明显更高且done_reason为stop。实际输出本文未在真实环境执行两组数值与截断位置均标为未验证需按第二节的判定规则自行读数。常见失败及修复ollama create后仍按旧名qwen2.5:7b调用拿到的还是默认参数——用ollama list确认新模型名并改调用侧Open WebUI 模型列表是缓存的刷新或重启服务后再试。五、验证结果与边界判据只看两个字段done_reason为length说明是生成上限为stop说明模型自己收尾两者都不是就去看eval_count是否已达num_ctx上限。ollama ps的 CONTEXT 列与请求里的options一致是参数真的进了服务的第一手证据。边界要说清num_ctx调大换的是更长的可容纳输入与输出付出的是显存和首 token 延迟多模型并发场景下更容易把别的模型挤下卡。以下情形不建议沿用这条路径——任务本身可以分段处理拆成多次短调用更省显存、需要高吞吐批处理该换专门的推理服务端、或前端已固化了参数下发逻辑且无法修改此时应去前端侧配置而不是在 Ollama 里反复改。参考资料ollama/ollama (GitHub)open-webui/open-webui (GitHub)