Responses API silently truncates oversized input with truncation disabled (0.40.13 and 0.40.14, Bonsai 27B)

快速结论：该问题出现在使用 Ollama 的 Responses API（/v1/responses）提交超长输入、并显式设置 truncation: "disabled" 时：输入仍被服务端静默截断，接口返回 HTTP 200 和 completed，而不是报上下文溢出错误。优先排查请求中的 truncation 是否真正传入底层 chat 请求，以及实际分配的运行上下文是否小于输入长度。

适用环境：Windows；Ollama 0.40.13 与官方便携版 0.40.14（API 版本已确认，归档 SHA256 已校验）；模型 bonsai-2:27b-q2_0（digest f3c4f42086593225d8be9bb4270658d0e05f5232fb2b5e8faa49ef74d2cc843a）。Issue 未提供 Python、CUDA、GPU/CPU 型号信息。

最快修复方案：暂无确认的一步修复方案。Issue 已关闭，但讨论链中没有给出经验证可消除该行为的版本或配置。

注意事项：该行为影响 0.40.13 和 0.40.14；发帖者反馈 0.34.0 未复现，但在 0.34.0 与 0.40.14 之间的版本中均能复现，因此不能把“降级到某个中间版本”当作已确认的规避手段。基于源码的推断（truncation 未被转发、Truncate 缺省为 true）属于可能原因，尚未见官方确认或修复。

问题场景

用户在 Windows 上运行 Ollama 0.40.13，并用官方便携版 0.40.14 独立复现。请求在隔离服务中把运行时上下文设为 512（实际分配上下文报告为 2048），然后向 /v1/responses 发送：模型 bonsai-2:27b-q2_0、stream: false、max_output_tokens: 1、think: false、truncation: "disabled"，输入为一段固定填充文本重复 2048 次。期望得到明确的输入/上下文溢出错误，实际却从被静默缩短的输入中正常作答。0.40.14 的请求与之前逐字节相同。

报错原文

msg="truncating input prompt" limit=1026 prompt=6166 keep=4 new=1026
HTTP 200; status=completed; error=null; output=READY; truncation=disabled; usage.input_tokens=1026

原因分析

最可能的原因：在 v0.40.14 中，FromResponsesRequest 似乎没有把 truncation 转发到 api.ChatRequest；Responses 中间件设置 Stream 并编码该 chat 请求时未附加 Truncate 字段，而 handleNativeChat 对缺失的 Truncate 默认为 true，于是触发输入截断（日志中 6166 个输入 token 被缩短为 1026）。这导致请求虽标注 truncation: disabled，服务端仍执行截断并返回 200。该结论来自报告者的源码检查，官方尚未确认。

另一个相关因素：实际分配的运行时上下文（报告为 2048）与请求的 512 不一致，可能影响溢出判断和客户端提前压缩的时机。报告者询问生成式桌面模型目录能否反映实际分配上下文而非架构上限，Issue 讨论链中未见答复或结论。

环境排查

确认 Ollama 版本：0.40.13 与 0.40.14 均已复现；若使用其他版本，记录是否复现。
确认模型及 digest：bonsai-2:27b-q2_0，digest f3c4f42086593225d8be9bb4270658d0e05f5232fb2b5e8faa49ef74d2cc843a。
确认服务端实际分配的运行时上下文（该案例请求 512，实际报告 2048）。
确认请求参数：truncation 是否为 "disabled"，stream、max_output_tokens、think 是否与复现请求一致。
检查服务端日志中是否出现 truncating input prompt 及 limit/prompt 数值。
Issue 未提供 Python、CUDA、PyTorch、GPU 信息，无需据此排查。

解决步骤

在服务端日志中确认是否出现 truncating input prompt，并核对 prompt 与 limit 的数值，判断输入是否被截断。
对比响应中的 usage.input_tokens 与原始输入 token 数：若前者明显偏小且响应仍为 200/completed，即可确认命中该行为。
在客户端自行做输入长度校验或提前压缩，使输入 token 数低于实际分配上下文，避免依赖服务端溢出报错。可优先尝试，但 Issue 未验证其效果。
若需要该行为被修复，关注对应 GitHub Issue 及后续版本变更；讨论链中仅有认领意向，没有已验证的补丁或版本。
不要仅依赖更换 0.34.0–0.40.14 之间的版本作为规避，报告者反馈该区间内的版本均能复现。

验证方法

用与复现相同的合成输入重新请求 /v1/responses，检查三点：服务端日志不再出现 truncating input prompt；响应中 usage.input_tokens 与原始输入 token 数一致；超长输入时返回明确的上下文溢出错误而非 HTTP 200 completed。在官方修复出现前，这三项可能仍无法同时满足。