{"id":136093,"date":"2026-05-04T19:19:39","date_gmt":"2026-05-05T01:19:39","guid":{"rendered":"https:\/\/pongara.net\/news\/openai-revela-como-redujo-la-latencia-de-su-ia-de-voz-para-escalar-a-nivel-global\/"},"modified":"2026-05-04T19:19:39","modified_gmt":"2026-05-05T01:19:39","slug":"openai-revela-como-redujo-la-latencia-de-su-ia-de-voz-para-escalar-a-nivel-global","status":"publish","type":"post","link":"https:\/\/pongara.net\/news\/openai-revela-como-redujo-la-latencia-de-su-ia-de-voz-para-escalar-a-nivel-global\/","title":{"rendered":"OpenAI revela c\u00f3mo redujo la latencia de su IA de voz para escalar a nivel global"},"content":{"rendered":"<div>\n<div><img width=\"640\" height=\"384\" src=\"https:\/\/pongara.net\/news\/wp-content\/uploads\/2026\/05\/canuto-imagine-1777943964-840x504-1.jpg\" class=\"attachment-large size-large wp-post-image\" alt=\"\" style=\"margin-bottom: 15px;\" loading=\"lazy\" decoding=\"async\" srcset=\"https:\/\/pongara.net\/news\/wp-content\/uploads\/2026\/05\/canuto-imagine-1777943964-840x504-1.jpg 840w, https:\/\/diariobitcoin.b-cdn.net\/wp-content\/uploads\/2026\/05\/canuto-imagine-1777943964-608x365.jpg 608w, https:\/\/diariobitcoin.b-cdn.net\/wp-content\/uploads\/2026\/05\/canuto-imagine-1777943964-768x461.jpg 768w, https:\/\/diariobitcoin.b-cdn.net\/wp-content\/uploads\/2026\/05\/canuto-imagine-1777943964.jpg 1226w\" sizes=\"auto, (max-width: 640px) 100vw, 640px\"><\/div>\n<p><strong>OpenAI detall\u00f3 c\u00f3mo redise\u00f1\u00f3 su infraestructura de WebRTC para que la voz de ChatGPT y su Realtime API funcionen con menor latencia y a escala global. La compa\u00f1\u00eda apost\u00f3 por una arquitectura de relay m\u00e1s transceiver para reducir la superficie p\u00fablica de puertos UDP, mantener el estado de sesi\u00f3n en un solo punto y acercar el ingreso de medios a los usuarios.<br \/>\n***<\/strong><strong><\/strong><\/p>\n<ul>\n<li><strong>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\u00e9rdidas m\u00ednimas.<\/strong><\/li>\n<li><strong>La empresa redise\u00f1\u00f3 su pila de WebRTC con una arquitectura de relay m\u00e1s transceiver que separa el reenv\u00edo de paquetes de la terminaci\u00f3n del protocolo.<\/strong><\/li>\n<li><strong>El nuevo enfoque apunta a sostener servicios como ChatGPT Voice y la Realtime API para m\u00e1s de 900 millones de usuarios activos semanales.<\/strong><\/li>\n<\/ul>\n<hr>\n<p>OpenAI explic\u00f3 c\u00f3mo redise\u00f1\u00f3 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\u00fan la compa\u00f1\u00eda, es que la conversaci\u00f3n se sienta natural, algo que solo ocurre cuando el sistema responde a la velocidad del habla y no introduce pausas inc\u00f3modas, interrupciones tard\u00edas o respuestas cortadas.<\/p>\n<p>La publicaci\u00f3n, firmada por Yi Zhang y William McDonald, ambos miembros del personal t\u00e9cnico, describe un problema de escala muy concreto. OpenAI dice que hoy debe atender a m\u00e1s de 900 millones de usuarios activos semanales y, en ese contexto, necesita que la conexi\u00f3n se establezca r\u00e1pido, que el tiempo de ida y vuelta del audio se mantenga bajo y estable, y que el jitter y la p\u00e9rdida de paquetes sean reducidos.<\/p>\n<p>Ese desaf\u00edo no es solo de producto, sino tambi\u00e9n 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\u00eda est\u00e1 hablando.<\/p>\n<p>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\u00f3 por revisar a fondo c\u00f3mo gestiona WebRTC, el est\u00e1ndar abierto que suele usarse para transportar audio, video y datos de baja latencia entre navegadores, aplicaciones m\u00f3viles y servidores.<\/p>\n<h3>Por qu\u00e9 WebRTC sigue siendo central para la voz con IA<\/h3>\n<p>OpenAI sostiene que WebRTC resuelve varias de las partes m\u00e1s dif\u00edciles de las comunicaciones interactivas en tiempo real. Entre ellas menciona ICE para establecer conectividad y atravesar NAT, DTLS y SRTP para transporte cifrado, negociaci\u00f3n de c\u00f3decs, RTCP para control de calidad y funciones del lado del cliente como cancelaci\u00f3n de eco y buffers de jitter.<\/p>\n<p>La importancia de ese est\u00e1ndar, en la visi\u00f3n de la empresa, es que evita desarrollar una soluci\u00f3n distinta para cada plataforma. Sin WebRTC, cada cliente tendr\u00eda que gestionar por su cuenta problemas de conectividad, cifrado, c\u00f3decs y adaptaci\u00f3n a condiciones de red cambiantes, lo que complicar\u00eda mucho la interoperabilidad entre navegadores, m\u00f3viles y servidores.<\/p>\n<p>OpenAI tambi\u00e9n subraya que se apoya en el ecosistema ya existente alrededor de WebRTC, incluidas implementaciones maduras de c\u00f3digo 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\u00f3n de estos sistemas.<\/p>\n<p>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\u00f3n del usuario y no despu\u00e9s, una condici\u00f3n especialmente relevante en agentes de voz que deben responder de manera fluida.<\/p>\n<h3>La decisi\u00f3n de arquitectura: SFU o transceiver<\/h3>\n<p>Tras elegir WebRTC como base, OpenAI tuvo que decidir d\u00f3nde terminar esas conexiones y c\u00f3mo unirlas con el backend de inferencia. La compa\u00f1\u00eda evalu\u00f3 modelos como los SFU, o selective forwarding unit, que suelen recibir un flujo WebRTC de cada participante y reenviarlo selectivamente a los dem\u00e1s.<\/p>\n<p>Ese enfoque, seg\u00fan la publicaci\u00f3n, encaja bien en productos multiparte como reuniones, clases o llamadas grupales. Tambi\u00e9n puede ser una opci\u00f3n razonable en escenarios cliente a IA porque permite reutilizar sistemas ya probados para se\u00f1alizaci\u00f3n, grabaci\u00f3n, observabilidad y futuras extensiones, como transferir una llamada a un humano o a\u00f1adir m\u00e1s participantes.<\/p>\n<p>Pero OpenAI concluy\u00f3 que su carga de trabajo principal era distinta. La mayor\u00eda de sus sesiones son 1 a 1, es decir, un usuario hablando con un modelo o una aplicaci\u00f3n interactuando con un agente en tiempo real. En ese tipo de tr\u00e1fico, la prioridad es reducir latencia en cada turno y simplificar la escalabilidad de los servicios de inferencia.<\/p>\n<p>Por eso eligi\u00f3 un modelo basado en transceiver. En este dise\u00f1o, un servicio WebRTC en el edge termina la conexi\u00f3n del cliente y luego convierte medios y eventos a protocolos internos m\u00e1s simples para inferencia del modelo, transcripci\u00f3n, generaci\u00f3n de voz, uso de herramientas y orquestaci\u00f3n. El transceiver es, adem\u00e1s, el \u00fanico que mantiene el estado de la sesi\u00f3n WebRTC, incluidas comprobaciones ICE, handshake DTLS, claves SRTP y ciclo de vida de la sesi\u00f3n.<\/p>\n<h3>El choque entre WebRTC y Kubernetes<\/h3>\n<p>La primera implementaci\u00f3n de OpenAI fue un servicio \u00fanico en Go, basado en Pion, que manejaba tanto se\u00f1alizaci\u00f3n como terminaci\u00f3n de medios. Ese sistema ya impulsa la voz de ChatGPT, el endpoint WebRTC de la Realtime API y varios proyectos de investigaci\u00f3n, seg\u00fan explic\u00f3 la empresa.<\/p>\n<p>El problema apareci\u00f3 cuando se intent\u00f3 operar ese dise\u00f1o como el resto de la infraestructura de OpenAI, sobre Kubernetes. El modelo convencional de WebRTC, que usa un puerto por sesi\u00f3n, result\u00f3 poco compatible con entornos donde las cargas se escalan, se mueven entre hosts y se reprograman con frecuencia.<\/p>\n<p>La compa\u00f1\u00eda describe primero el problema de agotamiento de puertos. A alta concurrencia, el sistema necesita exponer y gestionar rangos enormes de puertos UDP p\u00fablicos. Eso no solo complica la configuraci\u00f3n de balanceadores y health checks, tambi\u00e9n ampl\u00eda la superficie externa que debe ser asegurada y auditada.<\/p>\n<p>Adem\u00e1s, el autoscaling se vuelve fr\u00e1gil si cada pod necesita reservar y anunciar un rango estable de puertos. Por eso, se\u00f1ala OpenAI, muchos sistemas WebRTC evolucionan hacia un \u00fanico puerto UDP por servidor con demultiplexaci\u00f3n a nivel de aplicaci\u00f3n detr\u00e1s de ese puerto.<\/p>\n<p>Sin embargo, ese esquema tambi\u00e9n tiene l\u00edmites. Aunque reduce la cantidad de puertos, no resuelve del todo el problema de mantener la propiedad de cada sesi\u00f3n dentro de una flota compartida. ICE y DTLS son protocolos con estado, y el proceso que crea una sesi\u00f3n debe seguir recibiendo los paquetes de esa misma sesi\u00f3n para validar conectividad, completar el handshake, descifrar SRTP y gestionar cambios posteriores como reinicios de ICE.<\/p>\n<div class=\"diari-in-content-middle diari-entity-placement\" id=\"diari-3094895054\">\n<div id=\"diari-1222271268\" data-diari-trackid=\"195495\" data-diari-trackbid=\"1\" class=\"diari-target diari-target\"><\/div>\n<\/div>\n<p>Si los paquetes terminan en otra instancia, la configuraci\u00f3n puede fallar o el flujo de medios puede romperse. De ah\u00ed surgi\u00f3 el objetivo central: mantener una superficie UDP p\u00fablica peque\u00f1a y fija, pero sin perder la capacidad de enviar cada paquete al transceiver exacto que posee la sesi\u00f3n correspondiente.<\/p>\n<h3>La arquitectura relay m\u00e1s transceiver<\/h3>\n<p>La respuesta de OpenAI fue separar el enrutamiento de paquetes de la terminaci\u00f3n del protocolo. En la arquitectura desplegada, la se\u00f1alizaci\u00f3n sigue llegando al transceiver para configurar la sesi\u00f3n, mientras que los medios entran primero a trav\u00e9s de un relay. Ese relay es una capa ligera de reenv\u00edo UDP con una huella p\u00fablica reducida.<\/p>\n<p>El relay no descifra medios, no ejecuta m\u00e1quinas de estado ICE y no participa en la negociaci\u00f3n de c\u00f3decs. Su tarea consiste en leer la metadata m\u00ednima del paquete necesaria para elegir un destino y luego reenviar el tr\u00e1fico al transceiver que ya posee la sesi\u00f3n. Desde el lado del cliente, OpenAI afirma que no cambia nada en la sem\u00e1ntica de WebRTC.<\/p>\n<p>El paso m\u00e1s importante es enrutar el primer paquete. Como todav\u00eda no existe una sesi\u00f3n en la propia ruta de medios, el relay debe tomar una decisi\u00f3n sin depender de una consulta externa en la ruta cr\u00edtica. Para resolverlo, la compa\u00f1\u00eda us\u00f3 un elemento ya presente en WebRTC: el fragmento de nombre de usuario ICE, conocido como ufrag.<\/p>\n<p>Seg\u00fan explica OpenAI, el ufrag del lado del servidor se genera con la metadata justa para que el relay pueda inferir el cl\u00faster de destino y el transceiver propietario. Durante la se\u00f1alizaci\u00f3n, el transceiver asigna el estado de la sesi\u00f3n y devuelve un VIP del relay compartido junto a un puerto UDP en la respuesta SDP. Ese VIP funciona como una direcci\u00f3n estable hacia la flota de relay.<\/p>\n<p>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\u00e9s, una vez creada la sesi\u00f3n en el relay, los paquetes posteriores de DTLS, RTP y RTCP fluyen sin necesidad de volver a decodificar el ufrag.<\/p>\n<p>El estado del relay se mantiene deliberadamente m\u00ednimo. OpenAI dice que solo conserva una sesi\u00f3n en memoria para guiar el reenv\u00edo, contadores para monitoreo y temporizadores para expiraci\u00f3n y limpieza. Si un relay se reinicia y pierde esa sesi\u00f3n, un nuevo paquete STUN puede reconstruirla desde la pista de enrutamiento incluida en el ufrag. Para acelerar a\u00fan m\u00e1s la recuperaci\u00f3n, la empresa utiliza una cach\u00e9 de Redis con el mapeo entre la IP y puerto del cliente y la IP y puerto del transceiver.<\/p>\n<h3>Ingreso global y mejoras de rendimiento<\/h3>\n<p>Una vez reducida la superficie UDP p\u00fablica a un conjunto peque\u00f1o de direcciones y puertos estables, OpenAI despleg\u00f3 el mismo patr\u00f3n de relay de forma global. La compa\u00f1\u00eda llama a esa capa Global Relay, una flota de puntos de ingreso distribuidos geogr\u00e1ficamente que aplican el mismo comportamiento de reenv\u00edo de paquetes.<\/p>\n<p>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\u00e1ficamente como en topolog\u00eda de red, disminuye la latencia, se reduce el jitter y caen las r\u00e1fagas evitables de p\u00e9rdida antes de que el tr\u00e1fico alcance el backbone interno.<\/p>\n<p>Para la se\u00f1alizaci\u00f3n, OpenAI indic\u00f3 que usa direccionamiento geogr\u00e1fico y de proximidad de Cloudflare. As\u00ed, la solicitud inicial por HTTP o WebSocket llega a un cl\u00faster de transceivers cercano. Ese contexto define d\u00f3nde se ubicar\u00e1 la sesi\u00f3n y qu\u00e9 punto de ingreso de Global Relay se anunciar\u00e1 al cliente en la respuesta SDP.<\/p>\n<p>En cuanto a implementaci\u00f3n, 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\u00faltiples workers sobre el mismo puerto UDP, runtime.LockOSThread para fijar goroutines lectoras a hilos espec\u00edficos del sistema operativo, y buffers preasignados para reducir asignaciones y presi\u00f3n del recolector de basura.<\/p>\n<p>OpenAI asegura que ese dise\u00f1o ya maneja su tr\u00e1fico global de medios en tiempo real con una huella de relay relativamente peque\u00f1a. Por eso, al menos por ahora, decidi\u00f3 conservar un enfoque m\u00e1s simple y no dar el salto a rutas m\u00e1s complejas de bypass del kernel.<\/p>\n<h3>Qu\u00e9 concluye OpenAI de este redise\u00f1o<\/h3>\n<p>En la pr\u00e1ctica, 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\u00fablicos para cada pod o sesi\u00f3n.<\/p>\n<p>La compa\u00f1\u00eda tambi\u00e9n presenta esta decisi\u00f3n como una validaci\u00f3n de su enfoque sin SFU para el caso de uso predominante. Dado que la mayor\u00eda 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\u00f3, en su opini\u00f3n, la opci\u00f3n correcta por defecto.<\/p>\n<p>Entre los aprendizajes m\u00e1s relevantes, OpenAI destaca cuatro ideas. La primera es preservar la sem\u00e1ntica est\u00e1ndar del protocolo en el edge para no romper interoperabilidad con navegadores y m\u00f3viles. La segunda es mantener los estados dif\u00edciles de la sesi\u00f3n en un solo lugar, concentrados en el transceiver.<\/p>\n<p>La tercera es utilizar informaci\u00f3n ya disponible en la propia configuraci\u00f3n, en este caso el ufrag de ICE, para lograr enrutamiento determinista del primer paquete sin introducir dependencias adicionales en la ruta cr\u00edtica. La cuarta es optimizar primero para el caso com\u00fan antes de asumir una complejidad mayor con tecnolog\u00edas de kernel bypass.<\/p>\n<p>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\u00f3 cambiar profundamente la forma en que despliega WebRTC, pero sin alterar lo que los clientes esperan de ese est\u00e1ndar.<\/p>\n<div class=\"footer-entry-meta\"><\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>OpenAI detall\u00f3 c\u00f3mo redise\u00f1\u00f3 su infraestructura de WebRTC para que la voz de ChatGPT y su Realtime API funcionen con menor latencia y a escala [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":136094,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,1],"tags":[285,5690,1872,11123,1268,57,11140,575],"class_list":["post-136093","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-crypto","category-noticias","tag-crypto","tag-escalar","tag-global","tag-latencia","tag-noticias","tag-openai","tag-redujo","tag-revela"],"_links":{"self":[{"href":"https:\/\/pongara.net\/news\/wp-json\/wp\/v2\/posts\/136093","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pongara.net\/news\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/pongara.net\/news\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/pongara.net\/news\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/pongara.net\/news\/wp-json\/wp\/v2\/comments?post=136093"}],"version-history":[{"count":0,"href":"https:\/\/pongara.net\/news\/wp-json\/wp\/v2\/posts\/136093\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/pongara.net\/news\/wp-json\/wp\/v2\/media\/136094"}],"wp:attachment":[{"href":"https:\/\/pongara.net\/news\/wp-json\/wp\/v2\/media?parent=136093"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/pongara.net\/news\/wp-json\/wp\/v2\/categories?post=136093"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/pongara.net\/news\/wp-json\/wp\/v2\/tags?post=136093"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}