Mihu betreibt den kompletten KI-Agenten-Stack — von Sprache und Reasoning bis zu Telefonie und Aktionen — innerhalb Ihrer Infrastruktur. Kundendaten müssen Ihre Umgebung nicht verlassen.
Mihu AI On-Premise ist ein Enterprise-Angebot, das es Organisationen ermöglicht, den kompletten Mihu AI Agenten-Stack in ihrer eigenen Infrastruktur zu betreiben.
Sprachverarbeitung, KI-Inferenz, Orchestrierung, Telefonie, Integrationen, Anwendungsdienste und Datenspeicherung können betrieben werden, ohne dass Kundendaten die Umgebung der Organisation verlassen.
Die gesamte Bereitstellung wird als containerisierte Docker-Dienste geliefert und läuft auf kundenverwalteter Infrastruktur, ausgerollt auf Kubernetes mit Rancher oder Helm.
Mihu stellt seine eigenen Sprachmodelle – Mihu STT (Speech-to-Text) und Mihu TTS (Text-to-Speech) – vollständig On-Premise bereit. Für unterstützte Bereitstellungen gilt:
Diese 7 Sprachen laufen vollständig auf Mihus eigenen STT- und TTS-Modellen innerhalb Ihrer Infrastruktur. Die Mihu-Cloud-Plattform unterstützt über zusätzliche Sprachmodelle mehr als 40 Sprachen.
Die Sprachinfrastruktur von Mihu ist darauf ausgelegt, die Inferenzanforderungen gering zu halten. Je nach Sprache und Modellkonfiguration umfassen die eingesetzten Sprachmodelle etwa 66M – 143M Parameter.
Dadurch lassen sich STT- und TTS-Workloads auf CPU-Infrastruktur betreiben, ohne dass für jeden Sprach-Workload dedizierte GPUs erforderlich sind.
Werte zur Gleichzeitigkeit werden pro Bereitstellung durch Benchmarks auf der Zielhardware ermittelt und nicht als festes Verhältnis von CPU zu Anrufen angegeben.
Eigene Sprachdaten und Markenstimmen bleiben auf einer Infrastruktur, die Sie kontrollieren.
Organisationen mit hochwertigen eigenen Sprachdaten können die Sprachebene weiter anpassen. Mihu kann unterstützte STT-/TTS-Modelle direkt auf einer vom Kunden kontrollierten Infrastruktur feinabstimmen, sodass eigene Datensätze nicht an einen Drittanbieter für Inferenz übertragen werden müssen.
Besonders nützlich für Organisationen mit spezialisiertem Vokabular, regionalen Akzenten oder strengen Anforderungen an die Datenresidenz.
Mihu On-Premise unterstützt außerdem privates Voice Cloning. Aus bereitgestellten Sprachproben lassen sich organisationsspezifische Stimmen erstellen, die anschließend in der eigenen Infrastruktur des Kunden gehostet werden.
Sowohl die Quellaufnahmen als auch das resultierende Stimmmodell können privat bleiben.
So können Unternehmen konsistente Markenstimmen schaffen, ohne bei der Inferenz im Produktivbetrieb auf einen externen TTS-Anbieter angewiesen zu sein.
Anforderung an die Stimmprobe: etwa 30 Sekunden saubere Sprache, aufgenommen ohne lange Pausen oder Lücken zwischen den Sätzen.
Die schlanken CPU-Sprachmodelle sind überwiegend sprachspezifisch und nicht ein einzelnes mehrsprachiges Modell. Für KI-Agenten, die während derselben Interaktion dynamisch die Sprache wechseln müssen, unterstützt Mihu mehrere Bereitstellungsstrategien.
Mehrere sprachspezifische Sprachmodelle laufen gleichzeitig. Die Orchestrierungsebene von Mihu erkennt die aktive Sprache oder erhält sie übermittelt und leitet die Sprachverarbeitung dynamisch an das passende Modell weiter.
Auch systemseitige Vorgaben können die Modellauswahl während einer Interaktion steuern.
Für Szenarien mit hochdynamischen mehrsprachigen Gesprächen können stattdessen größere mehrsprachige Sprachmodelle auf GPU-Infrastruktur bereitgestellt werden.
Je nach Workload wird die Architektur entweder auf CPU-Effizienz mit sprachspezifischen Modellen oder auf maximale mehrsprachige Flexibilität mit GPU-basierten Modellen optimiert.
Hinweis: Mehrsprachiges STT und mehrsprachiges TTS erfordern beide GPU-Infrastruktur. Der reine CPU-Pfad gilt für die sprachspezifischen Mihu-STT- und Mihu-TTS-Modelle.
Die Reasoning-Ebene läuft vollständig in Ihrer Umgebung mit Open-Weight-LLMs: Modellen, deren Gewichte öffentlich veröffentlicht sind und die vollständig offline auf Ihrer eigenen Hardware laufen können, ohne jede Verbindung zum Modellanbieter. Mihu evaluiert kontinuierlich neue Open-Weight-Modelle, statt den On-Premise-Stack dauerhaft an eine einzelne Modellfamilie zu binden.
Leistungsstarke LLM-Bereitstellungen erfordern in der Regel GPU-Infrastruktur. Das empfohlene Modell kann sich ändern, sobald neue Modelle verfügbar werden; Mihu kann das Reasoning-Modell unabhängig von der übrigen Agenten-Infrastruktur aktualisieren oder ersetzen.
Die Infrastruktur ist modellunabhängig. Das jeweils beste Modell kann sich ändern; Ihre Architektur muss das nicht.
Das Reasoning-Modell wird zum Zeitpunkt der Bereitstellung aus dem aktuellen Evaluationsset ausgewählt. Stand September 2026 ist Kimi K2.6 Instant eine unserer bevorzugten Hochleistungskonfigurationen. Es läuft auf dedizierter GPU-Infrastruktur, die zusätzlich zur Basis von 128 vCPU bereitgestellt wird. Wenn Beschaffungs- oder Modellherkunftsanforderungen gelten, können Open-Weight-Alternativen anderer Anbieter und Regionen wie Llama oder Mistral gewählt werden. Die Auswahl wird in jedem Bereitstellungsangebot bestätigt.
Eine vollständige Mihu-On-Premise-Bereitstellung besteht aus mehreren unabhängigen Diensten. Alle Kernkomponenten werden als containerisierte Docker-Dienste geliefert und auf Kubernetes mit Rancher oder Helm ausgerollt.
Zentrale KI-Agenten-Runtime und Geschäftslogik.
Koordiniert Sprachmodelle, LLMs, Agenten und Runtime-Services.
Echtzeit-Kommunikationsebene zwischen Services und Agentensitzungen.
Verwaltet Unternehmenstelefonie und SIP-Konnektivität.
Unterstützt ausgehende und volumenstarke Kommunikations-Workloads.
Führt Tools, Integrationen und Agentenaktionen aus.
Oberfläche für Administration, Konfiguration und Betriebsmanagement.
Persistente Speicherung von Anwendungs- und Betriebsdaten.
Echtzeit-Status, Caching und verteilte Runtime-Koordination.
Weitere Mihu-Funktionen können ebenfalls On-Premise bereitgestellt werden. Diese Komponenten erfordern je nach Nutzung zusätzliche Serverkapazität.
Zum Erzeugen und Ausführen eigener Dienste, Code, Integrationen und Workflows. Der Betrieb von Builder erfordert zusätzliche GPU-Kapazität auf dem Server.
Zur Bereitstellung des Mihu-Workspace und seiner Funktionen für MCP-kompatible KI-Systeme.
Verbindet Ihre bestehende PBX- oder Telefonanlage für ein- und ausgehende Anrufe mit der Mihu-SIP-Infrastruktur.
Erforderlich, wenn Sie den E-Mail-Kanal anbinden möchten. Agenten- und Benachrichtigungs-E-Mails werden über Ihren eigenen SMTP-Server versendet.
Produktivbereitstellungen sollten eine dedizierte Observability-Infrastruktur umfassen. Mihu empfiehlt eine separate Infrastruktur für zentrales Logging und Monitoring.
Logs aus Mihu Core, Orchestrierung, SIP, Relay, Modellservern und Anwendungsdiensten werden zentral erfasst.
Infrastruktur- und Anwendungsmetriken werden kontinuierlich überwacht. Bei Überschreitung vordefinierter Betriebsschwellen können Alarme ausgelöst werden.
Alle Mihu-Dienste laufen auf Servern im eigenen Netzwerk des Kunden. Für den Produktionsbetrieb ist kein VPN, kein Tunnel und keine dauerhafte Verbindung zu Mihu erforderlich.
Interne KI-Dienste müssen nicht öffentlich erreichbar sein. Die Telefonie erreicht die SIP-Infrastruktur über die bestehende Carrier- oder PBX-Anbindung des Kunden, und die Netzwerkregeln werden vollständig durch die Infrastruktur- und Sicherheitsrichtlinien des Kunden definiert.
Für eine produktive Mihu On-Premise-Installation wird die anfängliche Infrastrukturkonfiguration anhand der erwarteten Gleichzeitigkeit und der Workloads festgelegt.
Die Basis von 128 vCPU deckt die Mihu-Core-Dienste und CPU-basiertes STT/TTS ab. Sie deckt nicht die Reasoning-Schicht ab: Ein leistungsstarkes, selbst gehostetes LLM wie Kimi K2.6 Instant erfordert zusätzlich zu dieser Basis dedizierte GPU-Infrastruktur, dimensioniert nach dem gewählten Modell und der erwarteten Parallelität. Bei Auswahl eines kleineren Open-Weight-Modells verringert sich der GPU-Bedarf entsprechend. GPU-Kapazität wird auch hinzugefügt, wenn mehrsprachige GPU-Sprachmodelle benötigt werden. Die genaue Zuweisung hängt von gleichzeitigen KI-Gesprächen, STT/TTS-Last, eingesetzten Sprachen, LLM-Auswahl, Redundanzkonfiguration und zusätzlichen Diensten wie Builder und MCP ab.
Ob physische Kerne oder vCPUs zugewiesen werden, wird im Bereitstellungsangebot bestätigt.
Der Speicherbedarf hängt in erster Linie davon ab, ob Anrufaufzeichnungen und andere Medien lokal aufbewahrt werden. Die Mihu-Anwendungsdatenbanken benötigen persistenten Speicher, während die Aufzeichnungskapazität separat berechnet wird. Kunden, die Aufzeichnungen über Monate oder Jahre aufbewahren, sollten ein dediziertes Speichervolumen entsprechend ihrer Aufbewahrungsrichtlinie einplanen.
Die Produktionsarchitektur kann mit Redundanz über alle kritischen Mihu-Services hinweg konfiguriert werden. Das Erreichen dieses Ziels setzt voraus, dass die vereinbarte Produktionsarchitektur sowie die Redundanz- und Infrastrukturanforderungen eingehalten werden.
Für Enterprise-On-Premise-Installationen wird eine dedizierte betriebliche Verantwortung zugewiesen. Sofern keine Infrastruktur- oder Hardwareausfälle außerhalb der betrieblichen Verantwortung von Mihu auftreten, ist die Bereitstellung auf das vereinbarte Verfügbarkeitsziel von 99,9 % ausgelegt. Die Verantwortlichkeiten je Ebene sind im SLA-Dokument definiert.
Der komplette Mihu-Stack wird als vorkonfigurierte Docker-Services bereitgestellt. Das Engineering-Team von Mihu übernimmt Bereitstellungskonfiguration und Produktionsreife gemeinsam mit dem Infrastrukturteam des Kunden. Eine typische On-Premise-Bereitstellung wird in 3–6 Monaten von der Infrastrukturvorbereitung bis in die Produktion geliefert und steht Enterprise-Kunden zur Verfügung.
Kubernetes: Der Stack lässt sich mit Helm-Charts bereitstellen. Der Standard- und schnellste Weg von Mihu ist eine Rancher-verwaltete Kubernetes-Bereitstellung.
Mihu On-Premise verwendet Branch-basierte Versionierung: Jede Kundenbereitstellung läuft auf einem eigenen Release-Branch, und Updates werden als monatliche Releases ausgeliefert. Jedes Release wird vor dem Rollout validiert und in Abstimmung mit dem Infrastrukturteam des Kunden eingespielt, sodass Upgrades geplant und nicht erzwungen werden. Die Release-Validierung umfasst die Standard-Testsuite; einzelne Unit-Tests können je nach kundenspezifischen Anpassungen abweichen.
Für jede On-Premise-Umgebung stellt Mihu ein Customer-Success-Team und ein DevOps-Team bereit, die gemeinsam mit Ihrem Team arbeiten. Der Support läuft über eine gemeinsame Slack-Gruppe, sodass operative Fragen, Release-Koordination und Störungen direkt mit den Personen geklärt werden, die Ihre Bereitstellung kennen.
Eine Übersicht auf einer Seite, was in einer Mihu On-Premise-Bereitstellung wo läuft.
Der komplette Stack: Speech-to-Text, Text-to-Speech, Voice Cloning, die LLM-Reasoning-Ebene, die Orchestrierung, SIP-Telefonie, der Action Server für Integrationen, die Managementanwendung sowie die Datenbank- und Redis-Ebene. Kundendaten müssen Ihre Umgebung nicht verlassen.
Für die Sprachebene nicht. STT und TTS laufen auf CPU mit Modellen von rund 66M bis 143M Parametern. Leistungsstarke Open-Weight-LLMs erfordern in der Regel GPU-Infrastruktur; GPU-Kapazität kommt zudem hinzu, wenn Sie größere mehrsprachige Sprachmodelle wählen.
Der aktuelle On-Premise-CPU-Speech-Stack unterstützt sieben Sprachen: Englisch, Deutsch, Französisch, Spanisch, Italienisch, Russisch und Türkisch. Diese sprachspezifischen Mihu-STT- und Mihu-TTS-Modelle laufen auf CPU, ohne GPUs. Mihu STT erreicht typischerweise etwa 5–9 % Wortfehlerrate (WER); der genaue Wert hängt von der Sprache und dem Evaluationsdatensatz ab.
Die Reasoning-Ebene ist modellunabhängig und nutzt Open-Weight-Modelle. Mihu empfiehlt zum Zeitpunkt der Bereitstellung ein Modell; um Beschaffungs- oder Modellherkunftsanforderungen zu erfüllen, können auch Alternativen anderer Anbieter und Regionen gewählt werden, etwa Llama oder Mistral neben Kimi K2.6 Instant. Das Modell kann unabhängig von der übrigen Agenten-Infrastruktur aktualisiert oder ersetzt werden, sobald bessere Open-Weight-Modelle verfügbar sind.
Ja. Unterstützte STT- und TTS-Modelle können auf kundenseitig kontrollierter Infrastruktur mit Ihren eigenen Datensätzen feinabgestimmt werden, sodass eigene Audiodaten niemals an einen Drittanbieter gelangen. Die resultierenden Modelle bleiben Ihrer Organisation vorbehalten.
Eine typische Produktionsbasis beginnt bei 128 vCPU für die Mihu-Kerndienste und die CPU-basierte Sprachschicht. Das selbst gehostete LLM wird separat dimensioniert und erfordert zusätzlich dedizierte GPU-Infrastruktur; GPU-Kapazität wird auch für mehrsprachige GPU-Sprachmodelle hinzugefügt. Der Speicher wird anhand Ihrer Aufbewahrungsrichtlinie für Aufzeichnungen und Transkripte dimensioniert. Die genaue Dimensionierung wird im Bereitstellungsangebot bestätigt.
Alles wird als vorkonfigurierte Docker-Dienste ausgeliefert und läuft auf den eigenen Servern des Kunden. Für den Produktionsbetrieb ist kein VPN und keine Rückverbindung zu Mihu erforderlich, und kein interner KI-Dienst muss öffentlich erreichbar sein. Das Engineering-Team von Mihu übernimmt die Bereitstellungskonfiguration gemeinsam mit Ihrem Infrastrukturteam.
Ja. Neue Sprachen können auf Anfrage hinzugefügt werden. Der Trainingsaufwand unterscheidet sich je nach Sprachgruppe, und STT und TTS werden getrennt trainiert. Mihu kann den Trainingsdatensatz für Sie bereitstellen oder erwerben oder mit von Ihnen gelieferten Daten arbeiten. Das Training läuft auf von Ihnen bereitgestellten Maschinen oder auf von Mihu bereitgestellter Infrastruktur; die resultierenden Mihu-STT- und Mihu-TTS-Modelle werden anschließend genau wie die Standardmodelle in Ihrer Umgebung bereitgestellt.
Teilen Sie uns Ihre erwartete Gleichzeitigkeit, Ihre Sprachen und Ihre Anforderungen an die Datenresidenz mit. Unser Engineering-Team meldet sich mit einem Sizing-Vorschlag und einem Bereitstellungsplan.
