업스케일에서 서버가 18분 멈췄다 — 범인은 VRAM 이 아니라 시스템 RAM
96GB GPU 가 있는데도 영상 업스케일에서 서버가 응답 불능 — 픽셀 업스케일의 RAM 공식(frames×W×H×scale²×12B)과 WDDM fallback 이 겹친 사고의 경위와 조치.
영상 생성 서버(Windows, RTX Pro 6000 Blackwell 96GB)가 새벽에 18분간 응답 불능이 됐습니다. GPU 메모리가 96GB 나 되는 머신인데, 원인은 VRAM 이 아니라 시스템 RAM 이었습니다. 이벤트 로그로 확정한 경위와, 같은 함정을 피하는 계산식을 남깁니다.
경위 (윈도 이벤트 로그 + 직전 로그로 확정)
- 03:40:57 — 인코딩 전 픽셀 업스케일(
ImageUpscaleWithModel, RCAN 2x)이 12GB 의 CPU(시스템 RAM) 연속 할당에 실패 —DefaultCPUAllocator: not enough memory: 12,039,487,488 bytes. 예외는 잡혀서 프로세스는 살아 있었습니다. - 03:41:00 — RAM 이 마른 상태에서 곧바로 다음 작업의 텍스트 인코더 15GB 로드 시작.
- 03:41:02 — 로그 무기록, 18분간 정지. 페이징 스래싱입니다. GPU 드라이버 타임아웃(TDR)도 아니고(nvlddmkm 이벤트 0건), 크래시도 아니었습니다(Application Error 0건).
"업스케일에서 죽었다"는 보고를 받으면 반사적으로 VRAM 을 의심하기 쉽지만,
TDR·크래시 이벤트가 없는데 CPUAllocator 할당 실패 메시지가 있다면 시스템 RAM
부족입니다. 이 구분이 사고 조사의 갈림길이었습니다.
근본 원인 — 픽셀 업스케일의 RAM 공식
프레임 단위 픽셀 업스케일러는 전체 배치를 GPU 로 올린 뒤 float32 출력 전체를 CPU 메모리에 할당합니다:
RAM ≈ frames × W × H × scale² × 12 bytes
4x 배율로 10초(1728×960 기준) 영상을 올리면 72GB 입니다. 여기에 Windows WDDM 모드의 sysmem fallback 이 VRAM 압박까지 시스템 RAM 으로 전가해 증폭시킵니다 — 96GB VRAM 이 "여유"가 아니라 RAM 잠식의 통로가 되는 구조입니다.
조치의 변천 — 상한에서 제거까지
- 픽셀 업스케일에서 4x 제거, 2x 만 유지 + 입력 15초(368프레임) 상한
- 고배율·고품질 업스케일은 latent 경로(LTX IC-LoRA 재작화)로 분리 — RAM 소모가 프레임 크기에 비례하지 않음
- 최종적으로 픽셀 업스케일 작업판 자체를 제거 — 프레임만 보고 키우는 방식은 영상 처리 관점의 판단이 빠져 있다는 결론
교훈
- 프레임 수 × 해상도 × 배율² 은 작업을 받기 전에 선계산해서 상한으로 강제할 것. 실패하고 나서 잡는 예외는 다음 작업(15GB 로드)을 막지 못했습니다
- 같은 프레임 단위 방식을 쓰는 다른 경로(생성 직후 "인코딩 전 업스케일" 옵션)에도 같은 공식이 그대로 적용됩니다 — 한 곳의 사고 원인은 같은 방식 전부에서 찾아볼 것
이 서버의 H3 가속 실측은 별도 글에 있습니다.