Wan2gp best setting for fasteste generation

Beginners
1

Hello everyone, I’d like to know if anyone who has used the WAN2GP model for a PC with Windows 11 has been able to generate video from an image and the prompt in the shortest possible time. When I installed it, it took 5 hours and 20 minutes to generate 5 seconds of video. Now that I’ve downloaded the accelerators, it only takes 1 hour. I want to know if anyone can help me get the best settings, or what I need to do so that my PC takes at least 10 or 20 minutes instead of 50. My graphics card isn’t very good; I only have a low-end MSI 5060 Ti 16GB OC. The processor is an Intel 12700f, and I have 32GB of RAM. Your help in getting the best settings would be greatly appreciated. I’m new to local AI. Thanks, and have a good day. I downloaded the accelerators called Lightningi2v Enhanced Pro Something Low and High Noise. (note: I use WAN2GP on forge neo) NOT in comfy UI

2

Hmm… There isn’t enough information to tell yet, but common causes in general include not making full use of the available VRAM, differences in backend speed, and the level of quantization:

1. Where I would start

Getting from roughly an hour to 10–20 minutes may be possible, but it depends heavily on the exact model, resolution, frame count, quantization, and generation backend. I wouldn’t assume the RTX 5060 Ti 16GB itself is the main limitation yet.

The fact that adding Lightning acceleration reduced your generation time from 5 hours 20 minutes to about an hour is already useful information. It suggests that reducing the denoising workload helped, but something else may still be consuming a lot of time.

I’d look at three possibilities first:

  1. VRAM allocation and offloading. Too much of the model may be staying in system RAM and repeatedly moving between CPU and GPU. The opposite can also happen: filling VRAM too aggressively may trigger Windows shared-memory fallback, which can be extremely slow.
  2. The generation backend. Forge Neo, ComfyUI, and standalone WanGP can use different model-loading, quantization, attention, and memory-management implementations. The same model and nominal step count do not necessarily produce the same generation time.
  3. Quantization and model configuration. FP8, GGUF, and other low-bit formats have different memory requirements and computational overhead. Smaller model files do not automatically mean faster inference.

Resolution and frame count also matter considerably. A five-second video at one frame rate may require substantially more frames than a five-second video at another.

One important distinction: using VRAM efficiently does not mean keeping VRAM at 100% usage. The GPU still needs working memory for attention, intermediate tensors, and video decoding.

2. A reasonable starting point for Forge Neo

Since you mentioned Forge Neo rather than ComfyUI, I’d start by checking its native Wan 2.2 configuration.

For Wan 2.2 I2V A14B, Forge Neo supports switching between the High Noise and Low Noise models through its Refiner feature.

The relevant references are:

If you are using a compatible 4-step Lightning I2V setup, the following is a useful configuration to compare against, rather than a universal fastest preset:

Component Starting point
Main model Wan 2.2 I2V A14B High Noise
Refiner Matching I2V A14B Low Noise
Model precision Supported FP8-scaled or GGUF variants
Lightning LoRA Correct version for the corresponding model/stage
Steps 4, if recommended by that specific Lightning version
CFG 1.0 for the corresponding distilled setup
Sampler / scheduler Euler / Simple if specified by the LoRA workflow
Diffusion in Low Bits Automatic initially

The exact Lightning model matters here.

You mentioned something like “Lightning I2V Enhanced Pro” with High Noise and Low Noise variants. I couldn’t confidently identify the exact release from that name alone, so I wouldn’t assume its recommended schedule is identical to every other Lightning version.

For comparison, the LightX2V Wan2.2-Lightning model card documents four-step I2V generation, but those instructions should only be applied directly if you are using the corresponding model or LoRA variant.

Also, make sure that the High Noise and Low Noise checkpoints and LoRAs are actually associated with the correct stages. A LoRA appearing in the interface does not necessarily prove that the intended Low Noise variant is being applied after the Refiner switch.

3. The most useful first check

If convenient, could you share one screenshot of the generation settings or the generated video’s Infotext, ideally including the Refiner settings?

The most useful information would be the model and LoRA filenames, resolution, frame count, Steps, CFG, and Refiner configuration.

You can hide your prompt, image, and personal file paths.

That would help distinguish a configuration issue from a memory-management or backend-performance issue without asking you to run several expensive experiments.

In the meantime, here’s how I’d narrow it down.

4. Quick troubleshooting guide

What you observe What I would investigate
Unexpected step count or model/LoRA combination Lightning configuration, actual preset values, Refiner and LoRA switching
Every denoising step is extremely slow CPU/GPU transfers, dedicated and shared GPU memory, quantization and attention
Long pause when switching from High Noise to Low Noise Refiner checkpoint loading, memory availability, RAM usage
Denoising completes relatively quickly, but the final video takes a long time VAE decoding, video export or other postprocessing
Memory usage appears reasonable, but generation is still very slow Quantization kernels, active attention implementation, backend differences
First generation is acceptable but subsequent generations become much slower Retained memory, repeated model loading or system RAM/pagefile pressure

If the settings already look reasonable, I’d particularly suspect the memory-transfer side before trying increasingly aggressive acceleration options.

For a quick check, Windows Task Manager can show Dedicated GPU memory, Shared GPU memory, and system RAM usage while generation is running.

If dedicated VRAM is exhausted and shared GPU memory rises substantially, that is a useful clue. If dedicated VRAM remains relatively free but every step is still slow, excessive CPU offloading or a slow compute path becomes more interesting.

