- Apresentação de um caso de desenvolvimento de um agente de voz próprio com latência reduzida para cerca de 400 ms em um sistema de IA baseado em voz
- STT, LLM e TTS conectados em um pipeline em tempo real, alcançando uma velocidade de resposta 2x mais rápida do que plataformas comerciais existentes, como a Vapi
- Uso do Deepgram Flux para detectar fala e gerenciar a transição de turnos, além do modelo llama-3.3-70b da Groq para reduzir drasticamente o tempo até o primeiro token
- Implantação geográfica e otimização de rede reduziram a latência para menos da metade na distribuição na região da UE
- O ponto central de um agente de voz é a orquestração em tempo real e o desenho do pipeline; ao implementar isso diretamente, fica mais claro identificar gargalos de desempenho
Contexto da construção do agente de voz
- Com base na experiência de desenvolver um protótipo de agente de voz para uma grande empresa de bens de consumo, houve uma tentativa de construir a solução internamente para lidar diretamente com a complexidade das plataformas comerciais
- Plataformas como ElevenLabs e Vapi são convenientes, mas é difícil entender seu funcionamento interno e não permitem um controle fino da latência
- O objetivo era reproduzir diretamente um desempenho no nível da Vapi, e isso foi viabilizado em um dia e com cerca de 100 dólares em créditos de API
A complexidade dos agentes de voz
- Diferentemente de chatbots baseados em texto, a voz exige gerenciamento de turnos em tempo real (turn-taking)
- No momento em que o usuário começa a falar, o sistema precisa interromper imediatamente sua fala e, quando ele para, iniciar a resposta rapidamente
- Apenas a detecção simples de voz (VAD) não basta para determinar com precisão o fim da fala, e isso pode gerar latência, sobreposição de falas e silêncios desnecessários
Primeira implementação: teste baseado em VAD
- Recebimento de fluxo de áudio μ-law usando servidor FastAPI e WebSocket da Twilio
- Uso do Silero VAD para determinar a presença de voz e reprodução de um arquivo WAV previamente gravado ao detectar o fim da fala
- Embora simples, foi possível confirmar resposta imediata e fluxo de conversa natural
- Nesta etapa, foi obtida uma referência para medir o limite inferior da latência
Segunda implementação: Deepgram Flux e pipeline em tempo real
- Introdução do Deepgram Flux para integrar transcrição em streaming e detecção de turnos
- Quando o Flux detecta o fim da fala, o processamento segue esta ordem
- Envia o resultado da transcrição e o histórico da conversa ao LLM
- Assim que o primeiro token é gerado, faz streaming para o TTS (WebSocket)
- Transmite o áudio gerado em tempo real para a Twilio
- Manter a conexão do TTS pré-aquecida (warm pool) economizou cerca de 300 ms de latência
- Quando o usuário começa a falar, LLM, TTS e envio de áudio são cancelados imediatamente, permitindo uma interrupção natural
Medição de latência e implantação regional
- Em execução local na Turquia, houve uma latência média de 1,6 a 1,7 segundo
- Após implantar na região EU da Railway e alinhar Twilio, Deepgram e ElevenLabs também para a região da UE
- A média caiu para 690 ms (790 ms no total), cerca de 50 ms mais rápida que a Vapi
- Com a redução da latência, a reatividade da conversa melhorou bastante, e o tratamento de interrupções durante a fala ficou mais fluido
Escolha de modelo e melhora de desempenho
- Inicialmente foi usado o gpt-4o-mini e depois ele foi substituído pelo llama-3.3-70b da Groq
- Nos testes, o tempo até o primeiro token (TTFT) do modelo da Groq foi até 3x mais rápido que o da OpenAI
- Foi alcançada uma latência ponta a ponta média abaixo de 400 ms, com o primeiro áudio chegando em até 500 ms
- Nesse nível, a sensação é de que o agente responde mais rápido do que uma pessoa
Principais aprendizados técnicos
- A otimização de latência depende principalmente de gerenciar todo o caminho entre o fim da fala e a primeira saída de voz
- Como o TTFT representa mais da metade da latência total, escolher um modelo de baixa latência é essencial
- É preciso transformar STT→LLM→TTS em um pipeline de streaming, em vez de processá-los sequencialmente
- Para manter uma conversa natural, é necessário cancelar imediatamente todos os componentes quando houver interrupção de fala
- A proximidade geográfica entre serviços tem impacto decisivo na latência
Comparação com plataformas comerciais
- Vapi e ElevenLabs ainda são úteis para a maioria das equipes porque oferecem API, estabilidade, observabilidade e outros recursos adicionais
- No entanto, construir a solução diretamente permite entender os gargalos reais e o significado dos parâmetros, além de possibilitar uma orquestração personalizada para requisitos específicos
- No fim, sistemas de voz são um problema de orquestração e, quando a estrutura fica clara, tornam-se um desafio de engenharia solucionável
Código-fonte
1 comentários
Comentários do Hacker News
Este texto é realmente muito interessante. No passado, a equipe do Amazon Alexa estudou esse problema e até tem patentes relacionadas.
Em conversas, a latência média entre pessoas é de 0 ms; ou seja, a outra pessoa já começa a falar antes mesmo de a primeira terminar. Isso acontece porque o cérebro prevê a fala do outro enquanto prepara a resposta ao mesmo tempo.
Por outro lado, as pessoas esperam latência de assistentes de voz. Há dois motivos para isso — a percepção de que o computador precisa “pensar” e a latência das chamadas de celular.
Quase nenhuma resposta da Alexa fica abaixo de 500 ms. Antes, simplesmente se consideravam 300 ms de silêncio como “fim do turno”, mas o verdadeiro ponto-chave é o semantic end-of-turn.
Hoje há recursos computacionais suficientes, então fico curioso para saber o quanto isso evoluiu. O processamento por proximidade geográfica (edge computing) foi um grande ponto de virada.
Acho que voz no fim das contas é um problema de turn-taking. Existe uma melhoria fácil que ninguém mexeu — fillers e controle de ritmo.
Se o LLM detectar um breve silêncio, ele pode inserir fillers contextualizados como “hmm”, “claro” enquanto a resposta real está sendo gerada. Isso deixaria a conversa muito mais natural.
Excelente texto. O OpenAI Responses client adotou websockets recentemente, reduzindo a latência.
Outra forma é rodar um LLM minúsculo localmente. Eu montei um pipeline totalmente local com o projeto ova e consegui tempo de ida e volta abaixo de 1 segundo mesmo sem streaming.
A estrutura do pipeline de streaming e a análise de latência por etapa foram muito úteis. Foi impressionante ver o loop de turn-taking implementado diretamente.
Ainda assim, a comparação de “2x mais rápido que o Vapi” é um pouco imprecisa. O Vapi faz muito mais coisas, como chamadas de ferramentas, webhooks e roteamento multi-tenant.
O verdadeiro valor deste texto está no insight de ter construído o loop de orquestração por conta própria. Se tivesse sido apresentado simplesmente como “o que aprendi construindo isso eu mesmo”, teria ficado perfeito.
Eu também estou construindo um agente de voz comercial com a combinação Twilio + Deepgram + ElevenLabs + API de LLM.
O ponto principal não foi a precisão do STT, e sim a UX de turn-taking. Quando trocamos um limiar fixo de silêncio por semantic end-of-turn, a sensação mudou completamente.
A latência entre regiões também importa. Ao conectar da Índia a servidores nos EUA, só o edge hop da Twilio já acrescentava de 150 a 250 ms. Melhoramos isso com roteamento por região.
O tratamento de barge-in (interrupção no meio da fala) também é complexo. Não basta interromper o LLM e o TTS; é preciso desfazer também os workflows automatizados já executados. Já tivemos um bug em que, se houvesse uma interrupção durante a confirmação de uma reserva, a reserva acabava sendo concluída de verdade.
O Soniox Real-time (com suporte a 60 idiomas) trata endpoint detection no nível do modelo. É muito mais preciso do que VAD.
Dá para consultar a documentação técnica, o benchmark da Daily e a página de demo.
Eu trabalhava na Soniox. Foi o primeiro serviço a implementar endpoint detection em tempo real.
Pessoalmente, acho que a arquitetura STT → LLM → TTS tem limites. O futuro está em modelos de voz end-to-end.
Há 2 anos eu fiz a demo Chirpy, mas para chegar a um nível realmente utilizável seria necessário treinamento dedicado. Como side project, era inviável.
Clientes corporativos valorizam auditabilidade e confiabilidade. Em setores regulados como saúde e finanças, é preciso validar separadamente a saída do STT e a do LLM.
Já os modelos de voz end-to-end são mais adequados para usos narrativos, como entrevistas ou pesquisas. Na prática, os clientes querem mais acabamento de engenharia do que o modelo mais novo.
Esta abordagem me lembra o início da evolução do netcode de motores de jogos. A latência não é um problema do modelo, e sim de orquestração.
O artigo de VR do Carmack de 2013 defendia exatamente isso — é preciso rastrear o pipeline inteiro para encontrar gargalos na casa dos milissegundos.
Vale ver Latency Mitigation Strategies. O caso de abrir antecipadamente um pool de websockets de TTS para economizar 300 ms é um exemplo perfeito.
Quero apresentar o app open source de reconhecimento de voz Handy. Ele funciona totalmente offline e é expansível.
Eu o uso todos os dias com o Claude, e funciona muito melhor do que o ditado padrão do macOS.
O texto é bom, mas explicar conversa apenas com turn-taking é simplificar demais.
Conversas reais também têm fala sobreposta, sinais de confirmação, mensagens fáticas para manter a escuta, e até o comportamento cooperativo de completar a fala do outro.
Esses elementos não são bem representados por um modelo simples de turn-taking, e o modelo precisa ser capaz tanto de gerá-los quanto de entendê-los.