VibeVoice-ASR-Streaming-7B vs Gemini 3.5 Transcribe Live: Uma Semana, Dois Tipos de Transcrição de Fala em Streaming

A última semana de agosto e os primeiros dias de setembro de 2026 trouxeram dois sistemas de fala para texto em streaming que parecem concorrentes e são, na verdade, respostas diferentes para a mesma pergunta. Em 26 de agosto, o Google colocou o Gemini 3.5 Transcribe Live em prévia pública: um endpoint de fala para texto hospedado e fechado que retorna uma transcrição finalizada 0,40 segundo depois que o falante para de falar, respaldado por uma taxa de erro de palavras em streaming de 4,0%, medida pela Artificial Analysis, e por um pacote completo de materiais de lançamento. Em 2 de setembro, a Microsoft Research enviou o VibeVoice-ASR-Streaming-7B para o Hugging Face sob o namespace microsoft: pesos abertos licenciados sob MIT, sem comunicado à imprensa, sem página de lançamento e um model card que não publica taxa de erro de palavras nem valor de latência em texto legível. Ambos aceitam áudio enquanto ele ainda está chegando. Isso é quase a única coisa que compartilham.

As evidências dos dois lados não são simétricas, então esta comparação é escrita como o que sabemos até agora. O Gemini 3.5 Transcribe Live é um produto do Google com preços de token publicados e medições de terceiros, e esses estão rotulados abaixo. O VibeVoice-ASR-Streaming-7B é um checkpoint cujas afirmações são lidas diretamente do próprio repositório: os arquivos de configuração, a ficha do modelo e a documentação de streaming da Microsoft no repositório VibeVoice no GitHub. Nada do lado da Microsoft foi avaliado de forma independente ainda, e dizemos isso sempre que um número pareceria estar fazendo trabalho.

A trilha do lançamento: um lançamento de API e um upload silencioso

A Google lançou o Gemini 3.5 Transcribe Live da forma normal. O modelo fica sob o guarda-chuva do Gemini Audio, ao lado do irmão Gemini 3.5 Transcribe (o caminho da API Interactions para pré-gravações); os preços estão na página do modelo, e rankings independentes incluíram o endpoint Live em poucos dias — é daí que vêm os 4,0% de WER em streaming e a latência final de 0,40 segundo. Existe um nível gratuito, com a ressalva usual de que o conteúdo do nível gratuito pode ser usado para melhorar os produtos do Google.

O lançamento de streaming da Microsoft não tinha toda essa maquinaria. O repositório microsoft/VibeVoice-ASR-Streaming-7B no Hugging Face foi criado em 2026-09-02 às 15:46 UTC e modificado pela última vez três minutos depois; ele contém oito shards safetensors, um tokenizador e uma configuração de pré-processador sob licença MIT. O registro formal é uma linha de changelog datada de 3 de setembro no repositório microsoft/VibeVoice, anunciando "um modelo de ASR unificado em streaming que transcreve continuamente quem disse o quê à medida que a fala chega, com suporte a hotwords personalizadas e 10 idiomas", com links para uma demo em aka.ms/vibeasr e um relatório técnico de streaming. Quando verificamos um dia após o upload, o checkpoint ainda mostrava zero downloads, e nenhum provedor de inferência hospedado o lista. O model card diz mais do que o anúncio, e o repositório é a fonte de quase tudo abaixo.

As especificações, lado a lado

• O que é — VibeVoice-ASR-Streaming-7B: ASR de streaming de pesos abertos, auto-hospedado vs Gemini 3.5 Transcribe Live: API de streaming hospedada, pesos fechados.

• Forma de streaming — emite texto em blocos de aproximadamente 2,9 segundos, com cerca de 0,5 segundo de antecipação (derivado da configuração do checkpoint) versus uma sessão bidirecional de WebSocket com transcrições parciais contínuas e um resultado final 0,40 segundo após o locutor parar.

• Precisão no material impresso — nenhum valor de WER ou latência publicado por escrito, versus 4,0% de WER em streaming e 2,6% no modelo pré-gravado, de acordo com a Artificial Analysis.

• Falantes — reivindica atribuição de quem disse o quê em streaming, não verificada, vs. sem diarização de falantes no endpoint Live (disponível no modelo pré-gravado, com até três falantes).

• Idiomas — 10 (en, zh, es, pt, de, ja, ko, fr, ru, it) vs detecção automática em 85+ idiomas, com alternância no meio do fluxo.

• Duração da sessão — limitada apenas pela sua GPU e memória, em vez de um limite rígido de 10 minutos por sessão ao vivo.

• Custo — $0 pelos pesos, cerca de 18 GB de bf16 para auto-hospedar vs aproximadamente $0,54 por hora de áudio no Live, contando os tokens de saída de texto.

O que "streaming" significa em cada lado

A palavra esconde uma diferença real de design, e vale a pena ser preciso, porque os dois sistemas nem sequer tentam produzir a mesma cadência. A configuração do pré-processador da Microsoft torna concreto o ritmo do VibeVoice: o áudio chega a 24 kHz e é comprimido 3.200× em um fluxo de tokens a cerca de 7,5 quadros por segundo; em seguida, a configuração declara um bloco de 22 quadros e uma antecedência de 4 quadros — cerca de 2,9 segundos de áudio por bloco, com aproximadamente meio segundo de áudio futuro para firmá-lo. O modelo emite texto uma vez por bloco resolvido, e o contexto dos blocos anteriores é preservado por meio do cache KV, de modo que uma sessão longa não recalcula do zero. A transcrição prática cresce em incrementos de aproximadamente três segundos.