I would not immediately disable all CPU offloading or Windows shared-memory fallback. On a 16GB card, those mechanisms may be preventing an out-of-memory crash.

More detail: Forge Neo, WanGP, and the Lightning/Refiner configuration

A. First distinguish Forge Neo from standalone WanGP

There is a small naming ambiguity in “WAN2GP on Forge Neo.”

WanGP and Forge Neo are separate applications with different memory-management systems.

  • Forge Neo supports Wan 2.2 through its own model-loading and Refiner implementation.
  • WanGP uses its MMGP memory-management system, with settings such as memory profiles and model preloading.

If you are generating through Forge Neo’s native interface, I would follow the Forge-specific instructions first.

If you are actually running a standalone WanGP instance, its MMGP settings become relevant instead. In that case, the WanGP documentation is the appropriate starting point.

For example, WanGP’s Profile 4 is not a Forge Neo setting. A recommendation based on that profile should not be transferred directly to Forge.

B. Check the actual High Noise / Low Noise model pair

The Forge Neo model list provides separate Wan 2.2 I2V High Noise and Low Noise checkpoints, including FP8-scaled and GGUF options.

A typical FP8-scaled arrangement looks like:

Main checkpoint:
  wan2.2_i2v_high_noise_14B_fp8_scaled

Refiner checkpoint:
  wan2.2_i2v_low_noise_14B_fp8_scaled

Text encoder:
  UMT5-XXL

VAE:
  Wan 2.1 VAE

These are component examples, not a claim about your currently installed models.

Check that both checkpoints are I2V rather than T2V, and that they belong to compatible versions.

The High Noise and Low Noise stages are part of the same generation process. The Refiner must switch to the intended checkpoint at the intended point in the denoising schedule.

Also, don’t assume that a Refiner switch value such as 0.9 is universally correct. The meaning of the threshold can depend on whether the application is interpreting it as a step fraction or a noise-level threshold. The model or LoRA author’s workflow should take precedence.

C. A subtle Forge Neo LoRA naming issue

Forge Neo can automatically replace LoRA names when switching to the Refiner.

Its default replacement rules include:

high_noise=low_noise
high-noise=low-noise

However, the implementation performs case-sensitive string replacement.

That means a filename containing uppercase HIGH will not match the lowercase high_noise rule.

If your LoRAs have names such as:

Wan2.2-Lightning_I2V-A14B-4steps-lora_HIGH_fp16
Wan2.2-Lightning_I2V-A14B-4steps-lora_LOW_fp16

the default lowercase replacement rules alone would not convert the first name into the second.

Depending on how your LoRAs are configured, a matching replacement rule could look like:

_HIGH_=_LOW_

This is not proof that your Low Noise LoRA is currently missing. It’s simply a useful thing to check if you are relying on automatic LoRA replacement.

The relevant implementation is available in:

Some distilled workflows also have different expectations about which stages receive which LoRAs. Follow the specific LoRA author’s instructions rather than assuming that every Lightning setup requires the same arrangement.

D. Confirm the effective settings, not just the UI defaults

Forge Neo’s preset system can save checkpoint/module selections and generation parameters, overriding the normal UI defaults.

Therefore, it is worth checking the generated Infotext rather than relying only on remembered settings.

In particular:

  • Is the effective step count the one you intended?
  • Is CFG actually 1.0 for a compatible distilled setup?
  • Is the correct High Noise checkpoint selected?
  • Is the expected Low Noise checkpoint selected as Refiner?
  • Does the LoRA mapping correspond to the actual filenames?
  • Is the reported resolution and frame count what you expected?

For Lightning, be careful not to mix settings intended for a non-distilled model with settings intended for a four-step distilled model.

Also, don’t automatically interpret a four-step recommendation as four steps for each expert. The author’s definition of the inference schedule and the way the backend splits it between stages must agree.

More detail: Why VRAM allocation and offloading can make such a large difference

A. Two opposite memory problems

There are two important ways memory management can slow generation.

Case 1: Too much of the model remains on the CPU

A large video model may not fit entirely into 16GB VRAM, so some degree of CPU offloading is normal.

The problem is the frequency and volume of transfers.

If layers or weights need to move repeatedly across PCIe during denoising, transfer time can dominate computation.

Symptoms may include:

  • Very slow individual steps.
  • Significant system RAM usage.
  • Dedicated VRAM not necessarily being full.
  • Periods of GPU inactivity or low utilization while data is transferred.

In this situation, allocating more of the appropriate model weights to VRAM might help, provided sufficient working memory remains available.

Case 2: VRAM is overcommitted

The opposite problem occurs when the application attempts to keep too much in GPU memory.

Even if quantized model weights seem to fit, actual inference also requires memory for:

  • Attention calculations.
  • Intermediate activations.
  • Temporary quantization/dequantization buffers.
  • Model switching.
  • VAE decoding and related processing.

When dedicated VRAM becomes insufficient, Windows may move allocations into shared system memory instead of immediately failing.

NVIDIA documents this behavior in its System Memory Fallback explanation.

It can keep an operation alive, but performance may become dramatically worse because system memory is much slower to access from the GPU than local VRAM.

The important point is that both too much offloading and too little available VRAM can cause severe slowdown.

The best configuration is somewhere between them, and its location depends on the workload.

