Otimização de latência em agentes de voz: guia passo a passo

A capacidade de resposta de um agente de voz é determinada pelo atraso total entre o momento em que um usuário termina de falar e o momento em que o agente começa a responder. Esse atraso raramente é causado por um único componente lento. Ele se acumula em várias etapas independentes, cada uma contribuindo com algumas dezenas ou centenas de milissegundos, e reduzi-lo exige saber quanto tempo cada etapa consome.

Otimizar a latência de agentes de voz é o trabalho de descobrir onde esse tempo se esconde e recuperá-lo etapa por etapa.

Este artigo complementa a visão geral conceitual sobre latência. Enquanto aquela página explica o que é latência, esta aborda arquitetura e medição, para que você tenha um orçamento de latência para usar como referência e um conjunto de ações concretas a tomar.

Resumo

• O tempo até o primeiro áudio representa todo o pipeline, não o tempo de inferência de um único modelo.
• O tempo até o primeiro token do LLM e o endpointing são os dois maiores itens de latência.
• Sobrepor etapas, em vez de executá-las em série, recupera a maior parte do orçamento.
• Streaming, escolha de codec e ajuste do buffer do player reduzem milissegundos mensuráveis.
• Você deve medir por região na sua própria implantação e informar P50 e P95.

Definindo o orçamento de latência do agente de voz

Um orçamento de latência é uma meta total de tempo até o primeiro áudio definida entre as etapas do pipeline, com cada etapa recebendo uma margem que, somada, deve ficar abaixo da sua meta. Defini-lo é o primeiro passo e também onde o trabalho com latência mais costuma dar errado, pois engenheiros podem confundir dois números parecidos, mas com significados diferentes.

O primeiro é a latência de inferência do modelo: o tempo que um modelo leva para gerar uma saída. Para nossos modelos Flash, ela é de aproximadamente 75 ms para entradas curtas típicas, sem considerar a sobrecarga de rede e da aplicação. É uma métrica interna e útil para comparar modelos entre si. Não é o número que seu usuário vivencia.

Da perspectiva do usuário, o foco é o tempo até o primeiro áudio (TTFA): o tempo decorrido entre o usuário parar de falar e ouvir a primeira amostra da resposta do agente. O TTFA é sempre maior que a latência de inferência de qualquer modelo individual, pois soma todo o pipeline.

Um agente de voz em cascata é uma cadeia de cinco etapas:

• captura (microfone) -> STT -> LLM -> TTS -> reprodução

O áudio é capturado pelo microfone, transcrito em texto, enviado a um modelo de linguagem, o texto do modelo é sintetizado novamente em fala, e essa fala é armazenada em buffer e reproduzida. Cada etapa adiciona latência e, em várias delas, o maior custo não é o que você esperaria.

Veja um exemplo para um agente em inglês, com servidores razoavelmente próximos do usuário. Os números são intervalos ilustrativos, não garantias.

Normalmente, os dois maiores itens de latência são o tempo até o primeiro token do LLM e o atraso de endpointing no início da cadeia. 

A tabela é uma forma útil de visualizar o pipeline, mas sugere que as etapas são executadas estritamente em série, o que não acontece. Várias das otimizações mais importantes de latência de agentes de voz vêm da sobreposição dessas etapas, e é nela que se recupera a maior parte do orçamento abaixo.

Speech to Text: otimização da latência de transcrição e endpointing

A transcrição é a segunda etapa do pipeline, e seu custo real não é a transcrição em si, mas decidir quando o usuário parou de falar. Esta seção aborda os dois aspectos para ajudar você a otimizar a latência do agente de voz.

A transcrição acontece antes de chegar ao LLM. Scribe v2 Realtime (scribe_v2_realtime) retorna transcrições parciais em aproximadamente 150 ms e transmite em chunks de áudio, de modo que a transcrição é formada enquanto o usuário ainda fala. Ele oferece suporte a PCM de 8 kHz a 48 kHz e codificação mu-law, o que é importante para a seção sobre codecs abaixo. As parciais de 150 ms têm baixo custo.

O maior custo de latência é o endpointing: o momento em que seu sistema decide que o usuário realmente terminou sua vez de falar.

A Detecção de Atividade de Voz (VAD) segmenta a fala com base no silêncio, e é aí que o tempo se acumula. Se você espera, por exemplo, 700 ms de silêncio antes de declarar o fim do turno, adicionou 700 ms a cada turno, além da própria transcrição. Esse atraso é invisível em um benchmark de precisão de transcrição, mas muito presente em uma conversa real. Ele costuma ser a maior latência controlável de todo o pipeline e, por ser controlável, é um bom ponto de partida.

