# On-Premise-Bereitstellung — Mihu AI Mihu AI On-Premise # Ihre Agenten. Ihre Modelle. Ihre Stimmen. Ihre Infrastruktur. Ihre Daten. 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. Vertrieb kontaktieren (https://mihu.ai/de/contact) Bereitstellungsanforderungen (https://mihu.ai/de/on-premise#requirements) 7 On-Premise-Sprachen für Speech CPU Mihu STT & TTS Inferenz 99.9% Verfügbarkeitsziel Bereitstellungsgrenze In Ihrem Netzwerk Telefonie SIP-Infrastruktur, Broadcast-Dienste Lokal Sprache Mihu STT, Mihu TTS und Voice Cloning auf CPU Lokal Reasoning Open-Weight-LLM, selbst gehostet Lokal Aktionen Action Server, Integrationen, Workflows Lokal Daten Datenbank, Redis, Aufzeichnungen, Transkripte Lokal Bereitgestellt als containerisierte Docker-Dienste auf kundenverwalteter Infrastruktur, ausgerollt auf Kubernetes mit Rancher oder Helm. Überblick ## Private KI-Sprachinfrastruktur, vollständig in Ihrer eigenen Umgebung betrieben. 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. Sprache On-Premise, CPU-Inferenz LLM Open-Weight-Modelle, selbst gehostet Telefonie SIP in Ihrem Netzwerk Daten Kundenseitig kontrollierte Speicherung Sprachinfrastruktur ## Mihu STT & Mihu TTS, vollständig On-Premise. 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: Mihu STT (Speech-to-Text) läuft lokal. Mihu TTS (Text-to-Speech) läuft lokal. Für die Sprachebene wird reine CPU-Inferenz unterstützt. Eine externe Speech-API ist nicht erforderlich. Voice Cloning kann innerhalb der Infrastruktur des Kunden bereitgestellt werden. Audio- und Trainingsdaten des Kunden können vollständig in dessen Umgebung verbleiben. Aktueller On-Premise-Speech-Stack · 7 Sprachen Englisch Deutsch Französisch Spanisch Italienisch Russisch Türkisch 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. 5–9% Typische Wortfehlerrate (WER) aktueller Bereitstellungen von Mihu STT (Speech-to-Text), abhängig von Sprache und Evaluierungsdatensatz. ### Schlanke CPU-Sprachmodelle 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. Die tatsächliche Kapazität hängt ab von gleichzeitigen Gesprächen der gewählten Sprache dem gewählten STT/TTS-Modell der Audiokonfiguration dem Latenzziel den Redundanzanforderungen Werte zur Gleichzeitigkeit werden pro Bereitstellung durch Benchmarks auf der Zielhardware ermittelt und nicht als festes Verhältnis von CPU zu Anrufen angegeben. Anpassung ## Privates Fine-Tuning und Voice Cloning Eigene Sprachdaten und Markenstimmen bleiben auf einer Infrastruktur, die Sie kontrollieren. ### Privates Fine-Tuning 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. Individuelle Modelle können mit kundenseitig bereitgestellten Datensätzen feinabgestimmt werden für branchenspezifische Terminologie optimiert werden an Akzente und domänenspezifische Sprache angepasst werden ausschließlich innerhalb der Infrastruktur des Kunden bereitgestellt werden privat und vollständig innerhalb Ihrer eigenen Infrastruktur Besonders nützlich für Organisationen mit spezialisiertem Vokabular, regionalen Akzenten oder strengen Anforderungen an die Datenresidenz. ### Voice Cloning 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. Mehrsprachige Architektur ## Sprachspezifisch auf CPU oder mehrsprachig auf GPU 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. CPU-Effizienz ### Modellorchestrierung 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. Maximale mehrsprachige Flexibilität ### Mehrsprachige GPU-Modelle 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. Lokale LLM-Infrastruktur ## Die Reasoning-Ebene läuft mit Open-Weight-Modellen in Ihrer Umgebung. 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. Empfohlene Konfiguration zum Zeitpunkt der Bereitstellung 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. Mihu Core Infrastruktur ## Woraus eine vollständige Bereitstellung besteht 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. 01 ### Mihu Core Zentrale KI-Agenten-Runtime und Geschäftslogik. 02 ### Mihu Orchestration Koordiniert Sprachmodelle, LLMs, Agenten und Runtime-Services. 03 ### Mihu Relay Echtzeit-Kommunikationsebene zwischen Services und Agentensitzungen. 04 ### SIP-Infrastruktur Verwaltet Unternehmenstelefonie und SIP-Konnektivität. 05 ### Broadcast-Dienste Unterstützt ausgehende und volumenstarke Kommunikations-Workloads. 06 ### Action Server Führt Tools, Integrationen und Agentenaktionen aus. 07 ### Management / Webanwendung Oberfläche für Administration, Konfiguration und Betriebsmanagement. 08 ### Datenbankinfrastruktur Persistente Speicherung von Anwendungs- und Betriebsdaten. 09 ### Redis-Infrastruktur Echtzeit-Status, Caching und verteilte Runtime-Koordination. ### Optionale Infrastruktur Weitere Mihu-Funktionen können ebenfalls On-Premise bereitgestellt werden. Diese Komponenten erfordern je nach Nutzung zusätzliche Serverkapazität. ### Mihu Builder Zum Erzeugen und Ausführen eigener Dienste, Code, Integrationen und Workflows. Der Betrieb von Builder erfordert zusätzliche GPU-Kapazität auf dem Server. ### Mihu MCP Server Zur Bereitstellung des Mihu-Workspace und seiner Funktionen für MCP-kompatible KI-Systeme. ### PBX Connector Server Verbindet Ihre bestehende PBX- oder Telefonanlage für ein- und ausgehende Anrufe mit der Mihu-SIP-Infrastruktur. ### SMTP-Server Erforderlich, wenn Sie den E-Mail-Kanal anbinden möchten. Agenten- und Benachrichtigungs-E-Mails werden über Ihren eigenen SMTP-Server versendet. Observability & Logging ## Dedizierte Observability für Produktivbereitstellungen Produktivbereitstellungen sollten eine dedizierte Observability-Infrastruktur umfassen. Mihu empfiehlt eine separate Infrastruktur für zentrales Logging und Monitoring. ### Zentrales Logging Logs aus Mihu Core, Orchestrierung, SIP, Relay, Modellservern und Anwendungsdiensten werden zentral erfasst. ### Monitoring Infrastruktur- und Anwendungsmetriken werden kontinuierlich überwacht. Bei Überschreitung vordefinierter Betriebsschwellen können Alarme ausgelöst werden. Überwachte Metriken CPU-Auslastung Speicherauslastung GPU-Auslastung Festplattenkapazität Netzwerkzustand Servicezustand Latenz der Modellinferenz Warteschlangenlänge Anrufinfrastruktur Anwendungsfehler Netzwerkarchitektur ## Keine externe Konnektivität erforderlich 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. Kundennetzwerk Einstiegspunkte SIP trunk / PBX Web-App API Core / Orchestration / SIP STT LLM TTS Aktionen DB / Caching / Speicher Betrieb Logs Benachrichtigungen Monitoring Infrastrukturanforderungen ## Produktions-Baseline Für eine produktive Mihu On-Premise-Installation wird die anfängliche Infrastrukturkonfiguration anhand der erwarteten Gleichzeitigkeit und der Workloads festgelegt. ### Rechenleistung 128 vCPU Empfohlenes Minimum · Kerndienste und CPU-basierte Sprachschicht + GPU Je nach gewähltem Modell · z. B. Kimi K2.6 Instant, Qwen, Llama oder Mistral; das empfohlene Modell kann sich im Laufe der Zeit ändern 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. ### Speicher Anrufe × durchschnittliche Dauer × Aufzeichnungsformat × Aufbewahrungsdauer Aufzeichnungskapazität 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. Kunden legen selbst fest Aufbewahrung von Aufzeichnungen Aufbewahrung von Transkripten Backup-Richtlinie Archivierungsrichtlinie Löschrichtlinie ### Hochverfügbarkeit 99.9% Betriebliches Verfügbarkeitsziel 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. Bereitstellung ## Vorkonfiguriert, dockerisiert und gemeinsam mit Ihrem Infrastrukturteam ausgerollt 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. Infrastrukturvorbereitung Netzwerkkonfiguration Mihu-Services Sprachmodelle LLM Telefonie Speicher Observability Validierung Produktion Kubernetes: Der Stack lässt sich mit Helm-Charts bereitstellen. Der Standard- und schnellste Weg von Mihu ist eine Rancher-verwaltete Kubernetes-Bereitstellung. ### Versionierung & Releases 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. ### Dediziertes Support-Team 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. ## Alles bleibt im Haus. Eine Übersicht auf einer Seite, was in einer Mihu On-Premise-Bereitstellung wo läuft. Sprache On-Premise Mihu STT CPU Mihu TTS CPU Voice Cloning Privat LLM Open-Weight-Modelle / selbst gehostet Fine-Tuning Auf Kundeninfrastruktur Telefonie SIP Daten Kundenseitig kontrolliert Aufzeichnungen Kundenseitig kontrolliert Datenbank On-Premise Integrationen Action Server On-Premise Bereitstellung Dockerisiert · Kubernetes (Rancher / Helm) Konnektivität Innerhalb des Kundennetzwerks Observability Dediziert SLA-Ziel 99.9% Auslieferung 3–6 Monate bis zur Produktion Verfügbar für Enterprise-Kunden Support Customer-Success- und DevOps-Team, gemeinsame Slack-Gruppe Releases Monatlich, Branch-basierte Versionierung FAQ ## Mihu AI On-Premise — Häufig gestellte Fragen Was läuft tatsächlich in unserer Infrastruktur? 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. Benötigen wir GPUs? 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. Welche Sprachen unterstützt der On-Premise-Speech-Stack? 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. Welches LLM wird eingesetzt, und lässt es sich später wechseln? 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. Können wir die Sprachmodelle mit unseren eigenen Daten feinabstimmen? 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. Welche Infrastruktur benötigen wir für den Start? 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. Wie wird die Bereitstellung ausgeliefert und angebunden? 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. Können Sie STT und TTS für eine Sprache außerhalb der aktuellen sieben trainieren? 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. ## Planen Sie eine On-Premise-Bereitstellung? 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. Vertrieb kontaktieren (https://mihu.ai/de/contact)