Como criamos em seis meses um sistema em tempo real para IA de voz responsiva

Para a IA de voz, saber quando falar é mais difícil do que parece. As pessoas passam a palavra umas às outras sem esforço em uma fração de segundo, mas os sistemas anteriores de IA de voz não conseguiam acompanhar esse ritmo. A arquitetura baseada em turnos dependia de modelos pequenos, conhecidos como detectores de turno, que enfrentavam uma tarefa ingrata: decidir cedo demais interrompia o usuário; decidir tarde demais fazia a resposta parecer lenta. Somente depois que o detector tomava sua decisão é que o LLM, muito maior, podia começar a trabalhar.

O GPT‑Live⁠, nosso sistema de voz de terceira geração, remove o detector de turnos do caminho de áudio. Seu modelo de voz é full-duplex, ou seja, consegue ouvir e falar ao mesmo tempo. Isso elimina a necessidade de um detector separado e torna a conversa mais imediata e natural. Quando são necessários um raciocínio mais profundo ou o uso de ferramentas, o GPT‑Live também pode consultar nossos modelos de fronteira, como o GPT‑5.5, sem interromper o fluxo da conversa. Juntas, essas capacidades proporcionam ao GPT‑Live uma combinação inédita de agilidade e inteligência na conversa.

Oferecer essa experiência em grande escala exigiu uma nova arquitetura de sistema otimizada para baixa latência. Diferentemente da inferência comum baseada em solicitação e resposta, nosso sistema transmite o áudio recebido para o modelo de voz e a fala gerada de volta ao usuário, enquanto processa a delegação por um caminho assíncrono separado. Nos últimos seis meses, reformulamos a inferência do modelo, o gerenciamento de contexto e o transporte de mídia para manter a fala fluindo sem interrupções de ponta a ponta.

A arquitetura também cria um limite claro entre o caminho principal de voz e a lógica do aplicativo. Isso facilita a personalização do comportamento do aplicativo sem afetar a agilidade das respostas. Essa base viabiliza um conjunto crescente de recursos no ChatGPT Modo Voz, incluindo a recém-lançada capacidade de controlar seu computador e coordenar seus agentes no aplicativo ChatGPT para desktop.

Neste artigo, explicaremos por que os sistemas anteriores baseados em turnos não atendiam às nossas necessidades e como projetamos o novo sistema para responder rapidamente em todas as camadas. Abordaremos inferência com estado, gerenciamento dinâmico de contexto, delegação assíncrona e otimização no nível do protocolo — tudo funcionando em conjunto para fazer o GPT‑Live parecer realmente ao vivo.

As arquiteturas de voz anteriores herdaram dos LLMs de texto a dinâmica baseada em turnos, mas cada turno era representado por um bloco distinto de áudio, e não por texto. Nos sistemas em cascata, a conversão de fala em texto, o LLM e a conversão de texto em fala eram executados em sequência. Essa sequência aumentava a latência e ignorava sinais como o tom e o ritmo.

Os modelos de fala para fala aprimoraram essa abordagem ao processar o áudio diretamente. Treinar o modelo para compreender e gerar fala de forma nativa permitiu preservar detalhes perdidos na transcrição e responder com mais rapidez. Mas o sistema ainda dependia do detector de turnos para decidir quando a inferência poderia começar. O modelo assumia uma parte maior da interação, mas ela continuava baseada em turnos.

O GPT‑Live coloca o modelo de voz no controle da conversa: o áudio entra e sai do modelo, enquanto o raciocínio mais profundo e o uso de ferramentas ocorrem de forma assíncrona. A principal função do sistema é sustentar um ciclo de mídia ininterrupto. Outras tarefas, como acionar modelos de fronteira e persistir a conversa, ocorrem fora do caminho ao vivo.

Manter esse ciclo de mídia ininterrupto nem sempre é simples. Qualquer atraso no transporte, no processamento ou na inferência pode se transformar em uma pausa ou um artefato audível. Um sistema anterior baseado em turnos tolerava alguma variação no momento em que um bloco de áudio chegava. No entanto, um sistema de mídia ao vivo precisa entregar cada quadro de áudio dentro do prazo.

O trabalho anterior no ChatGPT Modo Voz e na Realtime API nos deu uma base importante. Já havíamos reconstruído nossa infraestrutura de voz⁠ para transmitir áudio e vídeo diretamente para dentro e para fora dos nossos sistemas, com latência menor e mais previsível. O GPT‑Live levou esse projeto adiante, transmitindo mídia até o modelo por meio de um novo sistema de inferência com estado, criado para conversas contínuas.

Mas a inferência contínua era apenas parte da solução. Para que ela funcionasse bem em produção, também precisávamos garantir a entrega confiável do áudio, do cliente à pilha de inferência, e lidar com os desafios de manter o estado.

