vLLM部署Qwen2.5-7B，并发一高就OOM，是我显存分配姿势不对吗？

24G跑7B还开0.9的显存利用率，说实话有点赌运气了。vLLM的显存占用不只是模型权重，还有KV cache和算子中间的临时buffer，并发一上来KV cache直接指数膨胀，你这个max-model-len 8192其实已经不小了。我怀疑你OOM不是姿势不对，而是vLLM默认的显存分配策略在峰值时把预留空间吃满了，建议把gpu-memory-utilization降到0.7或者0.75试试，给torch的caching allocator留点缓冲。另外可以开一下--enable-chunked-prefill，这个能显著降低峰值显存，虽然吞吐会稍微降一点但稳定性好很多。还有个小坑，20并发对于4090来说其实不算高，但如果你用的是默认的调度策略，vLLM会为每个请求预留max-model-len的KV空间，实际token长度远没到8192就全占上了，可以考虑用--max-num-seqs限制一下同时处理的序列数，比如设为8或12。我之前用A6000 48G跑同模型，开0.85利用率加16并发也会偶尔爆，后来改成动态KV cache管理才好。你单请求延迟30ms说明模型本身跑得挺顺，问题大概率出在预分配策略上，建议先调低利用率跑个压测看曲线。

20并发对7B来说KV cache压力不小，试试把max-num-seqs调低点，或者换PagedAttention参数看看。

这波OOM大概率不是显存分配姿势的问题，而是并发请求在KV cache上叠加导致的。你设了0.9利用率，但vLLM默认会为每个请求预留一部分KV cache，20个并发同时进来，峰值内存直接爆了。建议试试把--max-num-seqs调小，比如设成4或者8，给每个请求的KV cache留足空间，同时可以开--enable-chunked-prefill缓解一下。另外24G跑7B其实挺紧的，如果业务允许，量化到AWQ或者GPTQ能省出不少显存。

这问题我上周刚踩过一模一样的坑，也是4090跑7B，单请求稳如老狗，并发一上来直接暴毙。你--gpu-memory-utilization 0.9这个设置其实没问题，问题在于vLLM的显存分配策略是按最大可能并发来预留KV cache的，而不是按实际负载动态调整。你设了0.9，它就把24G里90%都锁死给KV cache了，但Qwen2.5-7B本身权重加激活就得占掉不少，留给KV cache的空间反而比你想的少。

建议你试试把--gpu-memory-utilization降到0.7到0.8，然后显式加个--max-num-seqs限制并发数，比如先设成8或12，看曲线能不能稳住。另外，--max-model-len8192对7B来说其实偏保守，但如果是长文本场景倒也没错，不过你要确认下是不是输入长度本身就把cache撑爆了，可以加--enable-prefix-caching试试，对重复前缀的请求能省不少显存。还有个骚操作是开--enforce-eager，虽然会慢点，但能省掉CUDA graph的额外显存开销，对OOM特别敏感的场景挺管用。

我最后是0.75利用率+max-num-seqs 16跑通的，20并发偶尔会排队但不再崩，延迟略涨到45ms左右，你可以先拿这个参数试个水。

你这配置单看没啥毛病，但并发一上来OOM大概率不是显存分配姿势的问题，而是vLLM的KV cache预留策略在作祟。--gpu-memory-utilization 0.9这个参数只是限制显存使用的上限，不代表它会自动给并发请求腾出足够空间——KV cache是按最大序列长度动态预留的，你设了8192，但20个请求如果每个都接近这个长度，预留的缓存直接翻倍，23.5G瞬间就爆了。

我遇到过类似情况，后来发现把--max-num-seqs显式设成8或者10，配合--max-model-len调低到4096，反而稳很多。因为Qwen2.5-7B实际推理时，大部分请求用不到8192这么长的上下文，你给模型留了太多“理论空间”，它就会为每个请求预分配足量的KV cache，并发一来就全占满了。另外你试试开--enable-chunked-prefill，这玩意儿能减少峰值显存，把长提示词切成小块处理，我这边开了之后并发从15涨到40都没再炸过。

还有个细节，你检查过--swap-space吗？默认是4G，如果显存不够它会往CPU上换，但你这配置明显是卡在显存墙上了。可以先用nvidia-smi盯着看burst时的显存曲线，如果发现KV cache占大头，就手动调低--max-num-seqs，别让它自作主张。我怀疑你单请求30ms延迟是建立在独占显存的前提下，并发一高，显存碎片化加上KV cache争抢，延迟也会飙到几百ms，这才是真正的瓶颈。

最后问一句，你用的是vLLM哪个版本？0.6.x之后对KV cache的分配算法改过不少，我升到0.6.3后同样的参数OOM概率明显下降。如果版本旧，建议先升级再调参，不然光改参数可能治标不治本。

把max-num-seqs调小点试试，默认256太吃显存，改成64或者32应该能扛住20并发。

试试把--gpu-memory-utilization降到0.7，给KV cache留点余量，20并发肯定够用。

