[Bug]: `--enable-sleep-mode` OOMs loading an NVFP4 (modelopt) 30B on 16GB SM120 cards where the identical model loads fine without it — cumem MemPool overhead, not resolved by raising max_split_size_mb

[JasonVranek]

Your current environment

The output of vllm collect-env

Collecting environment information...
uv is set
==============================
        System Info
==============================
OS                           : Ubuntu 24.04.4 LTS (x86_64)
GCC version                  : (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0
Clang version                : Could not collect
CMake version                : version 3.28.3
Libc version                 : glibc-2.39

==============================
       PyTorch Info
==============================
PyTorch version              : 2.11.0+cu130
Is debug build               : False
CUDA used to build PyTorch   : 13.0
ROCM used to build PyTorch   : N/A
XPU used to build PyTorch    : N/A

==============================
      Python Environment
==============================
Python version               : 3.12.3 (main, Jun 19 2026, 12:46:00) [GCC 13.3.0] (64-bit runtime)
Python platform              : Linux-6.17.0-35-generic-x86_64-with-glibc2.39
    
==============================
       CUDA / GPU Info
==============================
Is CUDA available            : True
CUDA runtime version         : 12.8.93
CUDA_MODULE_LOADING set to   : 
GPU models and configuration : 
GPU 0: NVIDIA GeForce RTX 5070 Ti
GPU 1: NVIDIA GeForce RTX 5070 Ti

Nvidia driver version        : 595.71.05
cuDNN version                : Could not collect
HIP runtime version          : N/A
MIOpen runtime version       : N/A
Is XNNPACK available         : True

==============================
          CPU Info
==============================
Architecture:                            x86_64
CPU op-mode(s):                          32-bit, 64-bit
Address sizes:                           48 bits physical, 48 bits virtual
Byte Order:                              Little Endian
CPU(s):                                  32
On-line CPU(s) list:                     0-31
Vendor ID:                               AuthenticAMD
Model name:                              AMD Ryzen 9 9950X 16-Core Processor
CPU family:                              26
Model:                                   68
Thread(s) per core:                      2
Core(s) per socket:                      16
Socket(s):                               1
Stepping:                                0
Frequency boost:                         enabled
CPU(s) scaling MHz:                      51%
CPU max MHz:                             5756.4521
CPU min MHz:                             624.1940
BogoMIPS:                                8583.31
Flags:                                   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpuid_fault cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk avx_vnni avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid bus_lock_detect movdiri movdir64b overflow_recov succor smca fsrm avx512_vp2intersect flush_l1d amd_lbr_pmc_freeze
Virtualization:                          AMD-V
L1d cache:                               768 KiB (16 instances)
L1i cache:                               512 KiB (16 instances)
L2 cache:                                16 MiB (16 instances)
L3 cache:                                64 MiB (2 instances)
NUMA node(s):                            1
NUMA node0 CPU(s):                       0-31
Vulnerability Gather data sampling:      Not affected
Vulnerability Ghostwrite:                Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit:             Not affected
Vulnerability L1tf:                      Not affected
Vulnerability Mds:                       Not affected
Vulnerability Meltdown:                  Not affected
Vulnerability Mmio stale data:           Not affected
Vulnerability Old microcode:             Not affected
Vulnerability Reg file data sampling:    Not affected
Vulnerability Retbleed:                  Not affected
Vulnerability Spec rstack overflow:      Mitigation; IBPB on VMEXIT only
Vulnerability Spec store bypass:         Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:                Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:                Mitigation; Enhanced / Automatic IBRS; IBPB conditional; STIBP always-on; PBRSB-eIBRS Not affected; BHI Not affected
Vulnerability Srbds:                     Not affected
Vulnerability Tsa:                       Not affected
Vulnerability Tsx async abort:           Not affected
Vulnerability Vmscape:                   Mitigation; IBPB on VMEXIT

==============================
Versions of relevant libraries
==============================
[pip3] No relevant packages
[conda] Could not collect

==============================
         vLLM Info
==============================
ROCM Version                 : Could not collect
vLLM Version                 : 0.25.0
vLLM Build Flags:
  CUDA Archs: Not Set; ROCm: Disabled; XPU: Disabled
GPU Topology:
  	�[4mGPU0	GPU1	CPU Affinity	NUMA Affinity	GPU NUMA ID�[0m
GPU0	 X 	PHB	0-31	0		N/A
GPU1	PHB	 X 	0-31	0		N/A

Legend:

  X    = Self
  SYS  = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI)
  NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node
  PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
  PXB  = Connection traversing multiple PCIe bridges (without traversing the PCIe Host Bridge)
  PIX  = Connection traversing at most a single PCIe bridge
  NV#  = Connection traversing a bonded set of # NVLinks

==============================
     Environment Variables
==============================
LD_LIBRARY_PATH=/home/j/.local/share/uv/tools/vllm/lib/python3.12/site-packages/cv2/../../lib64:/usr/local/cuda-12.8/lib64:/usr/local/cuda-12.8/lib64:
PYTORCH_NVML_BASED_CUDA_CHECK=1
TORCHINDUCTOR_COMPILE_THREADS=1
TORCHINDUCTOR_CACHE_DIR=/tmp/torchinductor_j
VLLM_WORKER_MULTIPROC_METHOD=spawn

Additional: FlashInfer 0.6.13; running with the /wake_up patch from PR #41602 applied locally (unrelated to this OOM, which is at load). vLLM installed via uv tool.

🐛 Describe the bug

Enabling --enable-sleep-mode (CuMemAllocator) makes weight loading OOM at load
time on 16GB cards, for a model + config that loads and serves fine WITHOUT
sleep mode.

Working (no sleep mode) — loads, serves, benched at 271 tok/s aggregate with a
~698K-token KV pool:

vllm serve /path/to/nemotron3-nano-30b-nvfp4 \
  --tensor-parallel-size 2 --max-model-len 32768 --max-num-seqs 64 \
  --gpu-memory-utilization 0.85 --port 8080

Failing — identical config plus --enable-sleep-mode (+ VLLM_SERVER_DEV_MODE=1):

• --gpu-memory-utilization 0.85 → torch.OutOfMemoryError during weight loading
• --gpu-memory-utilization 0.75 → same OOM (so it is not the KV/profile budget)
• adding --enforce-eager → same OOM (so it is not CUDA-graph memory; it dies
  before graph capture, during load)

The OOM lands inside the weight-load phase while process_weights_after_loading
runs the modelopt NVFP4 weight post-processing, i.e. allocations are going
through the cumem MemPool (use_memory_pool(tag="weights")).

Relationship to the #43951 / #34877 root-cause class (partial — see negative bisect below)

#43951 established (with bisection + cherry-pick proof) a two-layer mechanism:

1. [UX][Bugfix] Fix OOM by setting PyTorch max_split_size_mb during model loading #41268 scopes max_split_size_mb=20 during model load
   (vllm/v1/worker/gpu_worker.py::_scoped_allocator_max_split, still present
   in 0.25.0). Any transient buffer > 20 MiB gets a fresh segment each time —
   the high-water mark becomes Σ(all transients) instead of max(one transient).
2. Inside a cumem MemPool, PyTorch does not reclaim freed segments under
   pressure (OOM when using use_mem_pool due to restriction on retry pytorch/pytorch#159674, still open; empty_cache() is a no-op
   for a live pool; expandable_segments is incompatible with MemPool). So the
   stranded segments accumulate until OOM, before the context-exit sweep in
   vllm/device_allocator/cumem.py can run.

Without sleep mode the same transients run in the default caching allocator,
where splitting/reuse and reclaim work — which is exactly our observed
asymmetry (loads fine without sleep mode).

#45589 (merged 2026-06-17, present in our 0.25.0) does NOT cover this path.
It fixed only the FlashInfer TRTLLM BF16 MoE block-layout conversion by
preallocating outputs. The modelopt NVFP4 path
(vllm/model_executor/layers/quantization/modelopt.py,
process_weights_after_loading for linear + RoutedExperts) has its own
per-layer/per-expert transient pattern (scale swizzles, block-layout
interleaves, contiguous copies) that was not changed. On a 16GB card the
headroom is tiny, so far smaller stranded totals than #43951's 70 GiB are
enough to OOM.

What this report adds over #43951 / #34877

• A third independent quant path (modelopt NVFP4) hitting the same class —
  evidence that per-path transient fixes ([Bugfix] Fix MoE model load OOM in FlashInfer_TRTLLM backend with sleep mode #45589) leave other loaders exposed
  and the general fix proposed in [Bug]: MoE + --enable-sleep-mode OOM during weight load — bisected to #41268, root cause in cumem MemPool reclaim (pytorch#159674) #43951 (mid-load snapshot-sweep in
  cumem.py) is still needed.
• Consumer 16GB SM120 hardware — the smallest-headroom case; sleep mode is
  most attractive exactly here (hot-swap on small VRAM) and currently unusable
  for NVFP4 30B-class MoE models.
• Clean A/B on the same host, same checkpoint, same flags, sleep mode as the
  only variable; --enforce-eager and lower gpu_memory_utilization ruled out
  as mitigations.

Expected behavior

--enable-sleep-mode should not change the peak memory required to load a
model that fits comfortably without it.

Confirmation experiment — RAN 2026-07-14, result NEGATIVE (reframes the bug)

We locally patched _scoped_allocator_max_split(max_split_size_mb=20) → 64
in vllm/v1/worker/gpu_worker.py (the #43951/#45589 remedy) and re-ran the
identical --enable-sleep-mode load. It still OOMs — the max_split bump
does NOT resolve our path. The failure signature at OOM:

CUDA Error: out of memory at csrc/cumem_allocator.cpp:163
Failed to load model - not enough GPU memory ...
CUDA out of memory. Tried to allocate 168.00 MiB.
GPU 0 has a total capacity of 15.47 GiB of which 16.38 MiB is free.
... this process has 15.43 GiB memory in use. Of the allocated memory
14.67 GiB is allocated by PyTorch, with 4.85 GiB allocated in private pools
(e.g. CUDA Graphs) ...

Interpretation: with --enable-sleep-mode the load fills the 15.47 GiB card to
~16 MiB free, with ~4.85 GiB sitting in the cumem private MemPool on top of
the default-allocator weights — the same model without sleep mode fits with
headroom. So on this NVFP4 modelopt path the dominant cost is absolute cumem
MemPool overhead during weight post-processing, not the max_split_size=20
fragmentation class (#43951). The per-path out= fix (#45589) and the general
mid-load reclaim sweep proposed in #43951 both remain relevant; the one-line
max_split bump is insufficient here. This is a HONEST negative — filed as such,
it preempts "just raise max_split_size_mb" and points reviewers at the pool
overhead / reclaim path.

(Not re-tested at higher max_split values: 64 already exceeds #45589's proven
25/32 thresholds, and the residual is absolute pool bytes, not split
granularity, so higher values are not expected to help.)

Possible fixes (happy to PR)

• Path-specific (mirror of [Bugfix] Fix MoE model load OOM in FlashInfer_TRTLLM backend with sleep mode #45589): preallocate final tensors and write
  per-layer/per-expert results via out= in the modelopt NVFP4
  process_weights_after_loading conversions
  (vllm/model_executor/layers/quantization/modelopt.py), eliminating the
  clone/stack transients.
• General (the [Bug]: MoE + --enable-sleep-mode OOM during weight load — bisected to #41268, root cause in cumem MemPool reclaim (pytorch#159674) #43951 proposal, unimplemented): lift the context-exit
  snapshot-sweep in vllm/device_allocator/cumem.py to also run mid-load when
  mapped bytes approach a high-water mark, bounding reserved memory for every
  loader without per-quant-path fixes.

Related

• [Bug]: MoE + --enable-sleep-mode OOM during weight load — bisected to #41268, root cause in cumem MemPool reclaim (pytorch#159674) #43951 (closed via [Bugfix] Fix MoE model load OOM in FlashInfer_TRTLLM backend with sleep mode #45589) — same mechanism, FlashInfer TRTLLM BF16 MoE
• [Bug]: OOM during mxfp4 weight swizzle when --enable-sleep-mode is enabled on single GPU #34877 (closed NOT_PLANNED/stale) — same mechanism, mxfp4 swizzle
• [UX][Bugfix] Fix OOM by setting PyTorch max_split_size_mb during model loading #41268 — the max_split_size_mb=20 load-scope
• OOM when using use_mem_pool due to restriction on retry pytorch/pytorch#159674 (open) — MemPool no reclaim-on-pressure

Before submitting a new issue...

• Searched existing issues and the docs chatbot. This is filed as related-but-distinct to [Bug]: MoE + --enable-sleep-mode OOM during weight load — bisected to #41268, root cause in cumem MemPool reclaim (pytorch#159674) #43951 (closed via [Bugfix] Fix MoE model load OOM in FlashInfer_TRTLLM backend with sleep mode #45589), [Bug]: OOM during mxfp4 weight swizzle when --enable-sleep-mode is enabled on single GPU #34877, [UX][Bugfix] Fix OOM by setting PyTorch max_split_size_mb during model loading #41268, and OOM when using use_mem_pool due to restriction on retry pytorch/pytorch#159674 — the negative bisect below (max_split_size_mb 20→64 does not resolve our NVFP4 modelopt path) is why it is not a duplicate of those.