La version 5.18.0 de Transformers fait de la diarisation en streaming un workflow modèle standard

Hugging Face a publié Transformers Release 5.18.0 avec une prise en charge native d’un modèle de 100 millions de paramètres capable de suivre jusqu’à huit locuteurs dans de l’audio en direct ou enregistré. L’ajout phare, Nemotron 3 Diarization de NVIDIA, identifie qui a parlé et à quel moment tout en préservant l’identité des locuteurs entre des segments audio successifs.

Cette intégration est importante, car la diarisation des locuteurs a souvent été traitée en dehors du workflow modèle principal. Les développeurs pouvaient transcrire l’audio avec une pile, identifier les locuteurs avec une autre, puis rapprocher leurs sorties. Transformers 5.18.0 intègre le modèle de diarisation aux interfaces familières AutoProcessor et AutoModelForAudioFrameClassification.

L’enjeu ne se limite pas à l’opposition entre modèles ouverts et API vocales fermées. Il s’agit d’un choix entre des pipelines distincts orientés traitement par lots et un seul checkpoint capable de fonctionner dans des contextes en direct comme hors ligne. La nouvelle prise en charge facilite l’évaluation de cette seconde approche, même si la précision en production, les besoins de calcul et la complexité de déploiement exigent toujours des mesures rigoureuses.

Ce qu’ajoute réellement Transformers Release 5.18.0

La version transforme Nemotron 3 Diarization, d’un modèle NVIDIA spécialisé, en workflow natif de Transformers.

Hugging Face a publié Transformers Release 5.18.0 le 30 septembre 2026. Ses notes de version présentent Nemotron 3 Diarization comme l’une des quatre nouvelles familles de modèles. Les autres sont NemotronH Omni, HyperCLOVAX Vision V2 et GTE.

L’intégration de la diarisation est arrivée via la pull request 49056. Cette contribution a ajouté la configuration du modèle, le processeur, le parcours d’extraction des caractéristiques, le code de modélisation, la documentation, les outils de conversion et les tests. Concrètement, elle a établi une prise en charge dans l’ensemble de la bibliothèque plutôt que de proposer un simple exemple de chargement isolé.

Les développeurs peuvent charger le checkpoint avec les mêmes classes de haut niveau que pour de nombreux autres modèles Transformers. AutoProcessor prépare l’audio, tandis que AutoModelForAudioFrameClassification renvoie des scores d’activité des locuteurs au niveau des trames. Le processeur peut ensuite convertir ces scores en segments contenant un identifiant de locuteur, une heure de début et une heure de fin.

La diarisation des locuteurs répond à la question « qui a parlé et quand ». Elle ne détermine pas, à elle seule, l’identité réelle d’un participant. La sortie utilise des canaux génériques, comme locuteur zéro ou locuteur un, ordonnés selon l’apparition initiale de chaque voix.

Cette distinction est importante pour les applications centrées sur les réunions, les appels, les entretiens, les podcasts et les enregistrements de support client. Une transcription dépourvue de frontières stables entre locuteurs peut mélanger questions et réponses ou attribuer des décisions au mauvais participant. La diarisation fournit la structure nécessaire pour séparer ces contributions.

Nemotron 3 Diarization prend en charge jusqu’à huit locuteurs et produit une probabilité d’activité pour chaque canal de locuteur. Sa sortie par défaut représente l’activité toutes les 10 millisecondes. Les développeurs peuvent également choisir des résolutions plus grossières, par multiples de 10 millisecondes, lorsque leur application n’a pas besoin de ce niveau de précision temporelle.

Le checkpoint accepte de l’audio mono à 16 kHz. NVIDIA cite WAV, FLAC, Opus et MP3 parmi les formats pris en charge. L’inférence par segments supprime toute durée maximale fixe d’enregistrement, afin que les applications puissent traiter de longues réunions sans charger un fichier entier dans une seule fenêtre du modèle.

L’ajout couvre également deux modes de fonctionnement. L’inférence hors ligne accepte un enregistrement terminé, tandis que l’inférence en streaming traite l’audio au fil de l’arrivée des segments. Cette conception à double mode soulève la question centrale de la version : une même implémentation peut-elle remplacer des systèmes de diarisation distincts pour le temps réel et le post-traitement ?

