num_ctx prompt truncation limit is silently half the configured value (num_ctx/2 + 2), gpt-oss:20b, unrelated to num_parallel/num_predict

快速结论：在 Ollama 0.32.x 上处理长提示词时，一旦提示词超过完整 num_ctx，实际可用上下文会被静默截断为 num_ctx/2 + 2，而不是保留整个窗口。优先排查 num_ctx 设置与实际触发截断时的日志 limit= 值。

适用环境：Ollama 0.32.1 和 0.32.5；Ubuntu 24.04 与 Windows；NVIDIA RTX 5060 Ti 与 RTX 3070；模型 gpt-oss:20b 和 qwen2.5:7b；OLLAMA_NUM_PARALLEL=1 已确认。注意：该问题在 Ollama 0.13.5 中不存在，可能为 0.32.x 回归。

最快修复方案：暂无确认的一步修复方案。最直接的规避方式是确保输入提示词不超过完整 num_ctx；需要长上下文时，将 num_ctx 设置为提示词长度的 2 倍以上。

注意事项：该问题由 llama_server.go:314 的截断逻辑导致，无法通过调整 num_predict 或 num_parallel 解决；截断发生时系统提示词会被静默丢弃，即使 done_reason 返回 stop 且 truncated 为 0。

问题场景

用户在 Ollama 0.32.1/0.32.5 上运行长上下文任务（如文档处理、多轮对话），配置了较大的 num_ctx（如 65536），但当输入提示词超过完整 num_ctx 时，服务端日志出现 truncating input prompt 警告，实际处理 token 数仅为配置值的一半。该行为与 num_parallel、num_predict 无关，已通过 qwen2.5:7b 和 gpt-oss:20b 复现。

报错原文

WARN llama_server.go:314 msg="truncating input prompt" limit=32770 prompt=98005 keep=4 new=32770

其中 limit=32770 为 65536/2 + 2；无论原始提示词大小（98005 到 275710 token），截断后的 new 值恒等于 num_ctx/2 + 2。

原因分析

可能原因：Ollama 0.32.x 的 llama_server.go 在提示词超过完整上下文窗口时，使用 num_ctx/2 + 2 作为截断目标，而非文档描述的“截断至完整窗口”。该截断行为发生在引擎层之上（llama_server.go:314），且从提示词开头截断（keep=4），导致系统提示词被静默丢弃。经过验证，截断仅在提示词超过完整 num_ctx 时触发，而非超过 num_ctx/2——一旦触发即为断崖式丢失，例如 4097 token 提示词在 4096 窗口下损失 2047 token 而非 1 token。

环境排查

确认 Ollama 版本：0.32.x 有此问题，0.13.5 正常（参考日志显示 limit=4096 全窗口截断）。
确认 OLLAMA_NUM_PARALLEL=1（已验证不影响截断逻辑）。
通过 ollama ps 确认 CONTEXT 显示值为完整 num_ctx（如 65536），但截断日志显示 limit=32770。
检查服务器日志 journalctl -u ollama 或 Windows 事件日志，确认是否存在 truncating input prompt。

解决步骤

检查提示词长度：用 check 工具或 ollama run --verbose 统计 prompt eval count，确认是否已接近或超过 num_ctx。
若提示词超过 num_ctx，将 num_ctx 设置为实际需要量的 2 倍以上（例如需要 30000 token，设置 num_ctx 为 65536）。可优先尝试此方案，已验证提示词在 n/2 到 n 之间可完整处理。
如需保留系统提示词：将关键指令移到用户消息末尾（已验证截断后尾部指令仍被遵循），或拆分提示词发送。
检查响应中的 done_reason：即使截断发生也可能返回 stop 且 truncated=0，需结合服务端日志确认。
若无法接受此行为，可尝试降级至 0.13.5 或关注后续版本修复。

验证方法

运行长提示词任务后，检查服务端日志：若 limit= 值为 num_ctx 而非 num_ctx/2 + 2，则问题已解决；若仍是半数，则需继续等待官方修复。可通过 ollama ps 确认 CONTEXT 值，再用 --verbose 对比 prompt eval count 是否与预期匹配（预期匹配：提示词在 n/2 到 n 之间时，prompt eval count 应等于完整提示词 token 数）。