O endpointing envolve um equilíbrio entre capacidade de resposta e interrupção. Um limite curto de silêncio faz o agente responder rápido, mas pode interromper o usuário no meio da frase durante uma pausa natural. Um limite longo é seguro, mas lento. Na prática, as três mudanças que otimizam a latência em Speech to Text são:

1. Ajuste fino do limite de silêncio: Reduza o limite de silêncio ao menor valor que não corte as pausas naturais dos seus usuários e, depois, meça a taxa de interrupção em produção em vez de tentar adivinhar.
2. Incorpore um evento físico de controle: Use o controle de confirmação manual quando sua aplicação souber que o turno terminou por outro sinal, como soltar o botão de apertar para falar ou um evento da interface, em vez de esperar pelo temporizador de VAD.
3. Sobreponha com processos do LLM: Envie as parciais cedo para as etapas seguintes. Alimente o LLM com parciais estáveis e revise caso a transcrição final seja diferente: uma forma de execução especulativa que oculta o atraso de endpointing durante o processamento do prompt pelo LLM.

Para mais informações, o Scribe v2 Realtime é descrito em mais detalhes na página de recursos de Speech to Text e na página do produto Transcrição de Voz em Tempo Real.

A contribuição do LLM para a latência

O modelo de linguagem costuma ser o maior contribuinte individual para o TTFA, então é também onde a sobreposição traz mais ganhos na otimização da latência de agentes de voz. O principal insight é que o agente não precisa da resposta inteira antes de começar a falar.

O padrão que recupera a maior parte do orçamento de latência é transmitir tokens do LLM e alimentá-los no TTS conforme chegam, em chunks delimitados por frases ou orações. A lógica é armazenar tokens em buffer até o fim de uma frase e então sintetizar essa frase enquanto a próxima ainda está sendo gerada:

const SENTENCE_END = /(?<=[.!?])\s+/;

async function* speakLlmStream(tokens: AsyncIterable<string>) {
  let buffer = "";
  for await (const token of tokens) {
    buffer += token;
    const parts = buffer.split(SENTENCE_END);
    buffer = parts.pop() ?? ""; // keep the incomplete fragment
    for (const sentence of parts) {
      if (sentence.trim()) yield* synthesize(sentence.trim());
    }
  }
  if (buffer.trim()) yield* synthesize(buffer.trim());
}

async function* synthesize(text: string) {
  const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
    text,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  yield* stream;
}

Para conversas longas, prefira o WebSocket de TTS para que uma conexão aberta possa receber texto incrementalmente, sem pagar novamente pela configuração da conexão a cada frase. Apenas o tempo em que o modelo gera áudio ativamente conta para seu limite de simultaneidade, portanto um WebSocket aberto e ocioso é praticamente gratuito.

Text to Speech: streaming e escolha de voz

Text to Speech é a etapa em que você consegue determinar a latência com mais precisão. Ela tem duas principais alavancas: como você transmite o áudio e qual voz escolhe.

Flash v2.5 (eleven_flash_v2_5) é o modelo ideal para usar em um agente. Ele oferece aproximadamente 75 ms de inferência do modelo para entradas curtas, oferece suporte a 32 idiomas e aceita até 40.000 caracteres por solicitação.

O número de 75 ms refere-se apenas à inferência. A linha de TTFA do TTS no orçamento acima é maior porque, além da inferência, inclui o tempo de ida e volta da rede e o agendamento no servidor.

A maior alavanca aqui é o streaming. Se você solicitar o áudio completo e esperar por ele, o usuário aguarda a síntese de todo o clipe antes de ouvir qualquer coisa. Se usar streaming, o usuário ouve o primeiro chunk assim que ele é gerado, e o restante chega enquanto ele já está ouvindo. O streaming não torna o modelo mais rápido; ele simplesmente começa a enviar a saída ao usuário enquanto a geração ainda está em andamento.

O guia prático de streaming aborda o streaming por HTTP, e o guia de WebSocket em tempo real aborda o caminho de WebSocket que você vai querer usar ao alimentar tokens de um LLM.

Inicialize o cliente uma vez e reutilize-o em todas as chamadas abaixo:

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

const elevenlabs = new ElevenLabsClient({ apiKey: process.env.ELEVENLABS_API_KEY });

Depois, configure um stream e encaminhe-o conforme ele chega:

const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
  text: "Your call is connected. How can I help today?",
  modelId: "eleven_flash_v2_5",
  outputFormat: "mp3_44100_128",
});

for await (const chunk of stream) {
  // forward each chunk to your audio sink as it arrives
}