Transformers 5.18.0 ne répond pas automatiquement à cette question. Il fournit toutefois aux développeurs une interface commune pour mener la comparaison. Cela réduit le coût d’évaluation d’un même checkpoint face à plusieurs exigences de latence et de précision.

Un seul checkpoint couvre désormais l’audio en direct et hors ligne

Nemotron 3 Diarization remet en question l’hypothèse selon laquelle le suivi des locuteurs en temps réel et hors ligne nécessite des modèles différents.

Le modèle prend en charge une latence configurable du tampon d’entrée, c’est-à-dire la quantité d’audio collectée avant le début d’une étape d’inférence. NVIDIA documente une plage allant d’un minimum de 80 millisecondes à une configuration de type hors ligne de 30,4 secondes. L’entreprise recommande 0,32 seconde comme configuration standard minimale.

Hugging Face propose trois profils de streaming nommés dans sa documentation du modèle. Le mode par défaut à faible latence attend 1,04 seconde d’audio. Le mode à très faible latence utilise 0,64 seconde, tandis que le mode à latence ultra-faible utilise 0,32 seconde.

Ces chiffres décrivent l’audio mis en tampon, et non le temps de réponse total. Ils excluent l’extraction des caractéristiques, le calcul du modèle, les transferts de données, le post-traitement et la livraison par l’application. Une équipe produit devrait donc éviter de considérer 0,32 seconde comme une latence de bout en bout garantie.

Néanmoins, le tampon ajustable donne aux développeurs un choix opérationnel concret. Un assistant en direct peut privilégier des étiquettes de locuteur précoces, même si un contexte limité réduit la fiabilité. Une archive de conformité peut attendre des segments plus grands, car la précision et une segmentation stable comptent davantage que la sortie immédiate.

Le même checkpoint prend en charge les deux cas. Cela réduit une source de dérive opérationnelle, car les équipes n’ont pas besoin de poids de modèle indépendants pour les parcours en direct et hors ligne. Il leur permet également de comparer les profils de latence sans changer de famille de modèles sous-jacente.

Un système de centre de contact illustre cette différence. Pendant un appel, l’application pourrait utiliser un profil plus court pour distinguer le client d’un agent. Après la fin de l’appel, elle pourrait traiter l’enregistrement avec un tampon plus large pour l’analyse, le contrôle qualité ou la correction de transcription.

Les logiciels de réunion offrent un autre exemple. Une interface en direct a besoin d’étiquettes rapides pour les sous-titres et les notes. L’enregistrement terminé peut tolérer un traitement plus lent pour produire des comptes rendus consultables, des éléments d’action ou un dossier de connaissances pérenne.

Les développeurs pourraient connecter ces sorties à une base de connaissances interrogeable. Toutefois, l’utilité en aval dépend de la préservation du lien entre chaque déclaration, son étiquette de locuteur et son horodatage source.

Cette cohérence est plus difficile à obtenir qu’il n’y paraît. Si un modèle de streaming désigne une personne comme locuteur deux, un traitement hors ligne ne doit pas l’échanger sans précaution avec le locuteur trois. Les systèmes qui fusionnent notes en direct et transcriptions finales ont besoin d’une méthode stable pour rapprocher ces étiquettes.

La convention d’ordre d’arrivée de Nemotron offre une solution. Le premier locuteur détecté occupe le premier canal de sortie, puis les suivants sont placés selon leur apparition initiale. Elle remplace une attribution arbitraire des canaux par une règle déterministe liée à l’enregistrement.

L’ordre d’arrivée n’identifie toujours pas une personne par son nom. Une application a besoin d’une logique distincte d’inscription, de saisie utilisateur ou de correspondance d’identité pour cette tâche. Le modèle fournit plutôt aux systèmes en aval une structure anonyme stable au sein de chaque session.

C’est pourquoi cette intégration met sous pression les piles audio fragmentées. L’approche précédente peut rester pertinente lorsque des composants spécialisés obtiennent de meilleurs résultats. Toutefois, chaque frontière supplémentaire crée un travail de synchronisation, de déploiement et d’observabilité qu’un checkpoint unifié peut réduire.

Le cache de locuteurs est le mécanisme central de la version

La fonctionnalité décisive est la mémoire entre les segments, et non la simple capacité à classifier de courts extraits audio.

