Общая информация

Глоссарий

Модель. Обученная нейросеть, задающая соответствие между входом и выходом (текст -> текст, звук -> текст и т.д.). Модель определяется архитектурой и набором весов, полученных при обучении. В стеке робота их четыре: VAD (детекция голосовой активности), ASR (распознавание речи), LLM (генерация ответа), TTS (синтез речи).
Веса. Числовые параметры модели, полученные при обучении. Именно они хранятся в файлах модели и загружаются в VRAM при старте. «Загрузка весов» в логах vLLM — это чтение этих файлов с диска в память GPU.
Инференс. Использование готовой модели для получения ответа на некий набор входных данных ("прогон" данных через веса). В отличие от обучения, веса не меняются. Сервисы инференса в статье — Triton, vLLM, LightTTS.
LLM. Большая языковая модель. Класс моделей text-to-text, обученных на больших объемах мультиязычных и мультидоменных данных.
Triton (NVIDIA Triton Inference Server). Сервер инференса от NVIDIA, обслуживающий модели по gRPC и HTTP. В стеке на нём крутится ASR-модель T-one.
TensorRT. Библиотека NVIDIA для оптимизации моделей под конкретный GPU: она компилирует модель в специализированный «движок» ради ускорения инференса. Сборка такого движка — разовая операция под железо, поэтому в LightTTS и T-One Triton она выполняется на первой фазе и коммитится в образ.
vLLM. Движок инференса для больших языковых моделей (LLM), оптимизированный на пропускную способность и эффективную работу с памятью. Предоставляет OpenAI-совместимый API.
nvidia-smi (NVIDIA System Management Interface). Консольная утилита для просмотра состояния GPU: модель карты, версия драйвера, загрузка, потребление VRAM, запущенные процессы. Используется для проверки, что драйвер установлен и GPU виден (в т.ч. изнутри контейнера).
KV-Cache (кэш ключей и значений). Память, где LLM хранит промежуточные представления уже обработанных токенов, чтобы не пересчитывать их при генерации каждого нового токена. Ускоряет генерацию ценой VRAM. В конфиге ограничен параметром --kv-cache-memory (3 GiB). Растёт с числом сессий и длиной контекста — поэтому его размер критичен на картах с малым запасом VRAM.
LightTTS. Движок инференса для TTS-моделей (синтеза речи). В стеке запускает модель CosyVoice3, слушает порт 8080.
Промпт. Инструкция, которой следует большая языковая модель.
Токен. В контексте LLM это единица текста, которой оперирует модель (примерно часть слова / слово / знак). В токенах измеряются окно контекста и объём генерации.
Окно контекста. Максимальное количество токенов, которое LLM может учитывать за один запрос (вход + генерируемый ответ вместе). Чем больше окно, тем больше VRAM уходит под KV-Cache, поэтому на картах с ограниченным объёмом его сокращают.
Compute. Вычислительные ресурсы GPU. Абстрактный ресурс видеоускорителя. Измеряется в GFLOP/TFLOP (операциях в секунду)

Требования к оборудованию, нагрузка и мастштабирование

Микросервисы робота и их ресурсы

Робот функционирует на базе 4 микросервисов, каждый из которых может быть вынесен на отдельный сервер, или исполняться на общем сервере.

Микросервисы робота
Название	Назначение	Ключевые ресурсы	Минимальное потребление VRAM	Дополнительное потребление VRAM из расчета на 1 сессию	Условное потребление Compute на 1 сессию
secondchain	Инференс модели VAD (CPU), логика робота, голосовой pipeline, работа с сессиями, SIP-клиент	CPU, RAM	-	-	-
vLLM (qwen3.5-35b-a3b-INT4) Данные указаны с окном контекста 8192 токена.	Инференс больших языковых моделей (LLM)	VRAM, Compute	22gb	0.3gb	~3 GFLOP/токен
T-one (Triton Inference Server)	Инференс T-One speech-to-text	Compute	600mb	10mb	~1-3 GFLOP/секунда речи
LightTTS	Инференс CosyVoice3 TTS	Compute, VRAM	8gb	0.3gb	~120GFLOP/секунда генерируемоей речи

