AI-rate limiting voor spraak: concurrency, wachtrijen en 429s

De meeste teams pakken AI-rate limiting voor spraak op dezelfde manier aan als andere API's: ze begrenzen requests per minuut, proberen het opnieuw wanneer de server weerstand biedt en gaan verder. Voor workloads op ElevenLabs werkt dat model niet meer bij de eerste verkeerspiek, omdat de limiet die je daadwerkelijk bereikt concurrency is, niet het aantal requests.

Deze gids legt uit waarom concurrency de echte beperking is en behandelt vervolgens de patronen aan de clientzijde waarmee je binnen die limiet blijft. Van begrensde concurrency pools en zorgvuldige afhandeling van 429-fouten tot eerlijkheid voor meerdere tenants en token- en leaky buckets: we bieden praktische systemen die je kunt implementeren. We hebben elk patroon gekoppeld aan een werkende TypeScript-implementatie die je kunt aanpassen.

Als je spraakagents bouwt, narratiepipelines of andere productiesystemen op basis van onze modellen bouwt en wilt opschalen, dan is dit draaiboek voor jou.

Samenvatting

• AI-rate limiting voor spraak is concurrencybeheer, geen telling van requests per minuut.
• Het bereiken van de rate-limitinggrens leidt niet direct tot afgewezen verkeer. In plaats daarvan komen requests in een prioriteitswachtrij terecht, die ongeveer 50 ms toevoegt.
• Als je zelfs na het in de wachtrij plaatsen boven de capaciteit uitkomt, ontstaat er een HTTP 429-fout.
• WebSockets vergroten de effectieve capaciteit aanzienlijk, omdat alleen actieve generatie meetelt voor je limiet.
• Systemen met meerdere tenants hebben een extra laag voor eerlijkheid nodig: buckets per tenant, gewogen eerlijke wachtrijverdeling, gereserveerde headroom en sharding over sleutels voor isolatie. 
• Twee responseheaders, current-concurrent-requests en maximum-concurrent-requests, laten je zien hoe je ervoor staat met AI-rate limiting.

Waarom de limiet concurrency is, niet requests per minuut

Concurrency is het aantal requests dat op hetzelfde moment in behandeling is. Requests per minuut is de doorvoer binnen een tijdvenster. Dit onderscheid begrijpen is belangrijk, omdat het bepaalt welke knop je kunt gebruiken om binnen je limiet te blijven.

Bij het gebruik van een van de ElevenLabs-modellen schaalt de serverbelasting mee met het aantal gelijktijdige gebruikers. Audiogeneratie houdt gedurende de generatieduur een slot bezet, en die duur varieert met de invoerlengte, het model en de belasting.

Een limiet voor requests per minuut vertelt je niets over hoeveel slots er nu bezet zijn, terwijl dat het enige is wat de server meet.

De limieten per abonnement en modelfamilie

Je concurrencybudget is niet één enkel getal. Concurrencylimieten verschillen per abonnement en per modelfamilie. Zo heeft Speech to Text een hogere limiet dan Text to Speech, omdat transcriptierequests doorgaans korter duren en het systeem er meer tegelijk kan verwerken.

De limiet geldt per modelfamilie. Als je Flash voor agents gebruikt en Multilingual v2 voor narratie, werk je tegelijk met twee afzonderlijke budgetten. De huidige cijfers per abonnement en het onderdeel over concurrency staan op de modellenpagina.

Wat gebeurt er wanneer je de concurrencylimiet bereikt?

Het bereiken van de concurrencylimiet leidt niet direct tot afgewezen verkeer. Het systeem schaalt soepel terug via een prioriteitswachtrij en wijst verkeer pas volledig af als je nog steeds boven de totale capaciteit van de ratelimiet zit.

