PyTorch 2.9: "Depth" and "VAE Decode" trigger 128GB+ RAM spike. #937

New issue

Closed

opened 2026-10-27 21:24:08 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-27 21:24:08 +00:00

Owner

Originally created by @mamorett on GitHub (Dec 4, 2025).
Original GitHub issue: https://github.com/Comfy-Org/ComfyUI-Manager/issues/2348

Environment:

Hardware: NVIDIA DGX System.
GPU: NVIDIA GB10 (Blackwell Architecture / SM_120).
System RAM: 128GB+.
Drivers: CUDA 13.0.
PyTorch: 2.9.1+cu129 (also tested with +cu130).
OS: DGX OS (Ubuntu based).
ComfyUI Version: Latest (Frontend 1.33.10).

Description of the Bug:

On a certified NVIDIA DGX system running CUDA 13.0 (Blackwell), specific workflows cause an immediate and catastrophic consumption of System RAM (not VRAM), filling 128GB+ in seconds and forcing a system freeze or OS kernel panic (kill -9 required).

The issue appears to be a conflict between cudaMallocAsync (default on GB10), ComfyUI's Pinned Memory allocation, and CPU-bound thread spawning on high-core-count CPUs (DGX).

What Works / What Fails:

Operation	Status	Notes
Qwen Image (Transformer)	✅ WORKS	Runs correctly, seemingly bypassing the faulty allocator path.
VAE Decode (Z-Image)	❌ CRASHES	Immediate System RAM saturation (128GB+). Workaround: `--cpu-vae` works (but is extremely slow).
Depth / Preprocessors	❌ CRASHES	Any node using OpenCV/CPU (e.g., `DepthAnything`) triggers immediate OOM. No workaround found.

Observed Behavior & Logs:

When launching ComfyUI, the logs indicate:

