niklaslenzQwen-Image 2.1 with the Lightning 4-step LoRA on a DGX Spark
The LightX2V Lightning LoRA cuts Qwen-Image 2.1 from 25 steps to 4. This page measures what that does to the time for one 1024×1024 image in ComfyUI, with the same weights and prompts run both ways on the same machine.
Not ranked. Measured on the devices shown here only. Measured before the image test v2 protocol of 20 Oct 2026; shown separately and not ranked.
DGX Spark 128 GB · Q4_K_M + Lightning · 1024×1024 · models reloaded each run
one NVIDIA DGX Spark (GB10, 128 GB unified memory)
DGX Spark 128 GB · Q5_K_M + Lightning · 1024×1024 · models reloaded each run
one NVIDIA DGX Spark (GB10, 128 GB unified memory)
DGX Spark 128 GB · Q4_K_M + Lightning · 1024×1024 · models kept loaded
one NVIDIA DGX Spark (GB10, 128 GB unified memory)
Real outputs
How it was run
- Weights: Qwen-Image-2.1 as GGUF Q4_K_M and Q5_K_M (unsloth), text encoder qwen3vl_8b_w4a8 and bf16 VAE (Comfy-Org); sha256 of every file is listed
- LoRA: lightx2v Qwen-Image-2.1-Lightning at revision 6b0a1176, strength 1.0, applied unmerged with LoraLoaderModelOnly; ModelSamplingAuraFlow shift 2.0005 (= exp(mu), mu 0.6935, the dynamic shift from the LoRA README for 1024×1024); 4 steps
- Reference arm on the same device: the same GGUF weights, 25 steps, no LoRA, no shift node
- Engine: ComfyUI 0.39.0 (commit 46493d82) with ComfyUI-GGUF (commit 6ea2651e, small local patch for a qwen_image architecture fallback), NGC PyTorch 26.07 container
- Settings: 1024×1024, Euler, scheduler simple, CFG 1.0, seed 42; prompts "text" (chalkboard menu), "photo" (fisherman), "illustration" (robot and GPU rack)
- Method: per arm and prompt 1 warm run + 3 measured runs; median of the 9 measured runs; server started with --cache-none, so every run executes the text encoder, sampler and VAE and reloads the models. A second table row per device keeps the models loaded (seed 42 + index so the sampler really runs)
What to keep in mind
Measured on this device only, not ranked.
One GB10 was measured. Unified memory: the memory column is the sum of per-process GPU memory reported by the driver.
Time per image here is the wall time of one ComfyUI job. With --cache-none this includes loading the text encoder and the model each time, so it is not the pure sampling time; the "models kept loaded" cells show the difference. That is why the speed-up is well below 25/4 = 6.25.
Lightning images are different images, not faster copies of the 25-step ones: PSNR against the Q4_K_M 25-step image is 9.09 / 10.29 / 9.44 dB and SSIM 0.41 / 0.40 / 0.65 (text / photo / illustration). There is no per-image quality score; the chalkboard text with three menu lines was legible and correct in all four stages (two Lightning, two 25-step) by the test author's eye, which is a visual check, not a measurement.
The LoRA was applied through ComfyUI's LoraLoaderModelOnly with a shift value derived from the README. A reference run with the Diffusers example of the LoRA authors was not done, so it is not verified that ComfyUI applies the LoRA exactly as the authors' code does; the server log shows no key warnings. The README itself notes that BF16 Diffusers examples can differ numerically from LightX2V inference.
The GGUF loader (ComfyUI-GGUF) runs with a small local patch (qwen_image architecture fallback). This is our own build, not a release package.
An NVFP4 variant with Lightning was not run on this device.
Same seed gives bit-identical images on repeats (maximum pixel difference 0.0). The machine ran with its standard GPU clock cap (value not published here).
License: the saved model card of the LoRA states no license; see the model pages of the LoRA and of Qwen-Image-2.1.