LLM rate limitek élesben: újrapróbálás, backoff és szolgáltatóváltás

Minden LLM-funkció, amely valódi forgalmat kap, előbb-utóbb belefut egy 429-esbe. Néha a saját hibánk, például egy batch-feladat ugyanazt a kulcsot használja, mint a chat-végpont. Néha a szolgáltatóé, amely csúcsidőben túlterhelt. A felhasználó mindkét esetben egy töltésjelzőt, majd egy hibát lát, a szokásos reakció pedig az, hogy a hívást becsomagoljuk egy retry-ciklusba, és lépünk tovább. Ez megmenti a demót, és előkészíti a következő leállást.

Ez az útmutató bemutatja, mi történik valójában egy rate limit mögött, mely hibák érdemelnek újrapróbálást és melyek soha, hogyan várakozzunk úgy, hogy ne szinkronizáljuk az összes klienst, miért pontosan egy rétegbe tartozik az újrapróbálás, és hogyan építsünk fallback-láncot egy másik deploymentre vagy szolgáltatóra úgy, hogy közben csendben ne változzon meg, mit ad vissza a funkció. A számok az Anthropic és az OpenAI 2026. októberi dokumentációjából származnak.

Hogyan működnek valójában a szolgáltatói rate limitek

Az Anthropic a Messages API limitjeit percenkénti kérésekben (RPM), percenkénti bemeneti tokenekben (ITPM) és percenkénti kimeneti tokenekben (OTPM) méri, modellosztályonként, és token bucketet használ: a kapacitás folyamatosan töltődik vissza a maximumig, ahelyett hogy minden perc elején nullázódna. A dokumentáció egy részletet is kiemel, amely sok rejtélyes 429-et megmagyaráz: a 60 RPM-es limitet érvényesíthetik másodpercenként egy kérésként is, így egy rövid löket akkor is elbukik, ha a perc egészében a limit alatt maradsz.

Az OpenAI percenként és naponta számolja a kéréseket és a tokeneket, továbbá percenként a képeket, és amelyik előbb betelik, az váltja ki a hibát. Két további részlet fontos a tervezéshez. Az OpenAI egy kérést a max_tokens és a becsült kérésméret maximumával számol a tokenlimit ellen, vagyis a bőkezű max_tokens felfalja a mozgásteret; az Anthropic a kimeneti limitjére az ellenkezőjét írja, ott csak a generált tokenek számítanak. Az OpenAI arra is figyelmeztet, hogy a sikertelen kérések is beleszámítanak a percenkénti limitbe, ezért a szoros retry-ciklusok rontanak a 429-en, nem javítanak.

Az Anthropic gyorsulási limiteket is alkalmaz: ha a szervezet használata hirtelen megugrik, a szintedhez tartozó limitek alatt is kaphatsz 429-et, és a tanács az, hogy fokozatosan növeld a forgalmat. Ez az indulás napján számít, és akkor, amikor egy visszatöltő feladat teljes sebességgel indul.

Osztályozd a hibát, mielőtt újrapróbálod

Az újrapróbálás csak akkor hasznos, ha a következő kísérlet bármilyen változtatás nélkül sikerülhet. A legtöbb retry-hiba abból ered, hogy minden nem 200-as választ egyformán kezelünk. A Claude API hibalistája elég tisztán elválasztja az eseteket:

A streaming még egy esetet hoz. Server-sent events esetén a hiba azután is megérkezhet, hogy az API már 200-at adott vissza, így a státuszkód alapú retry-logika sosem látja. Hogy egy félig streamelt választ újrapróbálsz-e, termékdöntés: chat-felületen mutasd meg, ami megérkezett, és kínálj újrapróbálás gombot; háttérfeladatban dobd el a részleges kimenetet, és ismételd meg az egész kérést.

Exponenciális backoff jitterrel és határidővel

