NVIDIA Nemotron 3 Diarization : la carte de passage des locuteurs à la transcription pour la parole superposée

Prenons une transcription d'appel hypothétique. Deux personnes parlent en même temps. L'interface affiche speaker_1, speaker_2 et speaker_3. Le diariseur indique que deux canaux anonymes étaient actifs au même moment. Le système ASR a entendu une forme d'onde mélangée. Le produit doit maintenant décider quels mots appartiennent à quel canal, quels mots sont incertains et si une étiquette doit survivre lorsque le même utilisateur se reconnecte.

NVIDIA a publié Nemotron 3 Diarization le 23 septembre 2026. Il étend l'approche précédente Sortformer en streaming à quatre locuteurs à huit canaux de locuteurs. Pour les concepteurs de transcriptions, le changement utile est le signal d'activité. Transformer ce signal en mots correctement attribués nécessite toujours une étape ASR compatible et une gestion attentive des sessions.

Pourquoi huit canaux de diarisation ne sont pas une transcription de huit personnes

Ce que produit Nemotron 3 Diarization

NVIDIA décrit Nemotron 3 Diarization comme un modèle de diarisation à poids ouverts avec 100 millions de paramètres. Il consomme un audio monocanal à 16 kHz et produit des probabilités d'activité des locuteurs sur un maximum de huit canaux de sortie. La fiche du modèle et les documents de publication décrivent une sortie structurée comme le temps par canaux de locuteurs, avec un pas par défaut de 10 ms. Le modèle utilise des caractéristiques d'entrée de 80 ms, construites en empilant huit caractéristiques de 10 ms. Cela donne un signal d'activité fin. Cela ne résout toujours pas toutes les frontières de mots.

Le diariseur estime quels canaux anonymes sont actifs. Il ne peut pas identifier une personne nommée ni attribuer seul chaque mot superposé.

Ce qu'il ne produit pas

Nemotron 3 Diarization ne produit pas de texte. Il ne sépare pas les voix superposées en flux audio individuels propres. Il ne fournit pas d'identité biométrique. Une étiquette comme speaker_2 est un canal local à la session, fondé sur l'ordre d'arrivée, pas un profil de personne durable. Si un utilisateur se déconnecte, se reconnecte ou si l'application réinitialise son cache, cette étiquette peut changer.

Un assistant de réunion, un outil d'appels support, un enregistreur d'entretien, un éditeur de podcast ou un système de revue audio terrain peut utiliser la piste d'activité comme preuve. Il ne doit pas présenter cette preuve comme une vérité finale lorsque des chevauchements, une incertitude ASR ou des réinitialisations de session sont en jeu.

Le modèle mental utile

Cet article utilise la carte Optijara de passage des locuteurs à la transcription. La carte couvre l'horloge d'entrée, l'activité anonyme, l'association ASR, l'incertitude liée aux chevauchements, l'état par session, la finalisation applicative et les résultats mesurés. L'analyse repose sur la documentation publique et les sources disponibles. Optijara n'a pas exécuté d'inférence ni reproduit les benchmarks publiés. Les étapes d'implémentation et d'évaluation ci-dessous sont des tests proposés.

Ce que la publication de septembre change pour les applications vocales

Lire ensemble les artefacts de publication

Lisez ensemble le billet de publication, la fiche du modèle et le guide d'intégration. La publication établit le nouveau modèle ; la fiche définit les sorties d'activité et les préréglages de streaming ; le guide explique le chemin ASR couplé. Le guide est antérieur à l'annonce, il s'agit donc d'une documentation d'implémentation actuelle, pas d'un nouveau service hébergé récemment lancé. Figez les révisions du modèle et le checkout NeMo Speech avant les tests.

Diarisation autonome par rapport à l'intégration ASR

La diarisation autonome peut annoter un fichier ou un flux avec les canaux de locuteurs actifs. L'intégration ASR comporte davantage de points de défaillance. Le guide utilise multitalker-parakeet-streaming-0.6b-v1 pour l'anglais, tandis que d'autres fiches ASR NVIDIA en streaming ont des profils multilingues et une géométrie différentes. Les équipes devraient éviter d'ajuster les fragments de diarisation isolément pour les raccorder ensuite à l'ASR. L'horloge des trames, le contexte d'attention, la politique d'horodatage et le comportement du cache doivent être alignés.

