Optimización de latencia en agentes de voz: guía paso a paso

La capacidad de respuesta de un agente de voz depende del tiempo total que pasa desde que el usuario termina de hablar hasta que el agente empieza a responder. Ese retraso rara vez lo causa un solo componente lento. Se acumula en varias etapas independientes, cada una sumando decenas o cientos de milisegundos, y para reducirlo hay que saber cuánto tarda cada etapa.

Optimizar la latencia de un agente de voz consiste en identificar dónde se pierde ese tiempo y recuperarlo etapa por etapa.

Este artículo complementa la visión general conceptual de la latencia. Mientras que esa página explica qué es la latencia, aquí hablamos de arquitectura y medición, para que salgas con un presupuesto de latencia que puedas medir y un conjunto de acciones concretas.

Resumen rápido

• El tiempo hasta el primer audio (time-to-first-audio) representa todo el pipeline, no solo el tiempo de inferencia de un modelo.
• El tiempo hasta el primer token del LLM y el endpointing son los dos factores que más suman.
• Solapar etapas, en vez de ejecutarlas en serie, recupera la mayor parte del presupuesto.
• El streaming, la elección del códec y ajustar el buffer del reproductor recortan milisegundos medibles.
• Debes medir por región en tu propio despliegue, informando P50 y P95.

Definir el presupuesto de latencia del agente de voz

Un presupuesto de latencia es el objetivo total de tiempo hasta el primer audio, repartido entre las etapas del pipeline, asignando a cada una un margen que debe sumar menos que tu objetivo. Definirlo es el primer paso y también donde más suelen fallar los equipos, porque a veces se confunden dos cifras que parecen similares pero no lo son.

La primera es la latencia de inferencia del modelo: el tiempo que tarda un modelo en generar la salida. Para nuestros modelos Flash esto son unos 75ms para entradas cortas, sin contar red ni sobrecarga de aplicación. Es un dato interno, útil para comparar modelos entre sí. No es el número que experimenta el usuario.

Desde el punto de vista del usuario, lo importante es el tiempo hasta el primer audio (TTFA): el tiempo que pasa desde que el usuario deja de hablar hasta que escucha la primera muestra de la respuesta del agente. El TTFA siempre es mayor que la latencia de inferencia de cualquier modelo, porque suma todo el pipeline.

Un agente de voz en cascada tiene cinco etapas:

• captura (micrófono) -> STT -> LLM -> TTS -> reproducción

El audio se graba desde el micrófono, se transcribe a texto, se envía a un modelo de lenguaje, el texto del modelo se convierte de nuevo en voz y esa voz se almacena en buffer y se reproduce. Cada etapa añade latencia, y en varias de ellas el mayor coste no es el que imaginas.

Aquí tienes un ejemplo para un agente en inglés con servidores cerca del usuario. Los valores son rangos orientativos, no garantías.

Normalmente, los dos factores que más suman a la latencia son el tiempo hasta el primer token del LLM y el retraso de endpointing al principio de la cadena.

La tabla es útil para visualizar el pipeline, pero da a entender que las etapas se ejecutan en serie, y no es así. Muchas de las optimizaciones más importantes de latencia en agentes de voz vienen de solaparlas, y ahí es donde se recupera la mayor parte del presupuesto.

Voz a Texto: optimización de latencia en transcripción y endpointing

La transcripción es la segunda etapa del pipeline, y su coste real no es la transcripción en sí, sino decidir cuándo el usuario ha terminado de hablar. Aquí cubrimos ambos aspectos para ayudarte a optimizar la latencia.

La transcripción ocurre antes de llegar al LLM. Scribe v2 en Tiempo Real (scribe_v2_realtime) devuelve transcripciones parciales en unos 150ms y transmite en fragmentos de audio, así que la transcripción se va generando mientras el usuario sigue hablando. Soporta PCM de 8kHz a 48kHz y codificación mu-law, relevante para la sección de códecs más abajo. Los parciales de 150ms son muy rápidos.

El mayor coste de latencia es el endpointing: el momento en que tu sistema decide que el usuario ha terminado su turno.

La Detección de Actividad de Voz (VAD) segmenta el habla por silencios, y ahí es donde se acumula el tiempo. Si esperas, por ejemplo, 700ms de silencio antes de dar el turno por terminado, añades 700ms a cada turno, además de la transcripción. Ese retraso es invisible en un benchmark de precisión de transcripción, pero muy evidente en una conversación real. Suele ser la mayor latencia controlable de todo el pipeline, y como es controlable, es un buen punto de partida.

El endpointing es un equilibrio entre rapidez y no interrumpir. Un umbral de silencio corto hace que el agente responda rápido, pero puede cortar al usuario en una pausa natural. Un umbral largo es seguro pero lento. En la práctica, los tres cambios que más optimizan la latencia en voz a texto son:

