mlx engine: long-lived runner (keep_alive -1) returns a different prompt answer on repeat calls — cross-request response contamination

快速结论：在 Ollama MLX 引擎（Apple Silicon）下，当使用 OLLAMA_KEEP_ALIVE=-1 让模型常驻内存时，长生命周期 runner 在重复调用中可能返回“之前某个请求的完整答案”，即跨请求响应污染（mlx engine: long-lived runner (keep_alive -1) returns a different prompt answer on repeat calls — cross-request response contamination）。优先排查是否由 runner 的 prefix cache 状态导致，并升级到包含 #17581 修复的版本（如 0.32.7）。

适用环境：Ollama 0.31.1、0.32.3、0.32.5；macOS 26.6（M5 Pro, 64 GB）与 macOS 26.5.2（M2 Max, 64 GB）；MLX 引擎；OLLAMA_KEEP_ALIVE=-1 或长 keep-alive；q8_0 与 f16 KV cache；MoE 35B 与 Dense 27B 模型均可复现。

最快修复方案：升级到包含 ollama/ollama#17581 修复的版本（评论确认 0.32.7 已解决）；或在无法升级时，对每个请求显式设置 keep_alive: 0，让 runner 不再跨请求复用，可完全消除污染。

注意事项：评论验证使用的是标准库标签模型（qwen3.6:35b-mlx），而非 Issue 中的本地 nvfp4 导入；但修复在 0.32.7 上对 num_ctx 8192/32768/65536 均显示 0/48 污染。显式 keep_alive: 0 会牺牲常驻内存带来的首字延迟优势，仅适合作为临时规避手段。

问题场景

在 Apple Silicon Mac 上以 MLX 引擎运行 Ollama，并通过 OLLAMA_KEEP_ALIVE=-1（或较长 keep-alive）保持模型常驻时，连续发送多组独立、简短且互不共享上下文的代码生成/文本转换请求。第一轮请求结果正常，后续轮次中部分请求返回的是“另一个更早请求的完整正确答案”，而不是当前请求的结果。Issue 作者通过 16 个不同提示词、每轮重复 3 次的方式稳定复现。

报错原文

mlx engine: long-lived runner (keep_alive -1) returns a different prompt answer on repeat calls — cross-request response contamination

典型表现：请求“写一个端口解析函数”，却收到完全属于另一个提示词（如“写一个秘密脱敏函数”）的完整回答，且当前任务内容完全缺失。

原因分析

可能原因是长生命周期 runner 在服务端维护的请求/前缀缓存（prefix cache）状态发生了跨请求串扰。两个不同架构的模型（35B MoE 与 dense 27B）出现了完全相同的错误答案路由（例如 D07 拿到 D08 的答案、D08 拿到 E03 的答案），说明问题不在模型权重或采样逻辑，而在 runner 的缓存状态管理。

已排除 KV cache 量化：q8_0 与 f16 下复现率一致。
已排除 Ollama 版本：0.31.1 与 0.32.5 复现率一致。
已排除模型架构：MoE 35B 与 Dense 27B 均复现，而同一服务器上的 gemma 系 12B 模型从未复现（0/141）。
温度固定为 0 只是让失败变得确定性（同样的任务每轮都失败），并不能消除问题。
runner 生命周期是触发条件：每次请求之间卸载模型（keep_alive: 0）时，96 次调用 0 污染。

环境排查

确认 Ollama 版本是否为 0.32.3 / 0.31.1 / 0.32.5 等受影响版本；建议升级到 0.32.7 或更高。
检查服务端是否设置了 OLLAMA_KEEP_ALIVE=-1 或很长的 keep-alive；请求中是否携带 options.keep_alive。
确认 MLX 引擎是否启用（Apple Silicon 上运行 ollama runner --mlx-engine，或本地 safetensors/nvfp4 导入）。
记录 num_ctx 设置：在 0.32.3 下 num_ctx=65536 的污染率高于 8192/32768（第一轮就出现 6/16 污染），升级修复后三种上下文下均为 0/48。
注意提示词形态：16 个长度相近的提示词未触发；长短混合、或共享较长前缀（约 500 字符）且结尾带唯一 nonce 的提示词更容易触发。

解决步骤

优先将 Ollama 升级到包含 PR #17581 的版本（评论确认 0.32.7 已解决；此方案可优先尝试）。
若暂时无法升级，在每次 /api/chat 或 /api/generate 请求中显式设置 "keep_alive": 0，强制 runner 在请求后卸载，避免跨请求缓存串扰。
如果必须使用长驻 runner，请降低 num_ctx 并观察是否减少污染（Issue 在 0.32.3 下 65536 上下文比 8192 更严重），但这只是缓解而非修复。
复测时建议使用“多条不同任务、长短混合、共享固定前缀 + 唯一 nonce”的提示词集，并连续多轮重复请求，以提高检测灵敏度。

验证方法

升级后，用同一套脚本（16 个不同提示词、3 轮共 48 次调用）重新测试。如果所有响应都包含当前提示词的任务特征内容，且不包含其它提示词的签名内容或 nonce，则问题已修复。评论确认在 0.32.7 上，num_ctx 为 8192/32768/65536 时污染数均为 0/48；而 0.32.3 在同环境下为 12/48、12/48、18/48。