Вимоги до self-hosted AI stack: з чого складається стек
Для self-hosted AI stack з LLM, RAG і векторною БД для команди з 10–20 співробітників потрібен сервер із 16 vCPU, 64 GB RAM, 1 TB NVMe та GPU щонайменше з 24 GB VRAM.
Повний локальний AI-стек складається не лише з моделі в Ollama або vLLM. У типовій архітектурі працюють LLM для генерації, embedding-модель для індексації документів, векторна БД, інтерфейс на кшталт Open WebUI, API-рівень, черга завдань і іноді reranker. Навантаження між ними розподіляється нерівномірно: GPU визначає швидкість відповіді LLM, RAM впливає на кешування та розмір індексу, а швидкий NVMe-диск критично важливий для векторної БД і масового завантаження файлів.
Базова схема працює так: користувач надсилає запит в Open WebUI, оркестратор шукає релевантні фрагменти в Qdrant, Milvus або pgvector, передає контекст до LLM і повертає відповідь. Якщо одночасно виконується переіндексація PDF, DOCX і бази знань, сервер отримує додаткове навантаження на CPU, RAM, диск та embedding-модель.
Які сервіси споживають ресурси
- LLM-інференс: основний споживач VRAM, GPU-обчислень і RAM за CPU-offload.
- Embedding-модель: може працювати на CPU, але GPU помітно пришвидшує обробку десятків тисяч документів.
- Векторна БД: активно використовує RAM для індексів, NVMe для зберігання сегментів і CPU для пошуку.
- Open WebUI, Flowise, Dify, Langfuse: зазвичай потребують мало ресурсів, але створюють підключення, логи та історію діалогів.
- PostgreSQL, Redis, object storage: потрібні для метаданих, черг, файлів і резервних копій.
Для вибору моделі та обсягу VRAM корисно звіритися з окремими вимогами до сервера для self-hosted AI та LLM: розмір моделі, контекст і формат квантування впливають на конфігурацію сильніше, ніж сам веб-інтерфейс.
Чому не можна підбирати сервер лише за моделлю
Модель Qwen, Llama або Mistral у форматі Q4 може займати 5–6 GB VRAM за розміру 7–8B параметрів, але це не всі витрати. Для контексту, KV-cache, CUDA-буферів, паралельних запитів та embedding-моделі потрібен запас. На GPU з 8 GB VRAM модель 8B запуститься, але за контексту 16–32K токенів і кількох користувачів затримка стане нестабільною.
Практичне правило: резервуйте 20–30% VRAM понад розмір завантаженої моделі, 25% RAM понад розрахункове споживання контейнерів і щонайменше 30% вільного місця на NVMe для компактації індексів, тимчасових файлів та оновлення образів.
Як підібрати сервер для AI stack за масштабом навантаження
Вимоги до сервера для AI stack визначаються кількістю одночасних діалогів, розміром моделі, обсягом бази знань і частотою індексації, а не лише кількістю зареєстрованих акаунтів.
Факт-блок: масштаб → конфігурація
Орієнтовні ціни нижче актуальні для ринку VPS і GPU-серверів станом на лютий 2025 року; для постійного корпоративного навантаження конфігурацію варто підтвердити у Valebyte перед замовленням.
Для 10–20 одночасних користувачів RAG-системи достатньо 16 vCPU, 64 GB RAM, 1 TB NVMe-диска та GPU з 24 GB VRAM.
| Масштаб навантаження | vCPU | RAM | Диск | Мережевий порт | Ціна, $/міс |
|---|---|---|---|---|---|
| 1–2 користувачі, LLM 7–8B, до 20 GB документів | 8 vCPU | 32 GB | 500 GB NVMe | 1 Gbps | орієнтовно від $45 |
| 10–20 користувачів, LLM 8–14B, до 200 GB документів | 16 vCPU | 64 GB | 1 TB NVMe | 1 Gbps | орієнтовно від $300 з GPU 24 GB VRAM |
| 20–50 користувачів, LLM 32B Q4, до 1 TB документів | 24 vCPU | 128 GB | 2 TB NVMe | 1–10 Gbps | орієнтовно від $700 з GPU 48 GB VRAM |
| Відділ 50–100 користувачів, кілька моделей і RAG | 32 vCPU | 256 GB | 4 TB NVMe RAID 1 | 10 Gbps | орієнтовно від $1,400 з 2×48 GB VRAM |
Як інтерпретувати розрахунок
Перший рядок підходить для особистого асистента, внутрішнього пошуку по документації та тестів із Qwen2.5 7B, Llama 3.1 8B або Mistral 7B у Q4. На CPU модель відповідатиме, але швидкість зазвичай обмежиться кількома токенами за секунду; для інтерактивного чату краще GPU від 12 GB VRAM.
Конфігурація для 10–20 осіб передбачає не 20 постійних генерацій, а 2–5 одночасних запитів. Якщо всі співробітники використовують AI в один час, додавайте GPU, а не лише vCPU. Для відділу доцільно рознести компоненти: окремий GPU-сервер для LLM, окремий вузол для Qdrant/PostgreSQL і сховища документів.
Шукаєте надійний сервер для своїх проєктів?
VPS від $10/міс і виділені сервери від $9/міс з NVMe, DDoS-захистом і підтримкою 24/7.
Переглянути пропозиції →Апаратні вимоги self-hosted AI stack для LLM: GPU, VRAM і CPU
Підбір hardware для self-hosted AI stack починається з вибору обсягу VRAM, адже саме він визначає максимальний розмір моделі, контекст і кількість одночасних відповідей.
Які моделі вміщуються у VRAM
Квантована модель 7–8B у Q4 зазвичай потребує 5–6 GB пам'яті, 14B — близько 10–12 GB, 32B Q4 — 20–24 GB, а 70B Q4 — від 40 GB без значного запасу під контекст. Реальне споживання залежить від рушія, квантування GGUF/AWQ/GPTQ, довжини контексту та KV-cache.
- 12 GB VRAM: 7–8B Q4, один-два інтерактивні користувачі, обмежений контекст.
- 24 GB VRAM: 8–14B з нормальним запасом або 32B Q4 з компромісами щодо контексту.
- 48 GB VRAM: 32B Q4/Q6, довгий контекст, кілька одночасних сесій.
- 2×48 GB VRAM: 70B Q4, розподіл навантаження між моделями або висока паралельність.
Докладний розрахунок для Ollama, включно з RAM за часткового вивантаження шарів на CPU, наведено в матеріалі про підбір RAM, VRAM і CPU для Ollama.
Що можна залишити на CPU
На CPU можна запускати Open WebUI, PostgreSQL, Redis, Qdrant, ingestion-пайплайни та невеликі embedding-моделі. Наприклад, bge-small або multilingual-e5-small індексують документи на 8–16 vCPU без GPU, хоча швидкість буде нижчою. CPU-інференс LLM виправданий для особистого використання, нічних завдань і рідкісних запитів, але для команди затримка генерації зазвичай неприйнятна.
Для CPU-only сервера обирайте сучасні ядра з частотою від 3.0 GHz і швидкий NVMe. 16 vCPU та 64 GB RAM — практичний мінімум для LLM 7–8B Q4 плюс RAG, але очікуйте близько 3–10 токенів/с залежно від процесора та рушія. GPU зазвичай забезпечує десятки токенів/с на моделях того самого класу.
Вимоги сервера для LLM, RAG і vector DB: RAM, індекс та NVMe
Вимоги до сервера для LLM, RAG і vector DB залежать від кількості чанків, розмірності embedding-векторів, типу індексу HNSW і потреби тримати гарячі сегменти в пам'яті.
Як оцінити обсяг векторної БД
Один embedding розмірності 768 у float32 займає приблизно 3 KB без службових даних. Мільйон векторів потребуватиме близько 3 GB лише для масиву значень; з HNSW-графом, payload, реплікацією та внутрішніми сегментами слід планувати 8–15 GB RAM і 10–20 GB диска на мільйон векторів. За розмірності 1536 вихідні цифри приблизно подвоюються.
Документи перетворюються на чанки. Якщо розбивати текст на фрагменти по 500 токенів з overlap 50 токенів, 1 GB чистого тексту може створити сотні тисяч чанків. PDF зі сканами додатково потребують OCR, а таблиці й зображення збільшують час ingestion-процесу.
# Пример минимальной конфигурации Qdrant для Docker Compose
services:
qdrant:
image: qdrant/qdrant:v1.12.5
volumes:
- /srv/qdrant:/qdrant/storage
ports:
- "6333:6333"
deploy:
resources:
limits:
memory: 16GQdrant, pgvector чи Milvus
Qdrant зручний як виділена векторна БД для RAG: він швидко запускається в контейнері та добре підходить для більшості баз знань до десятків мільйонів векторів. pgvector раціонально використовувати, якщо PostgreSQL уже застосовується в застосунку та потрібні транзакційні метадані поруч з embedding-векторами. Milvus частіше обирають для великих обсягів, високої паралельності та за наявності окремої інженерної команди.
Не розміщуйте LLM-файли, Docker-образи, Qdrant, PostgreSQL WAL і резервні копії на одному заповненому SSD. Для бази до 200 GB достатньо 1 TB NVMe, але за 1 TB вихідних документів плануйте щонайменше 2–4 TB NVMe й окреме S3-сумісне сховище. Для зберігання вихідних файлів і снапшотів стане в пригоді підхід із матеріалу про вимоги до MinIO та об'єктного S3-сховища.
Як розрахувати hardware для self-hosted RAG за документами й користувачами
Розрахунок hardware для self-hosted RAG варто починати з інвентаризації документів: їхнього обсягу, форматів, швидкості оновлення та очікуваної кількості одночасних пошукових запитів.
Формула планування
Для попереднього розрахунку використовуйте чотири величини: кількість документів, середню кількість чанків на документ, розмір embedding-вектора та коефіцієнт індексу. Наприклад, 100 000 документів по 20 чанків дають 2 млн векторів. За 768 float32 це близько 6 GB сирих векторів; з HNSW, payload і запасом розумно виділити 32 GB RAM та 100 GB NVMe саме для векторного сховища.
Якщо документи оновлюються щодня, важлива не лише місткість, а й швидкість переіндексації. Embedding-модель на GPU з 24 GB VRAM здатна обробляти великі черги значно швидше за CPU. Для регулярного ingestion створіть окремий worker, обмежте кількість паралельних завдань і запускайте масову індексацію поза піковими годинами.
Контекст, reranker і якість відповіді
RAG не повинен передавати в LLM увесь знайдений текст. Типова конфігурація: top_k=20 для первинного пошуку, reranker залишає 4–8 фрагментів, до моделі надходить 3 000–8 000 токенів контексту. Це зменшує витрати VRAM і час генерації, а відповідь залишається прив'язаною до джерел.
# Переменные для консервативного RAG-пайплайна
TOP_K=20
RERANK_TOP_N=6
CHUNK_SIZE=500
CHUNK_OVERLAP=50
EMBEDDING_BATCH_SIZE=64
OLLAMA_NUM_CTX=8192За збільшення OLLAMA_NUM_CTX з 8K до 32K KV-cache може зайняти кілька додаткових гігабайтів VRAM. Не збільшуйте контекст «про всяк випадок»: спочатку виміряйте середній обсяг документів, фактичний prompt і якість пошуку.
Специфікації сервера для OpenWebUI, Ollama і vector DB та розгортання
Специфікації сервера для OpenWebUI, Ollama і vector DB у production-середовищі передбачають окремі контейнери, постійні томи, обмеження ресурсів і закритий доступ до внутрішніх портів.
Базова схема контейнерів
На одному сервері можна почати з Docker Compose: Ollama обслуговує модель, Open WebUI надає SSO або локальні акаунти, Qdrant зберігає вектори, PostgreSQL — метадані та історію. Для команди не публікуйте Qdrant і Ollama безпосередньо в інтернет: назовні залишайте лише reverse proxy з TLS і автентифікацією.
services:
ollama:
image: ollama/ollama:latest
volumes:
- /srv/ollama:/root/.ollama
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 1
capabilities: [gpu]
openwebui:
image: ghcr.io/open-webui/open-webui:main
volumes:
- /srv/openwebui:/app/backend/data
environment:
- OLLAMA_BASE_URL=http://ollama:11434Які налаштування обов'язкові
- Увімкніть TLS на reverse proxy та забороніть анонімну реєстрацію.
- Обмежте розмір завантажуваного файлу, наприклад до 50–100 MB, щоб один PDF не заповнив чергу OCR.
- Налаштуйте ліміти Docker: Qdrant не повинен витісняти Ollama з RAM, а Open WebUI не повинен отримувати доступ до GPU без потреби.
- Зберігайте API-секрети та паролі PostgreSQL у змінних середовища або secret-сховищі, а не у публічному Compose-файлі.
- Розділяйте ролі: користувачі чату не повинні мати адміністративний доступ до колекцій векторної БД.
Під час розгортання кількох внутрішніх сервісів корисні загальні принципи з посібника з підбору hardware для self-hosted застосунків: резерв ресурсів, ізоляція контейнерів і вимірювання реального навантаження важливіші за номінальну кількість акаунтів.
Залізо для локального AI stack: мережа, диск і резервні копії
Залізо для локального AI stack має забезпечувати не лише продуктивність GPU, а й передбачуваний I/O, безпечне зберігання документів і відновлення векторної БД.
Диск і мережа без вузьких місць
Для персонального сервера достатньо порту 1 Gbps і 500 GB NVMe. Для відділу з регулярним завантаженням файлів, окремим object storage та кількома вузлами краще використовувати 1–10 Gbps. Зовнішній трафік самого чату невеликий: відповідь у 1 000 токенів займає лічені кілобайти, але завантаження датасетів, моделей по 5–50 GB і резервних копій швидко споживає канал.
Не використовуйте HDD як активний диск для Qdrant або PostgreSQL. Жорсткі диски підходять для холодних архівів, але HNSW-пошук, WAL і компактація сегментів потребують низької затримки NVMe. RAID 1 захищає від відмови одного накопичувача, проте не замінює резервне копіювання.
Що включити до бекапу
Щодня зберігайте PostgreSQL, конфігурації, колекції Qdrant і вихідні документи. Моделі Ollama можна завантажити повторно, тому їх допустимо не включати до щоденного бекапу, якщо збережено теги й версії. Для 1 TB робочих даних тримайте щонайменше 2–3 TB резервного простору з історією версій.
Окремий сервер або об'єктне сховище знижує ризик втрати бази через помилку адміністратора, шифрувальник або пошкодження тому. Практику снапшотів, дедуплікації та розрахунку місткості розкриває стаття про вимоги до Proxmox Backup Server.
Як перевірити продуктивність self-hosted AI stack
Вимоги self-hosted AI stack підтверджуються навантажувальним тестуванням: вимірюйте токени за секунду, TTFT, затримку пошуку, споживання VRAM та IOPS під час паралельних запитів.
Які метрики вважати нормальними
Для внутрішнього чату цільовий TTFT — до 2–4 секунд за звичайного запиту, швидкість генерації — від 15 токенів/с на користувача, а пошук у векторній БД — до 300–500 мс без reranker. Ці орієнтири залежать від моделі та якості відповіді: модель 32B буде повільнішою за 8B, але може краще працювати зі складними інструкціями.
Під час тесту запускайте щонайменше 3–5 паралельних діалогів, окремо перевіряйте масове завантаження документів і стежте за чергою. Якщо VRAM заповнена більш ніж на 90%, а p95 TTFT зростає у кілька разів, зменште контекст, знизьте паралельність або додайте GPU.
# Наблюдение за GPU и контейнерами
watch -n 1 nvidia-smi
docker stats --no-stream
iostat -xz 1Для production корисні Prometheus і Grafana: збирайте GPU utilization, температуру, VRAM, CPU steal, вільне місце, p95 latency та кількість запитів. Сповіщення за 80% зайнятого диска дасть змогу розширити NVMe до того, як Qdrant припинить компактацію сегментів.
Часті запитання
Чи можна запустити LLM, RAG і векторну БД без GPU?
Так, для 1–2 користувачів CPU-only стек працює на 8–16 vCPU, 32–64 GB RAM і NVMe-диску. Модель 7–8B у Q4 відповідатиме повільніше за GPU, часто в діапазоні 3–10 токенів за секунду. CPU підходить для тестів, особистої бази знань і періодичної індексації, але не для активного чату команди.
Скільки VRAM потрібно для RAG-системи на 20 співробітників?
Для 10–20 співробітників практичний мінімум — GPU з 24 GB VRAM, 16 vCPU і 64 GB RAM. Такий обсяг дає змогу обслуговувати модель 8–14B із запасом для KV-cache та embedding-завдань. Якщо потрібні модель 32B, контекст понад 16K токенів або 5+ одночасних генерацій, обирайте 48 GB VRAM.
Чи потрібен окремий сервер для Qdrant або pgvector?
До 1 млн векторів Qdrant або pgvector можна тримати разом із LLM на сервері з 64 GB RAM і 1 TB NVMe, якщо GPU-інференс не впирається в CPU. За 5–10 млн векторів, активної переіндексації або понад 20 одночасних користувачів краще винести векторну БД на окремий вузол із 64–128 GB RAM.
Який диск потрібен для зберігання документів і векторного індексу?
Для особистого RAG-стека зазвичай достатньо 500 GB NVMe, а для команди зі 100–200 GB вихідних документів краще планувати 1 TB NVMe. На 1 млн векторів розмірності 768 закладайте приблизно 10–20 GB диска для індексу та метаданих. Залишайте щонайменше 30% вільного простору для компактації та резервних копій.
Висновки
Для особистого RAG достатньо 8 vCPU, 32 GB RAM і 500 GB NVMe, а для команди з 10–20 осіб обирайте 16 vCPU, 64 GB RAM, 1 TB NVMe та GPU з 24 GB VRAM. Якщо база знань перевищує 1 млн векторів або потрібна модель 32B, переходьте на 48 GB VRAM і 128 GB RAM або розділяйте LLM та векторну БД між окремими серверами.
NVMe VPS з активацією за 60 секунд: повний root-доступ, 20+ локацій, оплата карткою або криптовалютою.
Обрати тариф
