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

Większość zespołów podchodzi do limitowania ruchu AI dla głosu tak samo jak do innych API: ogranicza liczbę żądań na minutę, ponawia je, gdy serwer odmawia, i na tym kończy. W przypadku obciążeń ElevenLabs ten model zawodzi już przy pierwszym skoku ruchu, bo limitem, na który faktycznie trafiasz, jest współbieżność, a nie liczba żądań.

Ten przewodnik wyjaśnia, dlaczego prawdziwym ograniczeniem jest współbieżność, a następnie pokazuje wzorce po stronie klienta, które pomagają się jej trzymać. Od ograniczonych pul współbieżności i łagodnej obsługi 429 po sprawiedliwy podział między tenantów oraz wiadra tokenów i cieknące wiadra — przedstawiamy praktyczne rozwiązania, które możesz wdrożyć. Każdy wzorzec uzupełniliśmy działającą implementacją w 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 go skalować, ten poradnik jest dla ciebie.

Podsumowanie

• Limitowanie ruchu AI dla głosu to kontrola współbieżności, a nie liczenie żądań na minutę.
• Osiągnięcie limitu nie powoduje natychmiastowego odrzucenia ruchu. Zamiast tego żądania trafiają do kolejki priorytetowej, która dodaje około 50 ms.
• Przekroczenie pojemności nawet po kolejkowaniu spowoduje błąd HTTP 429.
• WebSockety znacznie zwiększają efektywną pojemność, ponieważ do limitu wlicza się tylko aktywne generowanie.
• Systemy wielotenantowe potrzebują dodatkowej warstwy sprawiedliwości: wiader na tenantów, ważonego sprawiedliwego kolejkowania, zarezerwowanego zapasu i podziału między klucze dla izolacji. 
• Dwa nagłówki odpowiedzi — current-concurrent-requests i maximum-concurrent-requests — pokazują, gdzie jesteś względem limitowania ruchu AI.

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

Współbieżność to liczba żądań przetwarzanych w tej samej chwili. Żądania na minutę to przepustowość w danym oknie czasowym. To ważne rozróżnienie, bo zmienia sposób utrzymania 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 na cały czas generowania, a ten 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 w tej chwili, a to jedyna wartość mierzona przez serwer.

Limity zależne od planu i rodziny modeli

Twój budżet współbieżności nie jest jedną liczbą. 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 zwykle trwają krócej, a system może obsłużyć ich więcej naraz.

Limit obowiązuje na rodzinę modeli. Jeśli używasz Flash do agentów i Multilingual v2 do narracji, korzystasz jednocześnie z dwóch osobnych budżetów. Aktualne wartości dla planów i sekcja o współbieżności są opisane 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ą i odrzuca żądania 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 trafiają do kolejki uporządkowanej według priorytetu twojego planu. Kolejka zwykle dodaje około 50 ms opóźnienia, więc krótkie przekroczenie limitu jest dla użytkowników prawie niewidoczne.

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

HTTP a WebSocket: jak każdy z nich liczy się do limitu

Wybrany transport bezpośrednio wpływa na limitowanie ruchu i budżet. Ta sama przychodząca rozmowa może zużyć znacząco inną część budżetu współbieżności zależnie od tego, czy działa przez HTTP, czy WebSocket.

W HTTP każde żądanie osobno wlicza się 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 zasadniczo się nie liczy.

W agencie głosowym rozmowa często ma długie momenty, gdy nikt nie mówi, a model niczego nie generuje. W HTTP przy każdej turze zajmowałbyś slot przez cały czas żądania. W WebSocket slot jest używany tylko przez milisekundy aktywnego generowania, więc jeden slot współbieżności jest współdzielony przez wiele rozmów. 

Więcej informacji o protokole 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 dużo 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, którego wygenerowanie trwa ułamek sekundy, tworzy kilka sekund audio, które słuchacz następnie odtwarza. W trakcie odtwarzania slot jest zwalniany i dostępny dla innych słuchaczy.

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 ilości ciszy między wypowiedziami.

Nagłówki, które pokazują twoją sytuację

Nie musisz zgadywać, gdzie jesteś względem limitu. Każda odpowiedź zawiera dwie liczby, dzięki którym możesz mierzyć zapas zamiast go szacować.

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

• current-concurrent-requests: ile żądań jest teraz przetwarzanych?
• 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 trafisz na limity ruchu AI.

Strategie limitowania ruchu AI po stronie klienta

Są cztery mechanizmy, które obejmują niemal każdy scenariusz limitowania ruchu AI:

• Wiadro tokenów: jeśli tokeny są dostępne, pozwala realizować żądania. Pojemność odnawia się z czasem, więc obsługuje krótkie skoki bez uderzania w limity.
• Cieknące wiadro: wygładza ruch przychodzący do stałej szybkości wyjściowej, co zapobiega przeciążeniu systemów downstream 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ęp między nieudanymi żądaniami, by klienci nie ponawiali ich wszyscy naraz.

Poniższe sekcje pokazują, jak budować je po kolei, zaczynając od mechanizmu najbardziej bezpośrednio odpowiadającego limitowi współbieżności.

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

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

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

Ograniczona współbieżność: mechanizm odpowiadający limitowi

Ponieważ serwer mierzy współbieżność, najprostszą kontrolą po stronie klienta jest ograniczona pula workerów, która ogranicza liczbę jednocześnie przetwarzanych żądań. Ustaw limit nieco poniżej limitu planu, aby zostawić miejsce na kolejkę priorytetową i 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

Wiadro tokenów: pozwól na skoki, ogranicz średnią

Wiadro tokenów przechowuje do capacity tokenów i odnawia refillRate tokenów na sekundę. Każde żądanie zużywa token, więc wiadro pozwala na krótkie skoki do swojej pojemności, jednocześnie ograniczając długoterminową szybkość. 

To właściwe narzędzie do wygładzania momentu, gdy nagle pojawia się kolejka pracy, aby nie wysłać wszystkiego naraz i nie zwiększyć 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;
  }
}

Cieknące wiadro: wymuszaj stały odpływ

W niektórych przypadkach nie chcesz tolerować żadnych skoków. Cieknące wiadro przyjmuje pracę ze stałą, niezmienną szybkością niezależnie od skokowego charakteru wejścia. To lepszy wybór, gdy system downstream woli płynne, przewidywalne obciążenie od okazjonalnych pików.

Na przykład gdy celowo pozostajesz wyraźnie poniżej małego 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 rozsuwa ponowienia w czasie, a pełny jitter losuje każde opóźnienie w całym przedziale, co zapobiega ponawianiu przez wielu klientów w tym samym rytmie i odtworzeniu skoku, który spowodował błąd.

Poniższy fragment korzysta z RetryableError — małej klasy zawierającej nieudany status i wartość Retry-After. Jest zdefiniowana w sekcji o łagodnej obsłudze 429 poniżej.

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

429 oznacza, że przekroczyłeś pojemność nawet po kolejce priorytetowej, więc właściwą reakcją jest zwolnienie, a nie intensywniejsze ponawianie. Możesz obsłużyć to na cztery sposoby. Dobra obsługa sprowadza się do czterech strategii:

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

Omówmy je dokładniej.

Pierwsze jest wykrywanie. Traktuj HTTP 429 (oraz przejściowe 500, 502, 503 i 504) jako możliwe do ponowienia, a 400, 401, 403 i 422 jako niemożliwe do ponowienia; ponawianie błędnego lub nieautoryzowanego żądania nigdy nie zadziała i tylko marnuje slot.

Drugie to uwzględnianie Retry-After. Jeśli odpowiedź zawiera ten nagłówek, zastosuj go dokładnie zamiast wyliczać własne opóźnienie. Serwer mówi ci, kiedy spodziewa się mieć pojemność, i wie to lepiej niż twoja wykładnicza formuła. 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 aspekt to sygnalizowanie backpressure. Nie pozwól, by ponowienia niewidocznie się kumulowały. Jeśli głębokość kolejki lub zmierzony zapas wskazuje, że nie obsłużysz wkrótce nowego żądania, odrzuć je na brzegu 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 szybko zwracaj błąd przez okno schłodzenia, 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 kwot dla wielu tenantów w limitowaniu ruchu AI

Wszystko dotąd zakłada jedną aplikację i jeden budżet. Gdy tworzysz SaaS oparty na ElevenLabs, problem wygląda inaczej: budżet współbieżności dzielisz między wszystkich własnych klientów, a tenant uruchamiający zadanie wsadowe nie powinien zagłodzić ruchu na żywo pozostałych tenantów. Potrzebujesz warstwy sprawiedliwości między tenantami a pojedynczym limitem upstream.

Podstawą są wiadra tokenów dla każdego tenanta. Daj każdemu tenantowi własne wiadro dopasowane do jego uprawnień i przyjmuj żądanie tylko wtedy, gdy pozwalają na to zarówno wiadro 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();
  }
}

