Lokale KI-Systeme auf Basis von Ollama können Texte erzeugen, Fragen beantworten, Dokumente zusammenfassen oder bei technischen Aufgaben helfen. Was vielen Installationen jedoch zunächst fehlt, ist eine natürliche Sprachausgabe.
Genau hier kommt Text-to-Speech ins Spiel.
Mit einer zusätzlichen TTS-Komponente kann aus einer klassischen lokalen KI-Installation ein System werden, das Antworten nicht nur schreibt, sondern auch vorliest. Dabei muss Text-to-Speech keineswegs direkt Bestandteil von Ollama sein. Im Gegenteil: Eine getrennte Architektur ist häufig flexibler, leichter zu warten und besser skalierbar.
In diesem ersten Teil der Serie geht es deshalb um die Grundlagen: Was bedeutet lokales Text-to-Speech überhaupt? Welche Aufgaben übernehmen Ollama, Open WebUI und die eigentliche TTS-Engine? Und welche Vorteile bietet eine vollständig lokal betriebene Sprachverarbeitung?
Was bedeutet Text-to-Speech?
Text-to-Speech, kurz TTS, bezeichnet die Umwandlung von geschriebenem Text in gesprochene Sprache.
Das Grundprinzip ist einfach:
Text ↓ Text-to-Speech-Modell ↓ Audiodatei oder Audiostream
Ein Satz wie:
Der Server wurde erfolgreich aktualisiert.
wird von einer TTS-Engine analysiert und anschließend als gesprochene Sprache ausgegeben.
Moderne TTS-Systeme beschränken sich dabei längst nicht mehr auf eine monotone Computerstimme. Je nach Modell können sie Betonungen, Satzmelodie, Sprechgeschwindigkeit, Pausen und teilweise sogar unterschiedliche Sprechercharaktere berücksichtigen.
Für lokale KI-Systeme ist das besonders interessant, weil dadurch aus einer rein textbasierten Installation eine deutlich vielseitigere Plattform wird.
Ollama erzeugt Text – aber nicht automatisch Sprache
Ollama ist in erster Linie eine Plattform zum Ausführen von KI-Modellen. Über eine lokale API können beispielsweise Sprachmodelle für Chat, Textgenerierung, Zusammenfassungen oder andere Aufgaben angesprochen werden. Ollama stellt dafür unter anderem Chat- und Generate-Endpunkte bereit.
Die typische Verarbeitung sieht zunächst so aus:
Benutzer ↓ Ollama ↓ Sprachmodell ↓ Textantwort
Das Sprachmodell erzeugt also eine Antwort als Text.
Für die eigentliche Sprachausgabe wird anschließend ein zweites System benötigt:
Benutzer ↓ Ollama ↓ Sprachmodell ↓ Textantwort ↓ TTS-Engine ↓ Audio
Damit entsteht eine klare Trennung zwischen zwei Aufgaben:
Ollama erzeugt den Inhalt.
Die TTS-Engine erzeugt daraus Sprache.
Diese Trennung ist technisch sinnvoll und bietet einige Vorteile.
Warum TTS nicht direkt Bestandteil von Ollama sein muss
Auf den ersten Blick könnte man vermuten, dass Ollama selbst die Sprachausgabe übernehmen sollte.
Das ist jedoch nicht notwendig.
Ein Sprachmodell und ein Text-to-Speech-Modell erfüllen vollkommen unterschiedliche Aufgaben.
Ein Large Language Model verarbeitet Sprache auf semantischer Ebene. Es formuliert Antworten, strukturiert Informationen und erzeugt neue Texte.
Ein TTS-Modell dagegen konzentriert sich darauf, vorhandenen Text möglichst natürlich auszusprechen.
Durch die Trennung können beide Komponenten unabhängig voneinander ausgewählt und aktualisiert werden.
Beispielsweise könnte eine Installation folgendermaßen aufgebaut sein:
Ollama ├── Qwen ├── Gemma ├── Llama └── weitere Sprachmodelle TTS-Server ├── Kokoro ├── Piper └── andere Sprachmodelle
Wird später ein besseres TTS-Modell verfügbar, kann lediglich der Sprachdienst ausgetauscht werden.
Ollama und die dort verwendeten Modelle bleiben unverändert.
Umgekehrt kann das verwendete Ollama-Modell gewechselt werden, ohne die Sprachausgabe neu konfigurieren zu müssen.
Eine modulare Architektur
Für den praktischen Betrieb bietet sich deshalb eine modulare Architektur an.
Ein möglicher Aufbau sieht so aus:
┌──────────────┐
│ Browser │
└──────┬───────┘
│
▼
┌──────────────┐
│ Open WebUI │
└──────┬───────┘
│
┌──────────┴──────────┐
│ │
▼ ▼
┌────────────┐ ┌────────────┐
│ Ollama │ │ TTS-Server │
└─────┬──────┘ └─────┬──────┘
│ │
▼ ▼
Sprachmodell Audio
Open WebUI übernimmt dabei die Rolle der Benutzeroberfläche.
Eine Frage wird zunächst an Ollama übergeben. Das ausgewählte Sprachmodell erzeugt eine Antwort. Diese Antwort kann anschließend an den TTS-Dienst weitergegeben werden.
Der Benutzer erhält damit sowohl die geschriebene als auch die gesprochene Antwort.
Open WebUI als Vermittler
Open WebUI eignet sich besonders gut für eine solche Architektur.
Die Oberfläche kann mit Ollama verbunden werden und unterstützt zusätzlich verschiedene Text-to-Speech-Verfahren. Unter anderem können OpenAI-kompatible TTS-Schnittstellen verwendet werden. Open WebUI erwartet dafür unter anderem einen kompatiblen /audio/speech-Endpunkt.
Das ist für lokale Installationen sehr praktisch.
Denn ein lokaler TTS-Server muss nicht speziell für Open WebUI entwickelt worden sein. Stellt er eine kompatible API bereit, kann er häufig wie ein normaler TTS-Anbieter eingebunden werden.
Vereinfacht sieht das so aus:
Open WebUI ↓ http://tts-server:PORT/v1/audio/speech ↓ lokale TTS-Engine ↓ MP3 oder WAV
Open WebUI unterstützt außerdem das Aufteilen längerer Antworten in kleinere Abschnitte. Dadurch kann die Sprachausgabe bereits beginnen, bevor ein sehr langer Text vollständig verarbeitet wurde. Die aktuelle Dokumentation empfiehlt dafür unter anderem eine Aufteilung anhand von Satzzeichen.
Welche TTS-Systeme kommen infrage?
Für lokale Installationen stehen unterschiedliche Projekte zur Verfügung.
Zu den interessanten Möglichkeiten gehören beispielsweise:
- Kokoro
- Piper
- openedai-speech
- andere OpenAI-kompatible TTS-Dienste
Open WebUI dokumentiert verschiedene lokale oder selbst gehostete Integrationsmöglichkeiten, darunter auch Kokoro-basierte Lösungen und openedai-speech.
Welche Lösung am besten geeignet ist, hängt unter anderem von folgenden Faktoren ab:
- gewünschte Sprachqualität
- unterstützte Sprachen
- verfügbare Stimmen
- CPU-Leistung
- vorhandene GPU
- Speicherbedarf
- gewünschte Latenz
- gleichzeitige Benutzer
- gewünschte API-Kompatibilität
Die einzelnen Lösungen werden wir in einem späteren Teil dieser Serie genauer vergleichen.
Text und Sprache bleiben getrennt
Ein wichtiger Vorteil dieser Architektur besteht darin, dass der Text weiterhin die zentrale Informationsquelle bleibt.
Das Sprachmodell erzeugt beispielsweise:
Die Aktualisierung wurde erfolgreich abgeschlossen. Ein Neustart des Systems ist aktuell nicht erforderlich.
Der TTS-Dienst erhält genau diesen Text und erzeugt daraus die entsprechende Sprache.
Das bedeutet auch:
Die TTS-Engine entscheidet normalerweise nicht darüber, was gesagt wird.
Sie entscheidet darüber, wie der vorhandene Text gesprochen wird.
Das ist insbesondere für automatisierte Workflows interessant.
Ollama kann beispielsweise einen langen technischen Text zunächst in eine gut verständliche Hörfassung umwandeln. Erst anschließend wird diese Hörfassung an den TTS-Dienst übergeben.
Beispiel: Blogartikel als Hörfassung
Ein möglicher Workflow könnte so aussehen:
Blogartikel ↓ Ollama ↓ Optimierte Hörfassung ↓ TTS-Engine ↓ MP3-Datei ↓ Audio-Player im Blog
Ollama könnte dabei beispielsweise lange Sätze kürzen, Tabellen beschreiben oder Codeblöcke in verständliche Erklärungen umwandeln.
Die TTS-Engine muss dann lediglich den bereits optimierten Text sprechen.
Gerade für längere technische Artikel ist diese Trennung sinnvoll.
Ein für das Lesen geschriebener Text ist schließlich nicht automatisch auch ein guter Hörtext.
Lokale Verarbeitung oder Cloud-TTS?
Text-to-Speech lässt sich grundsätzlich sowohl lokal als auch über Cloud-Dienste betreiben.
Bei einer Cloud-Lösung sieht die Verarbeitung typischerweise so aus:
Text ↓ Internet ↓ Cloud-TTS-Anbieter ↓ Audio ↓ Internet ↓ Benutzer
Bei einer vollständig lokalen Installation dagegen:
Text ↓ lokaler TTS-Server ↓ Audio
Beide Varianten haben Vor- und Nachteile.
Cloud-Dienste können hochwertige Sprachmodelle anbieten und benötigen lokal kaum Rechenleistung.
Dafür müssen Inhalte an einen externen Anbieter übertragen werden.
Bei einem lokalen TTS-System bleiben Text und erzeugte Audiodaten dagegen innerhalb der eigenen Infrastruktur, sofern auch alle beteiligten Modelle tatsächlich lokal betrieben werden.
Wichtig: „Ollama“ bedeutet nicht automatisch vollständig lokal
Bei der Planung sollte allerdings genau darauf geachtet werden, welche Modelle tatsächlich verwendet werden.
Ollama bietet inzwischen sowohl lokale als auch Cloud-Modelle an. Cloud-Modelle verwenden externe Rechenressourcen, während klassische lokale Modelle auf dem eigenen System ausgeführt werden.
Wer einen vollständig lokalen KI-Workflow aufbauen möchte, sollte deshalb sowohl beim Sprachmodell als auch beim TTS-System bewusst lokale Komponenten auswählen.
Eine tatsächlich vollständig lokale Verarbeitung könnte beispielsweise so aussehen:
Benutzer ↓ Open WebUI ↓ lokales Ollama-Modell ↓ lokaler TTS-Dienst ↓ lokale Audiodatei
In diesem Szenario muss die eigentliche Verarbeitung nicht das Internet verlassen.
Vorteile für Datenschutz und sensible Inhalte
Gerade bei vertraulichen Informationen kann eine lokale TTS-Architektur interessant sein.
Mögliche Inhalte sind beispielsweise:
- interne Dokumente
- technische Dokumentationen
- Protokolle
- Verwaltungsinformationen
- Schulungsunterlagen
- Wissensdatenbanken
- interne Anleitungen
- vertrauliche Texte
Bei einer vollständig lokalen Verarbeitung müssen diese Daten grundsätzlich nicht an einen externen Sprachdienst übertragen werden.
Das bedeutet allerdings nicht automatisch, dass eine lokale Installation sicher ist.
Auch ein lokales KI-System benötigt ein Sicherheitskonzept.
Dazu gehören beispielsweise:
- Zugriffskontrollen
- Authentifizierung
- Netzwerksegmentierung
- sichere Container
- regelmäßige Updates
- geschützte APIs
- TLS
- Protokollierung
- Berechtigungen
- Backup und Recovery
„Lokal“ und „sicher“ sind also nicht dasselbe.
Lokaler Betrieb schafft jedoch die Möglichkeit, Verarbeitung und Datenflüsse wesentlich stärker selbst zu kontrollieren.
Offline-Betrieb
Ein weiterer Vorteil lokaler TTS-Systeme ist die Möglichkeit des Offline-Betriebs.
Sind alle benötigten Modelle und Abhängigkeiten bereits vorhanden, kann eine entsprechend vorbereitete Architektur auch ohne dauerhafte Internetverbindung arbeiten.
Das kann beispielsweise für folgende Umgebungen interessant sein:
- abgeschottete Netze
- Entwicklungsumgebungen
- Labore
- interne Unternehmensnetze
- Behördennetze
- Testsysteme
- mobile Installationen
- Umgebungen mit eingeschränkter Internetanbindung
Allerdings muss dabei berücksichtigt werden, dass Installation, Updates und das Herunterladen neuer Modelle zunächst meist einen entsprechenden Bezugsweg benötigen.
Ein echter Offline-Betrieb muss deshalb geplant werden.
Typische Einsatzmöglichkeiten
Die Kombination aus Ollama und Text-to-Speech eröffnet deutlich mehr Möglichkeiten als das reine Vorlesen einzelner Chatantworten.
Antworten aus Open WebUI vorlesen
Der einfachste Anwendungsfall ist die Sprachausgabe einer KI-Antwort.
Der Benutzer stellt eine Frage:
Wie aktualisiere ich Debian?
Ollama erzeugt eine Antwort und der TTS-Dienst liest sie anschließend vor.
Das kann besonders für Barrierefreiheit oder paralleles Arbeiten hilfreich sein.
Technische Dokumentationen vorlesen
Längere Anleitungen lassen sich zunächst durch Ollama für die Sprachwiedergabe optimieren.
Aus:
apt update && apt full-upgrade
könnte beispielsweise eine natürlichere Erklärung werden:
Aktualisieren Sie zunächst die Paketlisten. Führen Sie anschließend die vollständige Systemaktualisierung durch.
Anschließend wird diese Fassung gesprochen.
Schulungsunterlagen vertonen
Lokale KI-Systeme können aus Schulungstexten Audiofassungen erzeugen.
Das eignet sich beispielsweise für:
- IT-Schulungen
- Sicherheitsschulungen
- interne Fortbildungen
- Einweisungen
- Lerninhalte
Blogartikel vertonen
Aus einem bestehenden Artikel kann automatisch eine Hörfassung entstehen.
Dabei könnte Ollama zuerst eine geeignete Sprechfassung erzeugen und anschließend TTS die Audiodatei produzieren.
So lassen sich beispielsweise zusätzliche Audioangebote für einen Blog bereitstellen.
Interne Podcasts erzeugen
Auch interne Informationsformate sind denkbar.
Ein vorhandener Text könnte automatisch in ein Skript umgewandelt und anschließend vertont werden.
Beispielsweise:
Wochenbericht ↓ Ollama ↓ Podcast-Skript ↓ TTS ↓ interne Audiodatei
Barrierefreiheit verbessern
Text-to-Speech kann außerdem helfen, Informationen zusätzlich akustisch bereitzustellen.
Dabei sollte TTS allerdings nicht als alleinige Barrierefreiheitsmaßnahme verstanden werden.
Es ist vielmehr eine zusätzliche Ausgabemöglichkeit.
Vom Chatbot zum Sprachassistenten
Text-to-Speech ist außerdem nur eine Hälfte eines vollständigen Sprachsystems.
Wird zusätzlich Speech-to-Text eingesetzt, entsteht ein echter Sprachdialog.
Die Architektur sieht dann beispielsweise so aus:
Mikrofon ↓ Speech-to-Text ↓ Text ↓ Ollama ↓ Antwort ↓ Text-to-Speech ↓ Lautsprecher
Der Benutzer spricht eine Frage.
Ein Speech-to-Text-Modell wandelt die Aufnahme in Text um.
Ollama verarbeitet die Anfrage.
Die Antwort wird anschließend von der TTS-Engine gesprochen.
Open WebUI bringt bereits Funktionen für Sprachverarbeitung mit und unterstützt sowohl Speech-to-Text als auch Text-to-Speech sowie einen Voice-Modus.
Dieses Thema werden wir später in der Serie noch ausführlicher behandeln.
CPU oder GPU?
Nicht jedes TTS-System benötigt zwingend eine leistungsfähige Grafikkarte.
Einige kleinere Modelle können problemlos auf CPUs betrieben werden.
Andere Modelle profitieren stark von GPU-Beschleunigung.
Für den praktischen Betrieb sind mehrere Faktoren wichtig:
- Größe des TTS-Modells
- gewünschte Geschwindigkeit
- Anzahl gleichzeitiger Benutzer
- Länge der Texte
- gewünschte Audioqualität
- vorhandene Hardware
Für einzelne Benutzer kann bereits eine relativ kleine Installation ausreichen.
Soll dagegen eine zentrale Plattform viele längere Texte gleichzeitig vertonen, steigen die Anforderungen entsprechend.
Latenz spielt eine wichtige Rolle
Bei Text-to-Speech ist nicht nur die Qualität entscheidend.
Auch die Verzögerung zwischen Text und Audio ist wichtig.
Bei einem interaktiven Sprachassistenten sollte möglichst schnell die erste Audioausgabe beginnen.
Bei einer automatischen Blogvertoung spielt eine Verzögerung von einigen Sekunden dagegen kaum eine Rolle.
Daraus entstehen zwei unterschiedliche Anforderungen.
Für interaktive Systeme:
geringe Latenz ↓ schnelle erste Audioausgabe
Für Batch-Verarbeitung:
Qualität ↓ Durchsatz ↓ Dateigröße
Die optimale TTS-Lösung hängt deshalb stark vom Einsatzzweck ab.
Lange Texte sind eine besondere Herausforderung
Viele TTS-Engines können nicht beliebig große Texte in einem einzigen Vorgang verarbeiten.
Lange Inhalte müssen deshalb häufig aufgeteilt werden.
Beispielsweise:
Artikel ↓ Absatz 1 Absatz 2 Absatz 3 Absatz 4 ↓ einzelne Audiodateien ↓ zusammenführen
Open WebUI kann Antworten bereits anhand verschiedener Kriterien in kleinere Bereiche aufteilen. Unter anderem können Satzzeichen oder Absätze als Trennpunkte verwendet werden.
Für komplette Blogartikel oder Dokumente ist später häufig eine eigene Aufteilungslogik sinnvoll.
Aussprache ist nicht automatisch perfekt
Auch sehr gute TTS-Modelle können Schwierigkeiten mit speziellen Begriffen haben.
Besonders problematisch sind häufig:
- Produktnamen
- Abkürzungen
- URLs
- IP-Adressen
- Dateipfade
- Programmiersprachen
- Versionsnummern
- englische Fachbegriffe in deutschen Texten
Beispielsweise kann ein Satz wie:
Installiere nginx über apt und rufe anschließend https://server.example.org auf.
für einen Menschen leicht verständlich sein.
Für eine TTS-Engine sind darin jedoch mehrere potenziell problematische Bestandteile enthalten.
Deshalb ist eine zusätzliche Textoptimierung häufig sinnvoll.
Genau hier kann wiederum Ollama helfen.
Ollama als Audio-Redakteur
Eine besonders interessante Kombination entsteht, wenn Ollama nicht nur die eigentliche Antwort erzeugt, sondern den Text zusätzlich für die Sprachausgabe aufbereitet.
Aus:
Öffnen Sie /etc/nginx/sites-enabled/example.conf und prüfen Sie anschließend mit nginx -t die Konfiguration.
könnte beispielsweise werden:
Öffnen Sie zunächst die Konfigurationsdatei der Website im Nginx-Verzeichnis. Prüfen Sie anschließend mit dem Befehl nginx minus t, ob die Konfiguration fehlerfrei ist.
Für eine technische Dokumentation wäre die erste Variante genauer.
Für eine Hörfassung kann die zweite Variante angenehmer sein.
Damit entsteht eine klare Verarbeitungskette:
Originaltext ↓ Ollama ↓ sprechoptimierter Text ↓ TTS ↓ Audio
Eine mögliche Gesamtarchitektur
Eine vollständige lokale Installation könnte beispielsweise so aussehen:
Benutzer
│
▼
┌──────────────┐
│ Open WebUI │
└──────┬───────┘
│
┌──────────┴──────────┐
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ Ollama │ │ TTS-Server │
├──────────────┤ ├──────────────┤
│ Llama │ │ Kokoro │
│ Qwen │ │ Piper │
│ Gemma │ │ andere │
└──────┬───────┘ └──────┬───────┘
│ │
▼ ▼
Text Audio
Die einzelnen Dienste können dabei:
- auf demselben Server,
- in unterschiedlichen Docker-Containern,
- auf verschiedenen virtuellen Maschinen
- oder sogar auf getrennten physischen Servern
betrieben werden.
Gerade bei größeren Installationen ist diese Trennung sehr hilfreich.
Container erleichtern den Betrieb
Für viele TTS-Projekte bietet sich Docker an.
Dadurch können Ollama, Open WebUI und TTS beispielsweise als getrennte Container betrieben werden.
Eine vereinfachte Struktur könnte aussehen:
docker-compose │ ├── ollama │ ├── open-webui │ └── tts
Jeder Dienst hat damit:
- eigene Abhängigkeiten
- eigene Updates
- eigene Ports
- eigene Logs
- eigene Ressourcen
Gleichzeitig können die Dienste über ein gemeinsames internes Docker-Netz miteinander kommunizieren.
Grenzen lokaler TTS-Systeme
So interessant lokale Sprachverarbeitung ist, sie bringt auch einige Herausforderungen mit.
Hardwarebedarf
Hochwertige Modelle können zusätzliche CPU-, RAM- oder GPU-Ressourcen benötigen.
Sprachqualität
Nicht jede lokale Stimme erreicht die Qualität großer kommerzieller Cloud-Plattformen.
Aussprache
Fachbegriffe oder Produktnamen können falsch ausgesprochen werden.
Wartung
Auch ein TTS-System benötigt Updates und Pflege.
Speicherplatz
Modelle und erzeugte Audiodateien benötigen zusätzlichen Speicher.
Gleichzeitige Benutzer
Bei mehreren parallelen TTS-Anfragen können CPU oder GPU schnell zum Engpass werden.
Sicherheit
Eine ungeschützte TTS-API sollte nicht einfach öffentlich aus dem Internet erreichbar sein.
Betrieb
Für produktive Systeme sollten Monitoring, Logging und Healthchecks berücksichtigt werden.
Welche Anforderungen sollte der Server erfüllen?
Eine allgemeingültige Mindestanforderung gibt es nicht.
Für erste Experimente reichen häufig:
- aktueller Linux-Server
- Docker oder vergleichbare Containertechnik
- mehrere Gigabyte Arbeitsspeicher
- ausreichend freier Speicher
- Netzwerkverbindung zwischen den Diensten
Eine GPU ist nicht zwingend erforderlich.
Für höhere Geschwindigkeit oder größere Modelle kann eine NVIDIA-GPU allerdings erhebliche Vorteile bieten.
Entscheidend ist immer der konkrete Einsatzzweck.
Ein privater Sprachassistent für einen einzelnen Benutzer stellt andere Anforderungen als ein zentraler TTS-Dienst für eine größere Organisation.
Ollama um Text-to-Speech zu erweitern bedeutet nicht zwangsläufig, die Sprachausgabe direkt in Ollama einzubauen.
Eine deutlich flexiblere Lösung besteht darin, Ollama und TTS als getrennte Dienste zu betrachten.
Ollama übernimmt die Aufgabe des Denkens und Formulierens.
Die TTS-Engine übernimmt die Sprachausgabe.
Open WebUI kann beide Komponenten miteinander verbinden.
Dadurch entsteht eine modulare Architektur:
Benutzer ↓ Open WebUI ↓ Ollama ↓ Text ↓ TTS ↓ Sprache
Diese Trennung erleichtert Updates, ermöglicht den Austausch einzelner Komponenten und erlaubt den Aufbau vollständig lokal betriebener KI-Audio-Systeme.
Besonders interessant wird das Konzept, wenn Ollama zusätzlich als Redakteur für die Sprachausgabe eingesetzt wird. Dann entsteht aus einem normalen Text zunächst eine hörfreundliche Fassung, die anschließend durch eine lokale TTS-Engine vertont wird.
Damit ist die Grundlage für zahlreiche weitere Anwendungen geschaffen: vorgelesene Chatantworten, automatische Hörfassungen von Blogartikeln, interne Schulungsinhalte oder sogar vollständig lokale Sprachassistenten.
Im nächsten Teil der Serie schauen wir uns deshalb genauer an, welche lokalen Text-to-Speech-Lösungen derzeit infrage kommen und wie sich beispielsweise Kokoro, Piper und andere Systeme hinsichtlich Sprachqualität, Ressourcenbedarf und Einsatzgebiet unterscheiden.