B. What to watch in Task Manager

Open Task Manager, go to Performance, select GPU, and observe memory usage during generation.

Observation Interpretation
Dedicated GPU memory nearly full, shared GPU memory increasing Possible VRAM pressure and shared-memory fallback
Dedicated GPU memory relatively low, RAM usage high, steps slow Possible excessive planned offloading
Dedicated and shared memory look reasonable, steps still slow Investigate compute path, quantization, attention or other bottlenecks
RAM usage grows between generations Investigate memory retention, model reloads or pagefile activity

These are clues, not definitive diagnoses. Task Manager does not show every internal allocation or transfer, and GPU utilization percentage alone is not enough to identify the bottleneck.

Combining memory observations with approximate seconds per step is much more useful.

Also, with 32GB system RAM, avoid settings that assume unlimited RAM is available for holding several very large model components. Heavy paging to disk can make things substantially worse.

C. Why faster Attention is not always faster overall

SageAttention and similar optimized kernels can improve attention computation considerably when the workload fits comfortably into the available memory.

However, they do not remove every other bottleneck.

There is an interesting example in InvokeAI issue #9831.

The reporter tested Wan 2.2 with Lightning acceleration on a 24GB RTX 4090 and obtained very different generation times depending on memory reservation, partial loading, and attention implementation.

Some configurations using SageAttention were actually slower because the additional memory requirements pushed the workload into an unfavorable memory state.

That is a different application and GPU, so the exact settings do not transfer to Forge Neo.

But the general lesson is useful:

An attention implementation that is faster when everything fits in VRAM may become slower when its additional memory requirements trigger spilling or excessive transfers.

I would therefore confirm the memory situation before adding multiple attention optimizations.

More detail: Quantization, backend differences, and real-world comparisons

A. FP8 versus GGUF and other low-bit formats

Quantization reduces the storage precision of model weights.

This can help by reducing memory requirements, allowing more weights to remain GPU-resident.

But it does not guarantee faster inference.

For example:

  • An FP8 model may run efficiently when supported by the GPU and its kernels.
  • A GGUF Q4 or Q5 model can use less memory, potentially reducing offloading.
  • Some quantized formats require additional conversion or dequantization work.
  • Different backend implementations may have substantially different performance for the same nominal precision.

In practice, the fastest configuration is not necessarily the smallest model file.

On 16GB VRAM, a lower-bit model that reduces excessive transfers may be faster overall than a larger-precision model.

But if a larger model already fits the effective memory budget, changing to a more aggressively quantized version may provide little benefit or even reduce performance.

For Forge Neo, I would first use one of the model formats listed in its supported model references.

Its inference reference page also recommends leaving Diffusion in Low Bits on Automatic unless you have a particular reason to change it.

That is a sensible baseline before comparing alternative formats.

If a precision change is worth testing, keep the model family, LoRA, frame count, resolution, and other settings as consistent as possible.

And compare both generation time and output quality.

B. Yes, Forge Neo and ComfyUI have shown different performance

There is a particularly relevant comparison in Forge Neo issue #258.

The reporter was generating Wan 2.2 I2V videos with Lightning acceleration and encountered memory-related issues in Forge Neo.

Their Forge Neo Infotext included:

Resolution: 1280x720
Frames: 49
Steps: 4
CFG: 1
Sampler: Euler
Scheduler: Simple
High Noise model: Wan 2.2 I2V A14B FP8-scaled
Low Noise model: Wan 2.2 I2V A14B FP8-scaled

The reported Forge Neo generation time was approximately 7 minutes 57 seconds.

The same reporter then tried ComfyUI and described it as substantially faster.

The ComfyUI log showed approximately:

High Noise sampling: 2m 12s
Low Noise sampling:  2m 14s

So the reported ComfyUI sampling time was approximately 4 minutes 26 seconds.

However, this is not a controlled end-to-end speed comparison:

  • Forge Neo’s number was the total reported generation time.
  • The ComfyUI numbers were sampling stages, not necessarily the complete pipeline.
  • The model-loading and attention configurations may differ.
  • The GPU in that report had 24GB VRAM rather than your 16GB.
  • The issue is historical and has since been closed.

It does not prove that the current Forge Neo is universally slower than ComfyUI.

What it does establish is that backend-specific behavior can matter, even with similar models and generation settings.

You also don’t necessarily need to switch to ComfyUI. A better first step is to identify whether Forge Neo is spending its time on sampling, transfers, model switching, or decoding.

C. Refiner switching can also consume memory and time

The same Forge Neo issue #258 contains a discussion of high system RAM usage during repeated generations and Refiner switching.

The developer later suggested the Refiner option:

Settings / Refiner
  Reload "state_dict" Only

A user reported a substantial reduction in memory consumption after enabling it, although they did not observe a corresponding improvement in execution time.

This is an important distinction: lower memory usage does not necessarily mean faster generation.

If your system shows a large RAM spike or long pause specifically when the Refiner changes models, that option may be worth investigating on a current Forge Neo version.

But I wouldn’t make it the first change without observing a relevant symptom.

D. Other known performance pitfalls

There have also been reports involving low-bit quantization, LoRA application, and memory management in Forge Neo.

For example:

Both changes were merged in 2026. They should be viewed as historical implementation context, not evidence that your current installation has those same bugs.

There is also a ComfyUI report involving aggressive model offloading on an RTX 5060 Ti 16GB. It describes low VRAM residency and slow execution with a quantized Wan 2.2 model.

