Speech-AI-Forge : une façade unifiée pour une dizaine de moteurs TTS

Le problème concret : chaque moteur TTS a sa propre plomberie

Prendre un modèle TTS en production implique d'écrire une couche d'inférence, un découpage de texte, une gestion de locuteurs et un serveur HTTP. Recommencer pour un deuxième moteur double ce travail. Speech-AI-Forge répond à ce point précis : le dépôt se présente comme un projet construit autour des modèles de génération TTS, exposant un serveur API et une interface Gradio. Le public visé est donc l'équipe qui veut essayer ChatTTS, CosyVoice, FishSpeech, F5-TTS ou GPT-SoVITS sans réimplémenter la même tuyauterie à chaque fois. Le journal des changements montre que cette accumulation est le cœur du projet : Index-TTS, Qwen3-TTS, Spark-TTS, FireRedTTS, GptSoVits et SenseVoice ASR y sont arrivés par vagues successives, avec un ajout de Cloud TTS MiniMax en 260402. La contrepartie est assumée : le dépôt porte la dette de tous ces moteurs à la fois.

Deux points d'entrée, une seule base de code

Le dépôt expose deux scripts distincts. python webui.py démarre l'interface Gradio, décrite dans docs/webui_features.md. python launch.py démarre uniquement le serveur API, ce que le README justifie par un besoin de débit supérieur ou par l'absence de besoin d'interface graphique. Une fois launch.py lancé, la documentation indique que http://localhost:7870/docs liste les points d'entrée disponibles, ce qui correspond à une documentation OpenAPI générée. Le README renvoie aussi vers docs/api.md pour le détail. Les deux scripts partagent la même couche d'inférence : les modèles, les voix et les réglages configurés dans la WebUI ne sont pas un monde séparé de l'API. C'est le principal argument technique du projet, et aussi sa principale source de complexité, puisque toute évolution de l'interface touche un code que l'API utilise également.

Le pipeline TTS vu depuis la WebUI

Le texte passe d'abord par un découpage. La WebUI expose un réglage de splitter qui contrôle le caractère de fin de segment et un seuil de découpage, ce qui laisse supposer que les segments trop courts sont fusionnés. Vient ensuite l'étape de génération, avec un choix de locuteur parmi les voix intégrées (27 ChatTTS et 7 CosyVoice, plus une voix de référence selon le README), ou une voix personnalisée importée, ou encore une référence audio fournie à la volée. Un réglage de batch size est prévu pour accélérer les modèles capables de traiter plusieurs segments ensemble. La sortie traverse enfin un ajusteur de vitesse, de hauteur et de volume, avec une option de normalisation de sonie, puis éventuellement un modèle Enhancer de renforcement de la voix. Le résultat est conservé dans un historique limité aux trois dernières générations. Cette chaîne est décrite dans la documentation, pas mesurée ici.

SSML et podcast : la partie qui dépasse la simple synthèse

La WebUI ajoute une couche SSML avec un éditeur de script, un mode Podcast pour les textes longs à plusieurs rôles, et une conversion depuis un fichier de sous-titres. L'intérêt pratique est de séparer l'écriture du script de l'exécution de la synthèse : on exporte depuis le splitter ou depuis les sous-titres, on retouche le SSML, puis on relance. C'est la fonctionnalité qui distingue le projet d'un simple wrapper autour d'un modèle. Elle impose en revanche d'apprendre le dialecte SSML retenu par le projet, et la documentation fournie ici ne détaille pas la liste des balises acceptées. Pour un usage ponctuel, cette couche représente un coût d'apprentissage sans bénéfice immédiat.

ASR et alignement forcé : le voisinage du TTS

Le projet ne se limite pas à la synthèse. La WebUI intègre une reconnaissance vocale via Whisper ou SenseVoice, ainsi qu'un alignement forcé avec Whisper pour ce que le README appelle la correspondance de script, c'est-à-dire l'alignement d'un texte connu sur un audio. Un point d'entrée ASR a été ajouté au serveur en 240801. Cette proximité a un sens : produire un jeu de données de voix personnalisées suppose de transcrire et d'aligner des enregistrements. Le revers est que le périmètre du projet s'élargit encore, avec les dépendances et les poids de modèles supplémentaires que cela implique.