Zolang je onder je limiet blijft, worden requests direct uitgevoerd. Wanneer je die bereikt, komen volgende requests in een wachtrij die is geordend op het prioriteitsniveau van je abonnement. De wachtrij voegt doorgaans ongeveer 50 ms vertraging toe, dus een korte overschrijding is voor gebruikers meestal niet merkbaar.

Als het systeem na plaatsing in de wachtrij nog steeds boven de capaciteit zit, ontvang je een HTTP 429. Dat is het signaal om te vertragen in plaats van meteen opnieuw te proberen. Het prioriteitsniveau in de tabel bepaalt hoe je requests in de wachtrij ten opzichte van ander verkeer worden geordend; hogere abonnementen doorlopen de wachtrij sneller.

HTTP versus WebSocket: hoe beide meetellen voor je limiet

Het transport dat je kiest, heeft directe invloed op rate limiting en je budget. Dezelfde binnenkomende conversatie kan aanzienlijk verschillende delen van je concurrencybudget verbruiken, afhankelijk van of die via HTTP of een WebSocket loopt.

Via HTTP telt elke request afzonderlijk mee voor je concurrencylimiet, gedurende de volledige looptijd. Via een WebSocket telt alleen de tijd waarin het model actief audio genereert. Een open maar inactieve WebSocket telt meestal niet mee.

Voor een spraakagent bevat een gesprek lange periodes waarin niemand spreekt en het model niets genereert. Met HTTP zou je bij elke beurt een slot bezet houden gedurende de looptijd van de request. Met een WebSocket wordt het slot alleen verbruikt tijdens de milliseconden van actieve generatie, zodat één concurrencyslot wordt gedeeld door meerdere gesprekken. 

Bekijk de gids voor realtime TTS via WebSocket voor de protocoldetails. Voor interactief verkeer zijn WebSockets de juiste standaardkeuze.

Waarom ~5 concurrency ~100 uitzendingen kan ondersteunen

De berekening achter concurrency is niet intuïtief totdat je rekening houdt met de afspeeltijd. Generatie is veel sneller dan afspelen, en een slot is alleen actief bezet terwijl audio wordt gegenereerd. Door dat verschil kan een klein budget een groot publiek bedienen.

Een request die een fractie van een seconde nodig heeft om te genereren, produceert enkele seconden audio die de luisteraar vervolgens afspeelt. Tijdens dat afspelen komt het slot vrij en is het beschikbaar voor andere luisteraars.

Als vuistregel kan een concurrencylimiet van 5 ongeveer 100 gelijktijdige audio-uitzendingen ondersteunen. Het exacte aantal hangt af van de stem, het spreektempo en hoeveel stilte er tussen uitingen zit.

De headers die laten zien hoe je ervoor staat

Je hoeft je positie ten opzichte van je limiet niet af te leiden. Elke response bevat twee getallen waarmee je de beschikbare headroom kunt meten in plaats van alleen te schatten.

Let op deze twee headers:

• current-concurrent-requests: hoeveel requests zijn er nu in behandeling?
• maximum-concurrent-requests: je limiet voor die modelfamilie.

Samen bieden deze headers een realtime overzicht van je huidige gebruik en beschikbare capaciteit. Je hoeft niet te gokken voordat je AI-ratelimieten tegenkomt.

Strategieën aan de clientzijde voor AI-rate limiting

Er zijn vier basisprincipes die bijna elk scenario voor AI-rate limiting dekken:

• Een token bucket: als er tokens beschikbaar zijn, kunnen requests doorgaan. De capaciteit wordt na verloop van tijd aangevuld, waardoor korte pieken kunnen worden opgevangen zonder ratelimieten te bereiken.
• Een leaky bucket: probeert binnenkomend verkeer af te vlakken tot een vaste uitvoersnelheid, waardoor plotselinge pieken je downstreamsystemen niet overbelasten.
• Een begrensde concurrency pool: begrenst het totale aantal requests dat tegelijk actief kan zijn, zodat je nooit de limieten voor gelijktijdige requests overschrijdt.
• Exponentiële backoff met volledige jitter: vergroot steeds verder de tijd tussen mislukte requests, zodat clients niet allemaal tegelijk opnieuw proberen.

