Ollama 模型速度过慢 — 5 种优化方法
如果 Ollama 模型在 OpenClaw 中每秒生成不足 5 个 token,最可能的原因是:GPU 加速未启用而在 CPU 上运行、使用了不适合 VRAM 的全精度(F16)模型,或者上下文窗口设置过大。以下每条优化都针对其中一个根本原因——按顺序执行可获得最快的累积改善效果。在配置了 gpu_layers: -1 和 Q4_K_M 量化的 Mac Mini M4 上,吞吐量通常可从 4-6 tok/s 提升至 80-120 tok/s。
🔍 第一步:诊断基准速度
重点关注两项输出:'ollama ps' 中的 'device' 列——如果显示 'CPU' 而非 'GPU' 或 'Metal',说明硬件加速未启用。以及 --verbose 输出中的 'eval rate' 行——Apple 芯片低于 10 tok/s,或独立 NVIDIA GPU 低于 20 tok/s,说明这是配置问题,而非硬件限制。记录该数值后再继续执行优化步骤。
✅ 5 种优化(按顺序执行)
默认情况下,如果 Ollama 无法确认所有层都能放入 VRAM,会将部分层卸载到 CPU。设置 gpu_layers: -1 可强制所有层到 GPU——若不够用,Ollama 会给出警告,而非静默降级。这一改动是 Apple 芯片和 NVIDIA 系统性能提升的最主要来源。
注意力计算随上下文长度呈平方级增长。大多数 OpenClaw 对话实际使用不超过 1,500 个 token,默认 4096 的窗口通常是浪费。除非处理长文档分析,否则减半即可。对于只发送简短心跳的 agent,512 已经足够。
Q4_K_M 是大多数场景的推荐量化方案:比 Q8 小 40-50%,基准性能损失不足 1%。Q2_K 更快但在推理和指令遵循方面明显更差——避免在需要多步逻辑的 agent 任务中使用。
重复相同的提示——每日问候、心跳 ping、静态问答——可从缓存以近零延迟提供服务。如果将 Ollama 数据目录挂载为 Docker 卷,缓存条目将在重启后保留。对每天多次发送相同提示的定时 agent 最有帮助。
将意图分类为'简单'的查询路由到 2-3B 模型。OpenClaw 路由配置允许为问候、状态检查和简短回复指定快速模型,将大模型留给真正需要深度推理的任务。Gemma 2B 能以 7B 模型两倍的速度处理大多数对话交流。
冷启动:重启后第一次请求报 「model not found」
重启后第一次响应特别慢、甚至直接报 「model not found」,其实是同一个问题的两个侧面:模型还没被加载进内存。下面这几个修复能让第一次请求的表现接近第十次。
✅ 修复方法 1 — 在 OpenClaw 中增加 Ollama 请求超时
# 在 openclaw.yaml 中,增加 Ollama 超时
providers:
- id: local-ollama
type: ollama
baseUrl: http://localhost:11434
timeout: 120000 # 120 秒(默认:30)
coldStartTimeout: 300000 # 首次加载 5 分钟✅ 修复方法 2 — 在网关启动前预热 Ollama
# 在启动脚本中,在 openclaw gateway start 之前添加 ollama run llama3.1:8b-q4_K_M '' --nowordwrap & sleep 30 # 等待模型加载 openclaw gateway start
✅ 修复方法 3 — 禁用模型卸载(始终保持模型加载)
# 无限期保持模型加载(使用更多 RAM)
{
"ai": {
"keep_alive": -1
}
}
# 或设置长超时
{
"ai": {
"keep_alive": "24h"
}
}