用於多代理系統和代理叢集的 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。