用于大规模自建 RAG 的 VPS

在笔记本上拿两百份文档做的 RAG demo，感觉毫不费力。可一旦你把它对准一个真实的语料库——一家公司的文档、多年的工单、一个真正的知识库——整件事就变成了一个内存问题。不是 CPU 问题，是内存问题。

这里有个大多数主机页面都略过的点：**快速检索需要把索引放在 RAM 里。**每一块文本都会变成一个 embedding——一个几百到几千个数字宽的向量——而搜索意味着把你的查询快速地与它们全部比对。放在磁盘上也能用，但每次查询都要交一笔延迟税，而低延迟检索本来就是你选择自建的原因。

老实算一算规格

去测你自己的语料库——维度和索引类型会让结果差很多——不过先给个大致感觉：

• 几十万个 embeddings——2–4 GB。一个个人知识库。这个用不着 Pro；小一点的套餐就行。
• 几百万个——加上应用、模型客户端和周边的操作系统，按 16–32 GB 来规划。一个正经的公司知识库。Pro-32 或 Pro-48 从这里开始变得合理。
• 几千万个，或高维向量——48 GB 起步，超过大约 80 GB 你就得把索引拆到多台服务器上了。海量文档资产、多租户检索、同时有好几个索引处于热态。

如果你想看细节，我们在这里写出了完整的内存曲线。

为什么高内存和无需KYC要凑在一起

租 48 GB 内存很容易。用加密货币、不做身份核验地租下来就不容易了——大多数便宜卖大内存的主机商，背后都要一张银行卡和一份 KYC 表单。你的 embeddings 不是抽象的数字；它们编码着自己来源的那些文本。你的文档、你客户的内容，都变成了向量。如果这些数据敏感到你要私密付款的地步，那么一个托管的向量云会让这一切前功尽弃——一个把服务器绑到你身份上的主机商也一样。

这一组合——高内存、独立IP、加密货币、无需KYC、每晚备份——正是 Pro 系列的用武之地。它不是每 GB 最便宜的，如果你不需要隐私，别处能找到更便宜的内存。但如果索引就是你的产品、而且它不能外流，这就是合适的形态。

从哪里开始

选一个能容下索引以及它周边一切（应用、模型客户端、增长空间）的套餐。对大多数真实语料库来说，那就是 Pro-48（48 GB）；大的则上 Pro-64 或 Pro-80。先加载一个样本，盯住内存，按你实测到的数字来定规格——而不是你担心的那个数字。

如果你的检索是一个更大的 AI 代理系统的一部分，同一台机器往往还会装下整个代理集群——一个 48 GB 的套餐就是这样悄悄变成 64 GB 的。