Limitación de velocidad con IA para voz: concurrencia, colas y errores 429

La mayoría de equipos aplica la limitación de velocidad con IA para voz igual que con otras APIs: ponen un tope de peticiones por minuto, reintentan cuando el servidor rechaza y siguen adelante. Pero en ElevenLabs, ese modelo falla en el primer pico de tráfico, porque el límite real es la concurrencia, no el número de peticiones.

Esta guía explica por qué la concurrencia es la verdadera restricción y repasa los patrones del lado del cliente para mantenerte dentro del límite. Desde pools de concurrencia limitada y gestión elegante de errores 429, hasta equidad multi-tenant y buckets de tokens o leaky buckets, te proponemos sistemas prácticos que puedes implementar. Cada patrón viene acompañado de una implementación en TypeScript lista para adaptar.

Si creas agentes de voz, pipelines de narración o cualquier otro sistema de producción sobre nuestros modelos y quieres escalar, esta guía es para ti.

En resumen

• La limitación de velocidad con IA para voz es control de concurrencia, no contar peticiones por minuto.
• Al llegar al límite de velocidad, el tráfico no se rechaza de inmediato. Las peticiones entran en una cola de prioridad que añade unos 50 ms.
• Si se supera la capacidad incluso tras la cola, se genera un error HTTP 429.
• WebSockets aumentan mucho la capacidad efectiva, ya que solo la generación activa cuenta para tu límite.
• Los sistemas multi-tenant necesitan una capa extra de equidad: buckets por tenant, colas ponderadas, reserva de margen y partición por claves para aislar.
• Dos cabeceras de respuesta, current-concurrent-requests y maximum-concurrent-requests, te indican tu situación respecto a la limitación de velocidad con IA.

Por qué el límite es la concurrencia y no las peticiones por minuto

La concurrencia es el número de peticiones en curso en un momento dado. Las peticiones por minuto son el flujo en una ventana de tiempo. Entender la diferencia es clave porque cambia qué palanca te mantiene dentro del límite.

Al usar uno de los modelos de ElevenLabs, la carga del servidor escala con el número de usuarios concurrentes. La generación de audio ocupa un slot durante todo el proceso, y esa duración varía según la longitud del input, el modelo y la carga.

Un tope de peticiones por minuto no te dice cuántos slots están ocupados ahora mismo, que es lo único que mide el servidor.

Límites por plan y familia de modelos

Tu presupuesto de concurrencia no es un solo número. Los límites de concurrencia varían según el plan y la familia de modelos. Por ejemplo, Voz a Texto tiene un límite más alto que Texto a Voz, porque las peticiones de transcripción suelen durar menos y el sistema puede absorber más a la vez.

El límite es por familia de modelos. Si usas Flash para agentes y Multilingual v2 para narración, trabajas con dos presupuestos distintos a la vez. Las cifras actuales por plan y la sección de concurrencia están documentadas en la página de modelos.

¿Qué ocurre al llegar al límite de concurrencia?

Al llegar al límite de concurrencia, el tráfico no se rechaza de inmediato. El sistema degrada de forma progresiva mediante una cola de prioridad, y solo rechaza por completo si sigues superando la capacidad total.

Mientras estés por debajo del límite, las peticiones se procesan al instante. Al llegar al límite, las siguientes peticiones entran en una cola ordenada según la prioridad de tu plan. La cola suele añadir unos 50 ms de latencia, así que un pequeño exceso apenas se nota para los usuarios.

Si el sistema sigue sobrepasado tras la cola, recibes un HTTP 429. Esa es la señal para reducir el ritmo, no para reintentar de inmediato. El nivel de prioridad en la tabla determina el orden de tus peticiones en la cola respecto al resto del tráfico; los planes superiores vacían la cola antes.

HTTP vs. WebSocket: cómo cuenta cada uno para tu límite

El transporte que elijas influye directamente en la limitación de velocidad y el presupuesto. Una misma conversación puede consumir cantidades muy distintas de tu presupuesto de concurrencia según si va por HTTP o WebSocket.

Por HTTP, cada petición cuenta individualmente para tu límite de concurrencia durante toda su duración. Por WebSocket, solo cuenta el tiempo en que el modelo está generando audio. Un WebSocket abierto pero inactivo casi no cuenta.

