Limitação de taxa com IA para voz: Concorrência, filas e erros 429

A maioria das equipes aplica a limitação de taxa de IA para voz da mesma forma que lida com outras APIs: limita as solicitações por minuto, tenta novamente quando o servidor impõe restrições e segue em frente. Para cargas de trabalho na ElevenLabs, esse modelo deixa de funcionar no primeiro pico de tráfego, porque o limite que você realmente atinge é o de simultaneidade, não a contagem de solicitações.

Este guia explica por que a simultaneidade é a verdadeira restrição e apresenta os padrões no lado do cliente que ajudam você a se manter dentro dela. De pools de simultaneidade limitados e tratamento adequado de erros 429 à equidade entre locatários e aos buckets de tokens e de vazamento, oferecemos sistemas práticos que você pode implementar. Incluímos uma implementação funcional em TypeScript para cada padrão, que você pode adaptar.

Se você cria agentes de voz, pipelines de narração ou qualquer outro sistema de produção baseado em nossos modelos e quer escalar, este guia é para você.

Resumo

• A limitação de taxa de IA para voz é controle de simultaneidade, não contagem de solicitações por minuto.
• Atingir o teto da limitação de taxa não rejeita o tráfego imediatamente. Em vez disso, as solicitações entram em uma fila de prioridade que adiciona cerca de 50 ms.
• Ultrapassar a capacidade mesmo após entrar na fila gera um erro HTTP 429.
• WebSockets aumentam significativamente a capacidade efetiva, pois apenas a geração ativa conta para o seu limite.
• Sistemas multilocatários precisam de uma camada extra de equidade: buckets por locatário, enfileiramento justo ponderado, capacidade reservada e divisão entre chaves para isolamento. 
• Dois cabeçalhos de resposta, current-concurrent-requests e maximum-concurrent-requests, mostram sua situação em relação à limitação de taxa de IA.

Por que o limite é de simultaneidade, não de solicitações por minuto

Simultaneidade é o número de solicitações em andamento no mesmo momento. Solicitações por minuto representam a vazão em um período. Entender essa diferença é importante porque ela muda qual mecanismo mantém você dentro do limite.

Ao usar um dos modelos da ElevenLabs, a carga de trabalho do servidor aumenta de acordo com o número de usuários simultâneos. A geração de áudio ocupa uma vaga durante toda a geração, e essa duração varia conforme o tamanho da entrada, o modelo e a carga.

Um limite de solicitações por minuto não informa quantas vagas estão ocupadas agora, que é a única métrica que o servidor controla.

Limites por plano e por família de modelos

Seu orçamento de simultaneidade não é um único número. Os limites de simultaneidade variam conforme o plano e a família de modelos. Por exemplo, Speech to Text tem um limite maior em comparação com Text to Speech, porque as solicitações de transcrição normalmente duram menos e o sistema consegue processar mais delas de uma vez.

O limite é por família de modelos. Se você usa Flash para agentes e Multilingual v2 para narração, está trabalhando com dois orçamentos separados ao mesmo tempo. Os valores atuais por plano e a seção sobre simultaneidade estão documentados na página de modelos.

O que acontece quando você atinge o limite de simultaneidade?

Atingir o limite de simultaneidade não rejeita o tráfego imediatamente. O sistema se degrada de forma gradual por meio de uma fila de prioridade e só passa a rejeitar totalmente quando você continua acima da capacidade total do limite de taxa.

Enquanto você está abaixo do limite, as solicitações são executadas imediatamente. Ao atingi-lo, as solicitações seguintes entram em uma fila ordenada pelo nível de prioridade do seu plano. A fila normalmente adiciona cerca de 50 ms de latência, então um breve excesso quase não é percebido pelos usuários.

Se o sistema continuar acima da capacidade após o enfileiramento, você receberá um HTTP 429. Esse é o sinal para reduzir o ritmo, em vez de tentar novamente de imediato. O nível de prioridade na tabela determina como suas solicitações em fila são ordenadas em relação a outro tráfego; planos mais altos liberam a fila mais cedo.

HTTP vs. WebSocket: como cada um conta para o seu limite

O transporte escolhido influencia diretamente a limitação de taxa e o orçamento. A mesma conversa recebida pode consumir quantidades muito diferentes do seu orçamento de simultaneidade, dependendo de ela usar HTTP ou WebSocket.

Em HTTP, cada solicitação conta individualmente para o seu limite de simultaneidade durante toda a sua duração. Em um WebSocket, apenas o tempo em que o modelo está gerando áudio ativamente conta. Um WebSocket aberto, mas ocioso, quase não conta.

