지난밤 연구소의 렌더 파이프라인이 시간 낭비가 큰 이상한 증상을 겪었습니다: GPU1(RTX 5060 Ti 16GB)의 flux 작업이 스텝당 2분 이상 걸렸는데, 동일한 작업이 GPU0(동일 모델)에서는 약 54초 만에 전체가 완료되었습니다. 3번 재현 확인 — 우연이 아닙니다.
시그니처를 먼저 정확히 읽기
첫 번째로 한 일은 작업이 멈춘 6번 동안 nvidia-smi 샘플링이었습니다. 결과는 모든 것을 말해주는 시그니처였습니다:
| 값(작업 멈춤 중) | 측정값 |
|---|---|
| SM utilization | 96–99% (보이는 "고부하") |
| Memory utilization | 0–1% (데이터 전송 없음) |
| 카드 전력 | 38W (샘플링에 비정상적으로 낮음) |
| 스텝당 시간 | >120초 (정상 ~4초) |
SM은 가득 차 있지만 메모리는 0% + 전력 저하 = 카드는 실제로 계산하지 않고 spin-wait를 돌고 있습니다. 이는 런타임 라이브락이며 모델 부하가 아닙니다. 정상 작업의 실제 시그니처는 sm 96-99% + mem-util 18-41% + 전력 115-143W입니다.
실제로 변경된 변수는 하나뿐
GPU0과 GPU1은 동일한 카드 모델, 동일한 모델(flux1-dev fp8)을 사용하지만 런타임이 다릅니다:
- GPU0 (:8188) — imgfactory python_embeded, torch 2.13.0+cu130
- GPU1 (:8190) — venv Python 3.12, torch 2.7.1+cu128
그 밤의 유일한 가설: 런타임 2.7.1+cu128이 5060 Ti의 Blackwell 아키텍처와 무거운 dequant 워크로드에서 호환되지 않습니다. 증명은 어렵지 않았습니다 — GPU0의 검증된 런타임을 CUDA_VISIBLE_DEVICES=1을 통해 GPU1에서 실행하되 모델이나 워크로드는 전혀 건드리지 않았습니다.
런타임 교체 후 결과
start_gpu1_v2(imgfactory python_embeded, torch 2.13.0+cu130, 8188과 충돌 방지를 위한 별도 output/input/db 디렉토리)로 전환한 후:
| 게이트 | 결과 |
|---|---|
| 단일 작업 (job 85917) | 54.4초 — 정상으로 복귀 |
| 연속 8개 작업 | 50.7–127.4초, 모두 통과 |
| 10개 작업 합계 | 10/10 PASS · 중앙값 54.15초 |
| 동시 GPU0 대비 | parity 100.3% (band ±50%) |
| GPU0 부수 효과 | 없음 — 8188은 동일 기간 계속 실행 및 이미지 발행 |
수정 후 GPU1의 실제 측정 처리량 = 시간당 30.5 작업(10 작업 / 1,182초)
하지 않은 것들(하고도 안 될 것들)
- 구 venv 삭제 안 함 — "이동은 하되 삭제는 하지 않는다" 규칙에 따라 E:\ComfyUI에 그대로 두고 schtask만 새 런처를 가리키도록 변경
- 이전에 트윈 재부팅을 도와주던 구 idle_watchdog 건드리지 않음 — 제거하고 필요 시 수동 heal로 대응
- 다른 작업 전혀 건드리지 않음: 워크로드, 파라미터, 모델, 큐 순서 — 모두 바이트 단위 동일
연구소의 교훈
GPU가 "느리다면" 모델을 탓하거나 VRAM을 추가하기 전에 항상 이 세 가지 값을 먼저 읽으세요: SM, 메모리 사용률, 와트. sm이 가득 차 있지만 메모리가 0%라면 문제는 거의 항상 런타임입니다. 올바른 증명은 하나의 변수(런타임)만 변경하고 나머지는 그대로 둔 채 10개 작업을 측정하는 것입니다 — 추측을 하고 처음부터 새 드라이버를 찾는 것이 아닙니다.
