Mihu виконує повний стек ШІ-агентів — від мовлення та міркування до телефонії й дій — усередині вашої інфраструктури. Дані клієнтів не мусять залишати ваше середовище.
Mihu AI On-Premise — це корпоративна пропозиція, що дає організаціям змогу запускати повний стек ШІ-агентів Mihu у власній інфраструктурі.
Обробка мовлення, ШІ-інференс, оркестрація, телефонія, інтеграції, прикладні сервіси та зберігання даних можуть працювати без того, щоб дані клієнтів залишали середовище організації.
Усе розгортання постачається у вигляді контейнеризованих Docker-сервісів і працює на інфраструктурі, керованій замовником, у Kubernetes за допомогою Rancher або Helm.
Mihu надає власні мовленнєві моделі — Mihu STT (Speech-to-Text) і Mihu TTS (Text-to-Speech) — повністю on-premise. Для підтримуваних розгортань:
Ці 7 мов повністю працюють на власних STT- і TTS-моделях Mihu всередині вашої інфраструктури. Хмарна платформа Mihu підтримує понад 40 мов завдяки додатковим мовленнєвим моделям.
Мовна інфраструктура Mihu спроєктована так, щоб вимоги до інференсу залишалися невеликими. Залежно від мови та конфігурації моделі розгорнуті мовні моделі мають приблизно 66M – 143M параметрів.
Це дає змогу виконувати навантаження STT і TTS на CPU-інфраструктурі, не потребуючи виділених GPU для кожного голосового навантаження.
Показники одночасності визначаються для кожного розгортання шляхом тестування продуктивності на цільовому обладнанні, а не наводяться як фіксоване співвідношення CPU до дзвінків.
Власні мовні дані та брендові голоси залишаються на інфраструктурі, яку ви контролюєте.
Організації з високоякісними власними мовними даними можуть додатково адаптувати мовний рівень. Mihu може донавчати підтримувані моделі STT/TTS безпосередньо на інфраструктурі, яку контролює клієнт, тож власні набори даних не потрібно передавати сторонньому постачальнику інференсу.
Особливо корисно для організацій зі спеціалізованою лексикою, регіональними акцентами або суворими вимогами до резидентності даних.
Mihu On-Premise також підтримує приватне клонування голосу. Надані зразки голосу можуть використовуватися для створення голосів, унікальних для організації, які потім розміщуються всередині власної інфраструктури клієнта.
Як вихідні записи, так і отримана голосова модель можуть залишатися приватними.
Це дає підприємствам змогу створювати послідовні брендові голоси, не покладаючись на зовнішнього постачальника TTS під час продуктивного інференсу.
Вимога до зразка голосу: близько 30 секунд чистого мовлення, записаного без довгих пауз чи проміжків між реченнями.
Легкі мовні моделі для CPU переважно є мовноспецифічними, а не єдиною багатомовною моделлю. Для ШІ-агентів, яким потрібно динамічно перемикати мови під час однієї взаємодії, Mihu підтримує кілька стратегій розгортання.
Кілька мовноспецифічних мовних моделей працюють одночасно. Рівень оркестрації Mihu визначає або отримує активну мову та динамічно спрямовує обробку мовлення до відповідної моделі.
Системні перевизначення також можуть керувати вибором моделі під час взаємодії.
Для сценаріїв, що потребують високодинамічних багатомовних розмов, натомість можуть бути розгорнуті більші багатомовні мовні моделі на GPU-інфраструктурі.
Архітектура оптимізується або під ефективність CPU з мовноспецифічними моделями, або під максимальну багатомовну гнучкість із моделями на GPU — залежно від навантаження.
Примітка: багатомовні STT і TTS потребують GPU-інфраструктури. Режим лише на CPU стосується мовно-специфічних моделей Mihu STT і Mihu TTS.
Рівень міркування працює повністю у вашому середовищі на LLM з відкритими вагами: це моделі, ваги яких опубліковано публічно і які можуть працювати повністю офлайн на вашому власному обладнанні, без з'єднання з постачальником моделі. Mihu постійно оцінює нові моделі з відкритими вагами, замість того щоб назавжди прив'язувати стек On-Premise до одного сімейства моделей.
Високопродуктивні розгортання LLM зазвичай потребують GPU-інфраструктури. Рекомендована модель може змінюватися з появою нових моделей, і Mihu може оновити або замінити модель міркування незалежно від решти інфраструктури агентів.
Інфраструктура не залежить від моделі. Найкраща доступна модель може змінитися; ваша архітектура — ні.
Модель міркувань обирається на момент розгортання з поточного набору для оцінювання. Станом на вересень 2026 року однією з наших пріоритетних високопродуктивних конфігурацій є Kimi K2.6 Instant. Вона працює на виділеній GPU-інфраструктурі, що надається на додаток до бази у 128 vCPU. Альтернативи з відкритими вагами від інших постачальників і регіонів, наприклад Llama або Mistral, можна обрати там, де діють вимоги до закупівель або до походження моделі. Вибір підтверджується в кожній пропозиції щодо розгортання.
Повне розгортання Mihu On-Premise складається з кількох незалежних сервісів. Усі базові компоненти постачаються у вигляді контейнеризованих Docker-сервісів і розгортаються в Kubernetes за допомогою Rancher або Helm.
Основне середовище виконання ШІ-агентів і бізнес-логіка.
Координує мовні моделі, LLM, агентів і сервіси виконання.
Рівень комунікації в реальному часі між сервісами та сесіями агентів.
Забезпечує корпоративну телефонію та SIP-підключення.
Підтримує вихідні та високонавантажені комунікаційні сценарії.
Виконує інструменти, інтеграції та дії агентів.
Інтерфейс адміністрування, налаштування та операційного керування.
Постійне зберігання прикладних та операційних даних.
Стан у реальному часі, кешування та розподілена координація виконання.
Додаткові можливості Mihu також можуть бути розгорнуті On-Premise. Ці компоненти потребують додаткових серверних потужностей залежно від використання.
Для генерації та запуску власних сервісів, коду, інтеграцій і робочих процесів. Для роботи Builder потрібні додаткові GPU-потужності на сервері.
Для надання доступу до робочого простору та можливостей Mihu ШІ-системам, сумісним із MCP.
Підключає вашу наявну АТС (PBX) або телефонну систему до SIP-інфраструктури Mihu для вхідних і вихідних дзвінків.
Потрібен, якщо ви хочете підключити email-канал. Листи агентів і сповіщення надсилаються через ваш власний SMTP-сервер.
Продуктивні розгортання повинні включати виділену інфраструктуру спостережуваності. Mihu рекомендує окрему інфраструктуру для централізованого журналювання та моніторингу.
Журнали з Mihu Core, оркестрації, SIP, relay, серверів моделей і прикладних сервісів збираються централізовано.
Метрики інфраструктури та застосунків відстежуються безперервно. У разі перевищення заздалегідь визначених операційних порогів можуть генеруватися сповіщення.
Усі сервіси Mihu працюють на серверах у власній мережі замовника. Для промислової експлуатації не потрібні VPN, тунель чи постійне з'єднання з Mihu.
Внутрішні ШІ-сервіси не потребують публічного доступу. Телефонія надходить до SIP-інфраструктури через наявне підключення замовника до оператора або АТС (PBX), а мережеві правила повністю визначаються інфраструктурними політиками та політиками безпеки замовника.
Для продуктивної інсталяції Mihu On-Premise початкова конфігурація інфраструктури визначається відповідно до очікуваної одночасності та навантажень.
База у 128 vCPU покриває сервіси Mihu Core та STT/TTS на CPU. Вона не покриває шар міркувань: високопродуктивна самостійно розміщена LLM, наприклад Kimi K2.6 Instant, потребує виділеної GPU-інфраструктури на додаток до цієї бази, розрахованої під обрану модель і очікувану паралельність. Вибір компактнішої моделі з відкритими вагами відповідно зменшує потребу в GPU. GPU-потужності додаються також тоді, коли потрібні багатомовні мовленнєві моделі на GPU. Точний розподіл залежить від кількості одночасних ШІ-розмов, навантаження STT/TTS, розгорнутих мов, вибору LLM, конфігурації резервування та додаткових сервісів, таких як Builder і MCP.
Розподіл між фізичними ядрами та vCPU підтверджується в пропозиції щодо розгортання.
Вимоги до сховища насамперед залежать від того, чи зберігаються записи дзвінків та інші медіафайли локально. Бази даних застосунків Mihu потребують постійного сховища, тоді як ємність для записів розраховується окремо. Клієнтам, які зберігають записи місяцями або роками, слід передбачити виділений том сховища, розмір якого відповідає їхній політиці зберігання.
Продуктивна архітектура може бути налаштована з резервуванням критичних сервісів Mihu. Досягнення цієї цілі потребує підтримання узгодженої продуктивної архітектури, резервування та вимог до інфраструктури.
Для корпоративних інсталяцій On-Premise призначається виділена операційна відповідальність. За відсутності збоїв базової інфраструктури або обладнання поза межами операційної відповідальності Mihu розгортання спроєктоване на досягнення узгодженої цільової доступності сервісу 99,9%. Відповідальність за кожен рівень визначена в документі SLA.
Повний стек Mihu надається у вигляді попередньо налаштованих сервісів Docker. Інженерна команда Mihu відповідає за конфігурацію розгортання та готовність до продуктивної експлуатації спільно з командою інфраструктури клієнта. Типове розгортання On-Premise впроваджується за 3–6 місяців — від підготовки інфраструктури до продуктивної експлуатації — і доступне корпоративним клієнтам.
Kubernetes: стек можна розгорнути за допомогою Helm-чартів. Стандартний і найшвидший шлях Mihu — розгортання Kubernetes під керуванням Rancher.
Mihu On-Premise використовує версіонування на основі гілок: кожне розгортання замовника працює у власній релізній гілці, а оновлення постачаються як щомісячні релізи. Кожен реліз перевіряється перед розгортанням і застосовується за погодженням з інфраструктурною командою замовника, тому оновлення плануються, а не нав'язуються. Перевірка релізу охоплює стандартний набір тестів; окремі юніт-тести можуть відрізнятися залежно від індивідуальних доопрацювань для клієнта.
Для кожного середовища On-Premise Mihu призначає команду customer success і команду DevOps, які працюють разом із вашою командою. Підтримка здійснюється через спільну групу в Slack, тому операційні питання, координація релізів та інциденти вирішуються безпосередньо з людьми, які знають ваше розгортання.
Огляд на одну сторінку: що і де працює в розгортанні Mihu On-Premise.
Повний стек: Speech-to-Text, Text-to-Speech, клонування голосу, LLM-рівень міркування, оркестрація, SIP-телефонія, Action Server для інтеграцій, застосунок керування, а також рівні бази даних і Redis. Дані клієнтів не мусять залишати ваше середовище.
Для мовного рівня — ні. STT і TTS працюють на CPU з моделями приблизно від 66M до 143M параметрів. Високопродуктивні LLM з відкритими вагами зазвичай потребують GPU-інфраструктури, а потужності GPU також додаються, якщо ви обираєте більші багатомовні мовні моделі.
Поточний мовний стек On-Premise на CPU підтримує сім мов: англійську, німецьку, французьку, іспанську, італійську, російську та турецьку. Ці мовноспецифічні моделі Mihu STT і Mihu TTS працюють на CPU, без GPU. Mihu STT зазвичай досягає близько 5–9% пословної помилки (WER); точне значення залежить від мови та набору даних для оцінювання.
Рівень міркування не залежить від конкретної моделі та працює на моделях з відкритими вагами. Mihu рекомендує модель станом на дату розгортання, а альтернативи від інших постачальників і регіонів, наприклад Llama або Mistral поряд із Kimi K2.6 Instant, можна обрати відповідно до вимог закупівель або походження моделі. Модель можна оновити чи замінити незалежно від решти інфраструктури агентів у міру появи кращих моделей з відкритими вагами.
Так. Підтримувані моделі STT і TTS можуть бути донавчені на інфраструктурі під контролем клієнта з використанням ваших власних наборів даних, тож власне аудіо ніколи не потрапляє до стороннього постачальника. Отримані моделі залишаються приватними для вашої організації.
Типова виробнича база починається зі 128 vCPU для базових сервісів Mihu та мовленнєвого шару на CPU. Самостійно розміщена LLM розраховується окремо й потребує виділеної GPU-інфраструктури на додаток до цієї бази; GPU-потужності додаються також для багатомовних мовленнєвих моделей на GPU. Сховище розраховується відповідно до вашої політики зберігання записів і транскриптів. Точний розрахунок підтверджується у пропозиції щодо розгортання.
Усе постачається у вигляді попередньо налаштованих Docker-сервісів і працює на власних серверах замовника. Для промислової експлуатації не потрібні VPN чи зворотне з'єднання з Mihu, і жоден внутрішній ШІ-сервіс не потребує публічного доступу. Інженерна команда Mihu виконує налаштування розгортання разом із вашою інфраструктурною командою.
Так. Нові мови додаються за запитом. Трудомісткість навчання залежить від мовної групи; STT і TTS навчаються окремо. Mihu може надати або придбати навчальний набір даних для вас або працювати з даними, які надасте ви. Навчання виконується на наданих вами машинах або на інфраструктурі Mihu, після чого отримані моделі Mihu STT і Mihu TTS розгортаються у вашому середовищі так само, як стандартні.
Повідомте очікувану одночасність, мови та вимоги до резидентності даних. Наша інженерна команда підготує пропозицію щодо розмірів інфраструктури та план розгортання.
