ollama stop reports success and clears ollama ps, but the MLX runner subprocess stays resident and keeps holding RAM until manually killed

问题场景

在 macOS 上通过 Ollama 使用 MLX 引擎运行大模型（如 gemma4:12b-mlx、muse-glimmer:30b-mlx 等），正常对话后执行 ollama stop。预期是模型进程立即退出并释放内存，但实际操作中 ollama stop 返回成功、ollama ps 显示为空列表，而底层 runner 子进程（命令行含 --mlx-engine）仍在运行，持续占用高内存（实测可高达 18–20 GB），直到手动 kill 或系统内存耗尽。

报错原文

ollama stop reports success and clears ollama ps, but the MLX runner subprocess stays resident and keeps holding RAM until manually killed

In every single case, ollama ps reported empty and ollama stop reported success at the exact moment the leaked process was independently confirmed still running via ps -p <pid>.

原因分析

Issue 中并未给出明确根因，但根据现象和评论内容可以归纳为以下几点：

可能原因一：这是 macOS 特有行为。Issue 评论中有用户在 Linux（同样使用 --mlx-engine）上复现相同操作，结果 runner 正常退出，说明问题与 macOS 下的进程管理或 MLX 运行时库的清理逻辑有关。

可能原因二：Ollama 在 0.32.13 版本（及更早 0.32.9）中，MLX runner 子进程的退出信号没有在 macOS 上正确传递，导致进程进入僵尸驻留状态。后续修复在 PR #17798 中处理。

可能原因三：与系统内存压力相关。Issue 记录中多次出现内存被压到 0.06–0.57 GB 的极端情况，内存压力可能影响 ollama stop 之后的清理流程时序，但评论中也有“无法在 Mac 上复现”的反例，说明这不是唯一触发条件。

环境排查

• 确认 Ollama 版本：ollama -v，重点排查 0.32.9、0.32.13 及更早版本。
• 确认操作系统是否为 macOS，以及是否是 Apple Silicon（M 系列芯片）。Issue 明确标注 OS 为 macOS、GPU/CPU 为 Apple。
• 确认模型确实走 MLX 引擎：ollama ps 中 PROCESSOR 列应显示 100% GPU，且进程命令行包含 --mlx-engine。
• 若在 Linux/Docker 下遇到相似现象，可能并非同一问题，优先按常规排查。
• 查看完整服务端日志（ollama serve 输出），确认 stop 请求是否在服务端被正确接收、runner 退出码是什么。

解决步骤

1. 升级 Ollama。PR #17798 已修复此问题，更新到包含该 PR 的版本（在 0.32.13 之后发布）。升级后重新执行加载模型→ollama stop→观察进程是否退出。
2. 如果无法升级，临时手动清理：先用 ollama ps 确认没有模型列表，再用 ps aux | grep runner 找到残留进程，记录 PID 后执行 kill <PID> 释放内存。注意这不会修复根本原因，每次 stop 后都需要手动处理。
3. 排查自定义配置。如果是通过代码或 API 调用 Ollama，检查是否在请求中设置了过长的 keep_alive（如 keep_alive: -1），这可能导致进程不会在 stop 时立即退出。改用默认 keep_alive 或显式设置为 0 测试。
4. 收集完整日志反馈。如果升级后仍复现，按 Ollama 排错文档收集从启动到 stop 的完整 server 日志，在 GitHub Issue 中补充。

验证方法

执行以下步骤确认问题已解决：

1. 加载一个 MLX 模型（如 gemma4:12b-mlx），等待其完全运行起；

2. 执行 ollama stop <model>，确认返回 success；

3. 执行 ollama ps，确认列表为空；

4. 立即（5 秒内）执行 ps aux | grep -- --mlx-engine，确认对应 PID 已消失，而不是残留；

5. 用 top 或 vm_stat 观察可用内存是否回到停止前的水平。

如果以上第 4 步仍能找到残留进程，说明修复未在本地生效，需要按“解决步骤”第 4 条反馈日志。

参考来源

ollama/ollama #17792

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。