AuK vs AuK-Flash : 32 étapes d'échantillonnage ou 4, et pourquoi l'étudiant gagne parfois.

Les deux checkpoints pèsent exactement 6,122 Go. Les deux sont publiés sous licence MIT. Les deux sont pilotés par le même encodeur d'instructions de 3 milliards de paramètres, téléchargé séparément, et par la même VAE de 637 Mo. AuK et AuK-Flash ne diffèrent en presque rien de ce que vous provisionnez — et en une chose que vous ressentez à chaque appel : combien de fois le sampler s'exécute. AuK, le modèle de fondation open-weight de génération et d'édition de la parole à 1,5 milliard de paramètres, que l'équipe Hunyuan de Tencent et les co-auteurs académiques de Shanghai Jiao Tong et de NTU ont mis en ligne sur Hugging Face le 9 septembre, effectue 32 évaluations de fonction avec un guidage sans classifieur à 2,0. AuK-Flash, le modèle élève distillé, n'en effectue que quatre, avec le guidage entièrement désactivé, pour une accélération annoncée de 4,5× en temps d'horloge. L'interprétation évidente est que Flash est le siège économique que vous choisissez lorsque la latence prime sur la qualité. Cette interprétation est fausse, et ce sont les propres tableaux d'évaluation du fournisseur qui la contredisent : sur les lignes de comparaison directe du rapport technique, Flash obtient le meilleur score sur la métrique edit-ratio de MMAE-Speech, sur la colonne paralinguistique de SpeechEditBench, sur le suivi d'instructions en anglais, sur la similarité du locuteur pour l'édition acoustique, et sur les quatre lignes de qualité perceptuelle de l'amélioration. Ce n'est pas une dégradation. C'est un compromis différent, et de quel côté vous vous rangez dépend de laquelle des deux tâches vous exécutez réellement.

Qu'est-ce qui diffère réellement entre eux ?

Une fois le marketing écarté, le choix se réduit à un fichier de configuration. Le runtime d'AuK est un Transformer hybride à flux rectifié — des blocs MMDiT à double flux alimentant des blocs DiT unifiés à flux unique — exécutant un solveur d'Euler en bfloat16 à 24 kHz et des latents de dimension 64 à 50 Hz. AuK-Flash exécute la même architecture avec un sampler distillé greffé, produit par initialisation de cohérence et un DMD découplé routé par tâche. Tous les autres composants sont partagés.

• Étapes d'échantillonnage — AuK : 32 évaluations de fonction, configurable. AuK-Flash : 4, fixe.

• Guidage sans classificateur — AuK: échelle 2.0, réglable. AuK-Flash: aucune (CFG=0).

• Taille du checkpoint — AuK : auk_base.safetensors de 6.122 Go. AuK-Flash : auk_flash.safetensors de 6.122 Go. Identiques au mégaoctet près.

• Runtime partagé — un VAE de 637 Mo ainsi que l'encodeur Qwen/Qwen2.5-Omni-3B, téléchargés séparément et utilisés par les deux.

• Vitesse revendiquée — AuK-Flash : 4,5× plus rapide en temps d'horloge que l'enseignant 32-NFE, à matériel, durée et taille de lot identiques.

• Licence — MIT pour les deux, ce qui, pour une fois, signifie ce que ça dit.

Cette taille de checkpoint identique est le détail qui recadre toute la comparaison. Les variantes distillées achètent généralement leur vitesse en étant plus petites. AuK-Flash n’est pas plus petit. Vous n’économisez pas d’espace disque, vous n’économisez pas de temps de transfert, et — puisque l’encodeur et le VAE sont partagés et que le DiT a la même largeur — vous n’économisez pas significativement de VRAM en choisissant le student. La seule ressource que Flash vous rend, c’est du temps. Il vaut quand même la peine de mentionner un piège budgétaire : le « 1.5B » dans le nom du modèle décrit le backbone de diffusion, et le fichier sur disque pèse 6,122 Go. Prévoyez de la place pour le fichier.

Là où AuK-Flash bat réellement le modèle complet.

