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

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 férové 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).
• Tok jednotek (např. tokens per minute, rows per hour).
• Souběžnost (concurrency): max. počet paralelních spojení/úloh.
• Okno (window): fixní (např. 60 s), posuvné (sliding), nebo tokové modely (bucket).
• Dimenze limitu: per klíč, per IP, per účet/organizaci, per koncový uživatel (sub-kvóty).

Běžné algoritmy: jak se rate limit aplikuje

• Fixed window: jednoduchý „reset“ počítadla každých T sekund. Výhoda: jednoduchost. Nevýhoda: „hraniční nárazy“ na přelomu oken.
• Sliding window: přesnější rozložení zátěže napříč plynoucím intervalem; méně burstů.
• 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 zdravé bursty až do kapacity kbelíku.
• Concurrency gate: tvrdý limit na počet souběžných zpracování; doplňuje tokové limity.

Signály z odpovědí API

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

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

• Exponenciální backoff: 1 s → 2 s → 4 s → 8 s (max. strop) při 429/503, s respektováním Retry-After.
• Full jitter: náhodný rozptyl v intervalu [0, aktuální_zpoždění] pro předcházení synchronizovaným nárazům více klientů.
• Idempotence: používat 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ý propustnostní strop je minimum ze všech aktivních limitů.

• Příklad výpočtu: limit je 60 RPM a 120k TPM. Průměrně spotřebujete 1,5k tokenů/požadavek. Maximální RPM podle TPM je floor(120000 / 1500) = 80. Efektivní strop je min(60, 80) = 60 RPM.
• Optimalizace: snížením průměrné délky promptu/odpovědi (tokenová ekonomika) zvýšíte dostupné RPM v rámci TPM limitu.
• Batching a kompozice: méně volání s rozumnou agregací, nebo streaming pro dřívější UX signály bez 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 vs. nízkoprioritní dávky).
• 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í chyb/latence; half-open testy pro obnovu.
• Cache a deduplikace: identické dotazy obsloužit z cache; „single flight“ zamezí paralelním duplikátům.

Server-side strategie a víceúrovňové kvóty

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

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: časujte dávky, sledujte response hlavičky a dynamicky upravujte propustnost.
• Obsahová generace s LLM: přerozdělte kapacity mezi SERP-feature výstupy (FAQ, HowTo, Product) a dlouhé články.
• Analogie s „crawl budget“: každé API má svůj „rozpočet“. Plánujte dotazy tak, aby přinesly maximální informační zisk.

Etika, legálnost a robots politika

• Respekt API TOS: nepoužívejte obcházení limitů (rotace účtů/IP) – hrozí blokace.
• Robotické standardy: při crawlování webů respektujte robots.txt a tarif požadavků; správné hlavičky User-Agent.
• Anti-spam: pozor na vysokofrekvenční dotazy do vyhledávacích polí a endpointů s veřejným přístupem.

CDN, cache a „stale-while-revalidate“

Pro snížení potřeby volání do původu:

• Edge cache pro časté GETy; kratší TTL s stale-while-revalidate pro rychlost a úsporu limitů.
• Variantizace cache (Vary) podle relevantních parametrů, aby nedocházelo k cache missům.
• ETag/304: snížení přenosů i 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), dropy v klientském throttle.
• Trace: korelace požadavků a retry cyklů; identifikace horkých míst.
• Alerty: při poklesu remaining < X%, při špičkách latence, při nárůstu 429.
• Experimenty: canary release pro změny rychlosti, A/B pro strategii backoff.

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

• Teoretické QPS: QPS = min(QPS_limit, concurrency / avg_latency).
• Tokenový strop (TPM): RPM_TPM = floor(TPM_limit / avg_tokens_per_request); efektivní RPM = min(RPM_limit, RPM_TPM).
• Šířka fronty: musí pokrýt největší burst do doby prvního zpracování, bez přetečení kbelíku.

Vzorná politika klienta (pseudo-konfigurace)

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 pro pipelines v AIO/AEO

• Orchestrace: rozdělte pipeline na kroky (extrakce → sumarizace → validace → publikace) se samostatnými limity a mezipamětí.
• Prioritizace: odpovědi pro uživatele (AEO) mají vyšší prioritu než offline dávky.
• Degradace: při přetížení použít kratší výstupy, nižší teploty nebo levnější model; plánovaný graceful fallback.

Testování a validace

• Load test v mezích TOS s reálnými promptami a velikostmi odpovědí; sledujte RPM/TPM a chování backoffu.
• Chaos test: simulujte 429/503, náhodné výpadky, latenci; ověřte circuit breaker a opakování.
• Replay: idempotentní požadavky přehrávejte na stagingu k ověření deterministickosti.

Časté chyby a jejich řešení

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

Checklist implementace pro praxi

• Zdokumentujte oficiální limity (RPM, TPM, concurrency) a pravidla retry.
• Nasaďte klientský token bucket + exponenciální backoff s jitterem a respektem 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, p95 latenci, 429/5xx, „remaining“; nastavte alerty.
• Připravte degradaci funkcí (kratší výstupy, levnější model) pro špičky.

Shrnutí

Rate limit je centrální součást škálovatelného a spolehlivého využívání API v moderním SEO, AIO a AEO. Spojením klientských technik (throttling, backoff, cache, fronty), serverových mechanismů (bucket, sliding window, admission control) a důsledné observability dosáhnete stabilní propustnosti bez 429, předvídatelné latence a lepší ekonomiky spotřeby tokenů při práci s LLM. Promyšlené řízení limitů je konkurenční výhodou celého obsahového i odpovědního ekosystému.