In de onderstaande onderdelen zie je hoe je deze één voor één opbouwt, te beginnen met degene die het meest direct aansluit op de concurrencylimiet.

Alle onderstaande snippets gaan uit van één client, die één keer wordt geïnitialiseerd:

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

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

Begrensde concurrency: het basisprincipe dat aansluit op de limiet

Omdat de server concurrency meet, is een begrensde worker pool de meest directe clientcontrole: die beperkt hoeveel requests je tegelijk in behandeling hebt. Stel de limiet iets onder die van je abonnement in, zodat er ruimte overblijft voor de prioriteitswachtrij en 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: pieken toelaten, het gemiddelde begrenzen

Een token bucket bevat maximaal capacity tokens en vult zich aan met refillRate tokens per seconde. Elke request verbruikt een token, dus de bucket staat korte pieken tot zijn grootte toe en begrenst tegelijkertijd de snelheid op lange termijn. 

Dit is het juiste hulpmiddel om het moment af te vlakken waarop plotseling een wachtrij met werk binnenkomt, zodat je niet alles tegelijk uitvoert en een concurrencypiek veroorzaakt.

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: een constante uitstroom afdwingen

In sommige gevallen wil je pieken helemaal niet tolereren. Een leaky bucket laat werk toe met een vaste, constante snelheid, ongeacht hoe piekerig de invoer is. Dit is de betere keuze wanneer het downstreamsysteem de voorkeur geeft aan een gelijkmatige, voorspelbare belasting boven incidentele pieken.

Bijvoorbeeld wanneer je bewust ruim binnen een klein concurrencybudget blijft dat je met andere services deelt.

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

Exponentiële backoff met volledige jitter

Wanneer een request mislukt met een status waarvoor je opnieuw kunt proberen, maakt direct opnieuw proberen de situatie erger. Backoff spreidt retries en volledige jitter maakt elke vertraging willekeurig binnen het hele interval. Zo voorkom je dat veel clients synchroon opnieuw proberen en dezelfde piek veroorzaken die de fout veroorzaakte.

De onderstaande snippet verwijst naar RetryableError, een kleine klasse die de mislukte status en een eventuele Retry-After-waarde bevat. Deze wordt hieronder gedefinieerd in het onderdeel over zorgvuldige 429-afhandeling.

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

Zorgvuldige 429-afhandeling: wat je doet wanneer je de limiet bereikt

Een 429 betekent dat je zelfs na de prioriteitswachtrij boven de capaciteit zat. De juiste reactie is dus vertragen in plaats van harder opnieuw proberen. Er zijn vier manieren om hiermee om te gaan. Goede afhandeling komt neer op vier strategieën:

• Detectie
• Retry-After respecteren
• Backpressure zichtbaar maken
• Retriestormen voorkomen met een circuit breaker

Laten we deze nader bekijken.

De eerste is detectie. Behandel HTTP 429 (en tijdelijke 500, 502, 503 en 504) als opnieuw te proberen, en behandel 400, 401, 403 en 422 als niet opnieuw te proberen; een misvormde of niet-geautoriseerde request opnieuw proberen lukt nooit en verspilt alleen een slot.

De tweede is Retry-After respecteren. Als de response deze header bevat, volg die dan exact in plaats van zelf een vertraging te berekenen. De server vertelt je wanneer deze verwacht capaciteit te hebben, en weet dat beter dan je exponentiële formule. Gebruik alleen jittered backoff als de header ontbreekt.

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

De derde dimensie is backpressure zichtbaar maken. Laat retries zich niet onzichtbaar opstapelen. Als de diepte van je wachtrij of de gemeten headroom aangeeft dat je een nieuwe request niet snel kunt verwerken, wijs deze dan aan de rand af met een duidelijk signaal aan de aanroeper, in plaats van werk te accepteren dat je niet kunt uitvoeren.

