VibeVoice-ASR-Streaming-1.5B vs Gemini 3.5 Transcribe: o discreto ASR de streaming da Microsoft contra a nova API do Google

Sete dias e uma divisão filosófica separam os dois mais recentes sistemas de transcrição de fala em streaming. Em 26 de agosto de 2026, o Google colocou o Gemini 3.5 Transcribe em pré-visualização pública: uma API de transcrição de fala hospedada e de código fechado, com preço por token de áudio e um endpoint Live separado para sessões em tempo real. Em 2 de setembro de 2026, a Microsoft Research disponibilizou o VibeVoice-ASR-Streaming-1.5B no Hugging Face sob o namespace microsoft — com pesos sob licença MIT, sem comunicado à imprensa, sem publicação de lançamento e, no momento em que este texto foi escrito, sem nenhuma cobertura de terceiros em lugar algum. Ambos transcrevem a fala enquanto ela ainda está chegando. Quase todo o resto sobre eles — quem tem permissão para executá-los, quanto custam, que evidências existem de que funcionam — é diferente.

Esta página compara os dois como eles realmente existem hoje, o que significa que os dois lados das evidências não são simétricos. O Gemini 3.5 Transcribe é um produto ativo do Google, com preços de token publicados e números de precisão de terceiros da Artificial Analysis; esses são os números rotulados como AA abaixo. O VibeVoice-ASR-Streaming-1.5B é um checkpoint cuja ficha do modelo não publica taxa de erro de palavras nem nenhum valor de latência em texto — a avaliação da ficha é uma imagem, e o único anúncio da família de streaming até agora é uma nota datada de 3 de setembro no repositório VibeVoice da Microsoft no GitHub. Tudo no lado da Microsoft abaixo é o que é possível saber a partir do repositório: os arquivos de configuração, a ficha do modelo e a documentação de streaming da própria Microsoft. Nada sobre ele foi submetido a benchmark independente até agora.

Os dois modelos num relance

• O que é — VibeVoice-ASR-Streaming-1.5B: checkpoint aberto, licença MIT, auto-hospedado vs Gemini 3.5 Transcribe: API hospedada, pesos fechados.

• Release — pesos em 2 de setembro de 2026, linha de notícias do repositório em 3 de setembro vs. prévia pública em 26 de agosto de 2026 com materiais completos de lançamento.

• Formato de streaming — emite texto em blocos de ~2,9 segundos com ~0,5 s de lookahead, com o estado da sessão mantido em cache de prefixo, vs. sessão WebSocket Live cobrada por token de áudio, limitada a 10 minutos de áudio por sessão.

Precisão na impressão — nenhum valor de WER ou latência publicado como texto versus os 2,6% de WER medidos pela AA no endpoint pré-gravado e 4,0% no endpoint Live.

• Saída do locutor — alega atribuição de quem disse o quê em streaming (não verificado) vs. sem diarização de locutores e sem timestamps em nível de palavra no endpoint Live.

• Hotwords — compatível, através do mesmo prompt de contexto do VibeVoice-ASR em lote, vs não ser um recurso listado do endpoint Live.

• Custo — $0 pelos pesos, ~5,6 GB para auto-hospedagem versus aproximadamente $0,30 por hora de áudio combinado no endpoint pré-gravado e ~$0,54 no Live, de acordo com os preços por token listados pelo Google.

Uma API hospedada e um upload silencioso, separados por sete dias

Gemini 3.5 Transcribe é o modelo de transcrição de nível substituto do Google, e ele é lançado como dois produtos. O endpoint pré-gravado, servido por meio da Interactions API, recebe um arquivo de áudio completo e retorna uma transcrição com os extras esperados. O endpoint Live, gemini-3.5-transcribe-live, opera sobre um WebSocket bidirecional e é o que compete com o VibeVoice-ASR-Streaming-1.5B no formato da tarefa: transcrever uma sessão em tempo real. O Google o anunciou com o mecanismo habitual — um lançamento em pré-visualização pública em 26 de agosto, preços na página do modelo e rankings de terceiros adotando-o em poucos dias.

