Как считать внедрение голосового бота

1. Три нагрузки, которые нельзя смешивать

CPS и параллельность — отдельные лимиты, например в документации Twilio. «20 работников агента» не равно «20 локальных генераций».

Средняя параллельность = V / (60 × рабочие часы периода)
                       = 75000 / (60 × 22 × 10) = 5,68
Использование 20 линий в рабочее время = 5,68 / 20 = 28,4%
Число звонков при среднем 2,5 мин = 75000 / 2,5 = 30000

2,5 мин — пример, а не автоматически правильное среднее для входящих по 2 и исходящих по 3 мин. Если известны минуты каждого направления: число звонков = Vвх/2 + Vисх/3. Делить общий объём на 2,5 можно только при соответствующем составе звонков.

Какие данные нужны от телефонии

CDR за репрезентативные недели: попытка, начало дозвона, ответ, завершение, направление, результат, перевод, очередь, повтор и отказ. Из них строятся интервалы 5–15 минут и всплески 10–30 секунд. Входящие разделяются с исходящими; запущенные и отвеченные вызовы — тоже. Нужны отказы/пропущенные: число принятых звонков уже перегруженной системы занижает спрос.

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

Наш условный пример: чтобы удерживать 20 состоявшихся разговоров по 150 секунд, нужно 0,133 ответа/с. При ответе на 20% попыток понадобится около 0,667 попытки/с. Если среднее ожидание ответа или отказа — 20 секунд, в дозвоне будет ещё примерно 13,3 линии. Итого около 33,3 телефонной линии в среднем для этой стационарной модели. Это не измеренный пик и не необходимое число AI-генераций: модель можно подключать после ответа.

Erlang — для телефонной ёмкости и ожидания

В интервале Δ минут предлагаемая нагрузка A = число поступивших вызовов × средняя длительность / Δ, в эрлангах. Erlang B оценивает блокировку, если все каналы заняты; Erlang C — ожидание в очереди, но не учитывает уход ожидающих. Если уход существенен, нужна модель с терпением, например Erlang A, либо воспроизведение реального потока в симуляции.

Пример расчёта Erlang B: 20 эрланг входящего спроса при 20 каналах дают около 15,9% блокировки; для ≤1% нужны 30 каналов. Это пример пуассоновского потока с потерей заблокированных вызовов, а не вывод о ваших 20 звонках. Средняя нагрузка 20 и жёсткий лимит одновременных 20 — разные исходные данные. Формулы телефонных очередей не определяют ёмкость GPU.

2. Мощность считается при согласованном отклике

Нужно выбрать SLO — например, целевой p95 от конца речи до первого звука ≤1,5 секунды. Это предлагаемый критерий для обсуждения, не отраслевой стандарт и не подтверждённое свойство нашего стенда. Отдельно измеряются приветствие после ответа на звонок, остановка звука при перебивании и завершение бизнес-действия.

LiveKit разделяет конец речи, распознавание, определение конца реплики, первый токен, первое аудио и инструменты. Для S2S модельный аудиоотклик заменяет часть стадий, но остаются транспорт и ожидание конца реплики. При стриминге стадии перекрываются: нельзя складывать их полные длительности как независимые задержки. Первое нейтральное «проверяю» и содержательный ответ полезно измерять отдельно.

Такой набор наблюдаемости поддерживает vLLM; это пример для GPU-сервинга, а не готовый сервер для нашего MLX на Mini. В таблицах Riva видно, что рост потоков увеличивает пропускную способность, но способен резко ухудшать хвост задержки. Эти цифры нельзя переносить на Mac или другие модели.

q = число разговоров на узле, ПОДТВЕРЖДЁННОЕ при выбранном SLO
Для одинаковых узлов и выдерживания отказа одного:
N = ceil(пик / q) + 1

Для разных узлов: сумма q оставшихся узлов после отказа любого одного ≥ пик.

q должно уже включать разумный эксплуатационный запас. Если берём сырую предельную мощность, запас задаётся отдельно один раз. «CPU не выше60%» — гипотеза настройки, не универсальная гарантия. Для ASR/LLM/TTS можно иметь независимые пулы; ёмкость всей системы задаёт самое узкое звено. Для S2S отдельно выясняются длительность закрепления состояния сессии и поддержка конкурентного стриминга конкретным runtime.

Два разных всплеска

• Много новых звонков одновременно — нужен запас готовых сессий.
• Много уже подключённых клиентов одновременно закончили реплики — нужен запас инференса. 20 линий с 4 ответами агента в минуту дают в среднем 1,33 запроса/с, но способны создать пачку из 20 запросов почти в один момент.

