Como criámos em seis meses um sistema em tempo real para uma IA de voz responsiva

Na IA de voz, saber quando falar é mais difícil do que parece. Os seres humanos passam a palavra uns aos outros sem esforço numa fração de segundo, mas os sistemas anteriores de IA de voz não conseguiam acompanhar este ritmo. A sua arquitetura baseada em turnos dependia de pequenos modelos conhecidos como detetores de turnos, que enfrentavam uma tarefa ingrata: se decidissem demasiado cedo, interrompiam o utilizador; se decidissem demasiado tarde, a resposta parecia lenta. Só depois de o detetor tomar a decisão é que o LLM, muito maior, podia começar a trabalhar.

O GPT‑Live⁠, o nosso sistema de voz de terceira geração, remove o detetor de turnos do percurso de áudio. O seu modelo de voz é full-duplex, o que significa que consegue ouvir e falar ao mesmo tempo. Isto elimina a necessidade de um detetor separado e torna a conversa mais imediata e natural. Quando é necessário um raciocínio mais profundo ou utilizar ferramentas, o GPT‑Live também pode consultar os nossos modelos de fronteira, como o GPT‑5.5, sem interromper o fluxo da conversa. Em conjunto, estas capacidades conferem ao GPT‑Live uma combinação sem precedentes de rapidez de resposta e inteligência na conversação.

Proporcionar esta experiência em grande escala exigiu uma nova arquitetura de sistema otimizada para baixa latência. Ao contrário da inferência típica de pedido e resposta, o nosso sistema transmite o áudio recebido para o modelo de voz e a fala de saída de volta ao utilizador, enquanto trata a delegação num percurso assíncrono separado. Nos últimos seis meses, reformulámos a inferência do modelo, a gestão do contexto e o transporte de conteúdos multimédia para manter a fala a fluir sem interrupções de extremo a extremo.

A arquitetura também cria uma fronteira clara entre o percurso de voz principal e a lógica aplicacional. Isto facilita a personalização do comportamento da aplicação sem afetar a rapidez de resposta. Esta base sustenta um conjunto crescente de capacidades no ChatGPT Modo Voz, incluindo a recém-lançada capacidade de controlar o computador e coordenar os agentes na aplicação ChatGPT para computador.

Neste artigo, explicaremos porque é que os sistemas anteriores baseados em turnos não satisfaziam as nossas necessidades e como concebemos o novo sistema para responder rapidamente em todas as camadas. Abordaremos a inferência com estado, a gestão dinâmica do contexto, a delegação assíncrona e a otimização ao nível do protocolo, que funcionam em conjunto para fazer com que o GPT‑Live pareça verdadeiramente ao vivo.

As arquiteturas de voz anteriores herdaram a natureza baseada em turnos dos LLM de texto, mas cada turno era representado por um bloco de áudio distinto, em vez de texto. Nos sistemas em cascata, a conversão de voz em texto, o LLM e a conversão de texto em voz eram executados sequencialmente. Esta sequência acrescentava latência e ignorava sinais como o tom e o ritmo.

Os modelos de voz-para-voz melhoraram esta abordagem ao processarem o áudio diretamente. Treinar o modelo para compreender e gerar fala de forma nativa permitiu-lhe preservar detalhes perdidos na transcrição e responder mais depressa. Mas o sistema continuava a depender do detetor de turnos para decidir quando podia começar a inferência. O modelo tratava uma parte maior da interação, mas esta continuava a basear-se em turnos.

O GPT‑Live coloca o modelo de voz no controlo da conversa: o áudio entra e sai do modelo, enquanto o raciocínio mais profundo e a utilização de ferramentas ocorrem de forma assíncrona. A principal função do sistema é manter um ciclo multimédia ininterrupto. Outras tarefas, como invocar modelos de fronteira e guardar a conversa de forma persistente, ocorrem fora do percurso em direto.