При высокой конкуренции за Compute, увеличиваются задержки на каждом из этапов инференса. Самым чувствительным компонентом, при этом, является LightTTS - из-за архитектурных особенностей. TTS требует много вычислительных ресурсов, и большое количество параллельных генераций могут значительно увеличивать задержку. В случае использования нескольких серверов рекомендуется первично выносить на отдельный сервер либо LightTTS, либо vLLM (для высвобождения Compute).

Архитектурно при этом, робот устроен таким образом, чтобы минимизировать инференс LightTTS при возможности (агрессивное кеширование результатов TTS).

Нюансы подбора GPU

При подборе GPU под данный стек объём VRAM не является определяющим критерием. Веса любой из трёх моделей помещаются в память практически любой современной карты (уровня 5090 или выше), тогда как реальными ограничивающими факторами выступают пропускная способность памяти на этапе декодирования LLM и вычислительная нагрузка DiT-декодера в TTS. Соответственно, при выборе оборудования следует ориентироваться в первую очередь на memory bandwidth и на аппаратную поддержку современных типов данных, а не на номинальный объём видеопамяти.

Отдельного внимания заслуживает интерфейс межкарточного взаимодействия. Потребительские карты рассчитаны преимущественно на одиночную эксплуатацию: в актуальных линейках Blackwell и Ada поддержка NVLink отсутствует, и обмен между несколькими GPU на одном сервере осуществляется исключительно через PCIe (Gen4/Gen5). При использовании tensor parallelism это создаёт заметные накладные расходы на межкарточную коммуникацию, что становится ощутимым при высокой конкурентной нагрузке. Дата-центровые решения (H100, H200, а также RTX PRO 6000 в соответствующем сегменте) либо предоставляют NVLink с пропускной способностью в сотни ГБ/с, либо обладают достаточным объёмом памяти для размещения моделей на одной карте, что позволяет полностью исключить tensor parallelism и связанные с ним издержки.

Следует также учитывать высокие темпы развития архитектур GPU. Производительная карта шестилетней давности может уступать современному решению среднего уровня как по вычислительной мощности, так и — что существенно в данном случае — по набору поддерживаемых типов данных. Например, NVIDIA V100 (Volta, 2017), несмотря на наличие NVLink и памяти HBM, не поддерживает аппаратное ускорение FP8 и Int4 на тензорных ядрах. Между тем рассматриваемый стек существенно опирается на эти форматы: Qwen в квантизации GPTQ-Int4 с fp8 KV-cache, T-one в TensorRT, TTS с int8-квантизацией. На оборудовании предыдущих поколений соответствующие операции либо неработоспособны в требуемых форматах, либо выполняются с существенным замедлением за счёт программной эмуляции.

С практической точки зрения приоритеты при выборе оборудования под данный пайплайн выстраиваются следующим образом: в первую очередь — поколение архитектуры (Ada, Ampere, Hopper, Blackwell — ввиду поддержки FP8 и Int4 на тензорных ядрах), далее — пропускная способность памяти, и лишь затем — объём VRAM, поскольку последний в рамках данной задачи практически всегда достаточен.

Робот тестировался преимущественно на картах поколения Blackwell:

RTX5090 (использовалась другая LLM меньшего размера)
RTX PRO 5000 48gb
RTX PRO 6000 96gb

Однако проводились также тесты на картах архитектуры Ampere. Результат можно считать удовлетворительным, особенно для организации тестовых и демо-сред без постоянной большой нагрузки.

Отдельно хочется сказать про ускорители других производителей (AMD, Intel):

К большому сожалению, большая часть инфраструктурного софта оптимизируется в первую очередь под ускорители NVIDIA. В связи с этим даже более производительные карты AMD "на бумаге", по факту показывают значительно меньшие скорости при реальных задачах. Некоторые же библиотеки и компоненты (TensorRT, Triton Inference Server и т.д.) вообще являются проприетарными разработками NVIDIA и не поддерживают работу с ускорителями других производителей.

