Découper le texte en phrases coûte 8 % à Kokoro et rien à Piper
Mesures réelles — même texte, même session, deux granularités
Une chaîne de synthèse vocale découpe presque toujours le texte en phrases avant de le lire. J'ai mesuré ce que ce découpage coûte : sur le même script, passer de 12 morceaux à 22 fait tomber Kokoro-82M de ×0,95 à ×0,87, soit 0,51 s de coût fixe par appel. Piper, lui, ne perd rien.
Une chaîne de synthèse vocale ne lit presque jamais un texte d'un bloc : elle le découpe en phrases, pour la prosodie et pour caler les sous-titres. La mienne le fait. J'ai mesuré ce que ce découpage coûte, et la réponse dépend entièrement du moteur.
Sur le même script, passer de 12 morceaux à 22 fait tomber Kokoro-82M de ×0,95 à ×0,87 le temps réel — 8 % de débit en moins. Piper TTS, sur le même test, ne perd rien.
Pourquoi je suis allé regarder
Parce que mon propre site affichait trois chiffres différents pour la même voix sur le même texte : ×0,75, ×0,79 à ×0,82, et ×0,95. Une mesure au banc, une mesure dans la chaîne complète, et une vieille passe unique. J'ai cherché ce qui les séparait, en supposant d'abord que la machine était occupée. C'était faux : c'était le découpage.
Le protocole
Un seul texte : le script de mon épisode 0, 950 caractères en 12 plans. Il est archivé et importé depuis son fichier, jamais recopié — sans ça la comparaison ne vaudrait rien.
Deux granularités :
- 12 plans entiers, 79 caractères en moyenne. C'est ce que fait un banc d'essai.
- 22 phrases, 43 caractères en moyenne, découpées exactement comme ma chaîne le fait (
re.split(r"(?<=[.!?…])\s+", texte), une synthèse par phrase). C'est ce que fait la production.
Les quatre séries tournent dans la même session, en série, sur deux cœurs ARM Neoverse-N1 sans GPU : le but est que rien d'autre qu'un changement de granularité ne puisse expliquer l'écart.
Les mesures
| Moteur | 12 plans entiers | 22 phrases |
|---|---|---|
Kokoro-82M ff_siwis | ×0,93 à ×0,95 (3 passes) | ×0,86 à ×0,87 (3 passes) |
Piper fr_FR-siwis-medium | ×8,38 à ×8,59 (4 passes) | ×8,50 à ×8,66 (4 passes) |
Pour Kokoro, en temps de calcul : 54,90 s contre 60,03 s (médianes) pour un audio identique à 0,04 s près (51,97 contre 52,01 s). Soit +5,13 s pour 10 appels supplémentaires, ou 0,51 s de coût fixe par appel.
Pour Piper : 6,69 s contre 6,63 s. Les deux fourchettes se chevauchent largement. Le coût par appel est indiscernable du bruit de mesure.
Ce que ça veut dire
Le coût de Kokoro est par appel, pas par caractère. C'est pour ça qu'il se voit sur un découpage fin et pas sur la longueur du texte : dans une autre série, le même moteur était légèrement plus rapide sur 950 caractères que sur 505, parce que les morceaux y étaient plus longs.
Et donc un banc d'essai qui lit le texte d'un bloc surestime le moteur de 8 % par rapport à ce que la production obtiendra, pour Kokoro. Si vous comparez deux moteurs au banc pour en déployer un dans une chaîne qui découpe, vous ne mesurez pas la bonne chose.
Deux notes de lecture honnêtes. L'audio produit n'est pas le même entre les deux moteurs — environ 52 s pour Kokoro contre 57 s pour Piper sur le même texte, ils ne parlent pas à la même vitesse ; c'est le ratio qui se compare, pas les secondes. Et la différence d'audio de 0,04 s entre les deux granularités de Kokoro vient du découpage lui-même, qui retire les espaces entre phrases (950 caractères deviennent 940).
Ce que cette mesure ne dit pas
Une machine, deux cœurs ARM sans accélérateur, un texte, une voix par moteur. Rien sur x86, rien sur GPU, rien sur d'autres langues.
Ce que j'avais écrit ici ce matin, et qui était faux. J'annonçais que le découpage n'expliquait que la moitié de l'écart, le reste venant « de ce que la chaîne fait autour de la synthèse ». C'était une supposition de plus. Mesuré le soir même, en instrumentant la vraie boucle de production (importée, cache froid, trois passes) : elle rend ×0,85 à ×0,87, exactement le banc. Le moteur y prend 59,96 à 61,17 s ; l'écriture du cache 0,01 s, la mise en page des sous-titres 0,00 s, les opérations sur les tableaux 0,00 s. La chaîne ne coûte rien de plus que le moteur, et le découpage explique donc tout ce qui est explicable.
Reste que mes relevés du 14/09 dans cette chaîne donnaient ×0,79 à ×0,82. Ils ne se reproduisent pas. Ce qui occupait la machine ce jour-là, je ne le sais pas, et je préfère l'écrire que de fabriquer une cause.
Les données brutes des quatre séries — chaque passe, chaque temps, le processeur relevé — sont sur la page des données brutes, sous licence CC-BY 4.0. Si votre machine dit autre chose, c'est votre chiffre qui compte.