Para um agente de voz, há longos períodos em uma conversa em que ninguém está falando e o modelo não está gerando nada. Com HTTP, você manteria uma vaga ocupada pela duração da solicitação a cada turno. Com WebSocket, a vaga é consumida apenas durante os milissegundos de geração ativa, de modo que uma vaga de simultaneidade é compartilhada entre várias conversas. 

Consulte o guia de WebSocket para TTS em tempo real para ver os detalhes do protocolo. Para tráfego interativo, WebSockets são a opção padrão mais adequada.

Por que uma simultaneidade de ~5 pode atender a ~100 transmissões

A matemática por trás da simultaneidade parece contraintuitiva até você considerar o tempo de reprodução. A geração é muito mais rápida do que a reprodução, e uma vaga só fica ocupada ativamente enquanto o áudio está sendo gerado. Essa diferença é exatamente o que permite que um orçamento pequeno atenda a um grande público.

Uma solicitação que leva uma fração de segundo para gerar produz vários segundos de áudio que o ouvinte reproduz depois. Durante a reprodução, a vaga é liberada e fica disponível para outros ouvintes.

Como regra geral, um limite de simultaneidade de 5 pode atender a aproximadamente 100 transmissões de áudio simultâneas. O número exato depende da voz, do ritmo da fala e de quanto silêncio há entre as falas.

Os cabeçalhos que mostram sua situação

Você não precisa deduzir sua posição em relação ao limite. Cada resposta traz dois números que podem ser usados para medir a capacidade disponível, em vez de apenas estimá-la.

Fique de olho nestes dois cabeçalhos:

• current-concurrent-requests: quantas solicitações estão em andamento agora?
• maximum-concurrent-requests: seu limite para essa família de modelos.

Juntos, esses cabeçalhos fornecem uma visão em tempo real do seu uso atual e da capacidade disponível. Você não deveria precisar fazer suposições antes de esbarrar nos limites de taxa de IA.

Estratégias de limitação de taxa de IA no lado do cliente

Há quatro mecanismos básicos que cobrem quase todos os cenários de limitação de taxa de IA:

• Um bucket de tokens: se houver tokens disponíveis, permite que as solicitações prossigam. A capacidade é reabastecida ao longo do tempo, permitindo lidar com picos curtos sem atingir limites de taxa.
• Um bucket de vazamento: tenta suavizar o tráfego de entrada em uma taxa fixa de saída, evitando que picos repentinos sobrecarreguem seus sistemas downstream.
• Um pool de simultaneidade limitado: limita o número total de solicitações que podem estar ativas ao mesmo tempo, para que você nunca ultrapasse os limites de solicitações simultâneas.
• Backoff exponencial com jitter total: aumenta progressivamente o intervalo entre solicitações que falharam, evitando que todos os clientes tentem novamente ao mesmo tempo.

As seções abaixo mostram como implementá-los um de cada vez, começando pelo que corresponde mais diretamente ao limite de simultaneidade.

Todos os snippets abaixo pressupõem um único cliente, inicializado uma vez:

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

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

Simultaneidade limitada: o mecanismo que corresponde ao limite

Como o servidor mede a simultaneidade, o controle mais direto no cliente é um pool de workers limitado, que restringe quantas solicitações você tem em andamento ao mesmo tempo. Defina o limite um pouco abaixo do limite do seu plano para deixar espaço para a fila de prioridade e para o 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

Bucket de tokens: permita picos, limite a média

Um bucket de tokens armazena até capacity tokens e é reabastecido com refillRate tokens por segundo. Cada solicitação consome um token, portanto o bucket permite picos curtos de até seu tamanho, enquanto limita a taxa no longo prazo. 

É a ferramenta certa para suavizar o momento em que uma fila de trabalho chega de repente, para que você não envie tudo de uma vez e eleve a simultaneidade.

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;
  }
}

Bucket de vazamento: imponha uma saída constante

Em alguns casos, você não quer tolerar picos de forma alguma. Um bucket de vazamento admite trabalho a uma taxa fixa e constante, independentemente de quanto a entrada oscile. É a melhor escolha quando o sistema downstream prefere uma carga suave e previsível a picos ocasionais.

Por exemplo, quando você deliberadamente se mantém bem abaixo de um orçamento pequeno de simultaneidade compartilhado com outros serviços.

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 com jitter total

Quando uma solicitação falha com um status que permite nova tentativa, tentar imediatamente piora a situação. O backoff espaça as tentativas, e o jitter total aleatoriza cada atraso por todo o intervalo, o que impede que muitos clientes tentem novamente em sincronia e recriem o mesmo pico que causou a falha.