Device: cuda:0 NVIDIA GB10 : cudaMallocAsync
Enabled pinned memory: 116381.0 MB`

ComfyUI pins ~90% of available RAM (116GB). When a CPU-bound node (like Depth) initializes, it seemingly spawns multiple threads (due to the high core count of the DGX CPU). Since system RAM is exhausted by the pinning, the system swaps immediately and freezes.

Attempts to disable cudaMallocAsync via PYTORCH_CUDA_ALLOC_CONF=backend:native result in an Internal Assert Failure in PyTorch 2.9, indicating the allocator backend is hardcoded for this architecture: RuntimeError: Allocator backend parsed at runtime != allocator backend parsed at load time

Troubleshooting Attempts (All Failed):
We have extensively tried to isolate the issue with the following methods, none of which resolved the crash:

Memory Management: --disable-smart-memory, --lowvram, --normalvram, MALLOC_ARENA_MAX=2, MALLOC_TRIM_THRESHOLD_=0.

Thread Limiting: OMP_NUM_THREADS=1, OPENCV_NUM_THREADS=1, MKL_NUM_THREADS=1 (To prevent fork-bombing on high-core CPU).

Kernel/OS Limits: ulimit -v, systemd-run --scope -p MemoryMax=....

Compilation/JIT: MAX_JOBS=1, TORCH_COMPILE_DISABLE=1.

Allocators: Attempted LD_PRELOAD with jemalloc.

CUDNN: TORCH_CUDNN_DISABLED=1, TORCH_CUDNN_BENCHMARK=0.

Steps to Reproduce:
Use an NVIDIA DGX with GB10 GPUs and CUDA 13.0 environment.

Install PyTorch 2.9 Nightly (cu129 or cu130).

Run a standard workflow with a DepthAnything node OR a heavy VAE Decode (Z-Image).

Observe System RAM spiking from ~10GB to 128GB+ instantly.

System Hang / Kernel OOM Killer invocation.

Workaround Found:
For VAE Decode: Running with --cpu-vae prevents the crash, confirming the issue lies in the GPU<->RAM data transfer or CUDNN driver interaction on Blackwell.

For Depth: No known workaround.

Originally created by @mamorett on GitHub (Dec 4, 2025). Original GitHub issue: https://github.com/Comfy-Org/ComfyUI-Manager/issues/2348 ### Environment: * **Hardware:** NVIDIA DGX System. * **GPU:** NVIDIA GB10 (Blackwell Architecture / SM_120). * **System RAM:** 128GB+. * **Drivers:** CUDA 13.0. * **PyTorch:** `2.9.1+cu129` (also tested with `+cu130`). * **OS:** DGX OS (Ubuntu based). * **ComfyUI Version:** Latest (Frontend 1.33.10). ### Description of the Bug: On a certified NVIDIA DGX system running CUDA 13.0 (Blackwell), specific workflows cause an immediate and catastrophic consumption of System RAM (not VRAM), filling 128GB+ in seconds and forcing a system freeze or OS kernel panic (`kill -9` required). The issue appears to be a conflict between **`cudaMallocAsync`** (default on GB10), **ComfyUI's Pinned Memory allocation**, and **CPU-bound thread spawning** on high-core-count CPUs (DGX). ### What Works / What Fails: | Operation | Status | Notes | | :--- | :--- | :--- | | **Qwen Image (Transformer)** | ✅ **WORKS** | Runs correctly, seemingly bypassing the faulty allocator path. | | **VAE Decode (Z-Image)** | ❌ **CRASHES** | Immediate System RAM saturation (128GB+). **Workaround:** `--cpu-vae` works (but is extremely slow). | | **Depth / Preprocessors** | ❌ **CRASHES** | Any node using OpenCV/CPU (e.g., `DepthAnything`) triggers immediate OOM. **No workaround found.** | ### Observed Behavior & Logs: When launching ComfyUI, the logs indicate: ```text Device: cuda:0 NVIDIA GB10 : cudaMallocAsync Enabled pinned memory: 116381.0 MB` ``` ComfyUI pins ~90% of available RAM (116GB). When a CPU-bound node (like Depth) initializes, it seemingly spawns multiple threads (due to the high core count of the DGX CPU). Since system RAM is exhausted by the pinning, the system swaps immediately and freezes. Attempts to disable cudaMallocAsync via PYTORCH_CUDA_ALLOC_CONF=backend:native result in an Internal Assert Failure in PyTorch 2.9, indicating the allocator backend is hardcoded for this architecture: RuntimeError: Allocator backend parsed at runtime != allocator backend parsed at load time Troubleshooting Attempts (All Failed): We have extensively tried to isolate the issue with the following methods, none of which resolved the crash: Memory Management: --disable-smart-memory, --lowvram, --normalvram, MALLOC_ARENA_MAX=2, MALLOC_TRIM_THRESHOLD_=0. Thread Limiting: OMP_NUM_THREADS=1, OPENCV_NUM_THREADS=1, MKL_NUM_THREADS=1 (To prevent fork-bombing on high-core CPU). Kernel/OS Limits: ulimit -v, systemd-run --scope -p MemoryMax=.... Compilation/JIT: MAX_JOBS=1, TORCH_COMPILE_DISABLE=1. Allocators: Attempted LD_PRELOAD with jemalloc. CUDNN: TORCH_CUDNN_DISABLED=1, TORCH_CUDNN_BENCHMARK=0. Steps to Reproduce: Use an NVIDIA DGX with GB10 GPUs and CUDA 13.0 environment. Install PyTorch 2.9 Nightly (cu129 or cu130). Run a standard workflow with a DepthAnything node OR a heavy VAE Decode (Z-Image). Observe System RAM spiking from ~10GB to 128GB+ instantly. System Hang / Kernel OOM Killer invocation. Workaround Found: For VAE Decode: Running with --cpu-vae prevents the crash, confirming the issue lies in the GPU<->RAM data transfer or CUDNN driver interaction on Blackwell. For Depth: No known workaround.

bsakaguchi closed this issue

2026-10-27 21:24:08 +00:00