C'est là que l'instinct « distillé = pire » se trompe, et cela se vérifie sur plusieurs familles de tâches sans rapport entre elles dans les tableaux du rapport. Commençons par la perception. Sur l'ensemble d'amélioration DNS Challenge, Flash obtient un UTMOS de 4,05 contre 3,86 pour AuK ; sur CHiME-4, 3,91 contre 3,72 ; sur Libri2Mix, 4,03 contre 3,87 ; sur VCTKSR, 4,05 contre 3,93. Flash remporte également la colonne des erreurs de reconnaissance sur deux de ces quatre ensembles, avec un WER de 7,84 sur CHiME-4 contre 7,98 et un WER de 2,92 sur VCTKSR contre 3,06. La naturalité évaluée par des humains est le seul axe sur lequel l'élève est systématiquement en tête, et le rapport le dit explicitement : le modèle complet offre une meilleure précision linguistique et une meilleure fidélité d'édition, tandis que Flash « offre souvent une meilleure qualité perceptuelle ».

Les gains ne se limitent pas à l'amélioration. Sur la métrique edit-ratio de MMAE-Speech — à savoir si une modification atteint l'amplitude prévue — Flash obtient 13,85 contre 12,44 pour AuK. Sur la colonne paralinguistique de SpeechEditBench, c'est 39,25 contre 38,50. Sur la tâche anglais description-à-parole d'InstructTTSEval, c'est 82,40 contre 81,60, ce qui fait égalité avec la meilleure référence sur cette ligne. En édition acoustique dans la suite Ming-Freeform, il conserve la meilleure similarité de locuteur de la famille, 0,79 en chinois et 0,75 en anglais, contre 0,78 et 0,74 pour le modèle de base. La préservation de l'identité du locuteur, en d'autres termes, est l'une des choses que quatre étapes vous procurent — le résumé du rapport lui-même indique que le modèle complet donne une erreur de reconnaissance moyenne plus faible, tandis que Flash préserve mieux l'identité du locuteur. Si vous faites de la conversion vocale, du doublage ou de l'amélioration là où le timbre importe plus que l'erreur sur les mots, le modèle élève est le meilleur choix.

Où les 32 marches gagnent toujours leur place

Les avantages du modèle de base se concentrent exactement là où l'on s'attendrait à ce qu'un modèle de diffusion avec un budget d'échantillonnage plus important excelle : tout ce qui nécessite une sortie linguistiquement correcte.

Sur Seed-TTS-Eval, le WER moyen d'AuK est de 2,65 contre 2,85 pour Flash, avec une similarité du locuteur de 0,795 contre 0,790. La dispersion au sein de cette moyenne est plus informative que la moyenne elle-même. Les deux sont effectivement à égalité sur le test en anglais — 1,02 et 1,03 — et se séparent sur le chinois, 1,02 contre 1,10, et encore sur le sous-ensemble chinois difficile, 5,91 contre 6,43. C'est sur le chinois que les étapes supplémentaires portent leurs fruits.

Le même schéma se retrouve dans le suivi d'instructions. Sur la tâche de synthèse vocale à partir de descriptions chinoises d'InstructTTSEval, l'écart est large : 83.37 pour AuK contre 78.80 pour Flash, et le rapport note que le modèle de base mène sur les trois métriques chinoises de cette suite, tandis que le « principal avantage » de Flash est « son meilleur résultat DSD en anglais ». C'est la langue, et non l'architecture, qui est la ligne de partage.

La fidélité d'édition est ce qui les sépare le plus. La précision d'édition de contenu de SpeechEditBench est de 91,83 pour AuK contre 87,50 pour Flash — l'écart le plus important de la comparaison. L'édition acoustique est presque aussi déséquilibrée : 37,07 contre 30,26. Dans la suite Ming-Freeform, AuK affiche un WER inférieur presque partout là où cela compte : 3,09 contre 3,34 sur l'édition complète en chinois, et un écart bien plus large de 3,96 contre 4,84 sur l'édition complète en anglais. Si votre produit réécrit les mots d'un enregistrement — modifications de paroles, remplacement de contenu, insertion et suppression — c'est le modèle à 32 étapes qui garde la transcription honnête, et la différence de 8× sur le nombre d'étapes vaut la peine d'être payée.

Les deux modèles sont également, selon les chiffres mêmes du rapport, {{1}}toujours faibles en édition émotionnelle : la précision émotionnelle de SpeechEditBench est de 9.94 pour AuK et de 6.29 pour Flash{{/1}}. {{2}}Ce n'est pas un artefact de distillation{{/2}}. {{3}}C'est une famille de tâches que personne n'a résolue, et choisir le modèle élève ne vous rendra pas pire dans ce domaine que vous ne l'êtes déjà{{/3}}.

Le 4,5× est un nombre d'échantillonnage, pas un nombre de bout en bout.

Voici l'arithmétique que cache l'accélération annoncée, et c'est la chose la plus utile à comprendre avant de confier une architecture à Flash.

