Ograniczanie AI dla głosu: współbieżność, kolejki i 429

Większość zespołów podchodzi do ograniczania ruchu AI dla głosu tak jak do innych API: ustawia limit żądań na minutę, ponawia je, gdy serwer odmawia, i na tym kończy. W przypadku obciążeń ElevenLabs ten model przestaje działać już przy pierwszym skoku ruchu, bo faktycznym limitem jest współbieżność, a nie liczba żądań.

Ten przewodnik wyjaśnia, dlaczego kluczowym ograniczeniem jest współbieżność, a potem pokazuje wzorce po stronie klienta, które pozwalają się jej trzymać. Od ograniczonych pul współbieżności i obsługi 429 po sprawiedliwy podział między tenantów oraz token bucket i leaky bucket — omawiamy praktyczne rozwiązania, które możesz wdrożyć. Każdy wzorzec zawiera działającą implementację TypeScript, którą możesz dostosować.

Jeśli tworzysz agentów głosowych, pipeline’y narracji lub inny system produkcyjny oparty na naszych modelach i chcesz skalować, ten poradnik jest dla ciebie.

Podsumowanie

• Ograniczanie ruchu AI dla głosu to kontrola współbieżności, a nie liczenie żądań na minutę.
• Osiągnięcie limitu nie odrzuca ruchu od razu. Żądania trafiają do kolejki priorytetowej, która dodaje około 50 ms.
• Przekroczenie pojemności nawet po kolejkowaniu powoduje błąd HTTP 429.
• WebSockety znacznie zwiększają efektywną pojemność, ponieważ do limitu liczy się tylko aktywne generowanie.
• Systemy wielotenantowe potrzebują dodatkowej warstwy sprawiedliwego podziału: bucketów per tenant, ważonego sprawiedliwego kolejkowania, zarezerwowanego zapasu i rozdzielania obciążeń między klucze dla izolacji.
• Dwa nagłówki odpowiedzi — current-concurrent-requests i maximum-concurrent-requests — pokazują, jak wygląda twoje ograniczanie ruchu AI.

Dlaczego limitem jest współbieżność, a nie żądania na minutę

Współbieżność to liczba żądań w toku w tej samej chwili. Żądania na minutę to przepustowość w określonym czasie. To ważne rozróżnienie, bo zmienia sposób, w jaki utrzymujesz się w limicie.

Podczas korzystania z jednego z modeli ElevenLabs obciążenie serwera rośnie wraz z liczbą równoczesnych użytkowników. Generowanie audio zajmuje slot przez cały czas generowania, a jego długość zależy od długości wejścia, modelu i obciążenia.

Limit żądań na minutę nie mówi nic o liczbie slotów zajętych teraz, a to jedyna wartość mierzona przez serwer.

Limity zależne od planu i rodziny modeli

Twój budżet współbieżności to nie jedna liczba. Limity współbieżności różnią się zależnie od planu i rodziny modeli. Na przykład Speech to Text ma wyższy limit niż Text to Speech, ponieważ żądania transkrypcji są zwykle krótsze, a system może obsłużyć ich więcej naraz.

Limit obowiązuje dla każdej rodziny modeli osobno. Jeśli używasz Flash dla agentów i Multilingual v2 do narracji, korzystasz jednocześnie z dwóch osobnych budżetów. Aktualne wartości dla planów i informacje o współbieżności znajdziesz na stronie modeli.

Co się dzieje po osiągnięciu limitu współbieżności?

Osiągnięcie limitu współbieżności nie odrzuca ruchu od razu. System łagodnie przechodzi na kolejkę priorytetową, a żądania odrzuca dopiero wtedy, gdy nadal przekraczasz całkowitą pojemność limitu.

Dopóki jesteś poniżej limitu, żądania są wykonywane od razu. Po jego osiągnięciu kolejne żądania trafiają do kolejki uporządkowanej według priorytetu twojego planu. Kolejka zwykle dodaje około 50 ms opóźnienia, więc krótkie przekroczenie jest dla użytkowników niemal niewidoczne.