Анизотропность нагрузки

Из-за логики работы голосового робота, нагрузка на его компоненты в рамках одной сессии достаточно неравномерна. Большинство моделей включаются последовательно после завершения инференса модели на предыдущем шаге:

VAD (детектирование голосовой активности) - работает всегда (но не вносит существенной нагрузки)
ASR (распознавание речи) - запускается при срабатывании триггера VAD (окончание реплики)
LLM - запускается после завершения работы ASR
TTS - запускается во время / после завершения работы ASR (LLM возвращает текст в потоковом режиме. Текст разбивается на предложения и передается TTS в реальном времени)

Кроме того, архитектурные особенности робота позволяют избегать шага вызова TTS для всех реплик, которые уже были сгенерированы ранее и помещены в кеш. Получается, что если инструкция робота задана таким образом, чтобы его реплики были "статичны" от сессии к сессии, получается экономить значительное количество ресурсов, переиспользуя уже существующие генерации.

Свои оптимизации есть и на стороне инференса LLM:

В команду запуска vLLM по-умолчанию включен режим prefix caching. Данный механизм позволяет кешировать системный промпт и переиспользовать ранее произведенные вычисления для новых запросов. Включение prefix caching позволяет экономить compute для однотипных запросов, а также уменьшить скорость отклика.

Поскольку в рамках голосового робота все запросы (к конкретной конфигурации) используют один системный промпт, это позволяет серьезно экономить.

Данный механизм теряет свою эффективность, к одной LLM будет обращаться большое число роботов с существенно отличающимися системными промптами (50+, точное количество зависит от доступного объема VRAM и настроек vLLM). Также механизм будет мешать, если LLM используется для каких-либо других задач, кроме работы голосового робота.

Приблизительный расчет требуемых мощностей

Рекомендуемой конфигурацией является следующая:

CPU 8x

RAM 64gb DDR5

300gb SSD

Сравнение ускорителей
Ускоритель	Архитектура	VRAM	Bandwith	Compute (INT8)	Приблизительное количество параллельных сессий
RTX PRO 5000	Blackwell	48gb	1.34TB/s	516 TOPS	30-40
RTX PRO 6000	Blackwell	96gb	1.79TB/s	1000 TOPS	50-70
RTX 4090/48	Ada	48gb	1TB/s	660 TOPS	25-30
2x RTX 5090	Blackwell	2x32gb	1.79TB/s	828 TOPS	30-40
2x RTX 4090/24	Ada	2x24gb	1TB/s	660 TOPS	10-20
A100/40	Ampere	40gb	1.56TB/s	624 TOPS	18-23
A100/80	Ampere	80gb	2TB/s	624 TOPS	55-75
H100	Hopper	80gb	3.35TB/s	990 TOPS	70-100

При использовании конфигураций из двух карт с небольшим объемом VRAM (24, 32gb) будет происходить проблема дисбаланса:

Одну из карт будет полностью занимать LLM (22gb базовых весов), а другую карту будут занимать другие модели. При этом в случае 2x24gb VRAM, для LLM будет оставаться крайне мало памяти на активные сессии, что будет являться главным ограничителем. Использовать память или compute соседней карты невозможно без NVLINK, а в потребительских картах он отсутствует.

Таким образом вариант 2x4090/24 может использовать только для ненагруженных систем - демо стендов или сред разработки. Для такой конфигурации возможно заменить вторую карту на более простую, например 4080, так как TTS + ASR не реализуют 24gb vram.

Объем оперативной памяти не может быть меньше, чем 32gb, так как в процессе запуска веса моделей помещаются сначала в оперативную память, и только затем в VRAM.

Масштабирование сервиса

При масштабировании голосового робота существует три подхода:

Использование дополнительных GPU, либо переход на сервер с более производительным GPU
Использование нескольких серверов с GPU для балансировки нагрузки
Использование нескольких экземпляров робота (движков)

