OpenAI a 4 de maio publicou detalhes da infraestrutura de IA de voz—para suportar os serviços de IA de voz para 900 milhões de utilizadores ativos semanais (Weekly Active Users). O grupo redesenhou a pilha WebRTC, passando a camada de ligação de media da arquitetura tradicional “um porto para uma sessão” para uma ponte (relay) translúcida escrita em Go e centralizando todo o estado das sessões WebRTC num serviço chamado “transceiver”. O blogue oficial da OpenAI explica que esta arquitetura suporta, em simultâneo, o modo de voz do ChatGPT, a Realtime API e vários projetos de investigação. Para qualquer equipa a fazer engenharia de IA de voz, este caso é uma rara fonte técnica sobre “como a IA de voz em escala global se sustenta”.
Três limitações técnicas: a WebRTC tradicional bate em limites na escala da OpenAI
A equipa de engenharia da OpenAI aponta de forma explícita três limitações que “colidem entre si” após a amplificação para escala:
A forma tradicional de terminar media “uma sessão, um porto” (per-session port termination) não é adequada para a infraestrutura da OpenAI—quando cada semana 900 milhões de utilizadores podem iniciar simultaneamente sessões de voz e cada uma ocupa um porto, o desenho esgota os recursos de rede
ICE (Interactive Connectivity Establishment) e DTLS (Datagram Transport Layer Security) com estado—assumindo a necessidade de um detentor estável. Numa arquitetura distribuída, se o estado da sessão for repartido por vários serviços, a tolerância a falhas e a migração tornam-se extremamente complexas
O routing global tem de manter baixa latência no primeiro salto (first-hop latency)—a “naturalidade” da IA de voz depende da fluidez do turn-taking (mudança de turnos na conversa). Um primeiro salto acima de 100ms torna-se claramente “travado”
A lista de requisitos da OpenAI também é clara: alcance global (cobrir 900 milhões+ de utilizadores), criação rápida de sessão (o utilizador abre a boca e consegue falar), e baixo e estável tempo de ida e volta do media (incluindo baixa variação de atraso e perda de pacotes).
Solução: relay fina em Go + serviço transceiver centralizado
A arquitetura da OpenAI divide-se em duas camadas:
Camada Relay—escrita em Go, implementada de forma deliberadamente simples. Um processo Go comum: lê pacotes via socket, atualiza um pequeno estado de tráfego, encaminha os pacotes, sem terminar WebRTC. Esta é a chave para permitir que o relay escale horizontalmente—não precisa de manter o estado completo da WebRTC, a interoperabilidade entre relays é sem dor, e uma falha num único ponto não interrompe toda a sessão.
Camada Transceiver—o único serviço que detém o estado das sessões WebRTC. Inclui verificação de ligação ICE, handshake DTLS, chaves de encriptação SRTP e gestão do ciclo de vida da sessão. Ao concentrar estes estados num único serviço, a atribuição da sessão torna-se mais fácil de inferir; os serviços backend podem escalar como serviços “normais”, sem terem de ser, cada um, pares WebRTC.
O engenho deste desenho está no facto de separar rigorosamente “as partes que precisam de estado” e “as partes sem estado”. O relay é um plano de dados sem estado (pode ser copiado em grande quantidade); o transceiver é um plano de controlo com estado (pouco em volume, mas com estado completo). Esta divisão também permite que a OpenAI escale horizontalmente à medida do uso, sem ter de recear uma explosão do número de ligações WebRTC.
Porque 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 com uma lógica deliberadamente estreita. Por trás desta escolha estão razões de engenharia:
As goroutines do Go suportam nativamente tarefas IO-bound, como “tratar dezenas de milhares de ligações por porto”, sem precisar de um ciclo de eventos complexo
O pacote net da biblioteca padrão consegue ler diretamente pacotes UDP, sem necessidade de fazer ligação a bibliotecas C
Após compilação, resulta num único binário estático—simples de implementar, contentorizar e levar a arquiteturas diferentes (x86/ARM)
A gestão de memória do Go é favorável a “muitos objetos de curta duração” (cada pacote precisa de ser interpretado). As pausas do GC são controláveis
Isto explica também por que o Go tem vindo a aumentar continuamente a sua penetração na camada de infraestrutura moderna (Cloudflare, Tailscale, HashiCorp, etc.)—não porque “o Go seja mais incrível do que outra linguagem”, mas porque “no cenário de infra IO-bound, com necessidade de expansão horizontal, o Go é o mais direto para escrever”.
Contraponto da Cloudflare: o campo de batalha da Realtime Voice AI
A Cloudflare, ao mesmo tempo (no início de maio), também publicou um blogue técnico intitulado “Cloudflare é o melhor lugar para construir agentes de voz em tempo real”, e apresentou a sua própria solução em contraponto à OpenAI. As duas abordagens divergem:
OpenAI: construir internamente a pilha WebRTC relay/transceiver, sem depender de terceiros e incorporando também a camada de media na sua própria tecnologia
Cloudflare: tratar o serviço de media WebRTC como uma extensão da sua plataforma de Workers, oferecendo aos programadores uma infraestrutura “tudo-em-um”
Para equipas de aplicação de IA de média e pequena dimensão, a abordagem da Cloudflare é mais prática—chamam diretamente APIs, sem necessidade de construir infraestrutura de WebRTC. Para equipas com a escala da OpenAI, construir por conta própria é um caminho obrigatório—SLA de serviços externos, estruturas de faturação e distribuição geográfica não conseguem alinhar-se perfeitamente.
Observações futuras: transceiver em código aberto, escala da Realtime API, resposta dos concorrentes
As principais prioridades de observação para a próxima fase:
Se a OpenAI vai disponibilizar em código aberto a parte do transceiver/relay—concorrentes como Anthropic, Google e xAI também estão a construir pilhas de voz próprias. Se a OpenAI abrir o código, pode tornar-se um padrão da indústria
Faturação e escala da Realtime API—atualmente depende principalmente de subscrições do ChatGPT para diluir custos. Se as receitas da API crescerem, passará a ser uma linha de produto independente?
Correspondência da Anthropic e da Google—Claude e Gemini já suportam voz, mas em termos de latência e escala ainda existe uma diferença face à OpenAI. Esta revelação técnica vai acelerar o seguimento da equipa de engenharia deles?
Para programadores de aplicações de IA em Taiwan, a IA de voz é um campo-chave da segunda metade de 2026—cenários como apoio ao cliente, educação, automóvel e IoT precisam de conversas com baixa latência. A revelação de engenharia da OpenAI desta vez é uma das referências mais importantes para avaliar “se deve construir a pilha de voz ou usar APIs de terceiros”.
Este artigo, OpenAI reestrutura a pilha WebRTC de voz: 900M de utilizadores ativos semanais, relay em Go como núcleo, apareceu pela primeira vez em 鏈新聞 ABMedia.
