[Bug] Second LoRA sampling pass hangs at 0% with --normalvram --disable-dynamic-vram after commit 1ac78180

Description

Expected Behavior
A two-pass LoRA workflow (HIGH LoRA → LOW LoRA, sequential sampling) completes both passes successfully, as it did with ComfyUI 115f418b (2026-04-27).

Actual Behavior
The second sampling pass hangs indefinitely at 0%|0/2 with no progress, no error output, and GPU utilization drops to 0% (12W idle power). The process must be manually interrupted. The first pass completes normally every time.

Steps to Reproduce
Hardware: NVIDIA GB10 (DGX Spark) — unified memory architecture, 121 GB shared VRAM/RAM
Start ComfyUI with flags: --normalvram --disable-dynamic-vram --reserve-vram 1 --disable-pinned-memory --use-sage-attention --force-fp16 --bf16-unet --bf16-vae --bf16-text-enc --dont-upcast-attention --disable-mmap
Run a two-pass WanVideo i2v workflow:
Pass 1: load Wan2.2 14B transformer + Wan2.2-Lightning_I2V-A14B-4steps-lora_HIGH_fp16, sample 2 steps (timesteps 1000→941)
Pass 2: reload same transformer + Wan2.2-Lightning_I2V-A14B-4steps-lora_LOW_fp16, sample 2 steps (timesteps 803→60)
Pass 1 completes in ~3 minutes. Pass 2 starts loading the transformer, reaches Sampling start, prints Generated new RoPE frequencies, then hangs at 0%|0/2 indefinitely.
Bisection Result
Commit Result
115f418b (2026-04-27) ✅ Both passes complete normally
04856acc (2026-05-15, includes 1ac78180) ❌ Second pass hangs at 0%
Reverting to 115f418b fixes the issue completely.

Root Cause Analysis
The regression appears to be introduced by commit 1ac78180 ("make control-net load order deterministic", 2026-05-04), which changed load_models_gpu() in
model_management.py
:

# Before (115f418b)
models_temp = set()
for m in models:
models_temp.add(m)
for mm in m.model_patches_models():
models_temp.add(mm)
models = models_temp

# After (1ac78180)
models_temp = {}
for m in models:
models_temp[m] = None
for mm in m.model_patches_models():
models_temp[mm] = None
models = list(models_temp)
models.reverse() # <-- reverses load order
On a unified memory system (GB10/Grace-Blackwell) with --normalvram --disable-dynamic-vram, the reversed load order appears to cause the first pass's model to not be fully unloaded/released before the second pass begins. When the second pass tries to allocate CUDA resources (likely in the SageAttention kernel or cudaMallocAsync), it enters an indefinite wait state with no error thrown.

This does not seem to affect discrete GPU systems, which may explain why it hasn't been widely reported. On unified memory architectures, the memory pool behavior under cudaMallocAsync is different — reserved memory from pass 1 (~10.75 GB) is not returned to the allocator before pass 2 attempts to allocate its attention buffers.

Environment
OS: Ubuntu 24.04 (Linux 6.17.0-1014-nvidia, aarch64)
Hardware: NVIDIA GB10 (DGX Spark), unified memory 121 GB
CUDA: 13.0 / Driver 580.142
PyTorch: 2.12.0+cu130
ComfyUI: 04856acc (broken) / 115f418b (working)
SageAttention: 2.2.0 (compiled for sm_121)
Custom node: ComfyUI-WanVideoWrapper (kijai)
Workaround
Pin ComfyUI to commit 115f418b:

cd /opt/ComfyUI && git checkout 115f418b