Les chiffres de benchmark ont besoin de contexte

Le billet de publication de NVIDIA décrit des résultats initiaux VoiceArena issus de 139 conversations en anglais et des comparaisons DER séparées, propres à certaines conditions. Ces chiffres aident à cadrer les tests, mais ils ne constituent pas une évaluation produit. Le DER combine la parole manquée, les fausses alarmes et la confusion de locuteurs sur le temps de locuteur de référence. Les références RTTM exactes, les marges, la notation des chevauchements, l'alignement forcé et les conditions acoustiques peuvent changer la lecture du même score.

Les chiffres de débit peuvent aussi induire en erreur. Une forte accélération du facteur temps réel (RTFx, durée audio divisée par le temps de traitement) dans une configuration précise de lot, précision, compilation et matériel n'est pas la même chose qu'une latence de bout en bout en direct pour un système destiné aux utilisateurs. L'utilisateur attend la mise en mémoire tampon de l'entrée, le calcul, le transport, l'ASR, les mises à jour de l'interface, le stockage et la finalisation. L'analyse temporelle d'Optijara sur les étapes d'encodage et de décodage dans OpenVINO GenAI fait la même distinction pour un autre pipeline d'inférence.

La carte de passage des locuteurs à la transcription

La carte de passage des locuteurs à la transcription est une carte d'architecture produit pour transformer l'activité anonyme en segments de transcription auxquels une personne peut faire confiance, ou au moins qu'elle peut contester avec des preuves.

1. Horloge d'entrée

Commencez par l'horloge audio, pas par la transcription. Le PCM entrant doit être rééchantillonné et découpé en trames avant que la diarisation et l'ASR puissent raisonner dessus. Si le service accepte l'audio de navigateur, l'audio téléphonique, les fichiers téléversés et les enregistrements mobiles, normalisez la fréquence d'échantillonnage et la gestion des canaux avant d'alimenter le modèle. Le diariseur attend un audio monocanal à 16 kHz, l'application doit donc rendre cette transformation explicite et testable.

2. Activité anonyme

Le diariseur produit des canaux d'activité anonymes. Il peut montrer que le canal 0 et le canal 3 étaient actifs au même moment. Il ne peut pas dire que deux personnes nommées parlaient au même moment sauf si une couche d'identité séparée, avec le consentement approprié, relie ces canaux à des personnes.

3. Association ASR

L'association ASR est l'endroit où de nombreuses démos deviennent fragiles. Un script d'aide qui rejoue un manifeste est un point de départ. Ce n'est pas un service de microphone ou WebSocket de production. Le code de production a besoin, lorsque c'est possible, de poids de modèle chargés une seule fois, de tampons par client, de caches par client, d'état du décodeur, d'historique des horodatages et d'une politique de vidage.

Utilisez le speech_to_text_multitalker_streaming_infer.py du guide pour rejouer des fichiers ou des manifestes dans le chemin de streaming. Un vrai service microphone ou WebSocket doit alimenter une session cliente persistante avec l'audio nouvellement arrivé au lieu de redémarrer sans cesse ce script de relecture.

4. Incertitude de chevauchement

L'activité superposée ne doit pas être aplatie en fausse certitude. Si un canal est actif au milieu d'un mot, l'application peut étiqueter le mot avec ce canal. Si plusieurs canaux sont actifs, marquez le segment comme chevauchement ou ambigu, sauf si le système ASR est explicitement conçu et évalué pour l'attribution tenant compte des chevauchements.

Gardez le drapeau de chevauchement visible lorsque l'attribution n'est pas résolue. La carte d'évaluation Vaani du bruit et des horodatages d'événements d'Optijara couvre une leçon connexe. La preuve d'horodatage n'a de valeur que lorsque l'application préserve ce que la preuve peut démontrer, et ce qu'elle ne peut pas démontrer.

5. État de session

Chaque client actif a besoin d'un état isolé : tampons, cache, état du décodeur, historique des locuteurs, horodatages et statut de finalisation. Des poids partagés peuvent être raisonnables. Un état de session partagé ne l'est pas. Si un client se reconnecte, l'application devrait décider s'il faut poursuivre une session avec une preuve explicite de continuité ou démarrer une nouvelle session avec de nouvelles étiquettes de canaux.

6. Finalisation applicative

