Sume 영상 Job 동시성과 큐: 한도와 queue_full

Sume는 유료 생성 Job을 큐 우선(queue-first) 방식으로 접수합니다. 유효하고, 잔액을 예약할 수 있고, 워크스페이스의 수락 Job 용량 안에 드는 제출은 내구성 있는 Job이 되며, 곧바로 시작하거나 동시성 슬롯이 열릴 때까지 queued에서 기다립니다. 동시성이 제한하는 것은 제출할 수 있는 Job 수가 아니라 processing 상태인 Job 수이므로, 제출이 429 queue_full로 실패하는 것은 큐까지 가득 찼을 때뿐입니다.

아래 접수 규칙은 Sume의 Generation admission 문서를 따르며, 요금제별 한도는 요금제 페이지의 바탕인 요금제 카탈로그에서 가져왔습니다.

동시성, 큐 용량, 요청 한도는 어떻게 다른가요?

Sume는 헷갈리기 쉬운 네 가지 제어를 구분합니다. 읽기와 상태 엔드포인트에도 요청 한도가 있을 수 있는데, 이는 생성 동시성이 아니라 폴링 백프레셔로 취급하세요.

요금제마다 생성 Job을 동시에 몇 개까지 실행할 수 있나요?

동시성은 동시에 실행할 수 있는 생성 Job 수이며, 요금제로만 정해집니다. 선불 충전으로는 올라가지 않습니다. 큐 용량의 기본값은 max(3, concurrency_limit × 5)입니다. 수락 Job 용량은 concurrency_limit + queued_jobs_limit로, 워크스페이스에서 한 번에 processing 또는 queued 상태일 수 있는 유료 생성 Job의 최대 개수입니다. 요금제는 Free $0, Pro 월 $40, Startup 월 $120, Scale 월 $400입니다.

관리자 오버라이드는 limit_source: admin_override로 표시되며, 워크스페이스의 유효 concurrency_limit을 올릴 수 있습니다. Enterprise는 더 높은 계약 한도에 이를 사용합니다. 기준값은 대시보드 Concurrency 탭이며, API에서는 generation_limits.concurrency_limit으로 노출됩니다. 어떤 정적 표보다 이 값을 우선하세요.

큐 우선 접수는 어떻게 동작하나요?

queued를 실패로 취급하지 마세요. job_id를 저장하고, 지수 백오프로 상태를 폴링하고, Job이 result_ready: true 또는 status: completed를 보고할 때만 결과를 가져오세요.

concurrency_limit: 1인 워크스페이스도 유효한 Job 여러 개를 한 번에 제출할 수 있습니다. 잔액과 큐 용량이 있는 동안 Sume는 모두 queued로 반환할 수 있으며, processing으로 넘어가는 Job은 한 번에 하나뿐이어야 합니다.

Job A: queued -> processing -> completed
Job B: queued -------------> processing -> completed
Job C: queued ---------------------------> processing -> completed

generation_limits 스냅샷은 어떻게 읽나요?

Sume가 워크스페이스 접수 스냅샷을 계산할 수 있으면 생성 제출 응답에 generation_limits가 들어 있습니다. 그 안의 개수는 응답 직후에도 바뀔 수 있습니다. 예시는 실행 중인 작업이 없는 Pro 워크스페이스입니다.

• concurrency_limit은 processing 상태일 수 있는 유료 생성 Job의 유효 최대값이고, plan_concurrency_limit은 요금제 기본값일 뿐입니다.
• queued_jobs_limit은 추가로 queued에서 기다릴 수 있는 Job 수이고, accepted_generation_jobs_limit은 두 값의 합입니다.
• queue_capacity_remaining은 queue_full이 되기 전까지 남은 queued Job 예산에 비어 있는 처리 슬롯을 더한 값입니다.
• wave_size_hint는 max(1, floor(queue_capacity_remaining * 0.75))입니다. 제출 묶음(wave) 크기에 대한 힌트일 뿐이며, 동시성 한도나 진행 중인 작업의 폭이 아닙니다.

{
  "generation_limits": {
    "plan_id": "pro",
    "limit_source": "plan",
    "plan_concurrency_limit": 4,
    "concurrency_limit": 4,
    "queued_jobs_limit": 20,
    "accepted_generation_jobs_limit": 24,
    "active_generation_jobs": 0,
    "queued_generation_jobs": 0,
    "queue_capacity_remaining": 24,
    "wave_size_hint": 18
  }
}

제출 묶음 크기는 어떻게 정해야 하나요?

max(0, concurrency_limit - active_generation_jobs - queued_generation_jobs)를 새로 진행할 작업의 예산으로 쓰되, queue_capacity_remaining을 넘지 않게 하세요. 다음 실시간 스냅샷을 받을 때까지 제출하는 Job마다 이 예산에서 차감하고, 여유가 남지 않았다면 더 제출하기 전에 기다리세요.

문서의 예시에서 concurrency_limit: 100, queued_jobs_limit: 500으로 설정된 워크스페이스는 유휴 상태일 때 wave_size_hint: 450을 보여 주지만, 새로 진행할 수 있는 Job은 최대 100개입니다. 30개가 처리 중이고 10개가 큐에 있으면 새로 진행할 작업의 예산은 60입니다.

429 queue_full을 받으면 어떻게 해야 하나요?

queue_full은 워크스페이스가 수락된 생성 용량을 모두 썼다는 뜻입니다. 오류 details에는 generation_limits 스냅샷이 들어 있을 수 있으며, 해당하는 경우 Sume는 실패한 접수의 예약을 해제하거나 환불합니다. 그다음 할 일은 다음과 같습니다.

• 그 워크스페이스에 생성 작업을 더 추가하지 마세요.
• 기존 Job 중 하나 이상이 종료 상태에 도달할 때까지 폴링하세요.
• 더 이상 필요 없는 queued Job은 취소하세요. 취소는 생성이 시작되기 전에만 성공하며, 그 뒤에는 409 job_generation_already_started를 반환합니다.
• 용량이 열리면 같은 멱등성 키로 재시도하고, retry-after가 있으면 그 값을 따르세요.

현재 큐의 한계는 무엇인가요?

접수 문서에는 다음 한계가 나와 있습니다.

• Job별 정확한 큐 위치나 예상 완료 시간(ETA)은 없고, 큐 개수와 남은 수락 용량만 있습니다.
• sync와 subscribe 모드는 최대 30초까지 기다릴 수 있습니다. 그 뒤에는 Job ID로 계속 폴링하세요.
• 큐 만료와 클라이언트가 지정하는 fail-fast 큐 길이는 현재 공개 API 옵션이 아닙니다.