Para un agente de voz, una conversación tiene largos ratos sin hablar y sin generación. Con HTTP, ocuparías un slot durante toda la petición en cada turno. Con WebSocket, el slot solo se usa durante los milisegundos de generación activa, así que un slot se comparte entre muchas conversaciones.

Consulta la guía de WebSocket TTS en tiempo real para ver los detalles del protocolo. Para tráfico interactivo, WebSocket es la mejor opción.

Por qué ~5 de concurrencia pueden soportar ~100 emisiones

Las matemáticas de la concurrencia sorprenden hasta que tienes en cuenta el tiempo de reproducción. La generación es mucho más rápida que la reproducción, y un slot solo está ocupado mientras se genera audio. Esa diferencia es lo que permite que un presupuesto pequeño sirva a mucha gente.

Una petición que tarda una fracción de segundo en generar produce varios segundos de audio que el oyente reproduce después, y durante la reproducción el slot se libera y queda disponible para otros.

Como regla general, un límite de concurrencia de 5 puede soportar unas 100 emisiones de audio simultáneas. El número exacto depende de la voz, el ritmo y los silencios entre frases.

Las cabeceras que explican tu situación

No necesitas adivinar tu posición respecto al límite. Cada respuesta incluye dos números que puedes usar para medir el margen en vez de estimar.

Fíjate en estas dos cabeceras:

• solicitudes simultáneas actuales: ¿cuántas peticiones hay en curso ahora mismo?
• máximo de solicitudes simultáneas: tu límite para esa familia de modelos.

Juntas, estas cabeceras ofrecen una visión en tiempo real de tu uso actual y la capacidad disponible. No deberías tener que adivinar antes de toparte con los límites de IA.

Estrategias del lado del cliente para la limitación de velocidad con IA

Hay cuatro mecanismos que cubren casi todos los escenarios de limitación de velocidad con IA:

• Token bucket: Si hay tokens disponibles, permite que las peticiones pasen. La capacidad se repone con el tiempo, así que puede absorber picos cortos sin llegar al límite.
• Leaky bucket: Intenta suavizar el tráfico entrante a un ritmo fijo, evitando que los picos saturen tus sistemas posteriores.
• Pool de concurrencia limitada: Limita el número total de peticiones activas a la vez, así nunca superas el límite de concurrencia.
• Backoff exponencial con jitter completo: Aumenta el tiempo entre reintentos fallidos para evitar que todos los clientes reintenten a la vez.

Las siguientes secciones muestran cómo construir cada uno, empezando por el que más se ajusta al límite de concurrencia.

Todos los ejemplos siguientes asumen un solo cliente, inicializado una vez:

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

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

Concurrencia limitada: el mecanismo que encaja con el límite

Como el servidor mide la concurrencia, el control más directo es un pool de workers limitado que pone tope a las peticiones en curso. Pon el tope un poco por debajo del límite de tu plan para dejar margen a la cola de prioridad y al jitter.

async function pool<T, R>(
  items: T[],
  maxInFlight: number,
  worker: (item: T) => Promise<R>,
): Promise<R[]> {
  const results: R[] = new Array(items.length);
  let next = 0;

  async function run(): Promise<void> {
    while (next < items.length) {
      const i = next++;
      results[i] = await worker(items[i]); // never more than maxInFlight of these run at once
    }
  }

  await Promise.all(
    Array.from({ length: Math.min(maxInFlight, items.length) }, run),
  );
  return results;
}

async function synthesize(text: string): Promise<Buffer> {
  const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
    text,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  const chunks: Buffer[] = [];
  for await (const chunk of stream) chunks.push(Buffer.from(chunk));
  return Buffer.concat(chunks);
}

// Plan Flash limit is, say, 10. Stay under it.
const texts = Array.from({ length: 50 }, (_, i) => `Sentence number ${i}.`);
const audio = await pool(texts, 8, synthesize); // never more than 8 in flight

Token bucket: permite picos, limita la media

Un token bucket almacena hasta su capacidad máxima y se recarga a refillRate tokens por segundo. Cada petición consume un token, así que el bucket permite picos cortos hasta su tamaño, pero limita la tasa a largo plazo.

Es la herramienta adecuada para suavizar el momento en que llega una cola de trabajo de golpe, evitando disparar la concurrencia de repente.

