NVIDIA libera Nemotron 3 Diarization, modelo aberto de 100M parâmetros para identificar quem fala em tempo real

Transcrever uma reunião é fácil. Saber quem disse cada frase é o problema real: sem essa informação, um sistema de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → não consegue atribuir um compromisso a um participante, detectar quem interrompeu quem, nem alimentar a memória de um agente de voz com contexto por pessoa. Esse é o problema que a NVIDIA ataca com o Nemotron 3 Diarization, publicado em 23 de setembro de 2026 no Hugging Face: um modelo de diarização de falantes, open-weight, com 100 milhões de parâmetros, que ficou em primeiro lugar no VoiceArena Diarization-Bench com 14,72% de Diarization Error Rate (DER), cerca de 24% melhor que o segundo colocado (19,3%).

Diarização não é reconhecimento de fala (ASR). O ASR transcreve palavras; a diarização marca intervalos de tempo e diz "aqui fala o speaker_0, aqui fala o speaker_1", inclusive quando duas pessoas falam ao mesmo tempo. Um pipeline de transcrição com atribuição de falante combina os dois: primeiro a diarização gera os timestamps por canal, depois o ASR preenche o texto em cada intervalo. É assim que ferramentas de atas de reunião, análise de call center e agentes de voz multiusuário funcionam por baixo do capô.

Como o modelo resolve o problema técnico

O Nemotron 3 Diarization segue a abordagem Sortformer, já usada em modelos anteriores da NVIDIA (como o streaming Sortformer de 4 falantes, usado aqui como baseline de comparação). A ideia central: os canais de saída são ordenados pela ordem de chegada de cada voz na conversa, não por identidade real. A primeira voz nova vira o canal speaker_0, a segunda vira speaker_1, e assim por diante, até oito canais. Isso evita ter que resolver um problema de permutação de falantes a cada novo trecho de áudio processado, o que é crítico para manter consistência em streaming.

Por baixo, o áudio (16 kHz, mono) vira espectrograma Mel, é agrupado em frames de 80ms e passa por um encoder Transformer de 31 camadas com rotary positional embeddings (RoPE). A saída é um tensor [T, 8]: para cada instante de tempo, a probabilidade de cada um dos oito canais estar ativo. Como os canais são independentes, sobreposição de fala é representada naturalmente, dois canais podem estar ativos no mesmo frame.

Para operar em streaming, o modelo usa duas formas de memória: o Arrival-Order Speaker Cache (AOSC), que retém informação de falantes já vistos em chunks anteriores, e uma fila FIFO com o contexto recente de frames. Combinado com um pouco de contexto "à direita" (áudio logo após o chunk atual), isso permite ajustar o trade-off entre latência e acurácia sem trocar de modelo.

Quatro pontos de operação, um modelo só

A NVIDIA documenta quatro configurações prontas, todas usando o mesmo checkpoint:

| Configuração | Latência de buffer | Speaker cache | FIFO | Chunk | Contexto direito | Período de atualização do cache | |---|---|---|---|---|---|---| | Offline-style | 30,4 s | 264 | 40 | 340 | 40 | 300 | | Baixa latência | 1,04 s | 9 | 4 | 222 | – | – | | Latência muito baixa | 0,64 s | 6 | 2 | – | – | – | | Latência ultra baixa | 0,32 s | 3 | 1 | – | – | – |

Esses números são medidos em frames de 80ms e representam apenas a latência do buffer de entrada, sem contar o tempo de computação, rede, ASR e processamento downstream, que se somam no fim a fim. É um detalhe que faz diferença: quem for prometer "latência de 320ms" para um agente de voz em produção precisa medir o pipeline completo, não só essa etapa.

Os números do benchmark

O DER (Diarization Error Rate) soma três tipos de erro: fala perdida, alarme falso e confusão de falante, dividido pelo tempo total de referência. A avaliação da NVIDIA usa 901 gravações espalhando telefonia multilíngue, reuniões, microfones de campo próximo e distante, e ambientes acústicos difíceis, com datasets como DIHARD III, AliMeeting, AMI, NOTSOFAR1 e CALLHOME-Part2.

Comparando com o Streaming Sortformer anterior (limitado a 4 falantes), a redução relativa média de DER foi de 41% na configuração de 1,04 segundo de latência, variando de 9% no CALLHOME-Part2 até 65,2% no NOTSOFAR1 MHM. O ganho cresce especificamente em cenários com mais de quatro falantes, o que faz sentido: é justamente onde o suporte a oito canais (contra quatro do modelo anterior) entra em jogo. Um detalhe honesto que a própria NVIDIA registra: no subconjunto de apenas dois falantes do CALLHOME, o modelo anterior teve DER levemente melhor (5,68% contra 5,98%), o ganho do Nemotron 3 não é uniforme em todo cenário, é mais forte quando há mais gente na sala.

