KI-Rate-Limiting für Voice: Nebenläufigkeit, Warteschlangen und 429-Fehler

Die meisten Teams behandeln KI-Rate-Limiting für Voice wie andere APIs: Sie begrenzen Anfragen pro Minute, wiederholen sie, wenn der Server sie ablehnt, und machen weiter. Bei Workloads auf ElevenLabs funktioniert dieses Modell schon beim ersten Traffic-Anstieg nicht mehr, denn das tatsächliche Limit ist die Parallelität, nicht die Anzahl der Anfragen.

Dieser Leitfaden erklärt, warum Parallelität die eigentliche Einschränkung ist, und zeigt dann clientseitige Muster, mit denen Sie innerhalb Ihres Limits bleiben. Von begrenzten Parallelitätspools und dem kontrollierten Umgang mit 429-Fehlern bis zu Fairness für mehrere Mandanten sowie Token- und Leaky-Buckets: Wir stellen praktische Systeme vor, die Sie implementieren können. Jedes Muster ergänzen wir mit einer funktionierenden TypeScript-Implementierung, die Sie anpassen können.

Wenn Sie Voice Agents entwickeln, Narrations-Pipelines oder andere Produktionssysteme auf Basis unserer Modelle betreiben und skalieren möchten, ist dieser Leitfaden für Sie.

Zusammenfassung

• KI-Rate-Limiting für Voice ist Parallelitätssteuerung, nicht das Zählen von Anfragen pro Minute.
• Das Erreichen des Rate-Limits führt nicht sofort zur Ablehnung von Traffic. Stattdessen gelangen Anfragen in eine Prioritätswarteschlange, die etwa 50 ms hinzufügt.
• Wenn die Kapazität auch nach dem Einreihen in die Warteschlange überschritten wird, entsteht ein HTTP-429-Fehler.
• WebSockets erhöhen die effektive Kapazität deutlich, da nur die aktive Generierung auf Ihr Limit angerechnet wird.
• Systeme mit mehreren Mandanten benötigen eine zusätzliche Fairness-Schicht: Buckets pro Mandant, gewichtete faire Warteschlangen, reservierte Kapazitätsreserven und Sharding über Schlüssel zur Isolierung.
• Zwei Response-Header, current-concurrent-requests und maximum-concurrent-requests, zeigen Ihnen Ihren Stand beim KI-Rate-Limiting.

Warum das Limit Parallelität und nicht Anfragen pro Minute ist

Parallelität ist die Anzahl der gleichzeitig laufenden Anfragen. Anfragen pro Minute sind der Durchsatz in einem Zeitfenster. Dieser Unterschied ist wichtig, weil er bestimmt, welcher Hebel Sie innerhalb Ihres Limits hält.

Bei der Nutzung eines der ElevenLabs-Modelle skaliert die Serverlast mit der Anzahl gleichzeitiger Nutzer. Die Audiogenerierung belegt für ihre Dauer einen Slot. Diese Dauer variiert je nach Eingabelänge, Modell und Auslastung.

Eine Begrenzung von Anfragen pro Minute sagt nichts darüber aus, wie viele Slots gerade belegt sind – und genau das misst der Server.

Limits pro Plan und Modellfamilie

Ihr Parallelitätsbudget ist keine einzelne Zahl. Die Parallelitätslimits unterscheiden sich je nach Plan und Modellfamilie. Beispielsweise hat Speech to Text ein höheres Limit als Text to Speech, da Transkriptionsanfragen meist kürzer laufen und das System mehr davon gleichzeitig verarbeiten kann.

Das Limit gilt pro Modellfamilie. Wenn Sie Flash für Agents und Multilingual v2 für Narration verwenden, arbeiten Sie gleichzeitig mit zwei getrennten Budgets. Die aktuellen Werte pro Plan und den Abschnitt zur Parallelität finden Sie auf der Modellseite.

Was passiert, wenn Sie das Parallelitätslimit erreichen?

Das Erreichen des Parallelitätslimits führt nicht sofort zur Ablehnung von Traffic. Das System reagiert kontrolliert über eine Prioritätswarteschlange und lehnt erst vollständig ab, wenn Sie weiterhin die Gesamtkapazität des Rate-Limits überschreiten.

Solange Sie unter Ihrem Limit bleiben, werden Anfragen sofort ausgeführt. Sobald Sie es erreichen, gelangen weitere Anfragen in eine nach der Prioritätsstufe Ihres Plans sortierte Warteschlange. Diese fügt typischerweise etwa 50 ms Latenz hinzu, sodass eine kurze Überschreitung für Nutzer meist kaum sichtbar ist.

