用vllm部署Qwen2.5 7B，显存一直涨到OOM，是代码有问题吗？

建议查下vllm版本，老版本显存碎片化严重，升到0.6.3以上试试。

这情况多半是连续请求触发了显存碎片，换个后端比如llama.cpp的server模式可能更稳。

显存涨说明paged attention可能没吃满，试试把gpu_memory_utilization降到0.8看看，或者换个AWQ量化版。

这情况像显存碎片化，vllm对int4支持本来就没fp16稳，建议直接上4bit的GPTQ加--enforce-eager。

试试关掉前缀缓存或者换paged attention的版本，之前我遇到类似问题升到最新版就好了。

max_num_seqs调低到16，再配合--enable-chunked-prefill试试，能缓解碎片化。

我之前也踩过类似的坑，vllm那个显存动态管理主要是针对paged attention的KV cache，但int4量化版的Qwen2.5 7B其实权重载入后就有大概4-5G，加上你设的gpu_memory_utilization=0.9，两张卡单张实际可用的显存就被锁死了，而max_num_seqs=64在某些长上下文场景下会一次性申请大量KV block，尤其是连续请求时block复用效率不高，碎块累积起来就爆了。你调max_num_batched_tokens没用是因为这个参数管的是单次decode的token数，跟KV cache的预分配不是一回事。建议先加个--max-model-len 4096或者更小，把序列长度上限压下来，然后试试把gpu_memory_utilization降到0.8，给vllm的调度器留点余量，同时用--enable-prefix-caching看能不能提高block复用。另外如果还不行，可以换llama.cpp的server跑同款量化，虽然吞吐低一点但显存控制稳很多，尤其是这种连续请求场景基本不会OOM。

试试把gpu_memory_utilization调到0.85，再配个max_seq_len限制，可能是长序列没释放导致碎片累积。

之前调试过类似问题，vllm的动态显存管理主要是靠paged attention的，但int4量化下显存碎片化可能会比fp16严重，尤其是长序列并发时。你可以先试试把gpu_memory_utilization降到0.7，同时把max_num_seqs调到32，看峰值是不是明显下降。另外建议用nvidia-smi盯着看是哪个缓存阶段在涨，如果持续上升而不是阶梯式跳跃，多半是prefill和decode的调度问题，可以试试加--enable-chunked-prefill参数。我之前用AWQ量化版加这个参数后稳定多了。

试试把gpu_memory_utilization降到0.7，再把max_num_seqs调小，vllm那套预分配吃显存挺狠的。

检查下是不是prompt里带长上下文了，7B int4按理说24G×2不会这么容易爆，可能峰值缓存没清干净。

试试把gpu_memory_utilization降到0.7，vllm预分配太狠了，容易跟缓存打架。

检查下是不是prompt长度波动大，动态管理对极端长度会失效，限制下max_model_len试试。

我之前跑7B也遇到过类似情况，后来发现是vllm的prefix caching没关，长文本共享前缀时显存会偷偷堆。你可以试试加--disable-prefix-caching参数，或者把max_num_seqs调小到32看看。另外int4量化版其实挺吃显存的，建议直接上AWQ量化，能省不少。还有个小技巧，把gpu_memory_utilization设成0.85，给pytorch留点余量，有时候反而更稳。

你这情况我遇到过类似的，排查重点可能不在max_num_seqs上，而是vllm的prefix caching和显存碎片。试试把gpu_memory_utilization降到0.85，同时加个--enable-chunked-prefill参数，能让显存释放更及时。另外7B int4在双卡下其实有点尴尬，单卡跑不动长上下文，双卡又容易因为张量并行导致显存分配不均，建议直接用AWQ量化版或者换4bit的Qwen2.5 7B GGUF配llama.cpp，单卡24G反而稳。

之前跑Qwen2.5 7B也遇到过类似情况，后来发现是长文本场景下vllm的KV cache增长比预期快，特别是并发高时，动态释放有延迟。你试试把gpu_memory_utilization降到0.8以下，或者直接限制max_model_len，比如4096，能明显缓解。另外int4量化版其实用vllm的AWQ或GPTQ支持可能更稳，如果还不行就换llama.cpp吧，显存控制更直接，就是吞吐会低一档。