La diarisation en streaming devient difficile lorsqu’un locuteur disparaît puis revient plus tard. Un modèle qui traite des segments isolés pourrait attribuer à cette personne un nouveau canal. Il peut aussi confondre deux voix lorsque la fenêtre actuelle ne contient pas suffisamment d’éléments historiques.

Nemotron 3 Diarization répond à ce problème avec un Arrival-Order Speaker Cache, ou AOSC. Le cache conserve des trames sélectionnées associées à des locuteurs précédemment observés. Ces représentations stockées aident le modèle à préserver l’identité des locuteurs à mesure que de nouveaux segments audio arrivent.

Une file premier entré, premier sorti fournit un second type de mémoire. Elle conserve des trames d’encodeur récentes et les place avant le segment actuel durant le traitement. Le cache fournit des informations de locuteur à plus long terme, tandis que la file fournit un contexte acoustique proche.

Cette conception provient de l’article Streaming Sortformer. Ce travail a étendu l’ordonnancement des locuteurs selon leur heure d’arrivée à la diarisation en ligne, où l’audio futur est indisponible ou volontairement limité. Nemotron 3 Diarization transpose ce mécanisme dans un checkpoint open-weight orienté production.

La distinction entre le cache et la file est importante. Les trames récentes sont utiles pour assurer la continuité autour d’une frontière entre segments. Elles ne suffisent pas lorsqu’un participant reste silencieux plusieurs minutes avant de reprendre la parole.

Le cache de locuteurs est conçu pour cette interruption plus longue. Lorsque son contenu est compressé, ses règles de scoring conservent des éléments utiles pour chaque locuteur suivi. Cela réduit le risque qu’un participant très actif consomme toute la capacité disponible du cache.

Chaque étape d’inférence combine le cache de locuteurs, la file récente, le segment actuel et une quantité limitée d’audio anticipé. L’anticipation correspond à des trames futures qui fournissent du contexte mais ne sont pas notées durant cette étape. Ces trames deviennent partie intégrante du segment noté suivant.

Cette construction explique le compromis de latence. Davantage d’anticipation donne au modèle un contexte supplémentaire avant de prendre une décision. Moins d’anticipation permet à une application de renvoyer les étiquettes plus tôt, mais limite les éléments disponibles au moment de la décision.

L’encodeur du modèle traite les représentations audio à une cadence de trame de 80 millisecondes. Une couche ultérieure suréchantillonne les prédictions vers la résolution de sortie configurable, fixée par défaut à 10 millisecondes. L’architecture utilise 31 couches d’encodeur Transformer et des embeddings positionnels rotatifs.

NVIDIA indique que le checkpoint compte 100 millions de paramètres dans sa fiche modèle. Cette taille est modeste comparée à celle de nombreux modèles de langage, mais le nombre de paramètres seul ne prédit pas le coût de déploiement. La durée audio, les réglages de segment, la précision, le matériel et la concurrence façonnent tous la planification de capacité.

Hugging Face documente une optimisation pour l’inférence en streaming répétée. Le cache et la file changent de longueur pendant leur remplissage, ce qui peut conduire torch.compile à créer de nombreuses formes compilées. Le remplissage de chaque étape jusqu’à une fenêtre maximale fixe permet à l’encodeur de compiler une seule fois pour un mode donné.

Dans les mesures de Hugging Face sur A100, cette approche a accéléré une étape de streaming de 1,2 fois avec float32 et de 4,4 fois avec bfloat16. Pour un enregistrement hors ligne de 488 secondes, les gains documentés étaient respectivement de 1,3 fois et 2,8 fois.

Ces mesures constituent des signaux d’ingénierie utiles, non des garanties de performance universelles. Elles proviennent d’un GPU spécifié et d’une taille de lot de un. D’autres accélérateurs, profils audio, versions de framework et charges de travail simultanées peuvent produire des résultats différents.

Le mécanisme plus large reste important même sans ces accélérations. Un cache de locuteurs réutilisable permet à une fenêtre de traitement finie de conserver des informations issues de segments antérieurs de la conversation. C’est ce qui rend un même checkpoint plausible à la fois pour les sessions en cours et les enregistrements complets.

La diarisation unifiée met sous pression les pipelines vocaux fragmentés

La principale ligne de fracture concurrentielle oppose désormais un chemin de diarisation adaptable à des systèmes distincts pour le traitement en direct et par lots.

