핵심 요약
1
PRO 6000의 ComfyUI 3프로세스 총처리량은 단일 워커 직렬 처리보다 1.9% 낮았습니다.
2
RTX 5090은 영상 100개당 GPU 비용이 약 $0.535로, 이번 고정 조건에서 가장 저렴했습니다.
3
96GB의 가치는 동일 작업 3배 가속보다 32GB 초과 작업과 OOM 여유에 있었습니다.
96GB RTX PRO 6000에 ComfyUI 프로세스를 세 개 띄우면 32GB RTX 5090 세 장처럼 빠르게 영상을 처리할 수 있을까요? RTX 5090 한 장과 RTX PRO 6000 한 장을 놓고, LTX-2.5 22B I2V로 생성 속도와 총처리량, 영상당 GPU 비용을 비교했습니다.
프로세스 세 개는 정상적으로 올라갔고 세 작업도 모두 끝났는데요. 총처리량은 PRO 6000 단일 워커가 차례로 처리할 때보다 1.9% 낮았습니다. VRAM 산수는 맞았지만 GPU 연산은 나눗셈대로 움직이지 않았습니다.
96GB를 32GB씩 나눠 쓰려던 실험
RTX 5090의 32GB VRAM으로도 LTX-2.5 22B는 실행됐지만, 여유는 거의 없었습니다. warm run은 약 29.7GB를 사용했고, 첫 성공에서는 31,766MiB까지 올라갔습니다. 고정된 작업만 큐로 받는다면 5090도 충분히 쓸 수 있지만 해상도나 프레임을 조금만 늘려도 OOM을 걱정해야 하는 수준입니다.
RTX PRO 6000 Blackwell Server Edition은 96GB GDDR7 ECC 메모리를 제공합니다. 이 96GB를 32GB씩 나눠 쓰면 5090 세 장을 빌린 효과가 날지 확인하고 싶었는데요. 이번 실험에서는 PRO 6000 한 장 위에서 ComfyUI 구성만 셋으로 나눴습니다. NVIDIA 하드웨어 자체는 MIG를 지원하지만 이번 Runpod Pod에서는 MIG 프로파일을 나누지 않았고, 포트 3000, 3001, 3002에 독립된 ComfyUI API 프로세스를 띄워 모델과 입력 폴더만 공유했습니다. 출력, 임시 파일, 사용자 폴더와 큐는 프로세스별로 분리했습니다.
세 프로세스가 같은 GPU를 바라보는 소프트웨어 멀티플렉싱입니다. 메모리 용량은 함께 쓰지만 CUDA 연산 자원과 대역폭은 그대로 한 장분입니다.
LTX-2.5 I2V 비교 조건
속도를 비교할 때 워크플로가 달라지면 GPU보다 설정 차이를 재게 됩니다. 그래서 두 GPU에 같은 입력 이미지, 모델 revision과 API 워크플로를 사용했습니다.
비용은 각 실행의 wall time에 시간당 가격을 곱했습니다. 이미지 pull과 약 39.7GB 모델 다운로드, Pod idle, 스토리지 비용은 뺐습니다. 실제 청구액과는 다른, 생성 구간만 떼어 비교하기 위한 값입니다.
32GB를 거의 다 쓴 RTX 5090
RTX 5090에서는 서로 다른 seed의 warm generation 두 번이 각각 18.095초와 20.805초 걸렸습니다. 평균은 19.450초, 분당 처리량은 3.085개였습니다. 영상 100개를 같은 속도로 연속 생성한다고 가정하면 GPU 실행비는 약 $0.535입니다.
첫 성공 때 VRAM 사용량이 31,766MiB까지 올라갔는데요. 32GB에서 실행은 됐지만 여유라고 부를 만한 공간은 거의 남지 않았습니다. 해상도와 프레임, 추가 업스케일 노드까지 고정한 전용 큐에 더 잘 맞는 구성이죠.
한 작업은 38% 빨랐던 RTX PRO 6000
PRO 6000에 PyTorch attention을 사용한 단일 warm 워커는 세 번의 영상을 각각 12.176초, 12.363초, 11.521초에 만들었습니다. 평균 12.020초로 RTX 5090보다 wall time이 38.2% 짧았고, 처리량은 분당 4.992개였습니다.
속도 차이는 분명했습니다. 다만 시간당 가격이 5090의 약 2.11배였는데요. 영상 100개당 생성 구간 비용은 약 $0.698로 5090보다 30.5% 높았습니다. 이 고정 작업 기준으로 PRO 6000은 한 작업을 더 빨리 끝내는 대신 영상당 비용이 높은 선택지였습니다.
세 프로세스를 띄워도 늘지 않은 총처리량
모델을 세 프로세스에 차례로 올린 뒤 서로 다른 seed의 작업 세 개를 거의 동시에 제출했습니다. 이 배치를 세 번 반복했으며 제출 시작 시각 차이는 0.002초 안팎이었습니다.
단일 PRO 6000 워커의 wall time으로 계산한 직렬 처리량은 분당 4.992개였습니다. 세 프로세스를 동시에 돌린 결과는 분당 4.895개로 1.9% 낮았는데요. 이 정도 차이는 배치별 편차 안에 있어서 어느 방식이 더 빠르다고 잘라 말할 수 없습니다. 적어도 프로세스를 세 개 띄워 3배 처리량을 얻는 그림은 나오지 않았습니다.
개별 작업의 Comfy 실행 시간은 단일 워커 평균 10.607초에서 동시 실행 평균 33.977초로 길어졌습니다. 세 요청을 한꺼번에 받는 대신, 각 사용자가 결과를 기다리는 시간은 약 세 배가 된 셈입니다.
VRAM은 더 아슬아슬했습니다. 최대 97,243MiB를 사용했고 남은 메모리가 9MiB까지 떨어졌습니다. 프로세스별 상주 메모리도 균등하지 않았는데요. Docker 컨테이너나 프로세스를 나눈다고 VRAM quota와 연산 공정성이 생기지는 않기 때문입니다.
SageAttention을 이미지에 미리 구워 넣은 이유
SageAttention은 런타임마다 컴파일하지 않았습니다. CUDA 서버에서 SageAttention 2.2.0을 Blackwell
sm_120용 wheel로 한 번 빌드한 뒤, ComfyUI 이미지 위에 설치해 immutable digest로 고정했습니다.wlsdml1114/engui_comfy@sha256:ef37e9680c9772889ca66c3a0895c7d6db0fccbcb5e70e7ef8b63bcd440708da같은 환경을 직접 띄워보고 싶다면 LTX-2.5 ComfyUI 3-Worker CUDA 13 Runpod 템플릿을 사용할 수 있습니다. Runpod Secrets에 본인의
HF_TOKEN을 먼저 등록해야 하며, 모델 파일은 이미지에 포함되어 있지 않습니다.CUDA compiler와 개발 헤더는 builder에만 두고 runtime 이미지에는 넣지 않았습니다. Runpod Secret은 이미지에 저장하지 않고 배포 시 참조로 주입했습니다. 실제 PRO 6000에서 이미지 pull, Sage import, 세 워커 기동과 I2V cold smoke까지 다시 확인했습니다.
배포는 깔끔해졌지만 이번 워크로드의 속도는 빨라지지 않았습니다.
세 프로세스 처리량의 1.9% 차이는 배치 편차보다 작았습니다. Sage를 기본값으로 바꿀 근거는 얻지 못한 셈이죠. 공식 저장소가 RTX 5090에서 제시한 2.7배 수치는 FlashAttention2와 비교한 attention kernel 성능입니다. LTX-2.5 전체 워크플로의 end-to-end 생성 시간이 2.7배 빨라진다는 뜻은 아닙니다.
같은 seed로 만든 PyTorch와 Sage 영상 세 쌍도 bit-identical하지 않았습니다. PSNR은 27.20~32.53dB, SSIM은 0.911~0.959였습니다. 세 개의 짧은 영상만으로 품질 동등성을 주장할 수는 없습니다.
SageAttention은 prebuilt 이미지에 선택 사항으로 남겼습니다. 기본 워커는 PyTorch attention으로 실행하고, 모델이나 워크플로가 바뀔 때만 Sage를 다시 A/B하는 편이 낫습니다.
영상 100개를 만들 때 달라지는 선택
고정된 LTX-2.5 작업을 한 줄의 큐로 처리한다면 RTX 5090 워커를 선택하겠습니다. 작업 하나당 비용이 낮고, GPU마다 ComfyUI 워커를 하나씩 두면 장애와 메모리도 물리적으로 분리됩니다.
PRO 6000이 필요 없어지는 것은 아닙니다. 32GB를 넘는 해상도·프레임·길이, 업스케일과 프레임 보간을 연결한 복합 워크플로, 여러 모델 상주, OOM보다 작업 성공률이 중요한 큐에서는 96GB가 선택지를 넓힙니다. 기존 Oh My GPU 테스트에서도 별도의 Two-Stage 워크플로로 1984×1088 영상을 만들 때 VRAM이 50.86GiB까지 올라갔습니다. 그런 작업은 애초에 32GB 5090 구성과 같은 출발선에 놓을 수 없습니다.
이번 측정에서 PRO 6000의 96GB는 같은 작업의 처리량을 세 배로 늘려 주지 않았습니다. 대신 32GB GPU가 받지 못하는 작업을 수용하는 쪽에서 쓸모가 있었죠. 같은 5초짜리 832×448 영상을 반복한다면 5090의 영상당 비용을 먼저 보고, 출력 크기와 파이프라인이 32GB를 넘기 시작할 때 PRO 6000으로 넘기는 2단 큐가 현실적인 구성입니다.
자주 묻는 질문
GPU 한 장에서 ComfyUI를 여러 개 실행할 수 있나요?
가능합니다. 포트와 output, temp, user 폴더를 분리해 독립 API와 큐로 실행할 수 있습니다. 다만 프로세스들이 같은 CUDA 연산 자원과 VRAM 풀을 공유하므로 처리량과 메모리 공정성은 보장되지 않습니다.
Docker 컨테이너를 세 개 띄우면 VRAM도 32GB씩 나뉘나요?
아닙니다. 별도 MIG나 GPU 가상화 계층 없이 컨테이너와 프로세스만 나누면 VRAM은 동적으로 공유됩니다. 이번 실행에서도 프로세스별 상주량은 균등하지 않았고 전체 여유가 9MiB까지 떨어졌습니다.
SageAttention은 항상 영상 생성을 빠르게 만드나요?
이번 LTX-2.5 테스트에서는 그렇지 않았습니다. 단일 워커는 오히려 5.1% 느렸고, 3프로세스 처리량의 1.9% 개선은 실행 편차 안에 있는 수준이었습니다. 모델, sequence 길이와 워크플로별 A/B가 필요합니다.
RTX PRO 6000은 언제 선택할 만한가요?
한 작업이 32GB를 넘거나 여러 모델을 VRAM에 상주시켜야 할 때, 복합 워크플로의 OOM 여유가 필요할 때 선택할 만합니다. 동일한 약 32GB 작업의 처리량만 높이려는 목적이라면 독립 GPU 워커 여러 개와 먼저 비교하는 편이 낫습니다.
🔗 References
- [1]NVIDIA RTX 5090 공식 사양↗
- [2]NVIDIA RTX PRO 6000 Blackwell Server Edition 공식 사양↗
- [3]Lightricks LTX-2.5 모델 카드↗
- [4]SageAttention 공식 저장소↗
- [5]ComfyUI SageAttention CLI 옵션↗
- [6]ComfyUI attention dispatch와 fallback 구현↗
- [7]RTX PRO 6000 Blackwell의 SageAttention 장시퀀스 FP8 품질 보고↗
- [8]기존 Oh My GPU LTX-2.5 PRO 6000 해상도 테스트↗