Again, that is a different implementation, but it illustrates why substantial CPU offloading can be worth investigating even when dedicated VRAM is not full.

E. Attention selection and backend configuration

Forge Neo supports multiple attention implementations, but installing an optimized attention library is not necessarily the same as actually selecting it for generation.

The active attention backend, PyTorch version, CUDA compatibility, and model precision can all affect performance.

The Forge Neo README documents its attention support and related installation options.

I’d avoid blindly combining multiple acceleration flags or reinstalling PyTorch, CUDA libraries, and attention packages at once.

Those changes can introduce compatibility problems, and if performance improves or regresses afterward, it becomes difficult to identify why.

A practical, low-cost way to narrow it down

The idea is to distinguish the major causes without turning this into a large benchmarking project.

Stage 1 — Compare the existing settings with a known configuration

No new generation is necessary for this part.

Check the Infotext from your latest successful run and compare it with:

  1. The installed Wan 2.2 I2V model and Refiner checkpoints.
  2. The exact Lightning LoRA version and its recommended step schedule.
  3. The LoRA filenames and Refiner replacement settings.
  4. The effective resolution, frame count, CFG, and sampler settings.
  5. The actual model precision and quantization.

If something clearly differs from the model author’s intended configuration, correct that item first.

This is usually more informative than immediately changing five performance settings.

Stage 2 — Identify where the hour is going

If the configuration looks correct, observe one normal generation, if you happen to run another.

Ideally, distinguish these phases:

Model / text encoder loading
          |
          v
High Noise denoising
          |
          v
High-to-Low model / Refiner switch
          |
          v
Low Noise denoising
          |
          v
VAE video decoding
          |
          v
Video encoding / export

You don’t need precise profiling tools.

Even approximate observations such as “each denoising step takes several minutes” or “sampling finishes quickly but exporting stalls” are enough to choose the next direction.

Stage 3 — Choose the relevant branch

If every denoising step is slow:

Check dedicated GPU memory, shared GPU memory, system RAM, and the active quantization/attention configuration.

If shared GPU memory rises heavily, consider memory pressure first.

If VRAM is mostly unused while RAM is busy and steps are slow, investigate whether too much of the model is being offloaded.

If neither pattern is apparent, examine the model’s compute format and backend.

If the High-to-Low transition takes a long time:

Look at Refiner loading, checkpoint replacement, and available RAM.

Compare the behavior on the first and subsequent generations.

A long switching delay suggests a different problem from consistently slow denoising steps.

If the slowdown occurs after denoising:

Look at VAE decoding and export.

VAE tiling can reduce memory usage, but may increase decoding time. It is useful when needed to fit the workload, not necessarily as a speed optimization.

Video export can also add time, particularly if additional processing is enabled.

If memory usage appears fine and sampling is still slow:

This is where attention implementation, quantization format, and backend comparisons become more valuable.

A different backend may help, but it is an optional comparison rather than something you must switch to.

Stage 4 — One small diagnostic generation, only if necessary

If the current resolution and frame count are high, one temporary smaller test can reveal a lot.

For example:

Same model
Same LoRA
Same steps and CFG
Same backend

Change only:
  Lower resolution, or
  Fewer frames

You could use a modest 480p-class resolution or a 33–49-frame diagnostic clip, depending on what the model and interface support.

This is not a suggestion to permanently give up the five-second video you want. It is a way to see whether the original workload crosses a memory or compute threshold.

Interpret the results cautiously:

Result What it suggests
Smaller workload is dramatically faster per step Memory threshold, attention scaling or excessive transfers may matter
Time decreases roughly with workload size Ordinary computational cost becomes more plausible
Step time barely changes Fixed overhead, transfer behavior, quantization or another bottleneck may dominate
Denoising becomes fast, but total time remains high Model loading, switching, VAE or export may dominate

These observations help narrow the problem, but a single test cannot establish the exact cause.

If you eventually want to compare two model precisions or two backends, keep all other settings fixed and compare both timing and visual results.

Additional references and how they apply

These are mainly useful if a particular symptom matches your setup.

Forge Neo configuration and implementation

Lightning and I2V model configuration

Memory and performance

Related reports from other setups

  • Forge Neo issue #258 — Wan 2.2 I2V/Lightning example, Forge/ComfyUI comparison and historical Refiner memory issues. Closed; not proof of a current regression.
  • ComfyUI issue #14447 — RTX 5060 Ti 16GB with aggressive offloading. Useful as a similar symptom, not evidence about Forge Neo itself.
  • Forge Neo issue #1275 — system RAM and pagefile pressure between generations, involving a different model.

The most relevant references for your immediate situation are still the Forge Neo documentation and the instructions for the exact Lightning LoRA you installed.

So my starting recommendation would be: verify the effective Forge Neo / Lightning / Refiner settings first, then check memory usage and per-step speed before changing the backend or quantization.

Your 10–20 minute target is worth investigating, but I wouldn’t promise a particular time without knowing the resolution, frame count, and actual memory behavior. The current one-hour result may reflect computational cost, avoidable memory transfers, or some combination of the two.

3

