AI-ratebegränsning för röst: Samtidighet, köer och 429:or

De flesta team hanterar AI-rate limiting för röst på samma sätt som andra API:er: begränsar antal förfrågningar per minut, försöker igen när servern säger ifrån och går vidare. För arbetslaster på ElevenLabs fungerar den modellen inte vid den första trafiktoppen, eftersom gränsen du faktiskt når är samtidighet, inte antalet förfrågningar.

Den här guiden förklarar varför samtidighet är den verkliga begränsningen och går sedan igenom klientmönster som hjälper dig att hålla dig inom den. Från begränsade samtidighetspooler och smidig 429-hantering till rättvisa mellan hyresgäster samt token- och läckande hinkar erbjuder vi praktiska system som du kan implementera. Vi har kopplat varje mönster till en fungerande TypeScript-implementation som du kan anpassa.

Om du bygger röstagenter, berättelsepipelines eller andra produktionssystem ovanpå våra modeller och vill skala upp, är den här handboken för dig.

Sammanfattning

• AI-rate limiting för röst handlar om samtidighetskontroll, inte om att räkna förfrågningar per minut.
• När du når gränsen för rate limiting avvisas inte trafiken direkt. I stället hamnar förfrågningar i en prioritetskö som lägger till cirka 50 ms.
• Om kapaciteten överskrids även efter köläggning får du ett HTTP 429-fel.
• WebSockets ökar den effektiva kapaciteten dramatiskt, eftersom endast aktiv generering räknas mot din gräns.
• System med flera hyresgäster behöver ett extra rättviselager: hinkar per hyresgäst, viktad rättvis köläggning, reserverad marginal och uppdelning över nycklar för isolering. 
• Två svarsrubriker, current-concurrent-requests och maximum-concurrent-requests, visar var du står med AI-rate limiting.

Varför gränsen är samtidighet, inte förfrågningar per minut

Samtidighet är antalet pågående förfrågningar vid samma tillfälle. Förfrågningar per minut är genomströmning under ett tidsfönster. Det är viktigt att förstå skillnaden eftersom den avgör vilken åtgärd som håller dig inom gränsen.

När du använder någon av ElevenLabs modeller skalar serverbelastningen med antalet samtidiga användare. Ljudgenerering upptar en plats under hela genereringen, och tiden varierar beroende på inmatningens längd, modell och belastning.

Ett tak för förfrågningar per minut säger inget om hur många platser som är upptagna just nu, vilket är det enda servern mäter.

Gränser per plan och modellfamilj

Din budget för samtidighet är inte en enda siffra. Gränserna skiljer sig mellan planer och modellfamiljer. Till exempel har Speech to Text en högre gräns än Text to Speech, eftersom transkriberingsförfrågningar vanligtvis är kortare och systemet kan hantera fler av dem samtidigt.

Gränsen gäller per modellfamilj. Om du kör Flash för agenter och Multilingual v2 för berättarröst arbetar du mot två separata budgetar samtidigt. Aktuella siffror per plan och avsnittet om samtidighet finns dokumenterade på modellsidan.

Vad händer när du når samtidighetsgränsen?

Att nå samtidighetsgränsen innebär inte att trafiken avvisas direkt. Systemet försämras gradvis via en prioritetskö och övergår till fullständigt avslag först när du fortfarande överskrider den totala kapaciteten för rate limiting.

Så länge du ligger under gränsen körs förfrågningar direkt. När du når den placeras efterföljande förfrågningar i en kö ordnad efter din plans prioritetsnivå. Kön tillför vanligtvis omkring 50 ms latens, så en kort överskridning märks sällan för användarna.

Om systemet fortfarande saknar kapacitet efter köläggning får du ett HTTP 429-fel. Det är signalen att vänta i stället för att försöka igen direkt. Prioritetsnivån i tabellen avgör hur dina köade förfrågningar ordnas i förhållande till annan trafik; högre planer lämnar kön snabbare.

HTTP jämfört med WebSocket: hur de räknas mot din gräns

Det transportprotokoll du väljer påverkar direkt rate limiting och budget. Samma inkommande konversation kan använda avsevärt olika delar av din samtidighetsbudget beroende på om den körs över HTTP eller WebSocket.

Över HTTP räknas varje förfrågan individuellt mot samtidighetsgränsen under hela sin varaktighet. Över en WebSocket räknas bara tiden då modellen aktivt genererar ljud. En öppen men inaktiv WebSocket räknas i stort sett inte.

