[GPU] 영상 생성 성능/비용 실측: 구성별 처리시간과 요금
개요
이전 글에서 영상 생성 모델을 HTTP API와 Python 클라이언트로 감싸서 실제로 호출할 수 있는 형태까지 만들었습니다. API가 정상적으로 동작한다는 것과, 그 API를 운영 규모로 돌렸을 때 처리시간과 비용이 감당할 만한 수준인지는 별개의 질문입니다. 이번 글은 SGLang 추론 최적화 글에서 다뤘던 GPU 배치와 정밀도/가속 조합을 다시 가져와서, 단건 지연시간과 시간당 처리량이 실제로 어떻게 갈리는지, 그리고 그 결과를 실제 GPU 인스턴스 단가에 대입하면 영상 한 편당 얼마가 나오는지를 직접 계산합니다.
테스트 조건은 PRO 5000 72GB GPU 4장 기준, 1344×768 해상도, 5초 영상입니다. 아래 수치는 이 조건에서 측정한 예시이며, 성능을 보장하는 값이 아니라 구성을 바꿨을 때 어느 방향으로 얼마나 움직이는지를 보여주는 참고 자료로 읽어야 합니다.
1. 지연시간과 처리량은 같은 것을 최적화하지 않는다
같은 FP8/20단계 설정을 GPU 4장을 어떻게 나눠 배치하느냐에 따라 세 가지로 실측했습니다.
| 배치 | 단건 지연 | 서버 집계 처리량 예 | 선택 이유 |
|---|---|---|---|
| 4 GPU × 1 (인스턴스 1개가 GPU 4장 사용) | 88.8초 | 약 40.5편/시간 | 한 편의 대기시간 우선 |
| 2 GPU × 2 (인스턴스 2개가 GPU 2장씩 사용) | 158.2초 | 집계 관측 예 44.4편/시간 | 처리량과 프로세스 장애 격리 |
| 1 GPU × 4 (인스턴스 4개가 GPU 1장씩 사용) | 382.1초 | 집계 관측 예 36.5편/시간 | 작업별 실행기 격리 |
단건 지연만 보면 GPU를 한 인스턴스에 몰아준 4×1 구성이 가장 빠릅니다(88.8초). 그런데 서버 전체의 시간당 처리량은 오히려 2×2 구성이 44.4편으로 가장 높게 나왔습니다. GPU 4장을 인스턴스 하나에 몰아주면 요청 한 건을 빨리 끝내지만 그동안 다른 요청은 큐에서 기다려야 하고, GPU를 2장씩 쪼개 인스턴스 두 개로 나누면 개별 작업은 느려지는 대신 두 실행기가 동시에 돌면서 전체 처리량이 늘어납니다.
여기서 실무적으로 중요한 함정이 하나 있습니다. 산술적으로는 2×2 구성의 이론 처리량이 3600초 ÷ 158.2초 × 2대 ≈ 45.5편/시간으로 계산되는데, 실제 집계값은 44.4편/시간으로 이론값보다 살짝 낮습니다. 인스턴스를 여러 개 동시에 돌리면 디스크/CPU/메모리 경합이 생기기 때문에, 단일 인스턴스를 혼자 돌렸을 때의 지연시간에 인스턴스 수만 곱해서 처리량을 예측하면 실제보다 낙관적인 숫자가 나옵니다. 동시 부하를 걸어본 뒤의 실측값을 기준으로 용량을 산정해야 하는 이유입니다.
같은 4 GPU×1 배치에서 FP8+Turbo(9단계)로 바꾸면 단건 지연 43.0초, 처리량 약 83.7편/시간까지 올라갔고, 이걸 2×2로 나누면 단건 지연은 78.6초로 늘어나지만 처리량은 91.6편/시간으로 오히려 더 높아졌습니다. 즉 "지연시간을 줄이는 방향"과 "처리량을 늘리는 방향"은 같은 손잡이가 아니고, 서비스 요구사항이 "사용자가 결과를 빨리 받아야 하는가"인지 "단위 시간당 더 많은 영상을 처리해야 하는가"인지에 따라 정반대 구성을 골라야 합니다.
2. 샘플링 단계 수를 줄이면 얼마나 빨라지는가
같은 4 GPU/1344×768/5초 조건에서 샘플링 단계 수만 바꿔가며 측정했습니다.
| 정밀도/가속 | 샘플링 단계 | 처리 시간 |
|---|---|---|
| FP8 | 20단계 | 88.8초 |
| FP8 + Turbo | 9단계 | 43.0초 |
| FP8 + LightX2V | 5단계 | 23.6초 |
20단계에서 5단계로 줄이면 처리 시간이 약 3.8배 단축됩니다. 다만 이 비교는 처리 시간만 본 것이고 결과물 품질이 동등하다는 뜻은 아닙니다. 움직임 자연스러움, 얼굴/제품 일관성, 디테일, 오디오 동기화는 별도로 평가해야 하는 항목이라서, 샘플링 단계를 줄이는 최적화는 반드시 실제 출력물을 눈으로 확인한 뒤에 적용해야 합니다.
3. 해상도별 처리량 변화
같은 SGLang/4 GPU/FP8/20단계 조건에서 해상도만 1344×768에서 768×768로 낮췄을 때의 차이입니다(5초 영상 기준).
| 해상도 | 처리 시간 | 이론 편/시간 |
|---|---|---|
| 1344×768 | 88.8초 | 40.5 |
| 768×768 | 40.8초 | 88.2 |
해상도를 낮추는 것만으로 처리량이 2배 이상 늘어났습니다. 다만 이 이론 편/시간 값은 대기, 실패/재시도, 모델 전환, 업로드, 초해상도 후처리에 걸리는 시간을 제외한, 단일 인스턴스를 쉬지 않고 연속 실행했을 때의 산술값이라는 점을 감안해야 합니다. 실제 운영 환경에서는 이 값보다 낮게 나올 수밖에 없습니다. ComfyUI와 SGLang은 해상도 표기 방식과 실제 디노이징 단계가 다를 수 있어서, 두 엔진 사이의 숫자를 직접 비교하지 않고 같은 엔진 안에서의 상대 비교로만 썼습니다.
4. 실제 비용 계산: G6s 4×72GB 기준
처리량을 알아도 그 처리량이 얼마짜리인지 모르면 구성을 고를 수 없습니다. 완성 영상 한 편의 비용은 다음 식으로 근사합니다.
완성 1편 비용 ≈ 서버 비용 ÷ 실제 성공 편수 + 후처리/저장/전송 비용여기서 "GPU 시간당 단가"만 보고 판단하면 안 되는 이유가 이 식에 있습니다. 가동률과 생성 성공률이 분모에 들어가기 때문에, 같은 서버 단가라도 실패율이 높거나 GPU를 놀리는 시간이 많으면 완성 1편당 비용은 그만큼 올라갑니다.
이 테스트에 쓴 GPU 배치(4×72GB, PRO 5000 72GB)에 해당하는 G6s 인스턴스의 예시 단가는 다음과 같습니다.
| 계열 | vCPU / RAM | GPU | 시간당 예시 단가(CNY) |
|---|---|---|---|
| G6s | 128 / 384GB | 4 × 72GB | 82.41 |
이 단가와 앞서 측정한 처리량을 대입하면, 후처리/저장/전송 비용과 실패율을 아직 반영하지 않은 "GPU 처리 시간만의" 편당 원가가 나옵니다.
| 구성 | 시간당 처리량 | 편당 GPU 원가(CNY) |
|---|---|---|
| FP8 20단계 | 40.5편 | 82.41 ÷ 40.5 ≈ 2.03 |
| FP8+Turbo 9단계 | 83.7편 | 82.41 ÷ 83.7 ≈ 0.98 |
| FP8+LightX2V 5단계 | 152.5편 | 82.41 ÷ 152.5 ≈ 0.54 |
샘플링 단계를 20단계에서 5단계로 줄이면 같은 GPU 시간에 대한 편당 원가가 약 3.8배 낮아집니다. 여기에 실제 가동률(장비를 얼마나 쉬지 않고 돌렸는지)과 생성 성공률(재시도 없이 한 번에 성공하는 비율)을 반영하면 체감 비용은 이보다 높아집니다. 예를 들어 실제 가동률 90%, 생성 성공률 95%를 가정하면, FP8+Turbo 구성의 실질 편당 GPU 원가는 0.98 ÷ 0.90 ÷ 0.95 ≈ 1.15CNY로 올라갑니다. 여기에 초해상도 후처리, 결과물 저장(COS), 다운로드 전송 비용을 더해야 최종 "완성 1편" 비용이 나옵니다. 이 가동률/성공률 숫자는 계산 방식을 보여주기 위한 예시이며, 실제 값은 운영 중인 서비스에서 직접 재보고 넣어야 하는 값입니다.
한 가지 더 확인해야 할 변수는 메모리입니다. 2 GPU/FP8+LoRA 구성의 GPU당 메모리 사용량은 1344×768 기준으로 영상 길이가 5초→10초→15초로 늘어날 때 약 40.7GB→50.6GB→60.4GB로 늘어나고, Ref2VA 15초 조건에서는 약 64.6GB까지 올라간 사례도 있었습니다. 처리량만 보고 구성을 정하면 안 되는 이유가 여기 또 있습니다. 영상 길이를 늘리는 실험을 할 때는 처리 시간뿐 아니라 GPU 메모리 피크와 호스트 쪽 잠금 메모리도 함께 관찰해야, 실제 운영 중에 메모리 부족으로 작업이 실패하는 상황을 피할 수 있습니다.
정리
- 단건 지연시간과 시간당 처리량은 같은 손잡이로 조절되지 않습니다. 같은 GPU 4장이라도 인스턴스 하나에 몰아주면 지연시간이 가장 짧고(4×1: 88.8초), 2개로 쪼개면 처리량이 가장 높습니다(2×2: 44.4편/시간). 서비스 요구사항이 응답 속도인지 처리량인지에 따라 반대 구성을 골라야 합니다.
- 동시 부하를 건 실제 집계 처리량은 산술 이론값보다 낮게 나옵니다(2×2 FP8: 이론 45.5편/시간 vs 실측 44.4편/시간). 단일 인스턴스 지연시간에 인스턴스 수를 곱해 처리량을 예측하면 리소스 경합을 놓칩니다.
- 샘플링 단계 수를 20→9→5로 줄이면 처리 시간이 최대 3.8배 단축되지만, 결과물 품질 동등성은 보장되지 않으므로 실제 출력을 검수한 뒤 적용해야 합니다.
- 해상도를 1344×768에서 768×768로 낮추면 이론 처리량이 2배 이상 늘어납니다. 다만 이 값은 대기/재시도/후처리를 제외한 이론치이므로 실제 운영값은 이보다 낮습니다.
- 완성 영상 한 편의 비용은
서버 비용 ÷ 실제 성공 편수 + 후처리/저장/전송으로 계산해야 하며, GPU 시간당 단가만으로는 실제 원가를 알 수 없습니다. G6s 4×72GB(시간당 82.41CNY) 기준으로 FP8 20단계는 편당 약 2.03CNY, FP8+Turbo는 약 0.98CNY, FP8+LightX2V는 약 0.54CNY의 GPU 원가가 나왔고, 여기에 실제 가동률과 생성 성공률을 반영하면 체감 비용은 더 올라갑니다. - GPU 메모리 사용량은 영상 길이에 비례해서 늘어나므로(2 GPU FP8+LoRA 기준 5초 40.7GB → 15초 60.4GB), 처리 시간과 비용뿐 아니라 메모리 피크도 함께 확인해야 운영 중 실패를 막을 수 있습니다.
이어지는 실측은 다음 글에서 다룹니다.