External Publication
Visit Post

Wan2.2 i2v (clarifications needed regarding settings on low vram system)

Hugging Face Forums [Unofficial] May 10, 2026
Source

To put it simply, there’s a suspicion that settings intended for a different model have gotten mixed in?:

Wan2.2 I2V-A14B High/Low UNets: blur, crosshatching, yellow flash — likely causes and clean baseline

Looking at the workflow screenshot, the problem is probably not mainly the prompt. It looks more like a sampling schedule / High-Low boundary / step count / VAE / distilled-vs-normal workflow mismatch problem.

The suspicious settings in the screenshot are:

HighNoise GGUF -> ModelSamplingSD3 shift 5.00 -> WanMoeKSampler model_high_noise
LowNoise GGUF  -> ModelSamplingSD3 shift 5.00 -> WanMoeKSampler model_low_noise

WanMoeKSampler:
  boundary: 0.750
  add_noise: enable
  steps: 6
  cfg_high_noise: 1.5
  cfg_low_noise: 2.0
  sampler_name: euler
  scheduler: simple
  sigma_shift: 4.00
  return_with_leftover_noise: disable

The short version:

The screenshot looks like a hybrid between a normal Wan2.2 High/Low UNet workflow and a 4-step Lightning/LightX2V-style workflow. That hybrid zone can easily cause heavy blur, side blur, crosshatching texture, and yellow lighting flashes.

1. Biggest issue: boundary = 0.750

For Wan2.2 I2V, boundary = 0.750 is the first thing I would change.

The WanMoeKSampler README says the Wan2.2 boundary is around:

Wan2.2 T2V: 0.875
Wan2.2 I2V: 0.900

It also explains that this boundary is a diffusion timestep , not a denoising step. The actual switch step depends on total steps, sampler, scheduler, and sigma shift.

So for Wan2.2 I2V , reset this:

boundary: 0.750

to this:

boundary: 0.900

Why this matters

Wan2.2 A14B uses separate denoising experts:

Expert Main job
High-noise expert early structure, broad layout, motion, pose, composition
Low-noise expert later detail, face, eyes, mouth, skin, color, texture, final sharpness

The Wan2.2 I2V-A14B model card describes this High-noise / Low-noise MoE design and the idea that the experts specialize in different denoising stages.

If the boundary is too low, the High-noise model can stay active too long and the Low-noise model may not get enough useful refinement time.

That can look like:

first frames look okay
then the clip turns blurry
center improves but sides remain mushy
fine texture looks scratchy/crosshatched
lighting becomes unstable
faces fail to refine

So the first clean correction is:

boundary: 0.900

2. Second issue: steps = 6 is too low for judging normal High/Low UNets

Six steps is very low for the normal Wan2.2 I2V-A14B High/Low model pair.

It can be useful as a quick smoke test, but it is not a fair quality test unless you are using a proper distilled / Lightning / LightX2V setup.

For the normal High/Low UNets, I would test:

steps: 12

If that is too slow on 8GB VRAM, use this only as a compromise:

steps: 8

But I would not judge the normal High/Low pair from 6 steps. At 6 steps, the Low-noise expert may simply not have enough time to resolve detail.

Symptoms of too few steps:

crosshatching texture
unfinished skin/detail
soft edges
side blur
poor face detail
color flicker
lighting pulses

3. Third issue: you may be applying shift twice

The screenshot shows:

ModelSamplingSD3 shift: 5.00

before both models, plus:

WanMoeKSampler sigma_shift: 4.00

inside the WanMoeKSampler.

While debugging, that is too ambiguous. Use one source of shift only.

Recommended cleanup

For the first stable baseline, remove the two ModelSamplingSD3 nodes:

HighNoise GGUF -> WanMoeKSampler model_high_noise
LowNoise GGUF  -> WanMoeKSampler model_low_noise

Then set this inside WanMoeKSampler:

sigma_shift: 5.0

This gives you one clear place controlling the shift.

Why 5.0? The LightX2V Wan2.2 I2V model card recommends Euler with:

shift: 5.0
guidance_scale: 1.0

for its distilled branch. More importantly, 5.0 is also a sane first test value when cleaning up the graph.

The key point is:

Do not run ModelSamplingSD3 shift 5 plus WanMoeKSampler sigma_shift 4 while trying to diagnose artifacts.

After you get a stable baseline, you can test whether the external ModelSamplingSD3 nodes help. But they should not be part of the first diagnosis pass.

4. Fourth issue: CFG values are in the wrong middle zone

The screenshot uses:

cfg_high_noise: 1.5
cfg_low_noise: 2.0

That is neither a strict Lightning/LightX2V recipe nor a normal High/Low baseline.

You need to decide which branch you are testing.

Branch A — normal Wan2.2 I2V-A14B High/Low UNets

Use this branch if you are loading the normal HighNoise and LowNoise GGUFs without Lightning/LightX2V LoRAs.

In this branch, CFG 1.0 is usually too weak. CFG 1.0 is mostly a Rapid/Lightning/distilled habit, not a universal Wan2.2 setting.

Recommended baseline:

High model:
  Wan2.2 I2V-A14B HighNoise GGUF

Low model:
  Wan2.2 I2V-A14B LowNoise GGUF

Remove:
  ModelSamplingSD3 nodes before WanMoeKSampler

WanMoeKSampler:
  boundary: 0.900
  add_noise: enable
  steps: 12
  cfg_high_noise: 3.0
  cfg_low_noise: 3.0
  sampler_name: euler
  scheduler: simple
  sigma_shift: 5.0
  start_at_step: 0
  end_at_step: 10000
  return_with_leftover_noise: disable

VAE:
  wan_2.1_vae.safetensors

Test size:
  33 frames
  512-640px long side
  fixed seed

Disable during baseline:
  LoRAs
  upscalers
  interpolation
  face restore
  post-sharpening
  color correction

If 12 steps is too slow:

boundary: 0.900
steps: 8
cfg_high_noise: 3.0
cfg_low_noise: 3.0
sampler_name: euler
scheduler: simple
sigma_shift: 5.0

But treat 8 steps as a sanity test, not a final quality test.

Branch B — Lightning / LightX2V / distilled 4-step branch

Use this branch only if you are using matching Lightning/LightX2V I2V LoRAs or a proper distilled LightX2V setup.

The LightX2V Wan2.2 I2V card recommends:

Euler scheduler
shift: 5.0
guidance_scale: 1.0

It describes this as running without CFG. The README also says the distilled model is built for substantially fewer inference steps, specifically 4-step-style use.

Strict distilled baseline:

High model:
  compatible Wan2.2 I2V-A14B HighNoise model

Low model:
  compatible Wan2.2 I2V-A14B LowNoise model

LoRAs:
  matching I2V Lightning/LightX2V High LoRA
  matching I2V Lightning/LightX2V Low LoRA
  strength: 1.0 each

Remove:
  external ModelSamplingSD3 nodes during baseline

WanMoeKSampler:
  boundary: 0.900
  add_noise: enable
  steps: 4
  cfg_high_noise: 1.0
  cfg_low_noise: 1.0
  sampler_name: euler
  scheduler: simple
  sigma_shift: 5.0
  start_at_step: 0
  end_at_step: 10000
  return_with_leftover_noise: disable

VAE:
  wan_2.1_vae.safetensors

Test size:
  33 frames
  512-640px long side
  fixed seed

Do not mix this with the normal branch.

Bad hybrid zone:

normal High/Low GGUFs
+ no matching distilled LoRAs
+ 6 steps
+ CFG around 1-2
+ boundary 0.750
+ external shift 5
+ internal sigma_shift 4

That is exactly the kind of setup that can produce blur, crosshatching, and flashing.

