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

La maggior parte dei team affronta il rate limiting dell'IA per la voce come farebbe con altre API: limita le richieste al minuto, riprova quando il server risponde negativamente e va avanti. Per i carichi di lavoro su ElevenLabs, questo approccio fallisce al primo picco di traffico, perché il limite che stai effettivamente raggiungendo è la concorrenza, non il numero di richieste.

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

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

In sintesi

• Il rate limiting dell'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é solo la generazione attiva conta ai fini del limite.
• I sistemi multi-tenant richiedono un ulteriore livello di equità: bucket per tenant, accodamento equo ponderato, capacità di riserva 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 dell'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 sul server cresce con il numero di utenti concorrenti. 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 sono occupati in questo momento, che è l'unica metrica considerata 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 sono in genere più brevi 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, utilizzi contemporaneamente due budget separati. I valori attuali 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 degrada gradualmente attraverso una coda prioritaria e passa al rifiuto completo solo quando 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 la capacità dopo l'accodamento, ricevi un HTTP 429. È il segnale che devi rallentare anziché riprovare subito. Il livello di priorità nella tabella determina l'ordine delle richieste in coda rispetto agli altri flussi di traffico; i piani superiori svuotano la coda più rapidamente.

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 avvenga su HTTP o su WebSocket.

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

Per un agente vocale, una conversazione ha lunghi periodi 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 giusta.

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 viene occupato attivamente solo mentre viene generato l'audio. Questo divario consente a un budget ridotto di servire un vasto pubblico.

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

Come regola pratica, un limite di concorrenza pari a 5 può supportare circa 100 trasmissioni audio simultanee. Il numero esatto dipende dalla voce, dalla cadenza del parlato e dalla quantità di silenzio tra un'enunciazione e l'altra.

Gli header che indicano la tua situazione

Non devi dedurre la tua posizione rispetto al limite. Ogni risposta contiene due valori che puoi usare per misurare la capacità disponibile invece di limitarti a stimarla.

Tieni d'occhio 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 offrono una panoramica in tempo reale del tuo utilizzo attuale e della capacità disponibile. Non dovresti dover fare supposizioni prima di raggiungere i limiti di rate dell'IA.

Strategie lato client per il rate limiting dell'IA

Esistono quattro elementi fondamentali che coprono quasi ogni scenario di rate limiting dell'IA:

• Un token bucket: se sono disponibili token, consente alle richieste di procedere. La capacità si ripristina nel tempo, permettendo di gestire brevi picchi senza raggiungere i limiti di rate.
• Un leaky bucket: cerca di uniformare il traffico in ingresso a una velocità di output fissa, impedendo che picchi improvvisi sovraccarichino i sistemi downstream.
• Un pool di concorrenza limitata: limita il numero totale di richieste attive contemporaneamente, così non superi mai i limiti di richieste concorrenti.
• Backoff esponenziale con full jitter: aumenta progressivamente l'intervallo tra le richieste non riuscite, evitando che tutti i client riprovino contemporaneamente.

Le sezioni seguenti mostrano come implementarli 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: l'elemento che corrisponde al limite

Poiché il server misura la concorrenza, il controllo lato client più diretto è un pool di worker limitato che impone un tetto al numero di richieste in corso contemporaneamente. Imposta il tetto leggermente sotto il limite del tuo piano, per lasciare margine 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 i 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 velocità nel lungo periodo. 

È lo strumento giusto per rendere più graduale il momento in cui arriva improvvisamente una coda di lavoro, così non avvii 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: imponi un deflusso costante

In alcuni casi non vuoi tollerare alcun picco. Un leaky bucket ammette lavoro a una velocità fissa e costante, indipendentemente da quanto sia intermittente 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));
  }
}

Backoff esponenziale con full jitter

Quando una richiesta non riesce con uno stato ripetibile, riprovare subito peggiora la situazione. Il backoff distanzia i tentativi e il full jitter rende casuale ogni ritardo nell'intero intervallo, impedendo a molti client di riprovare in sincronia e ricreare 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 qualsiasi valore Retry-After. È definita nella sezione sulla gestione corretta dei 429 qui sotto.

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 corretta dei 429: cosa fare quando raggiungi il limite

Un 429 significa che eri oltre la capacità anche dopo la coda prioritaria, quindi la risposta corretta è rallentare anziché riprovare con più insistenza. Ci sono quattro modi per gestirlo. Per farlo bene, servono quattro strategie:

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