O lançamento de streaming da Microsoft não teve nada disso. Em 2 de setembro, a conta da Microsoft no Hugging Face criou dois checkpoints no mesmo minuto: VibeVoice-ASR-Streaming-7B e VibeVoice-ASR-Streaming-1.5B. A tabela de modelos do repositório do GitHub agora lista VibeVoice-ASR-Streaming como membro da família, e sua seção de Notícias traz a linha de 3 de setembro anunciando "um modelo ASR de streaming unificado que transcreve continuamente quem disse o que à medida que a fala chega, com suporte para hotwords personalizadas e 10 idiomas" — mas esse anúncio menciona o 7B, e o 1.5B é o irmão menor que foi lançado junto sem ser destacado. Quando verificamos um dia após o upload, ambos os checkpoints ainda mostravam zero downloads.

O que "streaming" significa em cada lado

A palavra streaming esconde uma diferença real de design. A configuração do pré-processador da Microsoft torna a cadência do VibeVoice concreta: o áudio chega a 24 kHz e é comprimido 3.200× em um fluxo de tokens de fala a cerca de 7,5 Hz (um token a cada ~133 ms). A configuração então declara um bloco de 22 quadros e uma antecipação de 4 quadros — cerca de 2,9 segundos de áudio por bloco, com aproximadamente meio segundo de áudio futuro usado para consolidar o segmento atual. O modelo emite texto uma vez por bloco resolvido, e a documentação da Microsoft observa que o contexto de blocos anteriores é preservado por meio do cache KV, de modo que uma sessão longa não recomeça do zero. A aritmética está na configuração; a consequência prática é uma transcrição que cresce em incrementos de aproximadamente três segundos, não em parciais palavra por palavra.

O endpoint Live do Google é um formato de streaming diferente: uma sessão WebSocket bidirecional em que o áudio é cobrado a 25 tokens de áudio por segundo, projetado para uso interativo, mas limitado a 10 minutos de áudio por sessão e — especificamente no endpoint Live — sem diarização de locutores ou timestamps em nível de palavra. Para quem compara os dois como mecanismos de transcrição ao vivo, as diferenças que importam são o limite de sessão (10 minutos no lado do Google Live, limitado apenas pela sua própria GPU e memória no lado da Microsoft), a cadência de emissão (blocos de ~3 segundos versus o que a sessão WebSocket entregar) e os extras de saída (atribuição de locutor e hotwords anunciados no cartão da Microsoft, ausentes na lista de recursos do Google Live).

Precisão: um lado tem números, o outro tem uma imagem.

Esta é a maior lacuna na comparação, e é uma lacuna em evidência, não necessariamente em qualidade. A Artificial Analysis mede o Gemini 3.5 Transcribe com uma taxa de erro de palavras de 2,6% no endpoint pré-gravado e 4,0% no endpoint Live — o preço extra que você paga pela entrega em tempo real se reflete na taxa de erro, o que é um trade-off comum e honesto para sistemas de streaming. Esses são números de terceiros em um leaderboard neutro, publicados dias após o lançamento.

O VibeVoice-ASR-Streaming-1.5B não tem nenhum número comparável em lugar algum. A ficha técnica do modelo traz uma figura com os resultados da avaliação como imagem, mas nenhum WER, RTF ou latência numéricos em texto — nada citável e nada verificável de forma independente. A Microsoft não publicou números de precisão de streaming em texto, nem para o modelo 7B nem para o 1.5B. A única âncora numérica de toda a família é a ficha técnica do modelo em lote VibeVoice-ASR, que reporta uma média de 7,77% de WER calculada pelo fornecedor em oito conjuntos de teste em inglês e 2,20% no LibriSpeech clean — mas isso descreve o modelo não-streaming, e modelos de streaming normalmente trocam um pouco de precisão pelo ganho de latência. Até que alguém execute o checkpoint de streaming em um harness público, a posição honesta é que o modelo do Google foi medido e o da Microsoft não foi.

Custo: por hora de áudio versus por hora de GPU

