# How to Make WAN 2.2 Video Generation Faster: 12 Proven Optimization Strategies for 2026 Speed up WAN 2.2 video generation with 4-step LoRAs, FP8, SageAttention, ComfyUI, GPU tuning and proven inference optimizations. Canonical URL: https://aiidelist.com/blog/how-to-make-wan-2-2-video-generation-faster Language: en Published: 2026-10-10 Updated: 2026-10-10 WAN 2.2 can produce impressive AI-generated videos, but running the model locally can be frustratingly slow. A single clip may take several minutes or considerably longer, depending on the model variant, GPU, sampling steps, resolution, frame count, and memory configuration. Fortunately, **WAN 2.2 video generation can be accelerated substantially without replacing the entire workflow**. The most effective optimizations include reducing diffusion steps, using distilled models, selecting efficient attention kernels, optimizing GPU memory, and eliminating unnecessary CPU-to-GPU transfers. By 2026, acceleration frameworks such as LightX2V have pushed performance far beyond the original inference implementations. Some specialized configurations combine four-step generation, NVFP4 quantization, and sparse attention to achieve dramatic reductions in generation time. However, not every optimization works on every GPU. Some techniques reduce VRAM usage without improving inference speed, while others introduce visual artifacts or require specific hardware. This guide explains how to make WAN 2.2 faster in ComfyUI, with the official Python implementation, and through advanced inference frameworks. It also covers the trade-offs between performance, video quality, hardware requirements, and memory consumption. ## Key Takeaways - **Use distilled four-step models or compatible Lightning LoRAs for the largest potential reduction in denoising time.** Simply setting a standard model to four steps is not equivalent. - **Reduce frame count before sacrificing too much image quality.** Generating 49 frames instead of 81 can substantially reduce the computational workload. - **Choose the right model.** WAN 2.2 TI2V-5B is generally a more practical starting point for consumer GPUs than the larger A14B variants. - **Use FP8 or other supported quantized checkpoints when GPU memory is limited.** Quantization can reduce memory pressure, although faster inference is not guaranteed. - **Try SageAttention, FlashAttention, or PyTorch SDPA.** Efficient attention implementations can improve performance, especially with longer videos and higher resolutions. - **Avoid unnecessary CPU offloading.** Keeping frequently used model components in GPU memory is usually faster when sufficient VRAM is available. - **Consider caching methods such as MagCache or cache-dit for compatible workflows.** They reduce redundant transformer computations but can affect output quality. - **Use torch.compile for repeated inference workloads.** Compilation can improve steady-state performance, but first-run overhead may outweigh the benefits for occasional generations. - **For RTX 50-series users, investigate LightWan2.2-A14B.** Its developers report substantial acceleration through four-step distillation, NVFP4, and sparse attention. - **Measure complete generation time rather than sampling speed alone.** Model loading, text encoding, VAE decoding, GPU transfers, and video encoding can all contribute to latency. ## Why Is WAN 2.2 Video Generation So Slow? WAN 2.2 is a diffusion-based video generation system. Unlike a conventional image generator, it must create a sequence of temporally consistent frames while preserving subjects, motion, camera movement, lighting, and scene structure. That makes inference computationally expensive. The approximate end-to-end generation time can be expressed as: ```text Total latency = Model loading + Text/image encoding + Denoising + VAE decoding + Video encoding + Transfer overhead ``` For many configurations, transformer denoising dominates runtime. However, systems with insufficient GPU memory may spend substantial time transferring model weights between system RAM and VRAM. ### WAN 2.2 uses different model architectures The official WAN 2.2 repository provides several model variants. | Model | Architecture | Primary use | Performance considerations | |---|---|---|---| | WAN2.2-TI2V-5B | 5B hybrid video model | Text-to-video and image-to-video | More practical for consumer hardware | | WAN2.2-T2V-A14B | Two-expert MoE | Text-to-video | Higher memory and computational demands | | WAN2.2-I2V-A14B | Two-expert MoE | Image-to-video | Requires image conditioning and substantial memory | | WAN2.2-S2V-14B | Audio-conditioned video model | Speech-to-video | Additional audio-related processing | | WAN2.2-Animate-14B | Character animation model | Animation and character replacement | Extra conditioning and preprocessing requirements | The A14B models use a Mixture-of-Experts architecture with separate high-noise and low-noise denoisers. Each expert contains approximately 14 billion parameters. The complete architecture has roughly 27 billion parameters, while only one expert is active at a particular denoising stage. The high-noise expert establishes broad scene structure and motion. The low-noise expert refines details during later steps. This design improves model capacity without requiring both experts to execute during every step. Nevertheless, both sets of weights still need to be managed, which can create significant memory pressure. **An important implication is that WAN 2.2 acceleration must account for both noise stages.** Distillation adapters, quantization, and caching should be compatible with the appropriate expert rather than applied indiscriminately. ## 1. Use a Four-Step Distilled Model or Lightning LoRA Reducing diffusion steps is one of the most effective ways to accelerate video generation. Standard WAN 2.2 configurations commonly use approximately 40 to 50 sampling steps, depending on the model. Each step requires substantial transformer computation. Reducing the number of steps reduces the number of denoising passes. For example: | Configuration | Sampling steps | Relative step count | |---|---:|---:| | Standard generation | 40 | 100% | | Reduced-step preview | 24 | 60% | | Aggressive preview | 12 | 30% | | Compatible distilled model | 4 | 10% | These figures compare the number of sampling steps, not measured end-to-end runtime. Actual performance also depends on guidance calculations, model architecture, decoding, and overhead. ### Why four-step distillation works A normally trained diffusion model learns to denoise through many incremental operations. A distilled model is trained to approximate a longer sampling trajectory in fewer steps. This is fundamentally different from taking an ordinary 40-step checkpoint and forcing it to generate with four steps. Without compatible distillation, extremely low step counts may produce distorted motion, weak prompt adherence, incomplete subjects, and unstable details. ### LightX2V distilled LoRAs The LightX2V project provides distilled models and LoRA adapters for WAN 2.2. Its WAN 2.2 distilled LoRA collection includes separate high-noise and low-noise adapters for the A14B image-to-video architecture. A compatible four-step setup uses: - The correct WAN2.2-I2V-A14B base model. - A high-noise distilled LoRA assigned to the high-noise expert. - A low-noise distilled LoRA assigned to the low-noise expert. - The scheduler and timestep configuration required by that distillation method. - The guidance configuration recommended by the model developer. LightX2V documents a four-step denoising schedule represented by `[1000, 750, 500, 250]` in its own inference configuration. That schedule should not automatically be copied into a different scheduler or ComfyUI implementation. Different runtimes may represent timesteps differently. **Recommended approach:** Start from the workflow supplied with the exact distilled checkpoint instead of modifying an unrelated 40-step workflow. ### Does CFG affect speed? Classifier-free guidance can increase computation because many implementations evaluate conditioned and unconditioned predictions separately. Some distilled WAN 2.2 models are designed for guidance-free inference, often represented by a guidance scale of `1.0`. Disabling the extra guidance calculation can reduce inference workload, but the correct value depends on the checkpoint and implementation. For an ordinary, non-distilled model, setting CFG to 1 may reduce prompt adherence or otherwise change the output. It should not be treated as a universal acceleration switch. ## 2. Reduce Video Frames Before Generating Long Clips The number of frames is one of the most important factors affecting video generation time. Generating a longer video requires processing more temporal information. It also increases attention computation and the amount of work required for decoding. Consider the following frame counts: | Frames | Duration at 24 FPS | Typical purpose | |---|---:|---| | 17 | 0.71 seconds | Very short motion test | | 33 | 1.38 seconds | Quick composition preview | | 49 | 2.04 seconds | Short motion preview | | 81 | 3.38 seconds | Standard short clip | | 121 | 5.04 seconds | Longer generation | These durations assume 24 FPS. Actual output FPS depends on the model and export settings. WAN commonly uses frame counts following the constraint `4n + 1`, such as 17, 33, 49, and 81. For example, reducing a generation from 81 frames to 49 frames decreases the number of output frames by approximately 39.5%. That does not guarantee a 39.5% speedup because transformer attention cost, fixed overhead, and memory behavior are not perfectly linear. Nevertheless, reducing frames is often an effective way to cut latency. ### The preview-first workflow A practical production strategy separates testing from final rendering. **Preview stage:** Generate 17 to 49 frames using a reduced-step configuration and a fixed random seed. **Selection stage:** Evaluate camera motion, subject stability, composition, and prompt adherence. **Final stage:** Regenerate promising candidates using the intended frame count, resolution, and quality settings. This method can save substantial GPU time when experimenting with multiple prompts. ### Does lowering output FPS make WAN 2.2 faster? Not necessarily. Changing only the FPS metadata during video export does not reduce the number of frames the diffusion model generated. It primarily changes playback duration or timing. To reduce actual generation work, decrease the number of frames supplied to the model. Frame interpolation is another option for increasing playback smoothness after generation, but it adds processing time and can introduce interpolation artifacts. ## 3. Choose a Lower Resolution When the Model Supports It Higher resolution means more spatial information must be represented and processed. For diffusion transformers, additional spatial tokens can significantly increase attention and memory costs. WAN 2.2 A14B text-to-video and image-to-video models support both approximately 480p and 720p output configurations in the official implementation. | Resolution | Pixel count | Relative pixels | |---|---:|---:| | 832 × 480 | 399,360 | 1.00× | | 1280 × 720 | 921,600 | 2.31× | A 720p frame contains approximately 2.31 times as many pixels as an 832 × 480 frame. Actual inference scaling can be greater or smaller than this ratio because attention computation, memory bandwidth, and implementation details also matter. ### Important exception: WAN 2.2 TI2V-5B The official WAN 2.2 Python implementation defines the supported TI2V-5B sizes as `1280*704` and `704*1280`. Although the 5B architecture can be used in alternative workflows with different resolutions, the unmodified official CLI does not accept `832*480` for this task. This distinction can be verified in the official supported-size configuration. For the official 5B CLI, reducing frame count and steps is a safer starting point than supplying an unsupported size. For ComfyUI or a custom Diffusers implementation, lower resolutions may be possible when the workflow supports them and satisfies the model's latent-dimension constraints. **Recommended strategy:** Use lower resolution during exploration, then generate the selected result at the desired final resolution. Avoid assuming every WAN 2.2 model accepts identical dimensions. ## 4. Minimize CPU Offloading When VRAM Is Sufficient GPU memory is a major source of performance differences between WAN 2.2 installations. When a model cannot fit its required components into VRAM, inference frameworks can move inactive weights to system RAM and reload them when needed. This technique is called CPU offloading. It can make large models usable on smaller graphics cards, but it is not inherently an acceleration technique. Repeated CPU-to-GPU transfers can significantly increase latency. ### Understanding the memory trade-off | Memory strategy | VRAM requirement | Likely speed impact | |---|---|---| | Keep required weights on GPU | High | Usually fastest when memory fits | | Component-level CPU offloading | Lower | Adds transfer overhead | | Block or group offloading | Lower | Depends on prefetching and hardware | | Sequential CPU offloading | Very low | Often substantially slower | | Disk offloading | Lowest available-memory requirements | Can be extremely slow | The Hugging Face memory optimization guide explains how offloading strategies trade memory consumption against inference speed. For video workloads, group offloading with asynchronous prefetching may be preferable to repeatedly transferring small submodules without overlap. ### Official WAN 2.2 memory settings The official Python implementation includes several relevant options: - `--offload_model True` moves models away from the GPU when appropriate. - `--convert_model_dtype` converts parameters to the configured inference precision. - `--t5_cpu` keeps the T5 text encoder on the CPU. The official 5B example uses these options to support execution on a 24GB GPU such as an RTX 4090. The developers also explain that systems with at least 80GB of VRAM can remove these memory-saving options to accelerate execution. The broader principle is simple: **use as little offloading as necessary to avoid out-of-memory failures**. Removing offloading without sufficient VRAM can cause the entire generation to fail. Free memory, activation requirements, and decoder usage must be considered before making changes. ## 5. Use FP8 Quantization to Reduce Memory Pressure Quantization stores model weights with reduced numerical precision. For example, FP8 uses eight-bit floating-point values instead of the 16-bit representation commonly used by BF16 or FP16 checkpoints. This can substantially reduce the storage and memory bandwidth required for supported model weights. However, real-world speed improvements depend on the GPU, quantization format, supported kernels, and whether weights or activations are quantized. ### Comparing numerical formats | Precision | Approximate weight storage | Main advantage | Main limitation | |---|---|---|---| | BF16 / FP16 | 2 bytes per parameter | Good compatibility and numerical accuracy | Higher memory consumption | | FP8 | 1 byte per parameter | Lower weight storage and memory traffic | Hardware and kernel compatibility | | 4-bit formats | 0.5 bytes per parameter before metadata | Very low weight storage | Dequantization overhead and possible quality changes | These figures describe raw parameter storage rather than total application VRAM. Activations, temporary buffers, model metadata, VAE components, and offloading allocations consume additional memory. ### ComfyUI FP8 checkpoints The official ComfyUI WAN 2.2 tutorial documents FP8-scaled A14B text-to-video checkpoints, including: - `wan2.2_t2v_high_noise_14B_fp8_scaled.safetensors` - `wan2.2_t2v_low_noise_14B_fp8_scaled.safetensors` - `umt5_xxl_fp8_e4m3fn_scaled.safetensors` These files reduce the memory requirements associated with model weights. For users running larger models on limited VRAM, the main benefit may be avoiding expensive memory swapping. **Important:** FP8 does not automatically make every generation faster. Weight-only FP8 may still involve conversion overhead, and some GPUs cannot execute the most efficient FP8 kernels. Where possible, compare BF16, FP8, and other supported formats using identical generation settings and full end-to-end timing. ## 6. Enable Faster Attention Kernels Attention is a major computational component of transformer-based video generation. As the spatial and temporal token count grows, attention calculations can become increasingly expensive. Efficient attention implementations aim to reduce memory movement, improve kernel execution, or approximate selected calculations more efficiently. ### PyTorch SDPA PyTorch provides scaled dot-product attention, commonly abbreviated as SDPA. Modern Diffusers pipelines generally use SDPA when supported. PyTorch can select efficient attention backends based on the device and tensor configuration. SDPA is a sensible baseline because it avoids unnecessary third-party dependencies. ### FlashAttention FlashAttention implements memory-efficient attention algorithms that reduce data movement and improve GPU utilization. Its benefits depend on the GPU architecture, head dimensions, attention shapes, software versions, and workload. FlashAttention compatibility should be verified against the inference framework rather than assumed from the checkpoint name. ### SageAttention SageAttention uses quantized attention calculations to improve performance. The project reports substantial kernel-level speedups on supported hardware, including RTX 4090 and newer architectures. However, **kernel-level acceleration is not equivalent to end-to-end video generation acceleration**. For example, a faster attention kernel does not eliminate text encoding, VAE decoding, weight loading, or CPU offloading. Some versions also have specific CUDA, PyTorch, Triton, and GPU architecture requirements. ### Practical recommendation Start with the attention backend already supported by the chosen workflow. Next, benchmark one alternative at a time: 1. PyTorch SDPA as the baseline. 2. FlashAttention where supported. 3. SageAttention where compatible. 4. Sparse attention only with implementations designed for the selected model. Keep the prompt, seed, resolution, frames, steps, and other settings constant. Review output quality as well as runtime. Faster approximate attention is not automatically identical to full-precision attention. ## 7. Use MagCache or Cache-Dit to Skip Redundant Computation Feature caching is another approach to accelerating diffusion transformers. During denoising, some intermediate features change relatively little between adjacent steps. Caching methods attempt to reuse appropriate intermediate results instead of recomputing everything. This can reduce computational workload without modifying the base model weights. ### MagCache MagCache uses the relative magnitude of feature changes to help decide when previous computations can be reused. Community contributions to the WAN 2.2 repository have reported approximately 1.5–2× acceleration in supported MagCache configurations. The WAN 2.2 MagCache integration discussion includes task-specific configurations and illustrates why caching parameters require calibration. Actual speedups vary with the GPU, model, cache threshold, and generation settings. ### Cache-Dit The cache-dit project supports caching-based acceleration for diffusion transformer architectures, including WAN 2.2 workflows. Its techniques include methods such as DBCache and TaylorSeer. Cache-dit's documentation and release history also describe integration with quantization and multi-GPU execution. ### When caching works best Caching is most useful when: - A substantial number of denoising steps remain. - Repeated transformer computations dominate runtime. - The selected implementation supports the correct WAN 2.2 architecture. - The cache policy preserves enough newly computed information to maintain video quality. Excessive caching can introduce temporal instability, reduced motion detail, or other artifacts. Caching may also be less beneficial with an already distilled four-step model because fewer steps remain available to skip. **Recommended approach:** Benchmark caching independently before combining it with distillation, aggressive quantization, or alternative attention kernels. ## 8. Use Torch.compile for Repeated Video Generation PyTorch's `torch.compile` can accelerate model execution by optimizing operations and reducing some execution overhead. For transformer workloads, compilation can fuse operations and produce more efficient kernels. However, compiling a large video generation model may require considerable startup time and additional memory. ### When compilation is worthwhile Compilation is particularly useful when running many generations using the same model, resolution, frame count, and execution configuration. The first inference may be slower because kernels are being compiled. Later runs can reuse compiled artifacts. Changing input shapes or other relevant execution conditions may trigger recompilation. For an occasional single video, compilation overhead may outweigh the subsequent speed improvement. For persistent inference services, repeated jobs can amortize the compilation cost. ### WAN 2.2-specific considerations The A14B architecture contains two separate denoisers. A compilation strategy must account for the components actually used by the pipeline. Additionally, aggressive CPU offloading, LoRA implementations, and custom attention methods can introduce graph breaks or unsupported operations. Hugging Face documents these trade-offs in its Diffusers optimization guide. A practical sequence is to establish stable baseline inference, enable the intended quantization and attention backend, and only then evaluate compilation. Measure both cold-start and warmed-up generation times. Do not compare a compiled pipeline's warm run with an uncompiled pipeline's first model-loading run. ## 9. Optimize WAN 2.2 in ComfyUI ComfyUI provides a practical environment for experimenting with WAN 2.2 generation settings without modifying the original Python inference scripts. Its native workflows support the 5B hybrid model and the larger A14B text-to-video and image-to-video variants. The official ComfyUI WAN 2.2 workflow guide includes downloadable examples and model placement instructions. ### Start with the official workflow Before installing additional custom nodes, update ComfyUI and load the appropriate WAN 2.2 template. The official templates provide a known starting point for model loading, text encoding, latent creation, sampling, VAE decoding, and video export. For the 5B hybrid workflow, the documented components include: ```text ComfyUI/models/diffusion_models/wan2.2_ti2v_5B_fp16.safetensors ComfyUI/models/vae/wan2.2_vae.safetensors ComfyUI/models/text_encoders/umt5_xxl_fp8_e4m3fn_scaled.safetensors ``` The A14B workflows use separate high-noise and low-noise diffusion models. They must be connected to the correct sampling stages. ### Recommended optimization order 1. Load the official workflow and confirm that normal generation succeeds. 2. Reduce the frame count for faster previews. 3. Lower the resolution where the workflow and model support it. 4. Reduce sampling steps conservatively and compare visual quality. 5. Switch to compatible distilled checkpoints or four-step adapters when available. 6. Use supported FP8 or other quantized models if memory pressure is significant. 7. Test alternative attention backends. 8. Introduce caching only after establishing a stable configuration. 9. Tune model offloading and block swapping according to available VRAM. 10. Benchmark the complete workflow rather than relying only on sampler progress. ### Block swapping in ComfyUI Block swapping moves selected transformer blocks between GPU and system memory. It can allow larger models to run on hardware that could not otherwise hold all required weights. The downside is additional transfer overhead. Increasing the number of swapped blocks can reduce VRAM usage while increasing generation time. The optimal setting is generally the smallest amount of swapping that allows inference to complete reliably. ### When to use WanVideoWrapper Kijai's ComfyUI-WanVideoWrapper provides additional WAN-focused features and advanced inference options. These may include specialized memory management, attention backends, caching, and model-specific workflows. However, additional custom nodes can introduce compatibility problems when ComfyUI or PyTorch is updated. The wrapper's own documentation recommends native functionality when it already supports the required model and features. **For most beginners, native ComfyUI workflows are the safest starting point.** Advanced wrappers become more useful when a specific optimization or experimental capability is unavailable natively. ## 10. Accelerate the Official WAN 2.2 Python Implementation The official inference implementation provides command-line settings for controlling frame count, sampling steps, precision, and memory management. The following examples assume that the official repository and corresponding checkpoints have already been downloaded and configured according to its installation instructions. ### Example A: A faster TI2V-5B preview The official TI2V-5B task supports the `1280*704` output size. A shorter, reduced-step preview can be generated with: ```bash python generate.py --task ti2v-5B --size '1280*704' --ckpt_dir ./Wan2.2-TI2V-5B --offload_model True --convert_model_dtype --t5_cpu --frame_num 33 --sample_steps 24 --base_seed 42 --prompt 'A small red robot walks through a futuristic city at sunset, cinematic tracking shot' --save_file wan22_preview.mp4 ``` This example reduces the frame count and uses fewer steps than the official 5B default configuration. It is a **speed-oriented experimental preview setting**, not an officially validated quality preset. Visual fidelity and motion quality may decrease. The memory-saving options are retained because this example targets consumer GPUs with limited VRAM. ### Example B: Lower-resolution A14B text-to-video preview For the A14B text-to-video model, the original implementation supports an 832 × 480 output size. ```bash python generate.py --task t2v-A14B --size '832*480' --ckpt_dir ./Wan2.2-T2V-A14B --offload_model True --convert_model_dtype --frame_num 49 --sample_steps 24 --base_seed 42 --prompt 'A cinematic drone shot of ocean waves approaching a rocky coastline' --save_file wan22_t2v_preview.mp4 ``` The official repository documents an approximately 80GB GPU requirement for its standard single-GPU A14B example. This lower-resolution command does not guarantee that the model will fit a smaller GPU. The A14B model can also be run using compatible quantized or offloaded implementations, but hardware requirements depend on the chosen runtime. ### Example C: Check GPU usage Before generation, inspect the GPU and available memory: ```bash nvidia-smi --query-gpu=name,memory.total,memory.used,utilization.gpu --format=csv ``` Monitor memory and GPU utilization while the workflow runs. A GPU operating near its memory limit may experience expensive offloading or out-of-memory errors. Low GPU utilization during generation can indicate data transfers, CPU processing, synchronization overhead, or another bottleneck. It does not automatically prove that the model itself is inefficient. ### Important command-line parameters | Parameter | Purpose | Performance impact | |---|---|---| | `--frame_num` | Number of generated frames | Lower values reduce temporal workload | | `--sample_steps` | Number of sampling steps | Lower values reduce denoising work | | `--size` | Output dimensions | Smaller supported sizes reduce spatial workload | | `--offload_model` | CPU offloading | Saves VRAM but may increase latency | | `--convert_model_dtype` | Uses configured inference precision | Primarily a memory and compatibility optimization | | `--t5_cpu` | Runs text encoding on CPU | Saves VRAM but may slow preparation | | `--base_seed` | Controls reproducibility | Useful for fair visual comparisons | | `--use_prompt_extend` | Enables prompt expansion | Adds preprocessing work when enabled | For generation-speed experiments, consider leaving prompt extension disabled unless it is required for prompt quality. The official example workflow does not require it. ## 11. Try LightWan2.2-A14B for Extremely Fast RTX 5090 Inference One of the most significant developments in WAN 2.2 inference optimization arrived through LightX2V in 2026. The team released LightWan2.2-A14B, a specialized implementation combining: - Four-step distillation. - NVFP4 quantization-aware optimization. - Sparse attention. - Hardware-specific inference kernels. - A LightX2V runtime optimized for the model. The four-step architecture uses two high-noise denoising steps followed by two low-noise steps. ### Published RTX 5090 benchmarks The LightX2V team reports the following end-to-end results on a single RTX 5090 GPU: | Task | Resolution | Standard WAN 2.2 | LightWan2.2-A14B | Reported speedup | |---|---|---:|---:|---:| | Text-to-video | 480p | 734.0 seconds | 9.1 seconds | 80.7× | | Text-to-video | 720p | 2668.0 seconds | 22.5 seconds | 118.7× | | Image-to-video | 480p | 787.0 seconds | 10.7 seconds | 73.9× | | Image-to-video | 720p | 2685.0 seconds | 26.7 seconds | 100.5× | These are **developer-published benchmarks**, not independently reproduced measurements. The comparison uses the developer's standard 40-step baseline versus its optimized four-step implementation. The reported acceleration combines multiple techniques and should not be attributed to NVFP4, sparse attention, or distillation individually. Results are specific to the documented hardware and software configuration. Video quality, output characteristics, model behavior, and implementation differences must be evaluated alongside speed. The figures should not be interpreted as guaranteed performance on RTX 4090, RTX 3090, or unrelated GPUs. ### Hardware compatibility matters LightWan2.2-A14B is designed for NVIDIA Blackwell hardware, including the RTX 50-series family. Its NVFP4 implementation relies on hardware-specific features and kernels. It is not a universal replacement for FP8 or BF16 inference on older architectures. The model's documentation recommends the official LightX2V runtime and provides dedicated inference scripts. After preparing the required environment, model files, and dependencies, the relevant script entry points include: ```bash bash scripts/wan22/extreme/run_wan22_moe_t2v_extreme.sh bash scripts/wan22/extreme/run_wan22_moe_i2v_extreme.sh ``` These commands are run from the appropriate LightX2V project directory. They are not standalone installation commands, and the required model paths and environment must be configured first. **Best use case:** RTX 5090 and other supported Blackwell GPU systems where maximum generation throughput justifies using a specialized inference stack. ## 12. Benchmark WAN 2.2 Properly Before Changing More Settings Performance tuning is only useful when improvements can be measured reliably. A frequent mistake is comparing two generations that use different models, frame counts, prompts, resolution settings, and sampling configurations. That makes it impossible to determine which optimization produced the improvement. ### Measure the right metrics At minimum, record: - GPU model and VRAM capacity. - WAN 2.2 checkpoint and precision format. - Resolution and generated frame count. - Number of sampling steps. - CFG or guidance configuration. - Attention backend. - Cache and offloading settings. - Model-loading time. - Sampling time. - VAE decoding and export time. - Total end-to-end latency. - Peak GPU memory consumption. Where possible, measure more than one generation after the initial warm-up. ### Use a reproducible benchmark matrix | Test | Steps | Frames | Attention | Cache | Objective | |---|---:|---:|---|---|---| | Baseline | 40 | 81 | Default | Off | Reference quality and speed | | A | 24 | 81 | Default | Off | Measure step reduction | | B | 24 | 49 | Default | Off | Measure shorter output | | C | 24 | 49 | Alternative | Off | Measure attention improvement | | D | 24 | 49 | Alternative | On | Measure cache improvement | These values are illustrative experimental settings, not universal presets. The baseline must match the official or established configuration of the model being tested. For distilled models, construct a separate benchmark matrix using the required four-step scheduler and guidance settings. ### Calculate the real speedup ```text Speedup = Baseline end-to-end latency / Optimized end-to-end latency ``` For example, if a reference workflow takes 600 seconds and an optimized workflow takes 200 seconds, the end-to-end speedup is 3×. A reduction from 40 to 20 steps does not automatically produce a 2× overall speedup because non-denoising operations remain. For production applications, also measure throughput, queue waiting time, failure rate, and the percentage of outputs meeting the desired quality standard. An optimization that produces videos twice as fast but causes substantially more failed generations may not improve effective production efficiency. ## Recommended WAN 2.2 Settings by GPU Class The best configuration depends heavily on available VRAM and GPU architecture. | GPU memory or hardware | Suggested starting point | Main limitation | |---|---|---| | 8GB VRAM | Native ComfyUI TI2V-5B with offloading | Slow transfers and limited headroom | | 12–16GB VRAM | Quantized or aggressively offloaded compatible workflows | Memory pressure and possible quality trade-offs | | 24GB RTX 3090 / 4090 | TI2V-5B with the official memory-saving options, or optimized quantized workflows | A14B usually needs substantial additional memory management | | 32GB RTX 5090 | Compatible accelerated WAN 2.2 implementations, including Blackwell-specific optimizations | Software and kernel compatibility | | 48GB professional GPU | Larger quantized models, reduced offloading, specialized attention | Capacity still depends on checkpoint and generation dimensions | | 80GB-class accelerator | Official larger-model configurations with reduced offloading | Compute and attention may remain the main bottleneck | These are starting points rather than guaranteed memory requirements. ComfyUI's official documentation states that the 5B model can fit on approximately 8GB VRAM using native offloading. The official WAN Python example, by contrast, documents its 5B setup for a GPU with at least 24GB VRAM. These statements are not contradictory: **the execution framework and memory-management strategy can dramatically change the hardware required to run the same underlying model.** An 8GB configuration that technically runs may still be much slower than a less-offloaded configuration on a 24GB GPU. ## Common WAN 2.2 Speed Optimization Mistakes **Mistake 1: Setting an ordinary checkpoint to four steps without distillation.** A standard checkpoint generally cannot preserve its normal generation quality when forced to use a drastically shorter denoising schedule. Use a model or LoRA trained for the intended step count. **Mistake 2: Mixing high-noise and low-noise LoRAs.** WAN 2.2 A14B uses separate denoisers. Loading the wrong adapter into the wrong expert, or applying an I2V adapter to an incompatible T2V model, may cause failures or poor output. **Mistake 3: Assuming quantization always improves raw inference speed.** Some quantized implementations require additional conversion or dequantization operations. Their main benefit may be memory reduction rather than faster kernels. **Mistake 4: Enabling maximum offloading on a GPU with enough VRAM.** Unnecessary transfers between RAM and VRAM can make generation substantially slower. Offloading should be calibrated to actual memory requirements. **Mistake 5: Comparing sampler time instead of total latency.** A faster sampler can still produce disappointing end-to-end performance if model loading, decoding, or transfers dominate the workload. **Mistake 6: Changing too many optimizations simultaneously.** Combining caching, low precision, alternative attention, new schedulers, and experimental LoRAs makes regressions difficult to diagnose. **Mistake 7: Using unsupported resolutions.** The original WAN 2.2 CLI restricts resolutions by task. In particular, TI2V-5B does not accept 832 × 480 in the unmodified official configuration. **Mistake 8: Confusing FPS metadata with generated frame count.** Exporting the same frames at a different playback FPS does not reduce diffusion computation. Generate fewer frames to reduce the actual workload. **Mistake 9: Ignoring compilation warm-up.** Torch compilation can make an initial run considerably slower. For accurate comparisons, separate compile time from steady-state inference time. **Mistake 10: Applying every optimization to every model.** WAN 2.2 TI2V-5B, A14B, Animate, and S2V have different architectural and conditioning requirements. Techniques validated for one variant may not transfer directly to another. ## How to Make WAN 2.2 Faster Without Losing Too Much Quality The strongest optimization strategy is usually progressive rather than aggressive. Start by identifying whether the bottleneck is computation, memory, or workflow overhead. If the GPU is performing sustained high-utilization denoising, prioritize fewer steps, compatible distillation, efficient attention, and shorter outputs. If inference is dominated by CPU-to-GPU transfers, prioritize memory management and supported quantization. If model loading dominates every job, keep a persistent inference process alive instead of reloading checkpoints for every request. If decoding dominates the final stage, investigate the available VAE tiling, decoding precision, and memory settings. VAE tiling can reduce peak memory requirements, but smaller tiles may increase decoding time. ### A practical quality-preserving workflow 1. Generate a standard-quality baseline using a known-good workflow. 2. Reduce frames for fast composition and motion tests. 3. Reduce steps moderately and compare with the baseline. 4. Test a compatible distilled model separately. 5. Introduce one hardware-supported attention optimization. 6. Use quantization when it meaningfully reduces memory pressure. 7. Minimize offloading until the configuration approaches the available VRAM limit safely. 8. Keep whichever configuration offers the best balance of speed, stability, and acceptable video quality. The goal should not be the smallest possible number of seconds at any cost. For practical content production, **usable videos per hour** is often a more meaningful metric than theoretical maximum inference speed. ## WAN 2.2 Speed Optimization for Cloud GPU and API Workflows The same principles apply to cloud deployments, but additional factors become important. A hosted video generation job may spend time waiting for a GPU before inference even begins. Its overall completion time may be expressed as: ```text Job completion time = Queue delay + Model initialization + Inference + Encoding + Upload and delivery ``` A provider advertising fast GPU inference may still deliver slower overall results if queue times are significant. For self-hosted services, persistent model workers can reduce repeated checkpoint loading and compilation overhead. For multi-GPU systems, the official WAN 2.2 repository supports distributed inference techniques including PyTorch FSDP and DeepSpeed Ulysses. These techniques can distribute model or attention workloads across GPUs, although communication overhead and hardware topology affect scaling efficiency. When evaluating cloud configurations, compare: - Average and high-percentile end-to-end latency. - Cost per completed generation. - Effective output throughput per GPU-hour. - GPU memory headroom. - Queue waiting time. - Cold-start frequency. - Retry and failure rates. For workloads with consistent traffic, persistent workers and appropriate batching strategies may improve total system efficiency. For occasional generation, a managed service can be more convenient than maintaining a dedicated GPU, although its performance and costs depend on the provider. ## Frequently Asked Questions **Why does WAN 2.2 take so long to generate a video?** Video diffusion requires repeated transformer computations over spatial and temporal information. High resolution, long clips, large checkpoints, CPU offloading, and numerous sampling steps can substantially increase inference time. **What is the fastest way to speed up WAN 2.2?** For supported models, four-step distillation can provide one of the largest reductions in denoising workload. For standard checkpoints, reducing frames and using efficient attention are practical starting points. **Can WAN 2.2 generate videos in under 30 seconds?** Yes, in specialized configurations. LightX2V reports end-to-end results below 30 seconds on a single RTX 5090 for several LightWan2.2-A14B test cases. These results require the documented optimized architecture and hardware and are not representative of ordinary WAN 2.2 configurations. **Does WAN 2.2 support four-step generation?** Compatible distilled models and LoRAs support four-step inference. The original full-step checkpoints should not be expected to maintain normal quality when arbitrarily reduced to four steps. **Is WAN 2.2 faster with FP8?** FP8 can reduce model memory requirements and memory traffic. Whether it improves inference speed depends on hardware, kernels, dequantization overhead, and how much CPU offloading it eliminates. **Can WAN 2.2 run on an 8GB GPU?** ComfyUI documents a native-offloaded TI2V-5B workflow intended to fit within approximately 8GB VRAM. However, performance and compatibility depend on the environment, and the official Python implementation documents a higher memory requirement for its standard configuration. **Is WAN 2.2 faster on RTX 4090 or RTX 5090?** Performance depends on the implementation, model, and precision format. The RTX 5090 can benefit from Blackwell-specific NVFP4 optimizations unavailable on the RTX 4090. A direct comparison requires identical compatible workloads and complete latency measurements. **Does SageAttention make WAN 2.2 faster?** It can improve attention computation on compatible GPUs and frameworks. Actual end-to-end benefits vary, and installation requirements should be checked carefully. **Should MagCache and Lightning LoRAs be used together?** Not automatically. A four-step distilled workflow already performs very few denoising steps, reducing the opportunity for caching. Combining them may provide little benefit or negatively affect output quality. **Can changing FPS speed up video generation?** Changing export FPS alone does not reduce model computation. Reducing the number of generated frames is what lowers the temporal workload. **What is the best WAN 2.2 configuration for ComfyUI?** For beginners, the official TI2V-5B workflow is a useful starting point. For users with more GPU memory or advanced optimization requirements, compatible A14B checkpoints, distilled adapters, and specialized inference wrappers provide additional options. **Is it better to use WAN 2.2 TI2V-5B or A14B?** TI2V-5B is generally more convenient for consumer hardware and quick experimentation. A14B provides a larger model architecture but requires significantly more resources in standard configurations. The best choice depends on the desired output quality, generation mode, and available hardware. ## Conclusion Making WAN 2.2 video generation faster requires optimizing the entire inference pipeline, not simply adjusting one sampling parameter. For most users, the highest-impact starting points are **fewer frames, compatible reduced-step models, efficient attention, and better GPU memory management**. Four-step distilled LoRAs can dramatically reduce denoising work, while FP8 quantization and careful offloading can make larger models more practical on consumer hardware. Advanced methods such as MagCache, cache-dit, and torch.compile can provide additional improvements when applied to compatible workflows. For NVIDIA Blackwell users, LightWan2.2-A14B demonstrates how combining distillation, NVFP4, sparse attention, and specialized kernels can produce exceptionally fast inference under controlled conditions. However, performance claims should always be evaluated alongside hardware requirements, model compatibility, video quality, and complete end-to-end latency. **The recommended next step is to benchmark the current WAN 2.2 workflow, identify its primary bottleneck, and apply one optimization at a time.** Start with the official WAN 2.2 repository, the ComfyUI workflow documentation, or LightX2V according to the intended hardware and deployment environment. A carefully optimized workflow can substantially improve video generation throughput while preserving the motion consistency, prompt adherence, and visual quality that make WAN 2.2 useful for AI video production.