VibeVoice-ASR-Streaming-1.5B vs Gemini 3.5 Transcribe: el discreto ASR de streaming de Microsoft contra la nueva API de Google

Siete días y una división filosófica separan a los dos sistemas más nuevos de conversión de voz a texto en streaming. El 26 de agosto de 2026, Google puso Gemini 3.5 Transcribe en vista previa pública: una API de voz a texto alojada y cerrada, con precio por token de audio y un endpoint Live separado para sesiones en tiempo real. El 2 de septiembre de 2026, Microsoft Research subió VibeVoice-ASR-Streaming-1.5B a Hugging Face bajo el espacio de nombres microsoft: pesos con licencia MIT, sin comunicado de prensa, sin publicación de lanzamiento y, al momento de escribir esto, sin cobertura de terceros en ningún sitio. Ambos transcriben el habla mientras esta llega. Casi todo lo demás sobre ellos —quién puede ejecutarlos, cuánto cuestan, qué evidencia existe de que funcionan— es diferente.

Esta página compara los dos tal como existen realmente hoy, lo que significa que los dos lados de la evidencia no son simétricos. Gemini 3.5 Transcribe es un producto de Google en producción con precios de token publicados y cifras de precisión de terceros de Artificial Analysis; esos son los números etiquetados como AA más abajo. VibeVoice-ASR-Streaming-1.5B es un checkpoint cuya ficha de modelo no publica por escrito ninguna tasa de error de palabras ni cifra de latencia; la evaluación de la ficha es una imagen, y el único anuncio de la familia de streaming hasta ahora es una línea de novedades fechada el 3 de septiembre en el repositorio de GitHub de VibeVoice de Microsoft. Todo lo que se muestra a continuación sobre el lado de Microsoft es lo que se puede saber a partir del repositorio: los archivos de configuración, la ficha del modelo y la documentación de streaming de Microsoft. Nada de ello se ha sometido todavía a benchmarks independientes.

Los dos modelos de un vistazo

• Qué es — VibeVoice-ASR-Streaming-1.5B: checkpoint abierto, licencia MIT, autohospedado vs Gemini 3.5 Transcribe: API alojada, pesos cerrados.

• Lanzamiento — pesos el 2 de septiembre de 2026, línea de noticias del repositorio el 3 de septiembre frente a la vista previa pública del 26 de agosto de 2026 con materiales completos de lanzamiento.

• Forma de streaming — emite texto en fragmentos de ~2,9 segundos con ~0,5 s de anticipación; el estado de la sesión se almacena en una caché de prefijo, a diferencia de la sesión en vivo de WebSocket, que se factura por token de audio y está limitada a 10 minutos de audio por sesión.

• Precisión impresa: no se publicó ninguna cifra de WER ni de latencia como texto; AA midió un 2,6 % de WER en el endpoint pregrabado y un 4,0 % en el endpoint en vivo.

• Salida de hablantes: afirma atribución de quién dijo qué en streaming (no verificada) frente a la ausencia de diarización de hablantes y de marcas de tiempo a nivel de palabra en el endpoint Live.

• Hotwords: admitidos, a través del mismo prompt de contexto que el batch VibeVoice-ASR; no son una función listada del endpoint Live.

• Costo — $0 por los pesos, ~5.6 GB para autoalojar, frente a aproximadamente $0.30 por hora de audio (tarifa combinada) en el endpoint pregrabado y ~$0.54 en Live, según los precios por token listados por Google.

Una API alojada y una subida silenciosa, con siete días de diferencia.

Gemini 3.5 Transcribe es el modelo de transcripción de reemplazo de Google y se comercializa como dos productos. El endpoint de pregrabado, que se sirve a través de la API de Interactions, toma un archivo de audio completo y devuelve una transcripción con los extras esperados. El endpoint en vivo, gemini-3.5-transcribe-live, se ejecuta sobre un WebSocket bidireccional y es el que compite con VibeVoice-ASR-Streaming-1.5B en cuanto al tipo de tarea: transcribir una sesión a medida que ocurre. Google lo anunció con el mecanismo habitual — un lanzamiento en vista previa pública el 26 de agosto, precios en la página del modelo y tablas de clasificación de terceros que lo adoptaron a los pocos días.

