СТАТТЯ

Batch API до 50k запитів на job: mega-каталоги і multi-job оркестрація bulk у Bubble з BIAIG

Віталій Дорошенко Опубліковано

OpenAI Batch API дає до 50 000 рядків і 200 MB на один job — але вихідний JSONL не зберігає порядок рядків. Як планувати один batch проти кількох паралельних jobs у backend workflow Bubble і змерджити результати в BIAIG без втрати row-order для Merchant/ads.

Навіщо зараз

У дайджесті знову нагадали про operational ceiling OpenAI Batch API: до 50 000 image generation/edit запитів на один batch job (плюс до 200 MB на input JSONL). Це не про unit economics (−50% / 24h vs Flare — вже окремий матеріал), а про як не зламати mega-каталог, коли spreadsheet-каталоги в Bubble/BIAIG історично йдуть chunking ~500 рядків. Поруч із цим: OpenAI Batch API для images. Про це окремо: AI кодинг для Bubble: ai. Поруч із цим: GPT Image 2.5: 250 IPM.

Ключова думка з Scout-пакету: Bubble list-scheduling (до 100k unsorted / 50k sorted child workflows за офіційним manual) не є головним обмеженням для кількості OpenAI jobs. Оркестрація multi-job зазвичай диктується 50k/200 MB OpenAI і формою payload (b64 vs image_url/file_id), якщо ваш bulk-tool (BIAIG) не накладає власний нижчий chunk — ~500 рядків у попередній editorial thread не верифіковано в публічних BIAIG-доках. Схожий розбір: Tencent Hy Image 3.5 Preview.

Що каже первинне джерело (OpenAI)

  • Endpoints: batch підтримує /v1/images/generations і /v1/images/edits (JSON для edits, не multipart).
  • Per job: до 50 000 JSONL-рядків і 200 MB input file.
  • Час: ціль обробки до 24 годин; rate limits на створення batch (напр. до 2000 batches/hour — tier/account-specific).
  • Порядок: output JSONL ≠ порядок input — корелюйте через custom_id (унікальний в межах batch; cookbook/API reference рекомендують унікальний id на рядок).
  • Помилки: окремий error_file_id; статус expired може залишити частково виконані рядки — merge має це враховувати.
  • Images operational risk: DALL·E url — TTL 60 хвилин після генерації; GPT image models часто b64_json only — JSONL швидше впирається в 200 MB, ніж у 50k lines.
  • Docs: для multimodal/edits краще image_url / file_id, ніж великі base64 в JSONL.

Один OpenAI batch job чи багато паралельних?

Ситуація Типова стратегія
n ≤ 50k і JSONL < 200 MB Один OpenAI batch job на весь каталог (або на один «catalog run»). Bubble може далі обробляти стан каталогу chunkами ~500 — це внутрішній pacing, не обов’язково 1:1 з OpenAI job.
n > 50k ceil(n / 50k) jobs мінімум по ліміту рядків; паралельно перевіряйте 200 MB — при b64 або важких edit payload може знадобитися менший job раніше, ніж 50k.
Mega-каталог + ~500-row bulk ceiling (BIAIG/spreadsheet) Можливий патерн: багато Bubble chunks (~500) → менше OpenAI jobs (групуйте рядки в JSONL до caps). Або навпаки — 1 chunk = 1 batch для простоти retry; тоді jobs = ceil(n/500), що дорожче в orchestration, але простіше idempotency на рівні chunk. Чесно: без ваших полів batch_id/chunk index у BIAIG — оберіть явно і зафіксуйте в DB.

Parallel jobs у Bubble backend: Schedule API workflow on a list розганяє паралельні child workflows; для зовнішніх rate limits — interval pacing (manual). Не блокуйте весь app нулевим interval на тисячі children без потреби.

Не робіть один workflow «build 50k JSONL + upload + poll до completion»: server workflow timeout 300 s (Bubble hard limits) — monolithic poll малоймовірний; multi-step scheduling (submit → persist batch_id → окремий poll/merge) — inference з документованого timeout.

Workflow API: синхронний list response до 50 entries — не повертайте bulk batch status/results одним sync call; статус/merge через Data API або paginated reads.

Merge semantics і row-order (Merchant / ads)

  1. Не покладайтеся на порядок рядків у output JSONL — зіпсуєте Merchant/ad feeds.
  2. Кодуйте стабільний ключ у custom_id, напр.: catalogRunId:chunkIndex:rowIndex або SKU + run id — що у вас є authoritative для export (open question у Scout: spreadsheet row vs SKU vs thing creation order).
  3. Після join: sort у application logic за тим же ключем, не за line number у файлі.
  4. custom_id ≠ HTTP idempotency key OpenAI: повторний create batch — новий job, якщо app не dedupe по збереженому batch_id + business key. App-level dedup: «для цього catalogRunId + rowKey вже є успішний result» перед resubmit.
  5. Partial failure: обробляйте error_file_id, expired з subset completed; retry failed custom_id — новий batch job або sync fallback — політика double-charging для Merchant slots на вашому боці (не в OpenAI docs).
  6. DALL·E url у batch: якщо ingest затримується близько до 24h window — URLs можуть протермінуватись (60 хв); плануйте негайну persistence (CDN/Bubble storage) або модель/output format без крихких url.

Практичний checklist для Bubble + BIAIG

  • Перед submit: оцінка рядків + MB JSONL (b64 vs references).
  • DB: catalog_run_id, openai_batch_id, chunk_index, row_key, status per row.
  • Submit workflow: короткий — upload/create batch, зберегти ids, exit.
  • Poll workflow: scheduled/recursive або list of in_progress batches — не один 300s loop на 24h.
  • Merge workflow: parse output + error files; map by custom_id; sort; оновити Merchant export queue.
  • Документуйте в команді: коли 1 OpenAI job на весь run, коли N parallel (50k, 200 MB, tier queued-token limits — account-specific, Scout open question).

Практичний checklist для Bubble + BIAIG

Чого ми не стверджуємо

  • Точне походження ~500-row ceiling у попередньому thread (plugin, WU, parser) — не знайдено в публічних BIAIG docs.
  • Чи BIAIG сьогодні завжди 1 batch на spreadsheet chunk — потребує audit вашої схеми даних.
  • Tier-specific queued-token при кількох parallel 50k image jobs — перевіряйте в акаунті OpenAI.

Джерела (Scout packet)

OpenAI: Batch API guide, Create batch reference, Batch FAQ, Create image reference, Batch cookbook. Bubble: Hard limits, Scheduling API workflows, Workflow API, Bulk operation methods compared.

Схожі статті

← Усі статті