답변 속도와 가속
Qwen-Image 2.1 속도: RTX 5090과 Mac, 같은 모델인데 왜 다를까
누군가는 한 장에 6초라고 하고, 다른 사람은 3분을 기다렸다고 합니다. 둘 다 Qwen-Image 2.1이면 어느 쪽이 틀린 걸까요. 실행기와 양자화1, 해상도가 다르면 둘 다 가능한 기록입니다. 구매 전에 필요한 건 가장 짧은 숫자를 찾는 일이 아니라 내가 쓸 조건에서 기다릴 시간을 좁혀가는 일입니다.
한 장에 6초라는 숫자에는 실행 조건이 붙습니다
LightX2V의 RTX 5090 배포 안내에는 1024×1024, 40단계 텍스트→이미지가 5.930초로 기록돼 있습니다. seed 42, CFG 비활성, 연속 세 요청의 중앙값입니다. 입력 인코딩과 디노이징, VAE2 복원, PNG 저장까지 포함하지만 처음 모델을 올리는 시간은 빠져 있습니다.
이 숫자는 5090에서 어떤 프로그램을 열어도 나오는 기본 성능이 아니라 해당 설정의 결과입니다.
핵심은 FP83 가중치와 FP164 누산, SM120용 연산자, SageAttention2를 함께 사용하는 경로입니다. 텍스트 인코더는 단계별로 CPU5에 오프로딩6합니다. 같은 5090에서도 일반 Diffusers 설정은 다른 시간이 나옵니다. 반대로 일반 실행이 느렸다는 이유만으로 장비를 바꾸기 전에, 지원되는 최적화 경로가 있는지 확인할 이유가 생깁니다.