För en röstagent innehåller en konversation långa perioder då ingen talar och modellen inte genererar något. Med HTTP skulle du uppta en plats under hela förfrågan i varje tur. Med en WebSocket används platsen bara under millisekunderna med aktiv generering, så en samtidighetsplats kan tidsdelas mellan många konversationer. 

Se guiden för WebSocket med TTS i realtid för protokolldetaljer. För interaktiv trafik är WebSockets rätt standardval.

Varför omkring 5 samtidiga förfrågningar kan stödja omkring 100 sändningar

Matematiken bakom samtidighet är kontraintuitiv tills du räknar in uppspelningstiden. Generering går mycket snabbare än uppspelning, och en plats är bara aktivt upptagen när ljud genereras. Det är just den skillnaden som låter en liten budget betjäna en stor publik.

En förfrågan som tar en bråkdel av en sekund att generera kan producera flera sekunders ljud som lyssnaren sedan spelar upp. Under uppspelningen frigörs platsen och blir tillgänglig för andra lyssnare.

Som tumregel kan en samtidighetsgräns på 5 stödja ungefär 100 samtidiga ljudsändningar. Det exakta antalet beror på rösten, taltempot och hur mycket tystnad som finns mellan yttrandena.

Svarsrubrikerna som visar var du står

Du behöver inte gissa var du ligger i förhållande till gränsen. Varje svar innehåller två tal som du kan använda för att mäta marginal i stället för att bara uppskatta.

Håll utkik efter dessa två svarsrubriker:

• current-concurrent-requests: hur många förfrågningar pågår just nu?
• maximum-concurrent-requests: din gräns för den modellfamiljen.

Tillsammans ger dessa svarsrubriker en realtidsöversikt över din aktuella användning och tillgängliga kapacitet. Du ska inte behöva gissa innan du stöter på AI-rate limits.

Klientstrategier för AI-rate limiting

Det finns fyra grundprinciper som täcker nästan alla scenarier för AI-rate limiting:

• En token bucket: Om tokens finns tillgängliga kan förfrågningar fortsätta. Kapaciteten fylls på över tid, vilket gör att den kan hantera korta toppar utan att nå rate limits.
• En leaky bucket: Försöker jämna ut inkommande trafik till en fast utgående takt, vilket förhindrar att plötsliga toppar överbelastar dina efterföljande system.
• En begränsad samtidighetspool: Begränsar det totala antalet förfrågningar som kan vara aktiva samtidigt, så att du aldrig överskrider gränserna för samtidiga förfrågningar.
• Exponentiell backoff med full jitter: Ökar successivt tiden mellan misslyckade förfrågningar för att förhindra att alla klienter försöker igen samtidigt.

Avsnitten nedan visar hur du bygger upp dem en i taget, med början i den som motsvarar samtidighetsgränsen mest direkt.

Alla kodexempel nedan utgår från en enda klient som initieras en gång:

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

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

Begränsad samtidighet: grundprincipen som matchar gränsen

Eftersom servern mäter samtidighet är den mest direkta klientkontrollen en begränsad worker-pool som sätter ett tak för antalet pågående förfrågningar. Sätt taket strax under din plans gräns för att lämna utrymme för prioritetskön och 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: tillåt toppar, begränsa genomsnittet

En token bucket rymmer upp till capacity tokens och fylls på med refillRate tokens per sekund. Varje förfrågan förbrukar en token, så hinken tillåter korta toppar upp till sin storlek samtidigt som den begränsar den långsiktiga takten. 

Det är rätt verktyg för att jämna ut ögonblicket när en arbetskö plötsligt anländer, så att du inte skickar allt samtidigt och skapar en topp i samtidighet.

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: upprätthåll ett jämnt flöde

I vissa fall vill du inte tolerera toppar alls. En leaky bucket släpper igenom arbete i en fast, konstant takt oavsett hur ojämn inmatningen är. Den är ett bättre val när det efterföljande systemet föredrar en jämn, förutsägbar belastning framför tillfälliga toppar.

Till exempel när du medvetet håller dig väl inom en liten samtidighetsbudget som delas med andra tjänster.

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

Exponentiell backoff med full jitter

När en förfrågan misslyckas med en status som går att försöka igen med förvärrar ett omedelbart nytt försök situationen. Backoff sprider ut försöken, och full jitter slumpmässigt fördelar varje fördröjning över hela intervallet. Det förhindrar att många klienter försöker igen i takt och återskapar samma topp som orsakade felet.

