Mihu esegue l'intero stack di agenti AI — dalla voce al ragionamento, dalla telefonia alle azioni — all'interno della vostra infrastruttura. I dati dei clienti non devono necessariamente uscire dal vostro ambiente.
Mihu AI On-Premise è un'offerta enterprise che consente alle organizzazioni di eseguire l'intero stack di agenti Mihu AI all'interno della propria infrastruttura.
L'elaborazione vocale, l'inferenza AI, l'orchestrazione, la telefonia, le integrazioni, i servizi applicativi e l'archiviazione dei dati possono operare senza che i dati dei clienti escano dall'ambiente dell'organizzazione.
L'intero deployment viene fornito come servizi Docker containerizzati ed è eseguito su infrastruttura gestita dal cliente, distribuito su Kubernetes con Rancher o Helm.
Mihu fornisce i propri modelli vocali — Mihu STT (Speech-to-Text) e Mihu TTS (Text-to-Speech) — completamente on-premise. Per i deployment supportati:
Queste 7 lingue vengono eseguite interamente sui modelli STT e TTS proprietari di Mihu, all'interno della vostra infrastruttura. La piattaforma cloud Mihu supporta oltre 40 lingue tramite modelli vocali aggiuntivi.
L'infrastruttura vocale di Mihu è progettata per mantenere contenuti i requisiti di inferenza. A seconda della lingua e della configurazione del modello, i modelli vocali distribuiti hanno circa 66M – 143M di parametri.
Questo consente di gestire i carichi di lavoro STT e TTS su infrastruttura CPU senza richiedere GPU dedicate per ogni carico di lavoro vocale.
I valori di concorrenza vengono stabiliti per ciascun deployment tramite benchmark sull'hardware di destinazione e non sono indicati come rapporto fisso tra CPU e chiamate.
I dati vocali proprietari e le voci del brand restano su un'infrastruttura sotto il vostro controllo.
Le organizzazioni che dispongono di dati vocali proprietari di alta qualità possono personalizzare ulteriormente il livello vocale. Mihu può eseguire il fine-tuning dei modelli STT/TTS supportati direttamente su un'infrastruttura controllata dal cliente, in modo che i dataset proprietari non debbano essere trasferiti a un fornitore di inferenza terzo.
Particolarmente utile per le organizzazioni con un lessico specialistico, accenti regionali o requisiti stringenti di residenza dei dati.
Mihu On-Premise supporta anche la clonazione vocale privata. I campioni vocali forniti possono essere utilizzati per creare voci specifiche dell'organizzazione, che vengono poi ospitate all'interno dell'infrastruttura del cliente.
Sia le registrazioni di origine sia il modello vocale risultante possono rimanere privati.
Questo consente alle aziende di creare voci di brand coerenti senza dipendere da un fornitore TTS esterno durante l'inferenza in produzione.
Requisito del campione vocale: circa 30 secondi di parlato pulito, registrato senza pause lunghe o vuoti tra le frasi.
I modelli vocali leggeri per CPU sono principalmente specifici per lingua anziché costituire un unico modello multilingue. Per gli agenti AI che devono cambiare lingua in modo dinamico nel corso della stessa interazione, Mihu supporta diverse strategie di deployment.
Più modelli vocali specifici per lingua vengono eseguiti simultaneamente. Il livello di orchestrazione di Mihu rileva o riceve la lingua attiva e instrada dinamicamente l'elaborazione vocale verso il modello appropriato.
La selezione del modello durante un'interazione può essere controllata anche tramite override a livello di sistema.
Per scenari che richiedono conversazioni multilingue altamente dinamiche, è possibile distribuire in alternativa modelli vocali multilingue di dimensioni maggiori su infrastruttura GPU.
L'architettura viene ottimizzata, a seconda del carico di lavoro, per l'efficienza su CPU con modelli specifici per lingua oppure per la massima flessibilità multilingue con modelli basati su GPU.
Nota: sia lo STT multilingue sia il TTS multilingue richiedono un'infrastruttura GPU. Il percorso vocale solo CPU si applica ai modelli Mihu STT e Mihu TTS specifici per lingua.
Il livello di ragionamento viene eseguito interamente nel vostro ambiente utilizzando LLM open-weight: modelli i cui pesi sono pubblicati apertamente e possono funzionare completamente offline sul vostro hardware, senza alcun collegamento con il fornitore del modello. Mihu valuta costantemente nuovi modelli open-weight anziché vincolare in modo permanente lo stack on-premise a un'unica famiglia di modelli.
I deployment di LLM ad alte prestazioni richiedono generalmente un'infrastruttura GPU. Il modello consigliato può cambiare con la disponibilità di nuovi modelli e Mihu può aggiornare o sostituire il modello di ragionamento indipendentemente dal resto dell'infrastruttura degli agenti.
L'infrastruttura è indipendente dal modello. Il miglior modello disponibile può cambiare; la vostra architettura non deve farlo.
Il modello di ragionamento viene selezionato al momento del deployment dal set di valutazione corrente. A settembre 2026, una delle nostre configurazioni ad alte prestazioni preferite è Kimi K2.6 Instant. Viene eseguito su un'infrastruttura GPU dedicata, fornita in aggiunta alla base di 128 vCPU. Se si applicano requisiti di approvvigionamento o di origine del modello, è possibile scegliere alternative open-weight di altri fornitori e regioni, come Llama o Mistral. La selezione viene confermata in ogni proposta di deployment.
Un deployment completo di Mihu On-Premise è composto da diversi servizi indipendenti. Tutti i componenti core vengono forniti come servizi Docker containerizzati e distribuiti su Kubernetes con Rancher o Helm.
Runtime principale dell'agente AI e logica di business.
Coordina modelli vocali, LLM, agenti e servizi di runtime.
Livello di comunicazione in tempo reale tra i servizi e le sessioni degli agenti.
Gestisce la telefonia aziendale e la connettività SIP.
Supporta i carichi di lavoro di comunicazione in uscita e ad alto volume.
Esegue strumenti, integrazioni e azioni degli agenti.
Interfaccia di amministrazione, configurazione e gestione operativa.
Archiviazione persistente dei dati applicativi e operativi.
Stato in tempo reale, caching e coordinamento distribuito del runtime.
Anche ulteriori funzionalità di Mihu possono essere distribuite on-premise. Questi componenti richiedono capacità server aggiuntiva in base all'utilizzo.
Per generare ed eseguire servizi, codice, integrazioni e workflow personalizzati. L'esecuzione di Builder richiede capacità GPU aggiuntiva sul server.
Per esporre il workspace e le funzionalità di Mihu a sistemi AI compatibili con MCP.
Collega il PBX o il sistema telefonico esistente all'infrastruttura SIP di Mihu per le chiamate in entrata e in uscita.
Necessario se si desidera collegare il canale e-mail. Le e-mail degli agenti e di notifica vengono inviate tramite il vostro server SMTP.
I deployment in produzione devono includere un'infrastruttura di osservabilità dedicata. Mihu consiglia un'infrastruttura separata per il logging e il monitoraggio centralizzati.
I log di Mihu Core, dell'orchestrazione, di SIP, del relay, dei server dei modelli e dei servizi applicativi vengono raccolti in modo centralizzato.
Le metriche di infrastruttura e applicative vengono monitorate in modo continuo. È possibile generare avvisi al superamento di soglie operative predefinite.
Tutti i servizi Mihu vengono eseguiti su server all'interno della rete del cliente. Per l'operatività in produzione non sono richiesti VPN, tunnel o connessioni permanenti verso Mihu.
I servizi AI interni non necessitano di esposizione pubblica. La telefonia raggiunge l'infrastruttura SIP tramite la connettività esistente del cliente con il carrier o il PBX, e le regole di rete sono definite interamente dalle policy di infrastruttura e sicurezza del cliente.
Per un'installazione Mihu On-Premise in produzione, la configurazione infrastrutturale iniziale viene definita in base alla concorrenza e ai carichi di lavoro previsti.
La base di 128 vCPU copre i servizi Mihu Core e lo STT/TTS su CPU. Non copre il livello di ragionamento: un LLM self-hosted ad alte prestazioni come Kimi K2.6 Instant richiede un'infrastruttura GPU dedicata in aggiunta a questa base, dimensionata in base al modello scelto e alla concorrenza prevista. La scelta di un modello open-weight più piccolo riduce di conseguenza il fabbisogno di GPU. La capacità GPU viene aggiunta anche quando sono richiesti modelli vocali multilingue su GPU. L'allocazione esatta dipende dalle conversazioni AI simultanee, dal carico STT/TTS, dalle lingue distribuite, dalla scelta dell'LLM, dalla configurazione di ridondanza e da servizi aggiuntivi come Builder e MCP.
L'allocazione in core fisici rispetto a vCPU viene confermata nella proposta di deployment.
I requisiti di archiviazione dipendono principalmente dal fatto che le registrazioni delle chiamate e altri contenuti multimediali vengano conservati in locale. I database applicativi di Mihu richiedono archiviazione persistente, mentre la capacità per le registrazioni viene calcolata separatamente. I clienti che conservano mesi o anni di registrazioni devono predisporre un volume di archiviazione dedicato, dimensionato in base alla propria policy di conservazione.
L'architettura di produzione può essere configurata con ridondanza sui servizi Mihu critici. Il raggiungimento di questo obiettivo richiede il mantenimento dell'architettura di produzione, della ridondanza e dei requisiti infrastrutturali concordati.
Per le installazioni on-premise enterprise viene assegnata una responsabilità operativa dedicata. In assenza di guasti dell'infrastruttura sottostante o dell'hardware al di fuori della responsabilità operativa di Mihu, il deployment è progettato per raggiungere l'obiettivo concordato di 99.9% di disponibilità del servizio. Le responsabilità per ciascun livello sono definite nel documento SLA.
L'intero stack Mihu viene fornito come servizi Docker preconfigurati. Il team di ingegneria di Mihu si occupa della configurazione del deployment e della preparazione alla produzione insieme al team infrastrutturale del cliente. Un tipico deployment on-premise viene realizzato in 3–6 mesi, dalla preparazione dell'infrastruttura alla produzione, ed è disponibile per i clienti enterprise.
Kubernetes: lo stack può essere distribuito con chart Helm. Il percorso standard e più rapido di Mihu è un deployment Kubernetes gestito con Rancher.
Mihu On-Premise utilizza un versioning basato su branch: ogni deployment cliente viene eseguito sul proprio branch di release e gli aggiornamenti vengono forniti come release mensili. Ogni release viene validata prima del rollout e applicata in coordinamento con il team infrastrutturale del cliente, così gli aggiornamenti sono pianificati e non imposti. La validazione delle release copre la suite di test standard; alcuni unit test possono variare in base alle personalizzazioni specifiche del cliente.
Per ogni ambiente on-premise, Mihu assegna un team di customer success e un team DevOps che lavorano al fianco del vostro team. Il supporto passa attraverso un gruppo Slack condiviso, così le richieste operative, il coordinamento delle release e gli incidenti vengono gestiti direttamente con le persone che conoscono il vostro deployment.
Una panoramica in una pagina di ciò che viene eseguito e dove, in un deployment Mihu On-Premise.
L'intero stack: Speech-to-Text, Text-to-Speech, clonazione vocale, il livello di ragionamento LLM, l'orchestrazione, la telefonia SIP, l'Action Server per le integrazioni, l'applicazione di gestione e i livelli di database e Redis. I dati dei clienti non devono necessariamente uscire dal vostro ambiente.
Non per il livello vocale. STT e TTS vengono eseguiti su CPU con modelli di circa 66M – 143M di parametri. Gli LLM open-weight ad alte prestazioni richiedono generalmente un'infrastruttura GPU e la capacità GPU viene aggiunta anche se scegliete modelli vocali multilingue di dimensioni maggiori.
L'attuale stack vocale on-premise su CPU supporta sette lingue: inglese, tedesco, francese, spagnolo, italiano, russo e turco. Questi modelli Mihu STT e Mihu TTS specifici per lingua vengono eseguiti su CPU, senza GPU. Mihu STT raggiunge tipicamente un Word Error Rate (WER) di circa il 5–9%; il valore esatto dipende dalla lingua e dal dataset di valutazione.
Il livello di ragionamento è indipendente dal modello ed esegue modelli open-weight. Mihu consiglia un modello alla data del deployment e, per soddisfare requisiti di approvvigionamento o di origine del modello, è possibile scegliere alternative di fornitori e regioni diversi, ad esempio Llama o Mistral accanto a Kimi K2.6 Instant. Il modello può essere aggiornato o sostituito indipendentemente dal resto dell'infrastruttura degli agenti man mano che diventano disponibili modelli open-weight migliori.
Sì. I modelli STT e TTS supportati possono essere sottoposti a fine-tuning su un'infrastruttura controllata dal cliente utilizzando i vostri dataset, così l'audio proprietario non raggiunge mai un fornitore terzo. I modelli risultanti restano privati e riservati alla vostra organizzazione.
Una base di produzione tipica parte da 128 vCPU per i servizi core di Mihu e il livello vocale su CPU. L'LLM self-hosted viene dimensionato separatamente e richiede un'infrastruttura GPU dedicata in aggiunta a tale base; la capacità GPU viene aggiunta anche per i modelli vocali multilingue su GPU. Lo storage viene dimensionato in base alla vostra policy di conservazione di registrazioni e trascrizioni. Il dimensionamento esatto viene confermato nella proposta di deployment.
Tutto viene fornito come servizi Docker preconfigurati ed eseguito sui server del cliente. Per l'operatività in produzione non sono richiesti VPN o connessioni di ritorno verso Mihu, e nessun servizio AI interno necessita di esposizione pubblica. Il team di ingegneria di Mihu gestisce la configurazione del deployment insieme al vostro team infrastrutturale.
Sì. Nuove lingue possono essere aggiunte su richiesta. L'impegno di addestramento varia in base al gruppo linguistico, e STT e TTS vengono addestrati separatamente. Mihu può fornire o acquistare il dataset di addestramento per voi, oppure lavorare con i dati che fornite. L'addestramento viene eseguito su macchine fornite da voi o su infrastruttura fornita da Mihu, e i modelli Mihu STT e Mihu TTS risultanti vengono poi distribuiti nel vostro ambiente esattamente come quelli standard.
Comunicateci la concorrenza prevista, le lingue e i requisiti di residenza dei dati. Il nostro team di ingegneria vi risponderà con una proposta di dimensionamento e un piano di deployment.