O snippet abaixo faz referência a RetryableError, uma classe pequena que contém o status da falha e qualquer valor de Retry-After. Ela é definida na seção sobre tratamento adequado de 429 abaixo.

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

Tratamento adequado de 429: o que fazer ao atingir o teto

Um 429 significa que você estava acima da capacidade mesmo após a fila de prioridade, então a resposta correta é reduzir o ritmo, não insistir mais nas tentativas. Há quatro formas de lidar com isso. Para fazer isso bem, siga quatro estratégias:

• Detecção
• Respeitar Retry-After
• Sinalizar a contrapressão
• Evitar tempestades de tentativas com um circuit breaker

Vamos analisar cada uma delas em mais detalhes.

A primeira é a detecção. Trate HTTP 429 (e os status transitórios 500, 502, 503 e 504) como passíveis de nova tentativa e 400, 401, 403 e 422 como não passíveis de nova tentativa; tentar novamente uma solicitação malformada ou não autorizada nunca funciona e apenas desperdiça uma vaga.

A segunda é respeitar Retry-After. Se a resposta incluir esse cabeçalho, siga-o exatamente, em vez de calcular seu próprio atraso. O servidor está informando quando espera ter capacidade e sabe disso melhor do que sua fórmula exponencial. Recorra ao backoff com jitter apenas quando o cabeçalho estiver ausente.

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

O terceiro aspecto é sinalizar a contrapressão. Não deixe que as tentativas se acumulem sem visibilidade. Se a profundidade da fila ou a capacidade disponível medida indicar que você não conseguirá atender uma nova solicitação em breve, rejeite-a na borda com um sinal claro ao chamador, em vez de aceitar um trabalho que você não pode executar.

O quarto é evitar tempestades de tentativas com um circuit breaker. Se as falhas ultrapassarem um limite, abra o circuito e falhe rapidamente durante um período de resfriamento, em vez de enviar solicitações que você espera que falhem. Após esse período, envie algumas solicitações de teste; se forem bem-sucedidas, feche o 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();
    }
  }
}

Padrões de cotas multilocatárias para limitação de taxa de IA

Tudo até aqui pressupõe um único aplicativo usando um único orçamento. Quando você cria um SaaS sobre a ElevenLabs, o problema muda: seu orçamento de simultaneidade é compartilhado por todos os seus clientes, e um locatário executando um trabalho em lote não deve privar todo o tráfego ao vivo dos outros locatários. Você precisa de uma camada de equidade entre seus locatários e o único limite upstream.

A base são os buckets de tokens por locatário. Dê a cada locatário seu próprio bucket, dimensionado de acordo com a cota a que ele tem direito, e aceite uma solicitação apenas quando tanto o bucket do locatário quanto um limitador global permitirem.

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();
  }
}

Os buckets mantêm cada locatário dentro da sua cota, mas não decidem quem vence quando os locatários disputam o limitador global. Para isso, use enfileiramento justo ponderado. 

Não atenda por ordem de chegada, pois isso permite que um pico de um locatário monopolize as vagas. Mantenha uma fila por locatário e distribua em proporção ao peso de cada um, para que um locatário pagante receba uma parcela maior da capacidade disputada do que um gratuito.

Além da equidade, reserve capacidade. Nunca deixe o tráfego normal consumir 100% do limite de simultaneidade. Reserve uma fração, como 15% a 20%, como margem para solicitações interativas sensíveis à latência e para a fila de prioridade.

Quando a equidade dentro de um único orçamento deixa de ser suficiente, divida entre workspaces ou chaves. Um único orçamento de simultaneidade acaba se tornando o gargalo, por mais equitativamente que você o divida. 

Nesse momento, separe as cargas de trabalho em workspaces ou chaves de API distintos, cada um com seu próprio orçamento: por exemplo, uma chave para o tráfego de agentes em tempo real e outra para narração em segundo plano, para que uma fila de narração não afete a capacidade dos agentes.

Os workspaces também permitem aplicar restrição de escopo, cotas de créditos e controles por chave, descritos na documentação de autenticação.

Monitoramento da utilização de simultaneidade

Nada disso pode ser ajustado sem medição; você não consegue gerenciar uma capacidade disponível que não mede. Registre current-concurrent-requests e maximum-concurrent-requests em cada resposta, identificados por família de modelos, e envie a taxa de utilização como uma 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);
  }
}

Quatro sinais para acompanhar:

• Utilização (atual / máximo).
• Taxa de 429 como proporção do total de solicitações.
• Profundidade de tentativas, o número de tentativas por solicitação lógica.
• Tempo até o primeiro áudio, medido a partir do seu aplicativo, não dos dados de inferência do modelo. Consulte o guia sobre latência para saber o que o TTFA inclui.

Um sistema saudável mantém a utilização confortavelmente abaixo da saturação e vê erros 429 apenas em picos ocasionais. Monitorar esses sinais dá visibilidade sobre a pressão da limitação de taxa muito antes de ela se tornar um problema de indisponibilidade.

Quando escalar além da limitação de taxa no lado do cliente

Os padrões no lado do cliente podem resolver muita coisa, mas a demanda em regime estável acabará superando-os. Quando isso acontecer, é hora de fazer mudanças que ajudem tanto no custo quanto no esforço. 

Cada uma das etapas a seguir oferece capacidade adicional.

Comece migrando de HTTP para WebSockets no tráfego interativo. Se seus agentes ou casos de uso ao vivo usam HTTP, migrar para WebSocket muda a contabilização para que apenas a geração ativa conte. Para cargas de trabalho conversacionais, isso geralmente multiplica a capacidade efetiva sem mudar seu plano, pois o tempo ocioso da conversa deixa de consumir vagas.

Se seus picos são irregulares, mas sua carga média cabe no orçamento, um bucket de tokens ou de vazamento junto a um pool limitado transforma os picos em uma carga mais próxima da média.

Depois, escolha o modelo certo. Uma geração mais rápida ocupa cada vaga por menos tempo, aumentando o número de transmissões que um limite fixo de simultaneidade pode sustentar. Eleven Flash v2.5 é a opção de menor latência para trabalho em tempo real; combiná-lo com uma Clonagem Instantânea de Voz ou uma voz padrão evita a sobrecarga por geração das Clonagens Profissionais de Voz.

Só depois disso você deve fazer upgrade do plano. Quando sua demanda em regime estável realmente exceder o orçamento, mesmo com o cliente bem configurado, um plano mais alto aumenta tanto o limite de simultaneidade por modelo quanto a prioridade da sua fila. Compare os níveis na página de preços da API.

Se precisar de limites além dos publicados, os planos Enterprise oferecem limites de simultaneidade maiores e personalizados, além da maior prioridade na fila. Há controles adicionais disponíveis para casos de uso elegíveis, como lista de permissões de IPs (em prévia para Enterprise) e modos sem retenção. Entre em contato com seu gerente de conta para aumentar os limites.

Recapitulando o que considerar sobre a limitação de taxa de IA 

O erro central é tratar a limitação de taxa de IA para voz como uma contagem de solicitações. Tudo aqui diz respeito ao controle de simultaneidade. O número que determina seu sucesso é quantas solicitações estão gerando áudio no mesmo instante e por quanto tempo cada uma ocupa sua vaga.

Estruture o cliente em torno desse fato. 

Limite as solicitações em andamento com um pool limitado, controle a admissão com um bucket de tokens ou de vazamento, tente novamente com backoff exponencial limitado e jitter total, respeite Retry-After e interrompa o circuito antes que se forme uma tempestade de tentativas. 

Para sistemas multilocatários, acrescente buckets por locatário, equidade ponderada, capacidade reservada e divisão para isolamento. Acompanhe os cabeçalhos current-concurrent-requests e maximum-concurrent-requests e crie alertas com base na tendência de utilização, não nas falhas. 

Quando você realmente precisar de mais capacidade, siga a lista nesta ordem: WebSockets e melhor comportamento do cliente primeiro, depois o modelo certo, em seguida um upgrade de plano e, por fim, os limites Enterprise.

Crie aplicativos de voz com a ElevenAPI

A limitação de taxa de IA em nível de produção começa com o transporte certo, o modelo certo e cabeçalhos que mostram exatamente sua situação.

A ElevenAPI oferece modelos de baixa latência, como o Eleven Flash v2.5, streaming WebSocket em tempo real, Speech to Text e APIs de Text to Speech, além de cabeçalhos de simultaneidade em cada resposta que permitem criar agentes de voz que escalam dentro dos seus limites. 

Combinadas às estratégias de limitação de taxa de IA deste artigo, elas permitem oferecer experiências de voz responsivas e manter um desempenho previsível, mesmo sob carga. 

Explore a ElevenAPI para ver toda a linha de modelos em ação ou crie uma conta para começar a criar com a ElevenLabs hoje.

Perguntas frequentes sobre limitação de taxa de IA