Por Canuto  

OpenAI detalló cómo rediseñó su infraestructura de WebRTC para que la voz de ChatGPT y su Realtime API funcionen con menor latencia y a escala global. La compañía apostó por una arquitectura de relay más transceiver para reducir la superficie pública de puertos UDP, mantener el estado de sesión en un solo punto y acercar el ingreso de medios a los usuarios.
***

  • OpenAI asegura que la IA de voz solo se siente natural si responde a la velocidad del habla, con baja latencia, poco jitter y pérdidas mínimas.
  • La empresa rediseñó su pila de WebRTC con una arquitectura de relay más transceiver que separa el reenvío de paquetes de la terminación del protocolo.
  • El nuevo enfoque apunta a sostener servicios como ChatGPT Voice y la Realtime API para más de 900 millones de usuarios activos semanales.

OpenAI explicó cómo rediseñó la infraestructura que sostiene sus experiencias de voz en tiempo real, un componente clave para productos como la voz de ChatGPT, la Realtime API y distintos flujos interactivos con agentes. La meta, según la compañía, es que la conversación se sienta natural, algo que solo ocurre cuando el sistema responde a la velocidad del habla y no introduce pausas incómodas, interrupciones tardías o respuestas cortadas.

La publicación, firmada por Yi Zhang y William McDonald, ambos miembros del personal técnico, describe un problema de escala muy concreto. OpenAI dice que hoy debe atender a más de 900 millones de usuarios activos semanales y, en ese contexto, necesita que la conexión se establezca rápido, que el tiempo de ida y vuelta del audio se mantenga bajo y estable, y que el jitter y la pérdida de paquetes sean reducidos.

Ese desafío no es solo de producto, sino también de arquitectura. En sistemas de voz impulsados por IA, el audio no puede tratarse como un archivo que se sube completo para luego procesarse. Debe llegar como un flujo continuo, de modo que el modelo pueda transcribir, razonar, invocar herramientas o empezar a generar voz mientras el usuario todavía está hablando.

Ese comportamiento marca la diferencia entre una experiencia conversacional y una que se asemeja a un sistema de pulsar para hablar. Por eso, la empresa optó por revisar a fondo cómo gestiona WebRTC, el estándar abierto que suele usarse para transportar audio, video y datos de baja latencia entre navegadores, aplicaciones móviles y servidores.

Por qué WebRTC sigue siendo central para la voz con IA

OpenAI sostiene que WebRTC resuelve varias de las partes más difíciles de las comunicaciones interactivas en tiempo real. Entre ellas menciona ICE para establecer conectividad y atravesar NAT, DTLS y SRTP para transporte cifrado, negociación de códecs, RTCP para control de calidad y funciones del lado del cliente como cancelación de eco y buffers de jitter.

La importancia de ese estándar, en la visión de la empresa, es que evita desarrollar una solución distinta para cada plataforma. Sin WebRTC, cada cliente tendría que gestionar por su cuenta problemas de conectividad, cifrado, códecs y adaptación a condiciones de red cambiantes, lo que complicaría mucho la interoperabilidad entre navegadores, móviles y servidores.

OpenAI también subraya que se apoya en el ecosistema ya existente alrededor de WebRTC, incluidas implementaciones maduras de código abierto. En ese punto menciona el trabajo fundacional de Justin Uberti, uno de los arquitectos originales de WebRTC, y de Sean DuBois, creador y mantenedor de Pion, quienes ahora forman parte de OpenAI y colaboran en la evolución de estos sistemas.

La empresa remarca que, para sus casos de uso, el punto esencial es mantener un flujo de audio constante. Eso permite que la IA reaccione durante la intervención del usuario y no después, una condición especialmente relevante en agentes de voz que deben responder de manera fluida.

La decisión de arquitectura: SFU o transceiver

Tras elegir WebRTC como base, OpenAI tuvo que decidir dónde terminar esas conexiones y cómo unirlas con el backend de inferencia. La compañía evaluó modelos como los SFU, o selective forwarding unit, que suelen recibir un flujo WebRTC de cada participante y reenviarlo selectivamente a los demás.

Ese enfoque, según la publicación, encaja bien en productos multiparte como reuniones, clases o llamadas grupales. También puede ser una opción razonable en escenarios cliente a IA porque permite reutilizar sistemas ya probados para señalización, grabación, observabilidad y futuras extensiones, como transferir una llamada a un humano o añadir más participantes.

