Hy-SimulMT vs NLLB-200 : un interprète en continu n'est pas un traducteur en 200 langues

Les deux noms de benchmarks ne diffèrent que d’une lettre, et cette lettre, c’est tout l’article. Hy-SimulMT, l’interprète chinois↔anglais en temps réel de Tencent Hunyuan, publié le 26 octobre 2026, affiche un score de 90,3 sur un test appelé FLEURS. NLLB-200, le traducteur de texte en 200 langues de Meta AI datant de juillet 2022, est évalué sur un test appelé FLORES-200. Ils sont liés — FLEURS est construit à partir de phrases FLORES lues à voix haute — mais ce ne sont pas les mêmes tests, ils ne sont pas évalués de la même manière, et personne n’a jamais confronté ces deux modèles l’un à l’autre. Chercher cette confrontation renvoie des articles sur le lancement de l’un et la documentation de l’autre, sans rien entre les deux. Cette absence est le point de départ honnête : ce ne sont pas des concurrents, et la question utile est de savoir à quelle tâche chacun est réellement destiné.

Une lettre, deux références

FLORES-200 est un benchmark textuel. Meta l'a construit dans le cadre du projet No Language Left Behind : des phrases traduites par des professionnels dans 200 langues, utilisées pour mesurer la capacité d'un système de traduction à faire passer un texte écrit d'une langue à une autre. L'indicateur principal est spBLEU, une variante de BLEU calculée sur un tokeniseur fixe et équilibré par langue afin que les scores soient comparables entre des langues qui utilisent des écritures différentes. L'article NLLB rapporte également chrF++ et une évaluation humaine appelée XSTS.

FLEURS est le pendant oral. Il reprend des ensembles de phrases FLORES, les fait lire à voix haute par des locuteurs natifs et évalue la traduction vocale — audio en entrée, texte en sortie. Il couvre 102 langues au lieu de 200. Lorsque Tencent annonce 90,3 sur FLEURS pour Hy-SimulMT, ce chiffre englobe l’ensemble de la chaîne : entendre l’audio, reconnaître les mots et les traduire. Lorsque Meta annonce un spBLEU sur FLORES-200 pour NLLB-200, le texte est déjà correct et tokenisé, et la seule chose mesurée est l’étape de traduction.

Mettez ces deux nombres côte à côte et vous n’avez pas comparé deux modèles. Vous avez comparé un système vocal de bout en bout à un traducteur de texte sur des données différentes, avec des métriques différentes, dans des langues différentes. C’est l’erreur que suggère la similarité d’une seule lettre, et il vaut la peine de la nommer avant toute autre comparaison dans cet article.

Ce qu’est réellement NLLB-200, quatre ans plus tard

NLLB-200 est sorti en juillet 2022 et n’a pas été révisé depuis. Les checkpoints que vous téléchargez aujourd’hui sont ceux de 2022. Ce n’est pas une critique — c’est une constatation sur la nature de cet artefact : une publication de recherche qui a défini un benchmark et un jeu de données, puis s’est arrêtée.

La famille couvre cinq tailles, et c’est tout l’intérêt de cet éventail :

• NLLB-200-distilled-600M — le plus petit checkpoint utilisable, suffisamment petit pour un GPU de classe ordinateur portable.

• NLLB-200-distilled-1.3B et NLLB-200-1.3B — la paire de milieu de gamme, l’une distillée pour la vitesse et l’autre entraînée directement.

• NLLB-200-3.3B — la bête de somme dense, la taille que la plupart des gens déploient réellement.

• NLLB-200-54.5B — le modèle clairsemé phare : 128 experts avec un gating top-2, une couche de mélange d'experts dans chaque quatrième bloc Transformer, et un coût de calcul par token à peu près comparable à celui du modèle dense de 3,3 Md. C'est le plus grand modèle de traduction ouvert de sa génération, et c'est toujours la raison pour laquelle cette famille est citée.

L’ensemble d’entraînement comptait environ 18 milliards de paires de phrases parallèles, et la principale affirmation de l’article était une amélioration de 44 % du BLEU par rapport à l’état de l’art précédent, mesurée sur plus de 40 000 directions de traduction. L’architecture est un transformeur encodeur-décodeur conçu pour la traduction d’une seule phrase. Il n’y a pas de mode flux, pas d’entrée audio et aucune notion de sortie partielle — il prend une phrase et renvoie une phrase.

