Version 0.40.0 stops with “Maximum threads” error after a minute.

快速结论：该报错出现在 macOS Apple Silicon 上使用 Ollama 0.40.0/0.40.1-rc0/0.40.3 配合 MLX 模型（如 qwen3.6:35b-mlx）进行推理时，运行约一分钟后 MLX runner panic，并返回 HTTP 500。优先排查模型是否走 MLX runner，以及版本是否为 0.40.x 回归版本。

适用环境：Ollama 0.40.0、0.40.1-rc0、0.40.3（官方 Ollama-darwin.zip）；macOS（Apple Silicon）；Apple M1 Max / M1 Pro / M1 Max（Mac Studio）；MLX runner 与 MLX 模型标签（如 qwen3.6:35b-mlx、qwen3.6:27b-mlx）；LLM 模型与 llama.cpp runner 不触发该崩溃。

最快修复方案：改用同一模型的 q4_K_M 标签（例如 qwen3.6:35b-a3b-q4_K_M 或 qwen3.6:27b-mtp-q4_K_M），让 Ollama 切换到基于 llama.cpp 的 runner，而不是 MLX runner。Issue 中多位用户确认该 workaround 可以跑通原工作负载。

注意事项：该方案牺牲 MLX runner 的速度（例如从 23.7 tok/s 降到 13.4 tok/s），并且只是绕过 MLX 路径，并未修复 0.40.x 中 MLX runner / KV cache 的回归。Issue 在 2026-10-12 关闭，但讨论中未给出明确的代码修复版本，升级前建议先确认目标版本是否已修复。

问题场景

在 macOS Apple Silicon 上运行 Ollama 0.40.x，使用 MLX 标签的模型（如 qwen3.6:35b-mlx、qwen3.6:27b-mlx），通过 Ollama 自带聊天、pi.dev 或 LiteLLM 代理发起长上下文请求（如 OLLAMA_CONTEXT_LENGTH=65536），并触发工具调用或前缀缓存复用时，MLX runner 在运行约一分钟或第二次请求时崩溃。

报错原文

mlx runner failed: panic: mlx: Maximum threads per threadgroup is 896 but requested 1024 for kernel
sdpa_vector_2pass_1_bfloat16_t_256_256_nomask_qnt_c_nosinks_128. at
/Users/runner/work/ollama/ollama/build/darwin-sources/_deps/mlx-c-src/mlx/c/transforms.cpp:15

panic: cache: offset 5335 exceeds 5334 stored keys
Unable to parse ollama chunk
{'error': 'mlx runner failed: panic: cache: offset 5335 exceeds 5334 stored keys'}

原因分析

可能原因：Ollama 0.40.x 的 MLX runner 在特定模型/上下文长度下，线程组配置超出 Metal 允许的 Maximum threads per threadgroup（896），导致 sdpa_vector_2pass 内核请求 1024 或 960 线程而被拒绝并 panic。随后在展开时，prefix cache 关闭路径又抛出 offset 超出已存储 keys 的次级 panic。Issue 中的 A/B 结果显示 0.34.2–0.35.1 无此崩溃，0.40.0/0.40.1-rc0/0.40.3 复现，且另一个 MLX 模型 gemma4:e4b-mlx 在同一版本下运行正常，说明问题更偏向 Qwen 3.6 MLX 模型/运行时路径，而非 Ollama 0.40.x 的普遍性问题。目前讨论中尚未给出根因修复代码。

环境排查

确认 Ollama 版本是否为 0.40.0、0.40.1-rc0 或 0.40.3；Issue 中 0.35.1 及 0.34.2 未复现。
确认模型标签是否带 -mlx（如 qwen3.6:35b-mlx、qwen3.6:27b-mlx）；使用 q4_K_M 标签会走 llama.cpp runner。
确认是否设置了 OLLAMA_CONTEXT_LENGTH=65536；Issue 中多个复现都使用 64k 或 65,536 上下文。
确认机器是否为 Apple Silicon（M1 Max、M1 Pro、M1 Max Mac Studio 均已报告）。
确认 MLX runner 版本（Issue 中一条记录显示 MLX 0.32.3-53-ga59cc23）。
确认触发路径：Ollama 自带聊天、pi.dev、/v1/chat/completions、/api/chat，以及是否涉及工具调用、前缀缓存命中或 MTP 草稿。

解决步骤

可优先尝试：将模型切换到带 q4_K_M 的标签，例如 qwen3.6:35b-a3b-q4_K_M 或 qwen3.6:27b-mtp-q4_K_M，强制使用 llama.cpp runner 而不是 MLX runner。
重新运行同一工作负载（相同上下文长度、相同提示、相同工具调用流程），确认不再出现 MLX panic。
如果必须使用 MLX 路径，可临时降级到 0.35.0 / 0.35.1 作为 workaround；Issue 报告该版本区间无此问题。
在确认新版本已修复该回归前，不要在生产环境中将 MLX 模型路径升级到 0.40.x。

验证方法

使用 q4_K_M 标签运行相同请求，若不再出现 “mlx runner failed” 或 “Maximum threads per threadgroup” 报错，并且请求正常完成（Issue 中提到 llama.cpp runner 可连续 34 轮无错误），即说明 workaround 生效。若仍走 MLX 标签并持续复现相同 panic，则说明尚未绕开该路径。