CLIPLoaderMultiGPU to cuda:1 give completly different results compared to cuda:0 (Wan)

[seeker-ktf]

I'm running a Wan 2.2 I2V workflow, using a new installation of ComfyUI v 0.8.2 (pytorch version: 2.9.1+cu130, Python 3.13.9), with Sage Attenuation on and installed ComfyUI-MultiGPU 2.5.11 or 2.5.10.

When loading the clip model to cuda:1, I can see it working and the VRAM getting used as usual. I can see two different things happening. On the first run after a restart, I get all black but no error messages. Running a second time after the failure with the same seed, I get a video but there is essentially no controlled movement. Basically, the video I get is almost the same as supplying a blank prompt. There are no error messages.

When loading the clip model to cuda:0 (still using the MultiGPU Node) after a restart I get a video as expected, and the character moves as prompted.

Edit: This is happening on MultiGPU 2.5.11 or 2.5.10 using ComfyUI v0.8.2 but it is fine on ComfyUI v0.3.76.
Edit2: The same effect is seen without Sage Attenuation.
Edit3: Sorry for all the additions, but I traced this back and the failure began in ComfyUI v0.4.0 portable (Dec 9, 2025).

TLDR: Something in ComfyUI v0.4.0 caused CLIPLoaderMultiGPU to cuda:1 to give completely different results compared to cuda:0 on an otherwise stock Wan 2.2 I2V workflow.

[jakechai]

Same here, looks like the generation never follows the prompts, especially for t2v.

[seeker-ktf]

Note that the workaround is to just use CLIPLoaderDisTorch2MultiGPU with "#cuda:1;1.0;cpu" (or just specifying 1 GB for the offload).
I did some testing, and it took me longer than it should to figure out “the issue” that’s happening. Once I looked at the diagnostics in the log it took seconds to figure it out. Thank you for those.

My second GPU is a 3060 with 12GB. I assumed that the 11GB text encoder would fit, but I use that card as my primary display card too, so some of the memory was allocated elsewhere. The log display shows what’s going on:

--------------------------------------------------
DisTorch2 Model Final Device/Layer Assignments
--------------------------------------------------
Device             Layers   Memory (MB)   % Total
--------------------------------------------------
cuda:1 (<0.01%)        73          0.48      0.0%
cuda:1                150       9843.00     90.8%
cpu                    19        992.00      9.2%
--------------------------------------------------

It turns out that allowing Comfy/Windows/Nvidia to handle that 0.48 overflow completely kills the motion and gives the same result as CLIPLoaderMultiGPU starting at comfy v.0.4.0. That 1 extra GB changes everything by a massive amount.

Based on everything, this problem is not a multiGPU issue, but something screwy in the way the memory handling in comfy is being done. This probably needs to be closed.