La licence est CC-BY-NC 4.0, et la fiche du modèle est sans détour sur l'intention : non publiée pour un déploiement en production, non destinée à la traduction spécifique à un domaine, de longueur documentaire, à entrées longues ou certifiée. Le code autour des poids est sous MIT, mais les poids ne le sont pas, ce qui est la confusion qui a accompagné cette publication pendant quatre ans.

Ce qu’est réellement Hy-SimulMT, depuis cette semaine

Hy-SimulMT est un artefact de forme opposée dans presque toutes les dimensions. C’est un modèle vocal : l’audio arrive en flux à 16 kHz par fenêtres de 30 secondes, et le modèle produit du texte traduit pendant que le locuteur parle encore. L’architecture est un mélange d’experts clairsemé de 30,4 milliards de paramètres, avec environ 3 milliards de paramètres actifs par token, articulé autour d’un encodeur audio de 24 couches. La paire de langues documentée est le chinois et l’anglais, dans les deux sens.

Son affirmation centrale porte sur la latence, non sur la couverture. Tencent rapporte un StreamLAAL d'environ trois secondes sur de l'audio RealSI de longue durée, en le présentant comme le plus faible parmi les systèmes qu'il a comparés. Il s'agit là d'un type d'affirmation différent de tout ce que contient l'article NLLB, qui ne comporte aucune mesure de latence, faute de quoi que ce soit à mesurer : un traducteur de texte par lots n'accuse aucun retard sur un locuteur.

La version est sous Apache-2.0 et sans restriction d’accès, avec six checkpoints couvrant deux formats de sortie — traduction seule et texte source plus traduction — chacun en pleine précision, FP8 et GGUF. La version en pleine précision fait environ 61 Go, et la version GGUF Q4_K_M, 19,7 Go. La sortie vocale et le clonage de voix nécessitent un service TTS distinct ; le modèle lui-même produit du texte.

Et comme NLLB-200, il n’a pas d’API hébergée ni de prix publié. La surface grand public de Tencent est l’application Hy Translate, qui propose un niveau gratuit. Tout le reste implique d’exécuter les poids.

Pourquoi les scores ne peuvent pas partager une colonne

La tentation est de comparer les quatre scores de Hy-SimulMT au chiffre NLLB-200 le plus proche sous la main. Résistez-y, et pas seulement à cause de la distinction FLEURS/FLORES. On pose aux deux modèles des questions différentes.

• Modalité d'entrée — Hy-SimulMT reçoit de l'audio, son score inclut donc les erreurs de reconnaissance. NLLB-200 reçoit du texte dont les erreurs de reconnaissance ont déjà été retirées. Un modèle vocal et un modèle textuel évalués sur les mêmes phrases ne sont pas sur la même ligne de départ.

• Métrique — Hy-SimulMT rapporte des scores de la famille BLEU sur des ensembles de traduction de la parole ; NLLB-200 rapporte spBLEU, chrF++ et XSTS sur FLORES-200. Le tokeniseur de spBLEU existe spécifiquement pour rendre la comparaison entre langues équitable, ce qui signifie qu'il n'est pas interchangeable avec un simple nombre BLEU, même lorsque les deux sont appelés BLEU.

• Unité de travail — NLLB-200 est évalué phrase par phrase sur du texte aligné. Hy-SimulMT est évalué sur de l'audio en flux, où l'échec intéressant n'est pas un mot mal traduit, mais une phrase qui arrive trop tard pour être utile.

• Nombre de directions — Les plus de 40 000 directions de NLLB-200 sont moyennées dans son score principal ; les quatre benchmarks de Hy-SimulMT ne couvrent que le chinois↔anglais. Une moyenne sur la longue traîne et un score sur une seule paire à hautes ressources décrivent des formes de réussite différentes.

Dans son propre tableau, Hy-SimulMT n’est pas non plus systématiquement en tête. Il obtient 75,5 sur CoVoST2, contre 82,1 pour Qwen3.8-LiveTranslate, et il est devancé par Gemini3.5-LiveTranslate sur FLEURS (90,3 contre 92,4) et ACL6060 (81,2 contre 82,6). Sa victoire la plus nette est RealSI-Sentence, avec 84,7. Tous ces chiffres proviennent d’évaluations réalisées par le fournisseur, sur le banc d’évaluation choisi par Tencent, et n’ont pas été reproduits indépendamment. La fiche modèle ne précise pas non plus laquelle de ses deux variantes de sortie a produit ces résultats.

