Rate limit: omezení počtu volání API

LLM a generativní AI
Dalimil
Rate limit: Obmedzenie počtu volaní API

Co je rate limit a proč existuje

Rate limit je politika poskytovatele API, která omezuje počet požadavků (nebo zpracovaných jednotek, např. tokenů) v definovaném časovém intervalu. Cílem je chránit infrastrukturu, zajistit spravedlivé sdílení kapacity mezi klienty, udržet předvídatelnou latenci a kontrolovat náklady. V kontextu AIO/AEO a moderního SEO je řízení limitů klíčové zejména při práci s LLM API, vyhledávacími API, indexačními službami a při sběru či synchronizaci obsahových dat.

Typy rate limitů a metriky

  • Počet požadavků (requests/min, requests/sec).
  • Toky jednotek (např. tokens per minute, rows per hour).
  • Souběžnost (concurrency): max. počet paralelních spojení/úloh.
  • Okno (window): pevné (např. 60 s), posuvné (sliding), nebo modely založené na toku (bucket).
  • Dimenze limitu: na klíč, na IP, na účet/organizaci, na koncového uživatele (subkvóty).

Běžné algoritmy: jak se rate limit uplatňuje

  • Fixed window: jednoduchý „reset“ počítadla každých T sekund. Výhoda: jednoduchost. Nevýhoda: „nárazy na hranici“ při přechodu mezi okny.
  • Sliding window: přesnější rozložení zátěže v průběžném intervalu; méně nárazových špiček.
  • Leaky bucket (odkapávání): požadavky odtékají konstantní rychlostí; vyrovnává špičky.
  • Token bucket: do „kbelíku“ přibývají tokeny rychlostí R/s; požadavek tokeny spotřebuje. Umožňuje přiměřené nárazové špičky až do kapacity kbelíku.
  • Concurrency gate: pevný limit počtu souběžně zpracovávaných požadavků; doplňuje tokové limity.

Signály z odpovědí API

  • HTTP 429 Too Many Requests: limit byl překročen, dočasně zpomalte.
  • HTTP 503 Service Unavailable: přetížení; často je vhodné zkusit opakování s backoff.
  • Hlavičky: Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset (názvy se liší podle poskytovatele).

Exponenciální backoff a jitter: doporučený postup

  • Exponenciální backoff: 1 s → 2 s → 4 s → 8 s (max. limit) při 429/503, s respektováním Retry-After.
  • Full jitter: náhodný rozptyl v intervalu [0, aktuální_zpoždění], aby se předešlo synchronizovaným nárazům více klientů.
  • Idempotence: používejte idempotentní operace nebo Idempotency-Key pro bezpečné opakování.

Rate limit a LLM: RPM, TPM a souběžnost

LLM API často používají kombinované limity – např. requests per minute (RPM) a tokens per minute (TPM) plus concurrency. Skutečný limit propustnosti je minimum ze všech aktivních limitů.

  • Příklad výpočtu: limit je 60 RPM a 120k TPM. V průměru spotřebujete 1,5k tokenů na požadavek. Maximální RPM podle TPM je floor(120000 / 1500) = 80. Efektivní limit je min(60, 80) = 60 RPM.
  • Optimalizace: zkrácením průměrné délky promptu/odpovědi (tokenová ekonomika) zvýšíte dostupné RPM v rámci limitu TPM.
  • Batching a kompozice: méně volání s rozumnou agregací nebo streaming pro dřívější signály UX beze změny TPM.

Architektura klienta: jak se vyhnout 429

  • Client-side throttling podle známého limitu (token bucket v aplikaci).
  • Fronta požadavků s prioritami (důležité dotazy AEO/produkce oproti dávkám s nízkou prioritou).
  • Worker pool s limitem souběžnosti a adaptivním řízením rychlosti (měření latence a chyb → úprava R/s).
  • Circuit breaker při zhoršení chybovosti/latence; testy ve stavu half-open pro obnovení.
  • Cache a deduplikace: identické dotazy obsluhujte z cache; „single flight“ zamezí paralelním duplicitám.

Strategie na straně serveru a víceúrovňové kvóty

  • Hierarchické kvóty: organizace → projekt → klíč API → koncový uživatel; spravedlivé sdílení.
  • Burst capacity: větší kbelíky pro krátké špičky s průměrným limitem v posuvném okně.
  • Admission control: „queuing + tokens“ nebo „fair queuing“ podle priority a historie využití.
  • Autoscaling: rychlé škálování workerů spolu s ochrannými limity, aby škálování nenarazilo na limity upstreamu.

Rate limit vs. SEO/AEO pipeline

  • Crawl & fetch: respektujte limity zdrojových API/webů; používejte If-None-Match (ETag) a If-Modified-Since.
  • Indexační dávky: načasujte dávky, sledujte hlavičky odpovědí a dynamicky upravujte propustnost.
  • Generování obsahu pomocí LLM: přerozdělujte kapacity mezi výstupy pro prvky SERP (FAQ, HowTo, Product) a dlouhé články.
  • Analogie s „crawl budget“: každé API má svůj „rozpočet“. Plánujte dotazy tak, aby nejprve přinášely maximální informační přínos.

