A equipe Venus, do Ant Group, descreve no arXiv o Realtime-Venus, um sistema de interação full-duplex. A proposta coloca percepção contínua, controle conversacional, geração nativa de fala e delegação assíncrona de tarefas sob uma mesma linha do tempo causal.
São dois modelos de 9B treinados separadamente. O Realtime-Venus-Omni cuida da interação áudio-visual.
O Realtime-Venus-Audio, do diálogo falado.
Segundo os autores, a arquitetura de dois loops mantém a conversa ao vivo enquanto um harness executa trabalho em segundo plano. Os modelos lideram seis de oito benchmarks de vídeo avaliados, além de métricas de continuidade no Full-Duplex-Bench v1.5.
Tudo o que segue são afirmações dos autores, não resultados replicados de forma independente.
O que os autores propõem
A proposta central é tratar o modelo conversacional como um frontend completo, não apenas como um gerador de respostas.
Cada um dos dois modelos, construído sobre o MiniCPM-o 4.5, de Cui et al., 2026, acumula quatro funções. Perceber mídia continuamente, decidir quando escutar, falar ou ceder a vez, gerar fala de forma nativa (via arquitetura Thinker–Talker) e emitir pedidos privados de delegação para capacidades externas.
A inovação de formulação é alinhar, numa formulação de streaming unificada, observações do usuário, saídas do modelo, pedidos privados de delegação e resultados de background.
O frontend prevê conjuntamente tokens de controle de interação, texto de resposta e pedidos de delegação. Com isso, segundo os autores, a mesma política consegue manter uma resposta durante backchannels ("uhum", "certo"), revisar uma continuação ainda não falada depois de uma correção e iniciar trabalho em background quando o pedido exige capacidades externas.
Do lado da execução, o Realtime-Venus-Harness é apresentado como framework compartilhado. Ele ata cada pedido à sessão de origem e o compromete com um snapshot das evidências disponíveis no momento em que o pedido começou.
Os autores afirmam que o Realtime-Venus-Omni é o primeiro modelo omni full-duplex a suportar invocação assíncrona de backend para raciocínio e uso de ferramentas mantendo interação por vídeo. Com aumento de memória, dizem, suporta entendimento de vídeo em escala de horas.
O paper está em arXiv.org/abs/2609.13814.
Contexto: qual problema está sendo atacado
Interação natural exige interpretar observações em curso e decidir quando e como responder, inclusive sem pedido explícito.
O trabalho se posiciona entre Moshi (Défossez et al., 2024), que modela fluxos paralelos de fala, Qwen2.5-Omni e Qwen3-Omni (Xu et al., 2025a; 2025b), MiniCPM-o 4.5 (Cui et al., 2026) e uma linhagem de agentes falados com recuperação, chamadas de ferramenta e computação externa assíncrona. Nessa linhagem entram DuplexSLA (Zhang et al., 2026), MoshiRAG (Chien et al., 2026), DuplexOmni (Huang et al., 2026), GPT-Realtime (OpenAI, 2025) e NemotronLabs VoiceChat (NVIDIA, 2026).
O diagnóstico dos autores é preciso: interação contínua e computação externa operam em escalas de tempo diferentes dentro da mesma sessão.
Uma tarefa de background precisa de um registro estável do pedido e das evidências que o sustentam. Seu resultado, porém, precisa ser interpretado numa conversa que pode ter mudado durante a execução.
Coordenar a captura da tarefa com a entrega do resultado é o que mantém a coerência.
Há ainda o problema das interrupções graduadas. Backchannel, fala dirigida a terceiros e fala de fundo não deveriam ter o mesmo efeito sobre uma resposta em curso.
Como funciona
O runtime é organizado em dois loops.
O loop de interação é sensível à latência e roda continuamente. O frontend processa áudio (e vídeo, no caso do Omni) em chunks de um segundo, atualiza o estado retido da sessão e decide entre escutar, falar ou ceder.
A percepção permanece ativa enquanto o modelo fala e enquanto tarefas executam.
O loop de capacidade é ativado por um pedido privado em linguagem natural. O host esconde o trecho do pedido da saída visível ao usuário, captura o contexto disponível no limite do pedido, cria um item de trabalho assíncrono e o roteia para uma capacidade registrada.
O resultado volta como contexto privado, passa por checagens de atualidade (freshness) e por uma entrega ciente de playback, que governa quando ele pode reentrar na conversa.
A divisão de responsabilidades é explícita: o harness determina o conteúdo e a redação da resposta preparada; o frontend decide quando falar. É essa separação que permite que o resultado, embora calculado a partir de um snapshot antigo, seja adaptado a mudanças de intenção do usuário ocorridas no meio do caminho.
O treinamento depende de trajetórias que conectam eventos conversacionais a decisões de interação e execução delegada. O pipeline combina planejamento de cenários, realização de fala e alinhamento temporal.
Cenários duplex distinguem backchannels e fala dirigida a terceiros de interrupções que exigem parar, reparar ou redirecionar a resposta. Trajetórias proativas supervisionam quando iniciar uma resposta e quando continuar apenas escutando.
Cenários de delegação ligam pedidos privados a execução em background, informação retornada e resposta subsequente.
Sobre isso, os autores aplicam uma receita compartilhada de pós-treino que mistura compreensão offline, interação duplex proativa e fluxos de delegação. O Omni usa dados áudio-visuais e só-áudio, o Audio usa apenas o subconjunto sonoro.
A página do projeto com demonstrações está em realtime-venus.GitHub.io.
Resultados reportados
Em vídeo, o Realtime-Venus-Omni alcança a maior pontuação entre os modelos online avaliados em seis de oito benchmarks. Inclui StreamingBench (70,2%), OVO-Bench (64,7%) e Daily-Omni (81,3%).
Em áudio, o Realtime-Venus-Audio lidera as comparações em MMAU (78,0%), MMAU-Pro (63,2%), Llama Questions (83,8%) e Speech CMMLU (67,8%). Empata com a melhor marca de VoiceBench AlpacaEval, com 4,81.
No Full-Duplex-Bench v1.5, o modelo responde a 75% das interrupções do usuário. Apresenta taxas de continuação de 97%, 88% e 86% em backchannels, fala dirigida a terceiros e fala de fundo, respectivamente.
Fica acima de Gemini 3.1 Live e GPT-4o nas três métricas de continuação.
Os autores também relatam avaliações complementares de uso de ferramentas e de decisão de delegação. Elas separam o roteamento correto da conclusão bem-sucedida da tarefa.
Limitações e o que não foi provado
O material disponível não traz uma seção de limitações detalhada, o que por si só limita o escrutínio.
O recorte de comparação é definido pelos autores: as vitórias valem "entre os modelos online avaliados", e os números dos concorrentes não aparecem no extrato. Saber contra o que exatamente se compara é parte da interpretação.
Também não há, no material, informação sobre venue ou revisão por pares, nem sobre latência fim a fim, custo computacional, hardware de inferência ou o impacto real do aumento de memória no entendimento de vídeo em escala de horas.
O harness é descrito em termos arquiteturais e qualitativos, sem métricas de vazão ou de taxa de falha. Os próprios autores registram que as avaliações de delegação identificam desafios na execução de trabalho externo durante a conversa.
Decidir delegar corretamente não garante executar corretamente.
Nada no material indica avaliação em português ou em cenários multilíngues. Também não discute implicações de privacidade e auditoria de um pedido de delegação que é, por construção, oculto da saída visível ao usuário.
Por que isso importa para quem constrói com IA
O padrão arquitetural é a parte mais reaproveitável.
Separar um loop de interação sensível à latência de um loop de capacidade de longa duração resolve um problema que aparece em qualquer produto de voz ou vídeo: o tempo do modelo conversacional e o tempo das ferramentas não são o mesmo. Fixar as evidências no limite do pedido, em vez de deixar a tarefa ler um contexto que muda embaixo dela, é uma decisão de engenharia que reduz uma classe inteira de bugs de coerência.
A segunda lição é a granularidade do controle conversacional. Tratar backchannel, fala dirigida a terceiros e interrupção real como fenômenos distintos, e medir isso com métricas de continuação, é um avanço em relação a avaliar apenas turnos limpos.
Para times que constroem assistentes por voz, isso aproxima os benchmarks do que o usuário percebe como naturalidade.
O ponto de atenção é o custo de operar dois loops com um harness. A divisão entre "quem decide quando falar" e "quem decide o que dizer" precisa de contratos claros, ou o resultado assíncrono chega fora de hora.
Os autores propõem essa interface, mas o material não quantifica o preço em latência e complexidade.
Para quem projeta agentes multimodais em tempo real, o Realtime-Venus é uma referência de desenho. E um lembrete de que a parte difícil não é perceber, é decidir quando agir.
Referências
- Venus Team, Ant Group. Realtime-Venus: A full-duplex interaction system with asynchronous delegation. arXiv:2609.13814, 2026. Disponível em arXiv.org/abs/2609.13814.
- Página do projeto Realtime-Venus: realtime-venus.GitHub.io.
- Trabalhos citados pelos autores e relevantes ao contexto: Cui et al., 2026 (MiniCPM-o 4.5); Défossez et al., 2024 (Moshi); Xu et al., 2025a e 2025b (Qwen2.5-Omni e Qwen3-Omni); Zhang et al., 2026 (DuplexSLA); Chien et al., 2026 (MoshiRAG); Huang et al., 2026 (DuplexOmni); OpenAI, 2025 (GPT-Realtime); NVIDIA, 2026 (NemotronLabs VoiceChat).
