OpenAI Describe la Arquitectura WebRTC para la Voz AI a Baja Latencia a Escala

InfoQ Homepage Noticias OpenAI Describe la Arquitectura WebRTC para la Voz AI a Baja Latencia a Escala Arquitectura & Diseño Portable by Design: Patrones de Movilidad y Recuperación de Datos para Sistemas Multi-Nube (Webinar 21 de mayo) OpenAI Describe la Arquitectura WebRTC para la Voz AI a Baja Latencia a Escala 20 de mayo de 2026 2 min read por Eran Stiller Escribe para InfoQ Alimenta tu curiosidad. Ayuda a 550k+ desarrolladores senior a cada mes mantenerse a la vanguardia. Establece contacto Escucha este artículo - 0:00 Audio listo para reproducir Tu navegador no admite el elemento de audio. 0:00 0:00 Normal 1.25x 1.5x Me gusta Lista de lectura OpenAI ha descrito recientemente cómo ha adaptado WebRTC para la voz AI a baja latencia a escala global . La nueva arquitectura ha reemplazado un modelo de terminación de medios convencional con un diseño de relay-transceiver más adecuado para Kubernetes y equilibradores de carga en la nube. Mantiene el estado de las sesiones WebRTC en un capa de transceptor dedicada mientras utiliza relés ligeros para reducir la exposición pública UDP y mantener la ruta de los medios cerca de los usuarios. En el artículo, Yi Zhang y William McDonald, miembros del personal técnico de OpenAI, explican que la alcance global, la configuración rápida de las conexiones y los tiempos de round-trip de los medios estables fueron las principales restricciones detrás del cambio. El equipo evaluó varias alternativas para exponer las sesiones de medios, cada una con diferentes trade-offs operativos. La primera alternativa fue la exposición directa por sesión UDP, que preserva el modelo WebRTC convencional. Sin embargo, esto desplaza la complejidad operativa al nivel de infraestructura, especialmente en entornos Kubernetes, donde grandes rangos de puertos públicos son difíciles de gestionar de manera segura. La asignación de puertos únicos por servidor simplifica algunas decisiones de routing, pero deja a los operadores con el problema de la planificación de puertos, el uso desigual y los patrones de lanzamiento más frágiles. Opción 1: El enfoque SFU incluye a la IA como participante WebRTC ( source ) Relay -style relés también fueron una opción plausible, pero introducen un intermediario más pesado en el camino de los medios y resuelven un problema más amplio de lo que OpenAI necesitaba para las sesiones 1:1 modelo-to-user predominantes. OpenAI en su lugar eligió dividir las responsabilidades entre dos capas. Un relé ligero acepta los paquetes en llegada y los envía, mientras que un transceptor separado posee toda la maquinaria WebRTC estatal, incluida la negociación ICE, los handshakes DTLS, la criptografía SRTP y el ciclo de vida de la sesión. Opción 2: El enfoque tranceiver interrumpe WebRTC en el borde y convierte en un protocolo de backend ( source ) Esta separación significa que el relé puede mantenerse simple, rápido y en gran parte sin estado, mientras que el transceptor es el único componente que necesita comprender el protocolo completo. Esto mantiene la complejidad concentrada en un solo lugar en lugar de duplicarla en servicios backend o desplazarla en el comportamiento del cliente. "El lugar mejor para agregar complejidad es en un capa de routing delgada, no en cada servicio backend y no en el comportamiento del cliente personalizado," afirman los autores. Relay statelessly envía paquetes al transceptor ( source ) WebRTC es una elección común para cargas de trabajo AI en tiempo real. Además de la entrega de medios a baja latencia, proporciona también la travesía NAT, el transporte cifrado, la negociación de códigos, la bufferización de jitter y las características de audio como el anulamiento de eco en navegadores y plataformas móviles. STUN es parte de esa fundación, ayudando a los puntos finales a descubrir cómo aparecen en la red y apoyando ICE durante las verificaciones de conectividad. Muchos equipos se basan en unidades de forwarding selectivo, o SFUs, porque centralizan la ruta de los medios y la política para sistemas multi-participantes. Sin embargo, los cargos de trabajo de OpenAI son principalmente sesiones 1:1 entre un usuario y un modelo, lo que hace que un diseño transceptor sea un mejor ajuste que tratar al modelo como otro participante en una arquitectura de conferencia. El artículo agrega detalles de infraestructura al empuje de voz en tiempo real de OpenAI, ya disponible en productos como ChatGPT voice y la API Realtime . Para los arquitectos que construyen sistemas de medios interactivos, el patrón más interesante es la descomposición misma: preservar el comportamiento del protocolo en la capa de routing