Uma das primeiras decisões foi separar especificamente o fluxo de mídia da lógica do aplicativo e de negócios. O áudio trafega entre o cliente e o modelo de voz por um caminho rápido dedicado. A delegação, o uso de ferramentas e outras tarefas do aplicativo ocorrem além de um limite de RPC assíncrono. Uma chamada lenta de ferramenta ou um serviço de backend pode atrasar o próprio resultado, mas não consegue interromper o fluxo de mídia.

Essa separação também oferece ao sistema um limite claro para personalização. Os aplicativos podem alterar suas ferramentas, políticas e comportamento de backend sem afetar o frontend de mídia responsável por manter o áudio em movimento. O caminho ao vivo permanece enxuto, previsível e concentrado no trabalho que precisa ocorrer em tempo real.

Escrevemos o frontend de mídia e a lógica de inferência em Go, substituindo uma implementação anterior em Python com asyncio. Isso melhorou significativamente a fluidez da entrega dos quadros: o p95 do novo sistema ficou equivalente ao p50 do sistema anterior.

O WebRTC fornece a base de transporte. Ele foi projetado para mídia de baixa latência e consegue continuar operando mesmo com perda de pacotes, desvio de relógio e alterações na conexão do cliente. Se os pacotes chegarem atrasados, o WebRTC pode alongar sutilmente o áudio para evitar lacunas e, depois, acelerar brevemente a reprodução para voltar ao tempo real.

Ao minimizar o armazenamento em buffer e os bloqueios em todo o sistema, conseguimos oferecer a resposta em menos de um segundo que as pessoas esperam de uma conversa.

A inferência com estado tem suas próprias contrapartidas operacionais. Uma sessão de voz pode permanecer ativa por muito tempo, mas seu contexto cresce continuamente, enquanto instâncias do modelo são iniciadas e encerradas conforme a demanda.

Para resolver essas questões, criamos um mecanismo de transição contínua entre instâncias do modelo. Quando uma transição é necessária, podemos aquecer uma instância substituta do modelo junto à existente, preenchê-la previamente com o contexto atual da sessão, executar inferência em ambas em paralelo e fazer a troca quando a nova instância estiver totalmente pronta.

O mesmo mecanismo básico também permite a compactação dinâmica do contexto. À medida que a conversa avança, o contexto acumulado pode acabar ultrapassando o limite de contexto do modelo. A compactação pode reduzir o contexto para que ele caiba no limite, mas essa operação leva tempo. Além disso, por alterar o contexto anterior, ela também invalida o cache de chave-valor (KV) do modelo, que armazena as chaves e os valores de atenção dos tokens já processados. Reconstruir esse estado exige um novo preenchimento prévio, o que gera mais atraso.

Em vez disso, tratamos a compactação como outra transição gerenciada. Enquanto a instância original do modelo continua conversando, o sistema compacta o contexto e prepara uma instância substituta com o novo contexto. Quando essa instância fica pronta, podemos fazer a troca sem interromper a mídia. Isso permite que o sistema mantenha chamadas prolongadas, fazendo a compactação sempre que necessário.

O trabalho pesado fica fora do caminho ao vivo. Assim, mesmo durante uma transição, a conversa segue sem perder o ritmo.

A capacidade do GPT‑Live de acionar modelos de fronteira existentes lhe confere muito poder, separando, na prática, o ato de "falar" do processo mais profundo de "pensar". Mas fazer essa arquitetura de dois modelos parecer um único sistema exigiu resolver dois problemas de engenharia relacionados.

Primeiro, os resultados precisam retornar rápido o bastante para serem úteis durante a conversa. Por isso, tivemos que minimizar a latência em todo o caminho da delegação, do roteamento e processamento do prompt à inferência e às chamadas de ferramentas. Ao mesmo tempo, outros sistemas do produto ainda precisam de mensagens distintas, então tivemos que representar a conversa em andamento de uma forma que eles pudessem entender.

Quando uma delegação é enviada, otimizamos o tempo até que o modelo de fronteira produza algo útil para a conversa. O modelo de voz consegue manter brevemente a conversa em andamento enquanto um modelo de fronteira raciocina ou usa ferramentas, mas não pode ocultar uma resposta excessivamente lenta. Por isso, tratamos todo o ciclo de delegação — roteamento, processamento do prompt, inferência e chamadas de ferramentas — como parte do orçamento de tempo de resposta.

A primeira otimização é preparar o modelo de fronteira e todas as ferramentas necessárias antes que a delegação seja solicitada. Quando uma sessão de voz começa, o servidor do aplicativo cria uma sessão de inferência para o modelo de fronteira e a preenche previamente com o contexto inicial da conversa, garantindo que o prompt tenha sido totalmente processado antes da primeira solicitação delegada.

