1.9 GB 内存的极限运维：跑一个 AI 中枢需要多少内存？

2026-05-17 · 约 8 分钟

腾讯云轻量服务器，1.9 GB 内存，50G 硬盘，2 核 CPU。月费 68 元。

现在这上面跑着：一个 AI Agent 中枢（OpenClaw Gateway），一个 Nginx 反向代理，一个 Chrome Headless 浏览器（带 CDP 调试端口），Playwright 自动化引擎，Node.js 运行时，外加系统日志、安全监控、定时任务调度。

经常有人问我为什么不升级配置。答案很简单：68 块一个月够用了，为什么花 300？

但「够用」的背后是一整套让 1.9 GB 活下去的策略。这篇文章拆解它们。

先看负载：这 1.9 GB 里装着什么

写这篇文章时，实时数据：

$ free -h
              total    used    free    shared  buff/cache  available
Mem:          1.9Gi    1.4Gi   169Mi   5.6Mi    579Mi       561Mi
Swap:         9.9Gi    1.1Gi   8.8Gi

$ ps aux --sort=-%mem | head -6
%MEM  COMMAND
34.3% /root/.nvm/versions/node/v22.22.2/bin/node   ← OpenClaw Gateway
 9.2% node                                              ← 子 agent 进程
 3.1% YDService                                         ← 腾讯云监控
 2.8% chrome --headless --remote-debugging-port=9222    ← CDP 浏览器
 1.8% node / chrome-devtools-mcp                        ← CDP 桥接

算笔账：

进程	内存占比	约合	说明
OpenClaw Gateway	34.3%	~650 MB	AI 中枢主进程，最重
子 Agent 进程	9.2%	~175 MB	隔离执行任务时 fork
Chrome Headless	2.8%	~53 MB	幸运时只有这个数
CDP 桥接	1.8%	~34 MB	Node.js ↔ Chrome
云监控	3.1%	~59 MB	腾讯云自带，删不掉
系统 + Nginx + 其他	~20%	~380 MB	systemd, journald, nginx
合计	~71%	~1.35 GB	外加 579 MB 缓存

1.9 GB 里，纯物理占用约 1.35 GB，buffer/cache 占 579 MB。available 剩 561 MB——勉强还能 fork 一个子进程，再开一个 Chrome 就危险了。

系统负载 0.40，非常健康。瓶颈不在 CPU，在内存。

策略一：Chrome 是最大变量

Chrome Headless 的内存占用极度不稳定。刚启动时 50 MB，跑一个网页截图可能飙到 300 MB，长时间运行后内存碎片化会更糟。

所以有一条定时规则：

# 每天凌晨 4 点执行
pkill -9 -f chromium.*headless
sleep 2
# 下次需要时会自动拉起

粗暴但有效。凌晨 4 点没人用 AI，杀掉的 Chrome 会在第二天第一次用到浏览器功能时被 OpenClaw 自动重启。这样就避免了 Chrome 内存泄漏积累。

另外，Chrome 启动参数也做了限制：

chrome \
  --headless \
  --disable-gpu \
  --disable-dev-shm-usage \
  --no-sandbox \
  --max_old_space_size=128 \
  --remote-debugging-port=9222

--max-old-space-size=128 限制了 V8 堆上限 128 MB——正常情况下 Chrome 的 JS 引擎会无限增长，这个参数强行截断。代价是页面复杂时可能崩溃，收益是永远不会吃掉所有内存。

策略二：Swap 不是敌人

9.9 GB swap，1.1 GB 已用。很多运维文章告诉你 "swap 应该为 0，有 swap 就是性能有问题"。这在 2026 年的云服务器上是教条。

真实情况：当系统有 1.9 GB 物理内存和多进程负载时，swap 是救命稻草，不是性能杀手。数据证明：

$ cat /proc/loadavg
0.40 0.32 0.28

负载极低。为什么？因为被 swap 换出去的，是那些长时间不用的内存页——Chrome 渲染完某张截图后的缓存页、Node.js 冷代码路径。真正频繁访问的热数据还在物理内存里。

Linux 内核比我们聪明。它不会把正在用的数据 swap 出去。只要 available 不归零，swap 是健康的。

    🔄 判断标准：关注 available（可用内存），不是 free（空闲内存）。

    free = 169 MB 看起来危险，但 available = 561 MB 完全够用。

    buffer/cache 随时可以被回收，不要把它们当浪费。

策略三：零依赖的技术栈省内存

官网 jingxuanyoupin.icu 是纯 HTML/CSS/JS，零依赖。如果用了 React，需要额外的构建工具链、node_modules、Webpack Dev Server——至少多占 200 MB 内存。用了 WordPress 或者 Ghost CMS，需要 PHP-FPM + MySQL，至少再加 400 MB。

