1C1G VPS 服务编排：MetAPI 网关 + Nanobot + DERP 的资源取舍
更新（2026-08-01）：本文记录的 MetAPI + Nanobot + DERP 架构已演进。香港 VPS（
vps-hk）现跑 Kuma（服务监控）+ derper + rustdesk；德国 netcup VPS（vps-de）现跑 sub2api（模型网关）+ xray + home-probe。MetAPI/Nanobot 已被 sub2api 替代，DERP 保留。设备命名也从hk-cn2/netcup统一为vps-hk/vps-de。下文保留原始记录作为历史参考。
当时这台 VPS 是 1 核 CPU、1GB 内存、香港机房，用 Docker 部署，同时跑三个服务：
- MetAPI：统一模型入口，向后对接不同 AI 模型提供商，路由、鉴权和切换由网关集中管理
- Nanobot：聊天机器人前端，负责接 QQ 和 Telegram 消息、转发上游请求并返回结果
- DERP：Tailscale 在复杂网络环境下的中继节点，必须长期稳定在线
MetAPI 模型路由的问题
MetAPI 的难点不在容器启动，而在模型路由整理。
一是模型名并不总是等于真实模型名。有些站点给出的名字和实际后端使用的名字差异很大，不做重定向的话，配置上看似匹配，实际请求并不会命中预期后端。
二是命名不规范，例如 kimi-2.5 和 kimi-2-5。人眼能判断它们属于同一系列，系统不会。当时还发现有 19 条已经被禁用的路由混在配置里，配置文件更长了，实际可用性没有提高。
gpt-5.4 这类模型还有特殊问题：它只会命中一条路由，不会自动使用 @high 级别的后备渠道。表面上配置了多层回退，某些模型名进来后走不到预期的高等级备份路径。
容器重建也会出问题。MetAPI 重建后会自动生成一些路由名，有时会和手工整理过的配置冲突，在已有规则上叠出一层默认配置。
最后做了一次批量整理：统一命名、去重、合并，直接排除不匹配的低性能模型。整理完成后，配置里名称相近、行为不同的路由减少了。
Nanobot 的资源压力与 OOM 排查
MetAPI 像分发层，资源占用相对轻；聊天机器人直接承接会话、消息流和上游调用状态，对内存更敏感。Nanobot 在 1GB 内存的机器上可以运行，但机器上没有缓冲空间，只要几个服务同时都想多占一些内存，这种直接面向消息流的服务最先受影响。
一个典型现象是：MetAPI 仍然可用，但 Nanobot 不再回复。用户只能看到“机器人坏了”，真实故障点可能不在同一层。排查顺序后来固定为：
- 先确认容器是否仍然存活
- 查看日志中是否有明显异常
- 判断是否发生 OOM kill
- 单独验证 MetAPI 本身是否可用
如果 MetAPI 正常、上游模型也能返回结果，而 Nanobot 仍然沉默，问题通常落在机器人这一层的状态管理或资源占用上。
Docker 配置持久化
MetAPI 的配置通过 volume mount 持久化，单纯重建容器不会清空挂载目录，手工修改在容器删掉再起之后仍然存在。
但更新镜像有风险：新镜像可能带来新的默认路由生成逻辑，这些默认内容会在启动时与现有配置叠加，甚至覆盖手工整理过的规则。数据卷保住了文件，保不住配置语义。
所以更新流程是：先备份挂载目录，再拉取新镜像；重建完成后，先确认容器启动且状态正常，再检查路由是否仍然是预期的那一套。
什么该留什么该搬
DERP 当时决定保留。它轻量，香港节点本身有明确价值，不适合为了省一点资源迁来迁去。
MetAPI 当时决定留在这台机器上。路由整理干净之后资源占用可控，后端模型提供商也由网关集中管理。
Nanobot 当时决定迁走。聊天机器人直接面向用户，又最容易吃掉机器上不多的资源余量；把它和 MetAPI、DERP 挤在同一台 1C1G 机器上，是用最脆弱的资源承载最容易出体验问题的一层。当时的最终方案是：MetAPI 留在这台 VPS 上作为统一入口，DERP 常驻，聊天机器人类服务迁到更大的机器上。