5. VAE check: very important

For Wan2.2 14B I2V, check that you are using:

wan_2.1_vae.safetensors

The ComfyUI Wan2.2 docs and ComfyUI Wan2.2 examples point to wan_2.1_vae.safetensors for the 14B workflows.

A wrong or mismatched VAE can look like:

soft decode
general haze
yellow/red color cast
skin tone shift
center glow
lighting flash
poor reconstruction
blurred details

Do not try to fix a VAE mismatch with prompts like “no yellow light.” Fix the VAE first.

6. Artifact-by-artifact diagnosis

A. “First 3 frames normal, then 90% blur”

Most likely causes:

boundary too low
too few total steps
Low-noise expert starts too late
shift schedule conflict
wrong VAE
normal UNets being run like a distilled 4-step model

Fix order:

1. boundary: 0.900
2. remove external ModelSamplingSD3 nodes
3. sigma_shift: 5.0 inside WanMoeKSampler
4. VAE: wan_2.1_vae.safetensors
5. normal branch: steps 12, CFG 3.0 / 3.0
6. distilled branch: steps 4, CFG 1.0 / 1.0, matching LoRAs only

B. “Center improved but sides are still blurry”

Likely causes:

not enough Low-noise refinement
bad High/Low boundary
low step count
resolution/aspect stress
VAE softness
quantization/offload instability
post-processing or resize issue

Try:

33 frames only
512-640px long side
boundary 0.900
steps 12 if normal branch
correct VAE
no post nodes
no upscaler
no interpolation
no face restore

Also use clean dimensions. Examples:

512x288
576x320
640x360
640x384
384x640 for portrait

Avoid large or odd dimensions while debugging.

C. “Crosshatching texture, not square pixelation”

That usually means incomplete or unstable denoising, not classic video compression.

Most likely causes:

6 steps is too low
boundary is wrong
GGUF quantization is stressed
shift schedule is confused
Low-noise refinement is underpowered
VAE decode is wrong or mismatched

The QuantStack Wan2.2 I2V-A14B GGUF page lists approximate quant sizes such as:

Q2_K:    5.3 GB
Q3_K_S:  6.52 GB
Q3_K_M:  7.18 GB
Q4_K_S:  8.75 GB
Q4_K_M:  9.65 GB
Q5_K_S: 10.1 GB
Q5_K_M: 10.8 GB
Q6_K:   12 GB
Q8_0:   15.4 GB

On an 8GB laptop GPU, Q4_K_M can be theoretically better but practically worse if it causes too much offloading, swapping, or instability.

Low-VRAM quant tests:

Test A:
  High: Q3_K_M
  Low:  Q3_K_M

Test B:
  High: Q3_K_M
  Low:  Q4_K_S

Test C:
  High: Q4_K_S
  Low:  Q4_K_S

For face/detail fidelity, the most interesting test is:

High: Q3_K_M
Low:  Q4_K_S

Reason: the Low-noise model is the detail finisher.

D. “Strong yellow light flashing in the middle”

This is probably not a prompt issue.

Likely causes:

wrong VAE
double shift / schedule conflict
LightX2V LoRA trajectory mismatch
normal High/Low UNets using distilled settings
too few steps
bad High/Low boundary
quantization + low-step instability

Fix order:

1. confirm VAE = wan_2.1_vae.safetensors
2. remove external ModelSamplingSD3 nodes
3. boundary = 0.900
4. sigma_shift = 5.0
5. normal branch: 12 steps, CFG 3.0 / 3.0
6. distilled branch: 4 steps, CFG 1.0 / 1.0, matching LoRAs only
7. disable upscaler/interpolation/face restore
8. test 33 frames at 512-640px long side

A negative prompt can include yellow flash, but if the denoising path or VAE is wrong, the prompt will not reliably fix it.

7. What to check in the console

Check where WanMoeKSampler actually switches from High-noise to Low-noise.

