上周三公司新来了个实习生，看到热榜那篇"5 分钟部署 OpenClaw"就跟着搞了一台，结果 16G 内存的机器跑 Claude Opus 4.7 直接 OOM，进程被 kill 了三次。他跑来问我怎么办，我折腾了大半天帮他调好了——说实话这个坑我自己半年前也踩过，干脆写篇文章记录一下。
OpenClaw 在 16G 内存机器上推荐的配置思路是：把本地 Agent 编排层控制在 4G 以内，模型推理全部走远程 API，内存留给上下文缓存和工具链执行环境。下面我会给出三套实测可用的配置方案，从纯云端到混合部署都有覆盖。
先说结论
| 方案 | 本地内存占用 | 模型来源 | 适合场景 | 响应速度 |
|---|---|---|---|---|
| 方案一：纯 API 远程推理 | ~2.8G | 云端 API | 日常开发、写代码 | P95 约 380ms |
| 方案二：小模型本地 + 大模型远程 | ~6.2G | 本地 Qwen3-1.5B + 远程 API | 离线场景兜底 | 本地 120ms / 远程 400ms |
| 方案三：量化模型本地跑 | ~14.1G | 本地 DeepSeek-V3.2-Q4 | 纯离线、数据敏感 | 约 2.8s/请求 |
方案一最省心，方案三最折腾。我个人用的是方案一。
环境准备
我的测试环境：
- 机器：某云 4C 16G Ubuntu 22.04（¥98/月那种乞丐版）
- OpenClaw 版本：v0.9.3（4 月 22 号刚更新的）
- Docker：24.0.7
- Python：3.11
先把 OpenClaw 装好，这步不赘述了，热榜那篇教程写得挺清楚。装完之后跑一下 openclaw status，确认输出里 memory_allocated 那行不超过 1.2G——这是 Agent 框架本身的基础开销。
$ openclaw status
Version: 0.9.3
Status: running
memory_allocated: 1.14G
workers: 4
model_backend: none (not configured)
如果这一步就超 2G，大概率是 worker 数量太多。改一下 ~/.openclaw/config.yaml：
runtime:
workers: 2 # 16G 内存别超过 2
max_context_mb: 512 # 上下文缓存上限
gc_interval_sec: 30 # 垃圾回收频率调高点
方案一：纯 API 远程推理（推荐）
这是我自己在用的方案。思路很简单——本地只跑 OpenClaw 的编排层和工具链，模型推理全扔给云端 API。
graph LR
A[OpenClaw Agent] -->|tool_call| B[本地工具链<br/>文件读写/终端/浏览器]
A -->|推理请求| C[远程 API Gateway]
C --> D[Claude Sonnet 4.6]
C --> E[GPT-5.5]
C --> F[DeepSeek V4]
style A fill:#e1f5fe
style C fill:#fff3e0
编辑 ~/.openclaw/models.yaml：
models:
primary:
provider: openai_compatible
model: claude-sonnet-4-6-20260414
api_key: ${OFOX_API_KEY}
base_url: https://api.ofox.ai/v1
max_tokens: 8192
temperature: 0.3
fallback:
provider: openai_compatible
model: deepseek-v3.2
api_key: ${OFOX_API_KEY}
base_url: https://api.ofox.ai/v1
max_tokens: 4096
temperature: 0.2
这里 primary 用 Claude Sonnet 4.6 做主力推理，fallback 用 DeepSeek V3.2 兜底（便宜）。OpenClaw 支持 OpenAI 兼容协议，所以 OpenRouter、Together AI、ofox.ai 这些聚合平台都能直接接，改个 base_url 的事。我用 ofox.ai 是因为 0% 加价对齐官方价格，OpenRouter 那边要收 5.5% 手续费，一个月调用量大的话能差出好几十刀。
配好之后重启：
openclaw restart
openclaw test-model primary
正常的话会输出：
Testing model 'primary'...
Response: "Hello! I'm Claude, ready to assist."
Latency: 342ms
Token usage: 12 input / 8 output
Status: OK
实测内存占用稳定在 2.8G 左右，跑复杂的多步骤任务（比如让它重构一个 500 行的 Python 文件）峰值也没超过 3.5G。
踩坑：429 和超时
跑了大概两天，遇到一个问题。让 OpenClaw 并行执行 3 个子任务的时候，偶尔会报这个：
[ERROR] Model request failed: 429 Too Many Requests
{"error":{"message":"Rate limit exceeded. Please retry after 2s","type":"rate_limit_error"}}
原因是 OpenClaw 默认的并发策略比较激进，2 个 worker 同时发请求容易撞限流。解决办法是在 config.yaml 加一行：
runtime:
workers: 2
request_concurrency: 1 # 串行发请求，牺牲一点速度换稳定
retry_on_429: true
retry_delay_ms: 2000
加了之后就没再遇到了。
方案二：小模型本地 + 大模型远程
有时候网络不稳定，或者做一些简单的意图识别不想每次都走远程 API（费钱），可以本地跑一个小模型做"路由判断"，复杂任务再转发给云端。
models:
router:
provider: local_gguf
model_path: ~/.openclaw/models/qwen3-1.5b-q8.gguf
max_tokens: 256
gpu_layers: 0 # 纯 CPU 推理
context_size: 2048
primary:
provider: openai_compatible
model: claude-sonnet-4-6-20260414
api_key: ${OFOX_API_KEY}
base_url: https://api.ofox.ai/v1
max_tokens: 8192
routing:
strategy: complexity
simple_threshold: 0.4 # 复杂度低于 0.4 用本地模型
Qwen3-1.5B 的 Q8 量化版大概吃 1.8G 内存，加上 OpenClaw 本身的开销，总共 6.2G 左右。剩下的内存留给系统和工具链执行，还算够用。
不过说实话，这个方案我试了一周就放弃了。Qwen3-1.5B 做路由判断的准确率大概只有 78%——经常把该走云端的复杂任务判成"简单"，然后本地模型输出一坨垃圾，OpenClaw 还得重试一次，反而更慢更贵。也不确定是不是我 prompt 没调好，但折腾半天觉得不值当。
方案三：量化模型纯本地跑
数据敏感场景，或者就是想离线用，可以本地跑量化模型。16G 内存能跑的最大模型基本就是 DeepSeek-V3.2 的 Q4_K_M 量化了。
models:
primary:
provider: local_gguf
model_path: ~/.openclaw/models/deepseek-v3.2-q4_k_m.gguf
max_tokens: 4096
gpu_layers: 0
context_size: 4096 # 别开太大，内存会爆
threads: 4
实测这个配置内存直接拉到 14.1G，系统只剩不到 2G。跑起来是能跑，但是：
- 单次推理平均 2.8 秒，复杂任务能到 8-10 秒
- 上下文窗口只敢开 4096，再大就 OOM
- 系统偶尔会触发 swap，然后整个机器卡得像 PPT
如果真要走这条路，建议至少 32G 内存。16G 跑量化大模型属于"能用但很痛苦"。
踩坑记录汇总
坑 1：config.yaml 缩进错误不报错
OpenClaw 的 YAML 解析器有个 bug（或者说 feature），缩进错了它不报错，直接用默认值。我有一次 workers 写在了 models 下面，结果默认开了 8 个 worker，内存直接拉满。排查了好久才发现。建议改完配置跑一下：
openclaw config --validate
坑 2：GGUF 模型路径带空格
别笑，实习生的用户名带空格（/home/li ming/...），GGUF 加载直接 segfault。做个软链接就好了。
坑 3：日志撑爆磁盘
默认日志级别是 DEBUG，跑一天能写 2G 日志。改成 WARN：
logging:
level: warn
max_size_mb: 100
rotate: true
小结
16G 内存跑 OpenClaw，最靠谱的还是方案一——本地只跑编排，推理扔给云端 API。内存占用低、响应快、模型随时能换。方案二的混合路由听起来挺美好，但小模型的判断准确率是个硬伤，目前没找到比直接全走远程更好的办法。方案三纯本地……除非有强制离线要求，否则别折腾了。
我现在日常就是方案一，一天调用量大概 200-300 次，算下来一天 ¥3.4 左右，比本地跑 GPU 机器便宜太多了。