class TokenBucket {
  private tokens: number;
  private updated = performance.now();

  constructor(private capacity: number, private refillPerSec: number) {
    this.tokens = capacity;
  }

  private refill(): void {
    const now = performance.now();
    const elapsed = (now - this.updated) / 1000;
    this.tokens = Math.min(this.capacity, this.tokens + elapsed * this.refillPerSec);
    this.updated = now;
  }

  tryAcquire(cost = 1): boolean {
    this.refill();
    if (this.tokens >= cost) {
      this.tokens -= cost;
      return true;
    }
    return false;
  }

  timeUntil(cost = 1): number {
    this.refill();
    return this.tokens >= cost ? 0 : ((cost - this.tokens) / this.refillPerSec) * 1000;
  }
}

Leaky bucket: asegura un ritmo constante

En algunos casos no quieres tolerar picos. Un leaky bucket admite trabajo a un ritmo fijo y constante, sin importar lo irregular que sea la entrada. Es mejor opción cuando el sistema posterior prefiere una carga predecible y estable.

Por ejemplo, cuando quieres mantenerte bien dentro de un presupuesto de concurrencia pequeño compartido con otros servicios.

class LeakyBucket {
  private next = performance.now();
  constructor(private intervalMs: number) {} // admit at most one item per intervalMs

  async acquire(): Promise<void> {
    const now = performance.now();
    const wait = Math.max(0, this.next - now);
    this.next = Math.max(now, this.next) + this.intervalMs;
    if (wait > 0) await new Promise((r) => setTimeout(r, wait));
  }
}

Backoff exponencial con jitter completo

Cuando una petición falla con un estado reintentable, reintentar de inmediato empeora la situación. El backoff separa los reintentos y el jitter completo aleatoriza cada espera, evitando que muchos clientes reintenten a la vez y provoquen el mismo pico que causó el fallo.

El ejemplo siguiente usa RetryableError, una pequeña clase que lleva el estado fallido y cualquier valor Retry-After. Se define en la sección de gestión elegante de errores 429.

async function withBackoff<T>(
  call: () => Promise<T>,
  opts: { maxAttempts?: number; baseMs?: number; capMs?: number } = {},
): Promise<T> {
  const { maxAttempts = 5, baseMs = 500, capMs = 20_000 } = opts;
  let attempt = 0;
  for (;;) {
    try {
      return await call();
    } catch (e) {
      if (!(e instanceof RetryableError) || ++attempt >= maxAttempts) throw e;
      // honor Retry-After if present; otherwise capped exponential growth with full jitter
      const delay =
        e.retryAfterMs ?? Math.random() * Math.min(capMs, baseMs * 2 ** attempt);
      await new Promise((r) => setTimeout(r, delay));
    }
  }
}

Gestión elegante de errores 429: qué hacer al llegar al límite

Un 429 significa que superaste la capacidad incluso tras la cola de prioridad, así que la respuesta correcta es reducir el ritmo, no insistir más. Hay cuatro formas de gestionarlo bien:

• Detección
• Respetar Retry-After
• Mostrar backpressure
• Evitar tormentas de reintentos con un circuit breaker

Vamos a ver cada una en detalle.

La primera es la detección. Trata HTTP 429 (y 500, 502, 503 y 504 transitorios) como reintentables, y 400, 401, 403 y 422 como no reintentables; reintentar una petición mal formada o no autorizada nunca funciona y solo desperdicia un slot.

La segunda es respetar Retry-After. Si la respuesta incluye esa cabecera, síguela exactamente en vez de calcular tu propio retraso. El servidor sabe mejor que tu fórmula cuándo espera tener capacidad. Solo usa backoff con jitter si la cabecera no está.

class RetryableError extends Error {
  constructor(public status: number, public retryAfterMs?: number) {
    super(`retryable ${status}`);
  }
}

function classify(resp: Response): void {
  if ([429, 500, 502, 503, 504].includes(resp.status)) {
    const ra = resp.headers.get("retry-after");
    throw new RetryableError(resp.status, ra ? Number(ra) * 1000 : undefined);
  }
  if (!resp.ok) throw new Error(`non-retryable ${resp.status}`);
}