thanks so much for your response, I’ll do everything you mentioned, I know maybe I’ll not get the 10-20 min but at least reduce 20 min more from 50, the first video made in 5 hr. and 20 minutes with resolution of 1536 x 720 was too much but the quality and the well-made video worthing the wait, now trying to make it a bit fast with your suggestion, and I’ll try it, but the thing is my wan2gp is not in forge neo, I thought it was there but now, I was confused because, I was using Framepack thought pinokio, and now I install wan2gp in pinokio, but you know what? i can’t choose any other model or mode from the menu, after I installed the 2 lightning accelerator, I choose the one you see in the capture, and then after I can’t no longer choose another different, like I show you in my captures, another thing can you please help me explain to me? when I install wan2gp it was 83GB, then I installed the lighting accelerators and was 112GB, but now I don’t know why is 123GB, so my question is why is increasing the size of the model?

Screenshot 2026-10-15 132448
Screenshot 2026-10-15 132448793×345 23.2 KB

Screenshot 2026-10-15 132430
Screenshot 2026-10-15 1324301227×351 27.9 KB

Screenshot 2026-10-15 132313
Screenshot 2026-10-15 1323131423×880 60.4 KB

4

Ah, I see. If it’s Pinokio, I haven’t used it myself, but based on what I could find :thinking::

The short answer

Thanks for the clarification. FramePack through Pinokio, WanGP through Pinokio, and Forge Neo are not the same setup, so the Forge Neo-specific Refiner advice in my earlier reply is not the right place to start now. And since you are happy with the video quality, I would try to understand the current setup before sacrificing quality for speed.

I think there may be three separate things happening: (1) what the model and accelerator menus allow you to select, (2) what files have been added to disk, and (3) what still takes around 50 minutes during video generation. They may be connected, but we should not assume one problem caused all three.

About being unable to choose another model or mode: In the screenshot, Wan2.2, Image2video SVI 2 Pro Enhanced Lightning v2 14B, and Accelerators Profiles appear as different kinds of choices. Changing a model and changing an accelerator profile are not the same thing. According to the WanGP accelerator guide, available profiles depend on the model, and an already-accelerated model may not offer another accelerator. That could explain a limited accelerator list, but not a model selector that cannot be clicked. If clicking the actual model menu does nothing, a UI issue remains possible.

About 83 GB becoming 112 GB: This is the most specific clue I found. The published Enhanced Lightning v2 I2V FP8 weights include a HIGH-noise file of about 14.3 GB and a LOW-noise file of about 14.3 GB. Together they are about 28.6 GB, almost exactly your 29 GB increase. If WanGP downloaded that pair, this could simply be normal storage for two large weights, not a model unexpectedly growing. I cannot tell from the screenshots whether those exact files are on your PC.

About 112 GB becoming 123 GB: The additional 11 GB is still unexplained. It could be another model component downloaded when needed, a cache, another app’s files, previews or finished videos, or a different way of measuring folder/drive usage. A Hugging Face cache can occupy real space, but it is not always an extra copy of an app’s model; sometimes the cache is where the usable file lives. We should first find out what the 123 GB figure measures.

About going from 50 minutes closer to 30 minutes: It might be achievable, but I would not promise a particular time from the GPU model alone. The first 5-hour-20-minute video, the later Lightning result, and the current WanGP installation may not all be the same workload. A good first step is to identify which application made each clip and whether most time is spent generating frames or loading/switching/finishing the models. You do not need another hour-long run just to start that investigation.

What I would try first (without changing anything important)

1. Check which menu is affected. If it is Accelerators Profiles, a limited list may be expected. If it is the family/model choice, check whether the list opens but has few entries, does not open at all, or lets you select something but then reverts/freezes. Those are very different cases. If your interface has an All model-family filter or model search, check that before assuming everything is locked. The WanGP model guide describes these controls, although your Pinokio-installed version may look different.

2. Check where the storage number came from. Was it the size of the WanGP application folder, the size of all of Pinokio, or Windows’ used space on C: or another drive? If it is a folder, just look at the largest subfolders in Windows File Explorer. The Pinokio manual explains how its Files button opens the Pinokio Home location. No need to delete anything.

3. Preserve what already works. Keep the current model and settings that produce the quality you like. Avoid deleting weights, clearing caches, using Reset, reinstalling, or changing several performance settings at once. Those steps can introduce a new problem without diagnosing the original one.

What you actually see Most useful next interpretation
The list opens, but only one/few entries are offered Model family, model-specific options, filters, or compatibility limits
The Accelerators Profiles list is restricted The selected model may already include acceleration
The list does not open or other buttons are unresponsive A genuine interface/browser problem is possible
A different choice starts loading/downloading, then stalls The selection may work, while a download or model-loading step fails
About 29 GB appeared with Enhanced Lightning Compare with the published two-file, ~28.6 GB HIGH/LOW pair
Another 11 GB appeared later Find the measured folder before guessing which cache or component grew
The video still takes around 50 minutes Compare the app/workflow and identify the slow processing stage

If you feel like clarifying just two things, they would tell us a lot: (a) which menu fails and what happens when you try it; (b) where you saw the 83, 112 and 123 GB numbers. A plain description is enough. No command line, large logs, private paths, or new generation tests are required for those first checks.

The longer sections below are optional, including for later readers.

A. Model and accelerator menus: which situation is it?

A1. A small map of what the names mean

An AI video application can use the word model in several ways, and the UI may show all of these close together:

