Todo blog de fornecedor sobre "voice AI de baixa latência" trata, na verdade, de uma única caixa do pipeline. Um novo modelo de voz que cortou 80ms da síntese. Um ajuste de endpointing. Um truque de cache. Cada um é real — e cada um é inútil se os outros cinco estágios do seu caminho de chamada estiverem consumindo 1.200ms enquanto você comemora os 80.
Latência é um orçamento, não um recurso. Quem liga ouve um único número: o silêncio entre o momento em que a pessoa para de falar e o momento em que seu agente começa. Esse número é a soma de cada estágio, do microfone ao alto-falante, mais a rede que você não controla. Este é o modelo de ponta a ponta — quanto custa cada estágio, onde os milissegundos realmente se escondem e onde streaming, endpointing e cache de fato compram tempo, em contraste com onde apenas transferem o problema.
Por que a latência é a linha entre "AI" e "uma conversa de verdade"
A alternância de turnos entre humanos tem um ritmo. Em uma conversa natural, o intervalo entre falantes é de cerca de 200ms em média, e as pessoas começam a planejar sua resposta antes de a outra terminar. Quando um agente telefônico deixa 1,5 segundo de silêncio após cada frase, quem liga não pensa "que AI impressionante". Pensa que a ligação caiu, fala por cima do agente ou desliga.
Os limites práticos com os quais projetamos:
- Um tempo de resposta abaixo de ~500ms soa conversacional. Quem liga mal percebe o intervalo.
- 500–800ms é aceitável, mas soa audivelmente "de assistente". Adequado para muitos casos de uso.
- Acima de ~1.000ms o ritmo se quebra. Quem liga interrompe, se repete, e a confiança se desgasta.
Essa meta abaixo de um segundo é o jogo inteiro. E não é tarefa de um único componente — é o orçamento que você distribui por toda a stack.
O orçamento de latência: cada estágio do microfone ao alto-falante
Aqui está o ciclo completo de um único turno de conversa. Faixas aproximadas de produção para um agente bem construído em uma chamada telefônica:
| Estágio | O que acontece | Orçamento típico |
|---|---|---|
| Entrada de áudio / rede de entrada | O áudio de quem liga chega ao seu STT (PSTN → SIP → sua borda) | 50–150ms |
| STT (streaming) | Fala → transcrição parcial + final | 100–300ms |
| Endpointing | Decidir que quem liga realmente parou | 200–800ms |
| TTFT do LLM | Prompt → primeiro token de saída (tempo até o primeiro token) | 200–600ms |
| Primeiro byte do TTS | Primeiro trecho de texto → primeiro áudio de saída | 80–300ms |
| Saída de áudio / rede de saída | Áudio sintetizado de volta para quem liga | 50–150ms |
Some tudo isso e você fica entre aproximadamente 700ms e 2,4s. A variação é enorme — e repare no que a domina: endpointing e TTFT do LLM, não os modelos de STT ou TTS que todo mundo mede em benchmarks.
Duas regras decorrem imediatamente desta tabela:
- Otimize primeiro a maior caixa. Trocar um TTS de 120ms por um de 90ms é ruído se o seu endpointer espera 700ms. Meça antes de otimizar.
- As etapas se sobrepõem quando você usa streaming. O orçamento acima é o pior caso serial. O streaming permite que STT, LLM e TTS rodem simultaneamente em vez de ponta a ponta — e é daí que vêm a maior parte dos seus ganhos reais (abaixo).
Endpointing e detecção de silêncio: os 500ms mais subestimados
Endpointing é a decisão: o interlocutor terminou seu turno ou apenas pausou para respirar? É o maior bloco controlável de latência e o tradeoff mais difícil da stack.
Abordagem ingênua: esperar N milissegundos de silêncio e então disparar. Defina N baixo demais (digamos, 200ms) e você corta as pessoas no meio da frase — brutal quando alguém lê um número de cartão de 16 dígitos ou diz "meu endereço é... Rua Oak, 42". Defina N alto demais (900ms) e cada turno parece lento.
O que realmente funciona em produção é o endpointing semântico e adaptativo, em vez de um temporizador de silêncio fixo:
- VAD (detecção de atividade de voz) dá a você o sinal bruto de "há energia de áudio" — rápido, mas burro quanto à intenção.
- Endpointing semântico usa a transcrição parcial para julgar se a fala está completa. "Meu número de conta é" está obviamente inacabado; "Quero cancelar minha conta" é um pensamento completo. Um modelo que lê o texto parcial pode disparar mais cedo em enunciados completos e esperar mais no meio de um número.
- Timeouts sensíveis ao contexto. Quando você acabou de pedir um número de telefone, amplie a janela de silêncio e não trate as pausas entre dígitos como fim de turno. Vincule o limiar de endpointing ao slot que você está coletando.
Acerte isso e você recupera 300–500ms na maioria dos turnos sem nunca cortar a fala de quem liga. Erre e nenhuma troca de modelo vai te salvar.
Streaming em tudo: a latência grátis que você está deixando na mesa
A maior mentira na tabela de orçamento serial é que as etapas acontecem uma depois da outra. Elas não deveriam. Faça streaming em cada fronteira e o pipeline se comprime:
- Transcrições parciais. Não espere pelo resultado final do STT. Alimente o seu endpointer com os parciais e até pré-aqueça o contexto do LLM, para não começar do zero quando quem liga parar de falar.
- Streaming de tokens do LLM. O que importa é o tempo até o primeiro token, não o tempo até a resposta completa. Assim que a primeira oração sai por streaming, entregue-a ao TTS. Você não precisa da resposta inteira para começar a falar.
- Chunking de TTS. Sintetize e comece a reproduzir a primeira frase enquanto o LLM ainda está gerando a terceira. O número que conta é o áudio do primeiro byte, não o do clipe completo.
Bem feito, quem liga ouve as primeiras palavras da resposta enquanto o LLM ainda está escrevendo o resto. É assim que uma stack cujo orçamento serial soma 1,8s entrega uma resposta percebida de 600ms. Streaming não é uma otimização que você adiciona depois — é a arquitetura da qual você parte.
Uma ressalva: fazer streaming de TTS no meio da geração significa que você se compromete com palavras antes de a resposta completa existir. Se o seu LLM puder se autocorrigir ("na verdade, deixe-me verificar isso — não, você tem razão"), você já terá falado a metade errada. Restrinja o modelo a respostas que se comprometem de uma vez, ou armazene em buffer a primeira oração até que a estrutura da frase esteja estável.
Cache de áudio e pré-aquecimento: ganhos reais, armadilhas reais
Cache é onde vivem os posts do tipo "deixamos isso mais rápido" ao estilo Vapi, e é genuinamente útil — com arestas afiadas.
O que é seguro colocar em cache ou pré-aquecer:
- Prompts fixos e textos padrão. Saudações, mensagens de espera, avisos legais, "aguarde um momento enquanto eu verifico isso". Pré-sintetize esses itens uma vez. Zero latência de TTS em tempo de execução.
- Aquecimento de conexão. Mantenha os sockets de STT/LLM/TTS abertos e os modelos aquecidos, para que o primeiro turno de uma chamada não pague o custo de cold start. Só isso pode economizar centenas de milissegundos no primeiro turno.
- Preenchimento previsível. Um breve e natural "deixe-me verificar isso para você", tocado enquanto uma chamada de ferramenta lenta é executada, mascara a latência de backend que quem liga ouviria como silêncio.
O que quebra se você colocar em cache:
- Qualquer coisa com dados dinâmicos. Coloque "Seu saldo é [X]" em cache como template e, mais cedo ou mais tarde, você vai ler o saldo errado para a pessoa errada. Coloque em cache a frase de suporte e sintetize o slot variável ao vivo.
- Áudio personalizado ou sensível a compliance. Nomes, dados de conta, preços cotados — sintetize na hora, todas as vezes.
- Versões desatualizadas de voz/modelo. Um clipe em cache de uma voz TTS antiga ao lado de uma ao vivo é gritantemente óbvio no meio da frase. Versione suas chaves de cache conforme o modelo de voz.
O cache rende mais nas partes previsíveis de uma chamada. Ele não faz nada pelo turno de raciocínio dinâmico — que é exatamente por isso que ele não pode ser toda a sua estratégia de latência.
Realidade de telefonia e rede: a última milha que não é sua
Você pode ajustar cada modelo à perfeição e ainda assim entregar um agente lento, porque uma chamada telefônica trafega por uma infraestrutura que você não controla.
- PSTN e SIP acrescentam tempo real. A rede telefônica pública comutada e o SIP trunking introduzem atraso de transporte antes que seu STT sequer receba o áudio. A transcodificação de codecs (por exemplo, de/para G.711) adiciona um pouco mais.
- Jitter e perda de pacotes. Chamadores em redes sem fio, Wi-Fi ruim e operadoras congestionadas entregam áudio de forma irregular. Seu jitter buffer suaviza a reprodução, mas adiciona latência para isso — mais um tradeoff a ajustar, não a eliminar.
- Geografia. Se sua inferência roda em us-east e seu chamador e provedor de telefonia estão na Europa, você adicionou uma viagem de ida e volta transatlântica a cada turno. Coloque seu caminho de mídia próximo aos seus chamadores e aos endpoints dos seus modelos.
- O caminho de mídia importa tanto quanto o modelo. A ponte WebRTC-para-SIP, o roteamento do SBC e o local onde fica seu servidor de mídia podem custar ou economizar mais do que uma troca de modelo. Isso é engenharia de infraestrutura, não engenharia de prompt.
A conclusão: reserve 100–300ms para rede e telefonia que você não consegue otimizar, e garanta que os milissegundos que você pode controlar não estejam sendo desperdiçados em um caminho de mídia que faz hairpin por três regiões.
Medindo a latência de turn-taking em produção (o número que importa)
Você não pode otimizar o que não mede, e a métrica que importa não é o benchmark de nenhum componente isolado. É o fim da fala do usuário até o início do áudio do agente — medido em produção, em chamadas reais, no percentil que dói.
- Instrumente todo o percurso de ida e volta. Registre o timestamp: último frame de áudio do chamador → endpoint disparado → primeiro token do LLM → primeiro byte do TTS → primeiro frame de áudio de saída. Registre cada etapa em cada turno para que você possa ver qual bloco estourou o orçamento quando uma chamada pareceu lenta.
- Observe o p95, não a média. Sua latência média pode ser uns belos 550ms enquanto o p95 é de 1,8s — e são os turnos no p95 que fazem os chamadores desligarem. As médias escondem as chamadas que você está perdendo.
- Acompanhe a taxa de barge-in / interrupção. Se os chamadores falam por cima do seu agente com frequência, seu endpointer está disparando tarde ou sua resposta está começando devagar. É um sintoma de latência disfarçado de métrica de UX.
Implante a instrumentação antes de otimizar. Toda afirmação de "reduzimos a latência" que não seja sustentada por medição de p95 em produção é um palpite.
Links internos
- Como construímos o pipeline de voice AI — escolhas de STT: Whisper vs Deepgram
- Corrigindo a latência de SIP em soluções de call center com AI
- Conectando WebRTC e SIP: transferências de baixa latência entre agentes de voz com AI
- Agentes de voz com AI para empresas: arquitetura e ROI
- Como gerenciar altos volumes de chamadas sem contratar mais agentes (2026)
FAQ
Qual é uma boa meta de latência para um agente de voice AI em produção? Busque menos de 800ms de ponta a ponta (do fim da fala do chamador até o início do áudio do agente), e trate menos de 500ms como o objetivo para uma sensação genuinamente conversacional. Meça no p95, não na média — é a cauda lenta que provoca as desistências.
Qual parte do pipeline de voice AI causa mais latência? Normalmente o endpointing e o tempo até o primeiro token do LLM, não os modelos de STT ou TTS nos quais a maioria dos benchmarks se concentra. O endpointing pode adicionar 200–800ms sozinho, então é o primeiro lugar a investigar antes de trocar qualquer modelo.
O cache de áudio reduz a latência de voice AI? Sim, para conteúdo fixo — saudações, avisos legais, mensagens de espera e frases de preenchimento podem ser pré-sintetizados para uma latência de execução próxima de zero. Isso não ajuda em nada nos turnos de raciocínio dinâmico, e fazer cache de qualquer coisa com dados personalizados ou variáveis corre o risco de ler a informação errada para um chamador.
Por que meu agente de voz parece lento mesmo com um modelo rápido? Porque a latência é a soma de todo o pipeline mais a telefonia que você não controla. Um TTS rápido não vai ajudar se seu endpointer espera 700ms, seu LLM transmite lentamente ou seu caminho de mídia faz hairpin entre regiões. Instrumente cada etapa e corrija primeiro o maior bloco.
O Finn é construído com prioridade na latência — STT em streaming, endpointing semântico e handoff de token para TTS ajustados para atingir turn-taking abaixo de um segundo em chamadas telefônicas reais, não em clipes de benchmark. Veja como os agentes de voz do Finn lidam com o volume de chamadas em produção sem o silêncio constrangedor.
