OpenAI explica cómo rediseñó WebRTC para una IA de voz con baja latencia

OpenAI ha detallado cómo rehízo su infraestructura WebRTC para las funciones de voz de ChatGPT y la Realtime API. El objetivo era sencillo: que la conversación con la IA no se deshaga por culpa de los retrasos de red, ni siquiera con carga global y cientos de millones de usuarios.

Por qué el enfoque anterior no servía

Para una IA de voz no basta con reconocer el habla y generar una respuesta rápido. La conversación debe avanzar al ritmo del habla humana: sin pausas incómodas, sin interrupciones cortadas y sin esperar un segundo antes de que el modelo reaccione. OpenAI explica que, a su escala, esto se resume en tres requisitos a la vez: alcance global para más de 900 millones de usuarios activos semanales, establecimiento rápido de la conexión y un tiempo de ida y vuelta del audio bajo y estable.

«La IA de voz resulta natural solo cuando la conversación avanza a la

velocidad del habla».

El problema era que el enfoque clásico de WebRTC encaja mal con la infraestructura en la nube de OpenAI. Si cada sesión necesita su propio puerto UDP público, con mucha concurrencia hay que abrir y proteger rangos enormes de puertos. Eso resulta incómodo para Kubernetes, complica el balanceo de carga, hace más frágil el autoescalado y aumenta la superficie de ataque. Además, las sesiones ICE y DTLS siguen siendo stateful: los paquetes deben llegar exactamente al proceso que posee cada conexión.

Relay más transceiver

Tras comparar varias opciones, OpenAI descartó el esquema en el que el modelo actúa como un participante WebRTC normal a través de un SFU. Su carga típica es de uno a uno: un usuario habla con un modelo, o un cliente se comunica con un agente en tiempo real. Por eso la compañía eligió el modelo transceiver: un servicio de borde termina la conexión WebRTC del cliente y después traduce el contenido multimedia y los eventos a protocolos internos para inferencia, transcripción, síntesis de voz, llamadas a herramientas y orquestación.

La idea clave de la nueva arquitectura es separar el enrutamiento de paquetes de la terminación del protocolo. El relay pasó a ser una capa UDP ligera en la entrada, con una huella pública de red pequeña, mientras que el transceiver sigue siendo el componente stateful que mantiene ICE, DTLS, las claves SRTP y todo el ciclo de vida de la sesión. El relay no descifra el contenido multimedia, no negocia códecs y no intenta hacerse pasar por un peer WebRTC. Solo lee una cantidad mínima de metadatos del paquete y reenvía el tráfico adonde vive la sesión correspondiente.

El truco más interesante tiene que ver con el primer paquete. OpenAI usa el ICE username fragment, o ufrag, y le incrusta justo la información de enrutamiento que el relay necesita para elegir el clúster y el transceiver concreto. Durante la señalización, el cliente recibe una VIP de relay compartida y un puerto UDP fijo, y el primer paquete STUN da al sistema datos suficientes para enviar el flujo por el camino correcto de inmediato, sin consultar un servicio de lookup externo. Una vez establecida la ruta, la asignación de direcciones se guarda además en Redis para recuperarse rápido tras un reinicio del relay.

Cómo redujeron la latencia

Cuando lograron reducir la superficie UDP pública a un número pequeño de direcciones y puertos estables, OpenAI escaló el mismo esquema a nivel global. Así nació Global Relay, un conjunto distribuido de puntos de entrada que reciben los paquetes más cerca del usuario y los introducen en la red de OpenAI sin un primer salto innecesario por una región lejana. Para la señalización, la compañía usa el enrutamiento geográfico y por proximidad de Cloudflare, de modo que tanto la solicitud HTTP/WebSocket inicial como la primera comprobación ICE llegan al clúster adecuado más cercano.

• Una capa UDP pública pequeña y fija en lugar de miles de puertos abiertos
• Enrutamiento del primer paquete mediante datos ya incrustados en el ICE ufrag
• Un socket UDP compartido en el lado del transceiver en lugar de un socket por sesión
• Estado en memoria de corta duración más una caché Redis para recuperar la ruta rápidamente
• `SO_REUSEPORT`, anclaje de hilos a hilos del sistema operativo y minimización de asignaciones para lograr alto rendimiento

OpenAI escribió el relay en Go y mantuvo deliberadamente acotadas sus responsabilidades: no termina la sesión WebRTC, solo analiza rápido las cabeceras necesarias, actualiza el estado mínimo del flujo y reenvía los paquetes. La compañía subraya que no necesitó kernel bypass: bastó una optimización cuidadosa con `SO_REUSEPORT`, thread pinning y menos copias innecesarias para atender el tráfico multimedia global en tiempo real con una capa de relay relativamente pequeña y sin renunciar al comportamiento estándar de WebRTC en los clientes.

Qué significa

Para los usuarios, todo esto se traduce en que «el modo de voz responde mejor», pero para el mercado importa más otra cosa: OpenAI demostró cómo construir una IA de voz masiva sobre WebRTC estándar, sin clientes personalizados y sin un crecimiento doloroso de la infraestructura de red. Es una buena referencia para quienes desarrollan asistentes en tiempo real, agentes de voz y productos donde medio segundo de latencia ya arruina toda la experiencia de usuario.