예산을 초과하지 않는 batch 이미지 생성 pipeline 만들기

admitted call 하나, candidate 하나

어떤 public image route도 count, manifest, prompt 폴더를 받지 않습니다. gemini-3.1-flash-image의 generateContent call은 이미지가 inlineData에 base64로 담긴 candidate 하나를 반환하고, OpenAI 호환 POST /v1/images/generations(gpt-image-2)는 b64_json을 담은 단일 원소 data 배열을 반환합니다. 모델은 "500개 변형을 만들어 달라"를 보지 않습니다. batch 크기는 request가 아니라 queue의 속성입니다.

// gemini-3.1-flash-image → one candidate, image as base64 inlineData
{
  "candidates": [
    { "content": { "parts": [ { "inlineData": { "mimeType": "image/png", "data": "<base64>" } } ] } }
  ],
  "usageMetadata": { "promptTokenCount": 24, "candidatesTokenCount": 1120, "totalTokenCount": 1144 }
}

// gpt-image-2 → single-element data array, image as b64_json
{
  "created": 1754800000,
  "data": [ { "b64_json": "<base64>" } ],
  "usage": { "input_tokens": 38, "output_tokens": 4096, "total_tokens": 4134 }
}

두 형태의 저장은 설계 단계에서 계획하세요. base64는 한 번만 decode해 byte checksum을 계산하고 job과 함께 보관합니다. route가 URL 형태를 반환한다면 그것은 자체 만료가 있는 fetch 작업이지 durable asset이 아닙니다.

함께 보기: 이미지 생성 API 가격의 실제 계산 방식

prompt가 아니라 asset당 durable job 하나

1. 01무엇이든 enqueue하기 전에 stable asset ID와 immutable brief(prompt, references, protected traits)를 만듭니다.
2. 02job payload에 model, protocol, output size, maximum attempts를 고정해 retry가 새 결정이 아니라 같은 결정을 재현하게 합니다.
3. 03각 worker에 queue의 bounded slice를 주고 provider request 하나당 candidate 하나를 예약합니다. 모델에 internal batch를 요구하지 않습니다.
4. 04request ID, terminal usage, output checksum, validation verdict를 asset version과 함께 원자적으로 저장합니다.
5. 05storage와 downstream publication이 같은 asset version을 확인한 뒤에만 job을 완료합니다.

{
  "asset_id": "catalog/sku-1042/hero-v3",
  "idempotency_key": "sku-1042:hero-v3:attempt-1",
  "model": "gemini-3.1-flash-image",
  "size": "1K",
  "max_attempts": 2,
  "spending_key": "image-production"
}

SKU 500개 run의 비용 계산

Nano Banana 2는 고정 image-output leg를 공개합니다. 1K는 image token 1,120개로 공식 $0.0672, 일반 B2C는 $0.0336이며 같은 50% 정책으로 2K는 $0.0504, 4K는 $0.0756입니다. GPT Image 2에는 정직한 이미지당 상수가 없습니다. 일반 B2C image output은 1M token당 $15이고 정산 총액은 terminal usage를 따릅니다. run 전에 알 수 있는 부분은 고정 leg뿐이므로 이 값으로 계산하세요.

이것은 image-output leg뿐입니다. text/image input, 선택적 text/thinking output, grounding은 terminal usage에서 더해집니다. B2C 50% 할인은 official usage를 절반으로 줄이지만 asset × candidate × retry × resolution의 곱을 제한하지 않습니다. 그 경계는 직접 정해야 합니다.

이 batch 계산의 근거가 되는 token 요금 →

단가뿐 아니라 모든 배수를 제한

key의 평생 누적 지출 한도는 모든 application-level guardrail이 실패했을 때의 마지막 금액 경계입니다. 계정 잔액이 아니라 campaign 예산에 측정된 안전 마진을 더한 값으로 설정하세요.

retry, cooling, observability 규칙

• image bytes나 complete provider response가 전달된 후에는 절대 retry하지 않습니다. 그 retry는 복구가 아니라 두 번째 유료 candidate입니다.
• ambiguous timeout은 reconciliation 작업입니다. billable generation이 없었다고 결론 내리기 전에 request ID를 dashboard charge와 대조하세요.
• 429에는 Retry-After, provider cooling, jitter를 total deadline 안에서 적용합니다. 즉시 fan-out은 capacity event를 키웁니다.
• attempt, accepted asset, settled nanoUSD, validation 실패 사유를 추적하고 prompt와 key는 metric에 넣지 않습니다.
• HTTP success rate뿐 아니라 accepted asset당 비용과 failure share에 alert하세요. 전부 초록인 batch도 비쌀 수 있습니다.

accepted asset당 settled cost가 batch의 실제 unit economics입니다. token 가격, resolution, retry, quality reject를 비즈니스가 실제로 사는 숫자 하나로 합칩니다.

전용 key와 예산으로 batch lane 격리

batch worker는 평생 누적 지출 한도와 expiration date가 있는 전용 key로 실행하세요. queue 버그가 터져도 campaign 예산만 소진하고 계정은 건드리지 않습니다. Google이나 GitHub로 만든 새 계정에는 $5 플랫폼 웰컴 보너스 크레딧이 포함되어 첫 충전 전에 pipeline을 end-to-end로 검증할 수 있고, 이후에는 은행 카드나 USDT, BTC 같은 암호화폐로 원하는 정수 달러 금액을 충전합니다. prepaid 잔액은 만료되지 않고 규모를 맞춰야 하는 구독도 없습니다.

• workload당 key 하나: batch generation은 interactive나 editing 트래픽과 key를 공유하지 않습니다.
• campaign을 닫기 전에 모든 settled charge를 request ID와 대조합니다.
• 초기 설정 때 한 번이 아니라 새 campaign마다 평생 누적 지출 한도를 다시 확인합니다.

만료 없는 prepaid 요금제: campaign 예산만큼 정확히 충전 →

자주 묻는 질문

관련 가이드