Magazine LLM Opensource · 29 October 2026

Nemotron 3.5 Transcribe : ce que vaut vraiment le MoE audio de NVIDIA (et pourquoi votre brique STT est sur la sellette)

NVIDIA a publié le 28 octobre 2026 un modèle de transcription open weights de 30 milliards de paramètres, dont seulement ~4 milliards actifs, couvrant une quarantaine de langues. Sur le papier, c’est le premier acteur majeur à traiter la parole comme une brique native de son stack LLM ouvert. Dans les faits, une bonne partie de ce qui circule relève du communiqué repris en boucle. Voici ce qui est vérifiable, ce qui ne l’est pas, et comment décider si vous devez débrancher Whisper.

Le jour où NVIDIA a glissé un micro dans son stack LLM

Il y a une façon de lire l’annonce du 28 octobre 2026 qui est plus intéressante que les chiffres. Nemotron 3.5 Transcribe, c’est un modèle de reconnaissance vocale — un ASR, une brique parmi les plus ingrates de la chaîne IA, longtemps laissée à OpenAI (Whisper), à Meta (SeamlessM4T, MMS) et à quelques spécialistes (Deepgram, AssemblyAI, Speechmatics). NVIDIA, jusqu’ici, vendait des GPU et publiait des LLM. Le fait qu’il ajoute une corde vocale à une famille de modèles ouverts déjà multimodale, c’est un signal : la couche audio cesse d’être un satellite et devient une pièce du puzzle.

Pourquoi maintenant ? Parce que les pipelines qui comptent en 2026 sont des pipelines agentiques, et que ces pipelines ingèrent de plus en plus de parole : réunions, appels, notes vocales, podcasts, vidéos. Un agent qui ne sait pas lire l’audio est un agent borgne. NVIDIA le formule à sa manière, en publiant une collection Hugging Face dédiée à la parole (nvidia/nemotron-speech) aux côtés de ses briques RAG, safety (Nemoguard) et vision. La collection existe, c’est un fait officiel. Le contenu détaillé, en revanche, mérite qu’on ouvre le capot.

Car il faut poser d’emblée une distinction que la couverture presse a allègrement écrasée. Les chiffres qui circulent — 30B total, ~4B actifs, ~40 langues — proviennent tous, à notre connaissance, du même communiqué NVIDIA relayé par MarkTechPost, TheNextWeb, TechCrunch et quelques autres. Aucun rapport technique dédié, aucune fiche modèle Hugging Face détaillée, aucun benchmark indépendant ne figure dans la matière disponible à ce jour. Ce n’est pas anodin : cela signifie qu’on dispose d’une annonce, pas encore d’une preuve. Tout le reste de cet article part de là, et c’est précisément ce qui le rend utile à un praticien qui doit trancher.

30 milliards sur l’étiquette, 4 milliards en pratique : anatomie d’un MoE qui parle

Commençons par ce qui est solide. La famille Nemotron 3 est officiellement décrite par NVIDIA comme reposant sur une architecture hybride Mamba-Transformer de type Mixture-of-Experts, avec un contexte pouvant atteindre 1 million de tokens. C’est confirmé par deux pages officielles concordantes (developer.nvidia.com et research.nvidia.com). Les modèles de la gamme portent des noms évocateurs — Bolt, Nano (dont un Nano Omni multimodal), Lightning, Super, Ultra — avec des positionnements du edge au datacenter. Nemotron 3.5 Lightning, par exemple, est présenté comme « le modèle MoE 30B le plus rapide » pour des tâches d’agents always-on. Le « 30B MoE » est donc un format que NVIDIA exploite déjà.

Pour Transcribe, la revendication est un MoE de 30 milliards de paramètres totaux avec environ 4 milliards actifs par token. Ce ratio — environ 13 % d’activation — est cohérent avec la philosophie MoE : on paie en VRAM pour la capacité totale, on paie en calcul seulement pour la fraction mobilisée. Concrètement, pour l’inférence, ce qui compte n’est pas 30B mais ~4B : c’est ce qui détermine le débit et une bonne partie de l’empreinte mémoire à l’exécution. Un modèle dense de 30B aurait un coût de calcul par token bien supérieur. C’est là tout l’intérêt de l’architecture, et c’est aussi ce qui rend la comparaison avec Whisper (modèles denses, de taille bien plus modeste) délicate : on ne compare pas des régimes de calcul, on compare des philosophies.

