LLM batch API-k: félárú inferencia olyan munkára, amely várhat

Az LLM-költés meglepően nagy része sosem ér el felhasználót. Egy support-archívum újraosztályozása taxonómiaváltás után, termékleírások írása egy katalógusimporthoz, egy éjszakai eval-csomag futtatása, dokumentumok újraembeddelése modellváltás után: egyiknek sem kell két másodpercen belül válasz, mégis sok csapat ugyanazon a szinkron végponton küldi át őket, mint a chat-funkcióját, teljes áron, és ugyanazokért a rate limitekért versenyezve.

A batch API-k pontosan erre a munkára valók. Sok kérést küldesz be egyszerre, a szolgáltató akkor dolgozza fel őket, amikor van kapacitása, te pedig 24 órán belül, félárón átveszed az eredményfájlt. Ez az útmutató összeveti az Anthropic, az OpenAI, a Gemini és a Bedrock kínálatát, aztán sorra veszi, mi változik a kódodban: az eredmények párosítása, a részleges hibák, a cache, a limitek, az adatmegőrzés, és az, hogy mikor egyszerűbb az OpenAI flex szintje.

Milyen terhelés való batchbe

A próba egyszerű: észrevenné bárki, ha az eredmény most helyett holnap reggel érkezne? Az Anthropic saját felhasználási listája: nagy léptékű értékelések, tartalommoderálás, adatelemzés és tömeges tartalomgyártás, például termékleírások. Jellemző jelöltek az általam vitt projektekben:

• Katalógusbővítés. Leírások, attribútumkinyerés és fordítások több ezer cikkszámhoz egy PIM-import után, lásd: Pimcore ERP delta-szinkron.
• Eval-futások. Regressziós csomagok promptverziónként több száz esettel, ahol elég egy óra múlva az eredmény; lásd: LLM-evalok termékfunkciókhoz.
• Visszatöltések. Régi jegyek, rendelések vagy dokumentumok osztályozása vagy összefoglalása egy séma- vagy taxonómiaváltás után.
• Embeddingek és moderálás. Az OpenAI batchei lefedik a /v1/embeddings és /v1/moderations végpontot; a Gemininek külön batch-embedding hívása van.

Ami nem illik bele: bármi, amire felhasználó vár, és azok az ágensciklusok, amelyek eszközei a saját kódodban futnak. Minden batch-kérés egyetlen modellforduló, így egy kliensoldali eszközt hívó ágensnek minden lépéshez új kérés kell. A szerveroldali eszközök mások: a Claude API-nál a webes keresés, a web fetch és a kódfuttatás a batch-workerben fut, amely fordulónként több ciklusiterációt végez, mint egy szinkron hívás, mielőtt megállna.

Anthropic, OpenAI, Gemini és Bedrock összevetve

Néhány megkötés könnyen elkerüli a figyelmet. Egy OpenAI-bemeneti fájl csak egy modellt célozhat. A Converse formátumot használó Bedrock batch-feladatok nem tudnak eszközt hívni; ehhez InvokeModel formátum kell az adott modell natív kéréstörzsével. A Claude API pedig batchen belül elutasítja a stream-et, a fast mode speed paraméterét és a max_tokens: 0 értéket; szinte minden más, a képek, az eszközhasználat és a legtöbb béta funkció is működik.

Egy batch életciklusa

A Claude API-nál egy új batch processing_status értéke in_progress, és ended lesz, amikor minden kérés befejeződött; az eredmények akkor tölthetők le, amikor minden üzenet elkészült, vagy 24 óra után, amelyik előbb bekövetkezik. Az OpenAI-nak több állapota van: validating, failed, ha a bemeneti fájl érvénytelen, in_progress, finalizing, completed, expired, cancelling és cancelled. A Gemini JOB_STATE_* értékeket használ a pendingtől az expiredig. A Bedrock lekérdezés helyett EventBridge-en keresztül is értesíthet.

Párosítható és újrapróbálható kérések összeállítása