Les applications vocales traditionnelles assemblent souvent une chaîne de composants spécialisés. La détection d’activité vocale détermine d’abord où se situe la parole. Un modèle d’empreintes vocales représente ensuite les voix, le clustering regroupe les segments associés, puis un autre service transcrit l’audio.

Cette conception modulaire offre de véritables avantages. Les équipes peuvent remplacer un composant sans réentraîner les autres. Elles peuvent aussi ajuster chaque étape à un domaine précis, comme l’audio téléphonique, les enregistrements d’audience ou les réunions captées par des microphones éloignés.

Ses faiblesses apparaissent aux interfaces. Un segment de parole manqué n’atteint jamais les étapes suivantes. Une erreur de clustering peut persister dans une transcription pourtant exacte par ailleurs. Des horodatages séparés peuvent dériver, et chaque composant ajoute du travail de supervision et de déploiement.

La diarisation de bout en bout emprunte une voie différente. Elle prédit directement l’activité des locuteurs pour chaque trame temporelle, y compris l’activité simultanée lorsque les intervenants se chevauchent. Sortformer a introduit un ordre d’arrivée afin d’éviter le problème de permutation des canaux qui complique souvent cette approche.

Le problème de permutation survient parce que les étiquettes des locuteurs n’ont pas d’ordre universel. Deux sorties peuvent décrire une activité identique tout en échangeant les canaux de locuteurs. L’entraînement et l’évaluation deviennent plus difficiles, à moins que l’architecture ou la fonction de perte n’impose une attribution cohérente.

L’ordre d’arrivée fournit cette attribution. Le premier locuteur à apparaître est associé au premier canal, suivi de chaque nouvelle voix. Cette logique est suffisamment simple à comprendre pour les applications en aval et assez stable pour relier des fragments de streaming.

La prise en charge dans Transformers accroît la pression, car elle place cette approche au sein d’une bibliothèque de modèles largement utilisée. Les développeurs peuvent l’évaluer sans adopter une interface de programmation entièrement distincte. Ils peuvent aussi l’associer aux pratiques de déploiement PyTorch et Hugging Face existantes.

Cela n’élimine pas NVIDIA NeMo. La documentation de NVIDIA continue de présenter NeMo Speech comme une voie pour l’entraînement, le fine-tuning, l’évaluation détaillée et l’inférence. L’intégration à Transformers élargit plutôt l’accès via un autre runtime établi et une autre API de modèles.

La publication complète également la reconnaissance automatique de la parole plutôt qu’elle ne la remplace. La diarisation estime l’activité des locuteurs, tandis que l’ASR convertit la parole en mots. Une transcription complète nécessite toujours une méthode pour aligner les mots reconnus sur la chronologie de diarisation.

L’interface de Hugging Face renvoie des probabilités par trame ou des segments de locuteurs traités. Une intégration doit associer ces segments aux mots ou tokens produits par un modèle ASR. Les chevauchements de parole et les désaccords de timing peuvent rendre cette association difficile.

C’est le point de pression pratique pour les fournisseurs de solutions vocales et les équipes de plateformes internes. Un chargeur de modèles n’est qu’un début. Le workflow gagnant doit préserver la cohérence des locuteurs, l’alignement de la transcription, les objectifs de latence et la fiabilité opérationnelle sur de vrais enregistrements.

Les poids ouverts modifient également la décision d’achat. NVIDIA indique que le modèle est disponible pour des usages commerciaux et non commerciaux selon la licence indiquée. Les organisations peuvent examiner les exigences de déploiement et exécuter le checkpoint au sein d’une infrastructure qu’elles contrôlent.

L’exécution locale peut être importante pour les réunions sensibles, les appels clients, les entretiens et les données réglementées. Elle réduit la nécessité d’envoyer des enregistrements bruts vers un endpoint de diarisation hébergé. Les organisations ont néanmoins toujours besoin de contrôles d’accès, de règles de conservation, de processus de consentement et d’un stockage sécurisé.

Le modèle est donc en concurrence sur le contrôle et l’intégration, et pas seulement sur la précision brute. Les services hébergés peuvent proposer une mise à l’échelle gérée et des opérations plus simples. Une voie Transformers à poids ouverts offre un contrôle plus direct du traitement, de la localisation des données, des réglages de latence et de la logique en aval.

Pour les développeurs, cette publication facilite l’évaluation de ce compromis. Elle ne détermine pas à l’avance quel camp l’emportera.