Pero OpenAI concluyó que su carga de trabajo principal era distinta. La mayoría de sus sesiones son 1 a 1, es decir, un usuario hablando con un modelo o una aplicación interactuando con un agente en tiempo real. En ese tipo de tráfico, la prioridad es reducir latencia en cada turno y simplificar la escalabilidad de los servicios de inferencia.

Por eso eligió un modelo basado en transceiver. En este diseño, un servicio WebRTC en el edge termina la conexión del cliente y luego convierte medios y eventos a protocolos internos más simples para inferencia del modelo, transcripción, generación de voz, uso de herramientas y orquestación. El transceiver es, además, el único que mantiene el estado de la sesión WebRTC, incluidas comprobaciones ICE, handshake DTLS, claves SRTP y ciclo de vida de la sesión.

El choque entre WebRTC y Kubernetes

La primera implementación de OpenAI fue un servicio único en Go, basado en Pion, que manejaba tanto señalización como terminación de medios. Ese sistema ya impulsa la voz de ChatGPT, el endpoint WebRTC de la Realtime API y varios proyectos de investigación, según explicó la empresa.

El problema apareció cuando se intentó operar ese diseño como el resto de la infraestructura de OpenAI, sobre Kubernetes. El modelo convencional de WebRTC, que usa un puerto por sesión, resultó poco compatible con entornos donde las cargas se escalan, se mueven entre hosts y se reprograman con frecuencia.

La compañía describe primero el problema de agotamiento de puertos. A alta concurrencia, el sistema necesita exponer y gestionar rangos enormes de puertos UDP públicos. Eso no solo complica la configuración de balanceadores y health checks, también amplía la superficie externa que debe ser asegurada y auditada.

Además, el autoscaling se vuelve frágil si cada pod necesita reservar y anunciar un rango estable de puertos. Por eso, señala OpenAI, muchos sistemas WebRTC evolucionan hacia un único puerto UDP por servidor con demultiplexación a nivel de aplicación detrás de ese puerto.

Sin embargo, ese esquema también tiene límites. Aunque reduce la cantidad de puertos, no resuelve del todo el problema de mantener la propiedad de cada sesión dentro de una flota compartida. ICE y DTLS son protocolos con estado, y el proceso que crea una sesión debe seguir recibiendo los paquetes de esa misma sesión para validar conectividad, completar el handshake, descifrar SRTP y gestionar cambios posteriores como reinicios de ICE.

Si los paquetes terminan en otra instancia, la configuración puede fallar o el flujo de medios puede romperse. De ahí surgió el objetivo central: mantener una superficie UDP pública pequeña y fija, pero sin perder la capacidad de enviar cada paquete al transceiver exacto que posee la sesión correspondiente.

La arquitectura relay más transceiver

La respuesta de OpenAI fue separar el enrutamiento de paquetes de la terminación del protocolo. En la arquitectura desplegada, la señalización sigue llegando al transceiver para configurar la sesión, mientras que los medios entran primero a través de un relay. Ese relay es una capa ligera de reenvío UDP con una huella pública reducida.

El relay no descifra medios, no ejecuta máquinas de estado ICE y no participa en la negociación de códecs. Su tarea consiste en leer la metadata mínima del paquete necesaria para elegir un destino y luego reenviar el tráfico al transceiver que ya posee la sesión. Desde el lado del cliente, OpenAI afirma que no cambia nada en la semántica de WebRTC.

El paso más importante es enrutar el primer paquete. Como todavía no existe una sesión en la propia ruta de medios, el relay debe tomar una decisión sin depender de una consulta externa en la ruta crítica. Para resolverlo, la compañía usó un elemento ya presente en WebRTC: el fragmento de nombre de usuario ICE, conocido como ufrag.

Según explica OpenAI, el ufrag del lado del servidor se genera con la metadata justa para que el relay pueda inferir el clúster de destino y el transceiver propietario. Durante la señalización, el transceiver asigna el estado de la sesión y devuelve un VIP del relay compartido junto a un puerto UDP en la respuesta SDP. Ese VIP funciona como una dirección estable hacia la flota de relay.