Installation : ce que le dépôt demande vraiment

Le README est explicite sur l'ordre des opérations : installer les dépendances listées dans docs/dependencies.md, puis télécharger les modèles, avant de lancer python webui.py ou python launch.py. Les paramètres du script API se consultent avec python launch.py -h. Pour les conteneurs, deux fichiers distincts sont fournis : docker-compose.webui.yml et docker-compose.api.yml, avec des variables d'environnement dans .env.webui et .env.api. Un整合包 Windows est publié dans les releases, la dernière étant portable_v0.7. Un notebook Colab est également proposé pour un essai sans installation locale. Rien dans le matériel fourni ne décrit la taille des poids à télécharger ni la quantité de VRAM nécessaire : ce sont les deux premières choses à vérifier avant de s'engager.

La limite structurelle : un dépôt, dix moteurs

Supporter autant de moteurs a un coût. Chacun apporte ses dépendances Python, ses poids, ses formats de voix et ses paramètres d'inférence, et le tableau du README montre des versions figées pour plusieurs d'entre eux (FishSpeech 1.4, F5-TTS v0.6/v1, Index-TTS v1/v1.5, CosyVoice v2/v3). Quand un moteur amont change d'API, l'adaptation se fait ici. Le journal des changements est d'ailleurs présenté comme un journal de ruptures, ce qui indique que les mises à jour ne sont pas toujours rétrocompatibles. Si vous n'utilisez qu'un seul moteur, vous héritez de la surface de maintenance de tous les autres sans contrepartie. Et si votre besoin est un service TTS hébergé avec un engagement de disponibilité, un projet communautaire de cette forme n'est pas l'outil adapté.

Alternatives et différence d'approche

Le README liste lui-même les dépôts amont : ChatTTS, CosyVoice, F5-TTS, FishSpeech, GPT-SoVITS, Index-TTS, Spark-TTS, FireRedTTS, Qwen3-TTS. Chacun fournit son propre script d'inférence et, pour certains, sa propre interface. La différence n'est pas la qualité du son, elle est architecturale : un dépôt amont suit une seule famille de modèles et son API évolue avec elle, tandis que Speech-AI-Forge maintient une couche d'abstraction commune au-dessus de toutes. Vous gagnez la comparaison A/B dans une même interface et un point d'entrée unique ; vous perdez la réactivité face aux mises à jour amont et vous dépendez du rythme de ce dépôt pour chaque correctif. Pour un usage en recherche où l'on veut opposer plusieurs voix sur un même corpus, l'abstraction se défend. Pour industrialiser un seul modèle, elle s'interpose.

Licence et coût de mise à jour

Le dépôt est publié sous AGPL-3.0. Concrètement, si vous exposez le service à des utilisateurs sur un réseau, cette licence impose de fournir le code source correspondant à ces utilisateurs. Pour un usage interne ou une expérimentation locale, la question ne se pose pas de la même façon. Elle devient centrale si vous intégrez le serveur dans un produit distribué ou hébergé : il faut vérifier ce point avec votre juriste, car je ne peux pas trancher à votre place. À cela s'ajoute le coût de mise à jour : suivre le dépôt signifie relire un journal de ruptures, retélécharger des poids quand un moteur change de version, et retester vos voix personnalisées, dont le format peut dépendre du moteur sous-jacent. Le README ne documente pas de procédure de migration entre versions.

Conclusion éditoriale

Adoptez Speech-AI-Forge si vous devez faire cohabiter plusieurs moteurs TTS dans un seul service et que la licence AGPL-3.0 est compatible avec votre distribution. Évitez-le pour un produit embarqué propriétaire ou si vous ne voulez qu'un seul modèle, car vous porteriez la maintenance de tout l'écosystème. Avant de vous engager, vérifiez le contenu de docs/dependencies.md et la disponibilité des poids sur Hugging Face, puis comparez la sortie de v2/tts avec celle de votre moteur actuel sur vos propres phrases.

Sources officielles

1. Issues
2. lenML/Speech-AI-Forge on GitHub
3. License: AGPL-3.0
4. README
5. Releases