Look for something equivalent to:

switching model at step X

Do not reason from boundary alone. The WanMoeKSampler README explains that diffusion timestep is not the same thing as denoising step.

For a 4-step distilled branch, you generally want something close to:

High: 2 steps
Low:  2 steps

For a normal 12-step branch, you want enough Low-noise steps left to refine detail. If Low-noise only gets a tiny part of the run, blur and poor texture are expected.

8. Text encoder check

If prompt obedience is weak, do not only raise CFG. Text encoder quantization can matter.

The city96 UMT5 XXL encoder GGUF page says Q5_K_M or larger is recommended for best results, while smaller models can still be acceptable in constrained setups.

Approximate sizes listed there include:

Q3_K_M: about 3.06 GB
Q4_K_M: about 3.66 GB
Q5_K_M: about 4.15 GB
Q8_0:   about 6.04 GB
F16:    about 11.4 GB

For an 8GB GPU setup:

UMT5 Q3_K_M:
  safest memory option

UMT5 Q4_K_M:
  good low-VRAM baseline

UMT5 Q5_K_M:
  better prompt understanding if system RAM/offload behavior allows it

Weak prompt obedience may be text-encoder-related, not just CFG-related.

9. Suggested prompt while debugging

Use a boring source-faithful prompt. Do not use cinematic lighting while debugging a yellow lighting artifact.

Positive

A realistic image-to-video animation of the person in the source image. Preserve the exact same face, identity, hairstyle, clothing, colors, lighting, and background. The person makes only very subtle natural movement: slight breathing, a small blink, and minimal head movement. Static camera. No zoom. No scene change. Natural colors. Sharp facial details.

Negative

different person, face change, identity change, distorted face, warped eyes, asymmetrical eyes, deformed mouth, changing hairstyle, changing clothes, changing background, camera movement, zoom, scene change, fantasy, sci-fi, anime, painting, overexposed, oversaturated, red tint, yellow flash, blurry, low detail, melted face, extra teeth, crosshatching, noisy texture

At CFG 1.0, the negative prompt may have little practical effect. It should matter more in the normal branch at CFG around 3.0.

10. Minimal troubleshooting plan

Run these in order. Change only one branch at a time.

Test 1 — normal High/Low sanity test

Remove:
  both ModelSamplingSD3 nodes

WanMoeKSampler:
  boundary: 0.900
  add_noise: enable
  steps: 12
  cfg_high_noise: 3.0
  cfg_low_noise: 3.0
  sampler_name: euler
  scheduler: simple
  sigma_shift: 5.0
  start_at_step: 0
  end_at_step: 10000
  return_with_leftover_noise: disable

VAE:
  wan_2.1_vae.safetensors

Video:
  33 frames
  512-640px long side
  fixed seed

Disable:
  LoRAs
  upscaler
  interpolation
  face restore
  postprocessing

If this improves blur/crosshatching/yellow flash, the previous issue was probably:

boundary too low
too few steps
CFG too low for normal branch
shift conflict
VAE mismatch

Test 2 — cheaper normal-branch sanity test

If 12 steps is too slow:

Same as Test 1, but:

steps: 8

If 8 looks bad but 12 improves, the issue is mainly under-refinement.

Test 3 — strict Lightning/LightX2V branch

Only use this if you are using matching I2V Lightning/LightX2V LoRAs or a proper distilled LightX2V setup.

Use:
  matching I2V Lightning/LightX2V LoRAs
  LoRA strength: 1.0 each

Remove:
  both ModelSamplingSD3 nodes

WanMoeKSampler:
  boundary: 0.900
  add_noise: enable
  steps: 4
  cfg_high_noise: 1.0
  cfg_low_noise: 1.0
  sampler_name: euler
  scheduler: simple
  sigma_shift: 5.0
  start_at_step: 0
  end_at_step: 10000
  return_with_leftover_noise: disable