Ist das System nach dem Einreihen in die Warteschlange weiterhin überlastet, erhalten Sie HTTP 429. Das ist das Signal, langsamer zu werden, statt sofort erneut zu versuchen. Die Prioritätsstufe in der Tabelle bestimmt, wie Ihre wartenden Anfragen im Verhältnis zu anderem Traffic eingeordnet werden. Höhere Pläne durchlaufen die Warteschlange schneller.

HTTP vs. WebSocket: Wie beide auf Ihr Limit angerechnet werden

Das gewählte Transportprotokoll beeinflusst Rate-Limiting und Budget direkt. Dieselbe eingehende Unterhaltung kann je nach HTTP oder WebSocket sehr unterschiedliche Teile Ihres Parallelitätsbudgets verbrauchen.

Über HTTP zählt jede Anfrage während ihrer gesamten Dauer einzeln für Ihr Parallelitätslimit. Über einen WebSocket zählt nur die Zeit, in der das Modell aktiv Audio generiert. Ein offener, aber inaktiver WebSocket zählt größtenteils nicht.

Bei einem Voice Agent gibt es in Gesprächen lange Phasen, in denen niemand spricht und das Modell nichts generiert. Mit HTTP würde jeder Turn für die gesamte Anfragedauer einen Slot belegen. Mit WebSocket wird der Slot nur während der Millisekunden aktiver Generierung genutzt. Ein Parallelitätsslot wird damit zeitlich zwischen vielen Gesprächen geteilt.

Details zum Protokoll finden Sie im WebSocket-Leitfaden für Echtzeit-TTS. Für interaktiven Traffic sind WebSockets die richtige Standardwahl.

Warum etwa 5 parallele Anfragen etwa 100 Übertragungen unterstützen können

Die Mathematik hinter Parallelität wirkt zunächst kontraintuitiv, bis Sie die Wiedergabezeit berücksichtigen. Die Generierung ist deutlich schneller als die Wiedergabe, und ein Slot ist nur während der Audiogenerierung aktiv belegt. Genau dieser Unterschied ermöglicht es, mit einem kleinen Budget ein großes Publikum zu bedienen.

Eine Anfrage, die nur einen Bruchteil einer Sekunde zur Generierung benötigt, erzeugt mehrere Sekunden Audio. Während der Hörer es wiedergibt, wird der Slot freigegeben und steht anderen Hörern zur Verfügung.

Als Faustregel kann ein Parallelitätslimit von 5 ungefähr 100 gleichzeitige Audioübertragungen unterstützen. Die genaue Zahl hängt von der Stimme, dem Sprechtempo und der Länge der Pausen zwischen Äußerungen ab.

Header, die Ihren aktuellen Stand zeigen

Sie müssen Ihre Position im Verhältnis zum Limit nicht schätzen. Jede Response enthält zwei Werte, mit denen Sie freie Kapazität messen können.

Achten Sie auf diese beiden Header:

• current-concurrent-requests: Wie viele Anfragen laufen gerade?
• maximum-concurrent-requests: Ihr Limit für diese Modellfamilie.

Zusammen liefern diese Header einen Echtzeit-Überblick über Ihre aktuelle Nutzung und verfügbare Kapazität. Sie sollten nicht raten müssen, bevor Sie auf KI-Rate-Limits stoßen.

Clientseitige Strategien für KI-Rate-Limiting

Vier Grundbausteine decken fast jedes Szenario für KI-Rate-Limiting ab:

• Ein Token Bucket: Sind Tokens verfügbar, können Anfragen fortfahren. Die Kapazität wird mit der Zeit wieder aufgefüllt, sodass kurze Spitzen ohne das Erreichen von Rate-Limits verarbeitet werden können.
• Ein Leaky Bucket: Glättet eingehenden Traffic auf eine feste Ausgaberate und verhindert so, dass plötzliche Spitzen Ihre nachgelagerten Systeme überlasten.
• Ein begrenzter Parallelitätspool: Begrenzt die Gesamtzahl der gleichzeitig aktiven Anfragen, sodass Sie Limits für parallele Anfragen nie überschreiten.
• Exponentieller Backoff mit vollständigem Jitter: Vergrößert schrittweise die Zeit zwischen fehlgeschlagenen Anfragen, damit Clients nicht alle gleichzeitig erneut versuchen.