Depois, mantemos essa sessão de inferência disponível durante toda a conversa por voz e usamos afinidade de sessão estável nas solicitações seguintes. Junto ao cache de prompts, essas técnicas reduzem a latência sem dificultar a recuperação de falhas de um worker.

O esforço de raciocínio, os limites de saída, os esquemas das ferramentas e as idas e vindas entre modelo e ferramenta também afetam o momento em que a conversa recebe um resultado útil; ajustamos esses fatores para obter respostas mais rápidas. Ao minimizar o trabalho necessário no caminho da delegação, permitimos que o modelo de voz incorporasse rapidamente os resultados dos nossos modelos de fronteira.

Embora o modelo de voz opere com fluxos contínuos de fala, muitos dos sistemas ao redor ainda funcionam com turnos do usuário e do assistente, incluindo a interface de conversa do ChatGPT e partes da nossa infraestrutura de análise e segurança. Por isso, o servidor do aplicativo separa a conversa sobreposta e às vezes ambígua em mensagens distintas.

À medida que o áudio chega, o servidor usa transcrições parciais e sinais temporais para inferir quem está com a palavra e criar uma fila de mensagens. A mensagem mais recente permanece provisória: seu texto, tempo e identificação do falante podem mudar com a chegada de mais fala. Quando alguém mantém a palavra por tempo suficiente para que a atribuição seja confiável, o servidor finaliza a mensagem correspondente.

A sobreposição de falantes torna isso mais complicado. Uma breve confirmação do assistente enquanto o usuário fala (por exemplo, "mm hmm" ou "okay") não precisa necessariamente se tornar uma mensagem própria. Por outro lado, uma intervenção relevante do assistente muitas vezes deve virar uma mensagem. Da mesma forma, priorizamos a coerência das respostas do assistente exibidas mesmo quando o usuário fala no meio delas.

Toda política de segmentação equilibra rapidez e certeza. Confirmar cedo demais gera um histórico fragmentado e uma ordem instável; esperar demais atrasa as transcrições e os recursos que dependem delas. Por isso, o sistema mantém duas visões relacionadas da conversa: uma visão especulativa do estado atual e um registro definitivo do que foi dito. A visualização da conversa na interface do aplicativo aceita atualizações e, por isso, usa a visão especulativa. Já o registro no pipeline de análise exige uma transcrição final.

Isso oferece ao restante do ChatGPT uma visão estável da conversa sem impor turnos ao caminho de voz ao vivo.

A agilidade começa assim que o usuário clica no botão. Com o GPT‑Live, o sistema precisa estabelecer o caminho de mídia e começar a enviar áudio pelo modelo antes que a conversa possa começar. Isso coloca cada parte da sequência de inicialização no caminho crítico.

Como observado acima, o WebRTC oferece uma base sólida para operações em tempo real, mas iniciar uma sessão WebRTC padrão exige um número surpreendente de negociações de protocolo e viagens de ida e volta pela rede. O WebRTC é anterior ao foco em minimizar viagens de ida e volta que orientou protocolos posteriores, como o QUIC. Por isso, seus protocolos subjacentes às vezes repetem trabalho quando usados em conjunto. Por exemplo, cada protocolo incluía seu próprio mecanismo contra ataques de negação de serviço, mesmo quando ele não era necessário no contexto da pilha WebRTC completa.

Analisamos a pilha e desenvolvemos o WebRTC Abridged Roundtrip Protocol (WARP⁠(abre em uma nova janela)), que reduz a inicialização de mídia e dados de seis viagens de ida e volta pela rede para apenas uma. O WARP consegue isso com um conjunto de melhorias de protocolo retrocompatíveis: incorporando a negociação DTLS ao ICE (SPED⁠(abre em uma nova janela)), usando a negociação mais rápida do DTLS 1.3⁠(abre em uma nova janela), pré-negociando a negociação SCTP (SNAP⁠(abre em uma nova janela)) e pré-negociando canais de dados em vez de usar o DCEP⁠(abre em uma nova janela).

Projetamos o WARP como um conjunto de especificações abertas, em colaboração com integrantes da comunidade WebRTC, para que todo o ecossistema possa se beneficiar desse trabalho. Estamos promovendo as propostas no grupo de trabalho TSVWG da IETF, e o suporte ao WARP já foi adicionado ao libwebrtc e ao Pion, com iniciativas em andamento em outras implementações do WebRTC.

Depois de otimizar a negociação de mídia, um atraso restante chamou a atenção: a troca de sinalização usada para compartilhar parâmetros SDP antes que o WebRTC possa se conectar. Para remover essa troca do caminho crítico, desenvolvemos o que chamamos de Instant Connect. Ele negocia esses parâmetros antecipadamente, sem reservar capacidade do servidor e sem exigir alterações nas implementações existentes do WebRTC.

