[{"data":1,"prerenderedAt":813},["ShallowReactive",2],{"blog-llm-rate-limits-retries-provider-fallback-hu":3},{"slug":4,"published":5,"minutes":6,"category":7,"tags":8,"keywords":14,"about":26,"sources":36,"cover":67,"og":68,"expertise":69,"locales":70,"lang":73,"title":74,"description":75,"coverAlt":76,"metaTitle":77,"takeaways":78,"faq":84,"toc":100,"blocks":131,"others":585},"llm-rate-limits-retries-provider-fallback","2026-10-17",10,"llmops",[9,10,11,12,13],"Rate limits","Retries","Fallback","Reliability","LLM gateway",[15,16,17,18,19,20,21,22,23,24,25],"llm rate limit handling","429 too many requests llm api","exponential backoff with jitter","anthropic 529 overloaded error","openai rate limit retry","llm provider fallback","litellm fallbacks","retry-after header","llm circuit breaker","multi provider llm failover","claude api rate limits",[27,30,33],{"name":28,"url":29},"Token bucket","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FToken_bucket",{"name":31,"url":32},"Exponential backoff","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FExponential_backoff",{"name":34,"url":35},"Circuit breaker design pattern","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FCircuit_breaker_design_pattern",[37,40,43,46,49,52,55,58,61,64],{"title":38,"url":39},"Claude Platform Docs: Rate limits","https:\u002F\u002Fplatform.claude.com\u002Fdocs\u002Fen\u002Fapi\u002Frate-limits",{"title":41,"url":42},"Claude Platform Docs: API errors","https:\u002F\u002Fplatform.claude.com\u002Fdocs\u002Fen\u002Fapi\u002Ferrors",{"title":44,"url":45},"OpenAI API Docs: Rate limits","https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Frate-limits",{"title":47,"url":48},"AWS Builders Library: Timeouts, retries and backoff with jitter","https:\u002F\u002Fbuilder.aws.com\u002Fcontent\u002F3EumjoZascWd1oZiEgL8ORlv3qE\u002Ftimeouts-retries-and-backoff-with-jitter",{"title":50,"url":51},"MDN: Retry-After header","https:\u002F\u002Fdeveloper.mozilla.org\u002Fen-US\u002Fdocs\u002FWeb\u002FHTTP\u002FReference\u002FHeaders\u002FRetry-After",{"title":53,"url":54},"Martin Fowler: Circuit Breaker (2014)","https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FCircuitBreaker.html",{"title":56,"url":57},"LiteLLM Docs: Router, retries and cooldowns","https:\u002F\u002Fdocs.litellm.ai\u002Fdocs\u002Frouting",{"title":59,"url":60},"LiteLLM Docs: Proxy fallbacks and reliability","https:\u002F\u002Fdocs.litellm.ai\u002Fdocs\u002Fproxy\u002Freliability",{"title":62,"url":63},"OpenRouter Docs: Model fallbacks","https:\u002F\u002Fopenrouter.ai\u002Fdocs\u002Fguides\u002Frouting\u002Fmodel-fallbacks",{"title":65,"url":66},"AI SDK Docs: Settings (maxRetries, timeout)","https:\u002F\u002Fai-sdk.dev\u002Fdocs\u002Fai-sdk-core\u002Fsettings","\u002Fimages\u002Fblog\u002Fllm-rate-limits-retries-provider-fallback\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fllm-rate-limits-retries-provider-fallback\u002Fog.jpg","ai-engineer",[71,72,73],"en","de","hu","LLM rate limitek élesben: újrapróbálás, backoff és szolgáltatóváltás","Hogyan működnek az LLM rate limitek, mit érdemes újrapróbálni, backoff jitterrel, retry egy rétegben, és fallback-láncok, amelyek nem rontják el a kimenetet.","Kis négyzetek kapaszkodnak három fokon egy széles téglalaphoz, mögötte még kettő sorban.","LLM rate limitek: retry és fallback · Balázs Csorba",[79,80,81,82,83],"A szolgáltatói limitek token bucketek, percenkénti kérésben és tokenben mérve, de rövidebb intervallumokon érvényesítve, ezért a löketek akkor is elbuknak, ha a percösszeg rendben lévőnek tűnik.","Újrapróbálás előtt osztályozd a hibát: a retry-afterrel érkező 429 és az 5xx átmeneti, a költéskeret miatti 429, a 400-asok és a hitelesítési hibák nem.","Exponenciális backoffot használj jitterrel, a retry-aftert tekintsd minimumnak, és korlátozd a próbálkozások számát és a teljes időt is.","Pontosan egy rétegben próbálj újra. Az SDK, a gateway és az alkalmazás retry-jai összeszorzódnak, és az AWS példája megmutatja, milyen gyorsan.","A fallback-modell egy másik termék: értékeld ki a saját tesztkészleteden, mielőtt éles forgalmat szolgálna ki.",[85,88,91,94,97],{"q":86,"a":87},"Mi a különbség a Claude API 429-es és 529-es hibája között?","A 429 rate_limit_error azt jelenti, hogy a szervezeted elérte valamelyik saját limitjét, például a percenkénti kérés- vagy tokenkeretet, vagy a havi költéskeretet. Az 529 overloaded_error azt jelenti, hogy az API átmenetileg minden felhasználó számára túlterhelt. Mindkettőnél általában megéri késleltetve újrapróbálni, kivéve a költéskeret miatti 429-et: ennek nincs retry-after fejléce, és addig bukik, amíg a hozzáférés vissza nem áll.",{"q":89,"a":90},"Hányszor érdemes újrapróbálni egy LLM-kérést?","Két-négy próbálkozás exponenciális backoffal a szokásos tartomány, és az Anthropic SDK és a Vercel AI SDK is alapból kétszer próbál újra. A számnál fontosabb a teljes eltelt idő korlátozása, hogy egy felhasználói kérés ne lógjon perceken át, és hogy a stackben csak egyetlen réteg próbáljon újra.",{"q":92,"a":93},"Beleszámít a max_tokens a rate limitbe?","Szolgáltatótól függ. Az Anthropic szerint a max_tokens nem számít bele a kimeneti tokenlimitbe, amely csak a ténylegesen generált tokeneket számolja. Az OpenAI a max_tokens és a becsült tokenszám maximumát számolja a limit ellen, vagyis a túlméretezett max_tokens elhasználja a mozgásteret.",{"q":95,"a":96},"LiteLLM, OpenRouter vagy saját kód a fallbackhez?","Ha már futtatsz gatewayt, ott konfiguráld a fallbacket, és máshol kapcsold ki az újrapróbálást. A LiteLLM hibatípusonkénti retry-szabályokat, cooldownokat és kontextusablak-fallbacket ad, saját hosztolással; az OpenRouter egy models tömböt ad egyetlen API-kulcs mögött. Egy-két szolgáltatóhoz elég a saját kód, de a végén újraírod a cooldownokat.",{"q":98,"a":99},"Biztonságos-e más szolgáltatóra váltani strukturált kimenetnél?","Csak ha tesztelted. A szolgáltatók eltérnek abban, hogyan kényszerítik ki a JSON Schemát, milyen funkciókat támogatnak és hogyan fogalmazzák meg az elutasítást. Futtasd le ugyanazt az értékelőkészletet a fallback-modellen, és minden választ validálj a sémád ellen, akármelyik modell állította elő.",[101,104,107,110,113,116,119,122,125,128],{"id":102,"title":103},"how-limits-work","Hogyan működnek valójában a szolgáltatói rate limitek",{"id":105,"title":106},"classify-errors","Osztályozd a hibát, mielőtt újrapróbálod",{"id":108,"title":109},"backoff-jitter","Exponenciális backoff jitterrel és határidővel",{"id":111,"title":112},"retry-one-layer","Újrapróbálás pontosan egy rétegben",{"id":114,"title":115},"fallback-chain","Fallback-lánc építése",{"id":117,"title":118},"fallback-pitfalls","Miért változtatja meg csendben a fallback a termékedet",{"id":120,"title":121},"circuit-breakers","Cooldownok és circuit breakerek",{"id":123,"title":124},"raise-the-ceiling","Emeld a plafont, mielőtt beleütközöl",{"id":126,"title":127},"timeouts-streaming","Időtúllépések és hosszú kérések",{"id":129,"title":130},"sources","Források",[132,136,139,142,145,156,218,221,222,225,284,305,308,309,315,317,320,321,335,363,364,367,376,413,415,416,419,461,462,473,476,477,485,519,520,538,550,551],{"type":133,"content":134},"paragraph",[135],"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.",{"type":133,"content":137},[138],"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.",{"type":140,"level":141,"id":102,"text":103},"heading",2,{"type":133,"content":143},[144],"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.",{"type":133,"content":146},[147,148,152,153,155],"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 ",{"tag":149,"children":150},"code",[151],"max_tokens"," és a becsült kérésméret maximumával számol a tokenlimit ellen, vagyis a bőkezű ",{"tag":149,"children":154},[151]," 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.",{"type":157,"head":158,"rows":165},"table",[159,161,163],[160],"Szempont",[162],"Anthropic Claude API",[164],"OpenAI API",[166,173,180,186,204,211],[167,169,171],[168],"Dimenziók",[170],"RPM, ITPM, OTPM",[172],"RPM, RPD, TPM, TPD, IPM",[174,176,178],[175],"Cache-elt bemenet",[177],"A cache-olvasás a legtöbb modellnél nem számít bele az ITPM-be",[179],"Beleszámít a TPM-be",[181,182,184],[151],[183],"Nem számít; az OTPM a generált tokeneket nézi",[185],"max(max_tokens, becslés) számít",[187,189,197],[188],"Fejlécek",[190,193,194],{"tag":149,"children":191},[192],"anthropic-ratelimit-*",", ",{"tag":149,"children":195},[196],"retry-after",[198,193,201],{"tag":149,"children":199},[200],"x-ratelimit-*",{"tag":149,"children":202},[203],"Retry-After",[205,207,209],[206],"Retry-After érkezik",[208],"A legtöbb 429-nél, a költéskeret-429-nél nem",[210],"429-es és 503-as válaszoknál",[212,214,216],[213],"Löketvédelem",[215],"Gyorsulási limitek hirtelen növekedésnél",[217],"Rövidebb érvényesítési ablakok",{"type":133,"content":219},[220],"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.",{"type":140,"level":141,"id":105,"text":106},{"type":133,"content":223},[224],"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:",{"type":157,"head":226,"rows":233},[227,229,231],[228],"Válasz",[230],"Jelentés",[232],"Teendő",[234,243,253,267,277],[235,239,241],[236,237],"429 + ",{"tag":149,"children":238},[196],[240],"Elértél egy rate limitet",[242],"Várj legalább retry-afternyit, aztán próbáld újra",[244,249,251],[245,246],"429 retry-after nélkül, ",{"tag":149,"children":247},[248],"enforced_spend_limit_reached",[250],"Elérted a szint havi költéskeretét",[252],"Ne próbáld újra; riassz embert vagy válts",[254,263,265],[255,256,259,260],"500 ",{"tag":149,"children":257},[258],"api_error",", 529 ",{"tag":149,"children":261},[262],"overloaded_error",[264],"Átmeneti szerveroldali hiba",[266],"Várj, próbáld újra, aztán fallback",[268,273,275],[269,270],"504 ",{"tag":149,"children":271},[272],"timeout_error",[274],"Feldolgozás közben lejárt az idő",[276],"Egyszer próbáld újra; a hosszú kéréseket streameld",[278,280,282],[279],"400, 401, 403, 404, 413",[281],"Maga a kérés hibás, vagy saját költéskorlát (400)",[283],"Változatlanul soha; naplózd és javítsd",{"type":285,"variant":286,"title":287,"body":288},"callout","warn","Nem minden 429 átmeneti",[289],[290,291,294,295,297,298,301,302,304],"Amikor egy Anthropic-szervezet eléri a szintje költéskeretét, az API 429-et ad ",{"tag":149,"children":292},[293],"rate_limit_error"," hibatípussal, ",{"tag":149,"children":296},[196]," fejléc nélkül, és az ",{"tag":149,"children":299},[300],"error.details.error_code"," értéke ",{"tag":149,"children":303},[248],". A használat a következő hónap első napján 00:00 UTC-ig szünetel. Egy általános retry-ciklus, az SDK alapértelmezettje is, tovább ostromolja a falat. Ismerd fel ezt a kódot, állítsd le az újrapróbálást, és riassz valakit.",{"type":133,"content":306},[307],"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.",{"type":140,"level":141,"id":108,"text":109},{"type":133,"content":310},[311,312,314],"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 ",{"tag":149,"children":313},[203]," minimum, nem javaslat. A HTTP-szemantika szerint a fejléc vagy másodperceket, vagy HTTP-dátumot tartalmaz, ezért mindkettőt kezeld.",{"type":149,"code":316},"\u002F\u002F One retry wrapper for the whole app. Turn SDK retries off (maxRetries: 0) when you use it.\nconst RETRYABLE = new Set([408, 429, 500, 502, 503, 504, 529])\n\nfunction retryAfterMs(h: Headers): number | null {\n  const v = h.get('retry-after')\n  if (!v) return null\n  const s = Number(v)\n  if (!Number.isNaN(s)) return s * 1000\n  const t = Date.parse(v)              \u002F\u002F HTTP-date form\n  return Number.isNaN(t) ? null : Math.max(0, t - Date.now())\n}\n\nexport async function withRetry\u003CT>(call: () => Promise\u003CResponse>, parse: (r: Response) => Promise\u003CT>,\n  { attempts = 4, baseMs = 500, capMs = 20_000, deadlineMs = 45_000 } = {}): Promise\u003CT> {\n  const start = Date.now()\n  for (let i = 0; ; i++) {\n    const res = await call()\n    if (res.ok) return parse(res)\n    const body = await res.clone().json().catch(() => ({}))\n    const spendCap = body?.error?.details?.error_code === 'enforced_spend_limit_reached'\n    if (!RETRYABLE.has(res.status) || spendCap || i + 1 >= attempts) throw new Error(`LLM ${res.status}`)\n    const backoff = Math.random() * Math.min(capMs, baseMs * 2 ** i)   \u002F\u002F \"full jitter\"\n    const wait = Math.max(retryAfterMs(res.headers) ?? 0, backoff)\n    if (Date.now() - start + wait > deadlineMs) throw new Error(`LLM ${res.status}: retry budget spent`)\n    await new Promise((r) => setTimeout(r, wait))\n  }\n}",{"type":133,"content":318},[319],"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.",{"type":140,"level":141,"id":111,"text":112},{"type":133,"content":322},[323,324,326,327,330,331,334],"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 ",{"tag":149,"children":325},[196],"-t. A Vercel AI SDK-ban a ",{"tag":149,"children":328},[329],"maxRetries"," alapértéke 2. Egy gatewaynek, például a LiteLLM-nek, ",{"tag":149,"children":332},[333],"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.",{"type":336,"items":337},"list",[338,344,353,358],[339,343],{"tag":340,"children":341},"strong",[342],"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.",[345,348,349,352],{"tag":340,"children":346},[347],"Mindenhol máshol állítsd nullára az újrapróbálást."," ",{"tag":149,"children":350},[351],"maxRetries: 0"," az SDK-kliensben, semmi ciklus a route handlerekben.",[354,357],{"tag":340,"children":355},[356],"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.",[359,362],{"tag":340,"children":360},[361],"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.",{"type":140,"level":141,"id":114,"text":115},{"type":133,"content":365},[366],"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).",{"type":368,"attrs":369,"inner":373,"caption":374},"diagram",{"viewBox":370,"role":371,"aria-labelledby":372},"0 0 720 170","img","rlf1-t rlf1-d","\u003Ctitle id=\"rlf1-t\">Fallback-lánc a kimenet változásának mértéke szerint\u003C\u002Ftitle>\u003Cdesc id=\"rlf1-d\">Egy kérés először backoffal újrapróbál, aztán ugyanarra a modellre vált egy másik deploymenten, majd egy testvérmodellre, aztán egy másik szolgáltatóra, végül kontrolláltan visszalép.\u003C\u002Fdesc>\u003Cdefs>\u003Cmarker id=\"rlf1-ah\" viewBox=\"0 0 10 10\" refX=\"9\" refY=\"5\" markerWidth=\"7\" markerHeight=\"7\" orient=\"auto-start-reverse\">\u003Cpath d=\"M0 0L10 5L0 10z\" class=\"d-head\" \u002F>\u003C\u002Fmarker>\u003C\u002Fdefs>\u003Crect x=\"20\" y=\"47\" width=\"118\" height=\"76\" rx=\"10\" class=\"d-box\" \u002F>\u003Ctext x=\"79\" y=\"81\" text-anchor=\"middle\" class=\"d-text\">Retry\u003C\u002Ftext>\u003Ctext x=\"79\" y=\"103\" text-anchor=\"middle\" class=\"d-small\">backoff + jitter\u003C\u002Ftext>\u003Cpath d=\"M138 85H158\" class=\"d-line\" marker-end=\"url(#rlf1-ah)\" \u002F>\u003Crect x=\"160\" y=\"47\" width=\"118\" height=\"76\" rx=\"10\" class=\"d-mint\" \u002F>\u003Ctext x=\"220\" y=\"81\" text-anchor=\"middle\" class=\"d-text\">Ugyanaz a modell\u003C\u002Ftext>\u003Ctext x=\"220\" y=\"103\" text-anchor=\"middle\" class=\"d-small\">másik régió\u003C\u002Ftext>\u003Cpath d=\"M279 85H299\" class=\"d-line\" marker-end=\"url(#rlf1-ah)\" \u002F>\u003Crect x=\"301\" y=\"47\" width=\"118\" height=\"76\" rx=\"10\" class=\"d-sky\" \u002F>\u003Ctext x=\"360\" y=\"81\" text-anchor=\"middle\" class=\"d-text\">Testvérmodell\u003C\u002Ftext>\u003Ctext x=\"360\" y=\"103\" text-anchor=\"middle\" class=\"d-small\">azonos szolgáltató\u003C\u002Ftext>\u003Cpath d=\"M419 85H439\" class=\"d-line\" marker-end=\"url(#rlf1-ah)\" \u002F>\u003Crect x=\"441\" y=\"47\" width=\"118\" height=\"76\" rx=\"10\" class=\"d-gold\" \u002F>\u003Ctext x=\"500\" y=\"81\" text-anchor=\"middle\" class=\"d-text\">Más szolgáltató\u003C\u002Ftext>\u003Ctext x=\"500\" y=\"103\" text-anchor=\"middle\" class=\"d-small\">előre kiértékelve\u003C\u002Ftext>\u003Cpath d=\"M560 85H580\" class=\"d-line\" marker-end=\"url(#rlf1-ah)\" \u002F>\u003Crect x=\"582\" y=\"47\" width=\"118\" height=\"76\" rx=\"10\" class=\"d-box\" \u002F>\u003Ctext x=\"641\" y=\"81\" text-anchor=\"middle\" class=\"d-text\">Visszalépés\u003C\u002Ftext>\u003Ctext x=\"641\" y=\"103\" text-anchor=\"middle\" class=\"d-small\">őszinte hiba\u003C\u002Ftext>",[375],"Minél jobbra köt ki egy kérés, annál jobban eltérhet a kimenete attól, amit teszteltél.",{"type":133,"content":377},[378,379,384,385,388,389,392,393,395,396,399,400,403,404,408,409,412],"Ritkán kell magadnak megírnod. A ",{"tag":380,"to":381,"children":382},"link","\u002Ftools\u002Flitellm",[383],"LiteLLM"," a ",{"tag":149,"children":386},[387],"router_settings"," alatt egy ",{"tag":149,"children":390},[391],"fallbacks"," listát vár, amely egy modellcsoporthoz rendezett tartalékokat rendel, és ",{"tag":149,"children":394},[333]," próbálkozás után lép életbe. Van ",{"tag":149,"children":397},[398],"context_window_fallbacks"," is a túl hosszú promptokhoz és ",{"tag":149,"children":401},[402],"content_policy_fallbacks"," a szolgáltatói szűrő általi elutasításokhoz. Az ",{"tag":380,"to":405,"children":406},"\u002Ftools\u002Fopenrouter",[407],"OpenRouter"," prioritási sorrendben vár egy ",{"tag":149,"children":410},[411],"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.",{"type":149,"code":414},"# LiteLLM proxy: retries live here, nowhere else\nrouter_settings:\n  num_retries: 2\n  allowed_fails: 3        # failures per minute before a deployment cools down\n  cooldown_time: 30       # seconds the deployment is skipped\n  retry_policy:\n    RateLimitErrorRetries: 3\n    BadRequestErrorRetries: 0\n    AuthenticationErrorRetries: 0\n    DefaultRetries: 2\n  fallbacks: [{\"support-primary\": [\"support-secondary\"]}]\n  enable_pre_call_checks: true   # needed for context-window fallbacks to check input size",{"type":140,"level":141,"id":117,"text":118},{"type":133,"content":417},[418],"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.",{"type":336,"items":420},[421,431,436,446,451],[422,425,426,430],{"tag":340,"children":423},[424],"É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 ",{"tag":380,"to":427,"children":428},"\u002Fblog\u002Fllm-model-migration-regression-testing",[429],"LLM-modellmigrációk regresszió nélkül"," cikkben leírtam.",[432,435],{"tag":340,"children":433},[434],"Tarts modellenként külön promptot."," Egy fallback-bejegyzés modell, prompt és paraméterek együtt, nem csak egy modellnév.",[437,440,441,445],{"tag":340,"children":438},[439],"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 ",{"tag":380,"to":442,"children":443},"\u002Fblog\u002Fstructured-outputs-json-schema-llm",[444],"strukturált kimenetek"," ezt nem teszik feleslegessé.",[447,450],{"tag":340,"children":448},[449],"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á.",[452,455,456,460],{"tag":340,"children":453},[454],"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: ",{"tag":380,"to":457,"children":458},"\u002Fblog\u002Fgdpr-llm-api-eu-data-residency",[459],"GDPR és LLM-adatrezidencia",".",{"type":140,"level":141,"id":120,"text":121},{"type":133,"content":463},[464,465,468,469,472],"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 ",{"tag":149,"children":466},[467],"allowed_fails"," hiba történik (alapból 3), a deployment ",{"tag":149,"children":470},[471],"cooldown_time"," másodpercre (alapból 5) kimarad, és a forgalom a többihez megy.",{"type":133,"content":474},[475],"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.",{"type":140,"level":141,"id":123,"text":124},{"type":133,"content":478},[479,480,484],"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 ",{"tag":380,"to":481,"children":482},"\u002Fblog\u002Fllm-cost-latency-prompt-caching-routing",[483],"prompt caching és modell-routing"," cikkben írtam le. További karok:",{"type":336,"items":486},[487,492,497,510],[488,491],{"tag":340,"children":489},[490],"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.",[493,496],{"tag":340,"children":494},[495],"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.",[498,501,502,505,506,509],{"tag":340,"children":499},[500],"Olvasd a fejléceket."," Az ",{"tag":149,"children":503},[504],"anthropic-ratelimit-*-remaining"," és az ",{"tag":149,"children":507},[508],"x-ratelimit-remaining-*"," segítségével a kliens maga fékezhet, mielőtt a szolgáltató tenné.",[511,514,515,460],{"tag":340,"children":512},[513],"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: ",{"tag":380,"to":516,"children":517},"\u002Fblog\u002Fllm-endpoint-abuse-denial-of-wallet",[518],"denial of wallet",{"type":140,"level":141,"id":126,"text":127},{"type":133,"content":521},[522,523,526,527,193,530,533,534,537],"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 ",{"tag":149,"children":524},[525],"timeout"," objektumot fogad ",{"tag":149,"children":528},[529],"totalMs",{"tag":149,"children":531},[532],"stepMs"," és ",{"tag":149,"children":535},[536],"chunkMs"," mezőkkel, ami pontosan ezekre a keretekre illeszkedik.",{"type":133,"content":539},[540,541,544,545,549],"Minden hibánál naplózd a ",{"tag":149,"children":542},[543],"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 ",{"tag":380,"to":546,"children":547},"\u002Fblog\u002Fagent-observability-opentelemetry",[548],"LLM-ágensek megfigyelhetősége"," cikkben, így utólag látod, az incidens mekkora részét nyelte el a láncod.",{"type":140,"level":141,"id":129,"text":130},{"type":336,"ordered":552,"items":553},true,[554,558,561,564,567,570,573,576,579,582],[555],{"tag":556,"href":39,"children":557},"a",[38],[559],{"tag":556,"href":42,"children":560},[41],[562],{"tag":556,"href":45,"children":563},[44],[565],{"tag":556,"href":48,"children":566},[47],[568],{"tag":556,"href":51,"children":569},[50],[571],{"tag":556,"href":54,"children":572},[53],[574],{"tag":556,"href":57,"children":575},[56],[577],{"tag":556,"href":60,"children":578},[59],[580],{"tag":556,"href":63,"children":581},[62],[583],{"tag":556,"href":66,"children":584},[65],[586,647,703,756],{"slug":587,"published":5,"minutes":588,"category":7,"tags":589,"keywords":595,"about":606,"sources":616,"cover":641,"og":642,"expertise":69,"locales":643,"lang":73,"title":644,"description":645,"coverAlt":646},"prompt-versioning-management",8,[590,591,592,593,594],"Prompt management","Versioning","LLMOps","Evals","Langfuse",[596,597,598,599,600,601,602,603,604,605],"prompt versioning","prompt management","prompt registry","version control for prompts","langfuse prompt management","mlflow prompt registry","prompts in git","openai prompt object deprecation","prompt rollback production","prompt ci evaluation",[607,610,613],{"name":608,"url":609},"Prompt engineering","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FPrompt_engineering",{"name":611,"url":612},"Version control","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FVersion_control",{"name":614,"url":615},"Continuous integration","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FContinuous_integration",[617,620,623,626,629,632,635,638],{"title":618,"url":619},"OpenAI API Docs: Migrate from prompt objects","https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Fprompting\u002Fmigrate-from-prompt-object",{"title":621,"url":622},"OpenAI API Docs: Prompt engineering (reusable prompts deprecation note)","https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Fprompt-engineering",{"title":624,"url":625},"Langfuse Docs: Prompt version control","https:\u002F\u002Flangfuse.com\u002Fdocs\u002Fprompt-management\u002Ffeatures\u002Fprompt-version-control",{"title":627,"url":628},"Langfuse Docs: Prompt caching in the SDKs","https:\u002F\u002Flangfuse.com\u002Fdocs\u002Fprompt-management\u002Ffeatures\u002Fcaching",{"title":630,"url":631},"Langfuse Docs: Link prompts to traces","https:\u002F\u002Flangfuse.com\u002Fdocs\u002Fprompt-management\u002Ffeatures\u002Flink-to-traces",{"title":633,"url":634},"MLflow Docs: Prompt Registry","https:\u002F\u002Fmlflow.org\u002Fdocs\u002Flatest\u002Fgenai\u002Fprompt-registry\u002F",{"title":636,"url":637},"Promptfoo Docs: GitHub Action","https:\u002F\u002Fwww.promptfoo.dev\u002Fdocs\u002Fintegrations\u002Fgithub-action\u002F",{"title":639,"url":640},"Claude Platform Docs: Prompt caching","https:\u002F\u002Fplatform.claude.com\u002Fdocs\u002Fen\u002Fbuild-with-claude\u002Fprompt-caching","\u002Fimages\u002Fblog\u002Fprompt-versioning-management\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fprompt-versioning-management\u002Fog.jpg",[71,72,73],"Promptverziózás élesben: git, registry, címkék és visszaállítás","Promptok verziózása élesben: mi tartozik egy verzióhoz, git vagy prompt registry, címkék és visszaállítás, eval-kapu a CI-ban és a cache-re gyakorolt hatás.","Öt álló kártya sorban, a harmadik íves nyíllal visszafordul, a kapu az utolsó előtt áll.",{"slug":648,"published":5,"minutes":649,"category":7,"tags":650,"keywords":655,"about":666,"sources":676,"cover":697,"og":698,"expertise":69,"locales":699,"lang":73,"title":700,"description":701,"coverAlt":702},"llm-batch-api-offline-workloads",9,[651,652,592,653,654],"Batch API","Cost","Prompt caching","Data pipelines",[656,657,658,659,660,661,662,663,664,665],"llm batch api","anthropic message batches api","openai batch api","gemini batch mode","batch inference llm cost","batch api 50 percent discount","openai flex processing","bedrock batch inference","llm offline processing","batch api prompt caching",[667,670,673],{"name":668,"url":669},"Batch processing","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FBatch_processing",{"name":671,"url":672},"JSON Lines","https:\u002F\u002Fjsonlines.org\u002F",{"name":674,"url":675},"Large language model","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FLarge_language_model",[677,680,682,683,686,689,691,694],{"title":678,"url":679},"Claude Platform Docs: Batch processing","https:\u002F\u002Fplatform.claude.com\u002Fdocs\u002Fen\u002Fbuild-with-claude\u002Fbatch-processing",{"title":681,"url":39},"Claude Platform Docs: Rate limits (Message Batches API)",{"title":639,"url":640},{"title":684,"url":685},"OpenAI API Docs: Batch API","https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Fbatch",{"title":687,"url":688},"OpenAI API Docs: Flex processing","https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Fflex-processing",{"title":690,"url":45},"OpenAI API Docs: Rate limits (batch queue limits)",{"title":692,"url":693},"Google AI for Developers: Gemini Batch API","https:\u002F\u002Fai.google.dev\u002Fgemini-api\u002Fdocs\u002Fbatch-api",{"title":695,"url":696},"Amazon Bedrock User Guide: Batch inference","https:\u002F\u002Fdocs.aws.amazon.com\u002Fbedrock\u002Flatest\u002Fuserguide\u002Fbatch-inference.html","\u002Fimages\u002Fblog\u002Fllm-batch-api-offline-workloads\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fllm-batch-api-offline-workloads\u002Fog.jpg",[71,72,73],"LLM batch API-k: félárú inferencia olyan munkára, amely várhat","Mikor érdemes az Anthropic, OpenAI és Gemini batch API-ját használni, hogyan működnek a limitek, a párosítás és a hibák, és hogyan adódnak össze a kedvezmények.","Széles doboz nyolc kis négyzettel, balról érkeznek, egy hosszú nyíl visszatér.",{"slug":704,"published":705,"minutes":649,"category":7,"tags":706,"keywords":712,"about":724,"sources":731,"cover":750,"og":751,"expertise":69,"locales":752,"lang":73,"title":753,"description":754,"coverAlt":755},"structured-outputs-json-schema-llm","2026-10-16",[707,708,709,710,711],"Structured outputs","JSON Schema","Constrained decoding","LLM APIs","Validation",[713,714,715,716,717,718,719,720,721,722,723],"structured outputs LLM","JSON schema LLM output","OpenAI structured outputs strict mode","Claude structured outputs","Gemini structured output","constrained decoding","JSON mode vs structured outputs","validate LLM JSON output","Zod structured output","Pydantic LLM output","vLLM structured outputs",[725,728,730],{"name":726,"url":727},"JSON","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FJSON",{"name":708,"url":729},"https:\u002F\u002Fjson-schema.org\u002F",{"name":674,"url":675},[732,735,738,741,744,747],{"title":733,"url":734},"OpenAI API docs: Structured model outputs","https:\u002F\u002Fplatform.openai.com\u002Fdocs\u002Fguides\u002Fstructured-outputs",{"title":736,"url":737},"Claude API docs: Structured outputs","https:\u002F\u002Fplatform.claude.com\u002Fdocs\u002Fen\u002Fbuild-with-claude\u002Fstructured-outputs",{"title":739,"url":740},"Gemini API docs: Structured outputs","https:\u002F\u002Fai.google.dev\u002Fgemini-api\u002Fdocs\u002Fstructured-output",{"title":742,"url":743},"vLLM docs: Structured Outputs","https:\u002F\u002Fdocs.vllm.ai\u002Fen\u002Flatest\u002Ffeatures\u002Fstructured_outputs.html",{"title":745,"url":746},"Tam et al.: Let Me Speak Freely? A Study on the Impact of Format Restrictions on Performance of LLMs (2024)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2408.02442",{"title":748,"url":749},"Geng et al.: JSONSchemaBench: A Rigorous Benchmark of Structured Outputs for Language Models (2025)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2501.10868","\u002Fimages\u002Fblog\u002Fstructured-outputs-json-schema-llm\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fstructured-outputs-json-schema-llm\u002Fog.jpg",[71,72,73],"Strukturált kimenet JSON Schemával: mit fed le a garancia, és mit nem","Hogyan működik a strukturált kimenet és a korlátozott dekódolás az OpenAI, Claude, Gemini és vLLM esetén, mely sémaszabályok számítanak, és mit validálj.","Négy rekeszes merev keret, három blokk a helyén, egy túl széles fölötte lebeg.",{"slug":757,"published":705,"minutes":649,"category":7,"tags":758,"keywords":764,"about":777,"sources":785,"cover":807,"og":808,"expertise":69,"locales":809,"lang":73,"title":810,"description":811,"coverAlt":812},"evaluating-ai-agents-trajectories",[759,760,761,762,763],"Agent evals","Trajectories","Tool calling","pass^k","LLM-as-judge",[765,766,767,768,769,770,771,772,773,774,775,776],"evaluating AI agents","agent trajectory evaluation","agent evals","tool call accuracy","trajectory match evaluator","pass^k metric","tau-bench","LLM as a judge for agents","agent regression testing","outcome vs trajectory evaluation","agentevals","tool correctness metric",[778,781,784],{"name":779,"url":780},"Intelligent agent","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FIntelligent_agent",{"name":782,"url":783},"Software testing","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FSoftware_testing",{"name":674,"url":675},[786,789,792,795,798,801,804],{"title":787,"url":788},"Anthropic: Demystifying evals for AI agents (Jan 2026)","https:\u002F\u002Fwww.anthropic.com\u002Fengineering\u002Fdemystifying-evals-for-ai-agents",{"title":790,"url":791},"Yao et al.: τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (2024)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2406.12045",{"title":793,"url":794},"Barres et al.: τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment (2025)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2506.07982",{"title":796,"url":797},"LangChain: agentevals (GitHub)","https:\u002F\u002Fgithub.com\u002Flangchain-ai\u002Fagentevals",{"title":799,"url":800},"DeepEval docs: Tool Correctness","https:\u002F\u002Fdeepeval.com\u002Fdocs\u002Fmetrics-tool-correctness",{"title":802,"url":803},"Ragas docs: Agentic or tool use metrics","https:\u002F\u002Fdocs.ragas.io\u002Fen\u002Fstable\u002Fconcepts\u002Fmetrics\u002Favailable_metrics\u002Fagents\u002F",{"title":805,"url":806},"OpenAI API docs: Trace grading","https:\u002F\u002Fplatform.openai.com\u002Fdocs\u002Fguides\u002Ftrace-grading","\u002Fimages\u002Fblog\u002Fevaluating-ai-agents-trajectories\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fevaluating-ai-agents-trajectories\u002Fog.jpg",[71,72,73],"MI-ügynökök értékelése: trajektóriák, eredmények és megbízhatóság pontozása","Hogyan értékeld az MI-ügynököket: eredmény- és trajektória-értékelők, egyeztetési módok, pass^k, izolált környezet és megbízható LLM-bírák.","Két pontozott körút két négyzet között, széles kapocs keretezi a kanyargós utat.",1792222774272]