Une transcription en streaming devrait distinguer le texte provisoire du texte final. Les mots provisoires aident l'interface à paraître vivante, mais la persistance de la transcription finale devrait inclure les preuves d'horodatage, les preuves de canal de locuteur, le statut de chevauchement et l'historique des révisions. L'objet de transcription devrait préserver l'incertitude au lieu de l'écraser. Voici un enregistrement applicatif illustratif, pas une sortie de modèle mesurée ni un schéma NeMo officiel. Ses horodatages et son texte sont inventés uniquement pour montrer les champs proposés.

{
  "segmentId": "seg_001",
  "startMs": 12840,
  "endMs": 15420,
  "text": "we should hold that decision until the next test clip",
  "speakerChannel": "speaker_2",
  "attributionStatus": "single_active_channel",
  "overlapChannels": [],
  "sourceEvidence": {"diarizationWindowMs": [12800, 15500], "asrTimestamps": true},
  "finality": "final"
}

7. Résultats

Le DER compte, mais l'utilité produit dépend aussi des erreurs de mots attribués aux locuteurs, de l'erreur de nombre de locuteurs, du temps jusqu'au texte provisoire, du temps jusqu'au texte final, de la latence de bout en bout p95, de la mémoire et de la concurrence. Mesurez la transcription finale ainsi que chaque étape du modèle.

Trois schémas d'implémentation

Schéma A : diarisation autonome pour annotation et revue

La diarisation autonome fonctionne bien lorsque la tâche consiste à revoir l'audio, marquer qui était actif quand, ou préparer l'annotation. C'est aussi la façon la plus simple d'inspecter le comportement des canaux avant d'ajouter l'ASR.

Les valeurs cache, FIFO, fragment, contexte droit et mise à jour utilisent des trames d'encodeur de 80 ms. La formule (chunk + right) * 80 ms décrit la latence du tampon d'entrée, hors calcul, transport, ASR, interface et persistance. Utilisez les cinq réglages d'une même ligne, puis appelez _check_streaming_parameters(). Un tampon de 80 ms est techniquement possible, mais il est inférieur à la configuration recommandée la plus basse. Ces lignes autonomes ne sont pas des réglages prêts à l'emploi pour l'ASR couplé.

Schéma B : ASR hors ligne plus attribution des locuteurs au point médian

La jonction hors ligne est courante pour les enregistrements. Exécutez l'ASR, exécutez la diarisation, puis attribuez chaque mot ou segment à l'aide des horodatages. Une règle simple du point médian peut fonctionner comme référence de base. Un canal actif étiquette le mot. Plusieurs canaux actifs marquent un chevauchement ou une ambiguïté. Aucun canal actif laisse le mot non attribué. L'erreur consiste à prétendre que couper l'audio mélangé aux horodatages sépare les voix. Ce n'est pas le cas.

Schéma C : ASR en streaming couplé avec conditionnement par l'activité

Le guide d'intégration ASR actuel documente deux associations avec un conditionnement et un contexte d'encodeur différents.

Nemotron 3.5 ASR dispose de huit locales supplémentaires prises en charge par le tokenizer qui nécessitent une adaptation ; elles ne sont pas prêtes à l'emploi. Son chemin masqué à locuteur unique peut gérer les chevauchements dans une certaine mesure, pas comme une garantie. L'assistant dérive la géométrie des fragments de diarisation à partir de l'encodeur ASR. Validez les pas de trames et gardez les réglages propres au modèle ensemble. cache_gating=true évite un travail ASR inutile pour les canaux inactifs, mais davantage de flux de locuteurs concurrents exigent toujours de l'état et du calcul.

Matrice de décision

Liste de contrôle pour construire une transcription en streaming attribuée aux locuteurs

Chargez les poids partagés une seule fois lorsque la conception du service le permet, mais isolez les objets SpeakerTaggedASR, les tampons, les caches, les décodeurs, l'historique des horodatages et l'état de finalisation par client. Huit canaux de diarisation n'impliquent pas huit copies complètes du modèle. Les poids partagés n'effacent pas non plus les coûts de concurrence.

Rééchantillonnez le PCM entrant avant la géométrie de saut requise. Ne copiez pas un commentaire de rééchantillonnage fictif depuis un exemple pour l'appeler production. Validez les pas de trames, la configuration des fragments et le contexte droit avant de mesurer la latence.

