OpenAI 4 de maio divulgou detalhes da infraestrutura de IA de voz — para sustentar serviços de IA de voz para 900 milhões de usuários ativos semanais (Weekly Active Users), redesenhar a pilha WebRTC do time, reescrever a camada de conexão de mídia de uma arquitetura tradicional de “um porto para uma sessão” para um relay de camada fina escrito em Go, e concentrar todo o estado das sessões WebRTC em um serviço chamado “transceiver”. O blog oficial da OpenAI explica que essa arquitetura também dá suporte ao modo de voz do ChatGPT, à Realtime API e a vários projetos de pesquisa. Para qualquer equipe que esteja construindo engenharia de IA de voz, este caso é um raro acervo técnico sobre “como sustentar IA de voz em escala global”.
Três limitações técnicas: WebRTC tradicional bate na parede sob o tamanho da OpenAI
A equipe de engenharia da OpenAI aponta claramente três limitações que “se chocam” quando a escala aumenta:
A forma tradicional de encerramento de mídia “uma sessão, um porto” (per-session port termination) não serve para a infraestrutura da OpenAI — quando até 900 milhões de usuários podem abrir sessões de voz ao mesmo tempo, um design em que cada sessão ocupa um porto esgota recursos de rede
Conversas com ICE (Interactive Connectivity Establishment) e DTLS (Datagram Transport Layer Security) com estado — que precisam de um proprietário estável — em sistemas distribuídos, se o estado da sessão for compartilhado por vários serviços, tolerância a falhas e migração ficam extremamente complexas
Roteamento global precisa manter baixa latência no primeiro salto (first-hop latency) — a “sensação natural” da IA de voz depende do turn-taking (mudança fluida de turno na conversa); se o primeiro salto passar de 100ms, fica perceptível a interrupção
A lista de requisitos da OpenAI também é explícita: alcance global (cobrindo 900 milhões+ de usuários), criação rápida de sessão (o usuário fala e já consegue falar), e baixa e estável média de round-trip time da mídia (incluindo baixa variação de atraso e perda de pacotes).
Solução: relay fino em Go + serviço transceiver centralizado
A arquitetura da OpenAI se divide em duas camadas:
Camada Relay — escrita em Go, implementada de propósito para manter-se simples. Um processo Go comum que lê cabeçalhos de pacotes via socket, atualiza apenas um pequeno estado de fluxo de tráfego, encaminha pacotes e não encerra WebRTC. Essa é a chave para o relay escalar horizontalmente — não precisa manter estado completo do WebRTC, a troca entre relays é praticamente indolor e a falha de um ponto não interrompe a sessão inteira.
Camada Transceiver — o único serviço que possui o estado de sessão WebRTC, incluindo checagem de conexão ICE, handshake DTLS, chaves de criptografia SRTP e gerenciamento do ciclo de vida da sessão. Ao concentrar esses estados em um serviço, fica mais fácil inferir a atribuição da sessão; os serviços de back-end podem escalar como serviços comuns, sem precisar atuar como pares WebRTC.
O requinte desse design está em separar rigorosamente “o que precisa de estado” e “o que não precisa”. O relay é uma camada de dados sem estado (que pode ser copiada em grande quantidade); o transceiver é o plano de controle com estado (pouco em número, mas completo em estado). Essa divisão também permite que a OpenAI escale horizontalmente conforme o uso aumenta, sem se preocupar com uma explosão na quantidade de conexões WebRTC.
Por que usar Go: lógica de escolha para engenharia de IA de voz
O texto da OpenAI explica de forma clara que o relay é escrito em Go e implementado de forma propositalmente estreita. A lógica de engenharia por trás dessa escolha:
Goroutines do Go suportam nativamente tarefas com muitos IOs do tipo “processar milhares de conexões por porto”, sem precisar de um loop de eventos complexo
O pacote net da biblioteca padrão consegue ler pacotes UDP diretamente, sem precisar fazer binding com bibliotecas C
Depois de compilado, vira um binário estático único; implantação, containerização e compatibilidade entre arquiteturas (x86/ARM) ficam simples
O gerenciamento de memória do Go é amigável para “muitos objetos de vida curta” (cada pacote precisa ser interpretado), e as pausas do GC ficam controláveis
Isso também explica por que o Go continua ganhando penetração em camadas modernas de infraestrutura (Cloudflare, Tailscale, HashiCorp etc.) — não é “Go ser melhor que outra linguagem”, e sim “Go ser o mais direto para cenários de infraestrutura com IO-bound e necessidade de expansão horizontal”.
A correspondência da Cloudflare: o campo de batalha do Realtime Voice AI
A Cloudflare também publicou no mesmo período (início de maio) um blog técnico, “Cloudflare is the best place to build real-time voice agents”, e apresentou uma proposta própria em paralelo à OpenAI. As duas rotas divergem:
OpenAI: construir a pilha WebRTC relay/transceiver internamente, sem depender de terceiros, e incluir a camada de mídia no próprio stack técnico
Cloudflare: tratar o serviço de mídia WebRTC como uma extensão do próprio Workers platform, oferecendo aos desenvolvedores infraestrutura “one-stop”
Para equipes menores e médias de aplicação de IA, a rota da Cloudflare é mais prática — basta chamar API, sem precisar construir infraestrutura WebRTC. Para equipes no tamanho da OpenAI, construir internamente é um caminho obrigatório — SLA de serviços externos, estrutura de cobrança e distribuição geográfica não vão conseguir casar totalmente.
Observações futuras: transceiver de código aberto, escala da Realtime API, resposta de concorrentes
Os próximos pontos de observação:
A OpenAI vai abrir código do transceiver/relay — Anthropic, Google, xAI etc. também estão construindo stacks de voz internamente; se a OpenAI abrir, pode virar padrão da indústria
Cobrança e escala da Realtime API — hoje depende principalmente de rateio com a assinatura do ChatGPT; se a receita da API crescer, ela vira uma linha de produto independente?
Correspondência da Anthropic e da Google — o Claude e o Gemini já têm suporte a voz, mas em termos de latência e escala ainda há diferença em relação à OpenAI; a revelação técnica deste caso vai acelerar o avanço de engenharia deles?
Para desenvolvedores de aplicações de IA em Taiwan, a IA de voz é um campo de batalha-chave no segundo semestre de 2026 — cenários como atendimento ao cliente, educação, automotivo e IoT exigem conversas com baixa latência. A revelação de engenharia da OpenAI desta vez é uma das referências mais importantes para julgar “se vale construir o stack de voz ou usar APIs de terceiros”.
Este artigo sobre a OpenAI reestruturando a pilha de voz do WebRTC: 900M de usuários ativos semanais, com relay em Go como núcleo, foi publicado primeiro no 鏈新聞 ABMedia.