选择零依赖不是意识形态，是工程判断：

4 个 HTML 页面 + 1 个 CSS 文件 + 2 个 JS 文件 = 不到 50 KB 总大小
Nginx 直接 serve 静态文件，0 毫秒服务端渲染
没有数据库连接池，没有缓存层，没有消息队列
改内容就改 config.js 一个文件，不用进 CMS 后台

每省掉一层抽象，就省掉 50-200 MB 内存。三层加起来，就是这台机器能跑 AI 中枢而不是只能跑一个 WordPress 的原因。

策略四：Nginx 的反向代理复用

这台机器上只有一个 Nginx 配置文件：

$ ls /etc/nginx/sites-enabled/
wechat-mp-bridge

但它的路由规则覆盖了所有服务：

/ → 官网静态文件
/wechat → 微信公众号 Webhook（Node.js 独立端口）
/__openclaw__/ → OpenClaw Gateway（内部端口 12078）
SSH 端口保持 22，Chrome CDP 只监听 localhost

关键点：Chrome CDP 端口（9222）不开公网。所有浏览器操作通过 OpenClaw 的 MCP 协议桥接，Nginx 只暴露需要暴露的服务。这不仅省资源，也是安全基线。

策略五：定时任务分散负载

如果上午 9 点同时跑微信公众号发布、百度统计日报、RSS 抓取、L3 向量入库——内存峰值会瞬间击穿。

所以 cron 做了时间错峰：

时间	任务	预计内存增量
03:00	记忆梦境晋升	+30 MB
04:00	Chrome 内存清理	-300 MB（释放）
08:00	L1 RSS 抓取	+50 MB
09:00	微信日更发布	+40 MB
09:00	百度统计早间日报	+25 MB
16:00	L1 RSS 第二次抓取	+50 MB
22:00	百度统计晚间日报	+25 MB
每 6h	RSS L3 向量摄取	+80 MB
每 3d	记忆 L2 整合	+60 MB

每个任务都是独立子进程，执行完就释放。错峰后，任何一个时刻通常只有一个定时任务在跑。内存峰值可控。

红线：什么时候该慌

运行了几个月，我总结了一套「该慌了」的判断标准：

available < 100 MB 持续 5 分钟：该手动杀 Chrome 了
swap 使用量突然跳升 500 MB 以上：有进程内存泄漏
OOM Killer 日志出现：已经来不及了，查 dmesg 找凶手
负载持续 > 1.0：不是内存问题，是 CPU 竞争

目前这台机器从未触发过 OOM Killer。每天凌晨 4 点的 Chrome 清理 + 合理的任务错峰，把最危险的情况提前规避了。

承认局限性

1.9 GB 不是万能的。以下事情做不了：

本地跑大模型推理。不用说 1.9 GB，19 GB 都不一定够。推理走 API 调用，这是架构选择不是妥协。
同时跑多个 Chrome 实例。一个 Chrome 已经够呛，并行截图必须串行化。
Docker 化。Docker 本身的 overlay 存储和容器开销会让可用内存从 561 MB 跌到 300 MB 以下。裸机部署是唯一选择。
实时视频转码。ffmpeg 会吃光所有资源。短视频生成放在低频时段跑。

知道什么做不了，比知道什么能做更重要。这本身就是在 1.9 GB 上的生存法则。

所以，要不要升级？

每月 68 到 300 块的跳跃，能买到的只是从 2 核 2G 到 4 核 8G。

目前所有的自动化产线都在稳定运行。微信公众号每天 9 点准时推送，百度统计日报早晚各一次，记忆系统三层全绿。负载 0.4，没有 OOM 记录。升级配置的理由是什么？

当有一天，抖音自动化上线需要长期驻留 ffmpeg 进程，或者用户量增长到每天数千 PV 需要更多并发——那时候升级是合理的。

但在此之前，1.9 GB 不是限制，是纪律。它逼着你做零依赖的选择，逼着你设计错峰的调度，逼着你理解每个进程的内存模型。

这也是一种架构审美：用最少的资源，跑最多的东西。

标签：DevOps · 服务器运维 · 内存优化 · Chrome Headless · Nginx · 零依赖

🛠️ 需要类似系统？

AI系统集成 · 自动化管线开发 · 全栈定制——咨询免费，能做就做。

💬 微信：星尘和光文化传媒 ｜ 🌐 官网 →

📱 关注公众号「星尘和光文化传媒」

每周推送 AI 实战技术文章、全栈开发案例和自动化管线拆解。
不写广告，只写踩坑录。