O Instant Connect funciona em paralelo ao fluxo padrão de sinalização. Se os parâmetros pré-negociados forem válidos, o servidor poderá materializar a sessão quando o primeiro pacote de mídia chegar. Se estiverem desatualizados ou forem inválidos, o fluxo de sinalização já estará em andamento, permitindo que o cliente recorra a ele sem latência adicional.

Juntos, o Instant Connect e o WARP reduzem drasticamente o tempo entre a intenção do usuário e o início do fluxo de mídia ao vivo. Com a troca de SDP fora do caminho crítico e o WARP condensando a negociação de transporte, agora o cliente pode iniciar uma sessão com um único pacote UDP. O servidor pode responder imediatamente, permitindo que o restante do sistema comece a fazer o trabalho que realmente importa para o usuário: ouvir e responder.

Um sistema pode parecer rápido no papel e ainda travar com tráfego real de voz. Antes de permitir que o GPT‑Live conversasse com usuários, fizemos um teste silencioso que encaminhava uma parcela pequena e crescente das sessões de ChatGPT Modo Voz em produção tanto para a experiência atual de Voz avançada quanto para o novo sistema. A Voz avançada continuou atendendo os usuários normalmente, enquanto o caminho paralelo executava inferência em modo somente leitura. Isso expôs o sistema a clientes, redes, durações de sessão e distribuições geográficas reais sem alterar o que os usuários ouviam.

Uma das primeiras lições foi que a capacidade não podia se resumir à taxa de processamento da GPU. As sessões de voz permanecem abertas e enviam quadros continuamente; portanto, os manipuladores de fluxo na CPU, as filas e os caminhos de rede precisam escalar junto com a inferência. Sob carga real, um componente de apoio saturou antes do previsto por nossas estimativas de teste de carga, fazendo as solicitações de inferência se acumularem e a latência aumentar progressivamente. Mudamos a pergunta sobre capacidade de "Quantas solicitações uma GPU consegue processar?" para "Quantas sessões simultâneas o sistema consegue sustentar mantendo cada quadro dentro do prazo?"

O teste também tornou a localização geográfica uma preocupação central. Encaminhar uma sessão para uma capacidade distante pode gerar atrasos em vários pontos durante a inicialização e a transmissão contínua. Passamos a validar as implantações do modelo junto com a capacidade regional e a configuração de direcionamento de tráfego e, depois, a detalhar a latência por região de origem. Aproximar a inferência dos usuários ajudou, mas também reforçou uma lição mais ampla: a agilidade de ponta a ponta depende de todos os serviços do caminho, não apenas do servidor do modelo.

Outras falhas só surgiram ao longo de ciclos de vida realistas das sessões. Sessões prolongadas revelaram pressão sobre a memória e a persistência. As reconexões colocaram à prova a compactação e a restauração do estado. Desconexões comuns dos clientes revelaram condições de corrida na negociação de encerramento. Esses problemas raramente apareciam em testes de carga curtos porque dependiam do tempo, do estado acumulado e do comportamento entre os limites dos serviços.

Por fim, os testes em produção nos obrigaram a melhorar a observabilidade e os controles de implantação. Encontramos métricas que misturavam diferentes fontes de latência, painéis cujos dados agregados ocultavam mecanismos individuais com problemas e divergências de configuração entre os sistemas testados e implantados. Em resposta, adicionamos telemetria mais granular, validação com configurações comprovadamente boas, aumentos graduais por etapas e a capacidade de isolar ou desativar caminhos individuais rapidamente. O teste silencioso se tornou um ensaio antecipado do lançamento, não só para avaliar quanto tráfego o sistema conseguiria receber, mas também a rapidez com que poderíamos detectar e conter falhas e nos recuperar delas.

Levar o GPT‑Live à escala do ChatGPT exigiu um sistema totalmente novo, criado em torno de um princípio fundamental: a voz precisa fluir. A inferência contínua mantém o modelo full-duplex abastecido com áudio. Um caminho dedicado à mídia garante a entrega confiável dos quadros. A delegação assíncrona permite executar um raciocínio mais profundo em paralelo. O transporte otimizado mantém a experiência ágil até chegar ao usuário.

A arquitetura por trás do GPT‑Live já está se transformando em uma plataforma mais ampla para interações em tempo real. Ela viabiliza o ChatGPT Modo Voz à medida que ele evolui da conversa para a coordenação com agentes de IA e servirá de base para a futura API do GPT‑Live. Com o tempo, ela permitirá que as experiências de voz abranjam mais dispositivos, aplicativos e modalidades sem perder o imediatismo que faz uma conversa por voz parecer ao vivo.

Se você quer resolver problemas de engenharia como esses, venha trabalhar conosco⁠.