Cómo creamos en seis meses un sistema en tiempo real para una IA de voz ágil

Para la IA de voz, saber cuándo hablar es más difícil de lo que parece. Las personas se ceden la palabra sin esfuerzo en una fracción de segundo, pero los sistemas de IA de voz anteriores no podían seguir ese ritmo. Su arquitectura basada en turnos dependía de pequeños modelos conocidos como detectores de turnos, que afrontaban una tarea poco envidiable: si se anticipaban, interrumpían al usuario; si tardaban demasiado, la respuesta se sentía lenta. El LLM, mucho más grande, solo podía empezar a trabajar después de que el detector tomara una decisión.

GPT‑Live⁠, nuestro sistema de voz de tercera generación, elimina el detector de turnos de la ruta de audio. Su modelo de voz es full-duplex, lo que significa que puede escuchar y hablar al mismo tiempo. Esto elimina la necesidad de un detector independiente y hace que la conversación se sienta más inmediata y natural. Cuando se necesita un razonamiento más profundo o usar herramientas, GPT‑Live también puede consultar nuestros modelos de vanguardia, como GPT‑5.5, sin interrumpir el flujo de la conversación. En conjunto, estas capacidades ofrecen a GPT‑Live una combinación sin precedentes de capacidad de respuesta conversacional e inteligencia.

Ofrecer esta experiencia a gran escala exigió una nueva arquitectura de sistema optimizada para una baja latencia. A diferencia de la inferencia típica de solicitud y respuesta, nuestro sistema transmite el audio entrante al modelo de voz y devuelve el habla al usuario, mientras gestiona la delegación por una ruta asíncrona independiente. Durante los últimos seis meses, rediseñamos la inferencia del modelo, la administración del contexto y el transporte multimedia para que el habla fluyera con fluidez de extremo a extremo.

La arquitectura también establece un límite claro entre la ruta de voz central y la lógica de la aplicación. Esto facilita personalizar el comportamiento de la aplicación sin afectar su capacidad de respuesta. Esta base impulsa una variedad creciente de funciones en ChatGPT Voz, incluida la nueva capacidad de controlar tu computadora y coordinar tus agentes en la aplicación de escritorio de ChatGPT.

En este artículo explicaremos por qué los sistemas anteriores basados en turnos no satisfacían nuestras necesidades y cómo diseñamos el nuevo sistema para ofrecer capacidad de respuesta en cada capa. Abordaremos la inferencia con estado, la administración dinámica del contexto, la delegación asíncrona y la optimización a nivel de protocolo, que en conjunto hacen que GPT‑Live se sienta realmente en vivo.

Las arquitecturas de voz anteriores heredaron el funcionamiento por turnos de los LLM de texto, pero representaban cada turno como un bloque de audio discreto en lugar de texto. En los sistemas en cascada, la conversión de voz a texto, el LLM y la conversión de texto a voz se ejecutaban en serie. Esta secuencia aumentaba la latencia e ignoraba señales como el tono y el ritmo.

Los modelos de voz a voz mejoraron este enfoque al procesar el audio directamente. Entrenar al modelo para comprender y generar habla de forma nativa le permitió conservar detalles que se perdían en la transcripción y responder con mayor rapidez. Sin embargo, el sistema aún dependía del detector de turnos para decidir cuándo podía comenzar la inferencia. El modelo gestionaba una mayor parte de la interacción, pero esta seguía basándose en turnos.

GPT‑Live pone el modelo de voz al mando de la conversación: el audio entra y sale del modelo, mientras que el razonamiento más profundo y el uso de herramientas ocurren de forma asíncrona. La tarea principal del sistema es mantener un ciclo multimedia ininterrumpido. Otras tareas, como invocar modelos de vanguardia y conservar la conversación, ocurren fuera de la ruta en vivo.