Az Anthropic és az OpenAI is kimondja, hogy az eredmények nem feltétlenül a bemeneti sorrendben érkeznek, és azt tanácsolja, hogy custom_id alapján párosíts. Ezt az azonosítót tedd determinisztikussá: a forrásrekordból és a promptverzióból képezd, hogy egy újrafuttatás ugyanazt az azonosítót adja, és az író folyamat upsertelhessen duplikálás helyett. A Claude API-nál illeszkednie kell a ^[a-zA-Z0-9_-]{1,64}$ mintára, így a perjelet vagy pontot tartalmazó nyers cikkszámok kiesnek.

import hashlib, time, anthropic

client = anthropic.Anthropic()
PROMPT_VERSION = "desc-v7"

def cid(sku: str) -> str:   # deterministic, safe characters, <= 64 chars
    return f"{PROMPT_VERSION}-{hashlib.sha1(sku.encode()).hexdigest()[:20]}"

requests = [{
    "custom_id": cid(p["sku"]),
    "params": {
        "model": "claude-sonnet-5-5",
        "max_tokens": 800,
        "system": [{"type": "text", "text": STYLE_GUIDE,             # identical in every request
                    "cache_control": {"type": "ephemeral", "ttl": "1h"}}],
        "messages": [{"role": "user", "content": render_product(p)}],
    },
} for p in products]

batch = client.messages.batches.create(requests=requests)
while client.messages.batches.retrieve(batch.id).processing_status != "ended":
    time.sleep(60)

retry = []
for r in client.messages.batches.results(batch.id):
    if r.result.type == "succeeded":
        upsert_description(r.custom_id, r.result.message)   # idempotent write
    else:                                                    # errored, canceled, expired
        retry.append(r.custom_id)

A Claude API-nál a kérések params részének validálása aszinkron, így egy mező elírása csak akkor derül ki, amikor az egész batch véget ért. Az Anthropic azt tanácsolja, hogy egy kérésformát előbb próbálj ki a szinkron Messages API-n. Én ezt ugyanabban a szkriptben csinálom: az első kérést szinkron küldöm el, a választ ellenőrzöm a sémán, aztán beküldöm a többit.

Részleges hibák, és miért fizetsz

Egy batch sosem egyszerűen sikerül vagy bukik el. A Claude API-nál minden kérés succeeded, errored, canceled vagy expired állapotban végződik, és csak az elsőért kell fizetni. A lejárat nem elméleti: az Anthropic jelzi, hogy a feldolgozás a kereslettől és a saját kérésmennyiségedtől függően lelassulhat, ilyenkor több kérés jár le 24 óra után. Az OpenAI a sikeres válaszokat kimeneti fájlba, a hibákat hibafájlba írja; ha egy batch lejár, az elkészült kérések elérhetők maradnak és számlázódnak, a többi batch_expired kóddal jelenik meg.

• Válaszd szét a hibaosztályokat. A validációs hibákhoz kódjavítás kell; a szerverhibák és a lejártak változatlanul mennek a következő batchbe.
• Korlátozd az újrapróbálási köröket. Két-három újraküldés, utána tedd félre a rekordokat emberi átnézésre.
• A tartalmat is ellenőrizd, ne csak az állapotot. Egy sikeres kérés is elérheti a max_tokens határt, vagy adhat a sémán elbukó JSON-t, lásd: strukturált kimenetek.
• A nagyon nagy feladatokat bontsd szét. Az Anthropic azt javasolja, hogy a nagy adatkészleteket több batchre oszd; így a haladás és a költség is darabonként látható.

A batch- és a prompt caching-kedvezmény összeadása

A batch-feladatok többnyire ugyanazokat a hosszú utasításokat alkalmazzák sok rekordra, ami a prompt caching ideális formája. Az Anthropic kimondja, hogy a cache és a batch kedvezménye összeadódik. A csapda az, hogy a batch-kérések párhuzamosan és tetszőleges sorrendben futnak, így a cache-találat best effort; az Anthropic a forgalmi mintától függően 30% és 98% közötti jellemző találati arányt említ. A tanács az, hogy minden kérésbe azonos cache_control blokkot tegyél, és mivel egy batch tovább futhat az ötperces cache-élettartamnál, fontold meg az egyórás cache-t. A Gemini is támogatja a context cachinget batch-kéréseknél, a szokásos cache-díjakon.