Vediamole più nel dettaglio.

Il primo è il rilevamento. Considera HTTP 429 (e i 500, 502, 503 e 504 transitori) come ripetibili, e considera 400, 401, 403 e 422 come non ripetibili; riprovare una richiesta malformata o non autorizzata non avrà mai successo e sprecherà soltanto uno slot.

Il secondo è rispettare Retry-After. Se la risposta contiene questo header, rispettalo esattamente invece di calcolare un ritardo autonomamente. Il server ti indica 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 essere visibili. Se la profondità della coda o la capacità disponibile misurata indica che non puoi servire presto una nuova richiesta, rifiutala al margine con un segnale chiaro 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 interrompi rapidamente le richieste per una finestra di raffreddamento, invece di inviare richieste che prevedi falliranno. Dopo la finestra, invia alcune richieste di prova; se hanno successo, 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 quota multi-tenant per il rate limiting dell'IA

Finora tutto presuppone una singola applicazione con un singolo budget. Quando crei un SaaS basato su ElevenLabs, il problema cambia forma: il tuo budget di concorrenza è condiviso tra tutti i tuoi clienti e un tenant che esegue un batch job 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 ogni tenant il proprio bucket, dimensionato in base ai suoi diritti, 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 impediscono a un singolo tenant di eccedere, ma non decidono chi prevale quando i tenant competono per il limitatore globale. A questo scopo, usa l'accodamento equo ponderato. 

Non servire le richieste in ordine di arrivo, perché un picco di un tenant potrebbe monopolizzare gli slot. Mantieni una coda per tenant e invia le richieste in proporzione al peso di ciascun tenant, così un tenant pagante riceve una quota maggiore della capacità contesa rispetto a uno gratuito.

Oltre all'equità, riserva capacità. Non lasciare mai che il traffico normale consumi il 100% del limite di concorrenza. Conserva una frazione, 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ù, usa lo sharding tra workspace o chiavi. Un singolo budget di concorrenza diventa prima o poi il collo di bottiglia, indipendentemente da quanto equamente lo suddividi. 

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

I workspace ti consentono 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 una capacità disponibile che non misuri. Registra current-concurrent-requests e maximum-concurrent-requests in ogni risposta, etichettati per famiglia di modelli, ed esporta 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 il TTFA.

Un sistema sano mantiene l'utilizzo comodamente sotto la saturazione e rileva 429 solo durante picchi occasionali. Monitorando questi segnali, hai visibilità sulla pressione del rate limiting molto prima che diventi un problema di indisponibilità.

Quando scalare oltre il rate limiting lato client

I pattern lato client possono fare molto lavoro, 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 usano HTTP, il passaggio a un WebSocket modifica il calcolo affinché conti solo la generazione attiva. Per i carichi conversazionali, questo spesso moltiplica la capacità effettiva senza cambiare piano, perché il tempo di conversazione inattiva smette di consumare slot.

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

Poi scegli il modello giusto. Una generazione più rapida 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'Instant Voice Clone o a una voce predefinita evita l'overhead per generazione delle Professional Voice Clones.

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

Se ti servono limiti superiori a quelli pubblicati, i piani Enterprise offrono limiti di concorrenza elevati e personalizzati, oltre alla massima priorità nella coda. Per casi d'uso idonei sono disponibili controlli aggiuntivi, come l'inserimento degli 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 dell'IA 

L'errore principale è trattare il rate limiting dell'IA vocale come un conteggio di richieste. Qui si tratta interamente 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 intorno a questo fatto. 

Limita le richieste in corso con un pool limitato, regola l'ammissione con un token o leaky bucket, riprova con backoff esponenziale 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, capacità riservata e sharding per l'isolamento. Monitora gli header current-concurrent-requests e maximum-concurrent-requests e imposta avvisi sulla tendenza di utilizzo, non sugli errori. 

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

Crea applicazioni vocali con ElevenAPI

Il rate limiting dell'IA di livello production inizia con il trasporto giusto, il modello giusto e 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, nonché header di concorrenza per risposta che ti consentono di creare agenti vocali in grado di scalare entro i tuoi limiti. 

Insieme alle strategie di rate limiting dell'IA descritte in questo articolo, ti permettono 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 a sviluppare con ElevenLabs oggi.

FAQ sul rate limiting dell'IA