Mantener este ciclo multimedia sin interrupciones no siempre es sencillo. Cualquier demora en el transporte, el procesamiento o la inferencia puede convertirse en una pausa o un artefacto audible. Un sistema anterior basado en turnos podía tolerar cierta variación en el momento de llegada de un bloque de audio. Sin embargo, un sistema multimedia en vivo debe entregar cada fotograma de audio a tiempo.

El trabajo previo en ChatGPT Voz y la Realtime API nos dio una base importante. Ya habíamos reconstruido nuestra infraestructura de voz⁠ para transmitir audio y video directamente hacia y desde nuestros sistemas con una latencia menor y más predecible. GPT‑Live llevó este diseño más lejos al transmitir contenido multimedia hasta el modelo mediante un nuevo sistema de inferencia con estado, creado para la conversación continua.

Sin embargo, la inferencia por streaming era solo una parte de la solución. Para que funcionara bien en producción, también debíamos garantizar la entrega confiable del audio desde el cliente hasta la pila de inferencia y afrontar los desafíos de mantener el estado.

Una decisión inicial fue separar expresamente el flujo multimedia de la lógica empresarial y de la aplicación. El audio se desplaza entre el cliente y el modelo de voz por una ruta rápida exclusiva. La delegación, el uso de herramientas y otras tareas de la aplicación ocurren detrás de un límite RPC asíncrono. Una llamada lenta a una herramienta o servicio de backend puede retrasar su propio resultado, pero no detener el flujo multimedia.

Esta separación también proporciona al sistema un límite claro para la personalización. Las aplicaciones pueden cambiar sus herramientas, políticas y comportamiento de backend sin afectar al frontend multimedia encargado de mantener el audio en movimiento. La ruta en vivo sigue siendo pequeña, predecible y centrada en el trabajo que debe ocurrir en tiempo real.

Escribimos el frontend multimedia y la lógica de inferencia en Go, en sustitución de una implementación anterior en Python con asyncio. Esto mejoró considerablemente la fluidez de la entrega de fotogramas: el p95 del nuevo sistema igualó el p50 del anterior.

WebRTC proporciona la base de transporte. Está diseñado para contenido multimedia de baja latencia y puede seguir funcionando pese a la pérdida de paquetes, la deriva del reloj y los cambios en la conexión del cliente. Si los paquetes llegan tarde, WebRTC puede alargar sutilmente el audio para evitar vacíos y luego acelerar brevemente la reproducción hasta recuperar el tiempo real.

Al minimizar el almacenamiento en búfer y los bloqueos en todo el sistema, podemos ofrecer la respuesta en menos de un segundo que las personas esperan de una conversación.

La inferencia con estado implica sus propias concesiones operativas. Una sesión de voz puede permanecer activa durante mucho tiempo, pero su contexto crece continuamente y las instancias del modelo se inician y detienen según la demanda.

Para abordar estas cuestiones, creamos un mecanismo de transferencia fluida entre instancias del modelo. Cuando se necesita una transición, podemos preparar una instancia de reemplazo junto a la existente, precargarla con el contexto actual de la sesión, ejecutar la inferencia en ambas en paralelo y transferir la sesión cuando la nueva instancia esté completamente lista.

El mismo mecanismo básico también permite la compactación dinámica del contexto. A medida que avanza una conversación, su contexto acumulado puede terminar superando el límite de contexto del modelo. La compactación puede reducir el tamaño del contexto para ajustarlo al límite, pero la operación lleva tiempo. Además, como modifica el contexto anterior, también invalida la caché de clave-valor (KV) del modelo, que almacena las claves y los valores de atención de tokens procesados previamente. Reconstruir ese estado exige una nueva precarga, lo que introduce una demora adicional.

En cambio, tratamos la compactación como otra transición administrada. Mientras la instancia original del modelo continúa conversando, el sistema compacta el contexto y prepara una instancia de reemplazo con el nuevo contexto. Una vez que esa instancia está lista, podemos hacer el cambio sin interrumpir el contenido multimedia. Esto permite que el sistema admita llamadas prolongadas y realice la compactación cuando sea necesario.

