예산을 초과하지 않는 batch 이미지 생성 pipeline 만들기
자체 durable queue로 GPT Image 2, Flare, Sunburst를 실행하세요. 작업마다 n=1, worker와 시도 횟수 제한을 두고 결과가 불확실한 요청은 usage 대조 후 retry하세요.
·
작업당 이미지 하나를 큐에 등록
GPT Image 2, GPT Image 2.5 Flare, GPT Image 2.5 Sunburst는 같은 OpenAI Images endpoint, 키, 선불 잔액을 사용합니다. Flare는 빠른 일상 작업, Sunburst는 더 정밀한 편집에 맞습니다. 검수를 통과한 결과로 모델을 비교하세요. 세 모델의 공개 token 요금은 같습니다.
큐 작업마다 n=1로 이미지와 비용을 추적하세요. Images는 n=1..10을 순차 native 호출로 실행하며 비동기 batch 서비스가 아닙니다. 순서, 동시성, retry, 예산은 앱에서 관리하세요.
함께 보기: 이미지 생성 API 가격의 실제 계산 방식
prompt가 아니라 asset당 durable job 하나
- 01무엇이든 enqueue하기 전에 stable asset ID와 immutable brief(prompt, references, protected traits)를 만듭니다.
- 02job payload에 model, protocol, output size, maximum attempts를 고정해 retry가 새 결정이 아니라 같은 결정을 재현하게 합니다.
- 03각 worker에 queue의 bounded slice를 주고 provider request 하나당 candidate 하나를 예약합니다. 모델에 internal batch를 요구하지 않습니다.
- 04request ID, terminal usage, output checksum, validation verdict를 asset version과 함께 원자적으로 저장합니다.
- 05storage와 downstream publication이 같은 asset version을 확인한 뒤에만 job을 완료합니다.
측정한 token 사용량으로 예산 계산
| 100만 token 사용량 | 공식 | 일반 B2C · 50% 할인 |
|---|---|---|
| Text input | $5 | $2.50 |
| Cached text input | $1.25 | $0.625 |
| Image input | $8 | $4 |
| Cached image input | $2 | $1 |
| Image output | $30 | $15 |
예를 들어 fresh text input 900 token, fresh image input 1,200 token, image output 4,000 token인 편집은 공식 $0.1341, 일반 B2C $0.06705입니다. 예시 token 수는 이미지마다 보장되지 않습니다. 실제 최종 usage와 해당 요청의 차감액으로 측정하세요.
카탈로그나 batch 비용은 모든 정산 금액을 검수 통과 이미지 수로 나눕니다. 검수에 실패한 유료 결과도 포함하세요. GPT Image에는 무료 countTokens 추정기가 없으므로 소규모 유료 샘플을 측정하고 큐 시작 전 지출 한도를 설정하세요.
단가뿐 아니라 모든 배수를 제한
| 배수 | Guardrail |
|---|---|
| Assets | 명시적 queue 길이와 campaign budget |
| Variants | asset당 maximum candidate |
| Retries | proven not-started만; total deadline |
| Resolution | 반환 크기 확인; size는 비율 유도 |
| References | brief에 필요한 파일만 |
| Concurrency | 작은 worker ceiling과 429 cooling |
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 예산만 소진하고 계정은 건드리지 않습니다. prepaid 잔액은 만료되지 않고 규모를 맞춰야 하는 구독도 없습니다.
- workload당 key 하나: batch generation은 interactive나 editing 트래픽과 key를 공유하지 않습니다.
- campaign을 닫기 전에 모든 settled charge를 request ID와 대조합니다.
- 초기 설정 때 한 번이 아니라 새 campaign마다 평생 누적 지출 한도를 다시 확인합니다.
자주 묻는 질문
API 요청 하나로 전체 batch를 생성할 수 있나요?
Images는 n=1..10을 순차 native 호출로 실행합니다. 큰 작업은 큐 항목당 n=1로 앱에서 동시성과 예산을 제어하세요. 비동기 Images batch endpoint는 없습니다.
runaway image batch를 어떻게 막나요?
평생 누적 지출 한도가 있는 전용 key, 명시적 queue 길이, bounded worker, asset당 maximum attempts, total campaign budget을 조합하세요. 각 계층은 독립적으로 실패하고, key-level 한도는 나머지가 모두 고장 나도 유지되는 경계입니다.
429를 즉시 retry해야 하나요?
아닙니다. Retry-After와 provider cooling을 지키고 jitter를 더하며 job마다 total deadline을 유지하세요. capacity event 중 즉시 fan-out은 속도 저하를 직접 돈 내고 만든 장애로 바꿉니다.
base64 payload와 URL 중 무엇을 저장해야 하나요?
API 응답은 저장소가 아니라 전송 수단입니다. base64는 한 번만 decode해 checksum을 계산하고 byte를 자체 object storage에 보관한 뒤 최적화된 WebP/AVIF derivative를 게시하세요. 날것의 API payload를 storefront asset으로 제공하면 안 됩니다.
50% 할인이 batch의 모든 call에 적용되나요?
일반 B2C에는 generation과 edit을 포함한 모든 admitted call의 official usage에 적용됩니다. B2B는 협상 정책, OpenKeys는 공식 가격 1:1입니다. 할인은 특정 key에 모델이 현재 사용 가능함을 증명하지 않습니다.