Wiadra utrzymują każdego tenanta w ryzach, ale nie rozstrzygają, kto wygrywa, gdy tenanty rywalizują o globalny limiter. Do tego użyj ważonego sprawiedliwego kolejkowania. 

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

Oprócz sprawiedliwości zarezerwuj zapas. Nigdy nie pozwalaj, by zwykły ruch zużył 100% limitu współbieżności. Zachowaj część, na przykład 15–20%, jako bufor dla wrażliwych na opóźnienia żądań interaktywnych i kolejki priorytetowej.

Gdy sprawiedliwy podział jednego budżetu przestaje wystarczać, podziel obciążenie między workspace'y lub klucze. Jeden 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, kwoty kredytów oraz kontrole dla poszczególnych kluczy, opisane w dokumentacji uwierzytelniania.

Monitorowanie wykorzystania współbieżności

Bez pomiarów nie da się nic dostroić; nie możesz zarządzać zapasem, którego nie mierzysz. Rejestruj current-concurrent-requests i maximum-concurrent-requests przy każdej odpowiedzi, z oznaczeniem rodziny modelu, 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).
• Współczynnik 429 jako część wszystkich żądań.
• Głębokość ponowień, czyli liczba prób na logiczne żądanie.
• Czas do pierwszego audio, mierzony w aplikacji, a nie na podstawie danych o inferencji modelu. Zobacz opis opóźnień, aby sprawdzić, co obejmuje TTFA.

Zdrowy system utrzymuje wykorzystanie wyraźnie poniżej nasycenia i widzi 429 tylko przy okazjonalnych skokach. Monitorowanie tych sygnałów daje wgląd w presję limitowania ruchu na długo przed tym, zanim stanie się ona problemem z dostępnością.

Kiedy skalować poza limitowanie ruchu po stronie klienta

Wzorce po stronie klienta mogą zrobić bardzo dużo, ale stałe zapotrzebowanie z czasem je przerośnie. Gdy tak się stanie, warto wprowadzić zmiany zmniejszające koszt i nakład pracy. 

Każdy z poniższych kroków zapewni 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 tak, by liczyło się tylko aktywne generowanie. W przypadku obciążeń konwersacyjnych często zwielokrotnia to efektywną pojemność bez zmiany planu, ponieważ bezczynny czas rozmowy przestaje zużywać sloty.

Jeśli skoki ruchu są gwałtowne, ale średnie obciążenie mieści się w budżecie, wiadro tokenów lub cieknące wiadro wraz z ograniczoną pulą wyrównuje piki do średniej.

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 jej z Instant Voice Clone lub domyślnym głosem pozwala uniknąć narzutu na każde generowanie związanego z Professional Voice Clones.

Dopiero potem warto zmienić plan 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 kolejki. Porównaj plany 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 kolejki. Dla kwalifikujących się przypadków użycia dostępne są dodatkowe kontrole, takie jak lista dozwolonych adresów IP (w wersji preview dla Enterprise) i tryby bez retencji danych. Skontaktuj się z opiekunem konta, aby podnieść limity.

Podsumowanie najważniejszych zasad limitowania ruchu AI 

Podstawowym błędem jest traktowanie limitowania ruchu AI dla głosu jak liczenia żądań. Wszystko tutaj dotyczy kontroli współbieżności. O sukcesie 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 liczbę żądań w toku za pomocą ograniczonej puli, kształtuj przyjmowanie żądań wiadrem tokenów lub cieknącym wiadrem, ponawiaj z ograniczonym wykładniczym backoffem i pełnym jitterem, uwzględniaj Retry-After i przerwij obwód, zanim powstanie burza ponowień. 

W systemach wielotenantowych dodaj wiadra dla tenantów, ważoną sprawiedliwość, zarezerwowany zapas i podział dla izolacji. Obserwuj nagłówki current-concurrent-requests i maximum-concurrent-requests oraz ustaw alerty na trend wykorzystania, a nie na błędy. 

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

Twórz aplikacje głosowe z ElevenAPI

Limitowanie ruchu AI na poziomie produkcyjnym zaczyna się od właściwego transportu, modelu i nagłówków, które dokładnie pokazują twoją sytuację.

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 dla każdej odpowiedzi, dzięki którym możesz tworzyć agentów głosowych skalujących się w granicach twoich limitów. 

W połączeniu ze strategiami limitowania ruchu AI z tego artykułu zapewnisz responsywne doświadczenia głosowe przy przewidywalnej wydajności, nawet pod obciążeniem. 

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

FAQ: limitowanie ruchu AI