El trabajo pesado se mantiene fuera de la ruta en vivo, por lo que la conversación nunca pierde el ritmo, ni siquiera durante una transferencia.

La capacidad de GPT‑Live para invocar modelos de vanguardia existentes le aporta mucha potencia y, en la práctica, separa el “habla” del “razonamiento” más profundo. Sin embargo, lograr que esta arquitectura de dos modelos se sintiera como un solo sistema exigió resolver dos problemas de ingeniería relacionados.

En primer lugar, los resultados deben volver con suficiente rapidez para ser útiles en el intercambio en curso, por lo que tuvimos que minimizar la latencia de toda la ruta de delegación, desde el direccionamiento y el procesamiento del prompt hasta la inferencia y las llamadas a herramientas. Al mismo tiempo, otros sistemas del producto todavía necesitan mensajes discretos, por lo que debíamos representar la conversación en curso de una manera que pudieran comprender.

Cuando se envía una delegación, optimizamos el tiempo que tarda el modelo de vanguardia en producir algo útil para la conversación. El modelo de voz puede mantener brevemente el intercambio mientras un modelo de vanguardia razona o utiliza herramientas, pero no puede ocultar una respuesta excesivamente lenta. Por eso incluimos todo el ciclo de delegación —direccionamiento, procesamiento del prompt, inferencia y llamadas a herramientas— en el presupuesto de capacidad de respuesta.

La primera optimización consiste en preparar el modelo de vanguardia y las herramientas que necesite antes de solicitar la delegación. Cuando comienza una sesión de voz, el servidor de la aplicación crea una sesión de inferencia para el modelo de vanguardia y la precarga con el contexto inicial de la conversación, lo que garantiza que el prompt esté completamente procesado antes de la primera solicitud delegada.

Luego mantenemos disponible esa sesión de inferencia durante toda la conversación de voz y usamos afinidad estable de sesión para las solicitudes sucesivas. Junto con el almacenamiento en caché del prompt, estas técnicas mejoran la latencia sin dejar de facilitar la recuperación ante la falla de un proceso de trabajo.

El esfuerzo de razonamiento, los límites de salida, los esquemas de herramientas y los recorridos de ida y vuelta entre el modelo y las herramientas también influyen en cuándo recibe la conversación un resultado útil, y ajustamos estas variables para obtener respuestas más rápidas. Al minimizar el trabajo necesario en la ruta de delegación, permitimos que el modelo de voz incorporara rápidamente los resultados de nuestros modelos de vanguardia.

Aunque el modelo de voz opera con flujos continuos de habla, muchos de los sistemas que lo rodean todavía funcionan con turnos del usuario y del asistente, incluida la interfaz de conversación de ChatGPT y partes de nuestra infraestructura de análisis y seguridad. Por eso, el servidor de la aplicación descompone la conversación superpuesta y a veces ambigua en mensajes discretos.

A medida que llega el audio, el servidor usa transcripciones parciales y señales temporales para inferir quién tiene la palabra y crear una cola de mensajes. El mensaje más reciente permanece provisional; su texto, sus tiempos y la asignación del hablante pueden cambiar a medida que llega más audio. Cuando un hablante ha tenido la palabra el tiempo suficiente para que la atribución sea confiable, el servidor finaliza el mensaje correspondiente.

La superposición de hablantes complica este proceso. Una breve señal de escucha del asistente mientras habla el usuario (por ejemplo, “ajá” o “está bien”) no necesariamente debe convertirse en un mensaje independiente. Sin embargo, una intervención sustancial del asistente a menudo sí debería hacerlo. Del mismo modo, priorizamos la coherencia de las respuestas del asistente que se muestran, incluso cuando el usuario habla en medio de ellas.

