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 leva.

Otimizar a latência de agentes de voz é o trabalho de encontrar onde esse tempo está escondido 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 medir 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 componentes.
• 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 em relação à 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 uma margem para cada etapa cuja soma 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 que parecem semelhantes, mas têm significados diferentes.

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

Na perspectiva do usuário, você deve se concentrar no tempo até o primeiro áudio (TTFA): o tempo decorrido desde quando o usuário para de falar até 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 acrescenta 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 componentes 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 significativas de latência de agentes de voz vêm da sobreposição dessas etapas, e é nessa sobreposição 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 de agentes de voz.

A transcrição ocorre antes de chegar ao LLM. Scribe v2 Realtime (scribe_v2_realtime) retorna transcrições parciais em aproximadamente 150 ms e transmite blocos de áudio por streaming, para que a transcrição seja criada enquanto o usuário ainda está falando. Ele é compatível com PCM de 8 kHz a 48 kHz e codificação mu-law, o que importa 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 seu turno.

Detecção de Atividade de Voz (VAD) segmenta a fala com base no silêncio, e é aí que o tempo se acumula. Se você esperar, por exemplo, 700 ms de silêncio antes de declarar o fim do turno, terá adicionado 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 frequentemente é a maior latência controlável de todo o pipeline e, por ser controlável, é um bom ponto de partida.

O endpointing é um equilíbrio entre capacidade de resposta e interrupção. Um limite de silêncio curto faz o agente responder rapidamente, 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 interrompa 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 de controle físico: Use o controle de confirmação manual quando sua aplicação souber que o turno acabou por outro sinal, como soltar o botão push-to-talk ou um evento de UI, em vez de esperar pelo temporizador do VAD.
3. Sobreponha com os processos do LLM: Envie as parciais antecipadamente para as etapas seguintes. Alimente o LLM com parciais estáveis e revise se a transcrição final for diferente — uma forma de execução especulativa que oculta o atraso de endpointing durante o processamento do prompt do 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 Speech to Text 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, por isso é também onde a sobreposição oferece maior ganho na otimização da latência de agentes de voz. O ponto principal é que o agente não precisa da resposta completa antes de começar a falar.

O padrão que recupera a maior parte do orçamento de latência é transmitir tokens do LLM por streaming e enviá-los ao TTS à medida que chegam, divididos nos limites de frases ou orações. A lógica é armazenar tokens em buffer até um limite de 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 a configuração da conexão em cada frase. Apenas o tempo em que o modelo está gerando áudio ativamente conta para seu limite de concorrência, então um WebSocket aberto e ocioso praticamente não tem custo.

Text to Speech: streaming e escolha de voz

Text to Speech é a etapa em que você pode definir a latência com mais precisão. Ela tem duas principais alavancas: como você transmite o áudio por streaming 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, é compatível com 32 idiomas e aceita até 40.000 caracteres por solicitação.

O valor de 75 ms considera apenas a inferência. A linha de TTFA do TTS no orçamento acima é maior porque adiciona a viagem de ida e volta pela rede e o agendamento do servidor à inferência.

A maior alavanca aqui é o streaming. Se você solicitar o áudio completo e esperar por ele, o usuário aguardará a síntese do clipe inteiro antes de ouvir qualquer coisa. Se usar streaming, o usuário ouvirá o primeiro bloco assim que ele for gerado, e o restante chegará enquanto ele já estiver ouvindo. O streaming não torna o modelo mais rápido; ele apenas começa a enviar a saída ao usuário enquanto o modelo ainda está gerando.

O guia prático de streaming aborda o streaming por HTTP, e o guia de WebSocket em tempo real aborda o caminho via WebSocket que você vai querer usar ao enviar 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 });

Em seguida, configure um stream e encaminhe-o à medida que chegar:

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 Clones de Voz Instantâneos (IVCs) sintetizam mais rápido que Clones de Voz Profissionais (PVCs), pois os PVCs têm complexidade adicional de modelo que adiciona sobrecarga a cada geração. Para um agente com requisitos rígidos 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 blocos no streaming

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

Blocos menores chegam ao player mais cedo, reduzindo a latência até o primeiro byte, ao custo de mais mensagens e uma sobrecarga ligeiramente maior por bloco. Blocos maiores são mais eficientes para transportar, mas fazem o usuário esperar mais pelo primeiro. Para agentes interativos, prefira blocos menores no início da fala, porque é pelo primeiro bloco que o usuário espera; os blocos posteriores chegam enquanto o áudio já está sendo reproduzido, e o tamanho deles importa menos.

O player representa uma parcela 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 travamentos 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 travamentos por um TTFA menor, e o valor certo 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 uma quantidade perceptível do TTFA.
• Em uma conexão móvel instável ou entre regiões, um buffer maior evita lacunas audíveis que são piores que a latência que ele acrescenta.

A configuração exata que você escolher aqui depende do seu caso de uso ativo e do que você prioriza.

Escolhas de codec

O destino do áudio deve determinar o codec que você solicita. 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 na otimização da latência de agentes 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 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 perder nada que fosse audível.

Para WebRTC e reprodução no navegador, use PCM (pcm_24000 ou pcm_16000) ou um formato MP3. O PCM não é compactado, então não há uma etapa de decodificação no cliente, o que elimina uma pequena quantidade de latência por bloco e é conveniente ao alimentar diretamente um pipeline de 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 tenham uma curta distância a percorrer. 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 de clusters na América do Norte, Europa e Sudeste Asiático e roteamos automaticamente cada solicitação para o cluster mais próximo. A viagem de ida e volta pela internet pública costuma levar de 20 a 200 ms, dependendo da proximidade geográfica, e não pode ser reduzida sem mudar onde sua infraestrutura é executada.

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

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

Medindo você mesmo a latência de agentes de voz

Os números na tabela de orçamento de latência acima são intervalos ilustrativos para planejamento. Os números com base nos quais você lança seu produto devem vir de um script como este, executado em relação à sua própria implantação.

A instrumentação abaixo mede o TTFA da etapa de TTS isoladamente — o tempo entre a solicitação e o primeiro bloco de áudio — em várias execuções 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 é o que torna um agente pouco confiável. P95 é a experiência de um turno a 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 ter precisão: Espace suas solicitações (o setTimeout acima). Se você dispará-las todas de uma vez, medirá seu próprio enfileiramento em vez do serviço. Quando o limite de concorrência é excedido, as solicitações são enfileiradas 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 medição às outras etapas. Coloque sua finalização de STT, o primeiro token do LLM e a inicialização do player entre os mesmos parênteses de performance.now(), e você poderá preencher toda a tabela de orçamento com seus próprios números e ver qual etapa atacar primeiro.

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

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

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

Em ordem aproximada 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 do TTS para o player e reduza o buffer do player ao menor valor que a variação da sua rede tolerar.
• Use Flash com uma voz padrão ou IVC para ter o TTS de menor latência e combine o codec com o transporte (ulaw_8000 para telefonia, PCM ou MP3 para navegador/WebRTC).
• Localize seus servidores perto dos usuários e faça medições por região, pois os trajetos 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 sobrepor etapas para que as mais lentas sejam executadas enquanto um trabalho já está em andamento. Você pode criar e ajustar essa cascata manualmente em várias iterações, usando os padrões acima, ou começar com um pipeline que já tenha otimizações de latência incluídas.

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

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

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