GGUF + --fast pinned_memory = CUDA crash

[kaptainkory]

Custom Node Testing

• I have tried disabling custom nodes and the issue persists (see how to disable custom nodes if you need help)

Expected Behavior

GGUF Qwen models (e.g., Q4_K_M) should run with the --fast argument and not crash.

Actual Behavior

Even smaller GGUF Qwen models (e.g., Q4_K_M) that have run previously now produce the following error when run with the --fast argument or --fast pinned_memory argument:

KSampler

CUDA error: invalid argument
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1
Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

I'm aware the --fast argument "enables some untested and potentially quality deteriorating optimizations". The culprit appears to be the pinned_memory optimization.

Steps to Reproduce

Launch ComfyUI with --fast or --fast pinned_memory argument. Run a simple workflow that includes a GGUF Unet loader node. Notice the (likely) CUDA crash.

Debug Logs

--

Other

No response

[zwukong]

--fast not compatible with gguf ,i opened an issue before

[jprsyt5]

it was working fine, I’ve been using the --fast args and city96 gguf node the whole time, but after the recent comfy updates, it broke. I didn’t change any dependencies or update anything except ComfyUI itself.

[rattus128]

I think I have fixed this. Please try:

city96/ComfyUI-GGUF#355

[zwukong]

@rattus128
No oom, but vae decode node crash ,no logs ,just crash. --use-sage-attention --fast pinned_memory

[fangcun010]

@rattus128 No oom, but vae decode node crash ,no logs ,just crash. --use-sage-attention --fast pinned_memory

The same problem.
But I use pytorch2.10 nightly + cuda13.02 + py312 + xformer + sageattention 2.2.

[mcmonkey4eva]

