> 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.
>
> Web page: https://balazscsorba.com/hu/blog/llm-batch-api-offline-workloads · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/llm-batch-api-offline-workloads.md) · [Deutsch](https://balazscsorba.com/de/blog/llm-batch-api-offline-workloads.md)
> Author: Balázs Csorba · Published: 2026-10-17 · Keywords: 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

[Blog](https://balazscsorba.com/hu/blog)/LLMOps és értékelés

# 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.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 17.·9 perc olvasás

-   Batch API
-   Cost
-   LLMOps
-   Prompt caching
-   Data pipelines

![Széles doboz nyolc kis négyzettel, balról érkeznek, egy hosszú nyíl visszatér.](https://balazscsorba.com/images/blog/llm-batch-api-offline-workloads/cover.webp?v=417281c599)

## A lényeg röviden

-   Az Anthropic, az OpenAI és a Gemini is a normál ár 50%-át kéri a batch-kérésekért, cserébe az eredmény aszinkron, 24 órás ablakon belül érkezik.
-   Az eredmények tetszőleges sorrendben jönnek vissza: mindig custom\_id vagy key alapján párosítsd őket a forrásrekordokhoz, soha ne pozíció szerint.
-   A batch-limitek külön keretet alkotnak a szinkron limitek mellett, így a visszatöltések és evalok batchbe költöztetése az interaktív forgalmat is védi.
-   A batch- és a prompt caching-kedvezmény összeadódik, de a batchben a cache-találat best effort; használj azonos cache\_control blokkokat, és fontold meg az egyórás cache-t.
-   A batch-adatok hetekig a szolgáltatónál maradnak: az Anthropic 29 napig tartja az eredményeket, az OpenAI 30 nap után törli a kimeneti fájlokat, a Gemini 6 hét után.

Ezen az oldalon

1.  [Milyen terhelés való batchbe](https://balazscsorba.com/#when-batch-fits)
2.  [Anthropic, OpenAI, Gemini és Bedrock összevetve](https://balazscsorba.com/#provider-comparison)
3.  [Egy batch életciklusa](https://balazscsorba.com/#batch-lifecycle)
4.  [Párosítható és újrapróbálható kérések összeállítása](https://balazscsorba.com/#building-requests)
5.  [Részleges hibák, és miért fizetsz](https://balazscsorba.com/#results-and-failures)
6.  [A batch- és a prompt caching-kedvezmény összeadása](https://balazscsorba.com/#caching-with-batches)
7.  [Limitek, átviteli kapacitás és költés](https://balazscsorba.com/#limits-throughput)
8.  [Mikor egyszerűbb a flex processing](https://balazscsorba.com/#flex-alternative)
9.  [Adatmegőrzés és GDPR](https://balazscsorba.com/#data-retention)
10.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

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](https://balazscsorba.com/hu/blog/pimcore-erp-delta-sync).
-   **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](https://balazscsorba.com/hu/blog/llm-evals-for-product-features).
-   **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

Szempont

Anthropic

OpenAI

Gemini

Bedrock

Ár

a normál ár 50%-a

50%-kal olcsóbb

a normál ár 50%-a

Lásd a Bedrock árlistát

Batchenként

100 000 kérés vagy 256 MB

50 000 kérés, 200 MB-os fájl

20 MB inline, 2 GB-os fájl

Fiókonkénti kvóták

Ablak

24 óra, többnyire 1 óra alatt

24 óra, rögzített

24 órás cél

Aszinkron feladat

Bemenet

JSON kéréslista

Feltöltött JSONL-fájl

Inline vagy JSONL-fájl

JSONL S3-ban

Párosító kulcs

`custom_id`

`custom_id`

`key`

`recordId`

Eredmények megőrzése

29 nap

A kimenet 30 nap után törlődik

6 hét

A saját S3 bucketed

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 kör a hibákon zárul: az errored és expired kérések a következő batchbe kerülnek, nem vissza a szinkron API-ra.

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](https://balazscsorba.com/hu/blog/structured-outputs-json-schema-llm).
-   **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](https://balazscsorba.com/hu/blog/llm-cost-latency-prompt-caching-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.

**A batch túllőhet a költéskereten**

Az Anthropic jelzi, hogy a nagy átviteli sebesség és a párhuzamos feldolgozás miatt a batchek kissé túlléphetik egy workspace beállított költéskeretét. Ha egy workspace-limit az egyetlen védelmed egy elszabadult visszatöltés ellen, tegyél mellé saját ellenőrzést: becsüld meg a kérésenkénti tokenszámot, szorozd meg a batch méretével, és egy keret felett ne küldd be.

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.

Kérdés

Batch API

Flex processing

Kódforma

Fájl beküldése, lekérdezés, eredmények feldolgozása

Hagyományos kérés és válasz

Ár

Batch-ár

Batch-ár

Hibamód

Lejárt vagy hibás sorok az eredményben

429 resource unavailable, nem számlázva

Leginkább

Több tízezer független kéréshez

Alacsony prioritású munkához meglévő kódútvonalakon

## 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](https://balazscsorba.com/hu/blog/gdpr-llm-api-eu-data-residency) cikk adja; ha egy visszatöltés ügyféladatokat érint, előbb futtasd át egy [PII-kitakarási](https://balazscsorba.com/hu/blog/pii-redaction-llm-pipelines) lépésen.

## Források

1.  [Claude Platform Docs: Batch processing](https://platform.claude.com/docs/en/build-with-claude/batch-processing)
2.  [Claude Platform Docs: Rate limits (Message Batches API)](https://platform.claude.com/docs/en/api/rate-limits)
3.  [Claude Platform Docs: Prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)
4.  [OpenAI API Docs: Batch API](https://developers.openai.com/api/docs/guides/batch)
5.  [OpenAI API Docs: Flex processing](https://developers.openai.com/api/docs/guides/flex-processing)
6.  [OpenAI API Docs: Rate limits (batch queue limits)](https://developers.openai.com/api/docs/guides/rate-limits)
7.  [Google AI for Developers: Gemini Batch API](https://ai.google.dev/gemini-api/docs/batch-api)
8.  [Amazon Bedrock User Guide: Batch inference](https://docs.aws.amazon.com/bedrock/latest/userguide/batch-inference.html)

## Gyakori kérdések

Mennyivel olcsóbb a batch API?

Az Anthropic, az OpenAI és a Google Gemini is a normál díj 50%-át számolja fel a batch-kérésekért. A Claude API-nál ez a bemeneti, kimeneti és speciális tokenekre is vonatkozik, így a Claude Opus 5.5 batchben millió bemeneti tokenenként 2, millió kimeneti tokenenként 10 dollárba kerül. A prompt caching kedvezménye erre jön rá.

Mennyi ideig tart egy batch?

Mindhárom szolgáltató 24 órás ablakkal dolgozik. Az Anthropic szerint a legtöbb batch egy órán belül elkészül, de a 24 órán belül fel nem dolgozott kérések lejárnak. A pipeline-t a 24 órás legrosszabb esetre tervezd, ne a jellemzőre.

Használhatok eszközöket és strukturált kimenetet batch-kérésekben?

A Claude API-nál szinte bármilyen Messages-kérés batchelhető, eszközhasználattal, szerveroldali eszközökkel, képekkel, rendszerprompttal és többfordulós beszélgetésekkel együtt; a stream, a speed és a max\_tokens 0 nem támogatott. A kliensoldali eszközökhöz továbbra is oda-vissza kör kell, így minden eszközhívás új kérést jelent. Bedrockon az eszközhíváshoz InvokeModel formátum kell, nem Converse.

Mi történik a batch hibás kéréseivel?

Minden kérés saját eredményt kap. A Claude API-nál az errored, canceled és expired kérésekért nem kell fizetni. Az OpenAI-nál a hibák külön hibafájlba kerülnek, és ha egy batch lejár, a ténylegesen elkészült kérésekért fizetsz. Gyűjtsd össze a hibásakat, és küldd be őket újra egy új batchben.

Batch API vagy OpenAI flex processing?

A flex egy szinkron kérés service\_tier flex beállítással, batch-áron, de lassabban és néha elérhetetlenül; ilyenkor 429-et ad, amelyért nem kell fizetni. Olyan feladatokhoz illik, amelyeknél egyszerű kérés-válasz kód kell. A batch nagy mennyiséghez illik, ahol megvárhatod az eredményfájlt.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [LLM rate limitek élesben: újrapróbálás, backoff és szolgáltatóváltás](https://balazscsorba.com/hu/blog/llm-rate-limits-retries-provider-fallback)
-   [Promptverziózás élesben: git, registry, címkék és visszaállítás](https://balazscsorba.com/hu/blog/prompt-versioning-management)
-   [Strukturált kimenet JSON Schemával: mit fed le a garancia, és mit nem](https://balazscsorba.com/hu/blog/structured-outputs-json-schema-llm)
-   [MI-ügynökök értékelése: trajektóriák, eredmények és megbízhatóság pontozása](https://balazscsorba.com/hu/blog/evaluating-ai-agents-trajectories)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)
