영상 업스케일 중 서버가 18분 멈춘 원인은 시스템 RAM이었습니다

영상 생성 서버(Windows, RTX Pro 6000 Blackwell 96GB)가 새벽에 18분 동안 응답하지 않았습니다. GPU 메모리가 96GB나 되는 기계였는데, 모자란 건 VRAM이 아니라 시스템 RAM이었습니다. Windows 이벤트 로그로 확인한 경위와 다시 겪지 않으려고 쓰는 계산식을 적어 둡니다.

경위

03:40:57, 인코딩 전에 돌리는 픽셀 업스케일(ImageUpscaleWithModel, RCAN 2x)이 시스템 RAM 12GB를 연속으로 할당하지 못했습니다. 로그에는 DefaultCPUAllocator: not enough memory: 12,039,487,488 bytes가 남았습니다. 예외는 잡혀서 프로세스는 살아 있었습니다.
03:41:00, RAM이 바닥난 상태에서 곧바로 다음 작업의 텍스트 인코더 15GB를 읽기 시작했습니다.
03:41:02부터 로그가 끊기고 18분 동안 멈췄습니다. 페이징 스래싱이었습니다. GPU 드라이버 타임아웃(TDR) 이벤트는 0건이었고, 프로세스 크래시 이벤트도 0건이었습니다.

"업스케일하다 죽었다"는 보고를 받으면 VRAM부터 의심하게 됩니다. 이번에는 TDR과 크래시 이벤트가 없고 CPUAllocator 할당 실패가 있다는 점에서 시스템 RAM 쪽으로 방향을 잡을 수 있었습니다.

원인: 픽셀 업스케일의 RAM 사용량

프레임 단위 픽셀 업스케일러는 전체 배치를 GPU에 올린 다음, float32로 된 출력 전체를 CPU 메모리에 할당합니다.

RAM ≈ frames × W × H × scale² × 12 bytes

1728×960 영상 10초를 4배로 올리면 72GB가 필요합니다. 여기에 Windows WDDM 모드의 sysmem fallback이 VRAM 부족분까지 시스템 RAM으로 넘기니, VRAM이 크다는 것이 오히려 RAM을 더 쓰게 되는 통로가 됐습니다.

조치

처음에는 픽셀 업스케일에서 4배를 없애고 2배만 남긴 뒤 입력을 15초(368프레임)로 제한했습니다. 고배율·고품질 업스케일은 LTX IC-LoRA로 다시 그리는 latent 방식 구성으로 옮겼는데, 이 방식은 RAM 사용량이 프레임 크기에 비례하지 않습니다. 결국 픽셀 업스케일 구성은 없앴습니다. 프레임만 보고 크기를 키우는 방식으로는 영상 처리로서 할 수 있는 판단이 한정된다는 결론이었습니다.

생성 직후에 붙어 있는 "인코딩 전 업스케일" 옵션도 같은 프레임 단위 방식이라 위 계산식이 그대로 적용됩니다. 이번 사고도 그 옵션에서 났습니다.

프레임 수, 해상도, 배율의 제곱을 곱한 값은 작업을 받기 전에 계산해서 상한으로 막아야 했습니다. 실패한 뒤 예외를 잡는 것만으로는 바로 이어진 15GB 로드를 막지 못했습니다.

이 서버의 H3 가속 측정은 별도 글에 있습니다.