我最近也遇到过类似情况，不过是在跑Yi-34B的时候。你这个问题大概率不是代码bug，vllm那个动态显存管理其实主要管的是KV cache的复用，但int4量化后的权重虽然小了，激活值和中间状态的内存占用反而更容易成为瓶颈，尤其max_num_seqs开64对于7B来说有点太激进了，建议先降到16试试。另外你gpu_memory_utilization设0.9，两张卡总共43G可用，但vllm是按单卡显存算的，实际分配可能比你预期的高很多，可以试着改成0.7左右，留出一些余量给CUDA context和其他碎片。还有个坑是连续请求时如果prompt长度变化大，vllm会预留最大可能长度的KV cache，你可以把max_model_len设小一点比如4096，别用默认的32K，这样显存分配会紧凑很多。如果还不行，建议直接上flash-attention的版本，或者换llama.cpp的server模式，虽然吞吐低点但显存控制更稳，至少不会莫名OOM。你那边跑的是多长的prompt？如果平均就几百token，那其实用AWQ或者GPTQ的4bit配合量化KV cache会友好很多。

显存涨到OOM大概率是量化版没生效，检查下vllm是不是真的加载了int4权重，或者换个AWQ版本试试。

之前我也遇到过类似情况，把gpu_memory_utilization降到0.85加限制单条max_len，基本就稳了。

这问题我踩过类似的坑，vllm的显存管理在连续请求下确实有滞后，尤其是量化模型会多一层显存映射开销。你试试把gpu_memory_utilization降到0.7，然后强制加个--enable-prefix-caching看看，有时候是共享前缀没生效导致KV cache疯狂膨胀。另外如果prompt长度差异大，max_num_seqs=64太激进了，实际并发峰值远高于这个数，建议先压到32观察趋势。实在不行换TGI或者SGLang试下，7B int4用SGLang的RadixAttention在我这边稳很多。

这情况我遇到过，大概率不是代码问题，是vllm的显存预留和KV cache预分配在搞鬼。你把gpu_memory_utilization设到0.9，它会先把显存吃满预留，后面请求多时再动态分配，反而容易触发碎片化OOM。建议先降到0.8试试，然后把max_num_seqs调小到32，另外看看是不是prompt长度波动大导致预分配跟不上。我这边之前换用flashinfer后端，或者干脆切到sglang，同样配置下稳定很多，你可以对比下。

之前跑Qwen2.5 7B也遇到过类似情况，最后发现是vllm的显存碎片化太严重，尤其是量化模型在长上下文下特别明显。你试试把--enable-prefix-caching打开，然后max_num_seqs降到32，另外注意是不是有请求的max_model_len设得太高，比如超过8k，那会直接吃掉一大块预留显存。如果还不行，可以换llama.cpp的server跑，虽然吞吐低点但显存控制稳得多，基本不会OOM。

我之前也踩过类似的坑，vllm的显存管理在量化模型上确实不如fp16那么稳，尤其是连续长prompt时KV cache会悄悄累积。你试试把gpu_memory_utilization降到0.7左右，然后加个--enforce-eager参数，能省不少显存，虽然慢点但至少不会OOM。另外确认下是不是用的最新版vllm，老版本对int4支持有bug。如果还不行，建议换llama.cpp的server模式，7B int4在4090上单卡就挺稳，就是并发低点。

试试把gpu_memory_utilization降到0.8，然后关掉prefix caching，这版本vllm对量化模型显存回收有bug。

这情况我踩过坑，vllm的显存管理主要靠KV cache的抢占式释放，但int4量化后显存碎片化会加剧，尤其长文本下预分配还是按原始精度算的。你试试把env里的VLLM_ATTENTION_BACKEND改成flash_attention，再把max_num_seqs降到32，另外确认下是不是prompt里带了很多system历史导致context长度暴涨。实在不行换sglang，同配置下能省5-8G显存。

你这情况大概率不是代码问题，vllm的显存管理对长上下文场景本来就不太友好，尤其是量化版模型在连续请求时KV cache会持续累积。我之前用同款卡跑Qwen2.5 7B也遇到过，后来把gpu_memory_utilization降到0.8，同时限制max_model_len到4096才稳住。另外你检查下是不是有请求没正确关闭连接，导致显存碎片没被回收，可以试试定期重启worker进程。要是实在不行，换个思路用TGI或者ExLlamaV2，对小规模并发反而更省心。