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

En la IA de voz, saber cuándo hablar es más difícil de lo que parece. Los humanos 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 se enfrentaban a una tarea nada envidiable: si se adelantaban, interrumpían al usuario; si tardaban, la respuesta parecía lenta. El LLM, mucho mayor, 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 bidireccional simultáneo, lo que significa que puede escuchar y hablar a la vez. Esto elimina la necesidad de un detector independiente y hace que la conversación resulte 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. Juntas, estas capacidades ofrecen a GPT‑Live una combinación sin precedentes de agilidad 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 basada en solicitudes y respuestas, 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 gestió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 principal y la lógica de la aplicación. Esto permite personalizar fácilmente el comportamiento de la aplicación sin afectar a la capacidad de respuesta. Esta base impulsa un abanico creciente de funciones de ChatGPT Voz, incluida la nueva capacidad de controlar el ordenador y coordinar agentes desde 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 una respuesta ágil en todas las capas. Abordaremos la inferencia con estado, la gestión dinámica del contexto, la delegación asíncrona y la optimización a nivel de protocolo, que funcionan conjuntamente para que GPT‑Live parezca realmente en directo.

Las arquitecturas de voz anteriores heredaron el funcionamiento por turnos de los LLM de texto, pero representaban cada turno como un bloque de audio independiente 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 añadía latencia e ignoraba indicios como el tono y el ritmo.

Los modelos de voz a voz mejoraron este enfoque al procesar el audio directamente. Entrenar el modelo para comprender y generar habla de forma nativa le permitió conservar detalles que se perdían en la transcripción y responder más rápido. Sin embargo, el sistema seguía dependiendo 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 frente de la conversación: el audio entra y sale del modelo, mientras el razonamiento más profundo y el uso de herramientas tienen lugar de forma asíncrona. La tarea principal del sistema es mantener un bucle multimedia sin interrupciones. Otras tareas, como invocar modelos de vanguardia y conservar la conversación, se realizan fuera de la ruta en directo.

Mantener este bucle multimedia sin interrupciones no siempre es sencillo. Cualquier retraso 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 directo debe entregar cada trama de audio a tiempo.

Nuestro trabajo anterior en ChatGPT Voz y la Realtime API nos proporcionó una base importante. Ya habíamos reconstruido nuestra infraestructura de voz⁠ para transmitir audio y vídeo 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 el contenido multimedia hasta el modelo mediante un nuevo sistema de inferencia con estado, creado para mantener conversaciones continuas.

Sin embargo, la inferencia en streaming solo era una parte de la solución. Para que funcionara bien en producción, también tuvimos que garantizar una entrega fiable del audio desde el cliente hasta la pila de inferencia y afrontar los retos de mantener el estado.

Una de nuestras primeras decisiones fue separar expresamente el flujo multimedia de la lógica empresarial y de la aplicación. El audio circula entre el cliente y el modelo de voz por una ruta rápida específica. La delegación, el uso de herramientas y otras tareas de la aplicación tienen lugar tras un límite RPC asíncrono. Una llamada lenta a una herramienta o un servicio de backend puede retrasar su propio resultado, pero no detener el flujo multimedia.

Esta separación también ofrece 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 directo sigue siendo pequeña, predecible y centrada en el trabajo que debe realizarse en tiempo real.

Escribimos el frontend multimedia y la lógica de inferencia en Go, en sustitución de una implementación anterior de asyncio en Python. Esto mejoró notablemente la fluidez de la entrega de tramas: 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 cortes y después acelerar brevemente la reproducción para volver a sincronizarse con el tiempo real.

Al reducir al mínimo 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 conlleva sus propias contrapartidas 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 en función de la demanda.

Para abordar estos problemas, creamos un mecanismo de transferencia fluida entre instancias del modelo. Cuando se necesita una transición, podemos preparar una instancia de sustitución del modelo junto a la existente, precargarla con el contexto actual de la sesión, ejecutar la inferencia en ambas en paralelo y cambiar a la nueva cuando 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, el contexto acumulado puede acabar 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 cambia 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 los tokens procesados previamente. Reconstruir ese estado requiere una nueva precarga, lo que introduce un retraso adicional.

En su lugar, tratamos la compactación como otra transición gestionada. Mientras la instancia original del modelo mantiene la conversación, el sistema compacta el contexto y prepara una instancia de sustitución con el nuevo contexto. Cuando esa instancia está lista, podemos cambiar a ella sin interrumpir el contenido multimedia. Esto permite que el sistema admita llamadas prolongadas y compacte el contexto cuando sea necesario.

