generate completion API hangs with certain models but not with others

快速结论：该报错通常出现在 macOS（Apple Silicon）上用 Ollama 加载某些特定模型（如 qwen3.5:2b、gemma4:12b-it-qat）时，/api/generate 或 /api/chat 请求挂起、GPU 占用 100% 且迟迟不返回，而其他模型（如 llama3.2:3b、granite4.1:8b）正常。优先排查是否为模型专属加载问题、num_ctx 过大引发的调度器反复换入换出，以及当前 Ollama 版本是否引入回归。

适用环境：Apple Silicon macOS。Issue 中已确认的环境包括 Ollama 0.23.2、0.33.0、0.32.15、0.34.4；macOS Tahoe 26.4.1、macOS 15.7.7；Apple M4 Pro（24 GB、64 GB 内存），Apple M4 Mac Mini（24 GB，Homebrew 安装）；涉及模型 qwen3.5:2b (Q8_0)、llama3.2:3b (Q4_K_M)、gemma4:12b-it-qat (GGUF, QAT)；使用 Metal 后端，日志显示 use tensor = false（M4 非 M5/A19 设备禁用 tensor API）。

最快修复方案：暂无确认的一步修复方案。评论中唯一被报告“验证后可恢复”的处理是将 Ollama 从 0.33.0 降级到 0.32.15，并重建模型的 num_ctx（例如 32768）后清缓存，但该结论由第三方在生产环境报告，且维护者在 M4 Pro 上未能复现，因此仅供参考。

注意事项：维护者在 Apple M4 Pro、macOS 15.7.7 上，用 0.23.2 与 0.34.4 对 qwen3.5:2b-q8_0 和 llama3.2:3b 均测试通过，未能复现挂起，说明问题可能与具体机器/系统版本/模型文件或加载路径相关，而非普遍回归。评论中的降级与 num_ctx 重建方案尚未被维护者确认，也未定位到 0.33.x 中具体引入问题的改动，MLX 模型与 GGUF 模型表现可能不同，请勿直接照搬到所有模型。

问题场景

用户在 macOS（Apple Silicon）上运行 Ollama，通过 /api/generate（以及 /api/chat）向特定模型提交请求时，请求挂起不返回，Mac GPU 占用升至 100% 并持续不降，只能 kill -9 结束进程。提交给其他模型时则能在 2 秒内正常完成。触发场景包括：Ollama 0.23.2 + macOS Tahoe 26.4.1 上请求 qwen3.5:2b (Q8_0) 挂起，而 llama3.2:3b (Q4_K_M) 正常；以及 Ollama 0.33.0 上加载 gemma4:12b-it-qat 时挂起、granite4.1:8b 正常。日志显示模型架构为 qwen35，调度器发出 “model architecture does not currently support parallel requests” 警告，随后启用 flash attention 并启动 runner。

报错原文

generate completion API hangs with certain models but not with others

time=2026-05-08T18:24:02.280+02:00 level=WARN source=sched.go:423 msg="model architecture does not currently support parallel requests" architecture=qwen35
time=2026-05-08T18:24:02.320+02:00 level=INFO source=server.go:259 msg="enabling flash attention"
time=2026-05-08T18:24:02.320+02:00 level=INFO source=server.go:433 msg="starting runner" cmd="/Applications/Ollama.app/Contents/Resources/ollama runner --ollama-engine --model /Users/flavio/.ollama/models/blobs/sha256-b709d81508a078a686961de6ca07a953b895d9b286c46e17f00fb267f4f2d297 --port 49335"
time=2026-05-08T18:24:02.382+02:00 level=INFO source=runner.go:1297 msg=load request="{Operation:fit LoraPath:[] Parallel:1 BatchSize:512 FlashAttention:Enabled KvSize:262144 KvCacheType: NumThreads:10 GPULayers:25[ID:0 Layers:25(0..24)] MultiUserCache:false ProjectorPath: MainGPU:0 UseMmap:false}"
ggml_metal_device_init: tensor API disabled for pre-M5 and pre-A19 devices
ggml_metal_device_init: GPU name:   Apple M4 Pro
ggml_metal_device_init: has tensor            = false
ggml_metal_device_init: use residency sets    = true

