Требования

Voxagent — модульная платформа. Каждый сервис работает в своём контейнере, поэтому компоненты можно масштабировать независимо. Перед развёртыванием подберите железо под ожидаемое число одновременных сессий — остальное (бэкбон) остаётся примерно постоянным.

Программные зависимости

• Docker 24+ и Docker Compose v2.24+
• 64-битный Linux-хост (Ubuntu 22.04 LTS или аналог). macOS подойдёт для локальной разработки.
• Исходящий интернет (registry, LLM/STT/TTS провайдеры, STUN/TURN).
• Порты, доступные из браузеров пользователей: фронтенд, API бэкенда, Keycloak, LiveKit WebRTC (TCP 7881, UDP 50000–60000).

Ресурсы по сервисам

В таблице ниже — CPU / RAM / Disk для каждого сервиса при типовых нагрузках по одновременным сессиям. Значения — эмпирические замеры из прода.

⚠ Все цифры на этой странице — предварительные оценки. Реальная нагрузка может существенно отличаться в зависимости от паттерна трафика, выбора моделей, длительности сессий и характеристик аудио — используйте их как стартовую точку и обязательно проверяйте на своих метриках перед сайзингом продакшен-железа.

Как читать:

• Сервисы, зависящие от сессий (livekit-server, python-worker, egress, websocket-media-bridge) растут линейно по числу активных звонков. Их и нужно планировать.
• Backbone-сервисы (Postgres, Kafka, Keycloak, Redis, MinIO и т.п.) имеют в основном фиксированный футпринт — разворачиваются один раз и переиспользуются между тенантами.
• Диск в основном растёт в Postgres (транскрипты, счета), Kafka (retention событий) и MinIO (записи звонков). Планируйте хранилище с учётом retention.

Калькулятор ресурсов

Оцените общий футпринт application-слоя под пиковую нагрузку:

Замечания

• Числа только для application-слоя. CPU/RAM/диск под LLM, STT и TTS провайдеров (или self-hosted модели) оплачиваются отдельно у вендоров и здесь не учтены — для self-hosted GPU-планирования см. калькулятор ниже.
• Добавьте запас 20–30% сверху на headroom, пики и оверхед ОС.
• Для HA-прода удвойте backbone (реплика Postgres, Kafka с replication factor ≥ 2 и т.п.).

GPU-сайзинг под self-hosted модели

Если STT / TTS / LLM крутятся у вас на собственном железе, а не у облачного провайдера — GPU VRAM считается отдельно. Матрица ниже — актуальные OSS-модели на июнь 2026; калькулятор под ней позволяет выбрать по одной модели на роль и увидеть суммарный VRAM под целевую конкурентную нагрузку. В любом dropdown выберите «Custom» — поля станут редактируемыми и пересчёт идёт на лету.

Как считает GPU-калькулятор

• Веса модели — лежат в VRAM один раз вне зависимости от числа сессий. Квантизация в INT8 уменьшает их вдвое, INT4 (AWQ / GPTQ) — в четыре раза.
• KV cache — LLM хранит per-token attention state для каждой активной сессии. Bytes/token = 4 × layers × kv_heads × head_dim (KV cache остаётся в FP16 даже когда веса квантизованы — это дефолт vLLM / TGI / SGLang).
• Session buffers — STT и TTS держат per-stream activation-буферы. Размер зависит от архитектуры: autoregressive TTS (XTTS, Fish) тратит больше всего на сессию, encoder-only Whisper — меньше всего.
• Hybrid attention (DeepSeek-V4 CSA+HCA) — реальный KV cache при длинных контекстах ≈ 10% от naive-формулы. В пресете V4 это учтено через effective kv_heads.
• Рекомендация GPU — наименьшая карта из каталога, куда влезает с 10% запасом. Если ничего не подходит — снижаем precision, режем контекст или делим модель по нескольким GPU через tensor-parallel.

Минимальный сайзинг машины

Числа из калькулятора выше с включёнными backbone-сервисами и рекомендованным запасом 20–30%. CPU / RAM — только application-слой; GPU под self-hosted модели бюджетируется отдельно (секция выше).

Выше 50 одновременных сессий рекомендуем вынести livekit-server + python-worker на отдельные хосты, чтобы медиа и агентская нагрузка не мешали backbone. Выше 250 сессий — выделите ноды также под egress (запись) и turn-detector.