Traitez toutes les trames complètes et sérialisez les rappels qui modifient l'état de session. Les conditions de concurrence dans la finalisation de transcription peuvent créer une dérive d'étiquette de locuteur qui ressemble à une erreur de modèle, même lorsque l'application l'a causée.

À l'arrêt, à la déconnexion ou lors d'une interruption réseau, videz l'audio restant, persistez les segments finaux et réinitialisez l'état intentionnellement. Si la continuité après reconnexion compte, enregistrez comment l'application prouve la continuité au lieu de supposer que speaker_2 désigne toujours la même personne.

Stockez les temps de début et de fin, le canal de locuteur, le statut d'attribution, les canaux de chevauchement, la source de preuve, la finalité et l'historique des révisions. Ces champs rendent le débogage possible lorsqu'un utilisateur conteste une transcription.

Ce que les équipes se trompent avec les passages diarisation-ASR

La première erreur est de traiter speaker_2 comme une véritable identité. C'est un canal local à la session. Ce n'est pas un nom, un identifiant de connexion, un profil d'employé ni une identité biométrique.

La deuxième erreur est de supposer que les étiquettes de reconnexion sont stables. Une réinitialisation peut changer les canaux fondés sur l'ordre d'arrivée. Les applications ne devraient afficher une continuité que lorsqu'elles disposent de preuves séparées.

La troisième erreur est de découper l'audio mélangé par horodatage et de s'attendre à des voix séparées. Le découpage par horodatage peut isoler une fenêtre temporelle, pas séparer les voix à l'intérieur d'une forme d'onde mélangée. Le chevauchement exige une gestion explicite.

La quatrième erreur est de revendiquer des sessions illimitées à partir d'une inférence par fragments. Le fonctionnement par fragments supprime l'hypothèse d'une durée de fichier fixe. Il ne garantit pas un comportement fiable dans toutes les conditions acoustiques, réseau, linguistiques et de concurrence.

La cinquième erreur est de ne rapporter que le DER en ignorant l'attribution au niveau des mots. Un DER faible ne garantit pas que les utilisateurs voient une transcription digne de confiance. Les erreurs de mots attribués aux locuteurs, les chevauchements ambigus et le délai de finalisation comptent.

Un plan de test avant d'adopter Nemotron 3 Diarization

Traitez ceci comme un plan d'adoption fondé sur la documentation publique et l'inspection des sources, pas comme une campagne de benchmark terminée.

Figez la révision du modèle, la révision du compagnon ASR et le checkout du dépôt avant de comparer les résultats. Sinon, une modification ultérieure de fiche de modèle ou de dépôt peut rendre deux campagnes de test incomparables.

Construisez une petite suite de tests avec des locuteurs arrivant tard, des interruptions, des mots superposés, un locuteur revenant après un silence, une reconnexion client, des microphones variés, du bruit de fond et un extrait de stress à plus de huit locuteurs marqué hors périmètre.

Mesurez séparément la latence provisoire et finale. Les utilisateurs vivent ces états différemment. Séparez aussi le temps de tampon d'entrée du calcul, du réseau, de l'ASR, du rendu d'interface et du stockage.

Documentez les contraintes linguistiques, acoustiques et de consentement à côté de l'évaluation. La couverture linguistique dépend du compagnon ASR, pas seulement du diariseur. Le comportement acoustique dépend des microphones, du bruit de salle, du chevauchement et de la qualité des canaux. Enregistrer et diariser la parole peut nécessiter un consentement et des contrôles de confidentialité selon le contexte produit et la juridiction.

Les conditions des modèles et logiciels diffèrent aussi : le diariseur utilise OpenMDW 1.1, le code NeMo Speech utilise Apache 2.0, et le compagnon ASR a ses propres conditions de modèle. Les poids ouverts ne suppriment pas les obligations de consentement à l'enregistrement.

Résumé lisible par machine

{"framework":"Speaker-to-Transcript Handoff Map","input":{"sample_rate_hz":16000,"channels":1},"max_speakers":8,"identity_scope":"session-local anonymous channels","preserve":["overlap ambiguity","timestamps","tentative versus final text"],"deployment_checks":["matched ASR frame geometry","isolated client state","transcript-level evaluation"],"test_status":"proposed, not executed by Optijara"}