Az OpenAI útmutatója és az AWS Builders Library egyetért a formában: várj egy kicsit, minden hiba után egyre tovább, adj hozzá véletlenszerűséget, hogy a kliensek ne egyszerre próbálkozzanak, és egy határ után állj meg. Az OpenAI hozzáteszi, hogy a Retry-After minimum, nem javaslat. A HTTP-szemantika szerint a fejléc vagy másodperceket, vagy HTTP-dátumot tartalmaz, ezért mindkettőt kezeld.

// One retry wrapper for the whole app. Turn SDK retries off (maxRetries: 0) when you use it.
const RETRYABLE = new Set([408, 429, 500, 502, 503, 504, 529])

function retryAfterMs(h: Headers): number | null {
  const v = h.get('retry-after')
  if (!v) return null
  const s = Number(v)
  if (!Number.isNaN(s)) return s * 1000
  const t = Date.parse(v)              // HTTP-date form
  return Number.isNaN(t) ? null : Math.max(0, t - Date.now())
}

export async function withRetry<T>(call: () => Promise<Response>, parse: (r: Response) => Promise<T>,
  { attempts = 4, baseMs = 500, capMs = 20_000, deadlineMs = 45_000 } = {}): Promise<T> {
  const start = Date.now()
  for (let i = 0; ; i++) {
    const res = await call()
    if (res.ok) return parse(res)
    const body = await res.clone().json().catch(() => ({}))
    const spendCap = body?.error?.details?.error_code === 'enforced_spend_limit_reached'
    if (!RETRYABLE.has(res.status) || spendCap || i + 1 >= attempts) throw new Error(`LLM ${res.status}`)
    const backoff = Math.random() * Math.min(capMs, baseMs * 2 ** i)   // "full jitter"
    const wait = Math.max(retryAfterMs(res.headers) ?? 0, backoff)
    if (Date.now() - start + wait > deadlineMs) throw new Error(`LLM ${res.status}: retry budget spent`)
    await new Promise((r) => setTimeout(r, wait))
  }
}

A határidő ugyanannyit számít, mint a próbálkozások száma. Egy chat-kérés, amely 45 másodperc után is még újrapróbál, kudarc, bármi történjék utána, ezért add fel korán, és hagyd, hogy a fallback-lánc vagy a felület kezelje. A háttérfeladatok megengedhetnek hosszabb határidőt, de sokkal erősebben is kell várakozniuk, mert ugyanazokért a limitekért versenyeznek az interaktív forgalommal.

Újrapróbálás pontosan egy rétegben

Az AWS-cikk adja a legvilágosabb figyelmeztetést: egy öt szint mély hívási láncban, ahol minden szint háromszor próbálkozik újra, a legalsó függőség terhelése a 243-szorosára nőhet. Az LLM-stackek ugyanezt a csapdát rejtik. Az Anthropic SDK alapból kétszer próbálja újra a kapcsolati hibákat, a 429-eseket és az 5xx-eseket, és figyelembe veszi a retry-after-t. A Vercel AI SDK-ban a maxRetries alapértéke 2. Egy gatewaynek, például a LiteLLM-nek, num_retries beállítása van. Ha a saját kódod is ciklusban próbálkozik, egy incidens alatt egyetlen kattintásból tucatnyi upstream hívás lesz, éppen akkor, amikor a szolgáltató a legkevésbé bírja.

• Azt a réteget válaszd, amelyik a legtöbbet tudja. Általában a gatewayt, ha van, mert az látja az összes forgalmat és minden deploymentet. Különben a saját wrapperedet.
• Mindenhol máshol állítsd nullára az újrapróbálást. maxRetries: 0 az SDK-kliensben, semmi ciklus a route handlerekben.
• Vezess be retry-költségvetést. Az AWS token buckettel korlátozza a helyi újrapróbálást: amíg van token, szabadon mennek, utána csak rögzített ütemben. Így egy leállás nem duplázza meg a kérésszámot.
• Előbb tedd idempotenssé a mellékhatásokat. Egy ágenslépés, amely e-mailt küld vagy rendelést ír, nem futhat le kétszer csak azért, mert az utána következő modellhívást újrapróbáltad.

