Appearance
Sizing: сколько железа нужно платформе
Сколько ресурсов требует Unishift Platform на одну установку и как считать железо под конкретное число пользователей. Документ отвечает на вопросы пресейла: «что взять под 200 человек», «хватит ли 1 ТБ», «нужна ли GPU».
Готовые схемы размещения — в референсных архитектурах.
Короткий ответ
| Сценарий | vCPU | RAM | Диск | Примечание |
|---|---|---|---|---|
| Демо / пилот, до 25 пользователей | 4 | 8 ГБ | 100 ГБ SSD | AI — через внешний API |
| 200 пользователей, внешняя LLM | 8–16 | 32 ГБ | 1 ТБ NVMe | рекомендуемый старт |
| 200 пользователей, локальный AI на CPU | 16 | 32–48 ГБ | 1 ТБ NVMe | служебные модели 0.3–3B |
| 200 пользователей, локальная LLM 7–14B | 8–16 (app) + 8 (AI) | 32 ГБ + 64 ГБ | 1 ТБ + 500 ГБ | GPU 16–24 ГБ VRAM |
| 500–1000 пользователей | 32+ (app) | 128 ГБ | 4 ТБ NVMe | проектный, см. reference-architecture |
Самый тяжёлый компонент — не сервисы, а локальная модель (если AI работает в контуре) и данные (Postgres + pgvector + MinIO). Приложение без инференса укладывается в 1.5 ГБ RAM.
Что измерено, а что посчитано
| Тип | Откуда |
|---|---|
| Измерено | dev-стенд, TAG 0.5.9, Apple Silicon (arm64), простой (idle). Снято через docker stats, pm2 jlist, pg_database_size: значения помечены в таблицах |
| Посчитано | формулы и примеры под 200 пользователей — экстраполяция измеренного baseline с запасом |
| Оценка | пропускная способность моделей на CPU/GPU, требования VRAM по размеру модели |
На x86_64 Linux абсолютные значения отличаются на десятки процентов, а поведение под нагрузкой — сильнее: пики дают парсинг документов, индексация RAG, пайплайны Flow Manager и распознавание речи.
Из чего складывается потребление
- Приложение — 23 Go-сервиса prod-направлений (на измеренном dev-стенде — 25) + 9 раннеров Command Manager (shell, code, sql, docker, agent, ollama, docx, pdf, xlsx).
- Инфраструктура — PostgreSQL 16 (pgvector), NATS, MinIO, Centrifugo, SearXNG.
- AI — провайдер вне стека (внешний API или свой сервер моделей) и Voice (TTS/STT).
- Данные — БД сервисов, векторный индекс RAG, файлы в MinIO, образы, модели, логи и бэкапы.
Измеренный baseline
| Компонент | Измерено | Комментарий |
|---|---|---|
| Go-сервисы dev-стенда (25), простой | 278 МБ суммарно | больше всех flow-manager — 69 МБ; далее proxy-manager 26, command-manager 24, gateway 17, ai-router 13; остальные 4–12 МБ |
| 9 раннеров, простой | 47 МБ суммарно | ~6 МБ каждый (shell, code, sql, docker, agent, ollama, docx, pdf; xlsx в разработке) |
| PostgreSQL (Docker, простой) | 59 МБ | без учёта shared_buffers и рабочих процессов |
| NATS / MinIO / Centrifugo | 16 / 34 / 15 МБ | NATS с JetStream |
| SearXNG | 2.5 МБ | растёт кэш на диске |
| UI-контейнеры (4 шт.) | ~5 МБ | nginx со статикой, CPU почти не потребляет |
| Образ Go-сервиса | 12–21 МБ | content-extract 12 МБ, ai-router 21 МБ |
Образ voice | 56 МБ | CGO + sherpa-onnx |
| БД после миграций | 7.5–8.1 МБ на сервис | ~160 МБ на ~21 базу |
Ключевой вывод
Сервисы прод-стека в простое — меньше 1 ГБ RAM и около 0.5 ГБ образов. Отдельного образа инференса в стеке нет. Sizing определяют Postgres, объём данных и то, где запущен провайдер LLM.
Профили установки
Платформа ставится выборочно: каталог services.yaml делит сервисы на направления core, business, automate (ush platform install, ush platform enable/disable <service>). Чем меньше направлений — тем меньше железо.
| Профиль | Направления | Сервисов | vCPU | RAM | Диск | Пользователи |
|---|---|---|---|---|---|---|
| Ядро | core | 9 | 2 | 4–8 ГБ | 60 ГБ | до 20, без AI |
| Команда | core + business | 18 | 4 | 12 ГБ | 160 ГБ | до 50 |
| Полный | всё | 31 (prod) | 8–16 | 24–32 ГБ | 1 ТБ | 150–300 |
Состав направлений:
core(9) — postgres, nats, minio, minio-init, centrifugo, gateway, auth, spaces, client.business(9) — task-tracker, documents, notifications, storage, spark-grid, messaging, collatio, concierge, concierge_web.automate(13) — ai-router, mcp-gateway, flow-manager, command-manager, scheduler, env-manager, searxng, nats-bridge, guard, notebooks, content-extract, proxy-manager, voice.
Дополнительно к сервисам в стеке живут одноразовые *-migrate-контейнеры (19 штук, завершаются сразу) и, в dev-стенде devops/dev, Prometheus с экспортёрами. В прод-compose мониторинг не разворачивается.
Расчёт под 200 пользователей
Допущения примера:
- 200 учётных записей, 40–60 одновременно в пиковые часы;
- 20–40 AI-ходов на активного пользователя в день → 2 000–8 000 ходов в сутки;
- ~500 документов на пользователя → ~100 000 страниц, проиндексированных в RAG;
- ~2 ГБ файлов на пользователя (вложения, медиа) → ~400 ГБ;
- горизонт планирования — 1 год с запасом на рост.
RAM
| Статья | Расчёт | Итого |
|---|---|---|
| Go-сервисы | 23 × 64 МБ (резерв на пики поверх измеренных 278 МБ) | 1.5 ГБ |
| Раннеры | 9 × 32 МБ | 0.3 ГБ |
| PostgreSQL | shared_buffers 2–4 ГБ + рабочие процессы | 6–8 ГБ |
| MinIO + NATS + Centrifugo + SearXNG | по измерениям с запасом | 1.5 ГБ |
| ОС, Docker, nginx-контейнеры | — | 2.5 ГБ |
| Резерв на пики и фрагментацию | ~30% | 4 ГБ |
Итог: 16–20 ГБ минимум, рекомендуется 32 ГБ. Пики дают парсинг офисных файлов (content-extract), индексация RAG, сборка пайплайнов и Voice.
Формула:
RAM ≈ 2 ГБ (сервисы и раннеры)
+ RAM(PostgreSQL) # shared_buffers ≈ 25% RAM узла, но не больше 8–16 ГБ
+ 1.5 ГБ (MinIO, NATS, Centrifugo, SearXNG)
+ RAM(инференс) # 0 без локальных моделей
+ 25–30% резервЛокальный инференс добавляет:
| Режим | Дополнительно RAM | CPU |
|---|---|---|
| Служебные модели (0.3B ×3 + 0.6B + эмбеддинги) | 4–8 ГБ | +4 vCPU |
| Локальный чат 3B | 8–16 ГБ | +8 vCPU |
| GPU-узел инференса 7–14B | 64 ГБ на узле | 8 vCPU + GPU |
CPU
Измеренный простой — почти 0%. CPU нужен на всплески и на инференс:
| Нагрузка | Что требует |
|---|---|
| Postgres | 4 vCPU рабочий минимум, 8 — комфортно |
content-extract | парсинг PDF/DOCX/XLSX — CPU-bound, 2–4 vCPU на параллельные загрузки |
| Индексация RAG | эмбеддинги + rerank, 2–4 vCPU |
| Flow Manager / Command Manager | сборки и раннеры внутри sandbox, пиково 2–4 vCPU |
| Voice (STT/TTS) | sherpa-onnx: 2–4 vCPU, для STT заметно больше |
| Локальная LLM на CPU | 8+ vCPU: 3B даёт ориентировочно 10–25 ток/с на поток (оценка) |
Итог для 200 пользователей: 8 vCPU минимум, 16 vCPU рекомендуется.
Диск
Формулы:
Диск_Postgres ≈ 160 МБ (базовые схемы)
+ 0.2–0.4 ГБ на пользователя в год # данные, чаты, аудит
+ 15 МБ на 1000 страниц RAG # pgvector + FTS
Диск_MinIO ≈ 1.1 × объём загруженных файлов
Диск_модели ≈ 0 на app-узле; на своём AI-узле 2 ГБ (служебный набор) / 6–10 ГБ (чат 7–14B)
Диск_образы ≈ 0.5 ГБ (Go) + 0.1 ГБ (voice)
Диск_логи ≈ 20–40 ГБ в год с ротацией
Диск_бэкап ≈ 1.5–2 × (Диск_Postgres + Диск_MinIO)Пример под 200 пользователей, год 1:
| Статья | Объём |
|---|---|
| Postgres (данные + аудит + чаты) | 40–80 ГБ |
| Векторный индекс RAG (100 000 страниц) | ~2 ГБ |
| MinIO (400 ГБ файлов + метаданные, превью) | ~440 ГБ |
| Образы стека | ~0.5 ГБ Go-сервисов + voice. Веса моделей в стек не входят |
| Логи и метрики | 20–40 ГБ |
| Свободный запас 25–30% | ~150 ГБ |
| Итого | ~700 ГБ → 1 ТБ NVMe |
Локальные бэкапы на том же узле удваивают требование → берите 2 ТБ или выносите копии на отдельный узел/NAS.
Сеть
| Параметр | Значение |
|---|---|
| Внешний канал | 100 Мбит/с достаточно для 200 пользователей |
| AI-стриминг | 50 одновременных чатов ≈ 20–50 Мбит/с |
| Внутренний трафик | сервисы общаются по docker-сети; NATS-события и WebSocket |
| Задержка | gateway → сервис локально < 1 мс; основная задержка — провайдер LLM |
pgvector: сколько места съедает RAG
vector(1536)— 6 КБ на вектор,vector(768)— 3 КБ (float32).- HNSW-индекс добавляет примерно +50–100% к объёму векторов.
- Одна страница даёт ~1.2–1.5 чанка; чанк ≈ 800 токенов.
- Полнотекстовый индекс (
tsvector) добавляет +30–50% к объёму текста.
| Корпус | Векторы | Место (векторы + индекс) |
|---|---|---|
| 1 000 страниц | ~1 500 чанков | 12–18 МБ |
| 10 000 страниц | ~15 000 чанков | 120–180 МБ |
| 100 000 страниц | ~150 000 чанков | 1.2–1.8 ГБ |
RAG редко бывает причиной нехватки диска — основной объём дают файлы и история чатов.
Локальный AI-инференс: режимы и железо
| Режим | Железо | Что даёт | Когда выбирать |
|---|---|---|---|
| Внешний API (OpenAI-совместимый) | без GPU | лучшее качество и латентность, ноль затрат на своё железо | пилот, демо, если политика допускает egress |
| Локальные служебные модели | 8–16 vCPU, 4–8 ГБ RAM, 2 ГБ диска | планировщик хода, заполнение, диаграммы, decision-гейты, эмбеддинги | закрытый контур: AI нужен, но чат-модель не обязательна локально |
| Локальный чат на CPU (3B) | +8 vCPU, 8–16 ГБ RAM | чат и RAG без внешних вызовов, умеренная скорость | небольшие команды, жёсткий air-gap |
| Локальный чат на GPU (7–14B) | GPU 16–24 ГБ VRAM, 16 vCPU, 64 ГБ RAM | основной сценарий чата и RAG в контуре | продуктив 200+ пользователей в закрытом контуре |
| Гибрид | CPU-сайдкары + GPU-чат + внешний API для тяжёлых задач | оптимум по стоимости и качеству | типовая схема для крупных внедрений |
Ориентиры по VRAM (оценка, зависит от квантизации и ctx):
| Модель | Веса (Q4/Q8) | + KV-кэш | VRAM с запасом |
|---|---|---|---|
| 0.6B (decision, Q8) | 0.6 ГБ | 0.5–2 ГБ | CPU, GPU не нужна |
| 3B | 1.8–3 ГБ | 1–2 ГБ | 6–8 ГБ (если GPU) |
| 7B | 4.5–5 ГБ | 1–2 ГБ | 8–12 ГБ |
| 14B | 9–10 ГБ | 2–4 ГБ | 16–24 ГБ |
При 2–4 параллельных потоках VRAM растёт в 1.5–2 раза либо нужен батчинг (vLLM/TGI). Для 200 пользователей одна GPU 24 ГБ закрывает чат при последовательной обработке; при 40+ одновременных чатов планируйте вторую.
Бэкап: сколько места и где
| Что | Как | Объём |
|---|---|---|
| Postgres | pg_dump/pg_dumpall (в сжатом виде 30–50% от БД) | 20–40 ГБ на 200 пользователей |
| MinIO | копия тома/бакета | равен объёму файлов |
| Модели и образы | перекачиваются, бэкапить не нужно | — |
| Конфиги | .env, docker-compose.yaml, services.yaml | мегабайты |
Автоматического бэкапа в платформе пока нет: есть только ручной порядок переноса сервера (devops/prod/SERVER_MIGRATION.md) и нет pre-migration snapshot — см. раздел ограничений ниже. Планируйте минимум ежедневный дамп + недельное хранение, целевой узел — вне app-узла.
Ограничения платформы, влияющие на sizing
| Ограничение | Следствие для железа |
|---|---|
В compose нет лимитов ресурсов (mem_limit/cpus/deploy.resources не заданы ни для одного сервиса) | один сервис при утечке или пике может выесть всю RAM узла; лимиты стоит добавить override-файлом |
| Один PostgreSQL на все БД, без реплик и PITR | масштабируется только вертикально; бэкап — дампами |
Нет HA и автоскейла, общий TAG на все сервисы | 200+ пользователей = один узел; отказоустойчивость проектируется отдельно |
| Flow Manager пишет sandbox и артефакты на локальный диск узла | горизонтальное масштабирование app-узлов требует общей ФС |
guard-ner не входит в прод-compose | NER-классификация DLP при включении добавит RAM и CPU |
Мониторинг (Prometheus + экспортёры) только в devops/dev | для прода закладывайте отдельный узел наблюдаемости |
Пример ограничения ресурсов через override-файл рядом с docker-compose.yaml:
yaml
# docker-compose.override.yaml
services:
postgres:
deploy:
resources:
limits: { cpus: "4", memory: 8g }
ai-router:
deploy:
resources:
limits: { cpus: "2", memory: 1g }
flow-manager:
deploy:
resources:
limits: { cpus: "4", memory: 2g }
content-extract:
deploy:
resources:
limits: { cpus: "4", memory: 1g }Как измерить на своём стенде
bash
# Потребление контейнеров (снимок)
docker stats --no-stream --format '{{.Name}}\t{{.MemUsage}}\t{{.CPUPerc}}'
# Состав стека и статусы
docker compose ps
ush platform ps
# Размеры баз по сервисам
docker compose exec postgres psql -U "$DB_USER" -d postgres -c \
"SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size
FROM pg_database ORDER BY pg_database_size(datname) DESC;"
# Размер векторного индекса RAG
docker compose exec postgres psql -U "$DB_USER" -d ai_router_db -c \
"SELECT pg_size_pretty(pg_total_relation_size('document_chunks'));"
# Тома и образы
docker system df -v | head -40
# Локальный PM2-стенд
pm2 jlist | jq '.[] | {name, mem: .monit.memory, cpu: .monit.cpu}'Снимайте два профиля: простой и пиковый (загрузка документов, индексация, несколько параллельных чатов). Sizing строится по пику, а не по простою.
Дальше
- Референсные архитектуры — схемы на 1, 2 и N узлов.
- Установка сервисов — требования к ОС и Docker, порты, секреты.
- Архитектура — состав сервисов и их порты.