비교 가능한 숫자와 비교하면 안 되는 숫자
아래 표는 같은 모델 이름 아래에 공개된 서로 다른 실행 기록입니다. 5090의 FP4 7.40초는 Mesmer의 엔진 시간이며, 앞의 LightX2V 종단 시간과 측정 범위도 다릅니다. 일반 Diffusers의 NF4 기록은 또 다른 테스트입니다. 어느 실행기가 몇 퍼센트 우월하다고 계산하는 표가 아니라, 설정을 빼고 GPU7 이름만 적으면 왜 숫자가 맞지 않는지 보여주는 표입니다.
특히 Q4_K_M 파일을 받았다고 FP4 전용 커널의 속도가 나오는 것은 아닙니다. GGUF8, NF4, 하드웨어 친화적인 FP4는 저장 형식과 연산 경로가 다릅니다. 저메모리 카드에서 CPU로 가중치를 옮기는지, 인코더를 GPU에 남기는지도 확인하세요. 파일명 뒤에 적힌 4라는 숫자보다 실행 로그의 백엔드와 실제 메모리 사용량이 더 많은 것을 알려줍니다.
| 측정 장비 | 실행 구성 | 출력 크기 | 공개 시간 |
|---|---|---|---|
| RTX 5090 | LightX2V FP8 / FP16 accumulation | 1024×1024 | 5.930s |
| RTX 5090 | Mesmer FP4 rank 128 | 1024×1024 | 7.40s |
| RTX 5090 | Diffusers NF4 | 1024×1024 | 19.2s |
| RTX 4070 Ti SUPER 16GB | Mesmer INT4 rank 128 | 1024×1024 | 22.82s |
| M5 Max 36GB | ComfyUI GGUF Q8 + INT8 encoder | 1024×1024 | 156s |
| M5 Max 36GB | ComfyUI GGUF Q4 + W4A8 encoder | 1024×1024 | 218s |
공개 실행 기록 · 모두 텍스트→이미지 40단계
RTX 5090
- 실행 구성
- LightX2V FP8 / FP16 accumulation
- 출력 크기
- 1024×1024
- 공개 시간
- 5.930s
RTX 5090
- 실행 구성
- Mesmer FP4 rank 128
- 출력 크기
- 1024×1024
- 공개 시간
- 7.40s
RTX 5090
- 실행 구성
- Diffusers NF4
- 출력 크기
- 1024×1024
- 공개 시간
- 19.2s
RTX 4070 Ti SUPER 16GB
- 실행 구성
- Mesmer INT4 rank 128
- 출력 크기
- 1024×1024
- 공개 시간
- 22.82s
M5 Max 36GB
- 실행 구성
- ComfyUI GGUF Q8 + INT8 encoder
- 출력 크기
- 1024×1024
- 공개 시간
- 156s
M5 Max 36GB
- 실행 구성
- ComfyUI GGUF Q4 + W4A8 encoder
- 출력 크기
- 1024×1024
- 공개 시간
- 218s
Mac에서 Q4가 더 느릴 수도 있는 이유
공개된 M5 Max 36GB 테스트는 ComfyUI의 Metal 경로를 사용합니다. 1024에서는 Q8 조합이 156초, Q4 조합은 218초였습니다. 여기서 인코더도 INT8과 W4A8으로 다르므로 본체 비트 수 하나만의 차이라고 단정할 수 없습니다. 낮은 비트 수로 메모리를 아끼는 이득과, 해당 런타임에서 압축을 풀어 연산하는 비용을 함께 봐야 합니다.
1536에서는 두 조합이 약 8분대로 가까워졌고, 2048에서는 약 18분 규모의 기록이 나옵니다. 이때 Q4의 2048 결과는 반복 측정이 아니라 cold run으로 공개됐으므로 정밀한 우열 판단에 쓰지 않습니다. Mac Studio의 더 큰 메모리는 큰 작업을 올리는 데 유리하지만, 메모리 용량이 늘어난 비율만큼 이미지 연산이 빨라지는 것은 아닙니다.
5090 최적화는 전용 설정까지 맞춰야 합니다
LightX2V는 5090용 CUDA9 이미지와 FP8 변환 예제를 따로 제공합니다. 저장소의 일반 스크립트가 아니라 fp8_f16_accum_5090 스크립트를 선택하고, 원본 모델 경로와 변환된 DiT10 파일 경로를 각각 지정해야 합니다.
아래 명령은 소스와 실행 환경을 준비한 뒤 사용하는 변환·실행 부분입니다. /path/to 경로는 자신의 폴더로 바꿔야 하며 모델 전체를 여기서 대신 내려받는 명령은 아닙니다.
변환 뒤에는 선택한 JSON 설정의 dit_quantized_ckpt를 생성된 safetensors 파일로, 스크립트의 lightx2v_path와 model_path를 실제 폴더로 맞춥니다. model_path는 원본 모델 폴더를 가리켜야 합니다. SM120 연산자를 포함하는 lightx2v-kernel과 GPU에 맞는 환경이 필요하므로, 이 설정을 RTX 3090이나 DGX Spark에 그대로 붙여넣고 같은 가속을 기대하면 안 됩니다.
python tools/convert/converter.py \
--source /path/to/Qwen-Image-2.1/transformer \
--output /path/to/Qwen-Image-2.1-fp8-f16-accum \
--output_name qwen_image_21_fp8_f16_accum \
--model_type qwen_image_21_dit \
--quantization_profile qwen-image-21-fp8-f16-accum \
--quantized --linear_type fp8 --device cuda:0 --single_file
# Set the checkpoint path in the JSON config and model paths in the script first.
bash scripts/qwen_image_21/qwen_image_21_t2i_fp8_f16_accum_5090.sh
해상도를 올렸는데 시간이 훨씬 길어졌다면
한 변을 두 배로 키웠다고 시간을 두 배로 잡으면 실제 대기를 크게 놓칩니다. 일반 Diffusers NF4 공개 기록에서는 1K 19.2초가 2K 118.8초로 늘었습니다.
Mac Q8 기록도 1K 156초에서 2K 1094초로 올라갑니다. 내부 연산과 메모리 배치가 함께 바뀌기 때문에 단순 픽셀 비례만으로 설명하기 어렵습니다.
작업 해상도는 성능 비교의 부가 조건이 아니라 핵심 조건입니다.
체감 화면은 1024·1536·2048을 나눠 보여주고 Qwen-Image 2.1에는 별도 해상도 보정을 적용합니다. 5090 최적화 경로의 고해상도 시간은 공개된 1K 기록과 다른 실행의 증가 패턴을 조합한 추정이며, 2K 실측이라고 표시하지 않습니다. 결과를 마음에 들게 고르는 단계에서는 1K, 최종 후보를 확인할 때는 큰 출력으로 나누면 장비를 바꾸지 않고도 기다림을 줄일 수 있습니다.
GPU 두 장과 큰 Mac의 이득은 같은 종류가 아닙니다
GPU 두 장이면 이미지를 두 작업으로 나눠 동시에 만들 수 있는 구성을 생각할 수 있습니다. 하지만 그것이 이미지 한 장의 완성 시간을 절반으로 만든다는 뜻은 아닙니다.
한 작업을 나눠 계산하려면 모델과 실행기가 분산 방식을 지원해야 하고 통신 비용도 생깁니다. 이 사이트의 Qwen-Image 2.1 비교는 단일 GPU 경로라 2×5090을 골라도 한 장의 시간과 메모리를 단순 합산하지 않습니다.
큰 통합 메모리11를 가진 Mac은 모델과 다른 작업을 함께 올리기 편한 반면, 이미지 생성에서는 GPU 연산량과 Metal 구현의 영향이 큽니다. 이미 Mac이 있고 한 번에 몇 장만 만든다면 기다림을 감수하고 시작할 수 있습니다. 수십 장을 계속 고르는 작업이라면 NVIDIA의 최적화 경로를 비교해볼 이유가 있습니다. 용도와 반복 횟수 없이 하나의 장비를 무조건 추천하기는 어렵습니다.

