Скільки 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

Коментарі

Залишити коментар