返回博客列表

1C1G VPS 服务编排：MetAPI 网关 + Nanobot + DERP 的资源取舍

2026年3月22日 | Ruichen Zhou | 约 7 分钟阅读
VPS Docker MetAPI Nanobot 自托管

系列文章：本文是「OpenClaw + 基础设施」系列的第 5 篇。

  1. OpenClaw (Clawdbot) 多端部署：Gateway + Tailscale Serve + Node 配对
  2. OpenClaw Cron 监控实战：QQ Bot 通知链路排障与 Prompt 调优
  3. OpenClaw 多节点运维：Token 持久化、Gateway 冲突排障
  4. Tailscale + ZeroTier + FRP：11 台跨国设备的三层 Overlay 分工
  5. 1C1G VPS 服务编排：MetAPI 网关 + Nanobot + DERP 的资源取舍（本文）

本文记录在 1C1G 香港 VPS 上同时编排 MetAPI、Nanobot 和 DERP 三个服务时的资源分配、路由治理、OOM 排查和服务拆分决策。

  • VPS 规格：1 核 CPU、1GB 内存、香港机房
  • 服务角色：MetAPI 作为统一模型入口，Nanobot 负责 QQ/Telegram 聊天机器人交互，DERP 提供 Tailscale 中继
  • 部署方式：Docker

环境与服务角色

这台 VPS 同时承担网络中继、模型网关和交互层服务三个角色，资源非常紧。三个服务的职责边界如下：

  • MetAPI：统一模型入口，向后对接不同 AI 模型提供商，把路由、鉴权和切换收口到网关层
  • Nanobot：聊天机器人的前端，负责接 QQ 和 Telegram 消息、转发上游请求并返回结果
  • DERP：Tailscale 在复杂网络环境下的中继节点，必须长期稳定在线

在 1C1G 的前提下，问题不在于单个服务能否启动，而在于它们并发运行时是否还保有足够的资源余量，以及故障是否会跨层放大。

MetAPI 模型路由的坑

MetAPI 的难点不在容器启动，而在模型路由整理。

首先，模型名并不总是等于真实模型名。有些站点给出的名字和实际后端使用的名字差异很大，如果不做重定向，配置上看似匹配，实际请求并不会命中预期后端。统一入口最怕这种“表面统一”，因为上层一旦接受了错误名称，后续所有路由判断都会跟着偏离。

第二个问题是命名不规范。例如 kimi-2.5 和 kimi-2-5，人眼能判断它们属于同一系列，系统未必会这样处理。命名一旦不统一，后续做别名、回退和筛选都会变得混乱。当时还发现有 19 条已经被禁用的路由混在配置里，结果是配置文件更长了，实际可用性却没有提高。

gpt-5.4 这类模型也存在特殊问题。它只会命中一条路由，不会自动使用 @high 级别的后备渠道。也就是说，表面上配置了多层回退，实际上某些模型名进入系统后，根本没有走到预期的高等级备份路径。

另一个问题来自容器重建。MetAPI 重建后会自动生成一些路由名，而这些自动生成的名字有时会和手工整理过的配置冲突。结果是维护者以为自己在维护一套清晰规则，系统实际上又叠加出一层默认配置。

最后做了一次批量整理：统一命名、去重、合并，并直接排除不匹配的低性能模型。完成这一轮之后，MetAPI 才真正成为一个“统一入口”，而不是一组名称相近、行为不同的路由集合。

Nanobot 在 1G 内存上的资源风险与 OOM 排查

MetAPI 的主要问题是配置复杂，Nanobot 的主要问题则是资源压力。

模型网关本身更像分发层，资源占用相对轻；聊天机器人直接承接会话、消息流和上游调用状态，对内存更敏感。它在 1GB 内存的机器上可以运行，但缺乏缓冲空间。

一个典型现象是：MetAPI 仍然可用，但 Nanobot 不再回复。这类问题最麻烦的地方在于，用户只能看到“机器人坏了”，但真实故障点可能并不在同一层。

后来的排查顺序基本固定为：

  1. 先确认容器是否仍然存活
  2. 查看日志中是否有明显异常
  3. 判断是否发生 OOM kill
  4. 单独验证 MetAPI 本身是否可用

如果 MetAPI 正常、上游模型也能返回结果，而 Nanobot 仍然沉默，那么问题通常就落在机器人这一层的状态管理或资源占用上。

1GB 内存的问题不在于“绝对跑不动”，而在于没有缓冲区。只要系统里同时有几个服务都想多占一些内存，风险就会立刻放大。Nanobot 这种直接面向消息流的服务，正是最容易把这种风险暴露出来的一层。

结论很直接：在 1G 内存上，Nanobot 不是不能跑，而是难以长期放心地跑。

Docker 配置持久化

这套服务全部使用 Docker 部署后，需要区分“文件是否持久化”和“配置语义是否保持一致”这两个问题。

MetAPI 的配置通过 volume mount 持久化，因此单纯重建容器不会清空挂载目录。这个层面上，手工修改并不是一次性的，容器删掉再起，数据仍然存在。

但这不意味着更新镜像没有风险。新镜像可能带来新的默认路由生成逻辑，而这些默认内容会在启动时与现有配置发生叠加，甚至覆盖原来整理好的手工规则。也就是说，数据卷保住了文件，不代表保住了配置语义。

因此，这类服务的更新流程需要保守处理：先备份挂载目录，再拉取新镜像；重建完成后，第一件事不是确认容器是否起来，而是检查路由是否仍然是预期的那一套。Docker 持久化解决的是文件留不留的问题，不解决新版本会不会重新解释配置的问题。

什么该留什么该搬

经过这一轮排查和整理，这台 1C1G VPS 更适合承担什么角色，已经比较清楚了。

DERP 必须保留。它轻量、关键，而且香港节点本身有明确价值。Tailscale 中继这类服务不适合为了节省一点资源再迁来迁去。

MetAPI 也适合保留。统一入口这件事本身成立，只要路由整理干净，资源占用相对可控，长期放在 VPS 上没有明显问题。它的价值在于把后端模型提供商收口，这件事越稳定越好。

真正应该迁走的是 Nanobot。聊天机器人是最直接暴露给用户的服务，但它又比网关更容易吃掉机器上本来就不多的资源余量。把它和 MetAPI、DERP 挤在同一台 1C1G 机器上，本质上是在用最脆弱的资源承载最容易产生体验问题的一层。

当前更合理的方案是：MetAPI 继续留在这台 VPS 上作为统一入口，DERP 继续常驻，聊天机器人类服务迁移到更大的机器上。网关和中继适合小机器，交互层不适合。

1C1G VPS 可以同时承载多个服务，但前提是每个服务的职责边界清晰、资源曲线可预期。DERP 和整理后的 MetAPI 符合这个条件，Nanobot 不符合。对最小规格 VPS 来说，关键不是尽量多塞服务，而是把不确定性最高的交互层移出去。

评论