La latence se mesure dans une unité que NLLB ne possède pas

C’est l’élément qui décide des déploiements, et il n’a rien à voir avec les scores des benchmarks.

Un interprète simultané doit faire un compromis qu'un traducteur par lots n'a jamais à faire : attendre plus longtemps et mieux traduire, ou parler plus tôt au risque de se tromper. StreamLAAL mesure ce compromis — en gros, de combien la sortie retarde sur l'entrée en moyenne. Les trois secondes de Hy-SimulMT sont une affirmation concernant ce compromis. Ce n'est explicitement pas la même chose que le délai avant la première sortie vocale, et Tencent le précise sur la fiche du modèle. Dès que l'on ajoute un service TTS externe, l'expérience de l'auditeur inclut aussi la latence de ce service, ce que le chiffre de trois secondes ne fait pas.

NLLB-200 n’a pas d’équivalent chiffré, car il ne dispose d’aucun mode de streaming. On peut en greffer un : découper l’audio en segments, lancer la reconnaissance vocale, fournir des fragments de phrases à NLLB et émettre les traductions au fur et à mesure qu’elles sont prêtes. Cette architecture fonctionne, et des équipes l’ont mise en œuvre. Mais le découpage détruit le contexte sur lequel repose un traducteur au niveau phrase, et la qualité obtenue n’est pas celle mesurée sur FLORES-200 avec des phrases complètes et bien formées. L’écart entre « NLLB-200 obtient X sur FLORES » et « NLLB-200, dans un pipeline live découpé, donne un rendu Y » est précisément là où se concentre en réalité l’essentiel de l’effort d’ingénierie.

C'est la véritable asymétrie. Hy-SimulMT a été conçu pour le cas du streaming et le paie par sa couverture linguistique et une empreinte de classe 30B. NLLB-200 a été conçu pour la largeur de couverture et le paie par une interface uniquement par lots. Ni l'un ni l'autre n'est en retard. Ils sont optimisés pour des contraintes différentes.

Couverture en fonction de la profondeur

L’avantage durable de NLLB-200, c’est la longue traîne. Deux cents langues, y compris des langues à faibles ressources que la plupart des modèles de 2026 ne traitent pas du tout, au sein d’une famille qui s’échelonne d’un checkpoint de 600M à un mélange d’experts de 54,5B. Si votre problème est un document dans une langue comptant quelques millions de locuteurs et qu’aucune API commerciale ne couvre, NLLB-200 reste l’une des rares options ouvertes, et le checkpoint dense de 3,3B tourne sur un seul GPU modeste.

Hy-SimulMT ne peut pas du tout faire ce travail. Il documente le chinois et l’anglais. Ses métadonnées Hugging Face portent une étiquette de 36 langues, mais aucune liste des 34 autres n’est publiée, et chaque exemple du dépôt utilise en-zh ou zh-en. Planifier un déploiement multilingue sur la base de cette étiquette serait une erreur.

L’arithmétique matérielle joue en sens inverse. Le modèle dense 3,3B de NLLB-200 fait quelques gigaoctets en FP16 et tient confortablement sur une carte de 16 à 24 Go. Son modèle phare 54,5B fait environ 108 Go en FP16 — une affaire multi-GPU. Hy-SimulMT fait environ 61 Go en BF16 et nécessite un accélérateur de 80 Go pour être servi tel quel, ou 19,7 Go en Q4_K_M via un chemin GGUF dont la prise en charge par llama.cpp n’est pas encore intégrée en amont. Ainsi, NLLB-200 est moins cher en bas de gamme et comparable en haut ; le coût de Hy-SimulMT se concentre au milieu, et il permet d’obtenir le streaming.

Les licences pointent dans des directions opposées.

Ce n’est pas l’épine dorsale de la comparaison — c’est la modalité — mais c’est le moyen le plus rapide d’en disqualifier un pour un produit commercial.

Les poids de NLLB-200 sont sous CC-BY-NC 4.0. Non commercial. Le code environnant est sous MIT, d'où vient la confusion, mais ce sont les poids que vous serviriez, et la fiche de Meta indique clairement que les modèles ne sont pas publiés pour un déploiement en production. Un déploiement commercial nécessite soit un autre modèle, soit un accord de licence.