Ce que la matière ne dit pas, en revanche, est considérable. Le nombre d’experts, le top-k de routage, la dimension des experts, la présence ou non de couches LatentMoE (pourtant documentées sur Nemotron 3 Ultra), les couches MTP pour le décodage spéculatif : rien de tout cela n’est confirmé pour Transcribe. L’encodeur audio est évoqué sous le nom « Granary v2 » — mais uniquement dans le titre d’URL d’un article TheNextWeb, ce qui est un indice, pas une spécification. Type d’encodeur, taille, features mel (80 ou 128), stratégie de chunking ou de streaming : non documenté. Le décodeur et le tokenizer : non documentés. Et la question la plus intéressante pour un ingénieur — comment le routage MoE se comporte sur de l’audio, s’il se spécialise par langue ou par tâche — reste entièrement ouverte.

Autrement dit : on a l’étiquette architecturale, pas le plan de montage. Pour un praticien, cela signifie qu’il faut traiter Transcribe comme un modèle à évaluer empiriquement, pas comme un modèle à intégrer sur la foi d’un schéma.

Quarante langues, mais lesquelles ? Le français dans le mille ou dans le flou

« ~40 langues » est une promesse séduisante et une donnée inutilisable en l’état. La liste exacte n’est pas fournie. On ne sait pas si le français y figure en première classe (avec des données d’entraînement abondantes) ou en classe B (avec le risque de WER qui s’envole sur les accents, le code-switching et le vocabulaire spécialisé). On ne sait pas non plus quelles capacités annexes sont réellement présentes : timestamps au mot ou au segment, ponctuation et casse automatiques, diarisation native ou non, traduction intégrée, gestion du code-switching. Aucune de ces réponses n’est vérifiable dans la matière.

C’est un problème pratique, pas académique. Un pipeline de réunion a besoin de diarisation (qui parle) et de timestamps fiables. Un pipeline de sous-titrage a besoin de ponctuation et de segmentation propre. Un pipeline de conformité a besoin de la ponctuation ET de la précision sur les noms propres. Si Transcribe livre la transcription brute sans diarisation native, il faudra lui adjoindre un modèle dédié (pyannote, par exemple) — ce qui change complètement le calcul de coût et de complexité.

La comparaison avec les références du marché doit donc rester qualitative tant qu’on n’a pas de chiffres. Face à lui :

Le point clé : Transcribe n’arrive pas dans un vide. Il arrive dans un marché où Whisper a imposé un standard de fait, où Canary et Parakeet (déjà NVIDIA) occupent des niches, et où les API propriétaires vendent la commodité. Sa proposition de valeur doit donc être lue sur trois axes : qualité multilingue (surtout hors anglais), coût d’inférence (le MoE 4B actifs), et souveraineté (poids ouverts, self-hosting). Sur le premier axe, on n’a rien de vérifiable. Sur les deux autres, on peut raisonner.

Le vrai prix d’un token audio : VRAM, RTF et latence en self-hosting

C’est ici que le MoE devient intéressant — et que les chiffres manquent le plus cruellement. Aucun RTF (real-time factor), aucun débit en heures audio par heure GPU, aucune empreinte VRAM par GPU (H100, A100, L40S, RTX 4090), aucune latence streaming ne figure dans la matière. On ne peut donc pas calculer sérieusement le coût self-hosted face au coût par minute des API. Mais on peut poser le cadre de décision.

Un modèle à ~4B paramètres actifs, en pratique, s’exécute sur une carte unique de datacenter ou même sur une RTX haut de gamme, selon la quantification et le framework. C’est l’argument massue du MoE : la capacité totale reste élevée (30B), mais le coût par token reste celui d’un modèle de taille intermédiaire. Pour de la transcription, où l’on traite de longues séquences audio tokenisées, ce différentiel se traduit directement en débit.

Face à cela, les API propriétaires facturent à la minute d’audio. Le calcul de rentabilité classique s’établit ainsi : à partir de quel volume mensuel le coût d’un GPU dédié (amorti ou loué) devient-il inférieur au coût variable des minutes consommées ? Sans les chiffres de débit de Transcribe, on ne peut pas trancher — mais on peut dire que la question se pose à des volumes qui, pour beaucoup d’organisations, sont atteints dès qu’on traite des réunions internes à l’échelle d’une entreprise. C’est précisément le seuil où le self-hosting devient rationnel.

Deux nuances importantes. D’abord, le self-hosting n’est pas gratuit : il faut compter l’ingénierie, la surveillance, les mises à jour, la gestion des pannes. Ensuite, le débit n’est pas tout : la latence en streaming (temps entre la parole et le token transcrit) est critique pour les cas d’usage temps réel (assistants vocaux, sous-titrage live). Un modèle très rapide en batch peut être médiocre en streaming si son encodeur n’est pas conçu pour le chunking incrémental. Or on ne sait pas si l’encodeur Granary v2 (si c’est bien lui) gère le streaming. C’est un point de rupture à vérifier avant tout engagement.