На текущий момент наиболее удобным вариантом масштабирования является второй. Наиболее нагруженные сервисы vLLM и LightTTS можно выносить на отдельные сервера. При этом, например, для LightTTS не требуется большой объем VRAM, и он может качественно работать на сравнительно недорогих потребительских ускорителях (4090, 5080).

Отдельно стоит упомянуть вынесение на отдельный сервер ASR. Данный компонент работает в потоковом режиме по протоколу gRPC, и не рекомендуется вынесение его на другие площадки с высокой задержкой. Остальные компоненты (за исключением VAD, который работает на CPU в составе главного сервиса secondchain), не чувствительны к дополнительным задержкам (в рамках разумного, до 50-70мс).

Запуск робота с использованием облачных сервисов инференса

В случае, когда проектные требования позволяют использовать облачную инфраструктуру, нет необходимости полного разворота всех сервисов локально. Можно использовать ресурсы облачных провайдеров и ресурсы, предоставляемые командой платформы.

Сервис поддерживает наиболее популярные API для работы с облачными моделями:

OpenAI-like формат для LLM. Позволяет подключать к роботу любые из современных передовых языковых моделей.
OpenAI-like transcription формат для распознавания речи.
LightTTS API формат для генерации речи

Часто, экономически эффективным может быть использование только облачной LLM, так как она требует большого объема VRAM и дорогих ускорителей. При этом остальные модели запускаются локально, на более простой карте.

При выборе облачной LLM критичными показателями являются следующие:

Метрика TTFT (Time To First Token). Время отклика модели до пересылки первых токенов ответа. Должна быть <=300мс, включая сетевые задержки;
Поддержка streaming (SSE/chunked) ответов;
Возможность отключения режима thinking/reasoning;
Скорость генерации ответа >30 токенов/сек.

Популярные подписки на современные модели по типу "Token Plan", которые предлагают использование с ограничением на количество запросов, а не тарификацию по токенам, зачастую непригодны для использования с роботом. Данные подписки используются в агентских системах, где время отклика не является целевой метрикой, а запросы инференса с таких подписок, как правило обрабатываются облачными сервисами с меньшим приоритетом.

При использовании всех облачных сервисов инференса, локально разворачивается только главный контейнер - secondchain. Рекомендуемые требования к серверу для такой среды:

4x CPU

8gb RAM

80gb SSD

Этап 1. Подготовка

Установка Docker, базы данных и настройка проброса заголовков и абонента в системе телефонии.

1.1. Установка Docker

Установка самого Docker:

apt install ca-certificates curl
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Установка Nvidia Container Toolkit (только для серверов с GPU):

# репозиторий
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt update
sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

1.2. Создать БД в PostgreSQL

Установить или взять существующий инстанс Postgres, создать нового пользователя и базу для робота.

Пример с Docker:

docker run -d \
  --name postgres \
  --network host \
  -e POSTGRES_USER=secondchain \
  -e POSTGRES_PASSWORD=changeme \
  -e POSTGRES_DB=secondchain \
  -v pgdata:/var/lib/postgresql/data \
  postgres:17

1.3. Настройка проброса заголовка в B2B

Мастер-домен → приложение Настройки. В конфигурации, в нодах B2B добавить проброс заголовка X-Robot-Session:

"fwd_headers": ["X-Robot-Session"],

Активировать новую конфигурацию.

1.4. Создать абонента для робота

Проектный домен → приложение Настройки. Создать нового абонента, под которым будет регистрироваться робот.

Робот будет использовать данную учетную запись для приема звонков.

1.5. Создать канал интеграции для робота

Проектный домен → приложение Настройки. Создать новый канал интеграции:

Тип — Подписчик
Права — ai_admin, ai_voicebot_admin
Режим активности — постоянный

1.6. Создать движок в приложении ИИ

Задать произвольные название и код. В поле Номер телефона указать внутренний номер абонента, созданного на шаге 1.4.

Количество сессий по умолчанию = 8. Точное число зависит от оборудования, на котором размещаются сервисы робота.

Этап 2. Установка сервисов инференса (только для серверов с GPU)

Инструкция написана для Unbuntu 24.04.

