System Environment
- OS: Arch Linux (updated 2026-01-14)
- Kernel: Linux 6.12.65 (LTS, core/linux-lts)
- dGPU: Radeon RX 9060 XT (16GB VRAM, gfx1200, Navi 44)
- RAM: DDR4-2666 48GB (8 + 8 + 16 + 16)
- CPU: Ryzen 5 2600X
- Python: 3.11 (aur/python311)
- PyTorch: 2.11.0.dev20260112+rocm7.1
- torchvision: 0.25.0.dev20260113+rocm7.1
- torchaudio: 2.11.0.dev20260113+rocm7.1
Configuration Tested
- Model: LTX-2 / Dev 19B / Distilled
- Resolution: 480p / 832×624 (4:3) / 49 frames (2.0s)
- Attention mode: auto / sdpa
- Data type: BF16 (auto)
- Text Encoder Precision: 8-bit (less RAM, slightly lower quality)
- Profile: Profile 4 (Low RAM / Low VRAM - 32GB RAM, 12GB VRAM)
- How I ran it:
python wgp.py --verbose 2
- Log: log.txt- This log was re-collected in a separate run from the earlier attempt where I waited for ~5000 seconds. However, the overall behavior is unchanged and consistent with the previously described issue.
How to reproduce
- Simply run Generate with the hardware/software and settings above.
Problem Description
As described in the title, the process appears to stall for an extremely long time at
Encoding Prompt - 0.0%.
In my case, I waited for approximately 3000 seconds (50 minutes), but there was no sign of progress, so I manually stopped the process.
It is unclear whether the pipeline would eventually proceed if left running indefinitely.
Wan2GP Logs and Process State
The following logs indicate that the text encoder model layers are being loaded and unloaded repeatedly:
Unloading model text_encoder/model.language_model.layers.38 (Gemma3ForConditionalGeneration) from GPU
Loading model text_encoder/model.language_model.layers.39 (Gemma3ForConditionalGeneration) in GPU
Prefetching model text_encoder/model.language_model.layers.40 (Gemma3ForConditionalGeneration) in GPU
Unloading model text_encoder/model.language_model.layers.39 (Gemma3ForConditionalGeneration) from GPU
Loading model text_encoder/model.language_model.layers.40 (Gemma3ForConditionalGeneration) in GPU
Prefetching model text_encoder/model.language_model.layers.41 (Gemma3ForConditionalGeneration) in GPU
Unloading model text_encoder/model.language_model.layers.40 (Gemma3ForConditionalGeneration) from GPU
Loading model text_encoder/model.language_model.layers.41 (Gemma3ForConditionalGeneration) in GPU
Prefetching model text_encoder/model.language_model.layers.42 (Gemma3ForConditionalGeneration) in GPU
Unloading model text_encoder/model.language_model.layers.41 (Gemma3ForConditionalGeneration) from GPU
Loading model text_encoder/model.language_model.layers.42 (Gemma3ForConditionalGeneration) in GPU
Prefetching model text_encoder/model.language_model.layers.43 (Gemma3ForConditionalGeneration) in GPU
From the logs alone, the process does not appear to be fully hung.
However, CPU and GPU utilization remain very low, and VRAM usage stays mostly idle except for about 4GB reserved by the Wan2GP process.
amdgpu_top v0.11.0
0000:0b:00.0 (AMD Radeon RX 9060 XT), VRAM 6109/16304 MiB, GTT 230/24043 MiB
python ( 57524), ctxs 1, VRAM 3996 MiB ( 24%), GTT 2 MiB ( 0%)
Requested: VRAM 3996 MiB, GTT 2 MiB
According to iotop, the kernel worker kworker/9:2+events_freezable continuously performs disk read operations, and it does so for the entire 3000 seconds (50 minutes):
32851 be/4 root 537.38 M/s 0.00 B/s ⣇⣼⣀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ kworker/9:2+events_freezable
I understand that the Low RAM / Low VRAM profile intentionally causes frequent model swapping.
However, continuous disk reads for over 3000 seconds limited to the text encoder stage seems clearly abnormal, especially when compared to the documented requirements and to successful runs on NVIDIA/CUDA systems.
The Python process uses approximately 40GB of system RAM:
hogehog+ 57524 77.1 82.7 71359168 40762912 pts/2 Sl+ 00:46 34:46 python wgp.py --verbose 2
While I am aware that 48GB of RAM is not generous for video generation models, it still exceeds the Low RAM profile requirement (32GB), and no kernel OOM kills or crashes were observed.
I also found at least one similar report on Reddit (stuck for ~10 minutes, though this appears to be on Windows):
https://www.reddit.com/r/comfyui/comments/1lg55cz/comment/nkr6au5/
Finally, as a side note, I would like to sincerely thank the Wan2GP project and its developers.
You have given “GPU Poor” users the chance to experience video generation models, and that is genuinely appreciated. :)
System Environment
Configuration Tested
python wgp.py --verbose 2How to reproduce
Problem Description
As described in the title, the process appears to stall for an extremely long time at
Encoding Prompt - 0.0%.In my case, I waited for approximately 3000 seconds (50 minutes), but there was no sign of progress, so I manually stopped the process.
It is unclear whether the pipeline would eventually proceed if left running indefinitely.
Wan2GP Logs and Process State
The following logs indicate that the text encoder model layers are being loaded and unloaded repeatedly:
From the logs alone, the process does not appear to be fully hung.
However, CPU and GPU utilization remain very low, and VRAM usage stays mostly idle except for about 4GB reserved by the Wan2GP process.
According to
iotop, the kernel workerkworker/9:2+events_freezablecontinuously performs disk read operations, and it does so for the entire 3000 seconds (50 minutes):I understand that the Low RAM / Low VRAM profile intentionally causes frequent model swapping.
However, continuous disk reads for over 3000 seconds limited to the text encoder stage seems clearly abnormal, especially when compared to the documented requirements and to successful runs on NVIDIA/CUDA systems.
The Python process uses approximately 40GB of system RAM:
While I am aware that 48GB of RAM is not generous for video generation models, it still exceeds the Low RAM profile requirement (32GB), and no kernel OOM kills or crashes were observed.
I also found at least one similar report on Reddit (stuck for ~10 minutes, though this appears to be on Windows):
https://www.reddit.com/r/comfyui/comments/1lg55cz/comment/nkr6au5/
Finally, as a side note, I would like to sincerely thank the Wan2GP project and its developers.
You have given “GPU Poor” users the chance to experience video generation models, and that is genuinely appreciated. :)