AuK-Flash exécute 4 étapes d'échantillonnage là où AuK en exécute 32. C'est 8× moins d'étapes. Le fournisseur indique un temps d'horloge 4,5× plus rapide. La différence entre ces deux chiffres correspond à tout ce qui entoure la boucle d'échantillonnage, et elle est dominée par l'encodeur : un modèle multimodal Qwen2.5-Omni-3B que les deux points de contrôle chargent et que les deux doivent exécuter pour chaque requête. Cet encodeur fait environ deux fois la taille du backbone de diffusion, et son coût est fixe. Flash ne peut pas l'accélérer, car Flash n'en fait pas partie.

Voici donc la version honnête de l’affirmation : 4,5×, c’est ce que vous obtenez sur la partie diffusion à conditions égales, et votre gain de bout en bout sera la part de votre temps réel qu’occupe effectivement la boucle d’échantillonnage. Si vous exécutez une génération de longue durée, où 32 étapes sur de nombreuses images latentes dominent, vous obtiendrez un résultat proche du chiffre publié. Si votre charge de travail se compose de courts extraits avec un prétraitement intensif des instructions, ou si vous traitez de petites requêtes par lots, une plus grande fraction de chaque appel se concentre dans l’encodeur partagé et votre accélération réelle sera nettement inférieure à 4,5×. Mesurez votre propre combinaison de charges avant de faire reposer un budget de latence sur ce chiffre. Personne n’a encore publié ce résultat de bout en bout — y compris le fournisseur, qui ne communique aucun chiffre de latence absolu ni aucune exigence en VRAM.

Ce que coûte la distillation, selon les propres mots des auteurs.

Le rapport technique est d'une franchise inhabituelle sur les points de rupture de l'étudiant, et ces modes de défaillance sont plus utiles à un déployeur que le tableau de référence.

Les cibles de guidage de l'enseignant se sont révélées être le problème. L'utilisation de cibles CFG dans la branche de cohérence « peut exposer l'élève à quelques pas à des prédictions sur-saturées », ce qui, selon les auteurs, provoque des dépassements et un écrêtage audible. Par ailleurs, un programme DMD découplé uniforme « dégrade la séparation multi-locuteurs et vocale », certaines sorties de l'élève régressant vers le mélange non traité — la distillation efface la séparation que le modèle était censé effectuer. Le DMD routé par tâche est le correctif décrit, et c'est pourquoi le rapport prend soin de limiter cette faiblesse particulière à la variante uniforme. Si la séparation vocale est un élément central de votre pipeline, c'est le paragraphe à mettre à l'épreuve avant de lui faire confiance.

Deux autres contraintes sont opérationnelles plutôt que statistiques. Le Prompt Enhancer du pipeline fait correspondre les formulations familières concernant la vitesse, le volume et la hauteur à un ensemble fixe de valeurs prises en charge, et rejette tout ce qu'il ne peut pas mapper avant l'exécution de l'inférence acoustique — ainsi, les demandes non prises en charge échouent tôt plutôt que de se dégrader gracieusement. Et le dépôt n'accepte que Qwen/Qwen2.5-Omni-3B comme chemin d'encodeur ; le README indique que Qwen3-Omni n'est actuellement pas pris en charge, donc un encodeur plus récent n'est pas une mise à niveau de remplacement direct. L'intégration ComfyUI impose une limite de 30 secondes sur les séquences source-plus-cible.

Exécuter les deux est la configuration prévue.

L'exemple multi-GPU du dépôt lui-même place AuK sur un appareil et AuK-Flash sur un autre — cuda:0 et cuda:1 — ce qui est un signal clair que Tencent s'attend à ce qu'ils coexistent plutôt qu'ils ne se concurrencent. C'est aussi la bonne réponse pour la plupart des piles vocales de production, car les deux modèles excellent dans des domaines disjoints. Acheminez les requêtes d'édition intensive et les requêtes en chinois vers AuK ; acheminez l'amélioration, la séparation, le suivi d'instructions en anglais et tout ce qui est interactif vers AuK-Flash. Les deux chargent le même encodeur et la même VAE, si bien que vous ne payez qu'une seule fois pour ce runtime partagé et basculez entre les checkpoints qui reposent dessus.

