Rate limiting IA per la voce: concorrenza, code e 429

La maggior parte dei team gestisce il rate limiting IA per la voce come per le altre API: limita le richieste al minuto, ritenta quando il server risponde negativamente e passa oltre. Con i carichi di lavoro su ElevenLabs, questo approccio non regge al primo picco di traffico, perché il limite che raggiungi davvero è la concorrenza, non il numero di richieste.

Questa guida spiega perché la concorrenza è il vero vincolo e illustra i pattern lato client per restare entro il limite. Dai pool a concorrenza limitata alla gestione efficace dei 429, fino all'equità multi-tenant e ai token e leaky bucket, proponiamo sistemi pratici che puoi implementare. Abbiamo affiancato a ogni pattern un'implementazione TypeScript funzionante che puoi adattare.

Se sviluppi agenti vocali, pipeline di narrazione o qualsiasi altro sistema di produzione basato sui nostri modelli e vuoi scalarlo, questa guida fa per te.

In sintesi

• Il rate limiting IA per la voce riguarda il controllo della concorrenza, non il conteggio delle richieste al minuto.
• Raggiungere il limite di rate limiting non rifiuta subito il traffico. Le richieste entrano invece in una coda prioritaria che aggiunge circa 50 ms.
• Superare la capacità anche dopo l'accodamento genera un errore HTTP 429.
• I WebSocket aumentano notevolmente la capacità effettiva, poiché conta solo la generazione attiva ai fini del limite.
• I sistemi multi-tenant richiedono un ulteriore livello di equità: bucket per tenant, weighted fair queuing, headroom riservato e sharding tra chiavi per l'isolamento.
• Due header di risposta, current-concurrent-requests e maximum-concurrent-requests, ti indicano la tua situazione rispetto al rate limiting IA.

Perché il limite è la concorrenza, non le richieste al minuto

La concorrenza è il numero di richieste in corso nello stesso momento. Le richieste al minuto sono il throughput in un intervallo di tempo. Capire questa distinzione è importante perché cambia quale leva ti permette di restare entro il limite.

Quando usi uno dei modelli di ElevenLabs, il carico del server aumenta in base al numero di utenti simultanei. La generazione audio occupa uno slot per tutta la sua durata, che varia in base alla lunghezza dell'input, al modello e al carico.

Un limite di richieste al minuto non dice nulla su quanti slot siano occupati in questo momento, che è l'unico dato misurato dal server.

Limiti per piano e famiglia di modelli

Il tuo budget di concorrenza non è un unico numero. I limiti di concorrenza variano in base al piano e alla famiglia di modelli. Ad esempio, Speech to Text ha un limite più elevato rispetto a Text to Speech, perché le richieste di trascrizione durano in genere meno e il sistema può gestirne di più contemporaneamente.

Il limite è per famiglia di modelli. Se usi Flash per gli agenti e Multilingual v2 per la narrazione, lavori contemporaneamente con due budget separati. I valori aggiornati per piano e la sezione sulla concorrenza sono documentati nella pagina dei modelli.

Cosa succede quando raggiungi il limite di concorrenza?

Raggiungere il limite di concorrenza non rifiuta subito il traffico. Il sistema gestisce il degrado in modo graduale tramite una coda prioritaria e passa al rifiuto completo solo se superi ancora la capacità totale del rate limit.

Finché resti sotto il limite, le richieste vengono eseguite subito. Quando lo raggiungi, le richieste successive entrano in una coda ordinata in base al livello di priorità del tuo piano. La coda aggiunge in genere circa 50 ms di latenza, quindi un breve superamento è perlopiù invisibile agli utenti.

Se il sistema resta oltre capacità dopo l'accodamento, ricevi un HTTP 429. È il segnale per rallentare anziché ritentare subito. Il livello di priorità nella tabella determina l'ordine delle tue richieste in coda rispetto ad altro traffico; i piani superiori svuotano prima la coda.

HTTP e WebSocket: come incidono sul tuo limite

Il trasporto che scegli influenza direttamente il rate limiting e il budget. La stessa conversazione in ingresso può consumare quantità molto diverse del tuo budget di concorrenza, a seconda che usi HTTP o un WebSocket.

Con HTTP, ogni richiesta conta singolarmente ai fini del limite di concorrenza per tutta la sua durata. Con un WebSocket conta solo il tempo in cui il modello genera attivamente audio. Un WebSocket aperto ma inattivo generalmente non conta.

