非同期Batch 推論を独立実行 tierとして設計する運用

非対話・大量のLLM推論を、対話APIの単なる低優先度呼び出しではなく、独立した非同期execution tierとして扱う。Batch tierでは、submit、queue、processing、partial failure、expiry、cancellation、result retrieval、retry、reconciliationを明示的な状態として管理し、同期APIのlatency/SLOやretry設計をそのまま流用しない。

Geminiの現行公式資料はBatchをasynchronous bulk processingとして位置付け、標準料金から50%低い価格と最大24時間のturnaround targetを示す。AnthropicもBatch APIを大量非同期処理として提供し、input/output tokenを50%割引する。providerごとにmodel eligibility、queue/rate limits、expiry、cancel、result retention、data handlingは異なるため、共通抽象化の下でもprovider-specific adapterとreadbackが必要である。

最低限、LOCAL_CREATED、SUBMITTED、QUEUED/PROCESSING、SUCCEEDED、PARTIAL、FAILED、CANCEL_REQUESTED、CANCELLED、EXPIRED、RECONCILEDを区別する。providerの実際のstatus名へ一対一対応すると仮定せず、adapterで正規化する。

submit APIが成功したことは個々のrequest成功を意味しない。job ID、input manifest hash、provider、model、created time、request countを保存し、providerから取得したjob/resultをreadbackして初めて処理結果を確定する。

各requestにstable local keyを付与し、batch job IDだけでなくrequest key→result/errorを照合する。再送時はoriginal job、retry generation、reasonをlineageとして保持し、結果の二重取込を防ぐ。

providerがexactly-once executionを保証すると仮定しない。client-side deduplicationとresult reconciliationを別controlとして設計する。

大量batchでは一部requestのみvalidation/model/content/errorとなる場合がある。成功・失敗・未確定をrequest単位で集計し、retry対象を限定する。全件再送はcost重複とduplicate side effectを生むため、batch inputは原則として副作用を伴わない推論へ限定するか、副作用処理を後段のidempotent commitへ分離する。

cancelは未処理workの停止要求であり、既に完了したrequestや発生済みcostを巻き戻す保証ではない。expiryも「何も実行されなかった」ことを意味しない。cancel/expiry後もresult inventoryを再取得し、completed/failed/unprocessedを照合する。

Batchは低価格である一方、interactive latencyを要求するworkloadには不適切である。Geminiの現行資料ではBatchは50% discount、最大24時間のturnaround targetであり、offline evalやmassive datasets向けとされる。したがってrouting policyはdeadline、interactive dependency、data sensitivity、model eligibility、queue capacityを見てstandard/flex/batch等を選択する。

• SUBMIT-ACK-LOSS: provider側ではjob作成済みだがclientがackを失い、同一batchを再作成する。
• PARTIAL-RESULT-LOSS: job-level completedだけを見てrequest-level errorを取りこぼす。
• RETRY-DUPLICATION: failed/unknown requestを全件再送し、成功済みrequestを重複実行する。
• EXPIRY-MISREAD: expired/cancelledを全件未実行と誤認する。
• MODEL-DRIFT: queued中にmodel aliasやprovider behaviorが変化し、同期tierとの比較条件が崩れる。
• COST-RECONCILIATION-GAP: request/result ledgerとprovider usage/billing exportが結び付かない。
• RETENTION-OVERREACH: batch input/outputの保存期間やdata-use条件を同期APIと同一と仮定する。
• DEADLINE-MISMATCH: 24h級の非同期tierへinteractive dependencyを投入する。

• immutable input manifestにprovider、model ID、request key、payload hash、created time、policy versionを保存する。
• submit後はprovider job IDを即時保存し、GET/readbackで存在・status・request countを確認する。
• request-level result/errorをlocal ledgerへupsertし、reconciliationを再実行可能にする。
• retryはfailed/expired/unprocessed subsetだけを新generationとして作成し、original lineageを保持する。
• cancel/expiry後にも最終resultを取得し、completed subsetとbillingを照合する。
• batchとstandardを同一SLOに混ぜず、deadline-aware routingとcapacity fallbackを設ける。
• provider/modelごとのbatch eligibility、quota、pricing、retention、region/data policyをdeployment時に再確認する。
• prompt/model/tool/retrieval/evaluator versionを固定し、offline eval用途では同期tierとの差を同一fixtureで検証する。

Batch tierは安価だから常に有利とは限らない。queue待ち、result polling、manifest生成、reconciliation、retry、storage、運用監視の追加コストがある。依存関係の強いagent loop、低latency UX、即時transactionには不向きである。

provider間で「Batch」という名称が同じでも、supported models、request/file limits、completion window、cancellation、expiry、pricing、data retentionは一致しない。共通control planeは最小共通状態だけを正規化し、provider固有条件を消さない。

batch input fileやmanifestへsecretを埋め込まない。result ingestionはjob IDだけで信頼せず、provider/account、manifest hash、request keyを照合する。

input/outputの保存先、provider retention、region、training/data-use条件を確認し、必要ならPII redaction/tokenizationをsubmit前に行う。

AUDIT: input manifest hash、provider job ID、model ID、request count、submit/readback時刻、final status、request-level outcome、retry lineage、usage/cost referenceを保持する。

token単価だけでなく、storage、polling、failed retry、expiry、duplicate submission、reconciliation laborを含めて評価する。

queue age、oldest job、success/error/expired/cancelled count、reconciliation lag、unmatched result、billing mismatchを監視する。

• OpenAI Batchの2026-10-22時点のexact model eligibility、rate-limit、retention、cancel/expiry semanticsは本RUNで一次資料を十分取得できていない。
• Anthropic Message Batchesのcurrent completion window、result retention、cancel semanticsの一次ページは本RUN検索で直接取得できていない。pricingの50% discountとBatch endpoint存在は公式資料で確認。
• Gemini各modelのexact batch eligibility、file/request上限、region差はdeployment時に再確認が必要。
• providerがjob creationにclient-supplied idempotency keyを提供するか、その保証範囲。
• usage/billing exportとrequest-level resultのexact join key。
• batchとstandardでのmodel backend/version同一性。

UNKNOWNを推測で閉じない。

非対話・大量のLLM推論は、同期APIとは別の非同期Batch execution tierとして管理できる。Batchは低価格・高throughputに向く一方、queue、partial failure、expiry、cancellation、retry、result reconciliationを伴う。submit成功を処理完了とみなさず、immutable input manifest、provider job ID、request-level correlation、readback、retry lineageを保存する。providerごとのmodel eligibility、料金、期限、retention、data policyは変動するため、導入時点の公式資料で再確認する。