El lanzamiento en streaming de Microsoft no tuvo nada de eso. El 2 de septiembre, la cuenta de Microsoft en Hugging Face creó dos checkpoints en el mismo minuto: VibeVoice-ASR-Streaming-7B y VibeVoice-ASR-Streaming-1.5B. La tabla de modelos del repositorio de GitHub ahora lista a VibeVoice-ASR-Streaming como miembro de la familia, y su sección de Noticias incluye el anuncio del 3 de septiembre en el que se presenta «un modelo ASR de streaming unificado que transcribe continuamente quién dijo qué a medida que llega el habla, con soporte para hotwords personalizadas y 10 idiomas», pero ese anuncio menciona el de 7B, mientras que el de 1.5B es el hermano menor que se lanzó junto con él sin ser mencionado. Cuando lo comprobamos un día después de la subida, ambos checkpoints seguían mostrando cero descargas.

Qué significa "streaming" en cada lado

La palabra streaming esconde una diferencia de diseño real. La configuración del preprocesador de Microsoft hace concreta la cadencia de VibeVoice: el audio llega a 24 kHz y se comprime 3.200× en un flujo de tokens de habla a unos 7,5 Hz (un token cada ~133 ms). La configuración declara entonces un fragmento de 22 tramas y un lookahead de 4 tramas: unos 2,9 segundos de audio por fragmento, con aproximadamente medio segundo de audio futuro utilizado para consolidar el segmento actual. El modelo emite texto una vez por cada fragmento resuelto, y la documentación de Microsoft señala que el contexto de los fragmentos anteriores se conserva mediante la caché KV, por lo que una sesión larga no vuelve a calcular todo desde cero. La aritmética está en la configuración; la consecuencia práctica es una transcripción que crece en incrementos de unos tres segundos, no en parciales palabra por palabra.

El endpoint Live de Google es una forma de streaming diferente: una sesión WebSocket bidireccional en la que el audio se factura a 25 tokens de audio por segundo, diseñada para uso interactivo, pero limitada a 10 minutos de audio por sesión y — específicamente en el endpoint Live — sin diarización de hablantes ni marcas de tiempo a nivel de palabra. Para cualquiera que compare ambos como motores de transcripción en vivo, las diferencias que importan son el límite de sesión (10 minutos en el lado Live de Google, limitado solo por tu propia GPU y memoria en el lado de Microsoft), la cadencia de emisión (fragmentos de ~3 segundos frente a lo que entregue la sesión WebSocket) y los extras de salida (atribución de hablante y hotwords declarados en la tarjeta de Microsoft, ausentes en la lista de funciones de Google Live).

Precisión: un lado tiene números, el otro tiene una imagen.

Esta es la brecha más amplia del enfrentamiento, y es una brecha en la evidencia, no necesariamente en la calidad. Artificial Analysis mide Gemini 3.5 Transcribe con una tasa de error de palabras del 2,6% en el endpoint pregrabado y del 4,0% en el endpoint en vivo: la prima que se paga por la entrega en tiempo real se refleja en la tasa de error, que es una compensación común y honesta para los sistemas de streaming. Esos son números de terceros en una tabla de clasificación neutral, publicados días después del lanzamiento.

VibeVoice-ASR-Streaming-1.5B no tiene ninguna cifra comparable en ningún sitio. La tarjeta del modelo incluye una figura de resultados de evaluación como imagen, pero ningún WER, RTF o latencia numéricos en texto: nada citable ni verificable de forma independiente. Microsoft no ha publicado cifras de precisión de streaming en texto ni para el 7B ni para el 1.5B. El único anclaje numérico de toda la familia es la tarjeta del modelo por lotes VibeVoice-ASR, que informa de un WER medio del 7,77 % en ocho conjuntos de prueba en inglés y del 2,20 % en LibriSpeech clean, pero eso describe el modelo no streaming, y los modelos de streaming normalmente sacrifican algo de precisión para ganar latencia. Hasta que alguien ejecute el checkpoint de streaming en un marco de evaluación público, la postura honesta es que el modelo de Google está medido y el de Microsoft no.

Costo: por hora de audio frente a por hora de GPU