Die folgenden Abschnitte zeigen, wie Sie diese Bausteine einzeln aufbauen – beginnend mit demjenigen, der am direktesten dem Parallelitätslimit entspricht.

Alle folgenden Codebeispiele setzen einen einzelnen Client voraus, der einmalig initialisiert wird:

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

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

Begrenzte Parallelität: Der Baustein, der zum Limit passt

Da der Server Parallelität misst, ist ein begrenzter Worker-Pool die direkteste clientseitige Steuerung. Er begrenzt die Anzahl gleichzeitig laufender Anfragen. Setzen Sie die Obergrenze etwas unter das Limit Ihres Plans, damit Platz für die Prioritätswarteschlange und Jitter bleibt.

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: Spitzen zulassen, Durchschnitt begrenzen

Ein Token Bucket hält bis zu capacity Tokens und füllt sich mit refillRate Tokens pro Sekunde auf. Jede Anfrage verbraucht ein Token. So erlaubt der Bucket kurze Spitzen bis zu seiner Größe und begrenzt zugleich die langfristige Rate.

Er eignet sich, um den Moment zu glätten, in dem plötzlich eine Arbeitswarteschlange eintrifft. So senden Sie nicht alles auf einmal und erzeugen einen Anstieg der Parallelität.

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: Gleichmäßige Verarbeitung erzwingen

In manchen Fällen möchten Sie überhaupt keine Spitzen zulassen. Ein Leaky Bucket lässt Arbeit mit einer festen, konstanten Rate zu – unabhängig davon, wie schwankend die Eingabe ist. Er ist die bessere Wahl, wenn das nachgelagerte System eine gleichmäßige, vorhersehbare Last gegenüber gelegentlichen Spitzen bevorzugt.

Zum Beispiel, wenn Sie bewusst deutlich innerhalb eines kleinen Parallelitätsbudgets bleiben, das mit anderen Diensten geteilt wird.

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

Exponentieller Backoff mit vollständigem Jitter

Wenn eine Anfrage mit einem wiederholbaren Status fehlschlägt, verschlimmert ein sofortiger neuer Versuch die Situation. Backoff vergrößert die Abstände zwischen Wiederholungen. Vollständiger Jitter verteilt jede Verzögerung zufällig über das gesamte Intervall. So verhindern Sie, dass viele Clients synchron erneut versuchen und dieselbe Spitze erzeugen, die den Fehler verursacht hat.

Das folgende Snippet verwendet RetryableError, eine kleine Klasse, die den fehlgeschlagenen Status und einen möglichen Retry-After-Wert enthält. Sie wird weiter unten im Abschnitt zum kontrollierten Umgang mit 429 definiert.

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

Kontrollierter Umgang mit 429: Was tun, wenn Sie das Limit erreichen?

Ein 429 bedeutet, dass Sie selbst nach der Prioritätswarteschlange über der Kapazität lagen. Die richtige Reaktion ist daher, langsamer zu werden, statt aggressiver zu wiederholen. Dafür gibt es vier Ansätze:

• Erkennung
• Retry-After beachten
• Backpressure sichtbar machen
• Wiederholungsstürme mit einem Circuit Breaker vermeiden

Sehen wir sie uns genauer an.

Der erste Ansatz ist die Erkennung. Behandeln Sie HTTP 429 sowie temporäre Fehler 500, 502, 503 und 504 als wiederholbar. Behandeln Sie 400, 401, 403 und 422 als nicht wiederholbar. Eine fehlerhafte oder nicht autorisierte Anfrage wird durch Wiederholen nie erfolgreich und verschwendet nur einen Slot.

Der zweite Ansatz ist das Beachten von Retry-After. Enthält die Response diesen Header, halten Sie sich genau daran, statt Ihre eigene Verzögerung zu berechnen. Der Server teilt Ihnen mit, wann er voraussichtlich Kapazität hat – und weiß das besser als Ihre exponentielle Formel. Verwenden Sie nur dann Jitter-Backoff, wenn der Header fehlt.

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

Der dritte Aspekt ist, Backpressure sichtbar zu machen. Lassen Sie Wiederholungen nicht unbemerkt anwachsen. Wenn die Tiefe Ihrer Warteschlange oder die gemessene freie Kapazität zeigt, dass Sie eine neue Anfrage nicht bald bedienen können, lehnen Sie sie am Edge mit einem klaren Signal an den Aufrufer ab, statt Arbeit anzunehmen, die Sie nicht erledigen können.

