Self hosted AI stack requirements: из чего складывается стек
Для self-hosted AI-стека с LLM, RAG и векторной БД на команду из 10–20 сотрудников нужен сервер с 16 vCPU, 64 GB RAM, 1 TB NVMe и GPU минимум с 24 GB VRAM.
Полный локальный ИИ-стек состоит не только из модели в Ollama или vLLM. В типовой схеме работают LLM для генерации, модель эмбеддингов для индексации документов, векторная БД, интерфейс вроде Open WebUI, API-слой, очередь задач и иногда reranker. Нагрузка распределяется между ними неравномерно: GPU определяет скорость ответа LLM, RAM влияет на кеширование и размер индекса, а быстрый NVMe-диск критичен для векторной БД и массовой загрузки файлов.
Базовая схема выглядит так: пользователь отправляет вопрос в Open WebUI, оркестратор ищет релевантные фрагменты в Qdrant, Milvus или pgvector, передаёт контекст в LLM и возвращает ответ. Если одновременно идёт переиндексация PDF, DOCX и базы знаний, сервер получает дополнительную нагрузку на CPU, RAM, диск и эмбеддинг-модель.
Какие сервисы потребляют ресурсы
- LLM-инференс: основной потребитель VRAM, GPU-вычислений и RAM при CPU-offload.
- Embedding-модель: может работать на CPU, но GPU заметно ускоряет обработку десятков тысяч документов.
- Векторная БД: активно использует RAM для индексов, NVMe для хранения сегментов и CPU для поиска.
- Open WebUI, Flowise, Dify, Langfuse: обычно требуют мало ресурсов, но создают подключения, логи и историю диалогов.
- PostgreSQL, Redis, object storage: нужны для метаданных, очередей, файлов и резервных копий.
Для подбора модели и VRAM полезно сверяться с отдельными требованиями к серверу для self-hosted ИИ и 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 для компактации индексов, временных файлов и обновлений образов.
Сервер для ИИ стека: требования по масштабу нагрузки
Сервер для ИИ стека требования определяются числом одновременных диалогов, размером модели, объёмом базы знаний и частотой индексации, а не только количеством зарегистрированных аккаунтов.
Факт-блок: масштаб → спека
Ориентировочные цены ниже относятся к рынку 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 одновременных запросов. Если все сотрудники используют ИИ в одно время, добавляйте GPU, а не только vCPU. Для отдела разумнее разнести компоненты: отдельный GPU-сервер под LLM, отдельный узел под Qdrant/PostgreSQL и хранилище документов.
Ищете надёжный сервер для ваших проектов?
VPS от $10/мес и выделенные серверы от $9/мес с NVMe, DDoS-защитой и поддержкой 24/7.
Смотреть предложения →Self hosted AI stack hardware для LLM: GPU, VRAM и CPU
Self hosted AI stack hardware начинается с выбора 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 server requirements: RAM, индекс и NVMe
LLM RAG vector DB server requirements зависят от числа чанков, размерности эмбеддингов, типа индекса 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 уже используется для приложения и нужны транзакционные метаданные рядом с эмбеддингами. Milvus чаще выбирают при крупных объёмах, высокой параллельности и отдельной инженерной команде.
Не размещайте LLM-файлы, Docker-образы, Qdrant, PostgreSQL WAL и резервные копии на одном заполненном SSD. Для базы до 200 GB достаточно 1 TB NVMe, но при 1 TB исходных документов планируйте минимум 2–4 TB NVMe и отдельное S3-совместимое хранилище. Для хранения исходников и снапшотов пригодится подход из материала о требованиях к MinIO и объектному S3-хранилищу.
Self hosted RAG hardware sizing: расчёт для документов и пользователей
Self hosted RAG hardware sizing следует начинать с инвентаризации документов: их объёма, форматов, скорости обновления и ожидаемого числа одновременных поисковых запросов.
Формула планирования
Для предварительного расчёта используйте четыре величины: число документов, среднее число чанков на документ, размер 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 server specs и развёртывание
OpenWebUI Ollama vector DB server specs для 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-файле.
- Разделите роли: пользователи чата не должны иметь административный доступ к коллекциям векторной БД.
При развертывании нескольких внутренних сервисов полезны общие принципы из руководства по подбору железа для self-hosted приложений: резерв ресурсов, изоляция контейнеров и измерение реальной нагрузки важнее номинального числа аккаунтов.
Железо для локального ИИ стека: сеть, диск и резервные копии
Железо для локального ИИ стека должно обеспечивать не только производительность 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 requirements
Self hosted AI stack requirements подтверждаются нагрузочным тестом: измеряйте токены в секунду, 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+ локаций, оплата картой или криптой.
Выбрать тариф