De vierde is retriestormen voorkomen met een circuit breaker. Als fouten een drempel overschrijden, open je het circuit en faal je snel gedurende een afkoelperiode, in plaats van requests te versturen waarvan je verwacht dat ze falen. Stuur na die periode enkele proefrequests; als die slagen, sluit je het circuit.

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

Quota-patronen voor meerdere tenants bij AI-rate limiting

Alles tot nu toe gaat uit van één applicatie met één budget. Wanneer je een SaaS boven op ElevenLabs bouwt, verandert het probleem: je concurrencybudget wordt gedeeld door al je eigen klanten, en één tenant die een batchtaak uitvoert mag niet al het live verkeer van andere tenants verhinderen. Je hebt een laag voor eerlijkheid nodig tussen je tenants en de ene upstreamlimiet.

De basis bestaat uit token buckets per tenant. Geef elke tenant een eigen bucket die aansluit op zijn of haar rechten, en laat een request alleen toe wanneer zowel de bucket van de tenant als een globale limiter dit toestaan.

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

Buckets zorgen dat elke afzonderlijke tenant zich aan de regels houdt, maar ze bepalen niet wie wint wanneer tenants concurreren om de globale limiter. Gebruik daarvoor gewogen eerlijke wachtrijverdeling. 

Gebruik geen first-come-first-served, want daarmee kan een piek van één tenant alle slots monopoliseren. Houd een wachtrij per tenant bij en verdeel werk naar verhouding van het gewicht van elke tenant, zodat een betalende tenant een groter deel van de betwiste capaciteit krijgt dan een gratis tenant.

Reserveer naast eerlijkheid ook headroom. Laat normaal verkeer nooit 100% van de concurrencylimiet verbruiken. Houd een deel, bijvoorbeeld 15-20%, achter als buffer voor latentiegevoelige interactieve requests en voor de prioriteitswachtrij.

Wanneer eerlijkheid binnen één budget niet meer genoeg is, gebruik je sharding over workspaces of sleutels. Eén concurrencybudget wordt uiteindelijk de bottleneck, hoe eerlijk je het ook verdeelt. 

Scheid workloads dan over afzonderlijke workspaces of API-sleutels met elk een eigen budget: bijvoorbeeld één sleutel voor realtime agentverkeer en een andere voor narratie op de achtergrond, zodat een achterstand in narratie de capaciteit voor agents niet kan raken.

Met workspaces kun je ook scopelimieten, creditquota's en controles per sleutel toepassen, zoals beschreven in de authenticatiedocumentatie.

Je concurrencygebruik monitoren

Niets hiervan kun je afstemmen zonder metingen; je kunt headroom die je niet meet niet beheren. Registreer current-concurrent-requests en maximum-concurrent-requests bij elke response, getagd op modelfamilie, en stuur de bezettingsgraad uit als 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);
  }
}

Vier signalen om bij te houden:

• Bezettingsgraad (huidig / maximum).
• 429-percentage als aandeel van alle requests.
• Retrydiepte, het aantal pogingen per logische request.
• Time-to-first-audio, gemeten vanuit je applicatie en niet op basis van modelinferentiecijfers. Zie latency begrijpen voor wat TTFA omvat.

Een gezond systeem houdt de bezettingsgraad ruim onder verzadiging en ziet 429-fouten alleen bij incidentele pieken. Door deze signalen te monitoren, krijg je inzicht in rate-limitingdruk ruim voordat die tot een storing leidt.

Wanneer je verder moet schalen dan rate limiting aan de clientzijde

Patronen aan de clientzijde kunnen veel werk verzetten, maar de vraag in stabiele toestand groeit er uiteindelijk bovenuit. Wanneer dat gebeurt, is het tijd voor wijzigingen die zowel kosten als inspanning helpen beperken. 