Грубая проверка: входящая интенсивность запросов × средняя вычислительная работа не должна превышать производительность пула. Она не доказывает хвост задержки. Для конечного вывода нужен поток с реальными паузами и длинами, а не только запуск одинаковых коротких текстов.

3. Балансировка по слоям

LiveKit distributed использует Redis для координации и маршрутизации комнат; требования к портам описаны отдельно. vLLM load-aware routing показывает компромисс между сохранением локальности контекста и отправкой на менее занятый сервер.

Готовый процесс ≠ прогретая модель

Readiness должна означать, что нужная модель загружена, её голос доступен и тестовая обработка завершилась, а не просто «порт отвечает200». Для нескольких моделей резидентность и прогрев считаются отдельно. Переключение тяжёлой модели на каждый звонок — отдельная задержка, а не бесплатная операция.

Пик и непик

Прогретый базовый пул обслуживает обычную нагрузку. До известного пика ёмкость увеличивается по расписанию. При неожиданном росте масштабирование срабатывает заранее — по свободным слотам, очереди, памяти и хвостам задержки. Масштабирование вниз прекращает выдачу новых звонков и ждёт окончания текущих.

Pipecat прямо связывает тёплый запас со скоростью поступления и временем подготовки: в их облаке ориентир создания idle-agent около30с, и приведена формула MAX(baseline,CPS×delay). Это облачная механика Pipecat, не замер Mini. Для нашего контура общий принцип: свободные прогретые слоты должны покрыть прирост спроса до готовности новых узлов; число зависит от завершений звонков, отказов и выбранной политики переполнения.

LiveKit рекомендует масштабировать раньше порога отказа в новых сессиях и даёт отдельное время на drain. Их пример CPU/RAM для agent server содержит VAD и транспорт; он не доказывает ёмкость локальных LLM/TTS.

Что делать, если места всё-таки нет

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

Резерв и отказ

N+1 оставляет мощность для новых звонков после отказа одного узла. Это не обещание незаметного продолжения уже идущего разговора. Восстановление зависит от места отказа, сохранённой истории, живого медиатранспорта и поддержки runtime. Общие питание/сеть — один домен отказа: несколько Mini за одним коммутатором и ИБП не защищают от его потери. Резервировать нужно и узкие места SIP, управления, БД и хранения. Twilio рекомендует независимый fallback-маршрут, включая более простой перевод на линию поддержки.

Как устроен клиентский калькулятор · client-v1

Клиент задаёт общий поток и одновременный пик, задачу, охват ботом и размещение. Выбор связки и голоса сохраняется в таблице и разговорном плеере. 75 000 минут общего потока и пик20 по умолчанию отмечены как допущения. «Весь поток» — расчётный сценарий охвата, а не подтверждённая автоматизация всех обращений.

Для частичного охвата нужны отдельные минуты выбранных звонков и одновременный пик бота. Пик не умножается на долю минут. Сохранённые длительности клиента2мин входящие и3мин исходящие используются как исходный сценарий; фактическую длительность бота уточняют на пилоте. При неизвестном соотношении направлений не подставляется2.5мин: число звонков находится между V/3 и V/2. Если указана доля входящих в минутах f, число звонков равно V×f/2 + V×(1−f)/3; это не доля звонков.

Рабочий график допускает «Неизвестно». Средняя параллельность тогда не показывается как известная. Внутренний профиль оплаты24/7 может дать явно обозначенный стоимостной сценарий без знания графика поступления звонков. Календарное окно применяется только для проверки физической вместимости. Если выбран профиль оплаты по рабочим часам, график обязателен. Часы питания/аренды не становятся автоматически графиком работы клиента.

q, резерв, источник мощности, оборудование, энергия и CPS доступны в «Настройки → Профили расчёта». Они не обязательные поля клиента. Источник привязан к модели, голосу и способу размещения. По умолчанию это допущение; указанный пользователем протокол не проверяется стендом автоматически. Даже полный состав расходов не подтверждает готовность к20одновременным разговорам.

Расходы задаются раскрывающимися строками: минуты, часы, период, звонок либо попытка; коэффициент задаёт дополнительный оплачиваемый объём. Общие расходы применяются ко всем вариантам, профильные переопределения — только к выбранной связке/голосу. «Уже включено» и «Не требуется» явно отличаются от незаполненной статьи.

Если тариф зависит от звонков и смесь направлений неизвестна, считаются два крайних сценария, без выдуманного среднего. Полный состав может дать диапазон себестоимости; незаданные статьи остаются незаданными. Для неполного диапазона основная цена показывает только нижнюю границу учтённой части; диапазоны статей видны в составе. Внедрение отдельно либо распределяется на согласованный объём, маржа считается делением на1−m.