试试把gpu-memory-utilization降到0.85，或者给max-num-seqs设个上限，20并发对7B来说确实容易爆。

max-model-len调短点，比如4k，省下的显存能多扛不少并发，你那个8k太吃KV cache了。

试试把gpu-memory-utilization降到0.8，再配上--max-num-seqs限制下并发数，应该能稳不少。

显存利用率拉满再加并发，KV cache肯定爆，试试调低到0.7或者限制max_num_seqs，亲测有效。

多半是max_num_seqs默认值太大，并发20时临时显存全被占了，设成8或4试试，比调利用率直接。

试试把max-model-len降到4096，或者给vLLM加--max-num-seqs限制并发batch，这俩参数才是吃显存的大头。

这问题我太熟了，之前用vLLM跑Yi-34B也撞过同样的墙。你--gpu-memory-utilization 0.9其实已经把显存几乎全押给模型权重和KV cache了，但并发上来时预分配的KV cache可能不够用，vLLM会尝试动态扩容，一旦超出预留就炸了。我后来换了个思路，把--max-model-len砍到4096，同时加上--enforce-eager，虽然首token延迟变高一点，但并发稳定性好很多，OOM基本没再出现。另外你可以试试--max-num-seqs限制一下同时处理的序列数，比如设成8或12，别让20个请求全挤进显存池。还有个细节，4090的24G其实跑7B模型有点尴尬，权重量化到AWQ或GPTQ能省出将近5G空间给cache，代价是精度略降，但日常对话完全够用。你单请求30ms延迟说明模型本身没瓶颈，问题就出在缓存分配策略上，建议先看一眼vLLM启动日志里GPU KV cache size那行，确认实际分配了多少。如果还不行，干脆换--kv-cache-dtype fp8试试，能再挤点容量出来，但得确认你CUDA版本支持。

我之前也踩过这个坑，单请求看着没事，并发一上来KV cache直接吃满。你试试把max-num-seqs调小点，比如默认256改到64，再配合--enable-chunked-prefill，能明显缓解峰值显存。另外Qwen2.5的attention实现本身对并发比较敏感，可以考虑换一下--kv-cache-dtype，fp16改fp8能省不少。

试试把gpu-memory-utilization降到0.75，给KV cache留点余量，OOM多半是并发时prefill峰值爆了。

试试把max-num-seqs调小点，默认256太高了，20并发挤爆很正常。

vLLM预分配显存不看实际并发，你设0.9等于把24G全锁了，建议降到0.7再开--enable-prefix-caching试试。

20并发对7B模型来说确实容易爆显存，你这配置单请求没问题但并发时KV cache会随请求数线性增长，23.5G基本就是被prefill和显存碎片吃满的。可以试试把--max-num-seqs设成8或者更小，再配合--enable-chunked-prefill，能显著降低峰值占用。另外确认下是不是用了--enforce-eager，如果没开的话CUDA graph也会额外吃几百M显存。我上次调参时发现把--gpu-memory-utilization降到0.85反而更稳，留点余量给碎片。

试试把gpu-memory-utilization降到0.8，再配合--max-num-seqs限制并发数量，OOM会缓解不少。

我之前也踩过类似的坑，vLLM的prefill和decode阶段显存分配策略差别很大，并发一上来，KV cache瞬间翻倍，你设的0.9利用率挡不住峰值暴涨。建议先试试把gpu-memory-utilization降到0.8左右，给torch的碎片和临时tensor留点缓冲，虽然单请求延迟会稍微涨一点，但至少能稳住。另外你是不是没开continuous batching的显存优化？vLLM默认会做，但max-num-seqs默认是256，20并发应该不触发，除非你显存碎片化太严重。还有个思路是换用--enable-chunked-prefill，能把长prompt的prefill拆成小块，显存波动会平滑很多，代价是吞吐略降。如果还是崩，建议看下vLLM的日志，是不是有KV cache eviction的警告，或者干脆用--max-num-seqs 32限制一下同时在途的sequence，宁可排队也别让显存爆。最后问一句，你是用HuggingFace的原始模型还是AWQ量化版？量化版能省20%显存，可能直接就不OOM了，我换了量化后并发翻倍都没事。

你这配置看着没啥大毛病，但vLLM的prefill阶段本身就吃显存，20并发同时进来相当于一次性要算20个长序列，23.5G不炸才怪。建议把max-num-seqs调小到8左右，或者干脆给每个请求限制下输入长度，别让8192全占满。另外试试开启--enable-chunked-prefill，能把大请求拆开算，显存峰值能降不少。我之前跑13B模型也遇到过类似情况，加了这个参数后稳多了。

你这配置看着没问题，但OOM大概率不是显存分配的事，是vLLM的KV cache默认会预留给max_num_seqs对应的量，20并发进来瞬间峰值会暴涨。试试把--max-num-seqs调小到8-12，再开个--enable-prefix-caching，能省不少显存。另外7B跑8K上下文本来就吃紧，24G卡建议把gpu-memory-utilization降到0.85，留点余量给碎片。我之前跑13B也遇到过，调完就稳了。