Huit locuteurs et des poids ouverts n’éliminent pas les risques difficiles

La prise en charge native réduit les frictions d’intégration, mais elle ne valide pas les performances pour chaque langue, salle, microphone ou conversation.

La limite la plus visible est le plafond de huit locuteurs. Le modèle produit huit canaux d’activité des locuteurs et a été conçu pour des conversations réunissant un à huit participants. Un enregistrement comptant davantage de participants distincts dépasse cette plage de fonctionnement annoncée.

L’audio réel crée aussi de l’ambiguïté en dessous de cette limite. Des voix similaires, de la parole en arrière-plan, des interruptions, des conversations croisées, de la réverbération, de la musique et des microphones médiocres peuvent tous dégrader la diarisation. Une capacité fixe de canaux ne garantit pas que chaque canal occupé reste correct.

Les données d’entraînement du modèle offrent une grande diversité, mais pas une couverture universelle. NVIDIA fait état d’environ 10 000 heures de conversations réelles et de 82 611 heures de mélanges simulés de plusieurs locuteurs. Les sources comprennent des réunions, de la parole téléphonique, des podcasts, du contenu multilingue et de l’augmentation par bruit.

Ces volumes sont substantiels, mais le nombre d’heures de jeu de données ne se traduit pas directement par une précision adaptée à un déploiement donné. Une consultation médicale, une salle de classe, un appel commercial et un restaurant bruyant présentent chacun des conditions acoustiques différentes. Les équipes doivent effectuer des évaluations à partir de leur propre environnement.

La couverture linguistique mérite la même prudence. La fiche du modèle mentionne des sources en anglais, mandarin, hindi, kannada, télougou, bengali et multilingues. Cela n’établit pas des performances égales dans chaque langue, dialecte ou schéma d’alternance codique représenté.

Le buffer minimal de 80 millisecondes doit également être interprété avec attention. NVIDIA précise que le profil recommandé le plus bas utilise 0,32 seconde. En outre, ce chiffre de buffer d’entrée exclut le calcul et le temps de livraison au niveau du produit.

Les équipes doivent mesurer la latence de bout en bout, depuis la capture au microphone jusqu’à l’affichage de l’étiquette du locuteur. Ce test doit inclure l’encodage audio, le transport réseau lorsqu’il est présent, l’inférence du modèle, le post-traitement, l’alignement de la transcription et le rendu de l’interface.

Le matériel constitue une autre question ouverte. La fiche du modèle met l’accent sur les systèmes accélérés par GPU NVIDIA et la prise en charge de Linux. Transformers peut fournir une API familière, mais cela ne signifie pas que chaque appareil cible bénéficie des mêmes performances testées.

La documentation Hugging Face rapporte de solides gains de compilation en bfloat16 sur un A100. Un déploiement en périphérie, un GPU de station de travail ou un serveur d’inférence partagé nécessite son propre benchmark. L’utilisation mémoire en situation de concurrence peut compter autant que la vitesse d’un flux unique.

L’évaluation de précision doit également correspondre au coût de l’échec pour l’application. Le taux d’erreur de diarisation résume les segments de parole manqués, les fausses alarmes et les confusions entre locuteurs. Toutefois, un score moyen peut masquer les erreurs précises qui nuisent à un produit.

Par exemple, un assistant de réunion peut tolérer une brève interjection manquée, mais pas une décision attribuée au mauvais dirigeant. Un centre d’assistance peut davantage se soucier de séparer la parole de l’agent et celle du client que d’étiqueter systématiquement les voix en arrière-plan.

Les chevauchements de parole méritent des tests explicites. La sortie contient des probabilités d’activité indépendantes pour chaque locuteur, de sorte que plusieurs canaux peuvent être actifs pendant la même trame. La question de savoir si ces prédictions restent utiles lors de chevauchements fréquents dépend des conditions acoustiques et des seuils.

Le risque pour la vie privée persiste après l’inférence locale. Les transcriptions étiquetées par locuteur sont sensibles, car elles relient des déclarations à des rôles persistants au sein d’un enregistrement. Si une application associe ensuite des canaux anonymes à des noms, ce lien peut accroître les conséquences d’un accès non autorisé.

Les développeurs doivent également distinguer la diarisation des locuteurs de la reconnaissance vocale. Le modèle attribue des étiquettes génériques au niveau de la session. Il n’établit pas qu’une voix appartient à une personne précise, et les applications ne doivent pas présenter ces étiquettes comme des identités vérifiées.