Manter este ciclo multimédia ininterrupto nem sempre é simples. Qualquer atraso no transporte, processamento ou inferência pode tornar-se numa pausa ou num artefacto audível. Um sistema anterior baseado em turnos conseguia tolerar alguma variação no momento de chegada de um bloco de áudio. No entanto, um sistema multimédia em direto tem de entregar cada fotograma de áudio dentro do prazo.

O trabalho anterior no ChatGPT Modo Voz e na Realtime API proporcionou-nos uma base importante. Já tínhamos reconstruído a nossa infraestrutura de voz⁠ para transmitir áudio e vídeo diretamente de e para os nossos sistemas, com uma latência mais baixa e previsível. O GPT‑Live levou essa conceção mais longe, transmitindo conteúdos multimédia até ao modelo através de um novo sistema de inferência com estado, criado para conversas contínuas.

Contudo, a inferência em fluxo era apenas parte da solução. Para que funcionasse bem em produção, também tivemos de garantir a entrega fiável do áudio, desde o cliente até à pilha de inferência, e enfrentar os desafios da manutenção de estado.

Uma das primeiras decisões que tomámos foi separar especificamente o fluxo multimédia da lógica aplicacional e de negócio. O áudio circula entre o cliente e o modelo de voz através de um percurso rápido dedicado. A delegação, a utilização de ferramentas e outras tarefas aplicacionais ocorrem atrás de uma fronteira RPC assíncrona. Uma chamada lenta a uma ferramenta ou a um serviço de backend pode atrasar o próprio resultado, mas não consegue bloquear o fluxo multimédia.

Esta separação também proporciona ao sistema uma fronteira clara para personalização. As aplicações podem alterar as suas ferramentas, políticas e comportamento no backend sem afetar o frontend multimédia responsável por manter o áudio em movimento. O percurso em direto permanece pequeno, previsível e centrado no trabalho que tem de acontecer em tempo real.

Escrevemos o frontend multimédia e a lógica de inferência em Go, substituindo uma implementação anterior de asyncio em Python. Isto melhorou significativamente a fluidez da entrega de fotogramas, com o p95 do novo sistema a igualar o p50 do sistema anterior.

O WebRTC fornece a base de transporte. Foi concebido para conteúdos multimédia de baixa latência e consegue continuar a funcionar mesmo com perda de pacotes, desvio do relógio e alterações na ligação do cliente. Se os pacotes chegarem atrasados, o WebRTC pode alongar subtilmente o áudio para evitar falhas e, depois, acelerar brevemente a reprodução para voltar a acompanhar o tempo real.

Ao minimizar a colocação em memória intermédia e os bloqueios em todo o sistema, conseguimos proporcionar a resposta em menos de um segundo que as pessoas esperam de uma conversa.

A inferência com estado implica os seus próprios compromissos operacionais. Uma sessão de voz pode permanecer ativa durante muito tempo, mas o seu contexto cresce continuamente e as instâncias do modelo são iniciadas e encerradas em função da procura.

Para responder a estas questões, criámos um mecanismo de transferência transparente entre instâncias do modelo. Quando é necessária uma transição, podemos preparar uma instância de substituição do modelo em paralelo com a existente, pré-preenchê-la com o contexto atual da sessão, executar a inferência em ambas em paralelo e fazer a transição quando a nova instância estiver totalmente pronta.

O mesmo mecanismo básico também suporta a compactação dinâmica do contexto. À medida que uma conversa decorre, o contexto acumulado pode acabar por exceder o limite de contexto do modelo. A compactação pode reduzir o tamanho do contexto para respeitar o limite, mas a operação demora algum tempo. Além disso, como altera o contexto anterior, também invalida a cache de chave-valor (KV) do modelo, que armazena as chaves e os valores de atenção dos tokens processados anteriormente. Reconstruir esse estado exige um novo pré-preenchimento, o que introduz um atraso adicional.

