OpenAI explicó cómo reestructuró WebRTC para una AI de voz de baja latencia

OpenAI reveló detalles sobre cómo rediseñó su infraestructura WebRTC para las funciones de voz de ChatGPT y la Realtime API. El objetivo era directo: las conversaciones con IA no deberían fallar debido a la latencia de red, incluso bajo carga global con cientos de millones de usuarios.

Por qué el enfoque anterior no funcionaba

Para la IA de voz, no es suficiente simplemente reconocer la voz y generar rápidamente una respuesta. La conversación debe fluir al ritmo del habla humana: sin pausas incómodas, interrupciones cortadas y esperas de varios segundos antes de la reacción del modelo.

OpenAI escribe que en su escala, esto se reduce a tres requisitos clave: cobertura global para más de 900 millones de usuarios activos semanales, establecimiento rápido de conexión y latencia de ida y vuelta baja y estable para el audio.

"La IA de voz se siente natural solo cuando la conversación se mueve

al ritmo del habla."

El problema era que el enfoque clásico de WebRTC no se adaptaba bien a la infraestructura en la nube de OpenAI. Si cada sesión necesita su propio puerto UDP público, entonces con alta concurrencia tienes que abrir y asegurar enormes rangos de puertos. Esto es inconveniente para Kubernetes, complica el equilibrio de carga, hace que el autoescalado sea más frágil y aumenta la superficie de ataque. Mientras tanto, las propias sesiones de ICE y DTLS siguen siendo con estado: los paquetes necesitan llegar exactamente al proceso que posee la conexión particular.

Relay más transceptor

Después de comparar varias opciones, OpenAI abandonó el esquema donde el modelo actúa como un participante WebRTC regular a través de un SFU. Para su carga de trabajo, los escenarios uno a uno son típicos: un usuario habla con un modelo o un cliente se comunica con un agente en tiempo real. Entonces la empresa eligió el modelo transceptor: un servicio edge termina la conexión WebRTC del cliente y luego traduce medios y eventos en protocolos internos para inferencia, transcripción, síntesis de voz, invocación de herramientas y orquestación.

La idea clave de la nueva arquitectura es separar el enrutamiento de paquetes de la terminación del protocolo. Relay se convirtió en una capa UDP ligera en la entrada con una pequeña huella de red pública, mientras que transceptor siguió siendo el componente con estado que mantiene ICE, DTLS, claves SRTP y todo el ciclo de vida de la sesión. Relay no descifra medios, no negocia códecs y no intenta pretender ser un peer WebRTC. Solo lee la cantidad mínima de metadatos del paquete y reenvía el tráfico a donde reside la sesión necesaria.

El truco más interesante involucra el primer paquete. OpenAI utiliza el fragmento de nombre de usuario ICE, o ufrag, e incorpora en él información de enrutamiento suficiente para que relay seleccione el clúster y el transceptor específico. Durante la señalización, el cliente recibe un VIP de relay compartido y un puerto UDP fijo, y el primer paquete STUN proporciona al sistema suficientes datos para enviar el flujo por el camino correcto de inmediato, sin una llamada separada a un servicio de búsqueda externo. Después del establecimiento de la ruta, la asignación de direcciones se almacena adicionalmente en Redis para recuperación rápida después del reinicio del relay.

Cómo redujeron la latencia

Una vez que la superficie UDP pública se redujo a un pequeño número de direcciones y puertos estables, OpenAI escaló este mismo esquema globalmente. Así surgió Global Relay — un conjunto distribuido de puntos de entrada que reciben paquetes más cerca del usuario y los introducen en la red de OpenAI sin un salto inicial adicional a través de una región lejana. Para la señalización, la empresa utiliza el enrutamiento geográfico y de proximidad de Cloudflare, por lo que tanto la solicitud HTTP/WebSocket inicial como la primera verificación de ICE llegan al clúster más cercano adecuado.

• Capa UDP pública pequeña y fija en lugar de miles de puertos abiertos
• Enrutamiento de primer paquete a través de datos ya integrados en el ufrag de ICE
• Socket UDP compartido en el lado del transceptor en lugar de un socket por sesión
• Estado en memoria de corta duración más caché Redis para recuperación rápida de ruta
• `SO_REUSEPORT`, afinidad de thread a threads del SO y asignaciones minimizadas para alto rendimiento

OpenAI escribió su relay en Go y deliberadamente lo mantuvo estrecho en responsabilidad: no termina la sesión WebRTC, sino que solo analiza rápidamente los encabezados necesarios, actualiza el estado mínimo del thread y reenvía paquetes adelante. La empresa enfatiza específicamente que no necesitaba bypass de kernel: la optimización cuidadosa en el nivel de `SO_REUSEPORT`, afinidad de thread y reducción de copias innecesarias fue suficiente para manejar el tráfico de medios en tiempo real global con una capa relay relativamente pequeña y sin abandonar el comportamiento estándar de WebRTC en los clientes.

Qué significa

Para los usuarios, todo esto se ve como "el modo de voz se volvió más responsivo", pero para el mercado, algo más importa: OpenAI demostró cómo construir IA de voz a escala masiva sobre WebRTC estándar sin clientes personalizados y sin la expansión dolorosa de la infraestructura de red. Este es un buen punto de referencia para los desarrolladores de asistentes en tiempo real, agentes de voz y productos donde la latencia de medio segundo ya rompe toda la experiencia del usuario.