Speech-AI-Forge: a multi-model TTS server and Gradio front end
🍦 Speech-AI-Forge is a project developed around TTS generation model, implementing an API Server and a Gradio-based WebUI.
At a glance
- What is it?
- Speech-AI-Forge wraps several open TTS and ASR models behind one FastAPI server and one Gradio WebUI. It is a good fit if you want to compare voices across models without writing glue for each one, and a poor fit if you need a single-model, low-latency endpoint or a permissive licence.
- Who is it for?
- Adopt Speech-AI-Forge if you need one HTTP surface over several TTS backends and you can accept AGPL-3.0 terms, or if you want a local WebUI for building and auditioning voices from ChatTTS seeds and reference audio. Do not adopt it if you need a small, single-model inference path with predictable memory, or if your product cannot ship under a copyleft licence.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 117 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: too many TTS models, too many incompatible entry points
Each of the TTS projects listed in the README ships its own inference script, its own checkpoint layout and its own way of conditioning on a voice. ChatTTS conditions on a random seed. F5-TTS and CosyVoice use reference audio. FishSpeech, GPT-SoVITS, FireRedTTS, Spark-TTS and Index-TTS each bring their own conventions as well. If you want to hear the same sentence in several of them, you normally install each repository separately and write a thin wrapper per model. Speech-AI-Forge exists to collapse that work. The README describes it as a project built around TTS generation models that implements an API Server and a Gradio-based WebUI, and the model support table lists ten TTS entries plus MiniMax Cloud TTS and the ASR models Whisper and SenseVoice. The intended user is someone who needs to compare or switch between those backends without maintaining ten environments, or who wants a browser UI for voice design rather than a Python API.
Architecture: one server, two front doors, pluggable model backends
The repository exposes two entry points. webui.py starts the Gradio interface, and launch.py starts an API-only server. The README states that after running python launch.py you can open http://localhost:7870/docs to see which API endpoints are enabled, which implies a FastAPI-style OpenAPI page on port 7870. A separate API document lives at docs/api.md, and python launch.py -h prints the script arguments. The breaking change log shows the API surface growing over time: an ASR API was added on 240801 and a v2/tts API on 241111, so v1 and v2 TTS routes coexist. The WebUI is not a thin client over that API. It carries its own feature set: speaker switching with built-in voices (the README states 27 ChatTTS voices, 7 CosyVoice voices and 1 reference voice), style control, long-text inference with automatic splitting, a ChatTTS refiner, splitter settings for end-of-sentence tokens and thresholds, an adjuster for speed, pitch, volume and loudness equalisation, and a voice enhancer model. The SSML layer sits on top: a splitter, a Podcast mode for long multi-role audio, a From Subtitle importer, and a script editor that exports and re-imports SSML. Voice management is a separate area with a builder that creates voices from ChatTTS seeds or reference audio, a test-voice page, seed-based random voice sampling, seed blending, and a voice hub that pulls from the Speech-AI-Forge-spks repository. The practical consequence is that the WebUI is where voice design happens and the API server is where production traffic goes, and the two are started by different scripts.
Getting it running: three paths, and what each one asks of you
The README gives a Windows portable package (release portable_v0.7, dated 2026-02-02) that is described as unpack-and-run, a Colab notebook linked from the badge, and local installation. Local installation has two prerequisites stated in the README: dependencies must be installed per docs/dependencies.md, and the required models must be downloaded per the model download section. Only then do you run python webui.py. The API-only path is python launch.py, with python launch.py -h for arguments. Container deployment uses two compose files: docker-compose.webui.yml for the WebUI and docker-compose.api.yml for the API, both run with docker-compose -f <file> up -d. Environment variables for each are read from .env.webui and .env.api respectively. Notice what is missing from the README excerpt: it does not list the concrete keys inside those env files, nor the exact model download commands. Those live in the linked documents, and you should read them before assuming a one-command install. The dependency document matters more than usual here because the supported models span different PyTorch and CUDA expectations, and the README does not claim they all resolve cleanly in a single environment.
Where the multi-model design costs you
Breadth has a price. Each supported model brings its own weights, and the README's install order (dependencies, then models, then run) suggests the models are downloaded separately rather than fetched on demand. That means disk and VRAM planning is per model, not per deployment, and a machine sized for ChatTTS will not necessarily hold CosyVoice v2/v3, FishSpeech 1.4 and GPT-SoVITS at once. The breaking change log reinforces how fast this moves: Index-TTS-1 on 250505, Index-TTS-1.5 on 250702, Index-TTS-2 on 250912, Qwen3-TTS on 260129, CosyVoice3 on 260202, and MiniMax Cloud TTS on 260402. Six backend additions in roughly eleven months. If you pin to a specific voice, you inherit the upgrade cadence of whichever backend produces it. There is also a mismatch between the two front doors: the WebUI exposes refiner, splitter, adjuster and enhancer controls that the README does not map to API parameters, so a voice tuned in the browser may not reproduce exactly through launch.py without reading docs/api.md. Finally, the Cloud TTS entry is a category of its own. MiniMax Cloud TTS sends text to a third party, which changes your data handling story entirely compared with the local models, and the README excerpt does not describe how credentials for it are configured.
Alternatives: a single-model server versus a multi-model shell
The clearest alternative in the same space is a single-model server such as the upstream ChatTTS, F5-TTS or CosyVoice repositories run behind your own HTTP wrapper. The difference is not quality, it is surface area. A single-model deployment has one checkpoint, one set of conditioning rules and one upgrade path that you control; you write perhaps a hundred lines of FastAPI around the model's own inference function. Speech-AI-Forge trades that control for a shared request format across ten backends and a browser UI for voice building, seed sampling and SSML authoring. If your product has settled on one voice from one model, the single-model route is smaller and easier to reason about. If you are still choosing a voice, or you need to offer several, the Forge saves you from maintaining parallel environments. A second alternative worth naming is a hosted TTS API. Speech-AI-Forge itself supports one (MiniMax), which is an admission that cloud inference is a legitimate option. The trade is latency, per-character cost and text leaving your infrastructure against zero GPU operations on your side.
Licence and maintenance cost
The repository is AGPL-3.0. That is a copyleft licence with a network clause: if you run modified code as a network service, the licence's terms extend to users of that service. This is the single largest adoption decision in the project, and it is independent of how good the software is. If your product is closed source and you would be exposing the Forge as a service, AGPL-3.0 is a constraint you need to resolve with your own legal counsel before writing integration code. Note also that the licence covers this repository, not the model weights it loads. ChatTTS, CosyVoice, FishSpeech, F5-TTS, GPT-SoVITS, FireRedTTS, Spark-TTS, Index-TTS and Qwen3-TTS each carry their own licence terms, and those terms are what govern the audio you generate. The README does not summarise them, so checking each model's licence is work you cannot skip. On maintenance: the breaking change log shows a steady stream of backend additions through 2026, and the latest release in the material is the portable package from 2026-02-02. The project is active, but active also means the API and supported model list move. Treat any integration as something that needs re-verification when you bump versions rather than a frozen dependency.
The SSML and podcast layer is the underrated part
Most of the README is about models, but the SSML tooling is what distinguishes this from a plain model wrapper. Podcast mode targets long, multi-role audio, which is the case where naive text-to-speech falls apart: you need to split a script, assign voices per role, and keep the segments coherent. The From Subtitle importer turns a subtitle file into an SSML script, and the script editor lets you export from the splitter, edit, and feed it back. The splitter exposes the end-of-sentence token and threshold directly, which is the control you actually need when automatic segmentation cuts mid-sentence. This is a workflow feature rather than an inference feature, and it is the part that would be tedious to rebuild around a single model. If your use case is one sentence at a time, none of it matters. If you are producing long-form or multi-speaker audio, it is the reason to look here rather than at the individual model repositories.
Editorial conclusion
Adopt Speech-AI-Forge if you need one HTTP surface over several TTS backends and you can accept AGPL-3.0 terms, or if you want a local WebUI for building and auditioning voices from ChatTTS seeds and reference audio. Do not adopt it if you need a small, single-model inference path with predictable memory, or if your product cannot ship under a copyleft licence. Before committing, verify three things in your own environment: which model weights your target voices actually require and where they are downloaded from, whether the API endpoints exposed at http://localhost:7870/docs cover the request shape your client sends, and whether the container or portable build you plan to deploy is the one that matches your GPU and Python version.
Community notes