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) 13.3.0
Clang version : Could not collect
CMake version : version 3.28.3
Libc version : glibc-2.39
==============================
PyTorch Info
==============================
PyTorch version : 2.9.0+cu129
Is debug build : False
CUDA used to build PyTorch : 12.9
ROCM used to build PyTorch : N/A
==============================
Python Environment
==============================
Python version : 3.12.3 (main, Nov 6 2025, 13:44:16) [GCC 13.3.0] (64-bit runtime)
Python platform : Linux-6.8.0-86-generic-x86_64-with-glibc2.39
==============================
CUDA / GPU Info
==============================
Is CUDA available : True
CUDA runtime version : 12.0.140
CUDA_MODULE_LOADING set to :
GPU models and configuration :
GPU 0: NVIDIA GeForce RTX 4090
GPU 1: NVIDIA GeForce RTX 4090
GPU 2: NVIDIA GeForce RTX 4090
GPU 3: NVIDIA GeForce RTX 4090
Nvidia driver version : 570.195.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: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 128
On-line CPU(s) list: 0-127
Vendor ID: AuthenticAMD
Model name: AMD Ryzen Threadripper PRO 5995WX 64-Cores
CPU family: 25
Model: 8
Thread(s) per core: 2
Core(s) per socket: 64
Socket(s): 1
Stepping: 2
Frequency boost: enabled
CPU(s) scaling MHz: 70%
CPU max MHz: 2700.0000
CPU min MHz: 1800.0000
BogoMIPS: 5389.92
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 nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic 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 cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin brs arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm debug_swap
Virtualization: AMD-V
L1d cache: 2 MiB (64 instances)
L1i cache: 2 MiB (64 instances)
L2 cache: 32 MiB (64 instances)
L3 cache: 256 MiB (8 instances)
NUMA node(s): 1
NUMA node0 CPU(s): 0-127
Vulnerability Gather data sampling: 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: Mitigation; Safe RET
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; Retpolines; IBPB conditional; IBRS_FW; STIBP always-on; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
==============================
Versions of relevant libraries
==============================
[pip3] flashinfer-python==0.5.2
[pip3] numpy==2.2.0
[pip3] nvidia-cublas-cu12==12.9.1.4
[pip3] nvidia-cuda-cupti-cu12==12.9.79
[pip3] nvidia-cuda-nvrtc-cu12==12.9.86
[pip3] nvidia-cuda-runtime-cu12==12.9.79
[pip3] nvidia-cudnn-cu12==9.10.2.21
[pip3] nvidia-cudnn-frontend==1.16.0
[pip3] nvidia-cufft-cu12==11.4.1.4
[pip3] nvidia-cufile-cu12==1.14.1.1
[pip3] nvidia-curand-cu12==10.3.10.19
[pip3] nvidia-cusolver-cu12==11.7.5.82
[pip3] nvidia-cusparse-cu12==12.5.10.65
[pip3] nvidia-cusparselt-cu12==0.7.1
[pip3] nvidia-cutlass-dsl==4.3.1
[pip3] nvidia-ml-py==13.580.82
[pip3] nvidia-nccl-cu12==2.27.5
[pip3] nvidia-nvjitlink-cu12==12.9.86
[pip3] nvidia-nvshmem-cu12==3.3.20
[pip3] nvidia-nvtx-cu12==12.9.79
[pip3] pyzmq==27.1.0
[pip3] torch==2.9.0+cu129
[pip3] torchaudio==2.9.0+cu129
[pip3] torchvision==0.24.0+cu129
[pip3] transformers==4.57.3
[pip3] triton==3.5.0
[conda] No relevant packages
==============================
vLLM Info
==============================
ROCM Version : Could not collect
vLLM Version : 0.11.2
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled
GPU Topology:
GPU0 GPU1 GPU2 GPU3 CPU Affinity NUMA Affinity GPU NUMA ID
GPU0 X NODE NODE NODE 0-127 0 N/A
GPU1 NODE X NODE NODE 0-127 0 N/A
GPU2 NODE NODE X NODE 0-127 0 N/A
GPU3 NODE NODE NODE X 0-127 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
==============================
PYTORCH_NVML_BASED_CUDA_CHECK=1
TORCHINDUCTOR_COMPILE_THREADS=1
🐛 Describe the bug
Before anyone reads this. I believe this has something to do with lmcache. Should i go to lmcache's issues for this or is lmcache fully supported in vllm and this belongs here?
VLLM version 0.11.2 installed with uv pip install vllm==0.11.2 --torch-backend=auto
So i was stress testing my installation of vllm with the model specified which was served on 4x4090 using this command:
LMCACHE_CONFIG_FILE=lmcache_config.yaml vllm serve cpatonn/GLM-4.5-Air-AWQ-4bit \
--pipeline-parallel-size 2 \
--tensor-parallel-size 2 \
--tokenizer-mode auto \
--max-model-len 128000 \
--enable-log-requests \
--kv-cache-dtype auto \
--enable-expert-parallel \
--tool-call-parser glm45 \
--reasoning-parser glm45 \
--host 0.0.0.0 \
--enable-auto-tool-choice \
--port 8002 \
--dtype float16 \
--max-num-seqs 32 \
--kv-transfer-config '{"kv_connector":"LMCacheConnectorV1","kv_role":"kv_both"}' \
--kv-offloading-backend lmcache \
--kv-offloading-size 32 \
--swap-space 16
the lmcache_config.yaml (found somewhere online too)
chunk_size: 256
local_cpu: true
max_local_cpu_size: 32
enable_async_loading: true
I was running my personal suite to test parallelism up to 32 concurrent requests. input tokens 1024, 2048 and 4096, output stopped at 1024 tokens with concurrency from 1 to 32 using powers of 2. At some point it came down to 4096 input tokens while using 32 concurrency, and that's where things got weird. First i noticed this line:
Reqid: chatcmpl-2842fb0483564e60a5a12b59b172159c, Total tokens 4096, LMCache hit tokens: 0, need to load: -336
Which was weird, didn't come up before while serving full day with --max-num-seqs 4
And then it started breaking down
(EngineCore_DP0 pid=1779222) [2025-12-01 21:32:07,636] LMCache ERROR: The number of tokens is more than the number of blocks.Something might be wrong in scheduling logic! (vllm_v1_adapter.py:381:lmcache.integration.vllm.vllm_v1_adapter)
Which ultimately resulted in
(Worker_PP0_TP0_EP0 pid=1779356) ERROR 12-01 21:32:42 [multiproc_executor.py:815] assert len(slot_mapping) == len(token_ids)
(Worker_PP0_TP0_EP0 pid=1779356) ERROR 12-01 21:32:42 [multiproc_executor.py:815] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(Worker_PP0_TP0_EP0 pid=1779356) ERROR 12-01 21:32:42 [multiproc_executor.py:815] AssertionError
And it got down eventually.
The error log (full output of nohup) is attached below:
error.log
Looking for any help because we can't live long on 4 parallel queries. And i'm suspicious of --kv-transfer-config '{"kv_connector":"LMCacheConnectorV1","kv_role":"kv_both"}' which i found somewhere online and didn't test any variations of it yet.
Should i go to lmcache's issues for this or is lmcache fully supported in vllm and this belongs here?
Before submitting a new issue...
Your current environment
The output of
python collect_env.py🐛 Describe the bug
Before anyone reads this. I believe this has something to do with lmcache. Should i go to lmcache's issues for this or is lmcache fully supported in vllm and this belongs here?
VLLM version 0.11.2 installed with
uv pip install vllm==0.11.2 --torch-backend=autoSo i was stress testing my installation of vllm with the model specified which was served on 4x4090 using this command:
the lmcache_config.yaml (found somewhere online too)
I was running my personal suite to test parallelism up to 32 concurrent requests. input tokens 1024, 2048 and 4096, output stopped at 1024 tokens with concurrency from 1 to 32 using powers of 2. At some point it came down to 4096 input tokens while using 32 concurrency, and that's where things got weird. First i noticed this line:
Which was weird, didn't come up before while serving full day with --max-num-seqs 4
And then it started breaking down
Which ultimately resulted in
And it got down eventually.
The error log (full output of nohup) is attached below:
error.log
Looking for any help because we can't live long on 4 parallel queries. And i'm suspicious of
--kv-transfer-config '{"kv_connector":"LMCacheConnectorV1","kv_role":"kv_both"}'which i found somewhere online and didn't test any variations of it yet.Should i go to lmcache's issues for this or is lmcache fully supported in vllm and this belongs here?
Before submitting a new issue...