Google vende Gemini 3.5 Transcribe por token, y los precios se dividen claramente entre los dos endpoints. El endpoint pregrabado lista $2 por 1M de tokens de audio de entrada y $12 por 1M de tokens de texto de salida, lo que equivale a aproximadamente $0.30 por hora de audio combinada. El endpoint en vivo lista $3.50 por 1M de tokens de audio y $21 por 1M de tokens de texto: alrededor de $0.54 por hora de audio combinada, o aproximadamente un 80 % más que el pregrabado, que es el precio de la entrega en tiempo real. Google factura el audio a 25 tokens por segundo, por lo que el silencio solo es gratis si tu cliente no lo transmite; las reconexiones, el audio duplicado y el registro pueden aumentar la factura real. Existe un nivel gratuito, con la salvedad de que el contenido del nivel gratuito puede utilizarse para mejorar los productos de Google.

El modelo de Microsoft, en cambio, se cobra por horas de GPU. El checkpoint de 1.5B equivale aproximadamente a 5,6 GB de pesos en bf16 (un backbone de lenguaje Qwen de 1.5B, más los tokenizadores de audio y la cabeza de difusión; los metadatos de safetensors suman unos 3B de parámetros), y las vías documentadas para ejecutarlo consisten en autoalojarlo: los demos de Python del repositorio microsoft/VibeVoice o el plugin de vLLM descrito por Microsoft para servir endpoints compatibles con OpenAI y WebSocket. De momento no hay un precio para un servicio alojado, ya que ningún proveedor de inferencia ofrece el modelo. La cuestión del costo se reduce enteramente a si tu propio tiempo de GPU es más barato que la tarifa por hora de Google, lo cual, para cualquier volumen sostenido de transcripción, casi con seguridad es así. La cuestión de la licencia, por su parte, es independiente de la cuestión del costo, porque puedes conservar los pesos con licencia MIT, algo que ninguna suscripción a una API te permite.

Los dos no son mutuamente excluyentes en una pila de producción. El patrón pragmático para un equipo que necesita transcripción en vivo hoy es mantener la capa de ASR detrás de un único endpoint para que la elección siga siendo reversible: una API de enrutamiento que da acceso a más de 200 modelos a los precios de lista del proveedor —sin margen, por lo que un cambio de precio del proveedor se aplica el mismo día— con conmutación por error automática, es exactamente la capa que te permite ejecutar la API de Google con medición de uso como predeterminada mientras una parte del tráfico real prueba VibeVoice-ASR-Streaming-1.5B en cuanto un proveedor la aloja. Ese es el modelo de OrcaRouter, y es la forma de bajo riesgo de adoptar un checkpoint cuya precisión nadie ha verificado todavía.

Quién debería elegir cuál

Elige Gemini 3.5 Transcribe si quieres una API de transcripción que funcione hoy, con precisión publicada, precios predecibles por hora y sin GPU que vigilar — y especialmente si tu audio no está dentro de los diez idiomas que Microsoft enumera, o si necesitas la diarización del endpoint pregrabado y las marcas de tiempo a nivel de palabra para la transcripción de archivos. El límite de sesión en vivo de 10 minutos es una restricción real que debes probar contra tu caso de uso antes de comprometerte con él para sesiones en vivo.

Elige VibeVoice-ASR-Streaming-1.5B si lo alojas tú mismo, si quieres los pesos y el control de datos que ofrece MIT, si necesitas una duración de sesión ilimitada, o si la salida de streaming de quién dijo qué y las hotwords son características que específicamente quieres evaluar. Presupuesta una instalación desde el código fuente, ~5,6 GB de pesos en una GPU NVIDIA, y tu propio criterio de evaluación: no hay un benchmark en el que apoyarte, así que la cuestión de la precisión debes responderla con tu propio audio.

El veredicto de la primera semana: Google lanzó el producto medido y Microsoft lanzó la apuesta interesante. Gemini 3.5 Transcribe es la opción por defecto más segura y la que tiene cifras de terceros que la respaldan; VibeVoice-ASR-Streaming-1.5B es la alternativa abierta, autoalojable y completamente sin verificar. Lo que hace que la elección sea barata es que no tiene que ser permanente: mantén el endpoint de ASR intercambiable, y un checkpoint que se lanza sin un solo benchmark puede ganarse o perder tu tráfico con la evidencia de tus propias transcripciones.