Kodexemplet nedan refererar till RetryableError, en liten klass som innehåller den misslyckade statusen och ett eventuellt Retry-After-värde. Den definieras i avsnittet om smidig 429-hantering nedan.

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

Smidig 429-hantering: vad du gör när du når taket

Ett 429 innebär att du överskred kapaciteten även efter prioritetskön, så rätt åtgärd är att sakta ner i stället för att försöka igen mer aggressivt. Det finns fyra sätt att hantera det. Bra hantering bygger på fyra strategier:

• Identifiering
• Respektera Retry-After
• Synliggöra backpressure
• Undvika retry-stormar med en circuit breaker

Låt oss gå igenom dem mer i detalj.

Den första är identifiering. Behandla HTTP 429 (och tillfälliga 500, 502, 503 och 504) som möjliga att försöka igen med, och behandla 400, 401, 403 och 422 som sådana som inte går att försöka igen med. Att försöka igen med en felaktig eller obehörig förfrågan lyckas aldrig och slösar bara en plats.

Den andra är att respektera Retry-After. Om svaret innehåller den rubriken ska du följa den exakt i stället för att beräkna en egen fördröjning. Servern talar om när den förväntar sig att ha kapacitet, och den vet bättre än din exponentiella formel. Använd bara jittered backoff när rubriken saknas.

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

Den tredje aspekten är att synliggöra backpressure. Låt inte nya försök staplas på hög osynligt. Om ditt ködjup eller din uppmätta marginal visar att du inte snart kan hantera en ny förfrågan, avvisa den i kanten med en tydlig signal till anroparen i stället för att acceptera arbete du inte kan utföra.

Den fjärde är att undvika retry-stormar med en circuit breaker. Om felen passerar ett tröskelvärde, öppna kretsen och avbryt snabbt under en nedkylningsperiod i stället för att skicka förfrågningar du väntar dig ska misslyckas. Skicka sedan några testförfrågningar; om de lyckas, stäng kretsen.

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

Kvotmönster för AI-rate limiting i system med flera hyresgäster

Allt hittills utgår från en enda applikation med en enda budget. När du bygger en SaaS ovanpå ElevenLabs ändras problemet: din samtidighetsbudget delas mellan alla dina kunder, och en hyresgäst som kör ett batchjobb ska inte svälta ut alla andra hyresgästers live-trafik. Du behöver ett rättviselager mellan dina hyresgäster och den enda uppströmsgränsen.

Grunden är token buckets per hyresgäst. Ge varje hyresgäst en egen hink dimensionerad efter deras behörighet och godkänn en förfrågan bara när både hyresgästens hink och en global begränsare tillåter det.

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

Hinkar håller varje enskild hyresgäst inom ramarna, men de avgör inte vem som vinner när hyresgäster konkurrerar om den globala begränsaren. Använd viktad rättvis köläggning för det. 

Använd inte först till kvarn, eftersom en topp från en hyresgäst kan monopolisera platserna. Håll en kö per hyresgäst och fördela i proportion till varje hyresgästs vikt, så att en betalande hyresgäst får en större andel av konkurrensutsatt kapacitet än en kostnadsfri.

Utöver rättvisa bör du reservera marginal. Låt aldrig normal trafik använda 100 % av samtidighetsgränsen. Reservera en andel, exempelvis 15–20 %, som buffert för latenskänsliga interaktiva förfrågningar och prioritetskön.

När rättvisa inom en enda budget inte längre räcker, dela upp över workspaces eller nycklar. En enda samtidighetsbudget blir till slut flaskhalsen, oavsett hur rättvist du delar den. 

Dela då upp arbetslaster på separata workspaces eller API-nycklar med egna budgetar: exempelvis en nyckel för agenttrafik i realtid och en annan för berättarröst i bakgrunden, så att en eftersläpning för berättarröst inte kan påverka agentkapaciteten.

Workspaces låter dig också använda omfattningsbegränsning, kreditkvoter och kontroller per nyckel, som beskrivs i autentiseringsdokumentationen.

Övervaka ditt samtidighetsutnyttjande

Inget av detta går att justera utan mätning; du kan inte hantera marginal som du inte mäter. Registrera current-concurrent-requests och maximum-concurrent-requests för varje svar, taggat efter modellfamilj, och rapportera utnyttjandegraden som ett mätvärde.

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

