`/v1/chat/completions` forces `top_p: 1.0` when omitted, silently overriding Modelfile `PARAMETER top_p`

快速结论：当你的请求走 OpenAI 兼容端点 /v1/chat/completions 且没有显式传入 top_p 时，Ollama 会向请求选项注入硬编码的 top_p: 1.0，并在下游覆盖 Modelfile 里设置的 PARAMETER top_p。优先排查请求是否真的没有传 top_p，以及 Modelfile 里的采样参数是否被该回退值覆盖。

适用环境：Ollama 0.34.4（Linux，CPU），使用 OLLAMA_DEBUG=1 观察 llama-server runner 日志中的 sampler params；Issue 中涉及的模型包括 qwen3、qwen3.5、qwen3-coder、deepseek-r1、gemma3/4、magistral、gpt-oss。

最快修复方案：暂无确认的一步修复方案。Issue 中给出的修复方向是移除 openai/openai.go 中 FromChatRequest 和 FromCompleteRequest 里 temperature/top_p 的 else 回退分支，并在 completions 端仅对非零 penalties 写入；评论作者称其自建 0.34.4 验证有效，但对应上游 PR 在所述时点尚未合入。

注意事项：该问题是平台层的参数覆盖行为，不是模型文件语法错误，单纯改了 Modelfile 后走 OpenAI 端点仍无效。若在请求中显式传入 top_p，可覆盖该注入值，但那样就不是“保持 Modelfile 默认”的用法。自建二进制属于非官方修改，升级后可能被覆盖，建议先备份并记录原始版本。

问题场景

用户在 Ollama 中创建了一个带 PARAMETER top_p 0.5 的 Modelfile 模型，然后通过 OpenAI 兼容接口 /v1/chat/completions 调用该模型，请求里不传 top_p。结果模型实际用 top_p=1.0 采样，Modelfile 中的 0.5 被静默忽略；同一请求改走 /api/chat 时则能正确使用 0.5。评论还指出同类问题同样影响 temperature，以及 /v1/completions 上的 top_p 和 penalties。

报错原文

/v1/chat/completions forces `top_p: 1.0` when omitted, silently overriding Modelfile `PARAMETER top_p`

原因分析

最可能的原因是 OpenAI 兼容层在转换请求时，对缺省的 top_p 写入了固定回退值：

if r.TopP != nil {
	options["top_p"] = *r.TopP
} else {
	options["top_p"] = 1.0
}

下游 server/routes.go 的 modelOptionsWithEmbeddingBatchDefault 先应用模型自身选项、再应用请求选项，因此请求选项中的 1.0 最终胜出，Modelfile 里的 PARAMETER top_p 被覆盖。Issue 指出这与 #17744（temperature 同类问题）属于同一类缺陷，#17763 只移除了 temperature 回退，top_p 回退仍然保留。评论进一步说明，该 temperature 回退在 0.34.4 中同样存在，且 /v1/completions 的 top_p、penalties 回退也需要一并处理。

环境排查

确认 Ollama 版本：评论中的复现基于 0.34.4；其他版本是否包含相同回退行为需以实际代码为准。
确认操作系统与运行后端：评论复现环境为 Linux、CPU；GPU 后端未在该 Issue 中验证。
确认请求端点：对比同一模型在 /api/chat 与 /v1/chat/completions 下的采样参数是否一致。
确认 Modelfile：检查是否设置了 PARAMETER top_p，以及是否还包含 temperature、presence/frequency penalty 等参数。
开启 OLLAMA_DEBUG=1，查看 llama-server runner 为每个请求打印的 sampler params 块。
确认客户端是否隐式发送参数：OpenAI SDK 客户端在未设置 temperature/top_p 时，实际请求体中可能不包含这些字段，从而触发回退。

解决步骤

先用最小请求复现：创建带 PARAMETER top_p 0.5 的模型，分别向 /api/chat 和 /v1/chat/completions 发送不包含 top_p 的请求。
开启 OLLAMA_DEBUG=1 后重发请求，读取 runner 日志中的 sampler params 块，记录两种端点各自的 temp 与 top_p 值。
若确认 /v1/chat/completions 显示 top_p=1.0 而 /api/chat 显示 Modelfile 中的值，说明命中了本 Issue 的回退覆盖。
临时绕行（可优先尝试）：在 OpenAI 请求中显式传入与 Modelfile 一致的 top_p（以及需要保持的 temperature、penalties），避免触发回退注入；这是绕过而非修复。
如需根治，按评论思路修改源码：移除 FromChatRequest 与 FromCompleteRequest 中 temperature、top_p 的 else 回退分支，并让 completions 端的 penalties 仅在非零时写入；然后重新构建 Ollama。
跟踪上游修复：关注 #17763、#18691、#18694 的合并状态，并注意评论指出的缺口——FromCompleteRequest 中 options["temperature"] = 1.0 未被上述 PR 覆盖，/v1/completions 仍会覆盖模型 temperature。

验证方法

再次以 OLLAMA_DEBUG=1 运行，对比同一模型在 /api/chat 与 /v1/chat/completions（以及 /v1/completions）下的 sampler params：应用修改后，两个端点的 temp/top_p/penalties 应来自模型或 Modelfile 自身值；未设置参数的模型应回落到 Ollama 默认值（评论给出的默认值为 0.8/0.9），而不是 1.0/1.0。另可用固定 seed 重复采样，观察 Modelfile 中 temperature 0 的模型在 /api/chat 下输出稳定、而 /v1/chat/completions 下输出多样的现象是否消失。