Выбор задачи меняет инструкции будущего демо-разговора. Сбор заявки и маршрутизация не обещают настоящей CRM, заказа или перевода. Демо-действия записи доступны только для подходящего сценария. Заявка и ZIP сохраняют исходные/производные вводные, неизвестные доли и график, диапазоны цены, состав и статус мощности. Запись прикладывается по отдельному выбору и только при совпадении связки, голоса и задачи. Старый черновик сохраняется; его2.5мин не превращаются в новую якобы известную смесь направлений.

4. Полная себестоимость минуты

Себестоимость минуты =
(затраты на мощности за период + телефония + API + эксплуатация
 + хранение/сеть/лицензии + другие расходы того же периода)
/ соединённые разговорные минуты того же периода

Цена клиенту при целевой валовой марже m = себестоимость / (1 − m)
Если внедрение включено в минуту: + стоимость внедрения / согласованный объём минут

Знаменатель согласуется заранее. Минута соединения содержит речь обеих сторон и паузы; это одна минута услуги, хотя оператор/провайдер может тарифицировать несколько технических плеч. Проваленные и повторные попытки учитываются в затратах, даже если не дают полезных минут. Отдельно считаются ₽/попытку, ₽/состоявшийся звонок и ₽/успешную задачу.

Почему одинаковый «тариф за минуту» не равен одинаковому счёту

• ElevenAgents: длительность соединения, отдельная стоимость LLM и особая тарификация длинных пауз; параллельность и burst зависят от плана.
• Retell: свои правила секунды/тишины/перевода; исключения для коротких вызовов и больших промптов. Нельзя механически переносить правила ElevenLabs.
• Twilio приводит округление неполных минут вверх и отдельную тарификацию двух Call SID. Это пример конкретного оператора, не правило всех SIP-провайдеров.

Как это меняет наш расчёт Mini

Прежние допущения: Mini 180 000 ₽, 3 года, 30 календарных дней, питание 24/7, 5 Вт простой / 60 Вт работа, 8 ₽/кВт⋅ч, 75 000 мин; одинаковые машины, одна резервная. q — допустимые разговоры на узле, уже проверенные по SLO. Оценка энергии обработки оставлена прежней для иллюстрации. Ватты — допущения, не замер розетки; данные Apple относятся к другой конфигурации Mini.

0,40–1,39 нельзя показывать как готовую вилку тарифа. Это разные предположения о мощности. В прежней аппаратной оценке1,39 отсутствовали телефония, сервисная инфраструктура, эксплуатация и внедрение. Выключение купленных Mini ночью экономит электричество, но не отменяет владение. Экономия GPU-аренды от выключения оценивается по реальному графику оплачиваемых узло-часов с прогревом и резервом.

Результат бизнеса

Себестоимость полезного результата = все релевантные затраты / число подтверждённых успешных задач. Включаются труд человека после эскалации, повторное обращение в согласованном окне и исправление ошибочных действий. Быстро законченный звонок не равен решённой задаче; сравнивать с человеком нужно одинаковый набор результатов и границы затрат.

5. Как оценивать само внедрение

Смета работ = сумма трудозатрат по блокам × ставки + внешние расходы. Инженерная неопределённость и зависимость от чужой АТС/API фиксируются явно. Без состава интеграций и критериев приёмки давать единую точную цену внедрения преждевременно.

Что проверить до выпуска

• Речь: русские имена, даты, суммы, короткие «да/нет», паузы внутри фразы, исправления и перебивания, шум, эхо, тихий голос.
• Звук: приветствие, отсутствие обрезания конца фразы, реальные телефонные кодеки, потеря пакетов/джиттер, динамики и гарнитура. Браузерное демо не заменяет SIP-проверку.
• Действия: валидация аргументов, подтверждение важных изменений, права, идемпотентные ключи и отсутствие дублей после повторов. AWS объясняет безопасные повторы; их предел, backoff и jitter нужны для предотвращения перегрузки.
• Перевод: человек недоступен, вызывающий положил трубку, отмена лишнего исходящего плеча. Warm transfer может включать дополнительную консультационную сессию; cold transfer имеет другой жизненный цикл.
• Мощность: отдельно всплеск начала звонков и синхронные реплики, длинная история, долгий CRM, таймаут модели, исчерпание памяти, потеря одного узла.
• Релиз: новые звонки прекращают поступать на старую версию, текущие заканчиваются; предусмотрены возврат версии и маршрут переполнения.
• Контур: аудио, текст, embeddings, записи, логи, метрики и резервный маршрут остаются в согласованных границах. Внешний API-fallback допускается только при соответствующих условиях.
• Контроль расходов: лимиты длительности/тишины/повторов, бюджет на оператора/кампанию, авторизация инструментов. Порядок хранения и доступа согласовать до записи реального потока.