Toda política de segmentación sacrifica inmediatez a cambio de certeza. Confirmar demasiado pronto produce un historial fragmentado y un orden inestable; esperar demasiado retrasa las transcripciones y las funciones que dependen de ellas. Por eso, el sistema mantiene dos vistas relacionadas de la conversación: una vista especulativa del estado actual y un registro definitivo de lo que se dijo. La vista de la conversación en la interfaz de la aplicación admite actualizaciones, por lo que utiliza la vista especulativa. Sin embargo, el registro en el canal de análisis requiere una transcripción final.

Esto proporciona al resto de ChatGPT una vista estable del intercambio sin imponer turnos a la ruta de voz en vivo.

La capacidad de respuesta comienza en cuanto el usuario hace clic en el botón. Con GPT‑Live, el sistema debe establecer la ruta multimedia y comenzar a enviar audio al modelo antes de que pueda comenzar la conversación. Esto coloca cada parte de la secuencia de inicio en la ruta crítica.

Como señalamos antes, WebRTC proporciona una base sólida para el tiempo real, pero iniciar una sesión de WebRTC estándar requiere una cantidad sorprendente de negociaciones de protocolo y recorridos de ida y vuelta por la red. WebRTC es anterior al énfasis en minimizar los recorridos de ida y vuelta que definió protocolos posteriores como QUIC. Como resultado, sus protocolos subyacentes a veces repiten trabajo cuando se usan juntos. Por ejemplo, cada protocolo incluía su propio mecanismo contra ataques de denegación de servicio, incluso cuando no era necesario en el contexto de toda la pila WebRTC.

Analizamos la pila y desarrollamos WebRTC Abridged Roundtrip Protocol (WARP⁠(se abre en una nueva ventana)), que reduce el inicio del contenido multimedia y los datos de seis recorridos de ida y vuelta por la red a solo uno. WARP lo logra mediante un conjunto de mejoras de protocolo compatibles con versiones anteriores: incorporar la negociación DTLS en ICE (SPED⁠(se abre en una nueva ventana)), usar la negociación más rápida de DTLS 1.3⁠(se abre en una nueva ventana), negociar previamente la conexión SCTP (SNAP⁠(se abre en una nueva ventana)) y negociar previamente los canales de datos en lugar de usar DCEP⁠(se abre en una nueva ventana).

Diseñamos WARP como un conjunto de especificaciones abiertas en colaboración con integrantes de la comunidad WebRTC, para que todo el ecosistema pueda beneficiarse de este trabajo. Estamos impulsando las propuestas mediante el grupo de trabajo TSVWG de la IETF, y la compatibilidad con WARP ya se agregó tanto a libwebrtc como a Pion, mientras continúan los esfuerzos en otras implementaciones de WebRTC.

Después de optimizar la negociación multimedia, destacó una demora pendiente: el intercambio de señalización utilizado para compartir los parámetros SDP antes de que WebRTC pueda conectarse. Para eliminar ese intercambio de la ruta crítica, desarrollamos lo que llamamos Instant Connect. Negocia estos parámetros con anticipación, sin reservar capacidad del servidor ni modificar las implementaciones existentes de WebRTC.

Instant Connect funciona en paralelo con el flujo de señalización estándar. Si los parámetros negociados previamente son válidos, el servidor puede materializar la sesión cuando llega el primer paquete multimedia. Si están obsoletos o no son válidos, el flujo de señalización ya está en curso, por lo que el cliente puede recurrir a él sin latencia adicional.

En conjunto, Instant Connect y WARP reducen drásticamente el tiempo entre la intención del usuario y el inicio del flujo multimedia en vivo. Con el intercambio SDP fuera de la ruta crítica y WARP condensando la negociación del transporte, el cliente ahora puede iniciar una sesión con un solo paquete UDP. El servidor puede responder de inmediato y permitir que el resto del sistema comience a hacer lo que realmente le importa al usuario: escuchar y responder.