Jeśli system nadal nie ma pojemności po kolejkowaniu, otrzymasz HTTP 429. To sygnał, by zwolnić, a nie od razu ponawiać żądanie. Poziom priorytetu w tabeli określa kolejność twoich żądań względem innego ruchu; wyższe plany szybciej opuszczają kolejkę.

HTTP a WebSocket: jak wpływają na twój limit

Wybrany transport bezpośrednio wpływa na ograniczanie ruchu i budżet. Ta sama rozmowa może zużywać bardzo różną część budżetu współbieżności, zależnie od tego, czy działa przez HTTP, czy WebSocket.

W HTTP każde żądanie liczy się osobno do limitu współbieżności przez cały czas trwania. W WebSocket liczy się tylko czas, gdy model aktywnie generuje audio. Otwarty, ale bezczynny WebSocket zwykle się nie liczy.

W rozmowie z agentem głosowym często są długie chwile, gdy nikt nie mówi i model nic nie generuje. W HTTP slot byłby zajęty przez cały czas żądania w każdej turze. W WebSocket slot jest zużywany tylko przez milisekundy aktywnego generowania, więc jeden slot współbieżności może być współdzielony przez wiele rozmów.

Szczegóły protokołu znajdziesz w przewodniku po WebSocketach TTS w czasie rzeczywistym. Dla ruchu interaktywnego WebSockety są właściwym wyborem domyślnym.

Dlaczego współbieżność ~5 może obsłużyć ~100 transmisji

Matematyka współbieżności wydaje się nieintuicyjna, dopóki nie uwzględnisz czasu odtwarzania. Generowanie jest znacznie szybsze niż odtwarzanie, a slot jest aktywnie zajęty tylko podczas generowania audio. Ta różnica pozwala małemu budżetowi obsłużyć dużą grupę odbiorców.

Żądanie generowane przez ułamek sekundy tworzy kilka sekund audio, które odbiorca potem odtwarza. W trakcie odtwarzania slot zostaje zwolniony i może obsłużyć innych odbiorców.

Orientacyjnie limit współbieżności 5 może obsłużyć około 100 jednoczesnych transmisji audio. Dokładna liczba zależy od głosu, tempa mowy i długości ciszy między wypowiedziami.

Nagłówki, które pokazują, gdzie jesteś

Nie musisz zgadywać, jak blisko limitu jesteś. Każda odpowiedź zawiera dwie liczby, dzięki którym zmierzysz dostępny zapas.

Zwróć uwagę na te dwa nagłówki:

• current-concurrent-requests: ile żądań jest teraz w toku?
• maximum-concurrent-requests: twój limit dla tej rodziny modeli.

Razem te nagłówki zapewniają w czasie rzeczywistym wgląd w bieżące użycie i dostępną pojemność. Nie musisz niczego zgadywać, zanim natrafisz na limity AI.

Strategie ograniczania ruchu AI po stronie klienta

Cztery mechanizmy wystarczają w niemal każdym scenariuszu ograniczania ruchu AI:

• Token bucket: jeśli tokeny są dostępne, przepuszcza żądania. Pojemność odnawia się z czasem, więc obsługuje krótkie skoki bez uderzania w limity.
• Leaky bucket: wygładza ruch przychodzący do stałego tempa wyjściowego, co chroni systemy downstream przed nagłymi skokami.
• Ograniczona pula współbieżności: ogranicza łączną liczbę żądań aktywnych jednocześnie, więc nigdy nie przekraczasz limitu równoczesnych żądań.
• Wykładniczy backoff z pełnym jitterem: stopniowo wydłuża odstępy między nieudanymi żądaniami, aby klienci nie ponawiali ich wszyscy naraz.

Poniższe sekcje pokazują, jak budować je po kolei, zaczynając od tego, który najbliżej odpowiada limitowi współbieżności.