La tercera es mostrar backpressure. No dejes que los reintentos se acumulen sin que se note. Si la profundidad de la cola o el margen indican que no puedes servir una nueva petición pronto, recházala directamente con una señal clara al llamador en vez de aceptar trabajo que no puedes hacer.

La cuarta es evitar tormentas de reintentos con un circuit breaker. Si los fallos superan un umbral, abre el circuito y falla rápido durante una ventana de enfriamiento en vez de enviar peticiones que sabes que fallarán. Tras la ventana, envía algunas peticiones de prueba; si funcionan, cierra el circuito.

class CircuitBreaker {
  private failures = 0;
  private openedAt: number | null = null;
  constructor(private threshold = 5, private cooldownMs = 10_000) {}

  allow(): boolean {
    if (this.openedAt === null) return true;
    if (performance.now() - this.openedAt >= this.cooldownMs) {
      this.openedAt = null; // half-open: allow a probe
      this.failures = 0;
      return true;
    }
    return false;
  }

  record(ok: boolean): void {
    if (ok) {
      this.failures = 0;
      this.openedAt = null;
    } else if (++this.failures >= this.threshold) {
      this.openedAt = performance.now();
    }
  }
}

Patrones de cuota multi-tenant para la limitación de velocidad con IA

Hasta ahora hemos supuesto una sola aplicación con un solo presupuesto. Si creas un SaaS sobre ElevenLabs, el problema cambia: tu presupuesto de concurrencia se reparte entre todos tus clientes, y un tenant que lance un proceso por lotes no debería dejar sin capacidad al tráfico en vivo de los demás. Necesitas una capa de equidad entre tus tenants y el límite global.

La base son los token buckets por tenant. Da a cada tenant su propio bucket según lo que le corresponde y admite una petición solo si tanto el bucket del tenant como el limitador global lo permiten.

class MultiTenantAdmission {
  private tenantBuckets = new Map<string, TokenBucket>();
  constructor(private globalMaxInFlight: number) {}

  private bucket(tenant: string): TokenBucket {
    let b = this.tenantBuckets.get(tenant);
    if (!b) {
      // Each tenant: burst of 5, sustained 2 starts/sec. Tune per tier.
      b = new TokenBucket(5, 2);
      this.tenantBuckets.set(tenant, b);
    }
    return b;
  }

  async run<R>(tenant: string, work: () => Promise<R>): Promise<R> {
    const b = this.bucket(tenant);
    if (!b.tryAcquire()) {
      throw new RetryableError(429, b.timeUntil());
    }
    // ... then admit through the global limiter (e.g. the bounded pool above)
    return work();
  }
}

Los buckets mantienen a raya a cada tenant, pero no deciden quién gana cuando varios compiten por el limitador global. Para eso, usa colas ponderadas.

No sirvas en orden de llegada, porque un pico de un tenant podría monopolizar los slots. Mantén una cola por tenant y reparte según el peso de cada uno, así un tenant de pago recibe más capacidad que uno gratuito.

Además de la equidad, reserva margen. No dejes que el tráfico normal consuma el 100% del límite de concurrencia. Guarda un 15-20% como buffer para peticiones interactivas sensibles a la latencia y para la cola de prioridad.

Cuando la equidad dentro de un solo presupuesto no basta, divide por workspaces o claves. Un solo presupuesto de concurrencia acaba siendo el cuello de botella, por muy bien que lo repartas.

En ese caso, separa cargas en distintos workspaces o claves de API con sus propios presupuestos: por ejemplo, una clave para tráfico de agentes en tiempo real y otra para narración en segundo plano, así una cola de narración no afecta a la capacidad de los agentes.

Los workspaces también permiten aplicar restricciones de alcance, cuotas de crédito y controles por clave, descritos en la documentación de autenticación.

Monitoriza tu uso de concurrencia

Nada de esto se puede ajustar sin medir; no puedes gestionar el margen si no lo mides. Registra current-concurrent-requests y maximum-concurrent-requests en cada respuesta, etiquetados por familia de modelo, y emite el ratio de uso como métrica.

function recordHeadroom(resp: Response, metrics: Metrics): void {
  const cur = Number(resp.headers.get("current-concurrent-requests"));
  const max = Number(resp.headers.get("maximum-concurrent-requests"));
  if (Number.isFinite(cur) && Number.isFinite(max)) {
    metrics.gauge("el.concurrency.current", cur);
    metrics.gauge("el.concurrency.max", max);
    if (max > 0) metrics.gauge("el.concurrency.utilization", cur / max);
  }
}

