Response speed and acceleration
Qwen-Image 2.1 speed on RTX 5090 and Mac
One person reports six seconds; another waits three minutes. Both may be valid Qwen-Image 2.1 runs with different runtimes, quantization1 and resolutions. Before buying, narrow down the wait under your intended conditions instead of chasing the smallest number.
Six seconds per image comes with conditions
LightX2V reports 5.930 seconds for RTX 5090 text-to-image at 1024×1024 and 40 steps: seed 42, CFG disabled, median of three consecutive requests. It includes encoding through PNG save, but excludes initial model loading. This is the result of that setup, not a default for every 5090 application.
The path combines FP82 weights, FP163 accumulation, SM120 operators and SageAttention2, with staged encoder CPU4 offload5. A conventional Diffusers setup on the same GPU6 gives different timing. Check available runtime7 optimizations before replacing hardware solely because the default setup feels slow.
Which timing numbers belong together?
These are separate published runs of the same model. Mesmer's 7.40s FP4 figure is engine time, unlike LightX2V's end-to-end scope; the NF4 Diffusers run is another test. The table is not a controlled runtime ranking. It shows why a GPU name without settings is insufficient.
Downloading Q4_K_M does not produce the speed of a specialized FP4 kernel. GGUF8, NF4 and hardware-oriented FP4 differ in storage and compute paths. Check whether weights move to CPU and whether the encoder remains on GPU. The actual backend and memory use say more than a shared digit in a filename.
| Test hardware | Runtime setup | Output size | Reported time |
|---|---|---|---|
| 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 |
Published runs · text-to-image, 40 steps
RTX 5090
- Runtime setup
- LightX2V FP8 / FP16 accumulation
- Output size
- 1024×1024
- Reported time
- 5.930s
RTX 5090
- Runtime setup
- Mesmer FP4 rank 128
- Output size
- 1024×1024
- Reported time
- 7.40s
RTX 5090
- Runtime setup
- Diffusers NF4
- Output size
- 1024×1024
- Reported time
- 19.2s
RTX 4070 Ti SUPER 16GB
- Runtime setup
- Mesmer INT4 rank 128
- Output size
- 1024×1024
- Reported time
- 22.82s
M5 Max 36GB
- Runtime setup
- ComfyUI GGUF Q8 + INT8 encoder
- Output size
- 1024×1024
- Reported time
- 156s
M5 Max 36GB
- Runtime setup
- ComfyUI GGUF Q4 + W4A8 encoder
- Output size
- 1024×1024
- Reported time
- 218s
Why Q4 can be slower on Mac
The published M5 Max 36GB test uses ComfyUI's Metal path. At 1024, Q8 took 156s and Q4 218s. Encoders also differed—INT8 versus W4A8—so this does not isolate denoiser precision. Consider both memory savings and the runtime's cost of unpacking low-bit weights.
At 1536 the two configurations were both around eight minutes; at 2048, around eighteen minutes. The Q4 2048 result was a cold run, not a repeated warm measurement, so it is unsuitable for a precise ranking. More Mac Studio memory helps fit larger work, not accelerate computation in direct proportion to capacity.
Match the full 5090 optimization setup
LightX2V provides a 5090-specific CUDA9 image and FP8 conversion recipe. Use the fp8_f16_accum_5090 script, setting the original model directory and converted DiT10 file separately. The commands below cover conversion and launch after preparing the source and environment. Replace /path/to placeholders; they do not download the whole model.
After conversion, point dit_quantized_ckpt in the selected JSON config to the generated safetensors file and set lightx2v_path and model_path in the script. model_path must remain the original model directory. The path needs lightx2v-kernel's SM120 operator; copying it to an RTX 3090 or DGX Spark does not establish equivalent support or speed.
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
Why resolution can increase the wait so sharply
Doubling the edge length is not merely doubling the wait. One Diffusers NF4 record rises from 19.2s at 1K to 118.8s at 2K; the Mac Q8 record rises from 156s to 1094s. Computation and memory behavior change together. Resolution is a central comparison condition, not a footnote.
The experience offers 1024, 1536 and 2048 with a model-specific resolution curve. High-resolution optimized 5090 times extrapolate from its 1K record using another runtime's growth pattern; they are not labeled 2K measurements. Choose candidates at 1K and inspect finalists larger to reduce waiting without new hardware.
Two GPUs and a larger Mac offer different benefits
Two GPUs can potentially run separate jobs concurrently, but that does not halve the latency of one image. Splitting a single job requires runtime support and introduces communication overhead. Our Qwen-Image 2.1 preset follows a single-GPU path, so 2×5090 does not double usable memory or halve one-image time.
A large-memory Mac can hold more models and other work, but image generation depends heavily on GPU compute and Metal implementations. An existing Mac may suit occasional images; sustained iteration gives a reason to compare optimized NVIDIA paths. The workload and iteration count should drive the recommendation.
Compare your own run with the site estimate
Separate warmed generation from download and initial load. Fix the prompt, seed, steps and resolution and repeat at least three times. The median reduces the influence of one unusually long initialization. Record GPU, denoiser and encoder precision, offloading and runtime version for reproducibility.
The site anchors 5090 to its published optimized result, while other NVIDIA presets use broad relative estimates for a conventional NF4 path. Mac uses separate GGUF records and wider chip-family bands. Unverified GB10 timing and swap-dominated cases remain unnumbered. Compare the wait, then settle the runtime you actually intend to use before buying.
Terminology notes
Quantization — Representing model values with fewer bits. Memory use, accuracy, or execution speed may change; the effects depend on the format and implementation.
Back to the textFP8 — A family of 8-bit floating-point formats. Specific formats and support vary by hardware and software.
Back to the textFP16 — A 16-bit floating-point format. It uses the same bit width as BF16 but allocates bits differently between exponent and significand.
Back to the textCPU — The central processor that executes general-purpose program instructions. AI workloads may divide work between it and other processors such as GPUs.
Back to the textOffloading — Moving some model data from GPU memory to system RAM or storage when capacity is limited. This adds data transfer.
Back to the textGPU — A processor designed to handle many calculations in parallel. It performs model computations during AI inference.
Back to the textRuntime — Software that loads model files and runs their computations. Supported formats, hardware, and optimizations vary by runtime.
Back to the textGGUF — A file format for model data, widely used by llama.cpp-based tools. The format alone does not guarantee compatibility or speed on particular hardware.
Back to the textCUDA — A software platform for general-purpose computing on NVIDIA GPUs. Programs built for CUDA are not guaranteed to run unchanged on other GPUs.
Back to the textDiT — Short for Diffusion Transformer: a model architecture that uses a transformer to refine noisy representations across diffusion steps.
Back to the text