A outra alavanca é a escolha da voz, que também tem um custo de latência. Vozes padrão, vozes sintéticas e Instant Voice Clones (IVCs) sintetizam mais rápido do que Professional Voice Clones (PVCs), pois os PVCs têm uma complexidade adicional de modelo que acrescenta sobrecarga a cada geração. Para um agente com requisitos rigorosos de latência, a combinação de Flash com um IVC ou uma voz padrão é a opção de menor latência.

Escolhas de tamanho de chunks no streaming

Com tokens fluindo para o TTS e áudio retornando, a próxima decisão é o tamanho dos trechos e quanto o player armazena em buffer antes de iniciar.

Chunks menores chegam ao player mais cedo, reduzindo a latência até o primeiro byte, ao custo de mais mensagens e um pouco mais de sobrecarga por chunk. Chunks maiores são mais eficientes no transporte, mas fazem o usuário esperar mais pelo primeiro. Para agentes interativos, prefira chunks menores no início da fala, pois é o primeiro chunk que o usuário está esperando; os posteriores chegam enquanto o áudio já está sendo reproduzido, e seu tamanho importa menos.

O player representa uma parte significativa da latência restante. A maioria dos players de áudio não inicia a reprodução no primeiro byte. Eles armazenam uma pequena quantidade em buffer para evitar engasgos se o stream desacelerar brevemente. Um buffer padrão de 500 ms é comum e é adicionado diretamente à latência percebida. Reduzi-lo troca um pequeno aumento no risco de engasgos por um TTFA menor, e o valor ideal depende da variação de rede entre seu servidor e o cliente:

• Em uma conexão estável, como reprodução no servidor ou cliente no mesmo local, um buffer de 50 a 150 ms costuma ser seguro e reduz consideravelmente o TTFA.
• Em uma conexão móvel instável ou entre regiões, um buffer maior evita lacunas audíveis que são piores do que a latência que elas custam.

A configuração exata que você escolher depende do seu caso de uso ativo e das suas prioridades.

Escolhas de codec

O destino do áudio deve determinar o codec solicitado. Retornamos formatos como mp3_44100_128, mp3_22050_32, pcm_16000, pcm_24000 e ulaw_8000. Corresponder ao formato nativo do transporte elimina uma etapa de transcodificação, ajudando a otimizar a latência do agente de voz.

Para telefonia, como Twilio e provedores semelhantes, use ulaw_8000. A rede telefônica usa mu-law de 8 kHz de ponta a ponta, portanto solicitá-lo diretamente evita uma etapa de transcodificação no seu pipeline e corresponde ao que a operadora espera. Não há benefício em sintetizar áudio de maior fidelidade que a rede telefônica reduzirá imediatamente; você apenas adicionaria latência sem ganhar nada audível.

Para WebRTC e reprodução no navegador, use PCM (pcm_24000 ou pcm_16000) ou um formato MP3. O PCM é descompactado, portanto não há uma etapa de decodificação no cliente, o que remove uma pequena quantidade de latência por chunk e é conveniente ao alimentar diretamente um pipeline Web Audio. O MP3 é mais compacto na transmissão, o que ajuda em conexões limitadas, ao custo de uma decodificação leve no cliente.

Geografia e distâncias de rede

Todas as otimizações acima pressupõem que os bytes precisam percorrer uma distância curta. A geografia define o limite mínimo do seu orçamento de latência, então vale a pena analisá-la antes de ajustar qualquer outra coisa.

Atendemos solicitações a partir de clusters na América do Norte, Europa e Sudeste Asiático e encaminhamos automaticamente cada solicitação ao cluster mais próximo. O tempo de ida e volta pela internet pública normalmente é de 20 a 200 ms, dependendo da proximidade geográfica, e não pode ser reduzido sem mudar onde sua infraestrutura é executada.

Um agente que parece instantâneo em São Francisco, a um curto salto de um cluster norte-americano, pode parecer lento para um usuário no Sul da Ásia, cujo tráfego cruza um oceano duas vezes a cada turno.

A solução é posicionar seus servidores de aplicação perto dos seus usuários, não apenas de nós. Se seus usuários estão na Europa, execute o backend do seu agente na Europa para que o trecho entre o usuário e seu servidor seja curto; nosso roteamento então cuida do trecho entre seu servidor e o modelo a partir de um cluster próximo.

Como medir você mesmo a latência de agentes de voz

Os números da tabela de orçamento de latência acima são intervalos ilustrativos para planejamento. Os números usados na sua implantação devem vir de um script como este, executado na sua própria infraestrutura.

A instrumentação abaixo mede o TTFA da etapa de TTS isoladamente — o tempo entre a solicitação e o primeiro chunk de áudio — em vários testes e informa os percentis. Execute-a na mesma região em que seus servidores são executados, não na sua máquina de desenvolvimento. Ela pressupõe o cliente elevenlabs apresentado anteriormente:

const VOICE_ID = "JBFqnCBsd6RMkjVDRZzb";
const TEXT = "Thanks for waiting. I have pulled up your account and I can help with that now.";
const TRIALS = 50;

async function measureTtfa(): Promise<number | null> {
  const start = performance.now();
  const stream = await elevenlabs.textToSpeech.stream(VOICE_ID, {
    text: TEXT,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  for await (const _chunk of stream) {
    return performance.now() - start; // first chunk -> stop the clock
  }
  return null;
}

function percentile(values: number[], p: number): number {
  const v = [...values].sort((a, b) => a - b);
  const k = (v.length - 1) * (p / 100);
  const lo = Math.floor(k);
  const hi = Math.min(lo + 1, v.length - 1);
  return v[lo] + (v[hi] - v[lo]) * (k - lo);
}

const samples: number[] = [];
for (let i = 0; i < TRIALS; i++) {
  const ttfa = await measureTtfa();
  if (ttfa !== null) samples.push(ttfa);
  await new Promise((r) => setTimeout(r, 300)); // space requests, don't measure your own queueing
}

console.log(`trials: ${samples.length}`);
console.log(`P50:    ${percentile(samples, 50).toFixed(0)} ms`);
console.log(`P95:    ${percentile(samples, 95).toFixed(0)} ms`);

Alguns pontos para lembrar:

• Informe P50 e P95: Concentre-se neles, em vez da média. A média esconde a cauda, e é a cauda que faz um agente parecer pouco confiável. P95 representa a experiência de um turno em cada vinte. 
• Experimentação por localização: Execute o mesmo script em cada região que você atende e mantenha os resultados separados.
• Espace as solicitações para obter precisão: Espace suas solicitações (o setTimeout acima). Se enviá-las todas de uma vez, você medirá sua própria fila em vez do serviço. Quando o limite de simultaneidade é excedido, as solicitações entram na fila por prioridade, o que normalmente adiciona cerca de 50 ms, e além da capacidade você recebe HTTP 429.
• Meça toda a cadeia de latência: Estenda o mesmo padrão de temporização às outras etapas. Coloque a finalização do STT, o primeiro token do LLM e a inicialização do player entre os mesmos marcadores performance.now(), e você poderá preencher a tabela completa de orçamento com seus próprios números e ver qual etapa atacar primeiro.

Seguindo estas dicas, você conseguirá medir por conta própria a latência do agente de voz. A partir daí, terá um caminho claro de prioridades para abordar primeiro.

O que mais reduz a latência de agentes de voz?

Se você quer algumas ações rápidas em que se concentrar, estas são as mudanças de maior impacto.

Aproximadamente em ordem de impacto, você pode usar os seguintes métodos para reduzir a latência do agente:

• Inicie o trabalho do LLM com parciais estáveis de STT para ocultar o atraso de endpointing.
• Transmita tokens do LLM para o TTS nos limites de frases, para que a síntese da primeira frase se sobreponha à geração da segunda.
• Transmita o áudio de TTS ao player e reduza o buffer ao menor valor que a variação da sua rede tolerar.
• Use Flash com uma voz padrão ou IVC para obter o TTS de menor latência e corresponda o codec ao transporte (ulaw_8000 para telefonia; PCM ou MP3 para navegador/WebRTC).
• Posicione seus servidores perto dos usuários e meça por região, pois os trechos de rede são reais e desiguais.

Para técnicas específicas mais aprofundadas, consulte o guia prático para desenvolvedores sobre otimização de latência. Para um ponto de partida completo e executável, o início rápido da API e o guia prático de streaming têm exemplos completos. 

Quer acesso mais rápido a cascatas de agentes ajustadas? ElevenAgents implementa este pipeline com otimizações de sobreposição já incluídas.

Crie agentes de voz de baixa latência com ElevenAgents

A otimização da latência de agentes de voz exige medir cada etapa e depois sobrepô-las para que as mais lentas sejam executadas enquanto outros processos já estão em andamento. Você pode criar e ajustar essa cascata manualmente ao longo de várias iterações, usando os padrões acima, ou começar com um pipeline que já tenha otimizações de latência.

O ElevenAgents implementa essa cascata completa, desde o STT por streaming até a transferência token a token do LLM para o TTS Flash, com técnicas de sobreposição já incorporadas. Em vez de começar do zero, você ajustará limites para obter o desempenho mais importante para você.

Comece usando o ElevenAgents para criar um agente hoje ou falar com vendas para obter mais informações.

Perguntas frequentes sobre otimização da latência de agentes de voz