Em throughput, medido como RTFx (duração de áudio dividida pelo tempo de processamento) em uma RTX PRO 5000 com batch 32 e torch.compile(): 15.113x na configuração offline (contra 2.619x do modelo anterior) e 865x na configuração de baixa latência (contra 136x). São números de processamento em lote no hardware divulgado, não latência de uma única stream em produção, e o próprio material recomenda benchmarking do pipeline completo antes de assumir esses valores como referência de deploy.

Colocando para rodar

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

O modelo está disponível via NVIDIA NeMo. A instalação básica:

apt-get update && apt-get install -y libsndfile1 ffmpeg
uv pip install Cython packaging
uv pip install 'nemo-toolkit[asr]'

Para diarização offline de uma gravação com dois ou mais falantes:

from nemo.collections.asr.models import SortformerEncLabelModel

diar_model = SortformerEncLabelModel.from_pretrained(
 "nvidia/Nemotron-3-Diarization"
)
diar_model.eval()

# valores medidos em frames de 80ms
diar_model.sortformer_modules.spkcache_len = 264
diar_model.sortformer_modules.fifo_len = 40
diar_model.sortformer_modules.chunk_len = 340
diar_model.sortformer_modules.chunk_right_context = 40
diar_model.sortformer_modules.spkcache_update_period = 300
diar_model._check_streaming_parameters()

predicted_segments = diar_model.diarize(
 audio=["/path/to/conversation.wav"],
 batch_size=1,
)

for segment in predicted_segments[0]:
 print(segment)

O retorno é uma lista de segmentos no formato start_seconds end_seconds speaker_id, por exemplo 0.400 2.100 speaker_0. Vale notar que um mesmo intervalo pode aparecer em dois canais simultaneamente (fala sobreposta), e que os speaker_id são rótulos anônimos e por ordem de chegada, não identidades: mapear speaker_2 para "João da equipe de vendas" é trabalho da aplicação, cruzando timestamps com metadados de reunião ou um modelo de verificação de locutor.

O modelo exige Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → com GPU NVIDIA Ampere, Hopper ou Blackwell, e aceita .wav, .flac, .opus e .mp3 em 16 kHz mono. Fora dessas condições, não há suporte documentado.

Para quem no Brasil isso importa de verdade

O caso de uso mais direto é qualquer produto que hoje já usa ASR e quer parar de entregar transcrição "em bloco único": atas de reunião automatizadas, análise de call center, moderação de podcast, ou memória de agente de voz que precisa saber "quem disse o quê" para manter contexto por participante. Como o modelo é open-weight e roda localmente via NeMo, ele também é opção para quem precisa manter áudio sensível (jurídico, saúde, financeiro) dentro da própria infraestrutura, sem mandar chamada para API externa, algo relevante para times brasileiros sob LGPD↳LGPD14 conteúdosComo utilizar a LGPD com o objetivo de conformidade e inovação?Gestão Dev & TI · out 2021LGPD coloca pressão inédita nos responsáveis pela tecnologia das empresasData · ago 2021Proteção de dados: LGPD é sancionada e começa a valerData · set 2020Ver tudo em Gestão Dev & TI → que hoje dependem de serviços de diarização em nuvem de terceiros.

A fonte também cita a Argmax, que já integrou o Nemotron 3 Diarization ao Argmax Pro SDK 3 para rodar diarização em tempo real on-device, com uma API de pré-diarização que separa os falantes antes de rodar o ASR. Segundo Atila Orhon, da Argmax, em benchmark próprio com o OpenBench cobrindo 11 datasets, o modelo teve o menor DER entre 6 sistemas avaliados, com erro cerca de 60% menor que o do Sortformer v2.1 anterior, um dado de terceiro, vale registrar, não medido pela NVIDIA.

Onde não vale a pena

O limite de oito falantes é real: no DIHARD III, a categoria que agrupa de cinco a nove falantes inclui áudio fora do range suportado, o que distorce a leitura desse número específico. Conversas maiores que isso (painéis, webinars com plateia aberta) ficam fora do escopo documentado. Também vale lembrar que o ganho de acurácia é mais tímido em conversas simples de dois falantes, onde o modelo anterior já ia bem, então a decisão de migrar precisa pesar o esforço de troca contra o ganho real esperado para o seu caso. E, como o próprio material frisa, os rótulos de canal não são identidade: quem precisa de reconhecimento de locutor ("esta voz é a do cliente X") ainda precisa de uma camada extra de verificação por cima do que o Nemotron 3 entrega.

Fonte: Hugging Face Blog