What you see A useful plain-English interpretation
Pinokio A program that installs and runs other programs, often in separate environments
FramePack / WanGP Different video-generation applications; they do not automatically share downloads or settings
Wan2.2 A family of models, not one uniquely identified file
I2V model / variant / finetune The particular image-to-video weights and workflow you selected
HIGH / LOW noise In some Wan workflows, two stages using different weights; not simply a high/low video-quality switch
LoRA Additional compatible weights that modify a model; often much smaller than a complete checkpoint
Accelerators Profile A preset for compatible acceleration LoRAs and settings, sometimes also steps/guidance
Mode Depending on the selected model, a type of input or a workflow-specific option

The key point: similarly named controls can do different jobs. The screenshot alone does not establish that model selection is broken.

The official Models guide explains model families and variants; the LoRAs / Accelerators guide explains acceleration presets. Your installed Pinokio version may differ.

A2. If the list opens, but the choices are limited

If the model-family or variant list has only a few entries: Check whether you are looking at the family, the particular model within it, or a model-specific mode. WanGP can organize these into levels, and a variant selector may not be shown when there is only one available choice. Output-type filters can also narrow the visible list. If the interface offers All or model search, use that as a navigation check, not as an instruction to download everything.

If it is specifically the accelerator list: The official guide says acceleration profiles depend on the selected model, and that no extra accelerator is offered for an already-accelerated model/finetune. It also says applying a compatible profile can change enabled LoRAs and the number of steps, with missing LoRAs sometimes downloaded when a generation starts. So a missing additional profile can be perfectly normal, and changing a profile can alter settings without changing the model itself.

There are small acceleration LoRAs and much larger already-accelerated model weights. The label Enhanced Lightning alone does not reveal how a particular preset is applied; do not download another release just because a menu entry is missing.

A3. If the menu itself will not respond

This would be a different problem. In that case, it is worth noticing whether only this dropdown is unresponsive or whether ordinary buttons elsewhere on the page also fail.

