Сколько RAM реально нужно моему RAG?

Растёт от числа эмбеддингов и ширины вектора. Пара сотен тысяч кусков влезает в 2–4 ГБ; пара миллионов, с приложением и ОС вокруг, — 16–32 ГБ; десятки миллионов — 48 ГБ и дальше. Замерьте выборку, посмотрите резидентную память, экстраполируйте — не завышайте догадкой, переплатите.

Почему не managed векторный сервис?

Две причины self-host: эмбеддинги кодируют приватные данные (доки, заметки, контент клиентов), и держать их на своей машине важно; и цена фиксированная — managed считает по векторам и запросам, VPS это одно месячное число, которое можно долбить сколько угодно.

pgvector или отдельный движок?

Если уже крутите Postgres, pgvector — путь наименьшего усилия, одно расширение. Для миллионов векторов с тяжёлой фильтрацией специализированный движок вроде Qdrant оправдывает отдельный сервис. Начните с того, что эксплуатируете; выделяйте, когда поиск затормозит.

Нужен ли GPU для RAG?

Нет. Retrieval — это работа CPU + RAM: сравнение векторов, не генерация текста. Генерацию делает ваша LLM (API или отдельный хост модели). High-memory CPU-машина — ровно правильная форма для половины с поиском.

VPS для self-hosted RAG на масштабе

RAG перестаёт быть демкой на ноутбуке, когда корпус реальный. Векторный индекс хочет RAM, а эмбеддинги — это ваши приватные данные. Разбираем sizing и почему подходит high-memory без KYC. От $55/мес.

Демо RAG на ноутбуке с двумя сотнями документов кажется лёгким. Потом вы направляете его на реальный корпус — доки компании, годы тикетов, настоящую базу знаний — и всё превращается в задачу про память. Не про CPU. Про память.

Вот что большинство хостинг-страниц пропускают: быстрому поиску нужен индекс в RAM. Каждый кусок текста становится эмбеддингом — вектором из сотен-тысяч чисел — и поиск означает сравнение вашего запроса со всеми, быстро. На диске работает, но каждый запрос платит налог латентностью, а быстрый поиск и был причиной self-host.

Sizing, честно

Мерьте свой корпус — размерность и тип индекса сильно двигают это, — но как стартовое ощущение:

Пара сотен тысяч эмбеддингов — 2–4 ГБ. Личная база знаний. Pro для этого не нужен, хватит меньшего тарифа.
Пара миллионов — с приложением, клиентом модели и ОС вокруг закладывайте 16–32 ГБ. Серьёзная корпоративная база. Здесь начинает иметь смысл Pro-32 или Pro-48.
Десятки миллионов или векторы большой размерности — 48 ГБ и выше, а за ~80 ГБ вы разносите индекс по нескольким серверам.

Полную кривую RAM расписали здесь.

Почему high-memory и no-KYC вместе

Арендовать 48 ГБ RAM легко. Арендовать криптой и без проверки личности — нет. Эмбеддинги не абстрактны — они кодируют текст, из которого сделаны. Ваши доки, контент клиентов, превращённые в векторы. Если данные достаточно чувствительны, чтобы платить приватно, managed векторное облако рушит смысл — как и хостер, привязывающий сервер к вашей личности.

Эта комбинация — много памяти, выделенный IP, крипта, no-KYC, ночные бэкапы — и есть смысл линейки Pro. Она не самая дешёвая за гигабайт, и если приватность не нужна — RAM найдётся дешевле. Но если индекс и есть ваш продукт и он не может уйти — это подходящая форма.

С чего начать

Берите тариф с запасом под индекс плюс всё вокруг — приложение, клиент модели, место на рост. Для большинства реальных корпусов это Pro-48 (48 ГБ); крупный уходит на Pro-64 или Pro-80. Сначала загрузите выборку, посмотрите память, берите по замеренному числу — не по тому, которого боялись.

Если поиск — часть большей агентной системы, та же машина часто держит и флот агентов — вот так 48-гиговый тариф тихо становится 64-гиговым.

VPS для self-hosted RAG на масштабе

Sizing, честно

Почему high-memory и no-KYC вместе

С чего начать

FAQ

Комментарии

Оставить комментарий