Ce qui le distingue
Il vient de l'équipe k2-fsa (l'écosystème Kaldi / icefall, historiquement côté reconnaissance vocale). Sa promesse n'est pas la performance sur une langue mais la couverture : 646 langues annoncées. Le français n'y est pas un ajout symbolique — la table officielle des langues lui attribue 23 675 heures d'entraînement.
Choix techniques
ce que ses auteurs ont décidé, et ce que ça impliqueUn petit modèle de langue, un gros tokenizer audio
Mesuré dans les poids épinglés : 612,6 millions de paramètres pour le modèle principal (bâti sur Qwen3-0.6B d'après la carte), plus 201,4 millions pour le tokenizer audio (HiggsAudio v2, 24 kHz, 1 024 entrées de codebook) livré dans le même dépôt — donc pas de téléchargement implicite surprise, contrairement à d'autres.
Architecture « modèle de diffusion textuelle »
La documentation revendique une architecture de type « diffusion language model », choisie pour la vitesse autant que pour la qualité. C'est cohérent avec ce qu'on mesure : facteur temps réel de 0,26, soit le modèle clonant le plus rapide du benchmark encore utilisable en production (seul XTTS-v2 fait marginalement mieux à 0,24, mais sa licence l'exclut d'un usage commercial).
La langue se passe en paramètre
language="French" est transmis explicitement à chaque génération. La documentation note que préciser la langue améliore légèrement le résultat par rapport au mode « agnostique ».
Pas de graine propre
La fonction de génération n'expose pas de graine aléatoire : la variation entre nos répétitions provient de la graine globale PyTorch posée par le socle commun.
Langues couvertes
tabledocs/languages.md du dépôt officiel (646 lignes)646 langues — le français est la 5ᵉ mieux dotée
Trop nombreuses pour être listées. Classement par volume d'entraînement : anglais (206 061 h), chinois (111 343 h), japonais (36 914 h), espagnol (27 560 h), FRANÇAIS (23 675 h), allemand (21 927 h), russe (20 338 h), portugais (16 855 h), cantonais (13 302 h), thaï (10 500 h)… La liste complète des 646 langues, avec le volume de chacune, est publiée par le projet (lien ci-dessous).
Ce qu'on peut régler
paramètres exposés par ce modèleRelevé dans la signature du code réellement installé pour nos runs (et dans la documentation officielle quand elle précise les valeurs recommandées). Chaque modèle expose des leviers différents : c'est souvent là que se joue la différence entre un résultat correct et un bon résultat.
| paramètre | défaut | ce que ça change |
|---|---|---|
| language | None | Langue cible ("French" chez nous). Facultatif — le modèle sait fonctionner en mode agnostique — mais la documentation indique que préciser la langue donne un résultat légèrement meilleur. |
| num_step | 32 | Nombre d'étapes de « démasquage » successives. La documentation suggère 16 pour aller deux fois plus vite au prix de la qualité. |
| guidance_scale | 2.0 | Force du guidage (classifier-free guidance). |
| duration / speed | None / 1.0 | Durée cible imposée en secondes, ou simple facteur de vitesse. duration prend le pas sur speed quand les deux sont donnés. |
| instruct | — | Mode « Voice Design » : décrire la voix en mots (genre, âge, hauteur, accent, chuchotement) au lieu de fournir un extrait à cloner. |
| normalize_text | False | Verbalisation des nombres avant synthèse. En français elle passerait par num2words (WeTextProcessing ne couvrant que le chinois et l'anglais) ; laissée désactivée dans nos runs. |
| denoise / preprocess_prompt / postprocess_output | True | Chaîne de nettoyage : signal plus propre, silences retirés de l'extrait de référence, silences retirés de l'audio produit. |
symboles inline ([laughter], [sigh]…) | — | Sons non verbaux et corrections de prononciation s'écrivent directement dans le texte. |
Ce qu'on mesure sur ce modèle
nos runs, pas les chiffres de l'éditeurÀ l'oreilletest d'écoute en aveugle
Détail complet : table de toutes les métriques · résultats du test d'écoute.
Réglages de génération utilisés
relevés dans les métadonnées de nos runsCes valeurs sont celles réellement passées au modèle pour produire les audios mesurés — pas des réglages recommandés recopiés d'une documentation. Elles sont écrites par l'adaptateur dans le meta.json de chaque run.
À savoir avant de l'utiliser
pièges, limites, nuances de licence- La model card Hugging Face n'affiche AUCUNE balise de licence ; la licence Apache-2.0 vient du fichier LICENSE du dépôt GitHub officiel (code et poids publiés ensemble). Une note antérieure de notre registre affirmait des « poids CC-BY-NC » en confondant avec un finetune tiers : erreur corrigée le 2026-09-12, ledit finetune étant lui-même en Apache-2.0.
- Nos extraits de référence durent environ 24 secondes ; le modèle émet un avertissement au-delà de 20 secondes et recommande 3 à 10 secondes. Un raccourcissement des références pourrait donc encore améliorer ses résultats de clonage.
- La normalisation de texte est laissée désactivée (valeur par défaut du modèle) : les nombres écrits en chiffres ne sont pas verbalisés en amont.
Sources & vérification
vérifié le 2026-09-12Les comptes de paramètres cités plus haut sont lus directement dans les fichiers de poids de la révision épinglée ci-dessous (en-têtes safetensors / torch), pas repris d'une annonce. Les caractéristiques annoncées proviennent de la model card officielle, liée ici. Les chiffres de performance viennent de nos propres runs.
Note de licence : corrigé le 2026-09-12 : le poids k2-fsa/OmniVoice (celui utilisé par ce benchmark) n'affiche pas de tag license dans sa carte HF, mais le dépôt GitHub k2-fsa/OmniVoice (code + poids, même release) a un LICENSE Apache-2.0 à la racine, et le finetune émotion cité par une note antérieure (ModelsLab/omnivoice-singing) est LUI-MÊME apache-2.0 sur HF — l'ancienne note 'poids CC-BY-NC / conditionnel' était erronée.