Realtime-Venus: voz full-dúplex 9B que delega en segundo plano
Realtime-Venus: voz full-dúplex 9B que delega en segundo plano — lo que el abstract no cuenta
TL;DR
- Verificado contra el HTML v2 del paper (arXiv 2609.13814, Venus Team de Ant Group + Tsinghua; abstract consultado el 04/10/2026): el titular “supera a Gemini 3.1 Live y GPT-4o en Full-Duplex-Bench v1.5” es cierto y está incompleto. Venus-Audio gana en continuidad —seguir hablando pese a backchannels o habla ajena— con 0.97/0.88/0.86, pero en respuesta a interrupciones se queda cuarto de ocho: 0.75 frente al 0.88 de Joy-Duplex, 0.78 de GPT-4o y 0.77 de Gemini 3.1 Live.
- El propio paper lo admite: “strong continuation does not necessarily imply strong interruption handling”. Ese trade-off es la historia real; el abstract solo cuenta la mitad bonita.
- Segundo gancho verificado: delegación asíncrona de verdad. El frontend de 9B conversa, y el trabajo pesado sale por un span privado
<delegate>a un Harness que ejecuta en segundo plano y re-entra el resultado en la conversación, con snapshot de evidencia fijado en el boundary de la petición y freshness deadline al reintegrarla. - Pesos públicos con licencia Apache-2.0 en Hugging Face (dos checkpoints: Omni audio-visual y Audio solo voz), más el paquete del Harness en GitHub. La licencia del paper es CC BY-NC-SA 4.0: no son la misma cosa.
- Claims de vendor, etiquetados como tales: el benchmark de delegación es interno (no reproducible) y no hay medidas de latencia, RTF ni coste de inferencia en todo el paper. Lo que hay de tool use (FDB-v3) lo gana GPT-Realtime con holgura.
El titular es verdad, y es la mitad de la historia
El abstract de la v2 dice que Realtime-Venus-Audio “responde al 75% de las interrupciones del usuario” y logra “tasas de continuidad del 97%, 88% y 86% bajo backchannels, habla dirigida a otros y habla de fondo, superando a Gemini 3.1 Live y GPT-4o en las tres métricas de continuidad”. Todo eso está en el paper, literal. Lo que el abstract no dice: en la única categoría donde contestar es lo deseable —el usuario te interrumpe y quieres atenderle—, Venus-Audio no supera a nadie. Queda cuarto de ocho.
La Tabla 6 del paper separa cuatro escenarios de solapamiento de voz, y cada uno pide una acción distinta. La distinción clave que casi toda la cobertura ignora: un backchannel (un “sí, sí, te sigo”) no es una interrupción, y el habla de fondo (otra conversación en la cocina) tampoco. Contestar ahí es un fallo, no un acierto.
| Claim del abstract | Qué hay detrás (Tablas 2-8, HTML v2) | Estado |
|---|---|---|
| Supera a Gemini 3.1 Live y GPT-4o en Full-Duplex-Bench v1.5 | Solo en las 3 métricas de continuidad; en respuesta a interrupciones 0.75 vs 0.88 Joy-Duplex / 0.78 GPT-4o / 0.77 Gemini | Cierto e incompleto |
| Responde al 75% de las interrupciones | Literal; cuarto de ocho modelos comparados | Verificado |
| Seis de ocho benchmarks de vídeo | Solo entre modelos online; MiniCPM-o 4.5 (su propia base) gana en ProactiveVideoQA y WorldSense; Gemini-3.5-Flash, offline y solo como referencia, los supera en los 8 | Verificado con letra pequeña |
| Lidera en comprensión de audio | MMAU 78.0 y MMAU-Pro 63.2 (primero); MMAR segundo; MMSU tercero; VoiceBench AlpacaEval 4.81, empate con MiniCPM-o 4.5 | Verificado con matices |
| Delegación asíncrona sin cortar el turno | Mecanismo descrito en detalle y pesos publicados; pero el benchmark de delegación es interno del vendor | Mecanismo verificado; impacto = claim de vendor |
Qué es full-dúplex y por qué el VAD no basta
Un sistema de voz turn-based clásico usa VAD (voice activity detection): si detecta sonido tuyo, calla; cuando callas, responde. El problema es que el VAD decide con acústica, y la acústica no distingue “te interrumpo para corregirte” de “asiento mientras sigues” de “sigo hablando con otra persona”. Tres situaciones que piden tres acciones opuestas.
Realtime-Venus lo resuelve con control de turno semántico, no acústico. El modelo emite tokens de estado por cada chunk de un segundo: <|listen|> (sigue percibiendo sin hablar), <|speak|> (generación activa) y <|turn_eos|> (cierra el turno). El mismo pipeline que decide qué decir decide cuándo hablar y cuándo ceder, así que un “vale, vale” no corta la respuesta y una corrección sí la mata a tiempo. La interrupción la modelan como transición semántica con tres acciones: stop (descarta lo no dicho), repair (regenera el tramo obsoleto con la nueva evidencia) y redirect (abandona el plan y atiende la petición nueva). El audio ya reproducido no se toca.
El trade-off de la Tabla 6 sale de aquí: un modelo entrenado para aguantar bien el rango no-interruptivo (Venus-Audio: 0.97 de continuidad en backchannels) aprende un prior de “sigue hablando” que le cuesta soltar el turno cuando toca. Y al revés: parte del buen score de GPT-4o en interrupciones es sobre-reacción — responde al 91% del habla dirigida a otros y al 93% del habla de fondo, justo lo que no debería. La pregunta interesante no es “quién gana”, es qué prior quieres en tu producto.
La tabla que decide: quién aguanta el caos de una conversación
La dividimos en dos para que sea legible en móvil; en el paper es una sola (Tabla 6, ocho columnas). Primero, interrupciones — aquí lo deseable es C_RESPOND alto (contestar) y C_RESUME bajo (no resucitar la respuesta vieja que el usuario acaba de matar):
| Modelo | C_RESPOND ↑ (contesta) | C_RESUME ↓ (retoma lo viejo) |
|---|---|---|
| Joy-Duplex† | 0.88 | 0.07 |
| GPT-4o* | 0.78 | 0.10 |
| Gemini 3.1 Live† | 0.77 | 0.20 |
| Realtime-Venus-Audio | 0.75 | 0.23 |
| Freeze-Omni† | 0.72 | 0.12 |
| MiniCPM-o 4.5 (su base) | 0.60 | 0.36 |
| Realtime-Venus-Omni | 0.60 | 0.37 |
| Moshi* | 0.50 | 0.26 |
Después, continuidad — aquí lo deseable es C_RESUME alto (seguir con lo que estabas diciendo). Es donde Venus arrasa:
| Modelo | Backchannel ↑ | Habla a otros ↑ | Habla de fondo ↑ |
|---|---|---|---|
| Realtime-Venus-Audio | 0.97 | 0.88 | 0.86 |
| Realtime-Venus-Omni | 0.92 | 0.90 | 0.85 |
| Joy-Duplex† | 0.96 | 0.72 | 0.85 |
| MiniCPM-o 4.5 | 0.95 | 0.79 | 0.82 |
| Gemini 3.1 Live† | 0.95 | 0.66 | 0.66 |
| Freeze-Omni† | 0.80 | 0.25 | 0.25 |
| GPT-4o* | 0.70 | 0.02 | 0.04 |
| Moshi* | 0.06 | 0.19 | 0.07 |
Tres lecturas que no salen del abstract:
- Las tres cifras de continuidad de Venus superan también a Joy-Duplex (0.97 vs 0.96, 0.88 vs 0.72, 0.86 vs 0.85), no solo a Gemini y GPT-4o. En “habla a otros”, el mejor de la casa es Omni (0.90), no Audio.
- El matiz incómodo de la columna C_RESUME en interrupciones: tras ser interrumpido, Venus-Audio retoma su respuesta vieja el 23% de las veces, más del doble que Joy-Duplex (7%) y GPT-4o (10%). Resucitar lo que el usuario acaba de cancelar es probablemente lo peor que le puedes hacer.
- Sobre su propia base: MiniCPM-o 4.5 contesta interrupciones al 60% y Venus-Audio sube a 0.75. El post-training en full-dúplex sí movió la aguja ahí.
Procedencia, que importa: las filas con * (Moshi, GPT-4o) están tomadas del paper original de Full-Duplex-Bench v1.5 (Lin et al., 2026b); las filas con † (Freeze-Omni, Gemini 3.1 Live, Joy-Duplex) vienen del paper de JoyAI-Talker (Bai et al., 2026), citado por los propios autores de Venus. Las filas de Venus son evaluación de los autores. Comparar cifras importadas de dos papers distintos es estándar en la literatura pero suma ruido; tómalo como orden de magnitud, no como foto de laboratorio.
Dos frontends de 9B y un mayordomo: cómo encaja todo
La familia son dos modelos de 9B separados, ambos adaptados de MiniCPM-o 4.5: Realtime-Venus-Omni (audio + vídeo, para interacción audiovisual) y Realtime-Venus-Audio (solo voz). Dentro, la receta es conocida: encoders SigLIP2 (visión) y Whisper-Medium (audio), backbone Qwen3-8B, y un decoder flow-matching que convierte speech tokens S3 — unos 25 tokens por segundo — en audio. Solo se entrena el Thinker (el cerebro); el decoder acústico queda congelado.
Lo interesante es el runtime dual-loop. El bucle frontal procesa chunks de un segundo en tres flujos sincronizados (usuario, asistente, fondo) sobre un reloj conversacional común. Cuando el modelo decide que algo no lo puede o no lo debe resolver en caliente, emite un span privado <delegate>tarea en lenguaje natural</delegate> que se oculta del texto y del habla. El Realtime-Venus-Harness captura la petición, fija el snapshot de evidencia disponible en ese boundary — el trabajo en segundo plano razona sobre lo que había al pedirlo, no sobre lo que llega después —, elige una capacidad registrada, ejecuta, y devuelve el resultado por un canal privado de fondo. El frontend decide cuándo hablarlo; el Harness decide qué y cómo decirlo.
El ciclo de vida del trabajo está especificado con más rigor del habitual: Queued → Running → Completed → Delivering → Delivered (o Failed), separando “la respuesta está preparada” de “ya se ha hablado”. Dos detalles que un dev de agentes reconocerá al instante: la petición lleva freshness deadline (un resultado marcado como stale se excluye de la re-entrada, no se habla por hablar) y la re-entrada ocurre “en un boundary de entrada disponible”, sin cerrar el turno frontal. Si has seguido nuestra tesis de que el harness manda más que el modelo en pi-harness: por qué los modelos locales ya superan a Claude Code, aquí tienes la misma idea aplicada a la voz: el frontend 9B es la cara, el Harness es el que trabaja.
El corpus de post-training (Tabla 1): 2.8M de muestras, ~70% vídeo y ~30% audio compartido; por capacidades, ~56% comprensión offline, ~37% interacción dúplex y ~6% delegación (95k trayectorias vídeo + 90k audio del flujo delegate-backend-restate). La delegación no es un demo hack: es una categoría de entrenamiento con nombre propio.
Delegar decisiones: dos modelos, dos fallos opuestos
Aquí hay que poner el cartel de claim de vendor: el Delegate Benchmark es interno del paper, no público ni reproducible. Con esa advertencia, los resultados de la Tabla 8 son de los más legibles que he visto en un paper reciente:
| Modelo | Overall (routing) | External capabilities (recall) | Rutina (especificidad de NO delegar) | Razonamiento |
|---|---|---|---|---|
| Realtime-Venus-Omni | 75.93 | 68.33 | 84.44 | 75.00 |
| Realtime-Venus-Audio | 68.89 | 92.22 | 39.44 | 75.00 |
Omni delega menos de lo que debería (se le quedan peticiones sin resolver: recall 68.33); Audio delega de más — su especificidad en rutina es 39.44, o sea, delega tareas rutinarias el 60% de las veces. El mismo trade-off de la Tabla 6 en otra superficie: Audio está afinado para pasarte el trabajo a alguien, Omni para apañárselas solo. Para quien diseña routers agénticos, el patrón de arquitecturas multi-agente: patrones que funcionan en 2026 ya lo decía: el umbral de delegación es un hiperparámetro de producto, y este benchmark interno al menos lo mide por separado — recall de delegar y especificidad de no delegar, no una accuracy agregada que esconde ambos fallos.
Tool use: aquí Venus no gana
Full-Duplex-Bench v3 mide si el sistema de voz ejecuta bien herramientas. Venus no gana; GPT-Realtime lidera las tres métricas con diferencia:
| Modelo | Tool selection F1 | Argument accuracy | Pass@1 |
|---|---|---|---|
| GPT-Realtime | 87.6% | 68.0% | 60.0% |
| Realtime-Venus-Omni | 86.0% | 53.1% | 43.0% |
| NemotronLabs VoiceChat-11B | 82.5% | 42.2% | 33.0% |
| Realtime-Venus-Audio | 82.0% | 52.2% | 42.0% |
| Gemini 3.1 Live | 81.7% | 58.8% | 54.0% |
| Cascaded | 80.3% | 56.2% | 45.0% |
| Grok | 79.7% | 54.2% | 43.0% |
| Ultravox | 79.4% | 51.3% | 41.0% |
| Gemini 2.5 Live | 78.6% | 59.3% | 49.0% |
Venus-Omni queda segundo en selección de herramienta, a solo 1.6 puntos de GPT-Realtime (86.0 vs 87.6), pero se despeña en ejecución completa: 43.0 de Pass@1 frente a 60.0. Saber a qué llamar está resuelto; llamar bien con los argumentos correctos, no. Es la misma brecha selección/ejecución que arrastran los agentes de texto — el selector es barato, el ejecutor fiable es caro — y en voz se agranda porque los argumentos salen del habla, con sus errores de transcripción y sus restricciones dichas una vez y perdidas. Si vienes del mundo texto, la distancia con los fronts cerrados ya la trazamos en la comparativa Gemini 3.5 vs GPT-5.5 vs Claude Opus 4.7: el patrón “casi alcanza en lo fácil, muy por detrás en lo duro” se repite.
Ojo con la versión del paper que citas: la v2 corrige dos cifras de la v1. MMSU de Venus-Audio pasa de 66.8 a 66.0, y las métricas FDB-v3 de Venus-Audio de 85.0/54.2/48.0 a 82.0/52.2/42.0: su puesto en tool selection F1 cae de segundo a cuarto (82.0), superado también por NemotronLabs VoiceChat-11B (82.5) y apenas medio punto por delante de Gemini 3.1 Live (81.7). Esta pieza usa las cifras de la v2. El abstract no cambió entre versiones.
El “seis de ocho” en vídeo tiene letra pequeña
Realtime-Venus-Omni logra las mejores marcas “entre los modelos online evaluados” en seis de ocho benchmarks de vídeo: 70.2 en StreamingBench, 64.7 en OVO-Bench, 81.3 en Daily-Omni, 29.0 en OmniPro, más OmniVideoBench 39.2 y LVOmniBench 38.9. La letra pequeña, que el paper declara honestamente pero el abstract comprime:
- Solo entre modelos online (los que procesan streaming en tiempo real): LiveStar, MMDuet2, JoyAI-VL-Interaction y MiniCPM-o 4.5.
- Contra su propia base pierde en dos: MiniCPM-o 4.5 le gana en ProactiveVideoQA (47.5 vs 46.2 de PAUC) y en WorldSense (54.2 vs 54.0). El paper lo admite en la sección de alcance de la comparación.
- Gemini-3.5-Flash, offline y solo como referencia, gana en los ocho (77.3/71.6/56.5/52.4/67.2/82.3/64.6/58.2). No es competencia directa — un modelo offline no hace dúplex — pero te dice dónde está el techo actual.
En audio, el reparto es similar: Venus-Audio lidera MMAU (78.0) y MMAU-Pro (63.2) entre los comparados, es segundo en MMAR (65.6, tras Qwen3-Omni con 66.4), tercero en MMSU (66.0; por delante Qwen3-Omni 69.0 y Fun-Audio-Chat 67.8), primero en Llama Questions (83.8) y Speech CMMLU (67.8), segundo en Speech TriviaQA (75.7, tras 75.9 de Qwen3-Omni) y empata el mejor VoiceBench AlpacaEval (4.81) con MiniCPM-o 4.5. Que un modelo de interacción en tiempo real compita así en comprensión es el titular real de la sección; el 9B ha dejado de ser sinónimo de “versión tonta”.
Un extra que apenas se ha comentado: memoria training-free de vídeo largo. Un mecanismo de gating por coste de predicción de movimiento decide qué frames almacenar, y un retrieval estilo MaxSim con ponderación por MAD y poda por MMR recupera evidencia de horas atrás. En el subset de 60-90 minutos de LVOmniBench añade +5.88 puntos. Sin entrenar nada. El paper también reporta que el beneficio depende del backbone (en MiniCPM-o 4.5 la memoria ayuda en varios bins pero empeora un bin corto de LongVideoBench), así que no es magia universal: es un módulo que hay que medir por caso.
Pesos, licencia y qué puedes ejecutar hoy
Esto no es solo un paper: hay release público.
- Pesos: inclusionAI/Realtime-Venus en Hugging Face, con los dos checkpoints (Omni y Audio), BF16, contexto de 40.960 tokens y código custom de Transformers. Licencia del modelo: Apache-2.0 — más permisiva de lo habitual en este espacio.
- Harness: paquete reutilizable en github.com/inclusionAI/Realtime-Venus, con demo de navegador que usa Codex como backend de tareas. La demo dúplex en vivo pide al menos una A100, así que “ejecutarlo hoy” significa tener GPU de verdad o esperar cuants.
- Paper: CC BY-NC-SA 4.0. No confundas la licencia del texto (no comercial) con la de los pesos (Apache-2.0, uso comercial permitido). La que te importa para producto es la segunda.
- Sin cifras de rendimiento en inferencia: ni latencia, ni RTF, ni coste, ni comparación de velocidad con Gemini Live o GPT-4o. Para un sistema “realtime” que se compara con productos en producción, la ausencia es elocuente: la única referencia dura es que necesita una A100 la demo.
Qué significa esto para tu arquitectura
Si no vas a servir un modelo de voz full-dúplex mañana, ¿qué te llevas? Tres patrones que sobreviven al hype y que ya aparecían en nuestra cobertura de delegación asíncrona en agentes:
- Snapshot de evidencia en el boundary de la petición. Cuando un agente delega, el trabajo en segundo plano debe razonar sobre el estado congelado en el momento de la petición, no sobre el estado vivo (que habrá cambiado). Fijar el snapshot al capturar la tarea elimina toda una clase de carreras.
- Freshness deadline en la re-entrada. El resultado preparado solo se habla si sigue vigente. Traducido a agentes de texto: los resultados de background deberían caducar, no encolarse infinitamente para el siguiente turno.
- Control de turno semántico sobre VAD. Distinguir backchannel de interrupción es un problema semántico; si tu pipeline de voz trata todo solapamiento como “el usuario ha hablado”, tienes el bug de GPT-4o (interrumpirlo todo) o el de Moshi (no enterarte de nada) por construcción.
Y el meta-patrón: un frontend pequeño y rápido que conversa, con el trabajo pesado desplazado a un runtime que captura, ejecuta y re-entra. Nada de esto necesita 9B multimodales; necesita disciplina de diseño de turnos y de estados.
Qué NO sabemos
- Latencia y coste reales. El paper no reporta latencia de primera respuesta, RTF del decoder de habla ni coste de inferencia. Sin eso, “realtime” es una aspiración arquitectónica, no una medida.
- Si el delegate benchmark refleja el mundo real. Es interno, sin datos públicos ni protocolo reproducible. Las cifras de la Tabla 8 son autodiagnóstico del vendor: útiles para ver el trade-off Omni/Audio, no para comparar con nada externo.
- Reproducibilidad externa, cero. Todas las filas de Venus en todas las tablas son evaluación de los autores. El resto de filas vienen de otros papers, con setups que pueden no coincidir. Nadie fuera del consorcio ha medido esto todavía.
- Los asteriscos de la Tabla 6. Las filas importadas (GPT-4o, Moshi del paper de FDB; Gemini 3.1 Live y Joy-Duplex del de JoyAI-Talker) pueden diferir en decodificación y prompts. Es práctica normal y sigue siendo ruido metodológico.
- Voz en español. El corpus y los benchmarks son en inglés (y algo de chino en los datos); no hay evaluación de español. Para un sitio en español, es la primera pregunta que haría antes de pilotar nada.
Qué haría yo
Si montas una interfaz de voz: prototiparía con los pesos de Venus-Audio (Apache-2.0, corre con una GPU seria) para el frontend conversacional y dejaría la ejecución de tareas en tu propio harness — el suyo está pensado exactamente para enchufar backends externos, y su demo usa Codex. No compararía mi build con las tablas del paper: mediría respuesta a interrupciones y continuidad en tus diálogos reales, que es donde este paper demuestra que las prioridades de entrenamiento deciden el producto.
Si solo te llevas una idea para agentes de texto: el par snapshot-en-el-boundary + freshness-deadline-en-la-re-entrada. Es la especificación más limpia de delegación asíncrona que he visto en un paper de voz, y no tiene nada que ver con el audio: es gestión de estado y de tiempo. La parte incómoda — que tu modelo delegue el 60% de las tareas rutinarias si lo afinas demasiado para delegar — también te la ahorras con dos métricas separadas (recall de delegar, especificidad de no delegar) en tu eval, como hacen aquí.
Fuentes
- Primarias: arXiv 2609.13814 — abstract · HTML v2 completo (Tablas 1-8 cotejadas; erratum v1→v2 documentado arriba) — consultados el 04/10/2026.
- Pesos y código: inclusionAI/Realtime-Venus en Hugging Face (LICENSE Apache-2.0, ficha técnica) · repositorio con el Harness · project page — consultados el 04/10/2026.
- Recepción: página del paper en Hugging Face (224 upvotes vía API, 04/10/2026).
- Contexto interno: pi-harness: los modelos locales superan a Claude Code · arquitecturas multi-agente: patrones 2026 · GPT-6 Astra: delegación asíncrona · comparativa Gemini 3.5 vs GPT-5.5 vs Claude Opus 4.7.