Enfin, un checkpoint ouvert ne rend pas à lui seul l’ensemble d’un système reproductible. Le prétraitement, les seuils, la configuration de streaming, la précision, le matériel, le timing ASR et le post-traitement peuvent tous modifier les résultats. Les équipes doivent consigner ces paramètres avec leurs évaluations.

Ces limites n’annulent pas la publication. Elles définissent le travail requis avant qu’une intégration pratique ne devienne une fonctionnalité produit fiable.

Trois signaux montreront si l’intégration compte

Le prochain test est l’adoption sous de vraies charges de travail, et non la présence d’une architecture prise en charge de plus dans un journal de publication.

Le premier signal est la disponibilité d’un package stable et son adoption par l’écosystème. Au moment de la publication, la page de documentation actuelle indiquait que sa branche principale nécessitait une installation depuis les sources. Les développeurs doivent surveiller l’apparition de la prise en charge du modèle via l’installation standard de packages et les outils d’inférence en aval.

Cette transition importe, car les installations depuis les sources sont acceptables pour l’évaluation, mais peu pratiques dans des environnements de production contrôlés. Une voie de publication normale permet le verrouillage des versions, des builds reproductibles, la revue de sécurité et la gestion des dépendances. Des intégrations étendues renforceraient l’idée que la diarisation est devenue une charge de travail Transformers standard.

Le deuxième signal est l’existence de tests indépendants couvrant les profils de latence. Des évaluations utiles devraient présenter l’erreur de diarisation en parallèle du délai de bout en bout, du débit, de l’utilisation mémoire, de la langue, du nombre de locuteurs, du type de microphone et des conditions de chevauchement.

Les résultats obtenus dans les modes 1,04 seconde, 0,64 seconde et 0,32 seconde révéleraient quelle précision chaque application échange contre une sortie plus rapide. Les comparaisons avec le réglage de type hors ligne de 30,4 secondes montreraient si un même checkpoint sert réellement les deux extrémités du workflow.

Un seul benchmark agrégé ne suffirait pas. Les développeurs ont besoin de résultats par domaine pour les réunions, les appels, les podcasts et les environnements bruyants. Ils ont aussi besoin de tests sur un matériel qui ressemble aux systèmes de déploiement réels.

Le troisième signal est une intégration ASR fiable. L’activité des locuteurs devient utile lorsque les applications peuvent l’attacher aux mots sans introduire d’étiquettes instables ni d’erreurs de timing. Les systèmes de transcription en streaming constituent le test le plus exigeant, car le texte comme les attributions de locuteurs peuvent évoluer à mesure que le contexte arrive.

Une implémentation pratique devrait préserver une sortie en direct provisoire tout en produisant une transcription finale cohérente. Elle devrait exposer le comportement de confiance ou de révision, en particulier lorsque les locuteurs s’interrompent. Elle devrait aussi rendre explicite la relation entre les canaux anonymes et les participants nommés.

Ces trois signaux renforcent ou affaiblissent la même thèse. L’adoption via des packages standard montrerait que la prise en charge est opérationnellement mature. Des benchmarks indépendants montreraient si la latence ajustable fonctionne au-delà des exemples du fournisseur. Des intégrations ASR stables montreraient si la diarisation améliore des produits complets plutôt que des démonstrations isolées.

Pour les équipes qui évaluent Transformers Release 5.18.0, l’action immédiate est simple : tester les mêmes enregistrements représentatifs en modes streaming et hors ligne. Mesurez la confusion entre locuteurs, la latence totale, la demande de calcul et l’alignement de la transcription au lieu de vous fier uniquement aux réglages de buffer.

Conservez ensuite les sorties avec leurs horodatages et les détails de configuration. Ces enregistrements rendent les échecs traçables et aident les équipes à comparer les futures révisions du modèle. Ils peuvent aussi favoriser une meilleure mémoire de travail lorsque les preuves de réunion doivent rester liées à leur contexte d’origine.

Transformers Release 5.18.0 rend la diarisation en streaming plus accessible. La question plus importante est de savoir si votre évaluation montre qu’un checkpoint peut remplacer deux voies opérationnelles sans sacrifier la cohérence des locuteurs dont dépendent vos utilisateurs.