OpenAI explicou como reestruturou o WebRTC para AI de voz de baixa latência

OpenAI revelou detalhes sobre como redesenhou sua infraestrutura WebRTC para os recursos de voz do ChatGPT e da Realtime API. O objetivo era simples: conversas com IA não deveriam quebrar por causa da latência da rede, mesmo sob carga global com centenas de milhões de usuários.

Por que a abordagem anterior não funcionava

Para IA de voz, não é suficiente simplesmente reconhecer fala e gerar rapidamente uma resposta. A conversa deve fluir no ritmo da fala humana: sem pausas incômodas, interrupções cortadas e atrasos de alguns segundos antes da reação do modelo.

OpenAI escreve que na sua escala, isso se resume a três requisitos principais: cobertura global para mais de 900 milhões de usuários ativos semanais, estabelecimento rápido de conexão e baixa latência de ida e volta estável para áudio.

"IA de voz parece natural apenas quando a conversa se move no ritmo da fala."

O problema era que a abordagem WebRTC clássica não se compatibilizava bem com a infraestrutura em nuvem da OpenAI. Se cada sessão precisa de sua própria porta UDP pública, então com alta concorrência você precisa abrir e proteger enormes faixas de portas. Isso é inconveniente para Kubernetes, complica o balanceamento de carga, torna o autoscaling mais frágil e aumenta a superfície de ataque. Enquanto isso, as próprias sessões ICE e DTLS permanecem com estado: os pacotes precisam chegar exatamente ao processo que possui a conexão particular.

Relay mais transceiver

Depois de comparar várias opções, OpenAI abandonou o esquema onde o modelo atua como um participante WebRTC regular através de um SFU. Para sua carga de trabalho, cenários um-para-um são típicos: um usuário fala com um modelo ou um cliente se comunica com um agente em tempo real. Então a empresa escolheu o modelo transceiver: um serviço edge encerra a conexão WebRTC do cliente e traduz mídia e eventos em protocolos internos para inferência, transcrição, síntese de fala, chamada de ferramentas e orquestração.

A ideia-chave da nova arquitetura é separar o roteamento de pacotes do término do protocolo. Relay se tornou uma camada UDP leve na entrada com um pequeno footprint de rede pública, enquanto transceiver permaneceu o componente com estado que mantém ICE, DTLS, chaves SRTP e todo o ciclo de vida da sessão. Relay não descriptografa mídia, não negocia codecs e não tenta fingir ser um peer WebRTC. Ele simplesmente lê a quantidade mínima de metadados do pacote e encaminha o tráfego para onde a sessão necessária reside.

O truque mais interessante envolve o primeiro pacote. OpenAI usa o fragmento de nome de usuário ICE, ou ufrag, e incorpora informações de roteamento suficientes para que o relay selecione o cluster e o transceiver específico. Durante a sinalização, o cliente recebe um VIP relay compartilhado e uma porta UDP fixa, e o primeiro pacote STUN fornece ao sistema dados suficientes para enviar o fluxo pelo caminho correto imediatamente, sem uma chamada separada a um serviço de lookup externo. Após o estabelecimento da rota, o mapeamento de endereços é armazenado adicionalmente em Redis para recuperação rápida após reinicialização do relay.

Como reduziram a latência

Depois que a superfície UDP pública foi reduzida a um pequeno número de endereços e portas estáveis, OpenAI dimensionou esse 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 trazem para a rede OpenAI sem um primeiro salto extra através de uma região distante. Para sinalização, a empresa usa roteamento geográfico e de proximidade do Cloudflare, então tanto a solicitação HTTP/WebSocket inicial quanto a primeira verificação ICE chegam ao cluster mais próximo adequado.

• Camada UDP pública pequena e fixa em vez de milhares de portas abertas
• Roteamento de primeiro pacote através de dados já incorporados no ufrag ICE
• 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 recuperação rápida de rota
• `SO_REUSEPORT`, fixação de thread em threads do SO e alocações minimizadas para alta taxa de transferência

OpenAI escreveu seu relay em Go e deliberadamente o manteve estreito em responsabilidade: não encerra a sessão WebRTC, mas apenas analisa rapidamente os cabeçalhos necessários, atualiza estado de thread mínimo e encaminha pacotes adiante. A empresa enfatiza especificamente que não precisava de bypass de kernel: otimização cuidadosa no nível de `SO_REUSEPORT`, fixação de thread e redução de cópias desnecessárias foi suficiente para lidar com tráfego de mídia em tempo real global com uma camada relay relativamente pequena e sem abandonar o comportamento padrão de WebRTC nos clientes.

O que significa

Para os usuários, tudo isso parece "modo de voz ficou mais responsivo", mas para o mercado, algo mais importa: OpenAI demonstrou como construir IA de voz em escala de massa no topo do WebRTC padrão sem clientes customizados e sem o crescimento penoso da infraestrutura de rede. Este é um bom ponto de referência para desenvolvedores de assistentes em tempo real, agentes de voz e produtos onde a latência de meio segundo já quebra toda a experiência do usuário.