Der vierte Aspekt ist, Wiederholungsstürme mit einem Circuit Breaker zu vermeiden. Überschreiten Fehler einen Schwellenwert, öffnen Sie den Circuit und schlagen während eines Cool-down-Fensters schnell fehl, statt Anfragen zu senden, die erwartbar fehlschlagen. Senden Sie danach einige Testanfragen. Sind sie erfolgreich, schließen Sie den 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-Muster für mehrere Mandanten beim KI-Rate-Limiting

Bisher ging es um eine einzelne Anwendung mit einem einzelnen Budget. Wenn Sie ein SaaS auf ElevenLabs aufbauen, verändert sich das Problem: Ihr Parallelitätsbudget wird von allen Ihren Kunden geteilt, und ein Mandant mit einem Batch-Job darf nicht den Live-Traffic aller anderen Mandanten verdrängen. Sie benötigen eine Fairness-Schicht zwischen Ihren Mandanten und dem einzelnen Upstream-Limit.

Die Grundlage sind Token Buckets pro Mandant. Geben Sie jedem Mandanten einen eigenen Bucket entsprechend seinem Anspruch und lassen Sie eine Anfrage nur zu, wenn sowohl der Mandanten-Bucket als auch ein globaler Limiter dies erlauben.

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 begrenzen einzelne Mandanten, entscheiden aber nicht, wer gewinnt, wenn Mandanten um den globalen Limiter konkurrieren. Verwenden Sie dafür gewichtete faire Warteschlangen.

Verarbeiten Sie nicht nach dem First-Come-First-Served-Prinzip, denn damit kann ein Burst eines Mandanten Slots monopolisieren. Führen Sie eine Warteschlange pro Mandant und verteilen Sie proportional zu dessen Gewichtung. So erhält ein zahlender Mandant einen größeren Anteil umkämpfter Kapazität als ein kostenloser.

Reservieren Sie zusätzlich freie Kapazität. Lassen Sie normalen Traffic nie 100 % des Parallelitätslimits verbrauchen. Halten Sie einen Anteil von etwa 15–20 % als Puffer für latenzsensitive interaktive Anfragen und die Prioritätswarteschlange zurück.

Wenn Fairness innerhalb eines einzelnen Budgets nicht mehr ausreicht, nutzen Sie Sharding über Workspaces oder Schlüssel. Ein einzelnes Parallelitätsbudget wird letztlich zum Engpass – unabhängig davon, wie fair Sie es aufteilen.

Trennen Sie Workloads dann auf unterschiedliche Workspaces oder API-Keys mit eigenen Budgets auf: etwa einen Schlüssel für Echtzeit-Agent-Traffic und einen weiteren für Narration im Hintergrund. So kann ein Narrationsrückstau nicht die Agent-Kapazität beeinträchtigen.

Workspaces ermöglichen außerdem Einschränkungen des Geltungsbereichs, Credit-Quotas und Steuerungen pro Schlüssel, die in der Authentifizierungsdokumentation beschrieben werden.

Überwachung Ihrer Parallelitätsauslastung

Ohne Messung lässt sich nichts davon anpassen. Sie können keine freie Kapazität verwalten, die Sie nicht messen. Erfassen Sie current-concurrent-requests und maximum-concurrent-requests bei jeder Response, markieren Sie sie nach Modellfamilie und geben Sie das Auslastungsverhältnis als Gauge aus.

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 Signale, die Sie verfolgen sollten:

• Auslastung (aktuell / Maximum).
• 429-Rate als Anteil aller Anfragen.
• Wiederholungstiefe, also die Anzahl der Versuche pro logischer Anfrage.
• Zeit bis zum ersten Audio, gemessen in Ihrer Anwendung und nicht anhand von Modell-Inferenzwerten. Informationen dazu, was TTFA umfasst, finden Sie unter „Latenz verstehen“.

Ein gesundes System hält die Auslastung deutlich unter der Sättigung und sieht 429-Fehler nur bei gelegentlichen Spitzen. Die Überwachung dieser Signale macht Rate-Limiting-Druck sichtbar, lange bevor er zu einem Ausfall führt.

Wann Sie über clientseitiges Rate-Limiting hinaus skalieren sollten

Clientseitige Muster können viel leisten, doch die dauerhafte Nachfrage wird sie irgendwann übersteigen. Dann ist es Zeit für Änderungen, die sowohl Kosten als auch Aufwand reduzieren.

Jeder der folgenden Schritte schafft zusätzliche Kapazität.