Pinned memory is now enabled by default in comfy per #10656 - several users in the Swarm discord have reported the same bug as above (the process just suddenly disappears while swapping models at the end of a run, both from diffusion model to VAE, and from diffusion model to TE for wan2.2 high/low pair), which is fixed by the --disable-pinned-memory arg mentioned in that PR.
Swarm automatically updates GGUF at the same time it updates comfy, and 3x reports in the past few hours today, so definitely still happening with your PR included @rattus128 -- it is, as fangcun010 showed above, the process just suddenly closing itself without any clear error now. (Usually this implies a system RAM fault).
Every report I've seen has been on Wan GGUF models, has included an RTX 3060 12GiB and an RTX 4070 Ti Super 16GiB
One of the reports was Torch 2.7.1, which is up to date enough I think (others didn't have full debug logs)
Multiple of them reported lora key not loaded: spam for previously working wan loras, may be related, may be incidental, not sure.
Here's full debug log from one of the affected users https://paste.denizenscript.com/View/137284

[rattus128]

Pinned memory is now enabled by default in comfy per #10656 - several users in the Swarm discord have reported the same bug as above (the process just suddenly disappears while swapping models at the end of a run, both from diffusion model to VAE, and from diffusion model to TE for wan2.2 high/low pair), which is fixed by the --disable-pinned-memory arg mentioned in that PR. Swarm automatically updates GGUF at the same time it updates comfy, and 3x reports in the past few hours today, so definitely still happening with your PR included @rattus128 -- it is, as fangcun010 showed above, the process just suddenly closing itself without any clear error now. (Usually this implies a system RAM fault). Every report I've seen has been on Wan GGUF models, has included an RTX 3060 12GiB and an RTX 4070 Ti Super 16GiB One of the reports was Torch 2.7.1, which is up to date enough I think (others didn't have full debug logs) Multiple of them reported lora key not loaded: spam for previously working wan loras, may be related, may be incidental, not sure. Here's full debug log from one of the affected users https://paste.denizenscript.com/View/137284

I'm unable to reproduce with WAN+Loras on my 3060 so far. Are these low RAM users by any chance? Ill keep testing different variables tomorrow. That log has a big page file which might be interesting. I need to start pulling RAM sticks on my windows setup and maybe that will get me closer to that user.

If you have a concrete workflow that repros the 'lora key not loaded' regression that probably a really good place to start, as hopefully that is more deterministic.

Sudden process death sometimes has some useful stuff in the window "Event Viewer" if you can catch one live.

[jovan2009]

I'm unable to reproduce with WAN+Loras on my 3060 so far. Are these low RAM users by any chance? Ill keep testing different variables tomorrow. That log has a big page file which might be interesting. I need to start pulling RAM sticks on my windows setup and maybe that will get me closer to that user.

If you have a concrete workflow that repros the 'lora key not loaded' regression that probably a really good place to start, as hopefully that is more deterministic.

Sudden process death sometimes has some useful stuff in the window "Event Viewer" if you can catch one live.

Pulling RAM sticks? Maybe it's a figure of speech? If I remember correctly there is a msconfig option to use less RAM than the actual amount? Or it doesn't work as expected in the current situation? I'm not a developer but this msconfig option stuck at some point in my brain.

[mcmonkey4eva]

The case that posted logs was running with no relevant --args, and these hardware specs:

2025-11-05 19:50:28.282 [Init] CPU Cores: 12 | RAM: 47.95 GiB total, 44.01 GiB available, 69.92 GiB total page file, 63.22 GiB available page file
2025-11-05 19:50:28.299 [Init] GPU 0: NVIDIA GeForce RTX 3060 | Temp 50C | Util 0% GPU, 0% Memory | VRAM 12.00 GiB total, 11.33 GiB free, 505.00 MiB used
pytorch version: 2.7.1+cu128
Enabled pinned memory 22095.0
Python version: 3.12.10

Which isn't low per se but is indeed less than sufficient for Wan on VRAM. Sysram is quite a lot, should suffice fine.
per their log the diffusion model load reported loaded partially; 6604.16 MB usable, 6604.16 MB loaded, 2733.03 MB offloaded, lowvram patches: 0

I note the "lora key not loaded" spam in that log is actually after the diffusion and before the te load, for some reason. weird. possibly something changed in lora application pattern such that it's just reporting that the lora doesn't affect the te? (swarm's autogenerated workflow uses generic lora loader and pumps everything through it rather than trying to assume, which usually is fine it'll just skip doing anything to the te)

[jovan2009]

The case that posted logs was running with no relevant --args, and these hardware specs:

2025-11-05 19:50:28.282 [Init] CPU Cores: 12 | RAM: 47.95 GiB total, 44.01 GiB available, 69.92 GiB total page file, 63.22 GiB available page file
2025-11-05 19:50:28.299 [Init] GPU 0: NVIDIA GeForce RTX 3060 | Temp 50C | Util 0% GPU, 0% Memory | VRAM 12.00 GiB total, 11.33 GiB free, 505.00 MiB used

48 GB RAM, meaning some non ideal dual channel combination of 16 x 3 or 32 +16 GB, possibly there's an issue with that worth investigating with some memory checking tools if nothing else can be figured out.

Edit:
Also only 70 GB page file? It's true that I run full unquantized fp16 Wan safetensors + loras and fp32 VAE when I do but on my rtx 5060 ti 16 GB + 64 GB RAM I wouldn't dare to press start processing with less than 80 GB page file.

[Windecay]

@rattus128 No oom, but vae decode node crash ,no logs ,just crash. --use-sage-attention --fast pinned_memory

The same problem. But I use pytorch2.10 nightly + cuda13.02 + py312 + xformer + sageattention 2.2.

add a clean-vram node between ksampler and vae decode==> no crash

[mcmonkey4eva]

There's been 4 more users in the swarm discord that have reported the disable-pinned-memory arg fixes gguf crash -- I've asked them to post replication logs here

I see that a few days ago a relevant commit was made, I'll also ask them to make sure things are updated and retest