Руководство LiveKit от16.10.2026 собрано их инженерами по внедрениям: отдельное измерение приветствия, проверка пауз/шума, асинхронные долгие инструменты, наблюдаемость и fallback. Рекомендация из их облачного сценария не тестировать управляемые слои на пределе не переносится на наш собственный Mini-инференс.

Следующий полезный результат для нашего стенда

Сначала получить профиль CDR и согласовать SLO. Затем, по отдельному запросу, проверить1/2/4сессии на одной и той же связке Mini: живой микс реплик, короткий и длинный контекст, очередь, первое аудио, память и энергопотребление. Результат — q для каждой связки при заданном качестве и задержке. После этого уточнить в калькуляторе мощность и дополнить реальные ставки телефонии, инфраструктуры, эксплуатации и внедрения. Методика реализована в расчётной части стенда без новых модельных прогонов. Проверка реальной параллельности остаётся отдельным этапом.

Источники и границы

Проверены17.10.2026. Основная опора — документация разработчиков и операторов. Облачные примеры объясняют механику; их производительность и цены не являются замерами нашего Mac.

1. LiveKit: self-hosted deployments — распределение заданий, CPU/RAM агента, autoscaling, drain.
2. Pipecat: capacity planning — warm capacity, CPS, задержка подготовки, резерв.
3. Twilio: CPS — скорость новых исходящих вызовов.
4. Erlang B и Erlang C — предположения телефонных моделей.
5. LiveKit: session traces — стадийная и сквозная задержка, realtime.
6. vLLM: production metrics — очереди, память и хвосты задержки.
7. NVIDIA Riva: ASR performance — зависимость latency/throughput от потоков.
8. LiveKit distributed и порты и firewall — медиатранспорт и координация.
9. vLLM load-aware routing — контекст против очереди.
10. Twilio: failover — независимый fallback.
11. ElevenAgents: billing и план/параллельность/burst.
12. Retell: billing и исключения.
13. Twilio: округление и плечи.
14. AWS: idempotent APIs и ограничение повторов.
15. LiveKit warm transfer и cold transfer.
16. LiveKit: практики production-внедрений,16.10.2026.

Расчёт на главном экране ·18.10.2026

«База» показывает стоимость выбранной связки. Для Mini это общий сценарий оборудования по явно выбранной мощности1/2/4звонка на узел, а не измеренная цена модели. Для API — официальный тариф, заданная доля речи и история. «С расходами» использует учебный пример либо ваши вводные; переключатель не заменяет сохранённые ставки.

Пик15–20 даёт два сценария числа узлов; длительность входящих2мин/исходящих3мин считается по крайним случаям, пока доля минут не известна. Итог — минимум и максимум полных согласованных случаев, не сумма независимых минимумов статей.

Mini: N=ceil(пик/q)+резерв. Износ за минуту=N×цена×дни/(срок×365×минуты). Энергия=узло-часы×Вт/1000×₽кВтч/минуты. По умолчанию60Вт на каждый включённый узел — консервативное допущение, не измерение. Выключение вне пика снижает энергию, покупка всех пиковых узлов остаётся.

OpenAI: аудиовход10tokens/с, выход20tokens/с; на каждом ответе повторяется история. Повтор оценивается с одной явной долей льготной оплаты, без отдельных колонок. Ставки и достижимость повторного использования — разные основания. Gemini: опубликованные ставки аудио за минуту × доля/кратность; повтор входа и текстовый бюджет заданы явно. Фактические usage-токены не проверены.

STT потоковых композитов считается на весь переданный поток, TTS — на символы речи агента. Включённые кредиты и минимальный платёж плана учитываются один раз; LLM и оркестрация включены только согласно конкретному комплекту. Внешний SIP, перевод человеку и интеграции — отдельные статьи.

Курс90₽/$, цена Mini180000₽, срок3года, энергия8₽/кВтч, профиль речи50%клиент/35%агент/15%паузы — редактируемые допущения. Официальный банковский курс этим числом не заявляется. В режиме своих расходов незаданные налоги/комиссии остаются неизвестными. Пример5% — резерв расчёта, не нормативная ставка НДС.

Актуальные ставки и точные модели: проверенный набор тарифов. Формулы: расчёт. OpenAI · Google · Inworld · Soniox · ElevenAPI · ElevenAgents · xAI.

Тарифная оценка не подтверждает качество русского, скорость, доступность модели, разрешённый регион, телефонный CPS или возможность20одновременных разговоров. Эти критерии проверяются отдельно; ставки Enterprise не выдумываются.