При написании и проверке данной инструкции использовался сервер с RTX PRO 5000 48gb.

2.1. Предварительные требования

Убедиться, что установлены драйверы NVIDIA, Docker и NVIDIA Container Toolkit:

nvidia-smi                          # драйвер и GPU видны
docker --version                    # Docker установлен
docker run --rm --gpus all ubuntu nvidia-smi   # GPU проброшен в контейнер

Если последняя команда не отображает GPU, требуется установить NVIDIA Container Toolkit и перезапустить Docker.

2.2. Порядок запуска

Модели независимы. Рекомендуемый порядок развёртывания для упрощения диагностики: ASR → LLM → TTS.

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

2.3. ASR (T-one на Triton Inference Server)

Необходимо скачать и загрузить образ контейнера, создать контейнер и дождаться сборки ML-движка. Первый запуск может проходить долго, 5-15 минут, в зависимости от оборудования. Во время первого запуска система собирает движок модели с оптимизациями под текущий GPU.

wget https://ai02.era-platform.ru/tone-triton.tar.gz

docker load < tone-triton.tar.gz

docker run -d --name tone-triton --gpus all --restart unless-stopped \
    -p 17000:8000 -p 17001:8001 -p 17002:8002 \
    -v tone-engine:/models/streaming_acoustic/1 \
    tone-triton:dist-trt-b32

docker logs -f tone-triton

После появления данного сообщения можно считать что движок собран и переходить к следующему шагу установки:

I0706 22:41:02.484518 1 grpc_server.cc:2562] "Started GRPCInferenceService at 0.0.0.0:8001"
I0706 22:41:02.484664 1 http_server.cc:4832] "Started HTTPService at 0.0.0.0:8000"
I0706 22:41:02.525792 1 http_server.cc:358] "Started Metrics Service at 0.0.0.0:8002"

Проверка: после старта Triton слушает gRPC (стандартно 8001) и HTTP (стандартно 8000). Потребление VRAM — 600–800 MB. Статус контейнера:

docker ps | grep -i tone

2.4. LLM (Qwen3.5-35B-A3B на vLLM)

Установка выполняется из Docker Hub, следующей командой:

docker run -d \
  --name vllm-qwen35-moe \
  --gpus all \
  --ipc=host \
  -v /path/to/cache:/root/.cache \
  -p 16080:8000 \
  vllm/vllm-openai:cu130-nightly \
  --model Qwen/Qwen3.5-35B-A3B-GPTQ-Int4 \
  --served-model-name qwen35-35b-a3b \
  --quantization moe_wna16 \
  --max-num-seqs 6 \
  --max-model-len 4096 \
  --kv-cache-memory 3221225472 \
  --gpu-memory-utilization 0.50 \
  --enable-prefix-caching \
  --host 0.0.0.0 --port 8000 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --language-model-only


docker logs vllm-qwen35-moe -f

Ключевые параметры:

--max-model-len 8192 — максимальное окно контекста в токенах.
--max-num-seqs 6 — максимум одновременно обрабатываемых запросов.
--gpu-memory-utilization 0.50 — 50% VRAM выделено под LLM.
--kv-cache-memory 3221225472 — 3 GiB под KV-кэш.
/path/to/cache — директория хост-машины, где будет храниться кеш весов модели (24gb)

Минимальный объём VRAM для запуска — 24 GB. Фактическое потребление — 24–48 GB в зависимости от числа допустимых сессий (--max-num-seqs) и длины контекста (--max-model-len).

После запуска vllm скачает веса модели для запуска (24gb). После завершения запуска и загрузки весов в логах можно наблюдать следующие строки:

(APIServer pid=1) INFO:     Started server process [1]
(APIServer pid=1) INFO:     Waiting for application startup.
(APIServer pid=1) INFO:     Application startup complete.

Как только они появятся, можно переходить к следующему шагу.

Проверка: после загрузки весов проверить OpenAI-совместимый эндпоинт на порту 16080. Первый запрос к модели будет занимать достаточно много времени (холодный старт):

docker logs -f vllm-qwen35-moe        # ожидать "Application startup complete"