Licence, poids et petites lignes : ce qu’on peut vraiment faire du modèle

NVIDIA présente Nemotron comme une famille de modèles ouverts : poids, données d’entraînement et recettes publiés sur Hugging Face, avec rapports techniques accessibles. C’est une position forte, et c’est ce qui distingue Nemotron des modèles simplement « disponibles en téléchargement ». Mais il faut être précis sur le vocabulaire.

« Open weights » n’est pas « open source ». Un modèle à poids ouverts vous laisse l’utiliser, souvent le modifier, parfois le redistribuer — mais sous des conditions qui varient : restrictions d’usage commercial, clauses de non-concurrence, obligations d’attribution, limitations sur les données d’entraînement. La licence exacte de Transcribe n’est pas précisée dans la matière. C’est une lacune majeure pour un produit : une licence qui interdit l’usage commercial en SaaS change tout le calcul. Il faut donc vérifier la licence sur la fiche Hugging Face avant toute décision.

Côté opérationnel, la famille Nemotron est déployable via vLLM, SGLang, Ollama, llama.cpp, et via les microservices NIM. C’est un écosystème mature, et c’est un vrai avantage : un modèle qui tourne sur vLLM ou SGLang s’intègre dans une infrastructure d’inférence existante sans réécrire la moitié de la stack. Mais attention : ces frameworks sont conçus pour des LLM texte. Un modèle audio a un encodeur en amont et un pipeline de features spécifique. La compatibilité « vLLM » d’un modèle ASR signifie généralement que le décodeur tourne sur vLLM, pas que tout le pipeline est plug-and-play. Là encore, à vérifier.

Les contraintes matérielles minimales ne sont pas documentées. Pour un modèle à ~4B actifs, on peut raisonnablement penser qu’une carte unique de 24 Go suffit en quantification, mais c’est une inférence, pas une donnée. Un praticien sérieux testera avant de dimensionner.

Brancher Transcribe dans un pipeline RAG ou agent : le mode d’emploi critique

Voici à quoi ressemble un pipeline réaliste, et où ça casse.

Étape 1 — Ingestion audio. Fichier ou flux. Si flux temps réel, il faut un endpoint streaming ; si fichier, un découpage en chunks. Le piège classique : découper sur des frontières arbitraires (toutes les 30 secondes) coupe des mots et dégrade la transcription. Il faut un VAD (détection d’activité vocale) en amont pour segmenter sur les silences.

Étape 2 — Transcription. Transcribe produit du texte, idéalement avec timestamps. Si les timestamps ne sont pas natifs, il faut un alignement forcé (forced alignment) en aval — une étape supplémentaire, un modèle supplémentaire, un coût supplémentaire.

Étape 3 — Diarisation. Si Transcribe ne fait pas de diarisation native, il faut un modèle dédié (pyannote ou équivalent) et fusionner les sorties. C’est là que les pipelines se compliquent : aligner des segments de diarisation avec des segments de transcription demande de la logique.

Étape 4 — Post-traitement. Ponctuation, casse, normalisation, correction des noms propres. Un LLM léger peut s’en charger, mais attention à ne pas halluciner : un LLM qui « corrige » une transcription peut inventer du contenu. Il faut un prompt contraint et une vérification.

Étape 5 — Indexation / agent. Le texte enrichi (timestamps, locuteur, ponctuation) part dans un index vectoriel pour le RAG, ou directement dans le contexte d’un agent.

Les points de rupture à surveiller : le chunking sur l’audio long (qualité qui se dégrade aux frontières), la gestion du code-switching (un locuteur qui alterne français et anglais), les accents et le bruit de fond, et la cohérence des timestamps entre les étapes. Un pipeline qui marche sur un podcast propre peut s’effondrer sur une réunion avec micros partagés.

Benchmarks : trier les chiffres qui comptent des slides marketing

C’est le moment de la méthode. Les jeux de référence pour un usage francophone sont : MLS (multilingue, dont français), Common Voice (couverture large, accents variés), FLEURS (multilingue, orienté basse ressource), VoxPopuli (parole politique européenne, dont français), et LibriSpeech (anglais, pour la comparaison). Un WER publié sur LibriSpeech ne dit rien de la qualité en français. Un WER sur Common Voice dit quelque chose, mais dépend de la normalisation (ponctuation retirée ou non, casse, nombres écrits en chiffres ou en lettres).

Le piège classique : comparer des WER calculés avec des normalisations différentes. Un modèle qui sort de la ponctuation aura un WER artificiellement meilleur si on ne la compte pas. Un modèle qui écrit « 2026 » là où la référence dit « deux mille vingt-six » sera pénalisé. Il faut donc toujours vérifier la recette de normalisation avant de comparer.