Un sistema puede parecer rápido en teoría y aun así bloquearse con tráfico de voz real. Antes de permitir que GPT‑Live conversara con los usuarios, hicimos una prueba silenciosa que dirigía una proporción pequeña y cada vez mayor de las sesiones de ChatGPT Voz en producción tanto a la experiencia existente del modo de voz avanzado como a nuestro nuevo sistema. El modo de voz avanzado siguió atendiendo a los usuarios con normalidad, mientras que la ruta paralela ejecutaba inferencias en modo de solo lectura. Así expusimos el sistema a clientes, redes, duraciones de sesión y distribuciones geográficas reales sin cambiar lo que oían los usuarios.

Una de las primeras lecciones fue que la capacidad no podía reducirse al rendimiento de la GPU. Las sesiones de voz permanecen abiertas y envían fotogramas continuamente, por lo que los controladores de flujos del lado de la CPU, las colas y las rutas de red deben escalar junto con la inferencia. Con carga real, un componente auxiliar se saturó antes de lo previsto en nuestras pruebas de carga, lo que hizo que se acumularan las solicitudes de inferencia y aumentara progresivamente la latencia. Cambiamos la pregunta sobre la capacidad de “¿Cuántas solicitudes puede procesar una GPU?” a “¿Cuántas sesiones simultáneas puede sostener el sistema sin que ningún fotograma se retrase?”

La prueba también convirtió la ubicación geográfica en una consideración prioritaria. Dirigir una sesión a capacidad lejana puede generar demoras en varios puntos durante el inicio y la transmisión. Comenzamos a validar los despliegues de modelos junto con la capacidad regional y la configuración de direccionamiento del tráfico, y luego desglosamos la latencia según la ubicación geográfica de origen. Acercar la inferencia a los usuarios ayudó, pero también reforzó una lección más amplia: la capacidad de respuesta de extremo a extremo depende de todos los servicios de la ruta, no solo del servidor del modelo.

Otros errores solo surgieron durante ciclos de vida de sesión realistas. Las sesiones prolongadas expusieron presiones sobre la memoria y la persistencia. Las reconexiones pusieron a prueba la compactación y la restauración del estado. Las desconexiones habituales de los clientes revelaron condiciones de carrera en la negociación de cierre. Estos problemas rara vez aparecían en pruebas de carga breves porque dependían del tiempo, del estado acumulado y del comportamiento entre los límites de los servicios.

Por último, las pruebas en producción nos obligaron a mejorar la observabilidad y los controles de despliegue. Encontramos métricas que combinaban distintas fuentes de latencia, paneles cuyos valores agregados ocultaban motores individuales con problemas y divergencias de configuración entre los sistemas probados y los implementados. Como respuesta, agregamos telemetría más detallada, validación con configuraciones de buen funcionamiento comprobado, aumentos graduales por etapas y la capacidad de aislar o desactivar rápidamente rutas individuales. La prueba silenciosa se convirtió en un ensayo previo al lanzamiento, no solo para determinar cuánto tráfico podía aceptar el sistema, sino también con qué rapidez podíamos detectar, contener y resolver una falla.

Llevar GPT‑Live a la escala de ChatGPT exigió un sistema completamente nuevo, creado en torno a un principio fundamental: la voz debe fluir. La inferencia por streaming suministra audio continuamente al modelo full-duplex. Una ruta multimedia exclusiva garantiza la entrega confiable de los fotogramas. La delegación asíncrona permite ejecutar en paralelo el razonamiento más profundo. El transporte optimizado mantiene la capacidad de respuesta de la experiencia hasta llegar al usuario.

La arquitectura de GPT‑Live ya está convirtiéndose en una plataforma más amplia para la interacción en tiempo real. Impulsa ChatGPT Voz en su expansión de la conversación a la coordinación mediante agentes y será la base de la próxima API de GPT‑Live. Con el tiempo, permitirá que las experiencias de voz abarquen más dispositivos, aplicaciones y modalidades sin sacrificar la inmediatez que hace que una conversación de voz se sienta en vivo.

Si te interesa resolver este tipo de problemas de ingeniería, ven a trabajar con nosotros⁠.