原因分析

目前尚无维护者确认的根因。根据 Issue 讨论，可能原因包括：

模型专属问题：同机同版本下只有特定模型触发，说明与模型文件/架构（如 qwen35）相关，而非普遍性的服务故障。
调度器驱逐/重载循环：评论者观察到模型 manifest 中 num_ctx 被设为 262144/131072 这类超大值，可能导致调度器反复驱逐并重载 runner，形成循环。重建为较小的 num_ctx（如 32768）并清理探测缓存后，该循环消失。此结论来自第三方实测，未获维护者确认。
冷启动时间过长：该模型冷启动约需 100 秒，超过常见客户端超时，请求在 runner 就绪前即超时。这可能造成“挂起”的表象。
版本回归可能性：评论者报告 0.33.0 有挂起、降至 0.32.15 后消失，但未 bisect 出具体引入问题的改动，因此只能作为“可能原因”。
平台相关性：GitHub 评论中有人指出该问题“在 Linux 上正常，似乎是 Mac 问题”。

环境排查

确认 Ollama 版本：Issue 中出现 0.23.2、0.32.15、0.33.0、0.34.4，不同版本表现可能不同。
确认操作系统版本：Issue 中涉及 macOS Tahoe 26.4.1 与 macOS 15.7.7。
确认硬件：Issue 中为 Apple Silicon（M4 Pro、M4 Mac Mini），内存 24 GB 或 64 GB。
确认安装方式：官方 Ollama.app 或 Homebrew，不同安装路径会影响日志与资源位置。
确认触发模型与对照模型：例如 qwen3.5:2b (Q8_0) vs llama3.2:3b (Q4_K_M)、gemma4:12b-it-qat vs granite4.1:8b。
确认模型量化与格式：Q8_0、Q4_K_M、GGUF QAT 等，Issue 中评论者使用的是 GGUF 而非 MLX。
检查模型 manifest 中的 num_ctx 设置，以及日志中的 KvSize 字段（原日志显示 KvSize:262144）。
检查 Metal 相关日志，确认 tensor API、FlashAttention、residency sets 等状态（Issue 显示 M4 上 has tensor = false）。

解决步骤

先用同一台机器、同一 Ollama 版本、同一 prompt 分别请求“出问题的模型”和“正常模型”，记录是全部模型挂起还是仅特定模型挂起，以缩小范围。
查看请求期间的 Ollama 日志，重点关注调度器是否出现驱逐/重载（scheduler eviction）相关行，以及冷启动耗时。
检查触发模型 manifest 中的 num_ctx 值；如为 131072/262144 这类超大值，可尝试将 num_ctx 重建为更小值（评论中示例为 32768），并清理探测缓存后再测试。注意：这是评论者提出的方案，未获维护者确认，可优先尝试。
若客户端存在超时（评论中出现 120 秒），在冷启动较慢的模型上适当延长超时时间，以免把“仍在加载”误判为“挂起”。
如上述无效，可尝试将 Ollama 从 0.33.0 降级到 0.32.15 后重测（评论者报告中这样做消除了挂起）。降级前请自行备份配置与模型。
若仍无法解决，按 Issue 讨论建议，向维护者提供日志中的“加载进度/挂起”区分信息、模型名称与量化、Ollama 版本、macOS 版本和硬件信息，以便排查是否为某版本引入的回归。

验证方法

用之前会挂起的模型和 prompt 再次通过 /api/generate（stream:false）提交请求，确认能在合理时间内返回 "done": true 与 done_reason，且 GPU 占用在返回后回落，而不是持续 100%。同时对照一个已知正常的模型确认其行为未受影响。Issue 中维护者的复现测试使用的是 qwen3.5:2b-q8_0（blob 与 qwen3.5:2b 相同，ID 324d162be6ca），prompt 为 hello、开启 streaming、无 token 限制，可参照此方式做对照测试。