AI 工具内存占用过高怎么办？排查命令和优化方法

AI 工具跑着跑着就被 OOM kill 了，或者 SSH 卡到连命令都敲不进去，往往是内存撑爆了。VPS 内存本来就有限，部署了 Ollama、Open WebUI、n8n、Claude Code 这些 AI 工具后，内存占用经常飙到 90% 以上。本文直接给排查命令和优化方法，帮你把内存降下来，不用加钱升级配置。

先搞清楚谁在吃内存

别凭感觉，用命令看真实数据。

free -h
free -h -t

如果 `available` 接近 0，说明内存真的不够了。接下来定位进程：

ps aux –sort=-%mem | head -20

常见吃内存大户：

• Ollama 加载的模型（7B 模型通常占 4-6GB，13B 模型 8-10GB）

• Open WebUI 的 Python 进程（带 embedding 模型时更明显）

• n8n 的工作流执行节点（尤其是循环调用 AI API 时）

• Claude Code 或 Codex 的本地 agent

• Hermes Agent 的推理进程

`htop` 更直观，还能看每个线程的 RSS：

htop

Docker 部署场景内存排查

很多 AI 工具用 Docker 跑，用 `docker stats` 实时看：

docker stats –no-stream
docker stats

如果某个容器内存持续涨，可能是内存泄漏或者模型缓存无限增长。加上 `–limit` 参数可以约束容器最大内存：

docker run -d –memory="4g" –memory-swap="4g" your-ai-image

已经运行的容器，用 `docker update` 改限制：

docker update –memory="3g" –memory-swap="3g" 容器名

Ollama 模型内存优化

Ollama 默认会加载整个模型到内存。如果 VPS 只有 4GB 或 8GB 内存，跑 7B 模型很容易爆。

方法一：使用量化模型
Ollama 的模型标签带 `q4_K_M`、`q5_K_M` 等后缀，量化后内存占用减少 30%-50%。

ollama pull llama3.2:3b-q4_K_M

方法二：限制模型上下文长度
上下文越长，KV cache 占用越大。在 Ollama 启动时设置：

OLLAMA_NUM_PARALLEL=1 OLLAMA_CONTEXT_LENGTH=2048 ollama serve

或者修改配置文件 `/etc/systemd/system/ollama.service` 中的 Environment 行。

方法三：关闭 keep-alive
Ollama 默认会保持模型加载 5 分钟。如果只是偶尔调用，可以缩短时间或设为 0：

ollama run llama3.2 –keep-alive 0

Open WebUI 内存优化

Open WebUI 默认会加载 embedding 模型（如 all-MiniLM-L6-v2），这个模型大约占 500MB-1GB 内存。如果不需要本地 RAG，可以禁用：

在 Open WebUI 的 Admin Settings > Documents > Embedding Model 里选择 `None` 或使用远程 API 的 embedding。

另外，Open WebUI 的数据库（SQLite）会缓存大量对话历史。定期清理旧对话：

docker exec -it open-webui sqlite3 /app/backend/data/webui.db
DELETE FROM chat WHERE updated_at < datetime('now', '-30 days');
.quit

n8n 工作流内存管理

n8n 的每个工作流节点都会占用内存，尤其是 HTTP 请求节点、代码节点、AI 节点。优化方向：

•减少并发执行：在 n8n 设置中降低 `Workflow Execution Concurrency`（默认 20，建议改为 5）

•使用外部执行器：把耗时的 AI 节点拆分到远程 API，而不是本地模型

•清理执行日志：n8n 默认保存所有执行记录，时间长了撑爆内存。在 Settings > Execution Data 里设置保留天数（比如 7 天）

老鸟叮嘱：别踩这些坑

1.别用 swap 当救命稻草
swap 放在 SSD 上虽然能撑一会儿，但频繁换页会让 AI 工具响应变慢几十倍。swap 只适合应急，不能替代物理内存。

2.别同时跑多个大模型
一台 8GB 的 VPS 跑一个 7B 模型已经很勉强，再开一个 Hermes Agent 推理进程，直接 OOM。

3.别忽略日志文件
AI 工具日志默认不轮转，几个月下来日志能吃掉几个 GB。配置 logrotate 或定期清理 `/var/log` 下的日志。

4.别用 root 跑所有服务
非 root 用户跑的服务更容易通过 cgroups 限制内存。如果 root 跑 Ollama，OOM killer 可能会杀掉更重要的系统进程。

5.别把后台端口暴露公网
Open WebUI、n8n 的 Web 端口如果直接暴露，不仅不安全，还可能被爬虫或恶意请求打爆内存。建议只监听 127.0.0.1 或通过 Nginx 加认证。

FAQ

Q1：VPS 只有 2GB 内存，能跑 AI Agent 吗？
可以，但只能跑 1B 左右的量化模型（如 Qwen2.5-0.5B-q4），或者完全依赖 API 调用（如 Claude API、OpenAI API）。本地模型基本没戏。

Q2：Ollama 模型加载后内存一直不释放怎么办？
检查 keep-alive 设置，或者手动卸载模型：`ollama stop 模型名`。如果仍然不释放，重启 Ollama 服务。

Q3：docker stats 显示内存占用正常，但主机 free -h 显示很高？
可能是 Docker 的缓存/缓冲区未回收。运行 `sync && echo 3 > /proc/sys/vm/drop_caches` 清理缓存（谨慎操作，生产环境用 `echo 1` 只清理 pagecache）。

Q4：n8n 工作流跑一次内存就涨一点，最终 OOM？
大概率是节点里使用了 `$items()` 或循环未释放变量。检查代码节点是否有全局变量未清理，或者使用 `n8n` 的 `Stop and Error` 节点提前终止无用分支。

Q5：Open WebUI 的 embedding 模型能换更轻量的吗？
可以。在 Open WebUI 的 `.env` 文件中设置 `EMBEDDING_MODEL` 为 `sentence-transformers/all-MiniLM-L6-v2` 已经算轻量了。如果还嫌大，换成 `paraphrase-MiniLM-L3-v2`（约 200MB）。

Q6：用 `ulimit` 能限制内存吗？
`ulimit -v` 可以限制虚拟内存，但很多 AI 工具会直接忽略或导致崩溃。推荐用 Docker 的 `–memory` 或 systemd 的 `MemoryMax` 更可靠。

AI 工具内存优化本质是资源换速度——量化模型、降低并发、清理缓存、限制上下文，每一步都能挤出几十到几百兆内存。先排查再优化，别一上来就重装系统。如果你在 VPS 上部署了多个 AI 工具，建议单独为每个服务设置内存上限，避免一个进程把整台机器拖垮。