Mielőtt építenél rá, számolj. Az egyórás cache írása az alap bemeneti ár kétszerese az 1,25-szörös helyett, így csak akkor térül meg, ha a közös előtag hosszú, és a batch elég nagy ahhoz, hogy sokszor olvassa. Magáról a cache működéséről lásd: prompt caching és modell-routing.

Limitek, átviteli kapacitás és költés

A batch-forgalomnak mindkét platformon saját limitjei vannak, és ez a lényeg fele. Az Anthropic szerint a Batches API használata nem érinti a Messages API rate limitjeit; helyette a batch-végpontokra érkező HTTP-kéréseket és a feldolgozási sorban váró batch-kérések számát korlátozza, modellektől függetlenül: Start szinten 200 000, Build szinten 300 000, Scale szinten 500 000 várakozó kérés, batchenként legfeljebb 100 000. Az OpenAI batch-limitjei külön keretet alkotnak, amelyet modellenként a sorban álló bemeneti tokenekből számol, és óránként legfeljebb 2000 batch hozható létre.

Hosszú kimenetekhez a Claude API-nak van egy csak batchben elérhető funkciója: az output-300k-2026-03-24 béta fejléc 300 000-re emeli a max_tokens határt a jelenlegi Opus, Sonnet és Haiku 5.5 generáción és több korábbi modellen, könyvhosszúságú vázlatokhoz vagy kimerítő adatkinyeréshez. Egyetlen ekkora generálás egy óránál is tovább tarthat, így a 24 órás ablakból is fogyaszt.

Mikor egyszerűbb a flex processing

Az OpenAI középutat is kínál. Ha egy Responses- vagy Chat Completions-hívásnál a service_tier értéke flex, batch-áron kapsz egy normál szinkron kérést, cserébe lassabb válaszokért és alkalmi elérhetetlenségért. Ha nincs kapacitás, olyan 429-et kapsz, amelyért nem kell fizetni, és vagy vársz és újrapróbálod, vagy service_tier: auto beállítással normál áron küldöd újra. Az SDK alapértelmezett időkorlátja tíz perc, az OpenAI példái tizenötre emelik.

Adatmegőrzés és GDPR

Az aszinkron feldolgozás azt jelenti, hogy a szolgáltató addig tárolja a bemeneteidet és kimeneteidet, amíg át nem veszed őket. Az Anthropic a batch kérés- és válaszadatait a létrehozástól számítva legfeljebb 29 napig őrzi, a kész batch a DELETE /v1/messages/batches/{batch_id} végponttal törölhető, a batchek workspace-enként elkülönülnek, és a Console-beli eredményletöltés letiltható; hogy egy funkcióra vonatkozik-e a zero data retention, azt az adatmegőrzési oldal funkciónként sorolja fel. Az OpenAI 30 nappal a batch befejezése után törli a kimeneti fájlokat, a Gemini 6 hétig őrzi az eredményeket, a Bedrock pedig egy általad kezelt S3 bucketbe írja őket.

Személyes adatoknál ez három dolgot jelent: töröld a batcheket, amint eltároltad az eredményeket, vedd fel a szolgáltatót és a régiót az adatkezelési nyilvántartásba, és ellenőrizd, hogy a szerződésed megőrzési vállalásai egyáltalán kiterjednek-e a batch-tárolásra. A tágabb képet a GDPR és LLM-adatrezidencia cikk adja; ha egy visszatöltés ügyféladatokat érint, előbb futtasd át egy PII-kitakarási lépésen.

Források

1. Claude Platform Docs: Batch processing
2. Claude Platform Docs: Rate limits (Message Batches API)
3. Claude Platform Docs: Prompt caching
4. OpenAI API Docs: Batch API
5. OpenAI API Docs: Flex processing
6. OpenAI API Docs: Rate limits (batch queue limits)
7. Google AI for Developers: Gemini Batch API
8. Amazon Bedrock User Guide: Batch inference