El trabajo pesado queda fuera de la ruta en directo, por lo que la conversación no pierde el ritmo ni siquiera durante una transferencia.

La capacidad de GPT‑Live para invocar modelos de vanguardia existentes le aporta una gran potencia, ya que desacopla en la práctica el «habla» del «pensamiento» más profundo. Sin embargo, conseguir que esta arquitectura de dos modelos pareciera un único sistema exigió resolver dos problemas de ingeniería relacionados.

En primer lugar, los resultados deben llegar 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 enrutamiento y el procesamiento del prompt hasta la inferencia y las llamadas a herramientas. Al mismo tiempo, otros sistemas del producto siguen necesitando mensajes independientes, así que tuvimos que representar la conversación en curso de una forma que pudieran entender.

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 usa herramientas, pero no puede ocultar una respuesta excesivamente lenta. Por tanto, consideramos todo el ciclo de delegación —enrutamiento, procesamiento del prompt, inferencia y llamadas a herramientas— parte del presupuesto de tiempo 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 aplicaciones 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 se haya procesado por completo antes de la primera solicitud delegada.

Después mantenemos disponible esa sesión de inferencia durante toda la conversación de voz y usamos una afinidad de sesión estable para las solicitudes sucesivas. Junto con el almacenamiento en caché del prompt, estas técnicas mejoran la latencia y permiten recuperarse fácilmente si falla un proceso de trabajo.

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

Aunque el modelo de voz trabaja con flujos de habla continuos, muchos de los sistemas que lo rodean siguen funcionando con turnos del usuario y del asistente, incluida la interfaz de conversación de ChatGPT y parte de nuestra infraestructura de análisis y seguridad. Por eso, el servidor de aplicaciones descompone la conversación solapada y en ocasiones ambigua en mensajes independientes.

A medida que llega el audio, el servidor usa transcripciones parciales y señales temporales para inferir quién tiene el turno de palabra y crear una cola de mensajes. El mensaje más reciente sigue siendo provisional: su texto, sus tiempos y la asignación del hablante pueden cambiar a medida que llega más voz. Cuando una persona ha mantenido el turno de palabra el tiempo suficiente para que la atribución sea fiable, el servidor da por definitivo el mensaje correspondiente.

El solapamiento entre hablantes complica el proceso. Una breve señal de asentimiento del asistente mientras habla el usuario (por ejemplo, «ajá» o «vale») no tiene por qué convertirse en un mensaje independiente. Sin embargo, una intervención sustancial del asistente suele merecerlo. 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 genera un historial fragmentado y un orden inestable; esperar demasiado retrasa las transcripciones y las funciones que dependen de ellas. Por tanto, el sistema mantiene dos vistas relacionadas de la conversación: una vista provisional 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, así que utiliza la vista provisional. Sin embargo, el registro en el canal de análisis requiere una transcripción definitiva.

Así, el resto de ChatGPT dispone de una vista estable del intercambio sin imponer turnos a la ruta de voz en directo.

La capacidad de respuesta empieza en cuanto el usuario pulsa el botón. Con GPT‑Live, el sistema debe establecer la ruta multimedia y empezar a introducir audio en el modelo antes de que pueda comenzar la conversación. Esto sitúa cada parte de la secuencia de inicio en la ruta crítica.

Como ya indicamos, WebRTC ofrece una base sólida para el tiempo real, pero iniciar una sesión WebRTC convencional exige una cantidad sorprendente de protocolos de enlace e intercambios de ida y vuelta por la red. WebRTC es anterior al énfasis en reducir los intercambios de ida y vuelta que determinó el diseño de protocolos posteriores como QUIC. Por ello, sus protocolos subyacentes a veces repiten tareas cuando se utilizan juntos. Por ejemplo, cada protocolo incluía su propio mecanismo contra ataques DoS, incluso cuando no era necesario en el contexto de la pila WebRTC completa.

