Speech-AI-Forge: ein API-Server und eine Gradio-WebUI für viele TTS-Modelle
🍦 Speech-AI-Forge is a project developed around TTS generation model, implementing an API Server and a Gradio-based WebUI.
Auf einen Blick
- Was ist das?
- Das Projekt bündelt Modelle wie ChatTTS, CosyVoice, F5-TTS, GPT-SoVITS und FishSpeech hinter einer Oberfläche und einer HTTP-API. Der Nutzen liegt in der Vereinheitlichung, der Preis in einer sehr langen Liste von Abhängigkeiten und einem AGPL-3.0-Lizenzrahmen.
- Für wen ist es gedacht?
- Sinnvoll ist Speech-AI-Forge für Teams, die mehrere TTS-Modelle vergleichen und dafür eine gemeinsame HTTP-Schnittstelle brauchen, statt jedes Modell einzeln zu bedienen. Wer nur ein einziges Modell mit möglichst kleiner Abhängigkeitsfläche betreiben will, sollte beim jeweiligen Upstream-Projekt bleiben.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 117 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem die Modellvielfalt erzeugt
Wer heute Sprachsynthese einsetzen will, steht vor einer Auswahl, die sich etwa alle zwei Monate verschiebt. ChatTTS, CosyVoice in den Versionen v2 und v3, F5-TTS, FishSpeech 1.4, GPT-SoVITS, FireRedTTS, Spark-TTS, Index-TTS in v1 und v1.5 sowie Qwen3-TTS haben jeweils eigene Installationswege, eigene Inferenzskripte und eigene Formate für Referenzaudios. Die Breaking-change-Liste im README zeigt diesen Takt: 260202 CosyVoice3, 260129 Qwen3-TTS, 250912 Index-TTS-2, 250722 GptSoVits, 250508 Spark-TTS. Jeder Eintrag ist eine neue Integrationsarbeit.
Speech-AI-Forge setzt genau dort an. Das Projekt implementiert laut eigener Beschreibung einen API Server und eine auf Gradio basierende WebUI und führt die genannten Modelle unter einer Bedienoberfläche zusammen. Adressiert sind damit zwei Gruppen. Erstens Entwickler, die eine HTTP-Schnittstelle brauchen und nicht für jedes Modell einen eigenen Wrapper schreiben wollen. Zweitens Anwender, die ohne Python-Kenntnisse Stimmen ausprobieren, Referenzaudios hochladen und Ergebnisse vergleichen möchten. Das README nennt für die WebUI unter anderem eine Generation History der letzten drei Ergebnisse, was den Vergleichsgedanken stützt.
Ein Punkt vorweg: Das Projekt löst nicht das Problem knapper GPU-Ressourcen. Mehrere Modelle im gleichen Prozess bedeuten mehrere Gewichtssätze, und das README macht keine Angaben dazu, wie Speicher zwischen Modellen freigegeben wird.
Zwei Startpunkte, ein gemeinsamer Kern
Die Architektur ist an zwei Einstiegspunkten sichtbar. webui.py startet die Gradio-Oberfläche, launch.py startet ausschließlich den API-Server. Das README begründet den zweiten Weg ausdrücklich damit, dass man manchmal keine WebUI braucht oder einen höheren API-Durchsatz möchte. Beide Skripte greifen auf dieselbe Modellschicht zu, sonst wäre die Trennung sinnlos.
Der Datenfluss lässt sich aus der Funktionsbeschreibung rekonstruieren. Text gelangt über die WebUI oder einen API-Endpunkt hinein. Ein Splitter zerlegt lange Texte anhand von Endmarken und einem konfigurierbaren Schwellenwert; das README spricht von eos und Splitter-Threshold. Danach folgt die eigentliche Modellinferenz, wahlweise mit einem Referenzaudio und zugehörigem Referenztext für Zero-Shot-Stimmen. Ein Adjuster verändert Geschwindigkeit, Tonhöhe und Lautstärke und bietet zusätzlich Loudness-Normalisierung. Optional läuft das Ergebnis durch ein Enhancer-Modell. Die Ausgabe wird als Audiodatei zurückgegeben und in der WebUI zusätzlich in der History gehalten.
Bemerkenswert ist die SSML-Schicht. Das README beschreibt einen Script Editor, in den sich Ergebnisse aus dem Splitter oder aus Untertiteldateien exportieren und anschließend bearbeiten lassen. Für mehrrollige Formate gibt es den Podcast-Modus. Das ist mehr als eine Demo-Oberfläche: Hier wird ein Zwischenformat eingeführt, das sich versionieren und erneut abspielen lässt. Wer regelmäßig Hörfassungen aus Untertiteln erzeugt, spart damit manuelles Nachschneiden.
Installation: Abhängigkeiten zuerst, Modelle danach
Die Reihenfolge im README ist eindeutig. Zuerst müssen laut docs/dependencies.md die Umgebungsabhängigkeiten installiert sein, danach sind die Modellgewichte über den Abschnitt Modell-Download zu beziehen. Erst dann startet man. Wer die Modelle zuerst herunterlädt, hat nichts gewonnen, weil die Laufzeitumgebung fehlt.
Für die WebUI lautet der Befehl:
python webui.py
Für den reinen API-Betrieb:
python launch.py
Nach dem Start des API-Servers sind unter http://localhost:7870/docs die verfügbaren Endpunkte einsehbar. Das README verweist zusätzlich auf docs/api.md und auf python launch.py -h für die Skriptparameter. Der Endpunkt v2/tts wurde laut Changelog am 241111 ergänzt, ein ASR-Endpunkt am 240801. Wer die API anbindet, sollte die eigene Dokumentation lesen und nicht aus Changelog-Einträgen auf Feldnamen schließen.
Für Container gibt es zwei getrennte Compose-Dateien. Die WebUI startet mit docker-compose -f ./docker-compose.webui.yml up -d, der API-Server mit docker-compose -f ./docker-compose.api.yml up -d. Die zugehörigen Umgebungsvariablen liegen in .env.webui und .env.api. Diese Trennung ist konsequent, weil beide Dienste unterschiedliche Ressourcenprofile haben.
Zusätzlich existiert ein Windows-Integrationspaket. Die aktuelle Veröffentlichung heißt portable_v0.7 (Portable 整合包 v0.7) und stammt vom 2026-02-02. Ein Colab-Notebook ist ebenfalls verlinkt.
Wo das Projekt an seine Grenzen stößt
Die größte Einschränkung ist die Zahl der beweglichen Teile. Neun TTS-Modellfamilien, dazu ASR über Whisper und SenseVoice, dazu ein Enhancer, ein Adjuster und ein Splitter. Jede dieser Komponenten bringt eigene Abhängigkeiten mit, und die Breaking-change-Liste zeigt, dass Integrationen nachträglich angepasst werden. Ein Update des Forks kann eine funktionierende Modellversion verschieben. Wer Reproduzierbarkeit braucht, sollte Versionen von Modell und Forge gemeinsam pinnen.
Zweitens die Sprachabdeckung. Sie ist nicht für alle Modelle gleich. CosyVoice und GPT-SoVITS decken laut Tabelle en, zh, jp, ko und yue ab, FishSpeech en, zh, jp, ko, FireRedTTS dagegen nur en und zh. Wer eine dritte Sprache braucht, muss das Modell wechseln und damit auch die Stimmcharakteristik. Die Tabelle im README ist hier die maßgebliche Quelle, nicht die Themenliste des Repositories.
Drittens die Lizenz. Der Code steht unter AGPL-3.0. Diese Lizenz verlangt bei einer Bereitstellung über ein Netzwerk, dass Nutzer den zugehörigen Quellcode erhalten können. Für ein internes Werkzeug ohne Außenzugriff ist das selten ein Thema. Für einen gehosteten Dienst, der auf Speech-AI-Forge aufsetzt, ist es eines. Das gilt zusätzlich zu den Lizenzen der Modellgewichte selbst, die das Projekt nicht vereinheitlicht und die unterschiedlich ausfallen können. Eine rechtliche Bewertung kann hier nicht geleistet werden, aber die Prüfung sollte vor und nicht nach dem Deployment stattfinden.
Viertens die Dokumentationslage. Das README beschreibt Funktionen, aber es nennt keine Latenzwerte, keine Speicheranforderungen pro Modell und keine Angaben dazu, wie viele Anfragen der API-Server parallel verarbeitet. Wer Kapazität planen muss, bekommt aus dem vorliegenden Material keine Zahlen.
Der Vergleich mit einem einzelnen Upstream-Modell
Die naheliegende Alternative ist, direkt eines der Modelle zu betreiben, etwa F5-TTS aus dem Repository SWivid/F5-TTS oder CosyVoice aus FunAudioLLM/CosyVoice. Der Unterschied liegt nicht in der Ausgabequalität, denn beide Projekte werden von Speech-AI-Forge lediglich aufgerufen. Der Unterschied liegt im Umfang der Installation.
Ein Upstream-Repository bringt in der Regel ein Inferenzskript, ein Beispiel-Notebook und die Gewichte mit. Man installiert genau das, was man braucht, und die Update-Kette ist kurz: neuer Commit, neue Version, man entscheidet selbst. Der Preis ist, dass es keine einheitliche HTTP-Schnittstelle gibt. Für einen Dienst, der zwei Modelle vergleichen soll, schreibt man zwei Wrapper, zwei Startskripte und zwei Fehlerbehandlungen.
Speech-AI-Forge dreht dieses Verhältnis um. Man installiert einmal und bekommt alle Modelle hinter derselben API. Dafür übernimmt man die Integrationsschicht als zusätzliche Abhängigkeit, inklusive ihrer Updatezyklen. Die Entscheidung ist damit keine Frage der Qualität, sondern eine Frage, wie oft man das Modell wechseln will. Bei einem festen Modell ist der Upstream-Weg kürzer. Bei einem Vergleich mehrerer Modelle oder beim Wechsel je nach Sprache ist der Forge-Weg deutlich weniger Arbeit.
Ein zweiter Unterschied betrifft die Oberfläche. Die Upstream-Projekte liefern meist ein Notebook oder ein minimales Skript. Speech-AI-Forge liefert eine WebUI mit Stimmverwaltung, einem Voice Builder, einem Test-Voice-Werkzeug und einem Hub, aus dem sich Stimmen aus dem Repository Speech-AI-Forge-spks herunterladen lassen. Wer nicht programmiert, hat beim Upstream-Projekt faktisch keine Bedienoberfläche.
Wartungskosten und was ein Update mit sich bringt
Das Repository wird aktiv gepflegt. Der letzte Push ist mit 2026-05-21 datiert, die letzte Veröffentlichung portable_v0.7 mit 2026-02-02. Die Changelog-Einträge reichen von 240723 bis 260402 und umfassen sowohl neue Modelle als auch API-Änderungen. Diese Frequenz ist der eigentliche Kostenfaktor.
Konkret bedeutet das: Wer Speech-AI-Forge produktiv einsetzt, muss entscheiden, ob er dem main-Branch folgt oder auf einer Veröffentlichung bleibt. Dem main-Branch zu folgen heißt, dass eine neue Modellintegration die Abhängigkeiten verändern kann, ohne dass sich die eigene Konfiguration ändert. Auf einer Veröffentlichung zu bleiben heißt, dass neue Modelle fehlen. Ein Mittelweg ist, ein eigenes Image auf Basis des Docker-Setups zu bauen und die Modellversionen darin festzuschreiben.
Die Lizenz AGPL-3.0 wirkt sich auf die Wartung indirekt aus. Wenn eigene Änderungen am Code vorgenommen werden und der Dienst Netzwerknutzern zugänglich ist, müssen diese Änderungen nach derselben Lizenz verfügbar gemacht werden. Das ist bei internen Anpassungen an Splitter-Logik oder API-Endpunkten relevant, also genau an den Stellen, an denen man am ehesten eingreift. Wer den Code unverändert als Dienst betreibt, hat diesen Aufwand nicht.
Die Modellgewichte liegen außerhalb dieser Betrachtung. Sie werden separat bezogen, und ihre Bedingungen sind nicht Teil der AGPL-3.0 des Forks. Das README verlinkt die Upstream-Repositories, was die Prüfung erleichtert, sie aber nicht ersetzt.
Für wen sich der Einstieg lohnt
Der stärkste Anwendungsfall ist die Evaluation. Wer herausfinden will, welches der verfügbaren Modelle für einen chinesischen oder englischen Text die passende Stimme liefert, kann in derselben Oberfläche zwischen ChatTTS, CosyVoice und F5-TTS wechseln und die letzten drei Ergebnisse vergleichen. Diesen Vergleich in Eigenbau zu realisieren, kostet mehr Zeit als die Installation des Forks.
Der zweite Anwendungsfall ist die Batch-Erzeugung aus Untertiteln. Der Weg über From Subtitle in den Script Editor und von dort in die Synthese ist im README beschrieben und ersetzt das manuelle Zerlegen langer Texte. Der Splitter mit konfigurierbarer Endmarke und Schwelle ist dafür die eigentliche Arbeit, nicht die Modellinferenz.
Weniger geeignet ist das Projekt für den Betrieb eines einzelnen Modells mit hohen Stückzahlen. Dort dominiert die Inferenzzeit, und die zusätzliche Schicht bringt keinen Nutzen, während sie die Angriffsfläche für Updateprobleme vergrößert. Ebenfalls ungeeignet ist es, wenn die Lizenzbedingungen der Modellgewichte nicht geklärt werden können, denn der Fork löst dieses Problem nicht.
Vor dem ersten produktiven Einsatz sind drei Dinge zu klären: ob die benötigte Sprache von einem Modell mit passender Lizenz abgedeckt ist, ob die eigene Umgebung die in docs/dependencies.md genannten Abhängigkeiten in den vorgesehenen Versionen bereitstellt, und ob der geplante Betriebsmodus die AGPL-3.0-Pflichten auslöst. Der Endpunkt unter http://localhost:7870/docs beantwortet dagegen eine Frage, die sich schnell stellt: welche API-Oberfläche die installierte Version tatsächlich anbietet.
Redaktionelles Fazit
Sinnvoll ist Speech-AI-Forge für Teams, die mehrere TTS-Modelle vergleichen und dafür eine gemeinsame HTTP-Schnittstelle brauchen, statt jedes Modell einzeln zu bedienen. Wer nur ein einziges Modell mit möglichst kleiner Abhängigkeitsfläche betreiben will, sollte beim jeweiligen Upstream-Projekt bleiben. Vor dem Einsatz zu prüfen sind die Modell-Downloads laut docs/dependencies.md, die Lizenzbedingungen der einzelnen Modellgewichte und ob der eigene Anwendungsfall die AGPL-3.0-Pflichten auslöst.
Community-Notizen