Hy-SimulMT est sous Apache-2.0, sans restriction, l'utilisation commerciale, la modification et la redistribution étant autorisées. Tencent fournit une boîte à outils d'entraînement avec le serveur d'inférence, si bien que l'entraînement continu fait partie des usages prévus. Si le choix entre les deux ne repose que sur la licence, le verdict est sans appel.

Là où ils doivent être dans la même pile

La raison pour laquelle cette comparaison continue d’être recherchée, c’est que les équipes rencontrent les deux problèmes dans le même produit. Une entreprise ayant des activités en chinois et en anglais a besoin d’un interprète en direct pour les réunions et d’un pipeline de traitement de texte pour le flux de documents en 200 langues qui arrive par e-mail, contrat et ticket d’assistance. Ce sont deux tâches différentes, et une architecture honnête utilise deux modèles différents.

NLLB-200, ou un successeur moderne, prend en charge le chemin texte hors ligne : traduction par lots, identification de la langue, tri de corpus, la longue traîne. Hy-SimulMT prend en charge le chemin parole en direct chinois↔anglais, où la latence domine et la couverture n’a pas d’importance puisqu’il n’y a que deux langues dans la salle. La frontière entre les deux est une décision de routage, et il vaut la peine de l’énoncer explicitement plutôt que de laisser une application l’inférer à partir du type de fichier.

Aucun des deux modèles ne figure au catalogue d'OrcaRouter, nous ne sommes donc une route vers ni l'un ni l'autre. Ce qu'un routeur apporte, c'est la couture autour d'eux : une API unique devant plus de 200 modèles hébergés, à 0 % de marge, le prix catalogue du fournisseur répercuté sans rien ajouter, et un DSL de routage qui décide quel chemin une requête emprunte. Cette dernière partie est banale et utile — les requêtes texte basculent vers un modèle général hébergé, les requêtes vocales vont vers votre interpréteur auto-hébergé, et l'application n'a pas besoin de savoir laquelle est laquelle. Le basculement automatique en cas de défaillance couvre le cas où le segment hébergé est indisponible et où la requête doit tout de même renvoyer quelque chose.

Comme le segment hébergé est facturé au tarif catalogue du fournisseur, sans rien ajouter, une baisse de prix du fournisseur côté texte est effective de notre côté le jour même. C’est un détail jusqu’à ce que vous ayez à acheminer du trafic documentaire à grande échelle et que l’alternative consiste à renégocier un contrat chaque fois qu’un fournisseur modifie sa grille tarifaire.

Quoi demander avant l’un ou l’autre

La question n’est pas de savoir quel modèle est meilleur. Il s’agit de deux questions, et elles ont des réponses différentes.

Si l’entrée est de l’audio qui arrive encore, et que les langues sont le chinois et l’anglais, la réponse est Hy-SimulMT — et la question du déploiement devient de savoir lequel de ses six checkpoints choisir, ce qui est une décision portant sur la forme et la précision de la sortie plutôt que sur la qualité. Si l’entrée est du texte dans une langue que vous n’avez pas encore identifiée, parmi un ensemble qui inclut des langues à faibles ressources, NLLB-200 reste une référence ouverte légitime quatre ans plus tard, à condition que la licence non commerciale convienne et que vous acceptiez une interface par lots.

Ce que personne n’a publié, c’est le pont : la reconnaissance vocale alimentant NLLB-200 sur de l’audio chinois↔anglais, évaluée sur le même benchmark de streaming que Hy-SimulMT, avec latence et qualité rapportées ensemble. Cette expérience vous dirait si un traducteur textuel de 2022 enveloppé dans un harnais de streaming de 2026 peut rivaliser avec un interprète conçu spécialement. Elle serait aussi la première comparaison honnête de ces deux modèles, et elle n’existe pas encore.

{{1}}Une dernière chose qu'il vaut la peine de dire clairement{{/1}}, car la ressemblance entre {{2}}benchmarks à une lettre près{{/2}} continuera de générer de mauvaises comparaisons : {{3}}un modèle qui gagne sur FLEURS a démontré quelque chose sur la traduction de la parole dans un cadre d'évaluation spécifique{{/3}}. {{4}}Un modèle qui obtient de bons scores sur FLORES-200 a démontré quelque chose sur la traduction de texte dans 200 langues{{/4}}. {{5}}Aucun des deux résultats ne se transfère au travail de l'autre, et le fournisseur qui publie les deux sur le même audio, avec la même métrique et la même comptabilisation de la latence, sera le premier à donner un sens à cette comparaison.{{/5}}