EQVPS

Self-hosted RAG на масштабі: скільки RAM реально їсть векторний індекс

Aug 9, 2026 · 2 min read · EQVPS Team

Кожен туторіал з RAG крутиться на ноутбуці з парою сотень документів, і здається, що все легко. Потім ви скеровуєте його на реальний корпус — доки компанії, роки тікетів, базу знань — і раптом уся розмова лише про памʼять.

RAG масштабується не за CPU. Він масштабується за RAM.

Чому індекс хоче памʼять

Пошук працює так: кожен шматок тексту перетворюється на ембеддинг — вектор із сотень-тисяч чисел. Пошук — це порівняння вашого вектора-запиту з усіма, швидко. «Швидко» — ключове: для низької латентності індекс має жити в RAM. На диску працює, але кожен запит платить штраф, а швидкий пошук і був сенсом self-host.

Тож рахунок за памʼять росте від двох речей: скільки у вас шматків і наскільки широкий кожен вектор.

Реальні числа, грубо

Міряйте своє — розмірність і тип індексу сильно рухають це, — але як стартове відчуття:

Мульти-агентна система, що ще й тримає великий індекс, складає обидва рахунки на одну машину — ось так 32-гіговий тариф тихо перетворюється на 64-гіговий.

Вибір рушія, коротко

Якщо вже крутите Postgres, pgvector — варіант найменшого зусилля: розширення, а не новий сервіс на догляд. Коли векторів мільйони і потрібен швидкий фільтрований пошук, окремий рушій на кшталт Qdrant чи Weaviate виправдовує окремий процес. Не переускладнюйте в перший день; ганяйте що вже експлуатуєте й виділяйте, коли пошук реально загальмує.

Навіщо взагалі self-host

Дві причини, з яких це реально роблять, і жодна не «заощадити пару доларів»:

Приватність. Ембеддинги не абстрактні — вони кодують текст, з якого зроблені. Ваші доки, контент клієнтів, внутрішні нотатки, перетворені на вектори й відправлені на сервери третьої сторони. Self-host тримає це на машині під вашим контролем. Якщо дані досить чутливі, щоб ви ще й платили криптою без KYC, managed векторна хмара руйнує весь сенс.

Фіксована ціна. Managed векторні сервіси рахують за збереженими векторами й запитами. VPS — одне місячне число, і його можна довбати скільки завгодно. На масштабі передбачуване бʼє лічильник.

Що це означає для sizing

Почніть із заміру корпусу, а не з здогадки. Візьміть число ембеддингів і розмірність, завантажте вибірку, подивіться резидентну памʼять, екстраполюйте. Потім беріть тариф із запасом під індекс плюс усе навколо — застосунок, клієнт моделі, місце на ріст.

Для чого завгодно за парою мільйонів векторів, збережених приватно, лінійка Pro дає 32–80 ГБ з виділеним IP і нічними бекапами — що важливо, коли індекс і є продукт і втратити його боляче.

FAQ

Чому RAG потрібно стільки RAM?

Швидкому векторному пошуку потрібен індекс у памʼяті. Кожен шматок тексту стає ембеддингом — вектором із сотень-тисяч чисел — і на мільйонах шматків це набігає. Тримайте індекс на диску — латентність пошуку підскакує; зберегти весь сенс self-host (швидкість + контроль) означає тримати його в RAM.

Скільки RAM під конкретний корпус?

Грубо: пара сотень тисяч ембеддингів влазить у 2–4 ГБ. Пара мільйонів, із застосунком і ОС навколо, — 16–32 ГБ. Десятки мільйонів чи вектори великої розмірності — територія 48–80 ГБ, а далі — по кількох машинах. Розмірність і тип індексу сильно гойдають це, тож міряйте своє.

pgvector чи окремий рушій на кшталт Qdrant?

Якщо вже крутите Postgres, pgvector — шлях найменшого зусилля: одне розширення, одна база. Для мільйонів векторів із важкою фільтрацією спеціалізований рушій виправдовує окремий сервіс. Почніть з того, що вже експлуатуєте; переїжджайте, коли пошук загальмує.

Навіщо self-host замість managed векторного сервісу?

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

← Back to blogSee plans & pricing →

Коментарі

Поки немає коментарів. Будьте першим.

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

Коментарі проходять модерацію перед публікацією.