El primer paquete de medios desde el cliente suele ser una solicitud STUN de binding. El relay analiza lo suficiente de ese primer paquete para leer el ufrag del servidor, decodificar la pista de enrutamiento y reenviarlo al transceiver correcto. Después, una vez creada la sesión en el relay, los paquetes posteriores de DTLS, RTP y RTCP fluyen sin necesidad de volver a decodificar el ufrag.

El estado del relay se mantiene deliberadamente mínimo. OpenAI dice que solo conserva una sesión en memoria para guiar el reenvío, contadores para monitoreo y temporizadores para expiración y limpieza. Si un relay se reinicia y pierde esa sesión, un nuevo paquete STUN puede reconstruirla desde la pista de enrutamiento incluida en el ufrag. Para acelerar aún más la recuperación, la empresa utiliza una caché de Redis con el mapeo entre la IP y puerto del cliente y la IP y puerto del transceiver.

Ingreso global y mejoras de rendimiento

Una vez reducida la superficie UDP pública a un conjunto pequeño de direcciones y puertos estables, OpenAI desplegó el mismo patrón de relay de forma global. La compañía llama a esa capa Global Relay, una flota de puntos de ingreso distribuidos geográficamente que aplican el mismo comportamiento de reenvío de paquetes.

La ventaja principal es acercar el primer salto entre el cliente y la red de OpenAI. Si el paquete entra por un relay cercano al usuario, tanto geográficamente como en topología de red, disminuye la latencia, se reduce el jitter y caen las ráfagas evitables de pérdida antes de que el tráfico alcance el backbone interno.

Para la señalización, OpenAI indicó que usa direccionamiento geográfico y de proximidad de Cloudflare. Así, la solicitud inicial por HTTP o WebSocket llega a un clúster de transceivers cercano. Ese contexto define dónde se ubicará la sesión y qué punto de ingreso de Global Relay se anunciará al cliente en la respuesta SDP.

En cuanto a implementación, el relay fue escrito en Go y mantenido intencionalmente acotado. Corre en espacio de usuario sobre Linux y no utiliza frameworks de kernel bypass. En cambio, se apoya en decisiones como SO_REUSEPORT para repartir paquetes entre múltiples workers sobre el mismo puerto UDP, runtime.LockOSThread para fijar goroutines lectoras a hilos específicos del sistema operativo, y buffers preasignados para reducir asignaciones y presión del recolector de basura.

OpenAI asegura que ese diseño ya maneja su tráfico global de medios en tiempo real con una huella de relay relativamente pequeña. Por eso, al menos por ahora, decidió conservar un enfoque más simple y no dar el salto a rutas más complejas de bypass del kernel.

Qué concluye OpenAI de este rediseño

En la práctica, la empresa sostiene que la nueva arquitectura permite operar medios WebRTC sobre Kubernetes sin exponer miles de puertos UDP. Eso facilita asegurar y balancear la infraestructura, y hace posible escalar sin reservar grandes rangos de puertos públicos para cada pod o sesión.

La compañía también presenta esta decisión como una validación de su enfoque sin SFU para el caso de uso predominante. Dado que la mayoría de sus sesiones son punto a punto y muy sensibles a la latencia, separar una capa de enrutamiento delgada de unos servicios de inferencia que no necesitan comportarse como peers WebRTC resultó, en su opinión, la opción correcta por defecto.

Entre los aprendizajes más relevantes, OpenAI destaca cuatro ideas. La primera es preservar la semántica estándar del protocolo en el edge para no romper interoperabilidad con navegadores y móviles. La segunda es mantener los estados difíciles de la sesión en un solo lugar, concentrados en el transceiver.

La tercera es utilizar información ya disponible en la propia configuración, en este caso el ufrag de ICE, para lograr enrutamiento determinista del primer paquete sin introducir dependencias adicionales en la ruta crítica. La cuarta es optimizar primero para el caso común antes de asumir una complejidad mayor con tecnologías de kernel bypass.

El mensaje final de la empresa es claro. La IA de voz en tiempo real solo funciona cuando la infraestructura logra que la latencia se vuelva casi invisible para el usuario. En el caso de OpenAI, eso implicó cambiar profundamente la forma en que despliega WebRTC, pero sin alterar lo que los clientes esperan de ese estándar.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados