Arquitetura de agentes de voz: STT, LLM, TTS e o orçamento de latência

Se você já esperou 3 segundos para um agente de voz responder, conhece o principal assassino de produto. Não é a resposta errada. É a pausa longa antes da resposta. A conversa parece quebrada quando a latência passa de 500ms, e parece humana quando fica perto de 200ms. Todo o desafio de engenharia de um agente de voz se reduz a uma pergunta: como manter o tempo de ida e volta abaixo de um segundo enquanto se executa reconhecimento de fala, um LLM e síntese de voz em série? Este post caminha pelo pipeline, pelo orçamento de 800ms que equipes de produção miram em 2026 e pelos trade-offs arquiteturais que decidem se o seu agente vira produto ou continua demo.

O pipeline do agente de voz

Todo agente de voz digno de produção tem o mesmo esqueleto: voz entra, voz sai, com três estágios no meio. O reconhecimento de fala (STT, também chamado de ASR) converte áudio em texto. Um large language model (LLM) lê o texto e produz uma resposta. A síntese de voz (TTS) converte a resposta em áudio. Envolva isso em uma camada de transporte (WebRTC para navegador, SIP para telefonia) e você tem um agente.

O que engana nesse diagrama é que ele parece simples. A realidade é que cada estágio tem a própria latência, taxa de erro e teto de qualidade, e as falhas se compõem. Erros de STT confundem o LLM. Hesitação do LLM trava o TTS. Qualidade do TTS define se o usuário acredita na voz ou desliga.

O orçamento de 800ms

Equipes de produção em 2026 miram um tempo total de cerca de 800ms do fim da fala do usuário até o início da fala do agente. Uma alocação típica:

• Detecção de atividade de voz e captura de áudio: 50ms
• Transcrição STT (streaming): 150ms
• Time-to-first-token (TTFT) do LLM: 400ms
• Primeiro chunk de áudio do TTS: 150ms
• Overhead de rede: 50ms

O LLM fica com a maior fatia porque é o mais difícil de comprimir sem sacrificar qualidade. STT e TTS podem ser otimizados agressivamente porque são problemas majoritariamente de engenharia. O LLM é limitado pelo tamanho do modelo e pelo comprimento do prompt.

Pesquisas de mercado da AssemblyAI e da Hamming colocam a mediana real de latência de agentes de voz em 1,4 a 1,7 segundos, com 10% das chamadas passando de 3 segundos. Isso é cerca de 5x mais lento que a expectativa humana de 200ms. Quem ship produtos que parecem naturais roda metade da mediana do mercado.

Por que TTFT importa mais que o tempo total do LLM

Há dois números de latência que valem acompanhar no LLM. Tempo total de geração é quanto tempo o modelo levou para produzir a resposta completa. Time-to-first-token (TTFT) é o tempo até o primeiro token voltar. Para voz, TTFT é o que importa. A razão: o TTS pode começar a streamar áudio assim que a primeira frase fica pronta, então o usuário começa a ouvir o agente antes de o LLM terminar de pensar. Se o TTFT é de 800ms, o usuário sente 800ms de silêncio, por mais rápido que o TTS seja.

A mesma lógica vale para STT. Um STT em streaming emite transcrições parciais enquanto o usuário fala, então o LLM pode começar a raciocinar antes de o usuário terminar. Um STT baseado em turno que espera o fim da fala adiciona o silêncio inteiro ao orçamento.

Streaming versus pipeline por turno

A escolha arquitetural que mais afeta a latência de um agente de voz é streaming versus turno. Em um pipeline por turno, cada componente espera o anterior terminar antes de processar. Em streaming, componentes produzem saída parcial continuamente e os componentes seguintes consomem conforme chega.

Streaming é o único caminho para bater os 800ms. O STT emite chunks enquanto o usuário fala, o LLM começa a gerar assim que tem uma oração para trabalhar, e o TTS inicia a síntese antes de o LLM acabar. O usuário percebe o agente pensando e falando em paralelo, não em sequência.

Pipelines por turno são mais simples de construir e depurar, e por isso a maioria dos protótipos começa por aí. Também são a razão pela qual a maioria dos protótipos nunca vira produto.

Speech-to-speech versus cascata: quando cada um vence

Uma opção nova desde o fim de 2024 são modelos speech-to-speech como o GPT-4o realtime API ou o NVIDIA Nemotron. Eles colapsam STT, LLM e TTS em um único modelo que recebe áudio e produz áudio. O ganho é latência, frequentemente abaixo dos 800ms. O custo é perda de flexibilidade: function calling, RAG e escolha de modelos ficam mais difíceis.

Muitas implantações em 2026 são híbridas: speech-to-speech para small talk e aberturas com carga emocional, com fallback em cascata (STT, LLM, TTS separados) quando precisa de ferramenta ou RAG. Cascata dá mais flexibilidade e melhor uso de ferramentas. Speech-to-speech dá a abertura mais ágil.

A resposta certa depende do caso de uso. Um agente de reserva que sempre precisa consultar uma API de calendário fica em cascata. Uma recepcionista amigável que lida com muito small talk se beneficia de speech-to-speech.

Onde o SipPulse AI se encaixa

O SipPulse AI é a nossa plataforma de agentes de voz. Transporte WebRTC e telefonia SIP são cidadãos de primeira classe por padrão, a cascata padrão usa o Pulse Precision Pro como STT e o Pulse TTS como síntese, e o NIVA fica por cima combinando fluxos de URA e múltiplos agentes em um construtor baseado em blocos. O NIVA é a camada que deixa o agente real de produção fácil de montar, fácil de prototipar contra seus dados e fácil de evoluir depois que entra em operação.

Nós vendemos a stack completa: plataforma de agentes, construtor de URA, STT, TTS e telemetria por chamada entregue via webhooks para seus sistemas. A prova é pública: abra nossa demo, tenha uma conversa real com o agente e depois confira nosso visualizador de telemetria de exemplo, uma página aberta pequena que consome os mesmos eventos que o seu deployment receberia. Chamadas reais da demo ficam em torno de 800ms de round trip total, desmembrado em llm_ttft_ms, tts_latency_ms, eou_latency_ms e conv_latency_ms. A maioria das equipes nesse espaço esconde a latência real. Nós deixamos você medir a nossa no mesmo workload que você usaria de verdade.

Leia também

• Construindo agentes de voz em WebRTC: a stack de produção
• Turn detection, barge-in e tratamento de interrupções em agentes de voz
• Avaliando agentes de voz em produção: WER, MOS, latência

Conclusão

Um agente de voz vive ou morre pelo orçamento de latência. Os 800ms são atingíveis com um pipeline em cascata, streaming e otimização agressiva em cada camada. Modelos speech-to-speech abrem novas opções, mas não substituem a necessidade de ferramentas e RAG. Se você quer construir algo com que os usuários realmente gostem de conversar, comece pelo orçamento de latência e trabalhe de trás para frente. Teste nossa demo ao vivo para sentir a diferença ou fale com o time sobre implantar o SipPulse AI no seu próprio workload.