1. Ajusta el umbral de silencio: Reduce el umbral de silencio al valor más bajo que no corte las pausas naturales de tus usuarios y mide la tasa de interrupciones en producción en vez de adivinar.
2. Incluye un control físico: Usa control manual cuando tu aplicación sabe que el turno ha terminado por otra señal (soltar un botón de hablar, un evento en la interfaz), en vez de esperar al temporizador VAD.
3. Solapa con el procesamiento del LLM: Envía los parciales estables al LLM y revisa si la transcripción final cambia, una ejecución especulativa que esconde el retraso de endpointing tras el procesamiento del prompt del LLM.

Para más información, Scribe v2 Realtime se describe en detalle en la página de capacidades de voz a texto y en la página de producto de voz a texto en tiempo real.

La contribución del LLM a la latencia

El modelo de lenguaje suele ser el mayor responsable del TTFA, así que es donde más compensa solapar procesos para optimizar la latencia. La clave aquí es que el agente no necesita toda la respuesta antes de empezar a hablar.

El patrón que más recupera presupuesto de latencia es transmitir los tokens del LLM y enviarlos al TTS según llegan, agrupados por frases o cláusulas. La lógica es almacenar tokens hasta un punto de frase, luego sintetizar esa frase mientras se genera la siguiente:

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 conversaciones largas, usa mejor el WebSocket de TTS para que la conexión abierta reciba texto de forma incremental sin tener que volver a conectar en cada frase. Solo cuenta para tu límite de concurrencia el tiempo en que el modelo está generando audio, así que un WebSocket abierto e inactivo apenas consume recursos.

Texto a Voz: streaming y elección de voz

Texto a voz es la etapa donde puedes precisar la latencia con más exactitud. Hay dos factores principales: cómo transmites el audio y qué voz eliges.

Flash v2.5 (eleven_flash_v2_5) es el modelo recomendado para agentes. Ofrece unos 75ms de inferencia para entradas cortas, soporta 32 idiomas y acepta hasta 40.000 caracteres por petición.

La cifra de 75ms es solo inferencia. La línea de TTFA de TTS en el presupuesto anterior es mayor porque suma el viaje de red y la gestión del servidor.

El mayor factor aquí es el streaming. Si pides el audio completo y esperas, el usuario espera a que se sintetice todo antes de oír nada. Si transmites, el usuario escucha el primer fragmento en cuanto se genera, y el resto llega mientras ya está escuchando. El streaming no hace el modelo más rápido; simplemente empieza a enviar audio al usuario mientras sigue generando.

La guía de streaming cubre el streaming por HTTP, y la guía de WebSocket en tiempo real explica la ruta WebSocket que querrás usar para enviar tokens desde un LLM.

Inicializa el cliente una vez y reutilízalo en cada llamada:

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

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

Luego configura el stream y reenvíalo según llega:

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
}

El otro factor es la elección de voz, que también tiene un coste de latencia. Las voces por defecto, voces sintéticas y Clonados Instantáneos de Voz (IVC) se sintetizan más rápido que los Clonados Profesionales de Voz (PVC), porque los PVC tienen más complejidad de modelo y añaden sobrecarga por generación. Para un agente con requisitos estrictos de latencia, la combinación de Flash más una voz por defecto o IVC es la opción más rápida.

Opciones de tamaño de fragmento en streaming

Con los tokens llegando al TTS y el audio de vuelta, la siguiente decisión es el tamaño de los fragmentos y cuánto buffer usa el reproductor antes de empezar.

Fragmentos más pequeños llegan antes al reproductor, bajando la latencia del primer byte, a cambio de más mensajes y algo más de sobrecarga por fragmento. Los fragmentos grandes son más eficientes de transportar pero hacen que el usuario espere más por el primero. Para agentes interactivos, es mejor usar fragmentos pequeños al principio, porque el usuario espera ese primer fragmento; los siguientes llegan mientras ya se reproduce audio y su tamaño importa menos.

El reproductor suma una parte importante de la latencia restante. La mayoría de reproductores de audio no empiezan a reproducir con el primer byte. Hacen un pequeño buffer para evitar cortes si el stream se ralentiza. Un buffer por defecto de 500ms es habitual y se suma directamente a la latencia percibida. Reducirlo implica algo más de riesgo de cortes a cambio de menor TTFA, y el valor adecuado depende del jitter de red entre tu servidor y el cliente:

• En una conexión estable (reproducción en servidor, cliente cercano), un buffer de 50 a 150ms suele ser seguro y reduce notablemente el TTFA.
• En una conexión móvil o entre regiones con jitter, un buffer mayor evita huecos audibles que son peores que la latencia que añaden.

La configuración exacta depende de tu caso de uso y de tus prioridades.

Elección de códec

El destino del audio debe marcar el códec que pides. Devolvemos formatos como mp3_44100_128, mp3_22050_32, pcm_16000, pcm_24000 y ulaw_8000. Usar el formato nativo del transporte elimina un paso de transcodificación y ayuda a optimizar la latencia del agente de voz.

Para telefonía, como Twilio y proveedores similares, usa ulaw_8000. La red telefónica es mu-law a 8kHz de extremo a extremo, así que pedirlo directamente evita una transcodificación y se ajusta a lo que espera el operador. No tiene sentido sintetizar audio de más calidad que la red va a reducir; solo añadirías latencia y no ganarías nada audible.