Elk van de volgende stappen geeft je extra capaciteit.

Begin met HTTP voor interactief verkeer te vervangen door WebSockets. Als je agents of live use cases via HTTP draaien, verandert de overstap naar een WebSocket de berekening zodat alleen actieve generatie meetelt. Voor conversatieworkloads vermenigvuldigt dit vaak de effectieve capaciteit zonder je abonnement te wijzigen, omdat inactieve gesprekstijd geen slots meer verbruikt.

Als je pieken grillig zijn maar je gemiddelde belasting binnen het budget past, vlakt een token of leaky bucket samen met een begrensde pool de pieken af naar het gemiddelde.

Kies vervolgens het juiste model. Snellere generatie houdt elk slot minder lang bezet, waardoor een vaste concurrencylimiet meer uitzendingen kan ondersteunen. Eleven Flash v2.5 is de optie met de laagste latentie voor realtimewerk; door dit te combineren met een Instant Voice Clone of een standaardstem vermijd je de overhead per generatie van Professional Voice Clones.

Upgrade pas daarna je abonnement. Wanneer je vraag in stabiele toestand het budget daadwerkelijk overschrijdt nadat de client zich goed gedraagt, verhoogt een hoger abonnement zowel de concurrencylimiet per model als je wachtrijprioriteit. Vergelijk abonnementen op de API-prijzenpagina.

Als je limieten nodig hebt die hoger zijn dan gepubliceerd, bieden Enterprise-abonnementen verhoogde en aangepaste concurrencylimieten en de hoogste wachtrijprioriteit. Voor geschikte use cases zijn aanvullende controles beschikbaar, zoals IP-whitelisting (in Enterprise-preview) en modi zonder gegevensretentie. Neem contact op met je accountmanager om limieten te verhogen.

Samenvatting: wat je moet onthouden over AI-rate limiting 

De kernfout is AI-rate limiting voor spraak behandelen als het tellen van requests. Alles hier draait om concurrencybeheer. Het getal dat bepaalt of je slaagt, is hoeveel requests op hetzelfde moment audio genereren en hoelang elk daarvan een slot bezet houdt.

Bouw de client rond dat gegeven. 

Begrens requests in behandeling met een begrensde pool, regel toelating met een token of leaky bucket, probeer opnieuw met begrensde exponentiële backoff en volledige jitter, respecteer Retry-After en onderbreek het circuit voordat er een retriestorm ontstaat. 

Voeg voor systemen met meerdere tenants buckets per tenant, gewogen eerlijkheid, gereserveerde headroom en sharding voor isolatie toe. Houd de headers current-concurrent-requests en maximum-concurrent-requests in de gaten en waarschuw bij de trend in bezettingsgraad, niet bij de fouten. 

Wanneer je echt meer capaciteit nodig hebt, volg je de lijst in deze volgorde: eerst WebSockets en beter clientgedrag, daarna het juiste model, vervolgens een abonnementsupgrade en ten slotte Enterprise-limieten.

Bouw spraakapplicaties met ElevenAPI

AI-rate limiting van productiekwaliteit begint met het juiste transport, het juiste model en headers die je precies laten zien hoe je ervoor staat.

ElevenAPI biedt modellen met lage latentie zoals Eleven Flash v2.5, realtime WebSocket-streaming, Speech to Text en Text to Speech API's, en concurrencyheaders per response waarmee je spraakagents kunt bouwen die binnen je limieten schalen. 

Gecombineerd met de strategieën voor AI-rate limiting in dit artikel lever je responsieve spraakervaringen met voorspelbare prestaties, zelfs onder belasting. 

Verken ElevenAPI om het volledige modellenaanbod in actie te zien, of maak een account om vandaag te beginnen met bouwen met ElevenLabs.

Veelgestelde vragen over AI-rate limiting