Stellen Sie zunächst interaktiven Traffic von HTTP auf WebSockets um. Wenn Ihre Agents oder Live-Anwendungsfälle über HTTP laufen, ändert der Wechsel zu WebSocket die Abrechnung: Nur die aktive Generierung zählt. Bei dialogorientierten Workloads vervielfacht das oft die effektive Kapazität ohne Planwechsel, weil inaktive Gesprächszeit keine Slots mehr verbraucht.

Wenn Ihre Spitzen stark schwanken, die durchschnittliche Last aber ins Budget passt, glätten ein Token oder Leaky Bucket zusammen mit einem begrenzten Pool die Spitzen auf den Durchschnitt.

Wählen Sie dann das richtige Modell. Schnellere Generierung belegt jeden Slot kürzer und erhöht damit die Anzahl der Übertragungen, die ein festes Parallelitätslimit tragen kann. Eleven Flash v2.5 ist die Option mit der niedrigsten Latenz für Echtzeitanwendungen. In Kombination mit einem Instant Voice Clone oder einer Standardstimme vermeiden Sie den Overhead von Professional Voice Clones pro Generierung.

Erst danach sollten Sie Ihren Plan upgraden. Wenn Ihre dauerhafte Nachfrage das Budget trotz eines gut konfigurierten Clients tatsächlich übersteigt, erhöht ein höherer Plan sowohl das Parallelitätslimit pro Modell als auch Ihre Warteschlangenpriorität. Vergleichen Sie die Stufen auf der API-Preisseite.

Wenn Sie Limits über die veröffentlichten Werte hinaus benötigen, bieten Enterprise-Pläne höhere und individuelle Parallelitätslimits sowie die höchste Warteschlangenpriorität. Für berechtigte Anwendungsfälle stehen weitere Kontrollen zur Verfügung, etwa IP-Whitelisting (in der Enterprise-Vorschau) und Modi ohne Datenaufbewahrung. Wenden Sie sich an Ihren Account Manager, um Limits zu erhöhen.

Zusammenfassung: Das sollten Sie beim KI-Rate-Limiting beachten

Der grundlegende Fehler besteht darin, KI-Rate-Limiting für Voice als Zählen von Anfragen zu behandeln. Hier geht es vollständig um Parallelitätssteuerung. Entscheidend ist, wie viele Anfragen gleichzeitig Audio generieren und wie lange jede davon ihren Slot belegt.

Richten Sie Ihren Client danach aus.

Begrenzen Sie gleichzeitig laufende Anfragen mit einem begrenzten Pool, steuern Sie die Zulassung mit einem Token oder Leaky Bucket, wiederholen Sie mit begrenztem exponentiellem Backoff und vollständigem Jitter, beachten Sie Retry-After und unterbrechen Sie den Circuit, bevor ein Wiederholungssturm entsteht.

Für Systeme mit mehreren Mandanten ergänzen Sie Buckets pro Mandant, gewichtete Fairness, reservierte Kapazitätsreserven und Sharding zur Isolierung. Überwachen Sie die Header current-concurrent-requests und maximum-concurrent-requests und alarmieren Sie bei Auslastungstrends, nicht erst bei Fehlern.

Wenn Sie tatsächlich mehr Kapazität brauchen, gehen Sie die Liste der Reihe nach durch: zuerst WebSockets und besseres Client-Verhalten, dann das richtige Modell, anschließend ein Plan-Upgrade und schließlich Enterprise-Limits.

Voice-Anwendungen mit ElevenAPI entwickeln

KI-Rate-Limiting auf Produktionsniveau beginnt mit dem richtigen Transportprotokoll, dem richtigen Modell und Headern, die Ihnen genau zeigen, wo Sie stehen.

ElevenAPI bietet Modelle mit niedriger Latenz wie Eleven Flash v2.5, Echtzeit-Streaming über WebSocket, Speech to Text und Text-to-Speech-APIs sowie Parallelitäts-Header pro Response. Damit können Sie Voice Agents entwickeln, die innerhalb Ihrer Limits skalieren.

In Kombination mit den Strategien für KI-Rate-Limiting aus diesem Artikel liefern Sie reaktionsschnelle Voice-Erlebnisse bei vorhersehbarer Performance – auch unter Last.

Entdecken Sie ElevenAPI, um die gesamte Modellpalette in Aktion zu sehen, oder erstellen Sie ein Konto, um noch heute mit ElevenLabs zu entwickeln.

FAQ zum KI-Rate-Limiting