Le serveur de llama.cpp sert la synthèse vocale par HTTP
La proposition 26603 de llama.cpp est fusionnée le 20 octobre 2026 à 23 h 19 UTC et sort dans la version b11781 le lendemain : le serveur du projet accepte un POST /tts qui rend un fichier audio à partir d'un texte et d'une voix de référence. Le point d'entrée au format des API vocales d'OpenAI, lui, reste à faire.
par Gyom 22 octobre 2026 à 07:15 3 min de lecture rubrique : Voix et image
etiquettes : Chez soi · Local
llama.cpp servait déjà des modèles de langage et des modèles de vision par son serveur HTTP. Depuis la version b11781, publiée le 21 octobre 2026, il sert aussi des modèles de synthèse vocale. La proposition 26603, fusionnée le 20 octobre 2026 à 23 h 19 UTC, ajoute un point d'entrée POST /tts au serveur, avec 724 lignes ajoutées et 68 retirées sur 21 fichiers.
Un POST /tts qui écrit un fichier audio à partir d'un texte
L'appel tient en une requête JSON dont le champ input porte le texte à prononcer, et la réponse est le fichier audio, que curl écrit directement avec l'option -o. Le rendu au fil de l'eau se demande avec le champ stream, servi par l'interface de sortie audio ajoutée à la bibliothèque multimodale mtmd dans la même proposition, et la graine se transmet en entier 32 bits.
Les champs acceptés par le serveur, tels que la proposition les décrit :
- input, le texte à prononcer, seul champ obligatoire de l'appel JSON ;
- speaker_ref, le fichier de voix de référence, joint en multipart/form-data ;
- seed, la graine de génération, lue comme un entier non signé de 32 bits ;
- stream, le rendu progressif, dont la valeur texte est convertie en booléen avant lecture.
La voix de référence arrive en pièce jointe, plus en base64
Pour imposer un timbre, le client joint un fichier de référence dans un corps multipart/form-data sous le champ speaker_ref, au lieu de l'encoder en base64 dans le JSON, ce qui alourdissait la requête et compliquait l'appel depuis un simple formulaire. Le serveur en mode routeur annonce désormais quels modèles savent produire de l'audio, et écarte un modèle qui ne passe pas le test mtmd_helper_model_can_chat.
Qwen3-TTS, 1,7 milliard de paramètres, dix langues
Le modèle derrière ce point d'entrée est arrivé plus tôt dans l'année. La proposition 26254, fusionnée le 4 août 2026, a ajouté Qwen3-TTS au binaire llama-tts, avec le modèle Qwen3-TTS-12Hz-1.7B-Base en GGUFFormat de fichier de modèle utilisé par llama.cpp et ses dérivés. Le nom du fichier indique la quantification, par exemple Q4_K_M, ce qui suffit à savoir combien de mémoire il demande.Fiche du lexique, une option --tts-lang qui accepte dix langues dont le français, et --tts-speaker-file pour désigner un fichier de référence en wav ou en mp3. La proposition note au passage une rupture de compatibilité sur ce binaire, qui a changé d'arguments à cette occasion.
Ce qui manque encore pour remplacer une API vocale distante
Deux manques sont annoncés dans la proposition elle-même, comme travaux suivants. Une option --tts-speaker-dir doit permettre de désigner une voix par son nom, sans joindre de fichier à chaque appel. Un point d'entrée compatible avec le format des API vocales d'OpenAI doit venir ensuite. Tant qu'ils ne sont pas là, un client écrit pour ces API ne bascule pas sur un serveur llama.cpp sans adaptation, alors que c'est déjà le cas pour la génération de texte.
Le point d'entrée s'ajoute à un serveur qui porte déjà le texte, la vision et les embeddings. Une machine locale peut donc, avec un modèle vocal de 1,7 milliard de paramètrespoids du modèleNombre de valeurs apprises par un modèle. À quantification égale, plus de paramètres veut dire plus de mémoire occupée, et en général de meilleures réponses.Fiche du lexique et un fichier de référence de quelques secondes, produire de la parole dans dix langues sans sortir du réseau local.
Source primaire llama.cpp, version b11781 et proposition 26603, server : add POST /tts endpoint for TTS models