Per un agente vocale, una conversazione ha lunghi momenti in cui nessuno parla e il modello non genera nulla. Con HTTP terresti occupato uno slot per la durata della richiesta a ogni turno. Con un WebSocket lo slot viene consumato solo durante i millisecondi di generazione attiva, quindi uno slot di concorrenza viene condiviso nel tempo tra molte conversazioni.

Consulta la guida al WebSocket TTS in tempo reale per i dettagli del protocollo. Per il traffico interattivo, i WebSocket sono la scelta predefinita ideale.

Perché ~5 richieste concorrenti possono supportare ~100 trasmissioni

La matematica della concorrenza è controintuitiva finché non consideri il tempo di riproduzione. La generazione è molto più rapida della riproduzione e uno slot è occupato attivamente solo mentre viene generato l'audio. È proprio questo divario che permette a un piccolo budget di servire un vasto pubblico.

Una richiesta che richiede una frazione di secondo per generare produce diversi secondi di audio che l'ascoltatore riproduce; durante la riproduzione, lo slot viene rilasciato e reso disponibile ad altri ascoltatori.

Come regola pratica, un limite di concorrenza di 5 può supportare circa 100 trasmissioni audio simultanee. Il numero esatto dipende dalla voce, dal ritmo del parlato e dalla quantità di silenzio tra un enunciato e l'altro.

Gli header che indicano la tua situazione

Non devi dedurre la tua posizione rispetto al limite. Ogni risposta include due numeri che puoi usare per misurare l'headroom invece di limitarti a fare stime.

Cerca questi due header:

• current-concurrent-requests: quante richieste sono attualmente in corso?
• maximum-concurrent-requests: il tuo limite per quella famiglia di modelli.

Insieme, questi header forniscono una panoramica in tempo reale dell'utilizzo corrente e della capacità disponibile. Non dovresti dover fare supposizioni prima di raggiungere i limiti IA.

Strategie lato client per il rate limiting IA

Esistono quattro primitive che coprono quasi ogni scenario di rate limiting IA:

• Un token bucket: se sono disponibili token, consente alle richieste di procedere. La capacità viene ripristinata nel tempo, consentendo di gestire brevi picchi senza raggiungere i limiti.
• Un leaky bucket: cerca di uniformare il traffico in ingresso a una frequenza di output fissa, evitando che picchi improvvisi sovraccarichino i sistemi downstream.
• Un pool a concorrenza limitata: limita il numero totale di richieste attive contemporaneamente, così non superi mai i limiti di richieste concorrenti.
• Exponential backoff con full jitter: aumenta progressivamente l'intervallo tra richieste non riuscite per evitare che tutti i client ritentino insieme.

Le sezioni seguenti mostrano come costruirli uno alla volta, iniziando da quello che corrisponde più direttamente al limite di concorrenza.

Tutti gli snippet seguenti presuppongono un singolo client, inizializzato una sola volta:

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

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

Concorrenza limitata: la primitiva che corrisponde al limite

Poiché il server misura la concorrenza, il controllo lato client più diretto è un pool di worker limitato che imposta un massimo di richieste in corso contemporaneamente. Imposta il limite leggermente al di sotto di quello del piano, per lasciare spazio alla coda prioritaria e 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: consenti picchi, limita la media

Un token bucket contiene fino a capacity token e si ricarica di refillRate token al secondo. Ogni richiesta consuma un token, quindi il bucket consente brevi picchi fino alla sua dimensione, limitando al contempo la frequenza nel lungo periodo.

È lo strumento giusto per gestire il momento in cui arriva improvvisamente una coda di lavoro, così non invii tutto insieme causando un picco di concorrenza.

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: applica un deflusso costante

In alcuni casi non vuoi tollerare alcun picco. Un leaky bucket ammette lavoro a una frequenza fissa e costante, indipendentemente da quanto sia variabile l'input. È la scelta migliore quando il sistema downstream preferisce un carico uniforme e prevedibile a picchi occasionali.

Ad esempio, quando vuoi restare deliberatamente ben entro un piccolo budget di concorrenza condiviso con altri servizi.

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

Exponential backoff con full jitter

Quando una richiesta fallisce con uno stato ritentabile, ritentare subito peggiora la situazione. Il backoff distanzia i tentativi e il full jitter casualizza ogni ritardo sull'intero intervallo, evitando che molti client ritentino in sincrono e ricreino lo stesso picco che ha causato l'errore.