Cuatro señales a seguir:

• Uso (actual / máximo).
• Tasa de errores 429 sobre el total de peticiones.
• Profundidad de reintentos, es decir, número de intentos por petición lógica.
• Time-to-first-audio, medido desde tu aplicación, no desde la inferencia del modelo. Consulta la sección sobre latencia para ver qué incluye el TTFA.

Un sistema sano mantiene el uso bien por debajo de la saturación y solo ve errores 429 en picos puntuales. Monitorizar estas señales te da visibilidad sobre la presión de los límites mucho antes de que se convierta en un problema.

Cuándo escalar más allá de la limitación del lado del cliente

Los patrones del lado del cliente ayudan mucho, pero la demanda estable acabará superándolos. Cuando eso pase, es momento de hacer cambios que ayuden tanto en coste como en esfuerzo.

Cada uno de estos pasos te dará más capacidad.

Empieza cambiando de HTTP a WebSockets para tráfico interactivo. Si tus agentes o casos de uso en vivo van por HTTP, pasar a WebSocket cambia el cálculo: solo la generación activa cuenta. Para cargas conversacionales, esto suele multiplicar la capacidad sin cambiar de plan, porque el tiempo de conversación inactiva deja de consumir slots.

Si tienes picos pero la media cabe en el presupuesto, un token o leaky bucket junto a un pool limitado suaviza los picos y los ajusta a la media.

Luego elige el modelo adecuado. Una generación más rápida ocupa cada slot menos tiempo, así que sube el número de emisiones que puede soportar un límite fijo. Eleven Flash v2.5 es la opción de menor latencia para trabajo en tiempo real; si lo combinas con un Clonar Voz Instantáneo o una voz por defecto, evitas la sobrecarga de las voces profesionales.

Solo después deberías subir de plan. Si tu demanda estable supera el presupuesto tras optimizar el cliente, un plan superior sube tanto el límite de concurrencia por modelo como la prioridad en la cola. Compara niveles en la página de precios de la API.

Si necesitas límites más altos de los publicados, los planes Enterprise ofrecen límites de concurrencia elevados y personalizados y la máxima prioridad en la cola. Hay controles extra para casos de uso elegibles, como listas blancas de IP (en preview Enterprise) y modos sin retención. Contacta con tu account manager para ampliar límites.

Resumen de lo importante sobre la limitación de velocidad con IA

El error principal es tratar la limitación de voz IA como un simple conteo de peticiones. Todo esto va de controlar la concurrencia. El número clave es cuántas peticiones están generando audio a la vez y cuánto tiempo ocupa cada una su slot.

Construye el cliente en torno a ese hecho.

Limita las peticiones en curso con un pool, regula la admisión con un token o leaky bucket, reintenta con backoff exponencial y jitter, respeta Retry-After y corta el circuito antes de una tormenta de reintentos.

Para sistemas multi-tenant, añade buckets por tenant, equidad ponderada, margen reservado y partición para aislar. Vigila las cabeceras current-concurrent-requests y maximum-concurrent-requests y alerta según la tendencia de uso, no por los fallos.

Cuando realmente necesites más capacidad, sigue este orden: primero WebSockets y mejor comportamiento del cliente, luego el modelo adecuado, después subir de plan y por último los límites Enterprise.

Crea aplicaciones de voz con ElevenAPI

La limitación de velocidad con IA a nivel profesional empieza con el transporte adecuado, el modelo correcto y cabeceras que te indican tu situación exacta.

ElevenAPI ofrece modelos de baja latencia como Eleven Flash v2.5, streaming en tiempo real por WebSocket, Voz a Texto y APIs de Texto a Voz, y cabeceras de concurrencia por respuesta para que crees agentes de voz que escalen dentro de tus límites.

Combinando estas estrategias de limitación de velocidad con IA, ofrecerás experiencias de voz ágiles y con rendimiento predecible (incluso bajo carga).

Descubre ElevenAPI para ver todos los modelos en acción, o crea una cuenta y empieza a crear con ElevenLabs hoy mismo.

Preguntas frecuentes sobre la limitación de velocidad con IA