VAE:
  wan_2.1_vae.safetensors

Video:
  33 frames
  512-640px long side

If this still has yellow flashing, suspect:

wrong LoRA pair
T2V LoRA used in I2V
High/Low LoRAs mismatched
wrong VAE
wrong model pair
double shift
workflow node mismatch

11. Recommended settings table

Scenario Boundary Steps CFG high CFG low Sampler Scheduler Shift Notes
Normal High/Low sanity baseline 0.900 12 3.0 3.0 Euler Simple 5.0 Best next test
Normal low-cost test 0.900 8 3.0 3.0 Euler Simple 5.0 Debug only
Strict Lightning/LightX2V 0.900 4 1.0 1.0 Euler Simple 5.0 Only with matching distilled LoRAs/model
Current screenshot 0.750 6 1.5 2.0 Euler Simple 4.0 + external 5.0 Likely unstable hybrid

12. Things I would avoid right now

Avoid this while debugging:

boundary 0.750
steps 6
CFG 1-ish on normal High/Low UNets
external ModelSamplingSD3 shift + WanMoe sigma_shift
720p
49+ frames before baseline works
upscale
interpolation
face restore
multiple LoRAs
cinematic lighting prompts
large camera movement

Especially avoid judging the workflow from this combination:

8GB VRAM
normal High/Low GGUFs
boundary 0.750
steps 6
CFG 1.5 / 2.0
external shift 5
internal sigma_shift 4
large frame count
large resolution

That setup has too many unstable variables.

13. Short answer

Your screenshot has three likely problems:

1. boundary should probably be 0.900, not 0.750, for Wan2.2 I2V
2. six steps is too low for judging the normal High/Low UNets
3. shift is likely being applied ambiguously through both ModelSamplingSD3 and WanMoeKSampler

My recommended reset for the normal High/Low branch:

Remove:
  ModelSamplingSD3 nodes

WanMoeKSampler:
  boundary: 0.900
  steps: 12
  cfg_high_noise: 3.0
  cfg_low_noise: 3.0
  sampler: euler
  scheduler: simple
  sigma_shift: 5.0
  add_noise: enable
  return_with_leftover_noise: disable

VAE:
  wan_2.1_vae.safetensors

Test:
  33 frames
  512-640px long side
  no LoRAs
  no upscale
  no interpolation
  no face restore

If you are actually using Lightning/LightX2V LoRAs, use the strict distilled branch instead:

boundary: 0.900
steps: 4
cfg_high_noise: 1.0
cfg_low_noise: 1.0
sampler: euler
scheduler: simple
sigma_shift: 5.0
LoRA strength: 1.0
VAE: wan_2.1_vae.safetensors

The blur, crosshatching, and yellow flash are most likely from:

wrong boundary
+ too few steps
+ ambiguous/double shift
+ possibly wrong VAE
+ possibly mixing normal and distilled recipes

14. Useful references

  • WanMoeKSampler README — boundary guidance and explanation that diffusion timestep is not denoising step.
  • Wan2.2 I2V-A14B model card — official High-noise / Low-noise MoE model information.
  • Wan2.2 official GitHub — official Wan2.2 repository and model family overview.
  • ComfyUI official Wan2.2 workflow guide — official ComfyUI Wan2.2 workflow notes.
  • ComfyUI Wan2.2 examples — model/VAE file guidance for Wan2.2 workflows.
  • ComfyUI-GGUF — GGUF loading support for ComfyUI.
  • QuantStack Wan2.2 I2V-A14B GGUF — GGUF quant size reference.
  • city96 UMT5 XXL encoder GGUF — text encoder quantization reference.
  • LightX2V Wan2.2 I2V A14B MoE Distill — distilled 4-step-style branch guidance.
  • Wan2.2-Lightning GitHub — Lightning-style low-step Wan2.2 acceleration.

Discussion in the ATmosphere

Loading comments...