Em vez disso, tratamos a compactação como mais uma transição gerida. Enquanto a instância original do modelo continua a conversar, o sistema compacta o contexto e prepara uma instância de substituição do modelo com o novo contexto. Quando essa instância estiver pronta, podemos fazer a transição sem qualquer interrupção dos conteúdos multimédia. Isto permite ao sistema suportar chamadas prolongadas, compactando o contexto sempre que necessário.

O trabalho mais pesado mantém-se fora do percurso em direto, pelo que, mesmo durante uma transferência, a conversa nunca perde o ritmo.

A capacidade do GPT‑Live para invocar modelos de fronteira existentes dá-lhe muito poder, separando efetivamente o «falar» do «pensar» mais aprofundado. Mas fazer com que esta arquitetura de dois modelos parecesse um único sistema exigiu a resolução de dois problemas de engenharia relacionados.

Primeiro, os resultados têm de chegar suficientemente depressa para serem úteis na conversa em curso, pelo que tivemos de minimizar a latência em todo o percurso de delegação, desde o encaminhamento e o processamento do prompt até à inferência e às chamadas de ferramentas. Ao mesmo tempo, outros sistemas do produto continuam a precisar de mensagens distintas, pelo que tivemos de representar a conversa em curso num formato que conseguissem compreender.

Quando é enviada uma delegação, otimizamos o tempo até o modelo de fronteira produzir algo útil para a conversa. O modelo de voz consegue manter brevemente a conversa a fluir enquanto um modelo de fronteira raciocina ou utiliza ferramentas, mas não consegue ocultar uma resposta arbitrariamente lenta. Por isso, tratámos todo o ciclo de delegação — encaminhamento, processamento do prompt, inferência e chamadas de ferramentas — como parte do orçamento de tempo de resposta.

A primeira otimização consiste em preparar o modelo de fronteira e todas as ferramentas de que necessita antes de a delegação ser solicitada. Quando uma sessão de voz começa, o servidor da aplicação cria uma sessão de inferência para o modelo de fronteira e pré-preenche-a com o contexto inicial da conversa, garantindo que o prompt foi totalmente processado antes do primeiro pedido delegado.

Depois, mantemos essa sessão de inferência disponível durante toda a conversa por voz e utilizamos afinidade de sessão estável para os pedidos seguintes. Em conjunto com a colocação de prompts em cache, estas técnicas melhoram a latência e permitem recuperar facilmente de uma falha num worker.

O esforço de raciocínio, os limites de saída, os esquemas das ferramentas e as interações entre o modelo e as ferramentas também afetam o momento em que a conversa recebe um resultado útil, e ajustámos estes parâmetros para obter respostas mais rápidas. Ao minimizar o trabalho necessário no percurso de delegação, permitimos que o modelo de voz incorporasse rapidamente os resultados dos nossos modelos de fronteira.

Embora o modelo de voz funcione com fluxos contínuos de fala, muitos dos sistemas à sua volta continuam a funcionar com turnos do utilizador e do assistente, incluindo a interface de conversação do ChatGPT e partes da nossa infraestrutura de análise e segurança. Por isso, o servidor da aplicação separa a conversa sobreposta e, por vezes, ambígua em mensagens distintas.

À medida que o áudio chega, o servidor utiliza transcrições parciais e sinais temporais para inferir quem tem a palavra e criar uma fila de mensagens. A mensagem mais recente permanece provisória; o texto, os tempos e a atribuição do orador podem mudar à medida que chega mais fala. Quando um orador mantém a palavra durante tempo suficiente para que a atribuição seja fiável, o servidor finaliza a mensagem correspondente.

A sobreposição de oradores torna este processo mais complexo. Uma breve confirmação do assistente enquanto o utilizador fala (por exemplo, «mm hmm» ou «okay») não deve necessariamente tornar-se numa mensagem autónoma. No entanto, uma intervenção relevante do assistente deve muitas vezes tornar-se numa mensagem. Da mesma forma, damos prioridade à coerência das respostas do assistente apresentadas, mesmo quando o utilizador fala a meio.