Wszystkie poniższe fragmenty zakładają jednego klienta, inicjalizowanego raz:

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

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

Ograniczona współbieżność: mechanizm zgodny z limitem

Ponieważ serwer mierzy współbieżność, najprostszą kontrolą po stronie klienta jest ograniczona pula workerów, która ustala maksymalną liczbę żądań w toku. Ustaw limit nieco poniżej limitu planu, by zostawić miejsce dla kolejki priorytetowej i jittera.

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: zezwalaj na skoki, ogranicz średnią

Token bucket przechowuje do capacity tokenów i uzupełnia je w tempie refillRate tokenów na sekundę. Każde żądanie zużywa token, więc bucket pozwala na krótkie skoki do swojej pojemności, ograniczając jednocześnie długoterminowe tempo.

To odpowiednie narzędzie, gdy nagle pojawia się kolejka zadań: nie uruchamiasz wszystkiego naraz i nie powodujesz skoku współbieżności.

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: utrzymuj stałe tempo

Czasem w ogóle nie chcesz tolerować skoków. Leaky bucket przyjmuje zadania w stałym tempie, niezależnie od zmienności wejścia. To lepszy wybór, gdy system downstream woli płynne, przewidywalne obciążenie od okazjonalnych skoków.

Na przykład gdy celowo utrzymujesz się wyraźnie poniżej niewielkiego budżetu współbieżności współdzielonego z innymi usługami.

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

Wykładniczy backoff z pełnym jitterem

Gdy żądanie kończy się statusem pozwalającym na ponowienie, natychmiastowa próba tylko pogarsza sytuację. Backoff rozstawia ponowienia w czasie, a pełny jitter losuje każde opóźnienie z całego przedziału. Dzięki temu wielu klientów nie ponawia żądań synchronicznie, odtwarzając skok, który spowodował błąd.

Poniższy fragment używa RetryableError — małej klasy zawierającej status błędu i ewentualną wartość Retry-After. Jej definicję znajdziesz niżej, w sekcji o łagodnej obsłudze 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));
    }
  }
}

Łagodna obsługa 429: co zrobić po osiągnięciu limitu

Kod 429 oznacza, że przekroczyłeś pojemność nawet po kolejce priorytetowej, więc należy zwolnić, a nie intensywniej ponawiać żądania. Dobra obsługa opiera się na czterech strategiach:

• Wykrywanie
• Respektowanie Retry-After
• Sygnalizowanie backpressure
• Unikanie burz ponowień za pomocą circuit breakera

Przyjrzyjmy się im bliżej.

Pierwsze jest wykrywanie. Traktuj HTTP 429 oraz przejściowe 500, 502, 503 i 504 jako błędy, które można ponowić, a 400, 401, 403 i 422 jako nieodnawialne. Ponawianie wadliwego lub nieautoryzowanego żądania nigdy nie zadziała i tylko marnuje slot.

Drugie to respektowanie Retry-After. Jeśli odpowiedź ma ten nagłówek, trzymaj się go dokładnie, zamiast wyliczać własne opóźnienie. Serwer mówi, kiedy spodziewa się wolnej pojemności, i wie to lepiej niż twoja formuła wykładnicza. Użyj backoffu z jitterem tylko wtedy, gdy nagłówka nie ma.

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

Trzeci element to sygnalizowanie backpressure. Nie pozwalaj, by ponowienia niezauważenie się gromadziły. Jeśli głębokość kolejki lub zmierzony zapas wskazuje, że nie obsłużysz szybko nowego żądania, odrzuć je na wejściu z jasnym sygnałem dla wywołującego, zamiast przyjmować pracę, której nie wykonasz.

Czwarty to unikanie burz ponowień za pomocą circuit breakera. Jeśli liczba błędów przekroczy próg, otwórz obwód i przez czas schłodzenia szybko zwracaj błąd, zamiast wysyłać żądania, które prawdopodobnie zawiodą. Po tym czasie wyślij kilka żądań testowych; jeśli się powiodą, zamknij obwód.

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