Deuxième piège : les chiffres du rapport technique NVIDIA. Ils sont, par construction, choisis par l’éditeur. Ils doivent être recoupés par l’Open ASR Leaderboard (qui agrège des évaluations indépendantes) et, surtout, par des tests maison sur VOS données. Un modèle peut être excellent sur FLEURS et médiocre sur vos réunions internes avec vos accents et votre vocabulaire métier.

Protocole d’évaluation en cinq étapes :

1. Constituer un jeu de test maison : 2 à 5 heures d’audio représentatif de votre usage (accents, bruit, vocabulaire), transcrit manuellement.
2. Définir une normalisation unique : ponctuation, casse, nombres, et l’appliquer à toutes les sorties.
3. Mesurer le WER et le CER (le CER est plus parlant pour les langues à morphologie riche comme le français).
4. Mesurer le RTF et la latence sur votre matériel cible, en batch et en streaming.
5. Comparer au coût total : self-hosted (GPU + ingénierie) vs API (minutes consommées).

C’est le seul protocole qui protège contre les slides marketing.

Remplacer ou attendre ? La décision en trois scénarios

Startup produit. Vous avez un pipeline STT basé sur Whisper ou une API. Le passage à Transcribe se justifie si (a) vous traitez un volume suffisant pour amortir un GPU, (b) vous avez besoin de multilingue au-delà de l’anglais, et (c) vous pouvez absorber le coût d’intégration. Le risque : la licence et la maturité de l’écosystème audio autour du modèle. Verdict : tester en parallèle, ne pas migrer avant d’avoir des chiffres maison.

Entreprise avec données sensibles. C’est le scénario où Transcribe est le plus intéressant : poids ouverts, self-hosting, pas d’envoi d’audio à un tiers. La souveraineté n’est pas un argument marketing ici, c’est une contrainte réglementaire. Le coût marginal devient un coût fixe (GPU), ce qui simplifie la prévision budgétaire. Verdict : candidat sérieux, à condition de valider la licence et la qualité sur vos données.

Équipe de recherche. Vous voulez un modèle de référence, reproductible, modifiable. Les poids ouverts et les recettes publiées sont un avantage réel. Verdict : à évaluer, mais attendez le rapport technique pour comprendre l’architecture.

Dans les trois cas, le coût de migration depuis Whisper n’est pas neutre : écosystème, outils, habitudes. Et le risque de verrouillage, même avec des poids ouverts, existe : si vous bâtissez votre pipeline sur des spécificités de Transcribe (formats de sortie, API), vous recréez une dépendance.

Après Transcribe : la vague audio open weight qui arrive

L’entrée de NVIDIA dans l’ASR ouvert n’est pas un accident. Elle s’inscrit dans une dynamique plus large : les grands acteurs publient des modèles multimodaux qui intègrent l’audio, et la frontière entre ASR, traduction et LLM s’estompe. Les noms à surveiller : Qwen-Audio (Alibaba), Kyutai (français, orienté temps réel), Mistral Audio, Meta (SeamlessM4T et successeurs). La tendance de fond est aux modèles speech-to-LLM natifs, où l’audio n’est plus un pré-traitement mais une modalité d’entrée directe.

Trois indicateurs à surveiller dans les six prochains mois :

1. La publication du rapport technique de Transcribe : architecture, benchmarks, licence. C’est le document qui transformera une annonce en référence.
2. Les résultats sur l’Open ASR Leaderboard : si Transcribe y apparaît avec des scores compétitifs en français, le marché bouge.
3. L’adoption dans les frameworks : si vLLM, SGLang et les outils de pipeline audio (WhisperX, NeMo) intègrent Transcribe nativement, l’écosystème bascule.

En attendant, la décision raisonnable pour un praticien est simple : ne remplacez pas votre brique STT sur la foi d’un communiqué. Testez. Le MoE à 4B actifs est une promesse d’économie réelle, mais une promesse n’est pas un benchmark. Et dans un domaine où le WER sur vos données vaut mille slides, la prudence est la seule stratégie qui ne coûte rien.

Sources

• NVIDIA Releases Nemotron 3.5 Transcribe: An Open 30B MoE Model for 40-Language Transcription with ~4B Active Parameters — MarkTechPost, 28 octobre 2026
• NVIDIA Developer — Nemotron
• NVIDIA Research — Nemotron 3 Ultra
• NVIDIA — Foundation Models Nemotron
• GitHub — NVIDIA-NeMo/Nemotron
• Wikipédia — Nemotron

Article recherché et rédigé automatiquement · Magazine Electrosens