Todas as políticas de segmentação equilibram atualidade e certeza. Finalizar demasiado cedo produz um histórico fragmentado e uma ordenação instável; esperar demasiado atrasa as transcrições e as funcionalidades que delas dependem. Por isso, o sistema mantém duas perspetivas relacionadas da conversa: uma perspetiva especulativa do estado atual e um registo fidedigno do que foi dito. A vista da conversa na interface da aplicação consegue processar atualizações, pelo que utiliza a perspetiva especulativa. Mas o registo no pipeline de análise exige uma transcrição final.

Assim, o resto do ChatGPT obtém uma perspetiva estável da conversa sem impor a alternância de turnos ao percurso de voz em direto.

A rapidez de resposta começa assim que o utilizador clica no botão. Com o GPT‑Live, o sistema tem de estabelecer o percurso multimédia e começar a enviar áudio através do modelo antes de a conversa poder começar. Isto coloca todas as partes da sequência de arranque no caminho crítico.

Como referido acima, o WebRTC proporciona uma base sólida para o tempo real, mas iniciar uma sessão WebRTC convencional exige um número surpreendente de negociações de protocolo e viagens de ida e volta na rede. O WebRTC é anterior à preocupação em minimizar viagens de ida e volta que orientou protocolos posteriores, como o QUIC. Por isso, os protocolos subjacentes por vezes repetem trabalho quando são utilizados em conjunto. Por exemplo, cada protocolo incluía o seu próprio mecanismo anti-DoS, mesmo quando este não era necessário no contexto da pilha WebRTC completa.

Analisámos a pilha e desenvolvemos o WebRTC Abridged Roundtrip Protocol (WARP⁠(abre numa nova janela)), que reduz o arranque dos conteúdos multimédia e dos dados de seis viagens de ida e volta na rede para apenas uma. O WARP consegue-o através de um conjunto de melhorias de protocolo retrocompatíveis: integração da negociação DTLS no ICE (SPED⁠(abre numa nova janela)), utilização da negociação DTLS 1.3⁠(abre numa nova janela), mais rápida, pré-negociação da negociação SCTP (SNAP⁠(abre numa nova janela)) e pré-negociação dos canais de dados em vez da utilização de DCEP⁠(abre numa nova janela).

Concebemos o WARP como um conjunto de especificações abertas, em colaboração com membros da comunidade WebRTC, para que o ecossistema mais vasto possa beneficiar deste trabalho. Estamos a fazer avançar as propostas através do grupo de trabalho TSVWG da IETF, e o suporte para WARP já foi adicionado ao libwebrtc e ao Pion, estando também em curso esforços noutras implementações de WebRTC.

Depois de otimizarmos a negociação multimédia, restava um atraso evidente: a troca de sinalização utilizada para partilhar parâmetros SDP antes de o WebRTC conseguir estabelecer ligação. Para retirar essa troca do caminho crítico, desenvolvemos o que denominamos Instant Connect. Este sistema negoceia os parâmetros antecipadamente, sem reservar capacidade do servidor nem exigir alterações às implementações WebRTC existentes.

O Instant Connect funciona em paralelo com o fluxo de sinalização padrão. Se os parâmetros pré-negociados forem válidos, o servidor pode materializar a sessão quando chegar o primeiro pacote multimédia. Se estiverem desatualizados ou forem inválidos, o fluxo de sinalização já estará em curso, pelo que o cliente pode recorrer à alternativa sem latência adicional.

Em conjunto, o Instant Connect e o WARP reduzem drasticamente o tempo entre a intenção do utilizador e o início do fluxo multimédia em direto. Com a troca SDP fora do caminho crítico e o WARP a condensar a negociação de transporte, o cliente pode agora iniciar uma sessão com um único pacote UDP. O servidor pode responder de imediato, permitindo que o resto do sistema comece a fazer aquilo que realmente importa ao utilizador: ouvir e responder.

