Документ для технічної оцінки здійсненності. Розрахунки зроблені під ваші цифри з анкети: пік до 4 000 дзвінків на добу, телефонія FreePBX (Asterisk + MariaDB), обслуговування українською, ціль розвантаження операторів у пік 50 відсотків. Комерційна частина в окремому КП, тут тільки техніка.
Так. Ваша телефонія FreePBX на Asterisk підключається до голосового агента штатними засобами, без заміни АТС і без зміни номерів. Критичних вимог дві: обчислювальний вузол з GPU, якщо розпізнавання і синтез мають лишатися у вашому контурі, і мережева затримка в межах одного дата-центру, бо бюджет відповіді у нас одна секунда.
Якщо GPU в компанії немає і купувати його зараз не плануєте, робочий варіант це гібрид: медіа і бізнес-логіка у вас, розпізнавання і синтез через зовнішній сервіс. Тоді залізо не потрібно взагалі, але зʼявляється щомісячна плата за хвилини і питання передавання голосу назовні, яке треба погодити з безпекою.
| Що саме потрібно | Мінімум | Рекомендовано |
|---|---|---|
| Сервер застосунку | 8 vCPU, 16 ГБ RAM, 200 ГБ SSD | 8 vCPU, 32 ГБ RAM, 500 ГБ SSD, два інстанси |
| Сервер GPU (варіант у контурі) | 1 × GPU 24 ГБ, 16 vCPU, 64 ГБ RAM | 2 × GPU 24 ГБ (L4 або A10), 32 vCPU, 128 ГБ RAM, 1 ТБ NVMe |
| Місце під записи | 250 ГБ на рік (стиснуто) | 1 ТБ на рік плюс резервне копіювання |
| Мережа до Asterisk | та сама локальна мережа або L2/L3 з затримкою до 5 мс | один дата-центр, VLAN для голосу, QoS для RTP |
| Доступи | SIP-акаунт у FreePBX, читання білінгу | плюс запис показів у білінг і створення звернення в CRM |
Розрахунки нижче побудовані на цифрах, які ви дали в анкеті. Перед фінальним проєктуванням їх варто підтвердити вивантаженням з вашої ж системи, це робиться одним запитом до бази CDR.
| Параметр | Значення з анкети | Як впливає на інфраструктуру |
|---|---|---|
| Дзвінків на добу | пік до 4 000, середнє близько 1 400, спокійні дні 300 до 500 | визначає кількість одночасних сесій і потужність GPU |
| Структура звернень | покази 80%, інші питання 16%, немає електроенергії 3%, напруга 1% | визначає, яку частку бере бот і скільки триває типовий діалог |
| Телефонія | FreePBX (Asterisk + MariaDB), IVR з чергами за пріоритетом, запис розмов | спосіб підключення бота і місце запису |
| Оператори SIP | Укртелеком 0800, Київстар, Lifecell, Vodafone | кодеки і кількість каналів на транках |
| Мова і якість | українська, розпізнавання з помилкою до 5%, відповідь до 1 секунди, природність синтезу від 4.5 | визначає клас моделей і потребу в GPU |
| Суміжні системи | білінг (SQL або Access), CRM кол-центру на Oracle | інтеграції і права доступу |
| Контур | дані не залишають периметр компанії | ключовий вибір між варіантами А і Б |
Виконати на базі CDR вашого FreePBX за останні три місяці. Результат це максимальна кількість одночасних розмов у розрізі годин, саме її ми беремо за основу замість оцінки.
-- MariaDB, база asteriskcdrdb, таблиця cdr
SELECT DATE(calldate) AS d, HOUR(calldate) AS h,
COUNT(*) AS calls,
ROUND(SUM(billsec)/3600, 2) AS erlangs,
ROUND(AVG(billsec)) AS avg_sec
FROM cdr
WHERE calldate >= DATE_SUB(NOW(), INTERVAL 90 DAY)
AND disposition = 'ANSWERED'
GROUP BY d, h
ORDER BY erlangs DESC
LIMIT 20;
Стовпець erlangs це і є середнє навантаження в годину. Пікове значення підставляється у розрахунок нижче.
Кількість серверів залежить не від кількості дзвінків на добу, а від того, скільки розмов ідуть одночасно у пікову годину. Рахуємо за класичною формулою Erlang B, як для черг у кол-центрі.
| Крок | Розрахунок | Результат |
|---|---|---|
| Пікова година | приблизно 20% добового обсягу піку: 4 000 × 0,2 | 800 дзвінків за годину |
| Тривалість діалогу з ботом | покази 60 до 90 секунд, довідка 45 до 60 секунд, беремо середнє | 75 секунд |
| Навантаження, якщо бот приймає всі дзвінки першої лінії | 800 × 75 / 3 600 | 16,7 Ерланга |
| Потрібно каналів при втратах 1% | Erlang B для 16,7 Ерланга | 25 одночасних сесій |
| Проєктна місткість із запасом 20% | 25 × 1,2 | 30 одночасних сесій |
| Якщо бот бере тільки половину трафіку | 400 × 75 / 3 600 = 8,3 Ерланга | 16 сесій, тобто один вузол з запасом |
Вибір між ними це передусім рішення про те, де обробляється голос абонента, і про структуру витрат: разова закупівля заліза проти щомісячної плати за хвилини.
| Критерій | А. Повністю у вашому контурі | Б. Гібрид | В. Повністю у хмарі |
|---|---|---|---|
| Де обробляється голос | усе у вас, назовні нічого не йде | медіа і логіка у вас, розпізнавання і синтез назовні | усе у постачальника хмари |
| Потрібен GPU | так, 1 до 2 карт по 24 ГБ | ні | ні |
| Разові витрати на залізо | орієнтовно 8 до 12 тис. доларів за сервер з GPU | немає | немає |
| Щомісячна плата за хвилини | немає | орієнтовно 600 до 1 800 доларів на місяць при ваших обсягах | вища за гібрид, плюс плата за телефонію |
| Затримка відповіді | найкраща, вкладаємось у 1 секунду | плюс 60 до 150 мс на зовнішні виклики | залежить від каналу до хмари |
| Персональні дані | не залишають периметр | потрібна згода і договір з постачальником, бажано маскування | повністю поза периметром |
| Термін запуску | довший, треба закупити і встановити сервер | найшвидший | найшвидший |
| Наша рекомендація | цільовий стан | старт пілота | лише як тимчасове |
Пілот запускаємо у гібриді, щоб не чекати закупівлю заліза і перевірити реальну якість розпізнавання на вашому трафіку. Паралельно ви оцінюєте, чи виправдана закупівля GPU. Перехід на повністю внутрішній контур робиться зміною конфігурації, переписувати нічого не треба: шар розпізнавання і синтезу відокремлений від логіки.
Точка беззбитковості: сервер з двома картами окупається проти хмарних хвилин приблизно за 8 до 12 місяців при ваших обсягах, і це без урахування того, що на цьому ж сервері згодом можуть працювати інші моделі компанії.
| Компонент | Вимога | Коментар |
|---|---|---|
| CPU | 8 vCPU (мінімум 4) | медіа-шар, обробка RTP, мікшування, запис |
| RAM | 16 ГБ, рекомендовано 32 ГБ | буфери аудіо і кеш даних білінгу |
| Диск | 200 ГБ SSD під систему, окремий том під записи | записи виносяться на файлове сховище |
| ОС | Ubuntu Server 22.04 LTS або сумісна, Docker | сервіс постачається контейнерами |
| Віртуалізація | підходить ВМ на вашому кластері | окреме залізо не обовʼязкове |
| Компонент | Вимога | Чим зайнятий |
|---|---|---|
| GPU | 2 × NVIDIA L4 24 ГБ або 2 × A10 24 ГБ. Альтернатива: 1 × RTX 6000 Ada 48 ГБ | карта 1 розпізнавання мовлення, карта 2 синтез і мовна модель |
| Мінімальна конфігурація | 1 × GPU 24 ГБ | тягне близько 15 одночасних сесій, тобто половину піку |
| CPU | 16 vCPU, рекомендовано 32 | підготовка аудіо, VAD, черги |
| RAM | 64 ГБ, рекомендовано 128 ГБ | моделі та буфери |
| Диск | 1 ТБ NVMe | ваги моделей займають близько 40 ГБ, решта під кеш і логи |
| Драйвери | NVIDIA driver 550 або новіший, CUDA 12.x, NVIDIA Container Toolkit | стандартний стек |
| Живлення і охолодження | L4 це 72 Вт на карту, однослотова, без додаткового живлення | ставиться у звичайний стійковий сервер |
Ми не замінюємо і не переналаштовуємо вашу АТС. Голосовий агент підключається як ще один внутрішній ресурс, у який IVR спрямовує обрані гілки.
| Спосіб | Як працює | Оцінка |
|---|---|---|
| SIP-розширення (PJSIP) | бот реєструється у FreePBX як звичайний внутрішній номер, IVR переводить дзвінок на нього | рекомендовано найменше втручання, стандартна конфігурація |
| Asterisk ARI, externalMedia | Asterisk віддає боту потік RTP через REST і WebSocket | гнучкіше керування, потрібен доступ до ARI (порти 8088 або 8089) |
| AudioSocket або EAGI | окремий канал передавання аудіо у застосунок | резервний варіант, якщо перші два недоступні |
; приклад логіки у dialplan, спрощено
exten => _X.,1,Dial(PJSIP/voicebot,20,g) ; спроба віддати боту, 20 секунд
same => n,GotoIf($["${DIALSTATUS}" = "ANSWER"]?done)
same => n,Queue(operators) ; бот недоступний, працює черга
same => n(done),Hangup()
| Параметр | Значення | Коментар |
|---|---|---|
| Сигналізація | SIP 5060/UDP або 5061/TLS між Asterisk і ботом | рекомендуємо TLS навіть усередині периметра |
| Медіа | RTP, діапазон UDP 10000 до 20000 (достатньо 200 портів на 30 сесій) | за потреби звужується |
| Кодеки | G.711 alaw (основний), Opus за наявності | як у ваших транках сьогодні |
| Смуга | близько 100 кбіт/с на сесію в обидва боки, 30 сесій це до 3 Мбіт/с | навантаження на мережу мінімальне |
| Затримка мережі | до 5 мс між Asterisk і ботом, джитер до 20 мс | один дата-центр або одна майданчикова мережа |
| QoS | DSCP EF для RTP, окремий VLAN для голосу | стандартна практика для телефонії |
| Вихід в інтернет | потрібен тільки у варіантах Б і В | для варіанта А достатньо локальної мережі |
| Етап | Типово | Гірший випадок |
|---|---|---|
| Визначення кінця фрази абонента | 250 мс | 300 мс |
| Розпізнавання і фіналізація тексту | 150 мс | 250 мс |
| Логіка і запит у білінг | 80 мс | 150 мс |
| Мовна модель, якщо потрібна | 60 мс | 120 мс |
| Синтез до першого звуку | 150 мс | 300 мс |
| Мережа і буферизація | 30 мс | 60 мс |
| Разом | близько 720 мс | близько 1 180 мс |
Саме тому варіант з зовнішнім розпізнаванням і синтезом складніший: кожен зовнішній виклик додає 60 до 150 мс і бюджет секунди стає дуже щільним. У контурі запас комфортний, а відповідь на типове питання про покази лунає навіть швидше, бо там не потрібна мовна модель.
| Що зберігається | Обсяг на добу (пік) | За 12 місяців при середньому навантаженні |
|---|---|---|
| Аудіо без стиснення (WAV 8 кГц) | близько 4,8 ГБ | близько 610 ГБ |
| Аудіо стиснуте (Opus 24 кбіт/с) | близько 0,9 ГБ | близько 115 ГБ |
| Транскрипти і резюме (текст) | близько 8 МБ | близько 1 ГБ |
| Технічні журнали | близько 200 МБ | близько 40 ГБ з ротацією |
| Система | Що потрібно | Режим доступу | Критичність |
|---|---|---|---|
| FreePBX (Asterisk) | SIP-акаунт для бота, гілка IVR, за потреби доступ до ARI і CDR | читання CDR, реєстрація SIP | обовʼязково |
| Білінг (SQL або Access) | перевірка особового рахунку, історія показів, обсяг за період | читання: окремий користувач або представлення | обовʼязково |
| Білінг, запис показів | внесення прийнятого голосом показу | запис: процедура або проміжна таблиця | за вашим рішенням |
| CRM кол-центру (Oracle) | створення картки звернення за результатом дзвінка | API або таблиця обміну | бажано |
| Дані про відключення | довідка про зареєстроване відключення на день звернення | читання, вивантаження або представлення | бажано |
| База знань | офіційні тексти відповідей на типові питання | ведеться у кабінеті агента | обовʼязково |
У КП цей сценарій закладений, бо саме покази це 80 відсотків ваших дзвінків. Технічно можливі два режими, і вибір за вами: агент або пише показ у білінг напряму через погоджений інтерфейс, або передає його у чинний механізм приймання показів, а сам лише підтверджує абоненту, що показ прийнято. Другий режим не потребує прав на запис у білінг і зазвичай швидше проходить внутрішнє погодження.
Окремо про Access: якщо частина даних білінгу лежить у файлах Access, прямий одночасний доступ з боку сервісу не є надійним рішенням. Робочий варіант це нічне або погодинне вивантаження у проміжну базу, з якої читає агент. Це не впливає на якість відповідей про попередні періоди, але дає затримку в актуальності поточного дня, і про це треба домовитись на етапі проєктування.
| Сценарій відмови | Що відбувається | Наслідок для абонента |
|---|---|---|
| Сервіс агента недоступний | dialplan через 20 секунд переводить дзвінок у чергу операторів | жоден дзвінок не втрачається, працює як зараз |
| Відмова GPU-вузла | автоматичний перехід на зовнішнє розпізнавання або на операторів, за вашим вибором | або трохи вища затримка, або звичайна черга |
| Перевищення місткості у пік | понад 30 сесій нові дзвінки одразу йдуть операторам | черга як сьогодні, без погіршення |
| Недоступний білінг | агент чесно каже, що дані тимчасово недоступні, і передає оператору | без вигаданих цифр |
Моніторинг: одночасні сесії, затримка відповіді, частка дзвінків, закритих без оператора, частка ескалацій, помилки інтеграцій. Метрики віддаються у вашу систему моніторингу або у власну панель сервісу, алерти в Telegram або на пошту чергового.
Перелік того, що потрібно від вашого боку. Пункти 1 до 5 потрібні для старту пілота, решта до промислової експлуатації.
| Етап | Ваш бік | Наш бік | Строк |
|---|---|---|---|
| Технічна сесія | телефонія, білінг, безпека, кол-центр | уточнення схеми, фіксація варіанта розгортання | 1 зустріч |
| Підготовка середовища | ВМ, SIP-акаунт, доступи, мережеві правила | перелік і супровід налаштування | тиждень 1 |
| Розгортання і сценарії | погодження текстів і правил ескалації | установка, підключення до FreePBX, сценарії показів і довідки | тижні 1 до 2 |
| Тестові дзвінки | внутрішні номери, участь супервізора | налаштування розпізнавання, порогів, підтверджень | тиждень 3 |
| Пілот на частині трафіку | перемикання гілки IVR | щоденний контроль метрик, донастройка | тижні 3 до 4 |
| Підсумок | рішення про масштаб | звіт: частка закритих дзвінків, точність, затримка, ескалації | кінець пілота |
Технічна сесія на годину з вашими фахівцями по телефонії і білінгу плюс вивантаження CDR за три місяці. Після цього ми віддаємо фінальну специфікацію з точними цифрами під ваш реальний трафік, і вже за нею ІТ приймає рішення про залізо. Пілот при цьому можна стартувати паралельно, у гібридному режимі, без жодних закупівель.