There is a relevant but not identical Pinokio / WanGP browser issue (#2386): the page was visible but could not be used in a regular browser, while the same app worked inside Pinokio’s own tab. The reporter saw HTTP 403 errors and later suspected Pinokio proxying interacting with WanGP’s access checks. That does not tell us your cause. It offers one easy observation: if you already have the same running app open both ways, does the behavior differ? There is no need to change network access or launch a second server to investigate.

One failed selector and an entirely unresponsive page point to different branches. An update history may help later; updating blindly is not the first check.

A4. If a selection appears to work, then fails

If you select a different entry and then see a spinner, a download, a loading message, an error, or a return to the original selection, the dropdown may actually have accepted the action. WanGP supports downloading models and optional assets when needed. The first use of a model can therefore take time and disk space.

An older model-switch front-end error (#1866) shows that true callback failures can also occur. That issue is relevant only if the observed symptom matches, for example the interface freezes immediately after a model choice. There is no reason to presume the same bug here.

If an error/status message is visible, its wording is more useful than guessing that Lightning locked the menu. A cropped screenshot is enough.

A5. Short menu decision tree

Which control am I trying to change?

Accelerators Profiles:
  Few/no options: possibly normal for this model.
  A profile applies but changes settings: expected type of action.
  The control does not respond: possible UI issue.

Model family / model variant:
  Opens with few choices: inspect family, filter, and model-specific mode.
  Opens and starts a download/load: wait for status; check errors if it fails.
  Does not open: distinguish single-dropdown failure from whole-page failure.
  Changes then reverts/freezes: inspect the visible loading/error state.

A separate video/input "mode":
  Check whether this specific model supports that mode.

The safest first goal is simply to identify which of these behaviors is occurring, not to reset or reinstall the app. If you later change a profile, save or note the working settings first: acceleration profiles can change steps and selected LoRAs.

B. Why storage can jump from 83 GB to 112 GB to 123 GB

B1. The strongest clue: a pair of large HIGH/LOW files

In the public DeepBeepMeep Wan2.2 files, the Enhanced Lightning v2 I2V FP8 checkpoint pair is listed as:

wan22EnhancedLightning_v2I2VFP8HIGH.safetensors   about 14.3 GB
wan22EnhancedLightning_v2I2VFP8LOW.safetensors    about 14.3 GB
                                                   -----------
Published pair                                     about 28.6 GB
Your reported first change: 112 - 83             about 29 GB

That match is striking. It is an unusually good candidate explanation for the first increase, not proof that these exact files were downloaded. If they are the weights you got, the storage increase may be entirely ordinary. Lightning can mean fewer denoising steps, but it does not imply that a complete accelerated checkpoint will be a small file. A separate Lightning LoRA can be much smaller; the same everyday word can refer to a different type of asset.

The two stages have different roles. Do not assume that the HIGH and LOW files are duplicate versions of the same thing or that one is disposable. Both may be needed for the intended workflow. The linked HF pages are size/filename references, not a recommendation to download another copy.

Windows may display GiB or rounded values. The match still needs compatible filenames and the same measurement scope.

Usually it is additional stored files, not the same checkpoint inflating with each generation.

B2. The extra 11 GB is an open branch

Several possibilities are worth retaining without declaring any one of them the answer:

If what grew was… A plausible source What would distinguish it
Model/checkpoint folder Another checkpoint or alternate quantization; separate supporting weights Large newly dated .safetensors or similar files
WanGP app folder Downloaded weights, Python environment, previews, outputs Which immediate subfolder is now largest
Hugging Face data area Hub cache and/or version-dependent transfer cache Actual cache path and contents
Pinokio Home Another app, shared runtime, cache, or linked storage Compare api, bin, cache, drive and specific apps
Windows drive usage Some of the above, or other Windows-managed files Drive usage differs from one application’s folder size

WanGP’s model guide explicitly documents on-demand model and optional asset downloads. Thus, storage can increase later, when a different workflow or option is first used. That is normal behavior unless a specific failure or unexpected duplicate is identified.

A separate app installation also matters. You corrected the original description: you were using FramePack through Pinokio, then installed WanGP through Pinokio. Depending on the launchers, each app may have its own models and Python environment. The Pinokio Frame-Pack launcher and FramePack demo source provide a concrete example: the standard demo sets its Hugging Face download home under that app’s hf_download folder. Another Pinokio script may store WanGP files separately. Installing two apps does not imply they share all their downloaded files.

All three figures also need to use the same measurement scope; app-folder size and whole-drive usage are not interchangeable.

B3. What does “the model is 123 GB” actually mean?

One large model file          : a particular checkpoint's weight size
WanGP folder in Pinokio      : software + weights + environment + outputs
The whole Pinokio Home       : possibly several independent apps + shared data
All used space on a drive    : Pinokio plus Windows and everything else

These descriptions can all be called “the model’s size” in casual conversation, but they tell us different things. If it is one file, its exact filename matters. If it is an app folder, its largest immediate subfolders are more useful. If it is the whole Pinokio directory, first separate WanGP from FramePack. If it is the C: drive, it is much too early to conclude that WanGP itself expanded by 11 GB.

The Pinokio Home documentation describes the Files button and the main areas: api for installed application scripts, bin for shared runtimes, cache for cached material, drive for virtual linked storage, and logs. Those are places to inspect, not a list of folders to erase. Exact names and storage arrangements vary with the launcher and version.

First, reopen the Windows Properties view that showed 123 GB: what folder or drive is it? If it is a folder, inspect just its largest immediate subfolder.

B4. Cache: sometimes additional storage, sometimes the actual model storage

Hugging Face’s cache guide describes a Hub cache with file blobs and snapshot references. On systems where symbolic links work, more than one visible path may point to the same actual bytes. On Windows, lack of usable symlinks can sometimes produce less efficient copies. Therefore:

  • A path that looks duplicated is not proof of doubled disk consumption. It may be a link to an existing file.
  • Two files with the same name are not proof of shared storage. They could be two real copies.
  • A cache is not necessarily optional junk. Some programs load downloaded model files directly from the cache.
  • An application folder and a cache can both consume space, depending on how downloads were performed. There is no universal “model plus another full cached model” rule.

Pinokio virtual drives and Windows junctions can make a file visible through multiple paths. Summing folder sizes may then overstate physical disk use.

Hugging Face’s Xet transfer system is another layer. Older posts discuss downloaded-chunk caches of roughly 10 GB, but current defaults and behavior are version-dependent. The current Xet guide says the local downloaded-chunk cache is disabled by default in recent hf_xet versions. So I would not explain the extra 11 GB by assuming an old 10 GB cache exists on your installation. If that particular directory turns out to be large, it becomes worth checking the installed version and its settings then, rather than beforehand.

B5. Real reports that help, but do not diagnose your PC

A WanGP temporary-files issue (#458) reported over 25 GB of previews/videos after weeks of usage. This shows one possible growth mechanism, not a likely diagnosis of a fresh installation.

A Pinokio / FramePack symlink warning (#1020) is worth considering if Windows actually reports an HF cache or symlink warning; without that warning it is just a neighboring example. A different Pinokio virtual-drive deletion report (#1121) is a safety reminder: what looks like a duplicate directory can contain files that a working app still needs.

If Pinokio lives on D: but C: is filling, investigate that as a different measurement from WanGP-folder growth.

B6. An inspection-only route

  1. Identify the exact place where 83, 112 and 123 GB were read. Use the same definition for all three.
  2. If it is a folder, look at its largest immediate subfolders in File Explorer. Do not change anything yet.
  3. If large .safetensors files are visible, compare their names to the published HIGH/LOW pair. There is no reason to download them again.
  4. If it is all of Pinokio Home, distinguish the WanGP and FramePack applications from shared areas before adding folder sizes.
  5. If it is whole-drive usage, do not assume every changed byte belongs to Pinokio. Narrow down the directory only if the basic figures are still puzzling.
  6. If you later share a screenshot, folder names and sizes are enough; hide the personal parts of Windows paths.

The Pinokio manual also describes Disk Saver. A scan is read-only, while actual deduplication, making copies separate again, Reset, and deletion are different operations. I would leave all modifications for later. Do not clear Hugging Face caches or delete a HIGH/LOW weight, the env folder, or Pinokio’s drive simply to test whether the number falls. That could force large re-downloads or disrupt a working installation.

If these are needed weights or other assets, there may be nothing broken. First establish which files use the space.

C. A careful path from 50 minutes toward something faster

C1. First make sure the times describe comparable work

You reported 5 hours 20 minutes for the early five-second clip and about 50 minutes after Lightning. That is a major improvement. But we still do not know which application, model, steps, frame rate, and actual processing resolution were used for each result. FramePack and WanGP are different implementations, so the same words “five-second I2V” do not guarantee the same workload.

You also mentioned 1536 x 720 for the first video. That could be input-image dimensions, requested output dimensions, or internal processing dimensions. The standard FramePack demo maps images to supported resolution buckets. Consequently, an original 1536 x 720 image is not automatically proof that every frame was processed internally at 1536 x 720. Other FramePack modes and WanGP settings may differ. This matters before trying to explain hours of generation from pixel count alone.

For a later comparison, keep the image, prompt, duration, frames, resolution, model and seed as consistent as possible.

C2. Find the slow part before selecting the “fastest” setting

Observed waiting time can include:
  first-use downloads / preparation
  model loading and prompt encoding
  denoising / actual generation
  HIGH-to-LOW model transition
  VAE decoding and video export
Where the time goes More relevant possibility First useful observation
Before anything begins Download, initial setup, model loading, first-time compilation Is a progress/status message already visible?
Every generation step is slow Per-step compute, model size, resolution, memory movement Does the step counter progress steadily but slowly?
Big pause at HIGH-to-LOW transition Different large weights being loaded or swapped Is the pause always at the same stage?
Generation is done, but the video file appears much later VAE decoding, encoding, save step Are frames done while export is still working?
First run differs greatly from later runs Warm-up, compilation or downloads Were identical settings actually used?

A faster sampling profile cannot fix an unrelated download, export delay, or frozen menu.

C3. A 16 GB GPU: RAM/VRAM is worth observing, not guessing about

Your RTX 5060 Ti has 16 GB of dedicated VRAM, which can be useful for local generation, but some large video models and their working tensors will not fit there simultaneously. WanGP and related tools may move data between VRAM, system RAM and storage. If data is being moved repeatedly, generation can slow down considerably. However, high VRAM utilization alone is not evidence of failure, and trying to fill VRAM to 100% can make matters worse.

If you happen to look at Windows Task Manager during an existing run, the GPU’s dedicated memory, shared memory, and system memory usage can be informative. A big rise in shared GPU memory alongside slow processing might point toward memory pressure. It does not, by itself, prove the program’s exact offload policy. No additional test run is needed just for this.

The installed attention backend and weight precision also matter. FP8 files can reduce memory requirements, but a smaller file is not a guarantee of faster inference. SDPA, SageAttention, quantization, and model compilation have compatibility and setup tradeoffs. See WanGP’s configuration and performance documentation. I would not change several advanced switches, install alternate kernels, or edit Python scripts blindly in a currently functioning Pinokio environment.

C4. Keep the quality goal visible

A four-step accelerator can reduce the number of denoising operations, but it does not remove loading, encoding, memory transfers or the cost of each step. Nor does it guarantee that a five-second video will finish in four seconds or become faster by a fixed percentage. If the goal is saving another ~20 minutes, it is better to ask which stage consumes those minutes than to copy a “fastest settings” screenshot for a different model and computer.

Once the menu and storage situation are clearer, the most useful follow-up is simply: Which app produced the ~50-minute result, and was the long wait during frame generation or elsewhere? If your app displays step progress and logs the job settings automatically, those existing values are more informative than a fresh test. Later, if a setting is clearly relevant, change one supported option and compare runtime and quality; keep a copy of the working settings so you can return to them.

I would treat 30 minutes as a goal to investigate, not an expectation that your hardware must meet. The fact that your first video looked good is important: a speedup that destroys the result you value would not be a success.

D. Quick Q&A / decision guide for later readers

Q: An accelerated model offers no additional accelerator. Is it broken? Not necessarily. Compatibility is model-dependent, and already-accelerated variants may have no extra acceleration preset. This is different from a model dropdown that does not open.

Q: A model selection makes WanGP download many gigabytes. Is that expected? Sometimes. WanGP can fetch model weights and additional workflow assets when first needed. A download is not by itself proof of a faulty selector, although an error or endless retry would need investigation.

Q: Can “Lightning” occupy ~29 GB? Yes, if it refers to the published Enhanced Lightning v2 FP8 I2V HIGH/LOW checkpoint pair. That pair is about 28.6 GB. A Lightning LoRA and an already-accelerated full checkpoint are not necessarily the same size or installation step.

Q: App folder and cache show the same model name. Is that double storage? Not necessarily: a link, shared blob, cache-backed file, or real duplicate are different arrangements.

Q: Can I delete the largest cache or drive folder? Not as a first test. Inspection and a Disk Saver scan are different from deletion.

Q: Which issue should I read? Match the symptom, not just the word Pinokio. For an unclickable page in a browser but a working Pinokio tab, see WanGP #2386. For a freeze after model selection, see #1866. For previews and outputs accumulating over weeks, see #458. These are examples of different failure modes, not diagnoses of the original report.

Q: I have all three problems. What order should I use?

Menu:      opens with few choices / does not open / selects then fails?
Storage:   one model file / WanGP folder / Pinokio Home / whole drive?
Speed:     which app made the clip, and at which stage does it wait?

Answer the first distinction in each line before trying fixes.

For more background, see the WanGP model guide, accelerator guide, Pinokio manual, Hugging Face cache documentation, and the FramePack project. They cover different layers of the setup, and a community Pinokio install may not match the current upstream UI exactly.

For this thread, the first 29 GB has a strong, checkable candidate explanation; the extra 11 GB and menu behavior remain open. The two short observations near the top can narrow them down without advanced diagnostics. Then we can pursue speed without losing the video quality you liked.

5

12 minutos video de 8 segundos rtx3060 12 gb