Lo snippet seguente fa riferimento a RetryableError, una piccola classe che contiene lo stato non riuscito e l'eventuale valore Retry-After. È definita nella sezione seguente sulla gestione efficace dei 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));
    }
  }
}

Gestione efficace dei 429: cosa fare quando raggiungi il limite

Un 429 indica che eri oltre capacità anche dopo la coda prioritaria, quindi la risposta corretta è rallentare anziché ritentare con maggiore intensità. Puoi gestirlo in quattro modi. Una buona gestione si basa su quattro strategie:

• Rilevamento
• Rispetto di Retry-After
• Segnalazione della backpressure
• Evitare tempeste di retry con un circuit breaker

Vediamole più nel dettaglio.

La prima è il rilevamento. Tratta HTTP 429 (e gli errori temporanei 500, 502, 503 e 504) come ritentabili, mentre 400, 401, 403 e 422 come non ritentabili; ritentare una richiesta non valida o non autorizzata non avrà mai successo e spreca soltanto uno slot.

La seconda è il rispetto di Retry-After. Se la risposta include questo header, rispettalo esattamente invece di calcolare un ritardo personalizzato. Il server ti comunica quando prevede di avere capacità e lo sa meglio della tua formula esponenziale. Ricorri al backoff con jitter solo quando l'header è assente.

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

Il terzo aspetto è segnalare la backpressure. Non lasciare che i retry si accumulino senza visibilità. Se la profondità della coda o l'headroom misurato indicano che non puoi servire presto una nuova richiesta, rifiutala al margine con un chiaro segnale al chiamante anziché accettare lavoro che non puoi svolgere.

Il quarto è evitare tempeste di retry con un circuit breaker. Se gli errori superano una soglia, apri il circuito e fallisci rapidamente per una finestra di raffreddamento anziché inviare richieste che prevedi falliranno. Dopo questa finestra, invia alcune richieste di verifica; se riescono, chiudi il 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();
    }
  }
}

Pattern di quote multi-tenant per il rate limiting IA

Finora abbiamo considerato una singola applicazione con un unico budget. Quando sviluppi un SaaS su ElevenLabs, il problema cambia: il budget di concorrenza è condiviso tra tutti i tuoi clienti e un tenant che esegue un job batch non dovrebbe privare del traffico live tutti gli altri tenant. Ti serve un livello di equità tra i tenant e l'unico limite upstream.

La base sono i token bucket per tenant. Assegna a ciascun tenant un bucket dimensionato in base alla sua quota e ammetti una richiesta solo quando lo consentono sia il bucket del tenant sia un limitatore globale.

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

I bucket mantengono sotto controllo ogni singolo tenant, ma non decidono chi prevale quando i tenant competono per il limitatore globale. Per questo, usa il weighted fair queuing.

Non usare il criterio first-come-first-served, che permette a un picco di un tenant di monopolizzare gli slot. Mantieni una coda per tenant e distribuisci in proporzione al peso di ciascuno, così un tenant a pagamento riceve una quota maggiore della capacità contesa rispetto a uno gratuito.

Oltre all'equità, riserva headroom. Non lasciare mai che il traffico normale consumi il 100% del limite di concorrenza. Tieni da parte una quota, ad esempio il 15-20%, come buffer per le richieste interattive sensibili alla latenza e per la coda prioritaria.

Quando l'equità all'interno di un singolo budget non basta più, fai sharding tra workspace o chiavi. Un singolo budget di concorrenza finisce inevitabilmente per diventare il collo di bottiglia, indipendentemente da quanto equamente lo distribuisci.

A quel punto, separa i carichi di lavoro in workspace distinti o chiavi API con budget propri: ad esempio, una chiave per il traffico degli agenti in tempo reale e un'altra per la narrazione in background, così l'arretrato della narrazione non può intaccare la capacità degli agenti.

I workspace ti permettono inoltre di applicare restrizioni di scope, quote di crediti e controlli per chiave, descritti nella documentazione sull'autenticazione.

Monitorare l'utilizzo della concorrenza

Niente di tutto questo è regolabile senza misurazioni: non puoi gestire l'headroom che non misuri. Registra current-concurrent-requests e maximum-concurrent-requests in ogni risposta, con tag per famiglia di modelli, ed esponi il rapporto di utilizzo come gauge.

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

Quattro segnali da monitorare:

• Utilizzo (corrente / massimo).
• Tasso di 429 come frazione delle richieste totali.
• Profondità dei retry, ovvero il numero di tentativi per richiesta logica.
• Tempo al primo audio, misurato dalla tua applicazione, non dai dati di inferenza del modello. Consulta la guida sulla latenza per sapere cosa include TTFA.

Un sistema sano mantiene l'utilizzo comodamente sotto la saturazione e registra 429 solo in picchi occasionali. Monitorare questi segnali ti dà visibilità sulla pressione del rate limiting molto prima che diventi un problema di interruzione del servizio.

Quando scalare oltre il rate limiting lato client

I pattern lato client possono fare molto, ma la domanda costante finirà per superarli. Quando accade, è il momento di apportare modifiche che riducono sia i costi sia l'impegno.

Ciascuno dei passaggi seguenti ti offre capacità aggiuntiva.

Inizia passando da HTTP ai WebSocket per il traffico interattivo. Se i tuoi agenti o casi d'uso live funzionano su HTTP, il passaggio a un WebSocket cambia il conteggio affinché conti solo la generazione attiva. Per i carichi conversazionali, questo spesso moltiplica la capacità effettiva senza cambiare piano, perché il tempo di conversazione inattivo smette di consumare slot.

Se i tuoi picchi sono irregolari ma il carico medio rientra nel budget, un token o leaky bucket insieme a un pool limitato appiattisce i picchi sulla media.

Poi scegli il modello giusto. Una generazione più veloce occupa ogni slot per meno tempo, aumentando il numero di trasmissioni che un limite di concorrenza fisso può sostenere. Eleven Flash v2.5 è l'opzione a latenza più bassa per il lavoro in tempo reale; abbinarlo a un Clonazione Vocale Istantanea o a una voce predefinita evita l'overhead per generazione delle Professional Voice Clone.

Solo dopo dovresti effettuare l'upgrade del piano. Quando la domanda costante supera davvero il budget dopo che il client è ben configurato, un piano superiore aumenta sia il limite di concorrenza per modello sia la priorità della coda. Confronta i piani nella pagina dei prezzi API.

Se ti servono limiti superiori a quelli pubblicati, i piani Enterprise offrono limiti di concorrenza più elevati e personalizzati, oltre alla massima priorità in coda. Per casi d'uso idonei sono disponibili controlli aggiuntivi, come l'inserimento di IP in whitelist (in anteprima Enterprise) e modalità senza conservazione dei dati. Contatta il tuo account manager per aumentare i limiti.

Riepilogo: cosa ricordare sul rate limiting IA

L'errore fondamentale è trattare il rate limiting IA per la voce come un conteggio delle richieste. Qui si parla di controllo della concorrenza. Il numero che determina il successo è quante richieste generano audio nello stesso istante e per quanto tempo ciascuna occupa il proprio slot.

Progetta il client attorno a questo fatto.

Limita le richieste in corso con un pool limitato, regola l'ammissione con un token o leaky bucket, ritenta con exponential backoff limitato e full jitter, rispetta Retry-After e interrompi il circuito prima che si formi una tempesta di retry.

Per i sistemi multi-tenant, aggiungi bucket per tenant, equità ponderata, headroom riservato e sharding per l'isolamento. Controlla gli header current-concurrent-requests e maximum-concurrent-requests e crea avvisi in base alla tendenza dell'utilizzo, non agli errori.

Quando hai davvero bisogno di più capacità, segui l'ordine: prima WebSocket e un comportamento migliore del client, poi il modello giusto, quindi l'upgrade del piano e infine i limiti Enterprise.

Crea applicazioni vocali con ElevenAPI

Un rate limiting IA pronto per la produzione inizia dal trasporto giusto, dal modello giusto e da header che ti indicano esattamente la tua situazione.

ElevenAPI offre modelli a bassa latenza come Eleven Flash v2.5, streaming WebSocket in tempo reale, Speech to Text e API Text to Speech, oltre a header di concorrenza per risposta che ti permettono di creare agenti vocali scalabili entro i tuoi limiti.

Insieme alle strategie di rate limiting IA di questo articolo, ti consentono di offrire esperienze vocali reattive mantenendo prestazioni prevedibili, anche sotto carico.

Esplora ElevenAPI per vedere in azione l'intera gamma di modelli, oppure crea un account per iniziare oggi a sviluppare con ElevenLabs.

FAQ sul rate limiting IA