LTX 2.5로 영상 해상도를 높이면 얼마나 더 기다려야 하고, GPU 메모리는 얼마나 더 사용할까요? Runpod의 RTX PRO 6000 Blackwell Server Edition 한 장에서 5초 길이의 영상을 요청하고, 세 해상도를 각각 5회 측정했습니다. 생성 시간 중앙값은 832×448에서 16.39초, 1280×704에서 25.65초, 1984×1088에서 54.87초였습니다.
짧은 영상을 반복해서 만들 때는 한 번의 대기 시간도 작업 속도에 영향을 줍니다. 이 글에서는 해상도를 고를 때 참고할 수 있도록 제가 Oh My GPU에서 진행한 실험의 생성 시간과 관측 VRAM을 비교합니다. 영상 품질이나 다른 GPU에서 실행했을 때의 속도까지 평가한 글은 아닙니다.
세 해상도의 생성 시간과 VRAM
아래에서 해상도를 선택하면 해당 조건의 측정값을 볼 수 있습니다. 실제로 측정한 세 가지 해상도만 제공하며, 그 사이의 해상도는 보간하거나 예측하지 않습니다.
2026.08.18 실측 · RTX PRO 6000 Blackwell 1장
해상도를 선택해 관측한 생성 시간과 메모리를 비교해 보세요. 새 영상을 생성하거나 성능을 예측하는 도구는 아닙니다.
1280 × 704 · warm 5회
- 생성 시간 중앙값
- 25.65초
- 5회 중 최단–최장
- 24.85–26.45초
- 최대 관측 VRAM
- 50.61GiB
해상도별 생성 시간 중앙값
막대는 0초부터 시작하며, 최장 중앙값인 54.87초를 전체 길이로 표시합니다.
해상도별 5회 기록 펼쳐보기
832 × 448
생성 시간(1→5회): 16.39 / 16.48 / 16.25 / 16.53 / 14.91초
중앙값 16.39초 · 최대 관측 VRAM 50.11 GiB
1280 × 704
생성 시간(1→5회): 26.45 / 25.65 / 25.99 / 25.36 / 24.85초
중앙값 25.65초 · 최대 관측 VRAM 50.61 GiB
1984 × 1088
생성 시간(1→5회): 56.87 / 54.87 / 58.80 / 54.33 / 54.61초
중앙값 54.87초 · 최대 관측 VRAM 50.86 GiB
시간은 생성 래퍼 프로세스 시작부터 종료까지이며 최초 로딩과 warm-up은 제외했습니다. VRAM은 100ms 간격 장치 샘플의 최대값으로, 필요한 최소 GPU 용량을 뜻하지 않습니다.
832×448에서 1984×1088로 바꾸면 출력 픽셀 수는 약 5.79배가 됩니다. 이때 생성 시간 중앙값은 약 3.35배로 늘었습니다. 두 배수는 측정 조건과 기록에서 계산한 값이지, 앞으로 어떤 해상도를 넣어도 적용되는 비례식은 아닙니다.
중간 해상도인 1280×704는 중앙값 25.65초로, 1984×1088의 54.87초보다 대기 시간이 짧았습니다. 정확한 출력 규격이 정해지지 않았고 대기 시간을 먼저 줄이고 싶다면 낮은 해상도부터 시작하는 편을 권합니다. 다만 낮은 해상도에서 확인한 장면이나 구도가 높은 해상도에서도 그대로 나온다는 뜻은 아닙니다.
5초 요청, 같은 프롬프트, 해상도별 5회
측정일은 2026년 8월 18일입니다. GPU는 RTX PRO 6000 Blackwell Server Edition 한 장을 사용했습니다.
- 모델: LTX 2.5 22B distilled, INT8 ConvRot
- 실행 환경: ComfyUI 0.33.0, SageAttention 사용
- 영상 길이: 5초 요청, 24fps, 121프레임
- 워크플로: 1차 샘플링 8스텝, latent 업스케일 3스텝, 프롬프트 강화 사용
- 입력: 같은 프롬프트(P01)를 유지하고, 반복 회차마다 시드를 변경
- 집계: 해상도별 warm 실행 5회, 총 15회
여기서 warm 실행은 모델 로딩과 사전 실행을 거친 상태의 반복 생성입니다. 처음 모델을 불러오는 실행과 해상도별 warm-up, 실패한 실행, 별도로 만든 품질 확인용 영상은 속도 집계에서 제외했습니다.
또한 1984×1088은 정확한 1920×1080이 아닙니다. 이 글의 숫자를 그대로 “1080p 생성 시간”으로 옮겨 쓰면 측정 조건이 달라집니다. 출력 규격이 정해져 있다면 그 크기로 별도 측정해야 합니다.
캐시된 결과가 아닌 반복 생성의 시간
같은 시드로 같은 ComfyUI 워크플로를 반복하면 노드 캐시가 이전 결과를 재사용할 수 있습니다. 그런 실행을 섞으면 실제로 영상을 새로 만드는 시간보다 짧게 보일 수 있는데요. 이번 집계에서는 회차마다 시드를 424243부터 424247까지 바꿔 샘플링 이후 단계를 다시 실행했습니다. 같은 회차의 세 해상도에는 같은 시드를 사용했습니다.
모델 로딩과 동일 텍스트 인코딩은 warm 상태를 유지했습니다. 따라서 이 결과는 이미 준비된 같은 워크플로에서 시드를 바꿔 반복 생성한 시간입니다. 매번 새로운 프롬프트를 넣거나 서버를 새로 시작하는 작업의 지연과는 구분해서 봐야 합니다.
표시한 시간의 경계는 생성 래퍼 프로세스 시작부터 종료까지입니다. ComfyUI 내부 샘플링 시간만 떼어낸 숫자가 아니며, Pod 생성·환경 설치·모델 다운로드부터 사용자가 영상을 확인하기까지의 전체 대기 시간도 아닙니다.
해상도를 낮춰도 약 50GiB였던 관측 VRAM
생성 시간은 해상도에 따라 달라졌지만, 최대 관측 VRAM은 50.11GiB, 50.61GiB, 50.86GiB로 차이가 작았습니다. 이 구성에서는 출력 해상도를 낮춘 만큼 메모리도 비례해서 줄지는 않았습니다.
메모리는 100ms 간격으로 nvidia-smi 장치 전체 사용량을 수집하고 최대 샘플을 골랐습니다. 프레임워크가 기록한 정확한 메모리 피크는 아닙니다. 샘플 사이에 더 짧은 피크가 있었다면 놓칠 수 있습니다.
이 수치만으로 “51GiB면 충분하다”거나 “48GB GPU에서는 실행할 수 없다”고 결론 내릴 수는 없습니다. 이번에 확인한 것은 해당 GPU와 워크플로에서 관측한 사용량입니다. 다른 GPU나 메모리 오프로딩 설정을 썼을 때의 성공 여부와 속도는 이 실험의 확인 범위 밖입니다.
같은 기준으로 따라 해보기
설정과 실행 코드는 OMG Runpod Media의 LTX 2.5 레시피에 모아뒀습니다. 글의 근거를 나중에도 확인할 수 있도록 특정 커밋에 연결했습니다.
레시피에는 ComfyUI UI·API 워크플로, 모델 다운로드 스크립트, 프롬프트, 실행 행렬이 들어 있습니다. 다음 순서로 보면 어떤 조건을 맞춰야 하는지 파악하기 쉽습니다.
README.md에서 모델 배치와 실행 조건을 확인합니다. 모델 파일은 저장소에 포함되어 있지 않으므로 사용 조건과 접근 권한도 확인해야 합니다.workflows/에서 사용한 그래프를 확인하고,inputs/prompts.json의 P01 입력을 맞춥니다.inputs/run-matrix.csv에서warm행의 해상도와 시드를 확인합니다. 최초 로딩과 warm-up은 반복 생성 통계에서 분리합니다.- 결과에는 GPU, 워크플로, 생성 시간의 시작·종료 기준, 반복 횟수, VRAM 수집 방법을 함께 남깁니다.
브라우저에서 위 결과를 선택하는 것에는 GPU가 사용되지 않습니다. 반면 레시피를 실제 Runpod 자원에서 실행하면 GPU와 저장 공간 비용이 발생할 수 있습니다. 이 글에는 현재 요금이나 실제 청구 비용을 계산한 결과를 포함하지 않았습니다.
출력 규격보다 반복 속도가 먼저라면
이번 구성에서 1984×1088은 중앙값 54.87초, 832×448은 16.39초였습니다. 해상도를 낮추면 기다리는 시간은 줄었지만 관측 VRAM은 여전히 약 50GiB였죠. 빠르게 반복하려고 해상도를 낮추는 판단과, 더 작은 GPU로 옮길 수 있다는 판단은 구분해야 합니다.
같은 환경에서 출력 규격이 아직 정해지지 않은 작업을 시작한다면, 대기 시간이 가장 짧았던 832×448을 먼저 선택하겠습니다. 더 큰 출력이 필요할 때 1280×704나 1984×1088로 올리되, 이 글의 warm 생성 시간과 최초 실행 대기 시간을 따로 보고 작업 계획을 잡는 편을 권합니다.
이 글은 김진의가 Oh My GPU에서 진행한 실험과 공개 GitHub 레시피를 바탕으로 커뮤니티용으로 재구성했습니다. Runpod 공식 벤치마크가 아니며, 커뮤니티 공동 측정 결과로 제시하지 않습니다. 원본 실험 레시피와 측정 요약을 함께 확인할 수 있습니다.