# 非同期Batch inferenceを独立execution tierとして設計する運用 CURRENT_STATUS: CURRENT OBSERVATION: SPEC_ONLY FRESHNESS: CURRENT PAGE_TYPE: reference CANONICAL_URL: /tools/ea-798-batch-inference-execution-tier CLAIM_IDS: none EVIDENCE_IDS: EVD-EA-798-URL-41FE60B53A13, EVD-EA-798-URL-B88C4950BBF3, EVD-EA-798-URL-5770757567C6, EVD-EA-798-URL-7EF0664F2DE9, EA-798-CURRENT-APPROVAL, EA-798-CURRENT-BODY-READBACK UNKNOWN_IDS: EA-798-UNKNOWN-01 OPS_IDS: none ## Summary 非対話・大量の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は変動するため、導入時点の公式資料で再確認する。 ## Current judgment 非対話・大量の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は変動するため、導入時点の公式資料で再確認する。 ## Scope 非同期Batch inferenceを独立execution tierとして設計する運用 ## Confirmed ## UNKNOWN - EA-798-UNKNOWN-01: - 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を推測で閉じない。 ## Evidence - EVD-EA-798-URL-41FE60B53A13 (RESEARCH): Google Gemini API optimization and inference: — https://ai.google.dev/gemini-api/docs/optimization - EVD-EA-798-URL-B88C4950BBF3 (RESEARCH): Google Gemini Developer API pricing: — https://ai.google.dev/gemini-api/docs/pricing - EVD-EA-798-URL-5770757567C6 (RESEARCH): Anthropic Pricing — Batch processing: — https://docs.anthropic.com/en/docs/about-claude/pricing - EVD-EA-798-URL-7EF0664F2DE9 (RESEARCH): Anthropic API Errors — Batch endpoint request-size/network guidance: — https://docs.anthropic.com/en/api/errors - EA-798-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応 - EA-798-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合 ## Failure / limits SUBMIT-ACK-LOSS: provider側ではjob作成済みだがclientがackを失い、同一batchを再作成する。 ## Failure / limits PARTIAL-RESULT-LOSS: job-level completedだけを見てrequest-level errorを取りこぼす。 ## Failure / limits RETRY-DUPLICATION: failed/unknown requestを全件再送し、成功済みrequestを重複実行する。 ## Failure / limits EXPIRY-MISREAD: expired/cancelledを全件未実行と誤認する。 ## Failure / limits MODEL-DRIFT: queued中にmodel aliasやprovider behaviorが変化し、同期tierとの比較条件が崩れる。 ## Failure / limits COST-RECONCILIATION-GAP: request/result ledgerとprovider usage/billing exportが結び付かない。 ## Failure / limits RETENTION-OVERREACH: batch input/outputの保存期間やdata-use条件を同期APIと同一と仮定する。 ## Failure / limits DEADLINE-MISMATCH: 24h級の非同期tierへinteractive dependencyを投入する。 ## Failure / limits 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固有条件を消さない。 ## Practice batch input fileやmanifestへsecretを埋め込まない。result ingestionはjob IDだけで信頼せず、provider/account、manifest hash、request keyを照合する。 ## 概要 非対話・大量の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が必要である。 ## 主要claim ### 1. Batchは独立した状態機械として扱う 最低限、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して初めて処理結果を確定する。 ### 2. request単位のcorrelationを失わない 各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として設計する。 ### 3. partial failureをjob全体の失敗へ潰さない 大量batchでは一部requestのみvalidation/model/content/errorとなる場合がある。成功・失敗・未確定をrequest単位で集計し、retry対象を限定する。全件再送はcost重複とduplicate side effectを生むため、batch inputは原則として副作用を伴わない推論へ限定するか、副作用処理を後段のidempotent commitへ分離する。 ### 4. cancellationとexpiryはrollbackではない cancelは未処理workの停止要求であり、既に完了したrequestや発生済みcostを巻き戻す保証ではない。expiryも「何も実行されなかった」ことを意味しない。cancel/expiry後もresult inventoryを再取得し、completed/failed/unprocessedを照合する。 ### 5. cost tierとlatency tierを同時に分離する 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等を選択する。 ## failure modes - 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を投入する。 ## control / implementation implication 1. immutable input manifestにprovider、model ID、request key、payload hash、created time、policy versionを保存する。 2. submit後はprovider job IDを即時保存し、GET/readbackで存在・status・request countを確認する。 3. request-level result/errorをlocal ledgerへupsertし、reconciliationを再実行可能にする。 4. retryはfailed/expired/unprocessed subsetだけを新generationとして作成し、original lineageを保持する。 5. cancel/expiry後にも最終resultを取得し、completed subsetとbillingを照合する。 6. batchとstandardを同一SLOに混ぜず、deadline-aware routingとcapacity fallbackを設ける。 7. provider/modelごとのbatch eligibility、quota、pricing、retention、region/data policyをdeployment時に再確認する。 8. prompt/model/tool/retrieval/evaluator versionを固定し、offline eval用途では同期tierとの差を同一fixtureで検証する。 ## 適用境界・counterevidence 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固有条件を消さない。 ## SECURITY batch input fileやmanifestへsecretを埋め込まない。result ingestionはjob IDだけで信頼せず、provider/account、manifest hash、request keyを照合する。 ## PRIVACY 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を保持する。 ## COST token単価だけでなく、storage、polling、failed retry、expiry、duplicate submission、reconciliation laborを含めて評価する。 ## OPERABILITY queue age、oldest job、success/error/expired/cancelled count、reconciliation lag、unmatched result、billing mismatchを監視する。 ## OPEN_UNKNOWN - 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を推測で閉じない。 ## SAFE_WORDING 非対話・大量の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は変動するため、導入時点の公式資料で再確認する。 NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.