You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[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 #48680
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:
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:
[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).
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.
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.
Your current environment
The output of
vllm collect-envAdditional: FlashInfer 0.6.13; running with the
/wake_uppatch from PR #41602 applied locally (unrelated to this OOM, which is at load). vLLM installed viauv tool.🐛 Describe the bug
Enabling
--enable-sleep-mode(CuMemAllocator) makes weight loading OOM at loadtime 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:
Failing — identical config plus
--enable-sleep-mode(+VLLM_SERVER_DEV_MODE=1):--gpu-memory-utilization 0.85→torch.OutOfMemoryErrorduring weight loading--gpu-memory-utilization 0.75→ same OOM (so it is not the KV/profile budget)--enforce-eager→ same OOM (so it is not CUDA-graph memory; it diesbefore graph capture, during load)
The OOM lands inside the weight-load phase while
process_weights_after_loadingruns 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:
max_split_size_mbduring model loading #41268 scopesmax_split_size_mb=20during model load(
vllm/v1/worker/gpu_worker.py::_scoped_allocator_max_split, still presentin 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).
MemPool, PyTorch does not reclaim freed segments underpressure (OOM when using use_mem_pool due to restriction on retry pytorch/pytorch#159674, still open;
empty_cache()is a no-opfor a live pool;
expandable_segmentsis incompatible with MemPool). So thestranded segments accumulate until OOM, before the context-exit sweep in
vllm/device_allocator/cumem.pycan 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_loadingfor linear + RoutedExperts) has its ownper-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
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.most attractive exactly here (hot-swap on small VRAM) and currently unusable
for NVFP4 30B-class MoE models.
only variable;
--enforce-eagerand lowergpu_memory_utilizationruled outas mitigations.
Expected behavior
--enable-sleep-modeshould not change the peak memory required to load amodel 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)→64in
vllm/v1/worker/gpu_worker.py(the #43951/#45589 remedy) and re-ran theidentical
--enable-sleep-modeload. It still OOMs — the max_split bumpdoes NOT resolve our path. The failure signature at OOM:
Interpretation: with
--enable-sleep-modethe 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 generalmid-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)
per-layer/per-expert results via
out=in the modelopt NVFP4process_weights_after_loadingconversions(
vllm/model_executor/layers/quantization/modelopt.py), eliminating theclone/stack transients.
snapshot-sweep in
vllm/device_allocator/cumem.pyto also run mid-load whenmapped bytes approach a high-water mark, bounding reserved memory for every
loader without per-quant-path fixes.
Related
max_split_size_mbduring model loading #41268 — themax_split_size_mb=20load-scopeBefore submitting a new issue...
max_split_size_mbduring 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.