Um sistema pode parecer rápido no papel e, ainda assim, bloquear com tráfego de voz real. Antes de permitir que o GPT‑Live conversasse com os utilizadores, realizámos um teste silencioso que encaminhava uma pequena percentagem, gradualmente crescente, das sessões de ChatGPT Modo Voz em produção tanto para a experiência existente do Modo de voz avançado como para o nosso novo sistema. O Modo de voz avançado continuou a servir os utilizadores normalmente, enquanto o percurso paralelo executava inferência em modo só de leitura. Assim, o sistema ficou exposto a clientes, redes, durações de sessão e distribuições geográficas reais, sem alterar aquilo que os utilizadores ouviam.

Uma das primeiras lições foi que a capacidade não podia ser reduzida à taxa de processamento das GPU. As sessões de voz permanecem abertas e enviam fotogramas continuamente, pelo que os processadores de fluxos do lado da CPU, as filas e os percursos de rede têm de escalar a par da inferência. Sob carga real, um componente auxiliar atingiu a saturação antes do previsto pelas estimativas dos nossos testes de carga, fazendo acumular pedidos de inferência e agravando progressivamente a latência. Mudámos a questão da capacidade de «Quantos pedidos consegue uma GPU processar?» para «Quantas sessões em simultâneo consegue o sistema suportar, mantendo cada fotograma dentro do prazo?»

O teste também tornou a geografia uma preocupação de primeira ordem. Encaminhar uma sessão para capacidade distante pode acrescentar atrasos em vários momentos durante o arranque e a transmissão em fluxo. Começámos a validar as implementações de modelos em conjunto com a capacidade regional e a configuração do encaminhamento de tráfego e, depois, a decompor a latência por origem geográfica. Aproximar a inferência dos utilizadores ajudou, mas também reforçou uma lição mais abrangente: a capacidade de resposta de extremo a extremo depende de todos os serviços no percurso, não apenas do servidor do modelo.

Outras falhas só surgiram ao longo de ciclos de vida de sessão realistas. As sessões prolongadas revelaram pressão sobre a memória e a persistência. As religações puseram à prova a compactação e o restauro do estado. As desconexões normais dos clientes revelaram condições de corrida na negociação de encerramento. Estes problemas raramente surgiam em testes de carga curtos, porque dependiam do tempo, do estado acumulado e do comportamento além das fronteiras entre serviços.

Por fim, os testes em produção obrigaram-nos a melhorar a observabilidade e os controlos de implementação. Encontrámos métricas que confundiam diferentes fontes de latência, painéis cujos valores agregados ocultavam mecanismos individuais com problemas e divergências de configuração entre os sistemas testados e implementados. Em resposta, acrescentámos telemetria mais granular, validação face a configurações comprovadas, aumentos graduais por fases e a capacidade de isolar ou desativar rapidamente percursos individuais. O teste silencioso tornou-se um primeiro ensaio de lançamento: não só para avaliar quanto tráfego o sistema conseguia aceitar, mas também a rapidez com que conseguíamos detetar e conter falhas e recuperar das mesmas.

Levar o GPT‑Live à escala do ChatGPT exigiu um sistema totalmente novo, concebido em torno de um princípio fundamental: a voz tem de fluir. A inferência em fluxo mantém o modelo full-duplex abastecido com áudio. Um percurso dedicado aos conteúdos multimédia garante uma entrega fiável dos fotogramas. A delegação assíncrona permite executar em paralelo um raciocínio mais profundo. Um transporte otimizado mantém a experiência responsiva até chegar ao utilizador.

A arquitetura subjacente ao GPT‑Live já está a tornar-se numa plataforma mais abrangente para interação em tempo real. Sustenta o ChatGPT Modo Voz à medida que este evolui da conversa para a coordenação agêntica e servirá de base à futura API do GPT‑Live. Com o tempo, permitirá que as experiências de voz abranjam mais dispositivos, aplicações e modalidades, sem sacrificar o imediatismo que faz uma conversa por voz parecer ao vivo.

Se estes são os desafios de engenharia que gostaria de resolver, venha trabalhar connosco⁠.