O endpoint Live do Google é feito para um ciclo mais rápido e mais interativo: o áudio é transmitido por um WebSocket em blocos PCM de 16 ou 24 kHz, transcrições parciais retornam continuamente enquanto o locutor fala, e uma transcrição final formatada chega 0,40 segundo após o fim da fala — esse número é a medição da Artificial Analysis, citada pelo Google. As contrapartidas são o limite de sessão (dez minutos de áudio, após os quais seu aplicativo precisa se reconectar e costurar as partes) e os extras ausentes: sem diarização de locutores e sem timestamps em nível de palavra no caminho Live, ambos existentes no Transcribe Gemini 3.5 pré-gravado. O resumo sincero é que o modelo de streaming do Google é mais rápido por enunciado, enquanto o checkpoint de streaming da Microsoft é mais lento por bloco, mas oferece a atribuição de locutores que o caminho Live do Google descarta, em uma duração de sessão que o Google não oferece.

Precisão: medida, em comparação com um espaço em branco

A maior lacuna neste confronto é uma lacuna de evidências, não necessariamente de qualidade. A Artificial Analysis mediu o Gemini 3.5 Transcribe Live com uma taxa média de erro de palavras de 4,0% em streaming e 2,6% no modelo não-streaming; este último ficou em quinto lugar no ranking WER da empresa no lançamento. A Google, separadamente, cita 5,50% em streaming e 5,04% em não-streaming no conjunto multilíngue FLEURS. Leia esses números conforme eles são rotulados: a Artificial Analysis é independente do Google, mas os números de uma API com apenas um dia de existência ainda são preliminares, e o custo adicional do streaming em relação ao modelo em lote — 4,0% contra 2,6% — é o preço usual da entrega em tempo real.

VibeVoice-ASR-Streaming-7B não tem nenhuma métrica comparável em lugar nenhum. O model card do modelo traz uma figura de avaliação como imagem, e o relatório técnico da Microsoft é um PDF, mas nenhum dos dois oferece um número de WER de streaming ou de latência em texto simples que possa ser citado ou verificado de forma independente. A única âncora numérica em toda a família é o model card do VibeVoice-ASR em lote, que reporta uma média de 7,77% de WER medida pelo fornecedor em oito conjuntos de teste de inglês e 2,20% no LibriSpeech clean — valores do modelo não-streaming, não deste, e modelos de streaming normalmente trocam um pouco de precisão pela vantagem de latência. Até que alguém execute o checkpoint de streaming em uma estrutura pública de avaliação, a afirmação justa é que um lado dessa comparação é medido e o outro não.

Custo: uma API por consumo versus uma GPU que você já orçou

O Google precifica o Gemini 3.5 Transcribe Live por token e cobra o áudio a 25 tokens por segundo. Nas tarifas Live publicadas — US$ 3,50 por 1 milhão de tokens de áudio e US$ 21 por 1 milhão de tokens de saída de texto — uma hora de áudio combinada chega a aproximadamente US$ 0,54, cerca de US$ 9 por 1.000 minutos de áudio, e o modelo pré-gravado é ainda mais barato, a aproximadamente US$ 0,30 por hora. O silêncio só é gratuito se o seu cliente não o transmitir em fluxo contínuo: reconexões, áudio duplicado e registro em log adicionam tokens medidos à fatura real.

O checkpoint da Microsoft é precificado em horas de GPU. Somente os pesos bf16 ocupam cerca de 18 GB antes de qualquer cache KV, os caminhos documentados são as demonstrações em Python no repositório microsoft/VibeVoice e um plugin vLLM que serve endpoints compatíveis com WebSocket e OpenAI, e não há preço hospedado porque nenhum provedor hospeda o modelo ainda — ele não está no Azure AI Foundry como o batch VibeVoice-ASR está desde março. Hospedar por conta própria um speech-LLM da classe 7B significa reservar uma GPU da classe 24 GB e seu próprio tempo de operação; em troca, você tem duração de sessão ilimitada e pesos que são seus para manter. Os dois modelos não são mutuamente exclusivos, que é o objetivo da última seção.

Mantendo a escolha barata

Qual você escolhe depende de se precisa de um número ou de um código. Escolha o Gemini 3.5 Transcribe Live quando quiser transcrição que funcione hoje, com precisão publicada e sem GPU para executar — e quando o seu áudio não estiver limitado a dez idiomas, ou se você estiver preparado para construir a rotulação de falantes por conta própria, porque o endpoint Live não a fornece. Escolha o VibeVoice-ASR-Streaming-7B quando você fizer self-hosting, quando a duração ilimitada de sessão ou a alegada saída de streaming com atribuição de falantes for importante, e quando estiver disposto a executar sua própria etapa de avaliação, porque não há benchmark em que se apoiar.

Nenhuma escolha precisa ser permanente, e é aí que uma camada de roteamento mostra seu valor — para os modelos em torno da transcrição, não para a transcrição em si. O OrcaRouter não faz roteamento de fala para texto atualmente, e nenhum dos modelos desta página está em seu catálogo; o que ele faz é dar acesso, por uma única API, aos mais de 200 modelos de linguagem que consomem uma transcrição ao vivo — o resumidor, o extrator de itens de ação, o planejador do agente de voz — a preços de tabela dos provedores, repassados sem margem, com failover automático entre eles. Um corte de preço de um fornecedor em qualquer modelo dessa pilha entra em vigor no mesmo dia, porque os preços de tabela são repassados, e não acrescidos de margem. A etapa de transcrição permanece onde você a colocou; a pilha que age sobre a transcrição é exatamente a camada em que uma única chave e uma rota de contingência transformam um checkpoint de uma semana, sem benchmark, de uma aposta em uma opção testável.