Analizamos la pila y desarrollamos el protocolo abreviado de ida y vuelta de WebRTC (WARP⁠(se abre en una ventana nueva)), que reduce el inicio del contenido multimedia y los datos de seis intercambios de ida y vuelta por la red a uno solo. WARP lo consigue mediante varias mejoras de protocolo retrocompatibles: superponer el protocolo de enlace DTLS sobre ICE (SPED⁠(se abre en una ventana nueva)), utilizar el protocolo de enlace más rápido de DTLS 1.3⁠(se abre en una ventana nueva), negociar previamente el protocolo de enlace SCTP (SNAP⁠(se abre en una ventana nueva)) y negociar previamente los canales de datos en lugar de usar DCEP⁠(se abre en una ventana nueva).

Diseñamos WARP como un conjunto de especificaciones abiertas, en colaboración con miembros de la comunidad WebRTC, para que todo el ecosistema pueda beneficiarse de este trabajo. Estamos impulsando las propuestas en el grupo de trabajo TSVWG del IETF, y la compatibilidad con WARP ya se ha añadido tanto a libwebrtc como a Pion, mientras prosigue el trabajo en otras implementaciones de WebRTC.

Tras optimizar el protocolo de enlace multimedia, destacaba un retraso pendiente: el intercambio de señalización utilizado para compartir los parámetros SDP antes de que WebRTC pueda conectarse. Para retirar ese intercambio de la ruta crítica, desarrollamos lo que llamamos Instant Connect. Negocia estos parámetros de antemano sin reservar capacidad del servidor ni modificar las implementaciones existentes de WebRTC.

Instant Connect se ejecuta junto 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.

Juntos, Instant Connect y WARP reducen drásticamente el tiempo desde que el usuario muestra su intención hasta que comienza el flujo multimedia en directo. Al sacar el intercambio SDP de la ruta crítica y condensar WARP el protocolo de enlace de transporte, el cliente ya puede iniciar una sesión con un único paquete UDP. El servidor puede responder de inmediato y permitir que el resto del sistema empiece a hacer lo que realmente le importa al usuario: escuchar y responder.

Un sistema puede parecer rápido sobre el papel y aun así bloquearse con tráfico de voz real. Antes de permitir que GPT‑Live conversara con los usuarios, realizamos una prueba silenciosa que dirigía una proporción pequeña y creciente 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 las GPU. Las sesiones de voz permanecen abiertas y envían tramas continuamente, por lo que los gestores 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 por 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 gestionar una GPU?» a «¿Cuántas sesiones simultáneas puede mantener el sistema sin que ninguna trama se retrase?»

La prueba también convirtió la geografía en una cuestión primordial. Dirigir una sesión a recursos lejanos puede añadir retrasos en varios puntos durante el inicio y la transmisión. Empezamos a validar los despliegues de modelos junto con la capacidad regional y la configuración del enrutamiento del tráfico, para después desglosar la latencia por ubicación 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 fallos solo aparecieron al reproducir ciclos de vida realistas de las sesiones. Las sesiones prolongadas revelaron presión sobre la memoria y la persistencia. Las reconexiones pusieron a prueba la compactación y la restauración del estado. Las desconexiones normales de los clientes revelaron condiciones de carrera en el protocolo 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 mezclaban distintas fuentes de latencia, paneles cuyos datos agregados ocultaban motores concretos con problemas y divergencias de configuración entre los sistemas probados y los desplegados. Como respuesta, añadimos telemetría más granular, validación con configuraciones de eficacia probada, aumentos graduales por etapas y la capacidad de aislar o desactivar rápidamente rutas concretas. La prueba silenciosa se convirtió en un ensayo previo al lanzamiento: no solo comprobaba cuánto tráfico podía aceptar el sistema, sino también con qué rapidez podíamos detectar, contener y subsanar un fallo.

Llevar GPT‑Live a la escala de ChatGPT exigió un sistema completamente nuevo, construido en torno a un principio fundamental: la voz debe fluir. La inferencia en streaming suministra audio de forma continua al modelo bidireccional. Una ruta multimedia específica garantiza una entrega fiable de las tramas. La delegación asíncrona permite ejecutar en paralelo un razonamiento más profundo. Un transporte optimizado mantiene la capacidad de respuesta de la experiencia hasta llegar al usuario.

La arquitectura de GPT‑Live ya está evolucionando para convertirse en una plataforma más amplia de interacción en tiempo real. Impulsa ChatGPT Voz en su evolución desde la conversación hacia la coordinación agéntica y servirá de base para 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 directo.

Si este es el tipo de problemas de ingeniería que quieres resolver, ven a trabajar con nosotros⁠.