curl http://localhost:16080/v1/models

curl http://localhost:16080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen35-35b-a3b",
    "messages": [{"role": "user", "content": "Привет"}],
    "chat_template_kwargs": {"enable_thinking": false}
  }'

2.5. TTS (LightTTS + CosyVoice3)

По аналогии с T-One, установка выполняется из образа docker-контейнера

wget https://ai02.era-platform.ru/lightts-weights.tar.gz

docker load -i lightts-weights.tar.gz

docker run -d --gpus all -p 8080:8080 --shm-size 4g \
  --restart unless-stopped --name lighttts \
  -v lighttts-engines:/opt/models/Fun-CosyVoice3-0.5B \
  lighttts/light-tts:weights \
  python -m light_tts.server.api_server \
    --model_dir /opt/models/Fun-CosyVoice3-0.5B \
    --data_type float16 \
    --load_trt True \
    --host 0.0.0.0

docker logs -f lighttts

После запуска сервис скомпилирует веса, по аналогии с T-One. После завершения подготовки в логах будут следующие строки:

INFO 07-06 23:16:49.963 [server/api_http.py:391] ✅ Startup health check passed!
INFO 07-06 23:16:49.963 [server/api_http.py:395] ✅ Application ready! Server is now accepting requests
INFO 07-06 23:16:49.963 [server/api_http.py:396] 🌐 Listening at: http://localhost:8080

Проверка: TTS слушает порт 8080, потребление VRAM — 10 GB:

docker ps | grep lighttts
nvidia-smi

2.6. Итоговая карта портов

Сервис	Контейнер	Внешний порт
ASR (Triton HTTP)	`tone-triton`	17000
ASR (Triton gRPC)	`tone-triton`	17001
LLM (vLLM)	`vllm-qwen35-moe`	16080
TTS (LightTTS)	`lighttts`	8080

2.7. Финальная проверка стека

docker ps        # все три контейнера (ASR / vLLM / TTS) в статусе Up

Этап 3. Настройка .env

Для упрощения работы с настройкой робота, нами был подготовлен набор демо-ресурсов:

Файл:Демо ресурсы для голосового робота.zip

Он включает файл голоса, example.env и файлы для импорта в разделы приложения ИИ с готовым настроенным роботом.

Необходимо переименовать файл example.env в .env и изменить в нём следующие параметры:

EXTERNAL_TEMPLATES_URL=https://[адрес инстанса эры]/rest/v1/model/ai/robot
EXTERNAL_TEMPLATES_TOKEN=[локальный токен из шага 1.5]

POSTGRES_HOST=[хост postgresql]
POSTGRES_PORT=5432
POSTGRES_USER=[логин postgresql]
POSTGRES_PASSWORD=[пароль postgresql]
POSTGRES_DB=[имя БД, если укзаанная БД отсутствует - она будет автоматически создана]

CONCURRENT_SESSIONS=[Жесткое ограничение количества одновременных сессий]

SIP_SERVER=[адрес Эры]
SIP_PORT=[порт SIP]
SIP_USERNAME=[Имя учетной записи абонента из пункта 1.4]
SIP_PASSWORD=[Пароль учетной записи абонента из пункта 1.4]
SIP_DOMAIN=[Полное имя домена, например robot.era-platform.ru]
#Детальные настройки SIP-клиента. В случае необходимости обхода NAT
SIP_TRANSPORT=udp
# NAT Traversal
SIP_STUN_SERVER=stun.l.google.com:19302
SIP_USE_ICE=false


LLM_MODE=openai_api
#В случае использования сервиса инфереса vLLM на другом хосте, необходимо изменить адрес/порт
LLM_OPENAI_API_BASE=http://localhost:16080/v1 
LLM_OPENAI_MODEL=qwen35-35b-a3b


ASR_MODE=triton
#В случае использования сервиса инфереса tone-triton на другом хосте, необходимо изменить адреса/порты
ASR_TRITON_URL=http://localhost:17000
ASR_TRITON_GRPC=localhost:17001
ASR_TRITON_MODEL=streaming_acoustic
ASR_TRITON_TIMEOUT=10
ASR_DECODER_TYPE=beam_search


