用于多代理系统和代理集群的 VPS

代理托管最常见的错误，是按一个代理来估算规格。有人跑了单个代理，看它用了 400 MB，就下结论说代理托管很便宜。然后他扩成一个真正的团队，凌晨 3 点机器开始疯狂 swap。

一个代理确实便宜。但那不是有意思的情况。

内存究竟去了哪

一个只朝模型发 API 调用的代理很轻——它大部分时间都在等网络。在小套餐上跑一打这样的代理，你根本不会察觉。

内存是在代理持有状态时消失的。每一轮都在增长的历史。好几个代理读写的一份工作集。同一个进程里作长期记忆用的向量库。当架构不再是「调 API，忘掉」而变成「记住、协调、交接」的那一刻，约束就是内存——而不是 CPU。CrewAI、LangGraph、AutoGPT 式的循环，认真起来都往这个方向走。吃内存的不是框架，而是状态。我们在这里深挖了具体数字。

大致的规格估算

• 轻量、受 API 限制的代理 —— 你不需要 Pro；一个 NAT 或独立IP套餐（$3–20）绰绰有余。本页剩下的内容跳过就行。
• 一个真正的团队（5–10 个代理），带共享记忆再加一个好用的向量库 —— Pro-32（32 GB）是最佳落点。大多数集群都落在这里。
• 更大的集群、更长的历史、一个上百万条的记忆索引 —— Pro-64（64 GB）。到了这里，一台机器就能替掉你原本要来回摆弄的那三台小的。
• 集群外加并置的服务，或者代理外加本地推理 —— 最高到 Pro-80（80 GB）。

从你以为需要的规格再往下选，盯着 htop 看上一天，看到 swap 再往上扩。往高了猜纯属浪费钱。

为什么是这种形态的主机

一个自行开通或管理自己服务器的集群，想要一个不需要人就能驱动的 API——而且越来越想连付款也不需要人。高内存、一个独立IP、加密货币付款、无需KYC，再加上整件事都能由一个代理通过 MCP 下单：这种组合很少见，而它正是 Pro 系列打造的初衷。它不是每 GB 最便宜的，如果你的代理很轻，你是真的不需要它。但对于一个持有状态、看重隐私的严肃系统，它就是对的选择。

到了那一步，Pro-32 能覆盖一个真正的团队；随着集群壮大，往上扩到 64 或 80 GB。