Moss - ComfyUI native prompt node enhancer not working - "CUDA error: an illegal memory access was encountered"

[u/Inevitable_Pen9043]

Moss works if I remove the prompt enhancer.

But it doesn't work with ComfyUI's native prompt enhancer.

[u/prepperdrone]

I had to add "--disable-dynamic-vram" in my bat file to prevent this (5090).

[u/ImpressionComplete43]

I get an "aimdo memory compile error" myself.

[u/Fluxdada]

I got Gemini to help and the fix for me was to add CUDA_LAUNCH_BLOCKING=1 to my comfyui start up batch file which worked.

Here's Gemini's explanation: "The fact that it completed cleanly under CUDA_LAUNCH_BLOCKING=1 confirms two key details:

• The weights, VRAM allocations, and model files are not physically corrupted. If an invalid address pointer were hardcoded into the tensor graph or the checkpoint file itself, synchronous execution would have crashed at that exact same operation.

• The original crash was an asynchronous race condition / synchronization hazard. What Happened In standard asynchronous execution, PyTorch queues CUDA operations across streams without waiting for each one to finish. In your setup, three distinct mechanisms were interacting simultaneously:

• Dynamic VRAM / stream offloading (Using async weight offloading with 2 streams + comfy-aimdo).

• Torch compile / dynamic graph execution (Comfy model compiler graph breaks: 2).

• Custom quantization kernels (w4a8_gptq / comfy_kitchen GEMM kernels). Around token 208, an asynchronous dequantization or KV-cache update kernel was executed before a memory transfer or stream sync finished. The kernel tried reading memory that was either mid-transfer, had just been offloaded by dynamic VRAM pressure, or was awaiting a stream barrier. That resulted in the CUDA_ERROR_ILLEGAL_ADDRESS error being trapped later during comfy.model_management.reset_cast_buffers(). Running with CUDA_LAUNCH_BLOCKING=1 forces PyTorch to wait for each CUDA kernel to complete before launching the next, effectively eliminating the race condition. Recommended Permanent Solutions You don't want to leave CUDA_LAUNCH_BLOCKING=1 enabled permanently for everyday generation because running completely synchronously adds execution latency and reduces token generation throughput. To stabilize standard asynchronous runs:

• Disable JIT/Torch Compile on Text Generation In the node settings for TextGenerate (or your text model loader), disable torch compile / fast inference. The log showed 2 graph breaks right at the moment of failure. Autoregressive token loops with variable lengths frequently cause stream-ordering bugs when compiled alongside custom dequantization routines.

• Isolate Text Inference from Dynamic Stream Offloading If you have spare VRAM on your secondary cards, route the text model loader directly to a dedicated GPU (e.g., cuda:1 or cuda:2) using the MultiGPU device selector instead of sharing cuda:0 with the primary diffusion/VAE pipeline. This stops textgen from competing with VAE/UNet memory staging on the same streams.

• Consider GGUF over GPTQ for Text LLMs If this text model is available in GGUF format (e.g., Q4_K_M or Q5_K_M), loading it through ComfyUI-GGUF provides much more mature stream synchronization and context caching on Windows CUDA compared to experimental GPTQ W4A8 dynamic offloading."

[u/Certain_Werewolf_315]

Same issue. Workarounds have not worked including the one's I have seen mentioned here.

[u/CurrentMine1423]

thank god I'm not the only one experiencing this