[Bug]: OOM killed caused by possible CPU memory leak in vLLM Worker RPC Broadcast Deserialization Path

[jeffye-dev]

Your current environment

The output of python collect_env.py

Collecting environment information...
==============================
        System Info
==============================
OS                           : Ubuntu 24.04.3 LTS (x86_64)
GCC version                  : (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0
Clang version                : Could not collect
CMake version                : Could not collect
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.13 (main, May  4 2026, 09:06:50) [GCC 13.3.0] (64-bit runtime)
Python platform              : Linux-5.15.0-176-generic-x86_64-with-glibc2.39
    
==============================
       CUDA / GPU Info
==============================
Is CUDA available            : True
CUDA runtime version         : 13.0.88
CUDA_MODULE_LOADING set to   : 
GPU models and configuration : 
GPU 0: NVIDIA B300 SXM6 AC
GPU 1: NVIDIA B300 SXM6 AC
GPU 2: NVIDIA B300 SXM6 AC
GPU 3: NVIDIA B300 SXM6 AC
GPU 4: NVIDIA B300 SXM6 AC
GPU 5: NVIDIA B300 SXM6 AC
GPU 6: NVIDIA B300 SXM6 AC
GPU 7: NVIDIA B300 SXM6 AC

Nvidia driver version        : 595.58.03
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:                           52 bits physical, 57 bits virtual
Byte Order:                              Little Endian
CPU(s):                                  256
On-line CPU(s) list:                     0-255
Vendor ID:                               GenuineIntel
BIOS Vendor ID:                          Intel(R) Corporation
Model name:                              Intel(R) Xeon(R) 6768P
BIOS Model name:                         Intel(R) Xeon(R) 6768P  CPU @ 2.4GHz
BIOS CPU family:                         179
CPU family:                              6
Model:                                   173
Thread(s) per core:                      2
Core(s) per socket:                      64
Socket(s):                               2
Stepping:                                1
BogoMIPS:                                4800.00
Flags:                                   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 ds_cpl smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cat_l2 cdp_l3 invpcid_single cdp_l2 ssbd mba ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local split_lock_detect avx_vnni avx512_bf16 wbnoinvd dtherm ida arat pln pts avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq la57 rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm md_clear serialize tsxldtrk pconfig arch_lbr amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities ibpb_exit_to_user
L1d cache:                               6 MiB (128 instances)
L1i cache:                               8 MiB (128 instances)
L2 cache:                                256 MiB (128 instances)
L3 cache:                                672 MiB (2 instances)
NUMA node(s):                            4
NUMA node0 CPU(s):                       0-31,128-159
NUMA node1 CPU(s):                       32-63,160-191
NUMA node2 CPU(s):                       64-95,192-223
NUMA node3 CPU(s):                       96-127,224-255
Vulnerability Gather data sampling:      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 Reg file data sampling:    Not affected
Vulnerability Retbleed:                  Not affected
Vulnerability Spec rstack overflow:      Not affected
Vulnerability Spec store bypass:         Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:                Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:                Mitigation; Enhanced / Automatic IBRS; IBPB conditional; PBRSB-eIBRS Not affected; BHI BHI_DIS_S
Vulnerability Srbds:                     Not affected
Vulnerability Tsa:                       Not affected
Vulnerability Tsx async abort:           Not affected
Vulnerability Vmscape:                   Mitigation; IBPB before exit to userspace

==============================
Versions of relevant libraries
==============================
[pip3] flashinfer-python==0.6.8.post1
[pip3] numpy==2.2.6
[pip3] nvidia-cublas==13.1.0.3
[pip3] nvidia-cuda-cupti==13.0.85
[pip3] nvidia-cuda-nvrtc==13.0.88
[pip3] nvidia-cuda-runtime==13.0.96
[pip3] nvidia-cudnn-cu13==9.19.0.56
[pip3] nvidia-cudnn-frontend==1.18.0
[pip3] nvidia-cufft==12.0.0.61
[pip3] nvidia-cufile==1.15.1.6
[pip3] nvidia-curand==10.4.0.35
[pip3] nvidia-cusolver==12.0.4.66
[pip3] nvidia-cusparse==12.6.3.3
[pip3] nvidia-cusparselt-cu13==0.8.0
[pip3] nvidia-cutlass-dsl==4.4.2
[pip3] nvidia-cutlass-dsl-libs-base==4.4.2
[pip3] nvidia-ml-py==13.595.45
[pip3] nvidia-nccl-cu13==2.28.9
[pip3] nvidia-nvjitlink==13.0.88
[pip3] nvidia-nvshmem-cu13==3.4.5
[pip3] nvidia-nvtx==13.0.85
[pip3] pyzmq==27.1.0
[pip3] torch==2.11.0+cu130
[pip3] torch_c_dlpack_ext==0.1.5
[pip3] torchaudio==2.11.0+cu130
[pip3] torchvision==0.26.0+cu130
[pip3] transformers==5.7.0
[pip3] triton==3.6.0
[conda] Could not collect

==============================
         vLLM Info
==============================
ROCM Version                 : Could not collect
vLLM Version                 : 0.20.1
vLLM Build Flags:
  CUDA Archs: 7.5 8.0 8.6 8.9 9.0 10.0 12.0+PTX; ROCm: Disabled; XPU: Disabled
GPU Topology:
        GPU0    GPU1    GPU2    GPU3    GPU4    GPU5    GPU6    GPU7    NIC0    NIC1    NIC2    NIC3    NIC4    NIC5    NIC6    NIC7    NIC8    CPU Affinity    NUMA Affinity   GPU NUMA ID
GPU0     X      NV18    NV18    NV18    NV18    NV18    NV18    NV18    PXB     NODE    SYS     SYS     SYS     SYS     SYS     SYS     NODE    0-31,128-159    0               N/A
GPU1    NV18     X      NV18    NV18    NV18    NV18    NV18    NV18    NODE    PXB     SYS     SYS     SYS     SYS     SYS     SYS     NODE    0-31,128-159    0               N/A
GPU2    NV18    NV18     X      NV18    NV18    NV18    NV18    NV18    SYS     SYS     PXB     NODE    SYS     SYS     SYS     SYS     SYS     32-63,160-191   1               N/A
GPU3    NV18    NV18    NV18     X      NV18    NV18    NV18    NV18    SYS     SYS     NODE    PXB     SYS     SYS     SYS     SYS     SYS     32-63,160-191   1               N/A
GPU4    NV18    NV18    NV18    NV18     X      NV18    NV18    NV18    SYS     SYS     SYS     SYS     PXB     NODE    SYS     SYS     SYS     64-95,192-223   2               N/A
GPU5    NV18    NV18    NV18    NV18    NV18     X      NV18    NV18    SYS     SYS     SYS     SYS     NODE    PXB     SYS     SYS     SYS     64-95,192-223   2               N/A
GPU6    NV18    NV18    NV18    NV18    NV18    NV18     X      NV18    SYS     SYS     SYS     SYS     SYS     SYS     PXB     NODE    SYS     96-127,224-255  3               N/A
GPU7    NV18    NV18    NV18    NV18    NV18    NV18    NV18     X      SYS     SYS     SYS     SYS     SYS     SYS     NODE    PXB     SYS     96-127,224-255  3               N/A
NIC0    PXB     NODE    SYS     SYS     SYS     SYS     SYS     SYS      X      NODE    SYS     SYS     SYS     SYS     SYS     SYS     NODE
NIC1    NODE    PXB     SYS     SYS     SYS     SYS     SYS     SYS     NODE     X      SYS     SYS     SYS     SYS     SYS     SYS     NODE
NIC2    SYS     SYS     PXB     NODE    SYS     SYS     SYS     SYS     SYS     SYS      X      NODE    SYS     SYS     SYS     SYS     SYS
NIC3    SYS     SYS     NODE    PXB     SYS     SYS     SYS     SYS     SYS     SYS     NODE     X      SYS     SYS     SYS     SYS     SYS
NIC4    SYS     SYS     SYS     SYS     PXB     NODE    SYS     SYS     SYS     SYS     SYS     SYS      X      NODE    SYS     SYS     SYS
NIC5    SYS     SYS     SYS     SYS     NODE    PXB     SYS     SYS     SYS     SYS     SYS     SYS     NODE     X      SYS     SYS     SYS
NIC6    SYS     SYS     SYS     SYS     SYS     SYS     PXB     NODE    SYS     SYS     SYS     SYS     SYS     SYS      X      NODE    SYS
NIC7    SYS     SYS     SYS     SYS     SYS     SYS     NODE    PXB     SYS     SYS     SYS     SYS     SYS     SYS     NODE     X      SYS
NIC8    NODE    NODE    SYS     SYS     SYS     SYS     SYS     SYS     NODE    NODE    SYS     SYS     SYS     SYS     SYS     SYS      X 

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

NIC Legend:

  NIC0: mlx5_0
  NIC1: mlx5_1
  NIC2: mlx5_2
  NIC3: mlx5_3
  NIC4: mlx5_4
  NIC5: mlx5_5
  NIC6: mlx5_6
  NIC7: mlx5_7
  NIC8: mlx5_21

==============================
     Environment Variables
==============================
NVIDIA_VISIBLE_DEVICES=GPU-6165c0ef-6980-e0f1-13c8-ab9c5e24faf0,GPU-6649d5ab-9f5f-3464-75be-6812bc716c3f,GPU-430d8f1b-bc37-1043-1d0b-5e86240f8acc,GPU-1dd74c37-70fe-9e61-3581-740020c020f5,GPU-205139bb-5f54-150e-d756-55c348445f66,GPU-97697070-b3a0-fa49-89f9-b0db5c5f801a,GPU-debef8f9-d864-0245-7a1e-49206f736cf9,GPU-c14646a6-c135-d9a8-3c9c-6a6a59fbced9
NVIDIA_REQUIRE_CUDA=cuda>=13.0 brand=unknown,driver>=535,driver<536 brand=grid,driver>=535,driver<536 brand=tesla,driver>=535,driver<536 brand=nvidia,driver>=535,driver<536 brand=quadro,driver>=535,driver<536 brand=quadrortx,driver>=535,driver<536 brand=nvidiartx,driver>=535,driver<536 brand=vapps,driver>=535,driver<536 brand=vpc,driver>=535,driver<536 brand=vcs,driver>=535,driver<536 brand=vws,driver>=535,driver<536 brand=cloudgaming,driver>=535,driver<536 brand=unknown,driver>=550,driver<551 brand=grid,driver>=550,driver<551 brand=tesla,driver>=550,driver<551 brand=nvidia,driver>=550,driver<551 brand=quadro,driver>=550,driver<551 brand=quadrortx,driver>=550,driver<551 brand=nvidiartx,driver>=550,driver<551 brand=vapps,driver>=550,driver<551 brand=vpc,driver>=550,driver<551 brand=vcs,driver>=550,driver<551 brand=vws,driver>=550,driver<551 brand=cloudgaming,driver>=550,driver<551 brand=unknown,driver>=565,driver<566 brand=grid,driver>=565,driver<566 brand=tesla,driver>=565,driver<566 brand=nvidia,driver>=565,driver<566 brand=quadro,driver>=565,driver<566 brand=quadrortx,driver>=565,driver<566 brand=nvidiartx,driver>=565,driver<566 brand=vapps,driver>=565,driver<566 brand=vpc,driver>=565,driver<566 brand=vcs,driver>=565,driver<566 brand=vws,driver>=565,driver<566 brand=cloudgaming,driver>=565,driver<566 brand=unknown,driver>=570,driver<571 brand=grid,driver>=570,driver<571 brand=tesla,driver>=570,driver<571 brand=nvidia,driver>=570,driver<571 brand=quadro,driver>=570,driver<571 brand=quadrortx,driver>=570,driver<571 brand=nvidiartx,driver>=570,driver<571 brand=vapps,driver>=570,driver<571 brand=vpc,driver>=570,driver<571 brand=vcs,driver>=570,driver<571 brand=vws,driver>=570,driver<571 brand=cloudgaming,driver>=570,driver<571 brand=unknown,driver>=575,driver<576 brand=grid,driver>=575,driver<576 brand=tesla,driver>=575,driver<576 brand=nvidia,driver>=575,driver<576 brand=quadro,driver>=575,driver<576 brand=quadrortx,driver>=575,driver<576 brand=nvidiartx,driver>=575,driver<576 brand=vapps,driver>=575,driver<576 brand=vpc,driver>=575,driver<576 brand=vcs,driver>=575,driver<576 brand=vws,driver>=575,driver<576 brand=cloudgaming,driver>=575,driver<576
CUDA_CACHE_PATH=/var/cache/vllm/cuda
VLLM_SKIP_P2P_CHECK=1
TORCH_CUDA_ARCH_LIST=7.5 8.0 8.6 8.9 9.0 10.0 12.0+PTX
NCCL_SOCKET_IFNAME=bond0
VLLM_CACHE_ROOT=/var/cache/vllm/vllm
NVIDIA_GDRCOPY=enabledpo
VLLM_USE_FLASHINFER_MOE_INT4=1
NVIDIA_DRIVER_CAPABILITIES=compute,utility
NCCL_DEBUG=WARNING
VLLM_USAGE_SOURCE=production-docker-image
VLLM_USE_FLASHINFER_SAMPLER=1
VLLM_NIXL_ABORT_REQUEST_TIMEOUT=600
CUDA_VERSION=13.0.2
VLLM_ENABLE_CUDA_COMPATIBILITY=0
NVIDIA_DISABLE_REQUIRE=true
VLLM_ENGINE_READY_TIMEOUT_S=1200
LD_LIBRARY_PATH=/usr/local/nvidia/lib64:/usr/local/cuda/lib64:/usr/local/nvidia/lib:/usr/local/nvidia/lib64:/usr/local/cuda/lib64
VLLM_LOGGING_LEVEL=INFO
VLLM_KV_CACHE_LAYOUT=HND
PYTORCH_NVML_BASED_CUDA_CHECK=1
TORCHINDUCTOR_COMPILE_THREADS=1
TORCHINDUCTOR_CACHE_DIR=/tmp/torchinductor_root

🐛 Describe the bug

Summary

We observed steady CPU RSS growth in a vLLM worker process during production traffic. A short sampling window using pmap, /proc/<pid>/status, /proc/<pid>/smaps_rollup, and memray --leaks points to retained anonymous private memory allocated while the worker is deserializing RPC broadcast messages.

The most suspicious path is not NIXL, file cache, shared memory, pinned memory, or the model execute_model path itself. The largest retained allocations are under:

worker_busy_loop
  -> rpc_broadcast_mq.dequeue(...)
  -> MessageQueue.recv(...)
  -> pickle.loads(...)

During the sampling window, OS-level memory growth and memray retained allocations are closely aligned:

• Worker RSS / Private_Dirty increased by roughly 93-108 MiB.
• memray --leaks reported roughly 115.5 MiB of still-live allocations.
• Most retained memory came from:
  • _PyMem_ArenaAlloc: about 73 MiB
  • c10::alloc_cpu: about 38.6 MiB

This suggests the leak is likely caused by Python objects and Torch CPU tensor storage created by RPC message deserialization and retained after the sampled window.

OS-level memory evidence

/proc/<pid>/status

status.1.txt -> status.2.txt showed:

VmSize:   +107748 kB  (~105.22 MiB)
VmRSS:    +105856 kB  (~103.38 MiB)
RssAnon:  +105312 kB  (~102.84 MiB)
RssFile:        0 kB
RssShmem:    +544 kB  (~0.53 MiB)
VmData:   +107748 kB  (~105.22 MiB)
VmPin:          0 kB
Threads:        0

Interpretation:

• Growth is almost entirely anonymous private/data memory.
• It is not pinned memory (VmPin unchanged).
• It is not file cache (RssFile unchanged).
• It is not shared memory (RssShmem increased by only ~0.5 MiB).
• It is not caused by new threads or thread stacks.

/proc/<pid>/smaps_rollup

smaps.1.txt -> smaps.2.txt showed:

Rss:            +95508 kB  (~93.27 MiB)
Pss:            +95024 kB  (~92.80 MiB)
Pss_Anon:       +94964 kB  (~92.74 MiB)
Private_Dirty:  +94968 kB  (~92.74 MiB)
Anonymous:      +94964 kB  (~92.74 MiB)
AnonHugePages:       0 kB
SwapPss:             0 kB

Interpretation:

• The increase is Private_Dirty / Anonymous memory.
• It is not hugepage growth and not swap-related.

pmap -x

pmap totals showed:

Size:  +111876 kB  (~109.25 MiB)
RSS:   +110516 kB  (~107.93 MiB)
Dirty: +110520 kB  (~107.93 MiB)

Aggregating mappings by type showed almost all growth came from rw--- [ anon ] private anonymous mappings:

anon:             +109.25 MiB Size, +107.39 MiB RSS, +107.39 MiB Dirty
psm_shm:             0 MiB Size,   +0.53 MiB RSS,   +0.53 MiB Dirty
.so:                 0 MiB
nvidia:              0 MiB
zero_deleted_shm:    0 MiB
stack:               0 MiB

In this window:

new anon VMAs:        +173.95 MiB RSS/Dirty
removed anon VMAs:     -48.94 MiB RSS/Dirty
existing anon change:  -17.62 MiB RSS/Dirty
---------------------------------------------
net anon growth:      +107.39 MiB RSS/Dirty

This matches the pmap total growth and is consistent with newly retained private anonymous allocations.

memray evidence

memray --leaks reported still-live allocations totaling approximately:

121085933 bytes = 115.48 MiB

This is close to the OS-level RSS/Private_Dirty growth observed by pmap and smaps_rollup, so memray likely captured the main retained allocations responsible for the process RSS increase.

_PyMem_ArenaAlloc             ~73.06 MiB   76 allocations
c10::alloc_cpu                ~38.56 MiB   23 allocations
operator new                   ~1.79 MiB   4357 allocations
<unknown>                      ~1.02 MiB   1714 allocations
list_resize                    ~0.49 MiB   2 allocations
cudnnBackendCreateDescriptor   ~0.45 MiB   142 allocations
cudnnHostMalloc                ~0.03 MiB   71 allocations

The two major contributors are _PyMem_ArenaAlloc and c10::alloc_cpu, together accounting for roughly 111.6 MiB, which explains most of the OS-observed net growth.

Suspicious call path

The memray flamegraph shows the main retained branch under the worker RPC loop:

worker_main
  -> worker_busy_loop

Two relevant branches were visible:

worker_busy_loop line 948: rpc_broadcast_mq.dequeue(...)  ~100.07 MiB retained
worker_busy_loop line 957: execute_model(...)              ~15.36 MiB retained

The largest branch is therefore dequeue, not the model execution path.

Expanded path:

worker_busy_loop
  /usr/local/lib/python3.12/site-packages/vllm/v1/executor/multiproc_executor.py:948
  method, args, kwargs, output_rank = self.rpc_broadcast_mq.dequeue(...)

  -> dequeue
     /usr/local/lib/python3.12/site-packages/vllm/distributed/device_communicators/shm_broadcast.py:768
     obj = MessageQueue.recv(self.local_socket, timeout)

  -> recv
     /usr/local/lib/python3.12/site-packages/vllm/distributed/device_communicators/shm_broadcast.py:781
     return pickle.loads(recv, buffers=recv_oob)

This path retained about 100 MiB during the sampled window.

Native Torch CPU allocation path

The largest Torch CPU-storage allocation path is:

worker_busy_loop
  -> rpc_broadcast_mq.dequeue
  -> MessageQueue.recv
  -> pickle.loads
  -> load_reduce
  -> torch.storage._load_from_bytes
  -> torch.serialization.load
  -> _legacy_load
  -> persistent_load
  -> THPStorage_pynew
  -> c10::make_storage_impl
  -> c10::DefaultCPUAllocator::allocate
  -> c10::alloc_cpu

Retained allocation:

c10::alloc_cpu: ~38.56 MiB, 22-23 allocations

This suggests the RPC message being deserialized contains Torch serialized storage/tensor data. The worker allocates CPU tensor storage during pickle.loads, and that storage remains live at the end of the sampling window.

Possible sources include tensors or tensor-like metadata inside RPC arguments, scheduler output, input metadata, block/slot metadata, sampling/logits-related CPU tensors, or other objects transported through the broadcast RPC queue.

Python object allocation path

The largest Python-object allocation source is:

worker_busy_loop
  -> rpc_broadcast_mq.dequeue
  -> MessageQueue.recv
  -> pickle.loads
  -> load_binint / load_binint2 / load_counted_tuple / load_counted_binbytes
  -> PyLong_FromLong / PyTuple_New / PyBytes_FromStringAndSize
  -> PyObject_Malloc
  -> pymalloc_alloc
  -> allocate_from_new_pool
  -> new_arena
  -> _PyMem_ArenaAlloc

Retained allocation:

_PyMem_ArenaAlloc: ~73.06 MiB

This indicates a large number of Python objects created while unpickling the RPC message remained live after the sample.

Current hypothesis

The current leading hypothesis is:

vLLM worker RPC broadcast messages are deserialized via pickle.loads; during this process, Python objects and Torch CPU tensor storages are allocated and some of them remain referenced after the worker finishes handling the RPC message. This causes worker private anonymous RSS to grow over time.

A multimodal cache or multimodal request lifecycle issue is still a possible contributing factor, because the workload involves image requests and RPC messages may carry multimodal scheduler/input objects. However, based on this sample, multimodal caching is only a hypothesis, not the directly proven allocation site. The directly observed retained allocation site is the RPC broadcast deserialization path.

Before submitting a new issue...

• Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

[jshaofa-ui]

 1|# vLLM #43639: OOM Killed from CPU Memory Leak in Worker RPC Broadcast Deserialization
 2|
 3|## Issue Summary
 4|
 5|vLLM Worker RPC Broadcast Deserialization Path has a possible CPU memory leak causing OOM kills. Environment: Ubuntu 24.04, PyTorch 2.11.0+cu130, 8x NVIDIA B300 SXM6 AC GPUs.
 6|
 7|## Root Cause Analysis
 8|
 9|The Worker RPC broadcast deserialization path likely accumulates deserialized objects without proper cleanup. In distributed training/inference, RPC broadcasts send tensor metadata and configuration to all workers. If the deserialization path doesn't properly release intermediate buffers or if there's a reference cycle, memory accumulates over time until OOM.
10|
11|Common causes in this pattern:
12|1. Deserialized tensors not released after use
13|2. Reference cycles in deserialized objects
14|3. Buffer pool not returning memory to OS
15|4. Python GC not running frequently enough for large allocations
16|
17|## Proposed Fix
18|
19|### Fix 1: Explicit Buffer Cleanup After Deserialization
20|
21|```python
22|def broadcast_deserialize(data: bytes) -> Any:
23|    """Deserialize RPC broadcast data with explicit cleanup."""
24|    import gc
25|    import torch
26|    
27|    # Use a context to ensure cleanup
28|    try:
29|        # Deserialize with memory-mapped tensors when possible
30|        obj = pickle.loads(data, buffers=None)
31|        return obj
32|    finally:
33|        # Explicitly clean up the raw bytes buffer
34|        del data
35|        # Force GC if memory pressure is high
36|        if torch.cuda.memory_allocated() > threshold:
37|            gc.collect()
38|```
39|
40|### Fix 2: Memory-Aware Broadcast with Size Limits
41|
42|```python
43|class RPCBroadcastManager:
44|    MAX_BROADCAST_SIZE = 100 * 1024 * 1024  # 100MB limit
45|    
46|    def broadcast(self, data: Any) -> None:
47|        serialized = pickle.dumps(data)
48|        if len(serialized) > self.MAX_BROADCAST_SIZE:
49|            raise ValueError(
50|                f"Broadcast payload too large: {len(serialized)} bytes. "
51|                "Consider splitting into smaller chunks."
52|            )
53|        # Broadcast with explicit cleanup
54|        try:
55|            self._do_broadcast(serialized)
56|        finally:
57|            del serialized
58|```
59|
60|### Fix 3: Periodic Memory Monitoring
61|
62|```python
63|import threading
64|import psutil
65|
66|class MemoryMonitor:
67|    def __init__(self, threshold_gb: float = 0.8):
68|        self.threshold = threshold_gb
69|        self._running = False
70|        
71|    def start(self):
72|        self._running = True
73|        threading.Thread(target=self._monitor_loop, daemon=True).start()
74|    
75|    def _monitor_loop(self):
76|        while self._running:
77|            mem = psutil.virtual_memory()
78|            if mem.percent / 100 > self.threshold:
79|                gc.collect()
80|                if torch.cuda.is_available():
81|                    torch.cuda.empty_cache()
82|            time.sleep(30)
83|```
84|
85|## Impact
86|
87|- **Stability**: CRITICAL — OOM kills crash the entire inference service
88|- **Scope**: Medium — Affects distributed inference setups with frequent RPC broadcasts
89|- **Fix complexity**: MEDIUM — Memory management + monitoring, ~200 lines
90|

[jshaofa-ui]

Solution: Fix CPU Memory Leak in RPC Broadcast Deserialization

Root Cause

The vLLM Worker RPC Broadcast Deserialization Path doesn't properly release memory after deserializing messages. Raw message buffers and deserialized objects accumulate, causing gradual memory growth until OOM kill.

Fix

Two-part fix:

1. Explicit memory release: Use memoryview context manager and explicitly delete raw message buffer after deserialization
2. Periodic GC: Trigger garbage collection for large messages (>1MB) or periodically (every 30s)

def _deserialize_broadcast(message: bytes) -> Any:
    message_size = len(message)
    try:
        with memoryview(message) as buf:
            result = _do_deserialize(buf)
        return result
    finally:
        del message  # Release raw buffer
        if message_size > 1024*1024 or time_since_last_gc() > 30:
            gc.collect()

Why This Works

• memoryview: Zero-copy deserialization avoids extra allocations
• Explicit delete: Raw buffer released immediately
• Periodic GC: Prevents accumulation of small leaks

[hiepnnguyentcu]

Hi @njhill @youkaichao could you take a look at PR when you get a chance?
This fixes the CPU memory leak reported in #43639.
@jeffye-dev would you be able to verify this resolves the issue on your end?