top_logprobs is capped at 20, but nothing downstream requires that

快速结论：当你在 Ollama 中通过 top_logprobs 请求超过 20 个候选 token 时，请求会在进入后端前被 Ollama 自己的请求校验拦截，报错信息为 top_logprobs is capped at 20, but nothing downstream requires that。优先确认你请求的数值是否超过当前上限 20，以及该上限是否仍是当前版本行为。

适用环境：Issue 中确认的工具为 Ollama；涉及 server/routes.go 的请求校验、llama.cpp 后端（llm/llama_server.go）以及原生 MLX/CUDA runner 的采样器（mlxrunner/sample/sample.go）。Issue 未提供具体的操作系统、Python、CUDA、显卡或依赖版本信息。

最快修复方案：暂无确认的一步修复方案。Issue 讨论的改动（将上限从 20 提高到 100）并未被合并，Issue 最终以关闭结束，维护者转向客户端侧的“深度拆分”方案。

注意事项：即使把上限提高，对大规模候选集合的帮助也有限：Issue 作者实测在 30 类分类场景下，上限从 20 提到 100 仅能多召回 7 个类别（从 5/30 到 12/30），排名 90+ 的类别 logprob 约 -13，本身已属于低概率项。因此不要把这个上限当成能覆盖任意类别数量的方案。

问题场景

在 Ollama 中使用 top_logprobs 请求模型的候选 token 及其概率时，客户端请求的 top_logprobs 数值超过 20，被 Ollama 服务端在请求校验阶段直接拒绝，请求无法到达后端。该问题在路由/分类类工具中容易触发：这类工具需要读取一小组候选答案（例如 access_denied、access_expired、access_revoked）各自的概率，但候选 token 可能排在 20 名之外，导致概率完全取不到。Issue 作者在 qwen3.5:4b 上验证时，使用当时的最大值 top_logprobs: 20 有时会完全漏掉三个候选之一，仅仅因为该 token 在该位置排在第 21 名或更后。

报错原文

top_logprobs is capped at 20, but nothing downstream requires that

原因分析

最可能的原因是 Ollama 在 server/routes.go 中自行加入了 > 20 的请求校验，涉及四个调用点：GenerateHandler、ChatHandler 以及它们对应的 OpenAI 兼容接口。这个上限是 Ollama 自身的选择，并非来自后端限制：Issue 作者核查后指出，llama.cpp 的 n_probs 字段（对应 llm/llama_server.go 中的 TopLogprobs）本身没有上限，是 softmax 输出的普通切片；原生 MLX/CUDA runner 的采样器 mlxrunner/sample/sample.go 也把 TopLogprobs 当作一个没有上界逻辑的普通 int 使用，直接作为 k 参与对整个词表的 argpartition。Issue 作者还构建了一个把校验放宽到 100 的服务端进行实测：请求 21（此前会被拒绝）返回 21 个真实候选；请求 100 返回恰好 100 个且顺序正确；请求 101 仍被拒绝；过程中未观察到后端报错或性能下降。

环境排查

确认当前 Ollama 版本中 server/routes.go 的 top_logprobs 校验上限是多少，是否仍为 20 或已发生变化。
确认请求走的是 GenerateHandler、ChatHandler 还是 OpenAI 兼容接口，四个调用点都可能触发该校验。
确认你使用的后端类型（llama.cpp 或原生 MLX/CUDA runner），以便判断限制来源是否只在 Ollama 服务端。
确认客户端实际发送的 top_logprobs 数值，以及是否可能被客户端库或封装层改写。
Issue 未提供操作系统、Python、CUDA、显卡型号或依赖版本，这些项目无法据此排查。

解决步骤

先确认报错是否由请求数值超过 20 引起：把客户端的 top_logprobs 降到 20 或以下再发请求，看是否不再被服务端拒绝。这能确认是校验拦截而非后端或模型问题。
检查你所用 Ollama 版本的 server/routes.go，确认 > 20 校验是否仍然存在于 GenerateHandler、ChatHandler 及两个 OpenAI 兼容调用点。若仍存在，说明该限制尚未被上游改动。
如果瓶颈在于候选 token 排在 20 名之外，可优先尝试在客户端侧改用“深度拆分”思路：把一个大而扁平的选择集拆成多轮更窄的分类，而不是依赖单次请求返回更多候选。这是 Issue 关闭时维护者选择的替代方向。
不建议直接依赖社区分支或自行放宽上限作为长期方案：Issue 中提到的改动（raise-top-logprobs-cap 分支，4 个文件约 17 行，把上限提到 100）并未合入，Issue 以关闭结束。

验证方法

确认问题是否已解决，可观察两点：一是把 top_logprobs 降到 20 以内后，上一版会触发 top_logprobs is capped at 20 的请求是否恢复正常返回；二是若你按客户端深度拆分方案改造了调用逻辑，检查原先取不到概率的候选 token（例如排在 21 名之外的那个类别）是否能在拆分后的某一轮里正常落到前 20 并被读到。若两者都仍失败，说明问题不在该上限或不在你的调用结构上。