Para WebRTC y reproducción en navegador, usa PCM (pcm_24000 o pcm_16000) o un formato MP3. PCM es sin comprimir, así que no hay que decodificar en el cliente, lo que elimina algo de latencia por fragmento y es útil si alimentas directamente un pipeline de Web Audio. MP3 es más compacto en la red, lo que ayuda en conexiones limitadas, a cambio de una ligera decodificación en el cliente.

Geografía y distancias de red

Todas las optimizaciones anteriores suponen que los bytes viajan poca distancia. La geografía marca el mínimo de tu presupuesto de latencia, así que conviene revisarlo antes de ajustar nada más.

Servimos peticiones desde clusters en Norteamérica, Europa y el Sudeste Asiático y cada petición se enruta automáticamente al cluster más cercano. El viaje de red por internet suele ser de 20 a 200ms según la proximidad geográfica, y no se puede reducir salvo cambiando dónde tienes tu infraestructura.

Un agente que parece instantáneo en San Francisco, cerca de un cluster norteamericano, puede parecer lento a un usuario en el sur de Asia cuyo tráfico cruza el océano dos veces por turno.

La solución es ubicar tus servidores de aplicación cerca de tus usuarios, no solo de nosotros. Si tus usuarios están en Europa, ejecuta tu backend de agente en Europa para que el tramo usuario-servidor sea corto; nuestro enrutamiento se encarga luego del tramo servidor-modelo desde un cluster cercano.

Mide tú mismo la latencia de tu agente de voz

Los valores de la tabla de presupuesto de latencia anterior son rangos orientativos para planificar. Los valores reales deben salir de un script como este, ejecutado en tu propio despliegue.

El siguiente ejemplo mide el TTFA para la etapa de TTS en aislamiento, el tiempo desde la petición hasta el primer fragmento de audio, en muchas pruebas, e informa los percentiles. Ejecútalo desde la misma región donde tienes tus servidores, no desde tu máquina de desarrollo. Usa el cliente de elevenlabs de antes:

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`);

Algunas cosas a tener en cuenta:

• Informa P50 y P95: Concéntrate en estos valores, no en la media. La media esconde los picos, y los picos son los que hacen que un agente parezca poco fiable. P95 es la experiencia de una de cada veinte interacciones.
• Experimenta por ubicación: Ejecuta el mismo script desde cada región que atiendes y guarda los resultados por separado.
• Espacia para mayor precisión: Separa tus peticiones (el setTimeout de arriba). Si las lanzas todas a la vez, mides tu propia cola en vez del servicio. Si superas el límite de concurrencia, las peticiones se ponen en cola por prioridad, lo que suele añadir unos 50ms, y si excedes la capacidad recibes HTTP 429.
• Mide toda la cadena de latencia: Aplica el mismo patrón de medición a las demás etapas. Mide la finalización de STT, el primer token del LLM y el arranque del reproductor con performance.now(), así podrás rellenar tu propia tabla de presupuesto y ver qué etapa atacar primero.

Siguiendo estos consejos, podrás medir tú mismo la latencia de tu agente de voz. Así tendrás claro por dónde empezar a mejorar.

¿Qué reduce más la latencia en agentes de voz?

Si quieres acciones rápidas en las que centrarte, estos son los cambios con más impacto.

Más o menos por orden de impacto, puedes usar estos métodos para reducir la latencia del agente:

• Empieza el trabajo del LLM sobre parciales estables de STT para ocultar el retraso de endpointing.
• Transmite los tokens del LLM al TTS en los límites de frase para que la síntesis de la primera frase se solape con la generación de la segunda.
• Transmite el audio de TTS al reproductor y ajusta el buffer al valor más bajo que tolere el jitter de tu red.
• Usa Flash más una voz por defecto o IVC para el TTS más rápido, y ajusta el códec al transporte (ulaw_8000 para telefonía, PCM o MP3 para navegador/WebRTC).
• Ubica tus servidores cerca de tus usuarios y mide por región, porque los tramos de red son reales y desiguales.

Para técnicas más avanzadas, consulta la guía para desarrolladores sobre optimización de latencia. Para un punto de partida funcional, el quickstart de la API y la guía de streaming tienen ejemplos completos.

¿Quieres acceso más rápido a agentes en cascada optimizados?ElevenAgents ya implementa este pipeline con optimizaciones de solapamiento.

Crea agentes de voz con baja latencia con ElevenAgents

Optimizar la latencia de un agente de voz requiere medir cada etapa y luego solaparlas para que las más lentas se ejecuten mientras ya hay trabajo en marcha. Puedes construir y ajustar esa cascada a mano en varias iteraciones usando los patrones anteriores, o empezar desde un pipeline que ya tiene optimizaciones de latencia.

ElevenAgents implementa toda esta cascada, desde el streaming de STT hasta la entrega token a token al LLM y Flash TTS, con técnicas de solapamiento ya integradas. En vez de empezar desde cero, solo tendrás que ajustar los umbrales para el rendimiento que más te importa.

Empieza usando ElevenAgents para crear un agente hoy o contactar con ventas para más información.

Preguntas frecuentes sobre optimización de latencia en agentes de voz