Wzorce limitów dla wielu tenantów w ograniczaniu ruchu AI

Wszystko dotąd zakładało jedną aplikację i jeden budżet. Gdy budujesz SaaS na ElevenLabs, problem się zmienia: budżet współbieżności jest wspólny dla wszystkich twoich klientów, a tenant uruchamiający zadanie wsadowe nie powinien zagłodzić ruchu na żywo pozostałych. Potrzebujesz warstwy sprawiedliwego podziału między tenantami a pojedynczym limitem upstream.

Podstawą są token buckety per tenant. Daj każdemu tenantowi własny bucket dopasowany do jego uprawnień i przyjmuj żądanie tylko wtedy, gdy pozwala na to zarówno bucket tenanta, jak i globalny limiter.

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

Buckety pilnują, by żaden tenant nie przekraczał swoich zasad, ale nie rozstrzygają, kto ma pierwszeństwo, gdy tenanci konkurują o globalny limiter. Do tego użyj ważonego sprawiedliwego kolejkowania.

Nie obsługuj według kolejności zgłoszeń, bo skok od jednego tenanta może zmonopolizować sloty. Utrzymuj kolejkę dla każdego tenanta i rozdzielaj zadania proporcjonalnie do jego wagi, aby płacący tenant dostawał większą część ograniczonej pojemności niż darmowy.

Oprócz sprawiedliwego podziału zachowaj zapas. Nie pozwalaj, by zwykły ruch zużywał 100% limitu współbieżności. Zarezerwuj część, np. 15–20%, dla interaktywnych żądań wrażliwych na opóźnienia i kolejki priorytetowej.

Gdy sprawiedliwy podział jednego budżetu przestaje wystarczać, rozdziel obciążenia między workspace’y lub klucze. Pojedynczy budżet współbieżności w końcu stanie się wąskim gardłem, niezależnie od tego, jak sprawiedliwie go podzielisz.

Wtedy rozdziel obciążenia między osobne workspace’y lub klucze API z własnymi budżetami: na przykład jeden klucz dla ruchu agentów w czasie rzeczywistym, a drugi dla narracji w tle, aby zaległości narracji nie wpływały na pojemność agentów.

Workspace’y pozwalają też stosować ograniczenia zakresu, limity kredytów i kontrole per klucz, opisane w dokumentacji uwierzytelniania.

Monitorowanie wykorzystania współbieżności

Bez pomiarów nie da się tego dostroić — nie możesz zarządzać zapasem, którego nie mierzysz. Zapisuj current-concurrent-requests i maximum-concurrent-requests z każdej odpowiedzi, oznaczając je rodziną modeli, oraz raportuj wskaźnik wykorzystania jako 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);
  }
}

Cztery sygnały do śledzenia:

• Wykorzystanie (bieżące / maksymalne).
• Odsetek 429 wśród wszystkich żądań.
• Głębokość ponowień, czyli liczba prób na jedno logiczne żądanie.
• Czas do pierwszego audio, mierzony w aplikacji, a nie według danych o inferencji modelu. Sprawdź opis opóźnień, aby dowiedzieć się, co obejmuje TTFA.

Zdrowy system utrzymuje wykorzystanie wyraźnie poniżej nasycenia, a kody 429 widzi tylko przy sporadycznych skokach. Monitorowanie tych sygnałów daje wgląd w presję związaną z limitami długo przed tym, zanim stanie się problemem z dostępnością.

Kiedy skalować poza ograniczanie ruchu po stronie klienta

Wzorce po stronie klienta mogą wiele zdziałać, ale stałe zapotrzebowanie w końcu je przerośnie. Wtedy pora na zmiany, które pomogą zarówno z kosztami, jak i nakładem pracy.

Każdy z kolejnych kroków da ci dodatkową pojemność.