Fyra signaler att följa:

• Utnyttjande (aktuellt / maximalt).
• 429-frekvens som andel av alla förfrågningar.
• Retry-djup, antalet försök per logisk förfrågan.
• Tid till första ljudet, mätt från din applikation, inte från modellens inferenssiffror. Se förstå latens för vad TTFA omfattar.

Ett välfungerande system håller utnyttjandet bekvämt under mättnad och ser 429-fel endast vid enstaka toppar. Genom att övervaka dessa signaler får du insyn i trycket från rate limiting långt innan det blir ett driftsavbrott.

När du ska skala bortom klientbaserad rate limiting

Klientmönster kan göra mycket av det tunga arbetet, men den långsiktiga efterfrågan kommer till slut att växa förbi dem. När det händer är det dags att göra ändringar som hjälper både kostnad och arbetsinsats. 

Vart och ett av följande steg ger dig extra kapacitet.

Börja med att byta från HTTP till WebSockets för interaktiv trafik. Om dina agenter eller användningsfall i realtid körs över HTTP ändrar en WebSocket beräkningen så att bara aktiv generering räknas. För konversationsbaserade arbetslaster multiplicerar detta ofta den effektiva kapaciteten utan att du byter plan, eftersom inaktiv konversationstid slutar uppta platser.

Om dina toppar är ojämna men din genomsnittliga belastning ryms inom budgeten, jämnar en token bucket eller leaky bucket tillsammans med en begränsad pool ut topparna till genomsnittet.

Välj sedan rätt modell. Snabbare generering upptar varje plats under kortare tid, vilket ökar antalet sändningar som en fast samtidighetsgräns kan hantera. Eleven Flash v2.5 är alternativet med lägst latens för arbete i realtid; att kombinera den med en Instant Voice Clone eller en standardröst undviker den extra belastningen per generering från Professional Voice Clones.

Först därefter bör du uppgradera planen. När din långsiktiga efterfrågan verkligen överstiger budgeten trots att klienten fungerar väl, höjer en högre plan både samtidighetsgränsen per modell och din köprioritet. Jämför nivåerna på API-prissidan.

Om du behöver gränser utöver de publicerade erbjuder Enterprise-planer högre och anpassade samtidighetsgränser samt högsta köprioritet. Ytterligare kontroller finns för kvalificerade användningsfall, till exempel IP-vitlistning (i Enterprise-förhandsversion) och lägen utan datalagring. Kontakta din kundansvariga för att höja gränserna.

Sammanfattning: vad du bör tänka på för AI-rate limiting 

Det grundläggande misstaget är att behandla AI-rate limiting för röst som att räkna förfrågningar. Allt här handlar om samtidighetskontroll. Siffran som avgör om du lyckas är hur många förfrågningar som genererar ljud i samma ögonblick och hur länge var och en upptar sin plats.

Bygg klienten utifrån det. 

Begränsa pågående förfrågningar med en begränsad pool, styr insläpp med en token bucket eller leaky bucket, försök igen med begränsad exponentiell backoff och full jitter, respektera Retry-After och bryt kretsen innan en retry-storm uppstår. 

För system med flera hyresgäster lägger du till hinkar per hyresgäst, viktad rättvisa, reserverad marginal och uppdelning för isolering. Följ svarsrubrikerna current-concurrent-requests och maximum-concurrent-requests och larma på utnyttjandetrenden, inte felen. 

När du verkligen behöver mer kapacitet, arbeta dig igenom listan i ordning: WebSockets och bättre klientbeteende först, sedan rätt modell, sedan en planuppgradering och därefter Enterprise-gränser.

Bygg röstapplikationer med ElevenAPI

AI-rate limiting för produktion börjar med rätt transport, rätt modell och svarsrubriker som visar exakt var du står.

ElevenAPI erbjuder modeller med låg latens som Eleven Flash v2.5, WebSocket-streaming i realtid, Speech to Text och Text to Speech API:er, samt samtidighetsrubriker i varje svar som låter dig bygga röstagenter som skalar inom dina gränser. 

Tillsammans med strategierna för AI-rate limiting i den här artikeln kan du skapa responsiva röstupplevelser med förutsägbar prestanda, även under belastning. 

Utforska ElevenAPI för att se hela modellutbudet i praktiken, eller skapa ett konto för att börja bygga med ElevenLabs i dag.

Vanliga frågor om AI-rate limiting