Fallback-lánc építése

Az újrapróbálás a rövid kiesésekre jó. Ha egy modell tartósan elérhetetlen, vagy kimerült a hozzá tartozó limited, a kérésnek máshová kell mennie. Én aszerint rendezem a lehetőségeket, mennyire változtatják meg a kimenetet: először ugyanaz a modell másik deploymenten vagy régióban, aztán ugyanannak a szolgáltatónak egy testvérmodellje, végül egy másik szolgáltató, a lánc végén pedig kontrollált visszalépés (cache-elt válasz, egyszerűbb funkció, őszinte hibaüzenet).

Ritkán kell magadnak megírnod. A LiteLLM a router_settings alatt egy fallbacks listát vár, amely egy modellcsoporthoz rendezett tartalékokat rendel, és num_retries próbálkozás után lép életbe. Van context_window_fallbacks is a túl hosszú promptokhoz és content_policy_fallbacks a szolgáltatói szűrő általi elutasításokhoz. Az OpenRouter prioritási sorrendben vár egy models tömböt, hiba esetén a következő modellel próbálkozik, rate limitnél, leállásnál és kontextushossz-hibánál is, és azt a modellt számlázza, amelyik ténylegesen kiszolgálta a kérést.

# LiteLLM proxy: retries live here, nowhere else
router_settings:
  num_retries: 2
  allowed_fails: 3        # failures per minute before a deployment cools down
  cooldown_time: 30       # seconds the deployment is skipped
  retry_policy:
    RateLimitErrorRetries: 3
    BadRequestErrorRetries: 0
    AuthenticationErrorRetries: 0
    DefaultRetries: 2
  fallbacks: [{"support-primary": ["support-secondary"]}]
  enable_pre_call_checks: true   # needed for context-window fallbacks to check input size

Miért változtatja meg csendben a fallback a termékedet

Egy 200-at visszaadó fallback is lehet kudarc. Az egy modellre hangolt promptok gyakran másként viselkednek egy másikon; a strukturált kimenet támogatása és a JSON Schema lefedettsége szolgáltatónként eltér; a tool-calling formátumok és az elutasítási stílusok különböznek; a prompt cache pedig szolgáltatónként külön él, így a fallbacken töltött első percek drágábbak és lassabbak. A csapatok ezt akkor veszik észre, amikor az incidens már véget ért, és a supportjegyekben furcsa válaszokról olvasnak.

• Értékeld ki a fallbacket úgy, mint egy migrációt. Futtasd a regressziós készletet a lánc minden modelljén, ahogy az LLM-modellmigrációk regresszió nélkül cikkben leírtam.
• Tarts modellenként külön promptot. Egy fallback-bejegyzés modell, prompt és paraméterek együtt, nem csak egy modellnév.
• Validáld a kimenetet a forrástól függetlenül. A sémavalidáció és az üzleti ellenőrzések minden válaszon lefutnak; a strukturált kimenetek ezt nem teszik feleslegessé.
• Rögzítsd, melyik modell válaszolt. A kiszolgáló modellt írd bele a trace-ekbe, hogy a minőségi dashboardok ne mossanak össze két terméket egy vonallá.
• Ellenőrizd az adattárolás helyét. Egy EU-régióból amerikai végpontra váltó fallback megszegheti az adatfeldolgozási szerződés ígéretét; lásd: GDPR és LLM-adatrezidencia.

Cooldownok és circuit breakerek

Memória nélkül minden kérés újra felfedezi, hogy egy deployment nem működik, és kifizeti az időtúllépést. Martin Fowler circuit breakere ezt három állapottal oldja meg: zárt (a hívások átmennek, a hibákat számolja), nyitott (a hívások azonnal elbuknak, a függőséget meg sem érintik) és félig nyitott (egy várakozás után egyetlen próbahívás dönti el, zárjon-e újra). A LiteLLM deploymentenként egy egyszerűbb változatot ad: ha egy percen belül allowed_fails hiba történik (alapból 3), a deployment cooldown_time másodpercre (alapból 5) kimarad, és a forgalom a többihez megy.