Zacznij od przejścia z HTTP na WebSockety dla ruchu interaktywnego. Jeśli twoi agenci lub przypadki użycia na żywo działają przez HTTP, przejście na WebSocket zmienia sposób naliczania, więc liczy się tylko aktywne generowanie. W przypadku rozmów często zwielokrotnia to efektywną pojemność bez zmiany planu, ponieważ bezczynny czas rozmowy nie zajmuje slotów.

Jeśli masz gwałtowne skoki, ale średnie obciążenie mieści się w budżecie, token lub leaky bucket wraz z ograniczoną pulą wygładzi szczyty do średniego poziomu.

Następnie wybierz właściwy model. Szybsze generowanie zajmuje każdy slot krócej, co zwiększa liczbę transmisji, które może obsłużyć stały limit współbieżności. Eleven Flash v2.5 to opcja o najniższym opóźnieniu do pracy w czasie rzeczywistym; połączenie go z Instant Voice Clone albo domyślnym głosem pozwala uniknąć narzutu Professional Voice Clones przy każdym generowaniu.

Dopiero potem rozważ zmianę planu na wyższy. Gdy stałe zapotrzebowanie naprawdę przekracza budżet mimo poprawnego działania klienta, wyższy plan zwiększa zarówno limit współbieżności na model, jak i priorytet w kolejce. Porównaj poziomy na stronie cen API.

Jeśli potrzebujesz limitów wyższych niż opublikowane, plany Enterprise oferują podwyższone i niestandardowe limity współbieżności oraz najwyższy priorytet w kolejce. W przypadku kwalifikujących się zastosowań dostępne są dodatkowe kontrolki, takie jak lista dozwolonych adresów IP (w wersji preview dla Enterprise) i tryby bez retencji danych. Skontaktuj się ze swoim opiekunem konta, aby podnieść limity.

Podsumowanie najważniejszych zasad ograniczania ruchu AI

Podstawowy błąd to traktowanie ograniczania ruchu AI dla głosu jak liczenia żądań. Wszystko tutaj dotyczy kontroli współbieżności. O powodzeniu decyduje liczba żądań generujących audio w tej samej chwili i czas, przez który każde z nich zajmuje slot.

Zbuduj klienta wokół tego faktu.

Ogranicz żądania w toku za pomocą ograniczonej puli, kształtuj przyjmowanie zadań przez token lub leaky bucket, ponawiaj z ograniczonym wykładniczym backoffem i pełnym jitterem, respektuj Retry-After i przerwij obwód, zanim powstanie burza ponowień.

W systemach wielotenantowych dodaj buckety per tenant, ważony sprawiedliwy podział, zarezerwowany zapas i sharding dla izolacji. Śledź nagłówki current-concurrent-requests oraz maximum-concurrent-requests i ustawiaj alerty na trend wykorzystania, nie na błędy.

Gdy naprawdę potrzebujesz większej pojemności, działaj po kolei: najpierw WebSockety i lepsze zachowanie klienta, potem odpowiedni model, następnie wyższy plan, a na końcu limity Enterprise.

Twórz aplikacje głosowe z ElevenAPI

Ograniczanie ruchu AI gotowe do produkcji zaczyna się od właściwego transportu, właściwego modelu i nagłówków, które dokładnie pokazują, gdzie jesteś.

ElevenAPI oferuje modele o niskim opóźnieniu, takie jak Eleven Flash v2.5, streaming WebSocket w czasie rzeczywistym, Speech to Text oraz API Text to Speech, a także nagłówki współbieżności w każdej odpowiedzi, które pozwalają tworzyć agentów głosowych skalujących się w ramach twoich limitów.

W połączeniu ze strategiami ograniczania ruchu AI z tego artykułu pozwoli ci to tworzyć responsywne doświadczenia głosowe przy przewidywalnej wydajności — nawet pod obciążeniem.

Poznaj ElevenAPI i zobacz pełną gamę modeli w działaniu lub utwórz konto i zacznij tworzyć z ElevenLabs już dziś.

FAQ: ograniczanie ruchu AI