TTS_PROVIDER=lighttts
#В случае использования сервиса инфереса LightTTS на другом хосте, необходимо изменить адрес/порт
LIGHTTTS_URL=http://localhost:8080/
LIGHTTTS_SAMPLE_RATE=24000
LIGHTTTS_STREAMING=false
LIGHTTTS_CONCURRENCY=4

А также настройки Postgres (из шага 1.2) и подключения SIP к учётной записи абонента (из шага 1.4).

Этап 4. Запуск контейнера secondchain и создание робота

4.1. Загрузка образа и запуск контейнера

Скопировать на сервер архив с образом контейнера и файл .env в одну директорию.

Ссылка на загрузку контейнера secondchain предоставляется менеджером по запросу.

docker load -i secondchain.tar.gz
mkdir -p ./logs
docker run -d --name secondchain \
  --network host \
  --env-file .env \
  --restart unless-stopped \
  -v secondchain-data:/data \
  -v ./logs:/app/logs \
  secondchain:1.0.3a-cpu

docker logs secondchain -f

Когда сервис загрузится и проинициализируется, в консоли появится сообщение:

Registration: OK (code=200)    [pjsip.account]
[info     ] SIP client registered successfully [voip.sip]
[info     ] VoIP health monitor started    [src.api.app]
[info     ] SecondChain started successfully [src.api.app]
[info     ] Application startup complete.  [uvicorn.error]
[info     ] Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)

4.2. Создать робота в приложении ИИ

Для упрощения работы с настройкой робота, нами был подготовлен набор демо-ресурсов:

Файл:Демо ресурсы для голосового робота.zip

Он включает файл голоса, example.env и файлы для импорта в разделы приложения ИИ с готовым настроенным роботом.

Загрузить голос

Необходим аудиофайл .mp3 или .wav длительностью ~10 секунд, без лишних шумов и эхо. При загрузке указать точную транскрипцию произнесённого текста (со знаками препинания).

Для быстрого старта можно импортировать демо-голос (импорт + загрузка файла).

Создать инструменты

Базовые инструменты работы со звонком.

drop_call

Параметр	Значение
Имя	`drop_call`
Код	`drop_call`
description	Завершение звонка по инициативе робота
toolType	`callManagement`
callAction	`drop`
enabled	Да

transfer_call

Параметр	Значение
Имя	`transfer_call`
Код	`transfer_call`
description	Перевод звонка на оператора
toolType	`callManagement`
callAction	`transfer`
transferDestination	Короткий номер для перевода звонков (например, номер очереди)
enabled	Да

Создать робота

Импортировать шаблон (Роботы.json). На вкладке Инструкции изучить рекомендуемый шаблон системного промпта, а также промпта пост-обработки звонка.

Системный промпт задаёт поведение робота, а промпт пост-обработки позволяет после окончания диалога проанализировать его и сохранить в сессии бизнес-результат (удобнее всего, в формате JSON).

При составлении собственного системного важным эффектом является "внимательность" (attention) больших языковых моделей. Они более строго следуют инструкциям, написанным в начале и конце промпта. Поэтому данные области рекомендуется оставлять для строгих ограничений.

Для построения надежных роботов с повторяемой эффективностью, рекомендуется использовать подход с описанием строгих шагов диалога.

4.3. Проверить создание пользователя

После создания робота должен автоматически создаться пользователь Робот_имяРобота.

4.4. Проверить и установить статус пользователя

Приложение Супервизор контакт-центра → раздел Операторы → Текущие статусы. Убрать фильтры, найти пользователя робота и убедиться, что у него установлен статус Готов. При необходимости установить этот статус.

4.5. Добавить робота в очередь

Приложение Администратор контакт-центра → добавить робота как участника очереди. Тип участника = Робот. В остальном настройки идентичны.

4.6. Осуществить звонок

Настройка завершена. Можно совершить звонок в очередь и протестировать работу робота.