Az AWS-cikk óvatosabb a breakerekkel: nehezen tesztelhető, módváltó viselkedést visznek a rendszerbe, és lassíthatják a helyreállást, ezért az AWS a helyi retry-költségvetést részesíti előnyben. Az én kompromisszumom: rövid cooldown deploymentenként, retry-költségvetés kliensenként, és semmi globális breaker, amely egyetlen zajos perc miatt egy egész funkciót lekapcsolhat.

Emeld a plafont, mielőtt beleütközöl

A legolcsóbb 429 az, amelyik meg sem történik. A legtöbb Claude-modellnél a cache-olvasás nem számít bele az ITPM-be, így a cache növeli a tényleges átviteli kapacitást: az Anthropic példájában egy 2 000 000-es ITPM-limit 80%-os cache-találati aránnyal percenként 10 000 000 bemeneti tokent dolgoz fel. A beállítást a prompt caching és modell-routing cikkben írtam le. További karok:

• Válaszd szét a terheléseket. Az Anthropic workspace-eknek saját, alacsonyabb limitjük lehet, így egy visszatöltés nem éheztetheti ki a chat-végpontot. Máshol külön kulcsok vagy projektek csinálják ugyanezt.
• Vidd le az offline munkát a szinkron API-ról. A batch-végpontoknak saját limitjük van, és nem fogyasztják a Messages API limitjeit.
• Olvasd a fejléceket. Az anthropic-ratelimit-*-remaining és az x-ratelimit-remaining-* segítségével a kliens maga fékezhet, mielőtt a szolgáltató tenné.
• Fokozatosan gyorsíts. A visszatöltéseket lassan indítsd, hogy elkerüld a gyorsulási limiteket, és védd a nyilvános végpontokat a visszaélésektől, lásd: denial of wallet.

Időtúllépések és hosszú kérések

Időkorlát nélkül a retry-szabály hiányos, mert egy beragadt kapcsolat sosem ad olyan hibát, amelyet újra lehetne próbálni. Az AWS azt javasolja, hogy az időkorlátot a függőség késleltetési percentiliseiből számold, ne találgass. LLM-hívásoknál ez külön keretet jelent az első tokenig eltelt időre és a teljes időtartamra. Az Anthropic a tíz percnél tovább futó kérésekhez streaminget vagy a Batches API-t javasolja, mert egyes hálózatok bontják a tétlen kapcsolatokat, és az SDK-k elutasítják azokat a nem streamelt kéréseket, amelyek várhatóan túllépnék a tízperces időkorlátot. Az AI SDK timeout objektumot fogad totalMs, stepMs és chunkMs mezőkkel, ami pontosan ezekre a keretekre illeszkedik.

Minden hibánál naplózd a request-id fejlécet. Ha az incidens a szolgáltatónál van, a supportjuk pontosan ezt az azonosítót kéri, és egy homályos „lassú volt az API” helyett követhető nyomot kapnak. Az újrapróbálásokat, a fallbackeket és a kiszolgáló modellt ugyanabba a trace-be írd, ahogy az LLM-ágensek megfigyelhetősége cikkben, így utólag látod, az incidens mekkora részét nyelte el a láncod.

Források

1. Claude Platform Docs: Rate limits
2. Claude Platform Docs: API errors
3. OpenAI API Docs: Rate limits
4. AWS Builders Library: Timeouts, retries and backoff with jitter
5. MDN: Retry-After header
6. Martin Fowler: Circuit Breaker (2014)
7. LiteLLM Docs: Router, retries and cooldowns
8. LiteLLM Docs: Proxy fallbacks and reliability
9. OpenRouter Docs: Model fallbacks
10. AI SDK Docs: Settings (maxRetries, timeout)