품질 하락을 숫자로 확인하는 SDXL 실측 벤치마크
요약: SDXL 실측 벤치마크란 이미지 생성 속도(images/min)와 프롬프트 정답률, 그리고 VRAM 상주·여유량 같은 자원 지표를 동일한 하드웨어와 설정에서 반복 측정해 '품질 하락'을 주관적 인상이 아니라 재현 가능한 숫자로 드러내는 성능 평가 절차를 말한다. 초보자가 로컬 AI를 다룰 때 가장 흔히 놓치는 지점은, 느려지거나 그림이 이상해지는 현상을 '체감'으로만 기억한다는 것이다. 벤치마크는 그 체감을 처리량·정답률·자원의 세 축으로 나눠 기록한다.
SDXL 실측 벤치마크란 이미지 생성 속도(images/min)와 프롬프트 정답률, 그리고 VRAM 상주·여유량 같은 자원 지표를 동일한 하드웨어와 설정에서 반복 측정해 '품질 하락'을 주관적 인상이 아니라 재현 가능한 숫자로 드러내는 성능 평가 절차를 말한다. 초보자가 로컬 AI를 다룰 때 가장 흔히 놓치는 지점은, 느려지거나 그림이 이상해지는 현상을 '체감'으로만 기억한다는 것이다. 벤치마크는 그 체감을 처리량·정답률·자원의 세 축으로 나눠 기록한다.
설치된 체크포인트 수 32 개
Hax가 자체 인프라에서 직접 측정한 실측값은?#
아래는 Hax가 자체 인프라에서 직접 계측·공개한 참고 수치입니다(측정값, 출처 표기).
| 데이터 항목 | 실측값 | 날짜 | 출처 |
|---|---|---|---|
| 최대 VRAM 상주(스냅샷) | 84.8 GB | 2026-07-04 | bench_harness.probe_comfy_gpus (bc_comfy_gpus 실측) |
| 카드당 총 VRAM | 95.6 GB | 2026-07-04 | bench_harness.probe_comfy_gpus (bc_comfy_gpus 실측) |
| 설치된 체크포인트 수 | 32 개 | 2026-07-04 | bench_harness.probe_comfy_models (bc_comfy_models 실측) |
- 표본
- 실측 지표 3개 (Hax /data 큐레이션)
- 측정 환경
- bench_harness.probe_comfy_gpus (bc_comfy_gpus 실측)
- 수집일
- 2026-07-04
- 방법
- bench_harness.probe_comfy_models (bc_comfy_models 실측)
이 수치는 어떻게 재현하나?#
측정 방법은 표의 출처와 우리 공개 데이터셋(/data)에서 확인할 수 있습니다.
| 지표 | Hax 우리 값 | 라벨 |
|---|---|---|
| 최대 VRAM 상주(스냅샷) | 84.8 GB | 측정 |
| 최소 여유 VRAM(풀 최저) | 10.2 GB | 측정 |
| 카드당 총 VRAM | 95.6 GB | 측정 |
| GPU 카드 수 | 4 장 | 측정 |
| 최대 GPU 사용률 | 95 % | 측정 |
| 설치 체크포인트 | 32 개 | 측정 |
| 설치 LoRA | 63 개 | 측정 |
| 설치 샘플러 | 44 종 | 측정 |
| 설치 ControlNet | 15 개 | 측정 |
| SDXL 처리량(images/min) | not measured / 측정대기 | 미보고(추정) |
| 프롬프트 정답률 | not measured / 측정대기 | 미보고(추정) |
최대 VRAM 상주(스냅샷) 84.8 GB
표에서 확인되듯 우리 환경은 카드당 총 VRAM 95.6 GB(측정) 중 최대 84.8 GB(측정)까지 상주가 올라가고, 풀 최저 여유는 10.2 GB(측정)까지 떨어진다. 즉 여유 마진이 약 10 GB 안팎으로 얇아지는 순간이 존재한다는 뜻이며, 이 구간에서 GPU 사용률은 최대 95 %(측정)에 닿는다. 품질 하락은 바로 이 경계에서 시작되는 경우가 많다. VRAM이 부족해지면 프레임워크가 일부 텐서를 시스템 메모리로 밀어내거나 배치를 쪼개는데, 이때 처리량(images/min)이 급감하고 해상도·스텝을 줄이도록 강제되어 결과물의 디테일이 무너진다.
품질을 숫자로 보려면 세 축을 반드시 분리한다. 첫째는 처리량으로, 분당 생성 이미지 수(images/min)다. 우리 환경의 처리량은 아직 측정대기 상태이므로 본문에서 특정 수치를 제시하지 않는다(측정대기). 둘째는 정답률로, '프롬프트가 지시한 요소가 실제 이미지에 들어갔는가'를 사람이 채점한 비율이다. 예컨대 100장 중 프롬프트의 핵심 지시(대상, 개수, 색, 구도)를 모두 만족한 장수를 세면 된다. 셋째는 자원으로, 위 표의 VRAM 상주·여유·GPU 사용률(모두 측정)이 여기에 해당한다.
정답률을 채점할 때는 오류를 유형으로 분류해 두면 하락 원인을 추적하기 쉽다. 대표적인 SDXL 오류 예시는 다음과 같다. (1) 손가락·팔다리 개수 오류, (2) 요청한 글자가 깨지거나 다른 글자로 생성되는 텍스트 붕괴, (3) '빨간 우산'을 요청했는데 색이 뒤바뀌는 속성 누수, (4) 두 인물을 요청했는데 한 명만 나오는 개수 무시, (5) VRAM 압박 구간에서 스텝이 줄며 나타나는 노이즈 잔상. 이 다섯 유형을 표로 세어 두면, 정답률이 떨어졌을 때 그것이 모델(체크포인트) 문제인지, LoRA 과다 적용인지, 샘플러 선택인지, 아니면 자원 부족인지 구분할 근거가 생긴다. 우리 환경에는 체크포인트 32개·LoRA 63개·샘플러 44종·ControlNet 15개(모두 측정)가 설치돼 있어 조합 경우의 수가 많고, 그만큼 '어떤 조합에서 정답률이 떨어지는가'를 고정 프롬프트 세트로 반복 측정하는 것이 중요하다.
실무 절차는 단순하다. 고정 프롬프트 20~50개를 정하고, 같은 시드·같은 스텝으로 반복 생성하면서 위 세 축을 함께 기록한다. VRAM 여유가 10.2 GB(측정) 근처로 내려가는 시점과 정답률·처리량이 꺾이는 시점을 겹쳐 보면, 품질 하락이 '자원 병목'에서 오는지 '모델·설정 선택'에서 오는지 눈으로 분리된다. 이렇게 숫자로 남겨 두면 다음 최적화(배치 축소, LoRA 정리, 샘플러 교체)의 효과도 같은 척도로 재검증할 수 있다.
참고: 위 자원 수치는 2026-07-04 단일 스냅샷 측정값이며, 처리량·정답률은 아직 측정대기 상태다. 드라이버·모델 구성이 바뀌면 재측정이 필요하다.
근거: Hax data의 bc_comfy GPU/모델 프로브 결과. 표의 모든 '측정' 값은 2026-07-04 bench_harness.probe_comfy_gpus·probe_comfy_models 실측이며, '측정대기'로 표시한 처리량·정답률은 본 글에서 수치를 제시하지 않는다.
함께 읽기: 처음 SDXL, 실측 VRAM과 설치 실패 지점으로 판단하기, 로컬 이미지 생성, 2026년 FLUX·SDXL 중 무엇을 골라야 하나?
종합 가이드: 노트북에서 돌리는 AI 모델, 흔한 함정과 해결법
Responses
No responses yet. Be the first to respond.