OpenAI explica como reformulou o WebRTC para IA de voz com baixa latência

A OpenAI revelou detalhes de como refez sua infraestrutura WebRTC para os recursos de voz do ChatGPT e da Realtime API. O objetivo era simples: evitar que a conversa com a IA se desfaça por causa de atrasos de rede, mesmo sob carga global e com centenas de milhões de usuários.

Por que a abordagem antiga não servia

Para uma IA de voz, não basta reconhecer a fala e gerar uma resposta rapidamente. A conversa precisa andar no ritmo da fala humana: sem pausas constrangedoras, sem interrupções cortadas e sem um segundo de espera antes de o modelo reagir. A OpenAI afirma que, na sua escala, isso se resume a três requisitos ao mesmo tempo: alcance global para mais de 900 milhões de usuários ativos semanais, estabelecimento rápido da conexão e tempo de ida e volta do áudio baixo e estável.

"A IA de voz só parece natural quando a conversa avança na velocidade da fala."

O problema era que a abordagem clássica de WebRTC combina mal com a infraestrutura de nuvem da OpenAI. Se cada sessão precisa de uma porta UDP pública própria, com alta concorrência é preciso abrir e proteger faixas enormes de portas. Isso é incômodo para o Kubernetes, complica o balanceamento de carga, deixa o autoscaling mais frágil e aumenta a superfície de ataque. Além disso, as sessões ICE e DTLS continuam stateful: os pacotes precisam chegar exatamente ao processo que detém cada conexão.

Relay mais transceiver

Depois de comparar várias opções, a OpenAI abandonou o esquema em que o modelo atua como um participante WebRTC comum via SFU. O cenário típico da sua carga é um para um: um usuário fala com um modelo, ou um cliente conversa com um agente em tempo real. Por isso, a empresa escolheu o modelo transceiver: um serviço de borda encerra a conexão WebRTC do cliente e depois converte mídia e eventos para protocolos internos de inferência, transcrição, síntese de voz, chamada de ferramentas e orquestração.

A ideia central da nova arquitetura é separar o roteamento de pacotes do encerramento do protocolo. O relay virou uma camada UDP leve na entrada, com uma pegada de rede pública pequena, enquanto o transceiver continuou sendo o componente stateful que mantém ICE, DTLS, chaves SRTP e todo o ciclo de vida da sessão. O relay não descriptografa a mídia, não negocia codecs e não tenta se passar por um peer WebRTC. Ele apenas lê uma quantidade mínima de metadados do pacote e encaminha o tráfego para onde a sessão correta vive.

O truque mais interessante envolve o primeiro pacote. A OpenAI usa o ICE username fragment, ou ufrag, e embute nele exatamente a quantidade de informação de roteamento de que o relay precisa para escolher o cluster e o transceiver específico. Durante a sinalização, o cliente recebe um VIP de relay compartilhado e uma porta UDP fixa, e o primeiro pacote STUN dá ao sistema dados suficientes para enviar o fluxo imediatamente pelo caminho certo, sem consultar um serviço de lookup externo. Depois que a rota é estabelecida, o mapeamento de endereços também é guardado no Redis, para se recuperar rapidamente após um reinício do relay.

Como a latência foi reduzida

Quando a superfície UDP pública foi reduzida a um pequeno número de endereços e portas estáveis, a OpenAI escalou o mesmo esquema globalmente. Assim surgiu o Global Relay, um conjunto distribuído de pontos de entrada que recebem pacotes mais perto do usuário e os levam à rede da OpenAI sem um primeiro salto desnecessário por uma região distante. Para a sinalização, a empresa usa o roteamento geográfico e por proximidade da Cloudflare, de modo que tanto a requisição HTTP/WebSocket inicial quanto a primeira verificação ICE chegam ao cluster adequado mais próximo.

• Uma camada UDP pública pequena e fixa em vez de milhares de portas abertas
• Roteamento do primeiro pacote por meio de dados já embutidos no ICE ufrag
• Um socket UDP compartilhado no lado do transceiver em vez de um socket por sessão
• Estado em memória de curta duração mais cache Redis para recuperar rapidamente a rota
• `SO_REUSEPORT`, fixação de threads a threads do SO e minimização de alocações para alto throughput

A OpenAI escreveu o relay em Go e deixou deliberadamente suas responsabilidades restritas: ele não encerra a sessão WebRTC, apenas analisa rapidamente os cabeçalhos necessários, atualiza o estado mínimo do fluxo e encaminha os pacotes. A empresa destaca que não precisou de kernel bypass: uma otimização cuidadosa com `SO_REUSEPORT`, thread pinning e redução de cópias desnecessárias bastou para atender o tráfego global de mídia em tempo real com uma camada de relay relativamente pequena e sem abrir mão do comportamento padrão do WebRTC nos clientes.

O que isso significa

Para os usuários, tudo isso se resume a "o modo de voz ficou mais responsivo", mas para o mercado importa mais outra coisa: a OpenAI mostrou como construir uma IA de voz em massa sobre o WebRTC padrão, sem clientes personalizados e sem um crescimento doloroso da infraestrutura de rede. É uma boa referência para quem desenvolve assistentes em tempo real, agentes de voz e produtos em que meio segundo de latência já estraga toda a experiência do usuário.