O Google vende o Gemini 3.5 Transcribe por token, e o preço se divide claramente entre os dois endpoints. O endpoint pré-gravado tem o preço de US$ 2 por 1M de tokens de áudio de entrada e US$ 12 por 1M de tokens de texto de saída, o que representa cerca de US$ 0,30 por hora de áudio combinada. O endpoint ao vivo tem o preço de US$ 3,50 por 1M de tokens de áudio e US$ 21 por 1M de tokens de texto — cerca de US$ 0,54 por hora de áudio combinada, ou aproximadamente 80% a mais do que o pré-gravado, que é o preço da entrega em tempo real. O Google cobra o áudio a 25 tokens por segundo, então o silêncio só é gratuito se o seu cliente não o transmitir; reconexões, áudio duplicado e registro de logs podem aumentar a conta real. Existe um nível gratuito, com a ressalva de que o conteúdo do nível gratuito pode ser usado para melhorar os produtos do Google.

Já o modelo da Microsoft é precificado em horas de GPU. O checkpoint de 1.5B corresponde a cerca de 5.6 GB de pesos bf16 (um backbone de linguagem Qwen da classe 1.5B, mais os tokenizadores de áudio e o head de difusão — os metadados do safetensors somam cerca de 3B parâmetros), e os caminhos documentados para executá-lo são auto-hospedados: as demos em Python no repositório microsoft/VibeVoice, ou o plugin vLLM que a Microsoft descreve para servir endpoints compatíveis com OpenAI e WebSocket. Ainda não há preço de hospedagem, porque nenhum provedor de inferência lista o modelo até agora. A questão de custo se resume inteiramente a saber se o seu próprio tempo de GPU é mais barato do que a taxa por hora do Google — o que, para qualquer volume sustentado de transcrição, quase certamente é — e a questão da licença é separada da questão de custo, porque os pesos MIT ficam com você de uma forma que nenhuma assinatura de API fica.

Os dois não são mutuamente exclusivos em uma stack de produção. O padrão pragmático para uma equipe que precisa de transcrição em tempo real hoje é manter a camada de ASR atrás de um único endpoint para que a escolha permaneça reversível: uma API de roteamento que atende mais de 200 modelos aos preços de tabela dos provedores — sem acréscimo, de modo que uma alteração de preço do fornecedor entre em vigor no mesmo dia — com failover automático, é exatamente a camada que permite rodar a API do Google com uso medido como padrão enquanto uma fatia do tráfego real testa o VibeVoice-ASR-Streaming-1.5B assim que um provedor o hospedar. Esse é o modelo da OrcaRouter, e é a forma de baixo risco de adotar um checkpoint cuja acurácia ninguém verificou até agora.

Quem deve escolher qual

Escolha o Gemini 3.5 Transcribe se você quiser uma API de transcrição que funcione hoje, com precisão publicada, preço previsível por hora e sem GPU para monitorar — e especialmente se o seu áudio não estiver entre os dez idiomas listados pela Microsoft, ou se você precisar da diarização do endpoint pré-gravado e de carimbos de tempo em nível de palavra para transcrição de arquivos. O limite de 10 minutos da sessão ao vivo é uma restrição real que você deve testar contra o seu caso de uso antes de se comprometer com ele para sessões ao vivo.

Escolha o VibeVoice-ASR-Streaming-1.5B se você fizer auto-hospedagem, se quiser os pesos e o controle sobre os dados que a licença MIT oferece, se precisar de duração de sessão ilimitada, ou se a saída de streaming que indica quem disse o quê e os hotwords forem recursos que você deseja especificamente avaliar. Preveja uma instalação a partir do código-fonte, ~5,6 GB de pesos em uma GPU NVIDIA e seu próprio processo de avaliação — não há benchmark em que se apoiar, então a questão da precisão cabe a você responder com seu próprio áudio.

O veredito da primeira semana: o Google lançou o produto comedido e a Microsoft lançou a aposta interessante. O Gemini 3.5 Transcribe é a opção padrão mais segura e a que tem números de terceiros por trás; o VibeVoice-ASR-Streaming-1.5B é a alternativa aberta, auto-hospedável e totalmente não verificada. O que torna a escolha barata é que ela não precisa ser permanente — mantenha o endpoint de ASR substituível, e um checkpoint lançado sem um único benchmark pode ganhar ou perder seu tráfego com base nas evidências das suas próprias transcrições.