Etika, legálnost a pravidla pro roboty

  • Respektujte podmínky API (TOS): neobcházejte limity (rotací účtů/IP) – hrozí zablokování.
  • Standardy pro roboty: při procházení webů respektujte robots.txt a četnost požadavků; používejte správné hlavičky User-Agent.
  • Anti-spam: pozor na vysokofrekvenční dotazy do vyhledávacích polí a veřejně přístupných endpointů.

CDN, cache a „stale-while-revalidate“

Pro snížení potřeby volání na zdrojový server:

  • Edge cache pro časté požadavky GET; kratší TTL s stale-while-revalidate pro vyšší rychlost a úsporu limitů.
  • Varianty cache (Vary) podle relevantních parametrů, aby nedocházelo k výpadkům cache.
  • ETag/304: omezení přenosů i zátěže CPU; šetří limity upstreamu.

Monitorování a observabilita

  • Metriky: počet volání, chybovost (429/5xx), latence p50/p95/p99, využití kvót (remaining), zahazování požadavků v klientském throttlingu.
  • Trace: korelace požadavků a cyklů opakování; identifikace úzkých míst.
  • Upozornění: při poklesu hodnoty remaining pod X %, při špičkách latence, při nárůstu počtu 429.
  • Experimenty: canary release při změnách rychlosti, A/B testování strategie backoff.

Výpočtové vzorce a plánování kapacity

  • Teoretické QPS: QPS = min(QPS_limit, concurrency / avg_latency).
  • Tokenový limit (TPM): RPM_TPM = floor(TPM_limit / avg_tokens_per_request); efektivní RPM = min(RPM_limit, RPM_TPM).
  • Velikost fronty: musí pokrýt největší náraz do doby prvního zpracování, aniž by došlo k přetečení kbelíku.

Vzorová politika klienta (pseudokonfigurace)

rateLimit: { window: 60s, rpm: 60, tpm: 120000, concurrency: 8 }
backoff: { type: "exponential", base: 1s, factor: 2, jitter: "full", max: 32s, maxRetries: 6 }
caching: { mode: "etag+ttl", ttl: 300s, staleWhileRevalidate: 30s }
queue: { priorities: ["prod", "batch"], maxLength: 5000 }
idempotency: { header: "Idempotency-Key" }
alerts: { remainingThreshold: 0.1, errorRate: 0.02, p95LatencyMs: 1500 }

Specifika pipeline v AIO/AEO

  • Orchestrace: rozdělte pipeline do kroků (extrakce → sumarizace → validace → publikace) se samostatnými limity a mezipamětí.
  • Stanovení priorit: odpovědi pro uživatele (AEO) mají vyšší prioritu než offline dávky.
  • Degradace: při přetížení použijte kratší výstupy, nižší teploty nebo levnější model; naplánujte záložní režim pro graceful degradaci.

Testování a validace

  • Load test v mezích TOS s reálnými prompty a velikostmi odpovědí; sledujte RPM/TPM a chování backoffu.
  • Chaos test: simulujte 429/503, náhodné výpadky a latenci; ověřte circuit breaker a opakování požadavků.
  • Replay: přehrávejte idempotentní požadavky ve stagingovém prostředí, abyste ověřili determinističnost.

Časté chyby a jejich řešení

  1. Ignorování hlavičky Retry-After → implementujte její respektování a kombinujte je s exponenciálním backoffem.
  2. Příliš vysoká souběžnost → zmenšete pool size, rozložte dávky, zaveďte izolaci typu bulkhead.
  3. Žádná cache → implementujte ETag/TTL; deduplikujte stejné dotazy.
  4. Neidempotentní retry → použijte Idempotency-Key nebo rozlišujte operace „read“ a „write“.
  5. Statické limity → zaveďte adaptive throttling podle skutečných metrik a zpětné vazby API.

Kontrolní seznam implementace v praxi

  • Zdokumentujte oficiální limity (RPM, TPM, concurrency) a pravidla pro opakování požadavků.
  • Nasaďte klientský token bucket a exponenciální backoff s jitterem a respektováním Retry-After.
  • Zapněte cache (ETag/TTL) a deduplikaci identických dotazů.
  • Zaveďte frontu s prioritami, worker pool s limitem souběžnosti a circuit breaker.
  • Měřte využití kvót, latenci p95, počet 429/5xx a hodnotu „remaining“; nastavte upozornění.
  • Připravte degradaci funkcí (kratší výstupy, levnější model) pro období špičky.

Shrnutí

Rate limit je klíčovou součástí škálovatelného a spolehlivého využívání API v moderním SEO, AIO a AEO. Kombinací technik na straně klienta (throttling, backoff, cache, fronty), mechanismů na straně serveru (bucket, sliding window, admission control) a důsledné observability dosáhnete stabilní propustnosti bez chyb 429, předvídatelné latence a efektivnější ekonomiky spotřeby tokenů při práci s LLM. Promyšlené řízení limitů představuje konkurenční výhodu pro celý obsahový ekosystém i ekosystém odpovědí.