내 기록과 사이트 수치를 맞춰보는 방법
먼저 모델을 올린 뒤의 한 장인지, 다운로드와 첫 적재를 포함한 전체 시간인지 분리하세요. 프롬프트, seed, 단계 수와 해상도를 고정하고 세 번 이상 반복합니다. 평균보다 중앙값을 남기면 한 번의 긴 초기 작업이 비교를 흔드는 일을 줄일 수 있습니다. 실행 로그의 GPU 이름, 본체·인코더 정밀도, 오프로딩과 실행기 버전도 함께 기록하면 다른 사람이 결과를 재현하기 좋습니다.
사이트는 5090의 공개 최적화 기록을 기준점으로 두고 다른 NVIDIA 구성은 일반 NF4 경로의 상대 추정으로 표시합니다. Mac은 별도의 GGUF 기록을 사용하며 칩별 추정 폭을 넓게 둡니다.
GB10의 전용 실행 시간이나 낮은 메모리의 스왑처럼 확인되지 않은 부분은 억지로 숫자를 만들지 않았습니다. 장비를 고른 뒤 체감 화면에서 기다림을 확인하고, 구매 전에는 자신이 사용할 실행 방식도 같이 정해두세요.
용어 각주
양자화 — 모델의 수치를 더 적은 비트로 표현하는 방법입니다. 메모리 사용량과 함께 정확도나 실행 속도도 달라질 수 있으며, 영향은 형식과 구현에 따릅니다.
본문으로 돌아가기VAE — Variational Autoencoder의 약자입니다. 입력을 압축된 잠재 표현으로 바꾸거나, 그 표현에서 결과를 복원하는 데 쓰입니다.
본문으로 돌아가기FP8 — 8비트 부동소수점 수치 형식 계열입니다. 세부 형식과 지원 범위는 하드웨어 및 소프트웨어에 따라 다릅니다.
본문으로 돌아가기FP16 — 16비트 부동소수점 수치 형식입니다. BF16과 비트 수는 같지만 지수부와 유효숫자 배분이 다릅니다.
본문으로 돌아가기CPU — 컴퓨터에서 일반적인 프로그램 명령을 실행하는 중앙 처리 장치입니다. AI 작업에서는 GPU 등 다른 프로세서와 역할을 나누기도 합니다.
본문으로 돌아가기오프로딩 — 메모리가 부족할 때 모델 데이터 일부를 GPU 메모리에서 시스템 RAM이나 저장장치로 옮겨 처리하는 방식입니다. 데이터 이동이 추가됩니다.
본문으로 돌아가기GPU — 많은 계산을 병렬로 처리하는 프로세서입니다. AI 모델 실행에서는 모델 계산을 맡습니다.
본문으로 돌아가기GGUF — 모델 정보를 담는 파일 형식으로 llama.cpp 계열 도구에서 널리 사용됩니다. 파일 형식만으로 특정 하드웨어 호환성이나 속도가 보장되지는 않습니다.
본문으로 돌아가기CUDA — NVIDIA GPU에서 범용 계산을 실행하기 위한 소프트웨어 플랫폼입니다. CUDA용으로 만든 프로그램은 다른 GPU에서 그대로 동작한다고 보장되지 않습니다.
본문으로 돌아가기DiT — Diffusion Transformer의 약자입니다. 트랜스포머 구조를 이용해 확산 과정에서 노이즈가 있는 표현을 단계적으로 다듬는 모델 구조입니다.
본문으로 돌아가기통합 메모리 — CPU와 GPU가 같은 물리 메모리 풀을 공유하는 구조입니다. 메모리 용량이 자동으로 늘어나는 것은 아니며, 실제 사용 가능량은 시스템에 따라 다릅니다.
본문으로 돌아가기