C'est une décision de routage au niveau de la couche modèle, et elle a la même forme que celle qu'OrcaRouter applique au niveau de la couche API pour les modèles hébergés. Là où les deux se rencontrent aujourd'hui se trouve la jonction dans le pipeline propre d'AuK : le Prompt Enhancer nécessite un endpoint de chat compatible OpenAI pour transformer une instruction approximative en vocabulaire pris en charge par le modèle, et la solution de repli ASR optionnelle a besoin d'un chemin de transcription. Pointez l'un ou l'autre vers un endpoint de chat compatible OpenAI et vous obtenez une clé pour plus de 200 modèles, le prix catalogue du fournisseur répercuté avec 0 % de marge, et un basculement automatique si un backend tombe — ce qui importe précisément parce qu'il s'agit d'une version sortie il y a deux jours, sans API hébergée ni reproduction indépendante, et vous ne voulez pas qu'une dépendance non éprouvée repose sur un endpoint codé en dur.

Soyez toutefois clair sur ce qui n'est pas disponible. Ni AuK ni AuK-Flash n'est servi par un fournisseur d'inférence hébergée — les fiches Hugging Face le disent directement — et aucun des deux n'est routable via OrcaRouter aujourd'hui. C'est une décision d'auto-hébergement de bout en bout.

Ce qui reste encore inconnu

Quasiment tout dans cette version provient de rapports du fournisseur. L’accélération de 4,5×, les chiffres de WER, les colonnes de SpeechEditBench et les lignes d’UTMOS proviennent tous du rapport technique de l’équipe AuK, arXiv 2609.08936, soumis le 8 septembre — il n’y a aucune reproduction indépendante, aucune entrée dans un classement tiers, ni aucun résultat de banc d’essai neutre. Le signal d’adoption est tout aussi mince : au 10 septembre, les deux dépôts Hugging Face affichent 30 téléchargements au cours du dernier mois et environ deux douzaines de likes chacun, tandis que le dépôt GitHub affiche 217 étoiles, 12 forks et trois contributeurs. C’est une publication de recherche, pas un engouement généralisé.

img src="4.png" alt="Capture d'écran du README du dépôt GitHub Tencent-Hunyuan AuK montrant l'avis de mise en open source du 9 septembre 2026 et le tableau des variantes AuK et AuK-Flash"> p>La sortie elle-même a été discrète d'une manière qui mérite d'être énoncée clairement, car il est facile de surinterpréter. Il n'y a eu ni annonce Hunyuan, ni article de blog, ni page de tarification, ni événement de lancement. La seule déclaration datée du fournisseur est une ligne unique dans le README du dépôt — [2026/09/09] Nous open-sourçons AuK. Les métadonnées du dépôt Hugging Face montrent que les Spaces ont été créés plus tôt, à la mi-août, et que les poids ont été modifiés pour la dernière fois les 9 et 10 septembre, donc l'empaquetage a eu lieu avant l'annonce. Ce qu'on peut savoir du dépôt : des poids sous licence MIT pour les deux variantes, un rapport technique, des instructions de téléchargement fonctionnelles pour Hugging Face et ModelScope, et une liste de tâches documentée. Ce qui n'est pas confirmé : si certains des chiffres rapportés survivent à un harnais de test indépendant, si un point de terminaison hébergé apparaîtra, et si le checkpoint Flash reste le défaut recommandé une fois que d'autres personnes l'auront exécuté.

Lequel choisir

Si vous créez du contenu, éditez des paroles ou prenez en charge de la parole en langue chinoise sous quelque forme que ce soit, optez pour AuK et acceptez les 32 étapes. Ses avantages y sont considérables, cohérents entre deux suites d'édition indépendantes, et correspondent exactement au type de défaut de correction — un mot erroné dans la transcription — que les utilisateurs remarquent immédiatement.

Si vous construisez de l’amélioration, de la séparation, de la conversion vocale, ou toute autre chose avec un humain qui attend le résultat, prenez AuK-Flash. Il est plus rapide d’une large marge sur la boucle d’échantillonnage, il remporte sans conteste les lignes de qualité perceptuelle, et il préserve mieux l’identité du locuteur que le modèle dont il a été distillé. L’écart de qualité qui existe se concentre dans des tâches que vous ne lancez probablement pas.

Si vous construisez un produit vocal qui couvre les deux, exécutez les deux. Même disque, même encodeur, même licence, une seule différence de configuration — et le modèle de déploiement que le dépôt démontre déjà. La seule chose qui vaille la peine d'attendre est votre propre mesure de latence de bout en bout : le facteur 4,5× est réel, mais il appartient à l'échantillonneur, et seule votre combinaison de charges de travail vous indique quelle part en atteint vos utilisateurs.