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

这个现象挺典型的，不是显存分配姿势问题，是vLLM默认会把请求的KV cache都预留在显存里，20并发下每个序列都要占一块，加上max-model-len设得长，峰值自然就爆了。你可以试试把--max-num-seqs调低，比如8或者4，让vLLM自己排队，或者用--enable-chunked-prefill把长prompt拆开处理，能明显缓解OOM。另外4090的24G跑7B其实有点紧，实在不行就上量化版本，AWQ或者GPTQ，精度损失在对话场景基本感知不到。

这个参数组合确实有点赌运气了，0.9的利用率基本把显存榨干，KV cache和并发下的临时张量稍微抖一下就炸。建议先降到0.7试试，然后看看是不是max_num_seqs没调，默认值在20并发时可能瞬间分配大量block。我这边跑13B用0.85加max_num_seqs=8才稳，你可以对比下nvidia-smi里的cache峰值。

你这配置单看没啥问题，但OOM大概率是KV cache和并发请求的显存分配冲突了。试试把--max-num-seqs调小点，比如8或者4，vLLM默认会按最大并发预分配显存，20个请求的临时缓存很容易顶爆。另外可以加--enable-prefix-caching，重复prompt能省不少显存，我上次跑8B模型这么调完并发翻倍都没崩。

这问题我也踩过坑，单看max-model-len和gpu-memory-utilization其实不够，vLLM默认会给每个并发请求预分配KV cache空间，20个请求同时进来那个峰值直接爆掉。你可以试试把--max-num-seqs调小到8或者4，或者手动设一下--kv-cache-dtype fp8，我这边同样配置下并发稳多了。另外确认下是不是开了--enable-prefix-caching，那个在高并发下也会额外吃显存，建议先关掉跑一轮对比看看。

把max-num-seqs调低点试试，默认256个并发序列太吃显存了，20并发建议设成8或16。

你这gpu-memory-utilization给的太满了，留点余量给KV cache，试试0.85再加--max-num-seqs 12，应该能稳。

我之前也踩过这个坑，--gpu-memory-utilization 0.9 其实只是给KV cache留了10%的余量，并发一上来每个请求的prefill阶段会临时申请额外显存，这部分根本不在你控制范围内。建议把利用率降到0.75左右，同时把--max-num-seqs限制到4或8，牺牲一点吞吐换稳定。另外可以试试开--enable-chunked-prefill，它能把长请求的prefill拆碎，显存峰值会平滑很多，20并发应该就不炸了。

说实话你这配置和参数我看着挺合理的，但问题可能出在vLLM预分配的KV cache上。--gpu-memory-utilization 0.9虽然给了90%显存，但Qwen2.5-7B的KV cache是按最大序列长度和最大并发数动态预留的，你设了8192长度，20并发理论上要预留208192(40层2头维度*2字节)的显存，这数字算下来比模型权重还大不少。我上次用7B模型开2048长度，并发16个，显存峰值也就15G左右，你试试把--max-model-len降到4096或者2048，应该能缓解OOM。另外可以加--max-num-seqs参数限制一下同时处理的序列数，比如设成8或12，让多余请求排队，这样显存占用会更可控。还有个思路是开--enable-chunked-prefill，把长输入的prefill阶段拆块，减少瞬时峰值，不过对短输入场景可能收益不大。我这边跑过类似压力测试，vLLM的OOM往往不是权重占满，而是KV cache的预留策略太激进，你调低--gpu-memory-utilization到0.8反而可能更稳，因为留点余量给CUDA context和碎片。最后建议你监控一下nvidia-smi里每帧的显存变化，看看是不是某个瞬间所有请求同时prefill导致峰值，如果真是这样，那就得靠限流或者调整调度策略了。

把max-num-seqs调小点，比如4或8，不然预分配的KV cache直接吃满显存。

你这配置单看没啥毛病，但OOM大概率不是显存分配姿势的问题，而是vLLM的KV cache预分配策略跟并发直接撞上了。max-model-len开到8192，gpu-memory-utilization又拉到0.9，意味着vLLM会按最大序列长度一次性把KV cache的显存池子全划走，20个并发请求同时进来，每个请求的KV cache都按8192长度算，24G根本兜不住。我之前用70B模型也踩过类似的坑，后来发现把gpu-memory-utilization降到0.75左右，同时把max-num-seqs设成16或更小，反而更稳，牺牲点吞吐但不会崩。另外你可以试试开--enable-chunked-prefill，这玩意儿能把长prompt的prefill阶段拆成小块，显存波动会平滑很多，对并发场景挺管用。还有个小技巧，如果你实际业务里的prompt长度远小于8192，比如平均就1-2k，那max-model-len别开这么宽，按实际需求收紧，KV cache瞬间能省出一大截。最后建议你监控下nvidia-smi的显存走势，看是匀速涨还是突然跳变，突然跳变的话大概率是某个请求触发了极端长度，可以配个--max-paddings或者限制单请求最大输入长度来兜底。整体感觉你这配置更适合低并发高单请求延迟的场景，真要扛20并发，得在预留显存和吞吐之间重新找个平衡点。

显存利用率调太高了，0.9基本不给KV cache留余量，试试0.7或者限制下max-num-seqs。

这参数组合确实容易爆，我上次调低max-num-seqs到4就好了，你可以试试看。

这题我熟，之前用vLLM跑Yi-34B也踩过同样的坑。你--gpu-memory-utilization 0.9其实已经预留了KV cache的空间，但并发的预分配是按最大可能请求数来算的，20路并发下KV cache直接吃满剩余显存，再加上激活值就炸了。建议试试--max-num-seqs限制一下并发序列数，或者把--max-model-len降到4096，我这边同样条件降到4096后稳定扛住30并发不崩。另外可以观察下是不是prefix cache导致的碎片化，开--enable-prefix-caching不一定省显存，反而可能加剧峰值。

显存利用率0.9太激进了，得给KV cache留点余量，降到0.8试试。

你这配置看着没啥问题，但20并发对于7B模型来说，KV cache的显存开销确实会暴涨，24G被吃满很正常。我猜你可能是漏了--max-num-seqs这个参数，默认值比较大，并发请求进来时vLLM会一次性预分配太多槽位，试试手动限制到8或者4，OOM应该能缓解。另外也可以开--enable-chunked-prefill，把长输入的prefill阶段拆碎，显存峰值能降不少。

试试把--gpu-memory-utilization调到0.85，再给vLLM加个--max-num-seqs 8限制并发数，OOM概率会小很多。

这参数看着没问题，但20并发对7B来说有点猛，要不你开个--enable-chunked-prefill试试，能省不少显存。

这应该不是姿势问题，是vLLM的prefill阶段和decode阶段显存分配逻辑不一样，并发一上来KV cache直接炸了。你可以试试把--max-num-seqs调小一点，比如默认是256，改到64甚至32，同时把--max-num-batched-tokens也限制一下，这样能强制vLLM更保守地预留显存。另外如果对延迟没那么敏感，可以开--enable-chunked-prefill，把长请求的prefill拆碎，能显著压峰值显存。我之前用8x7B也遇到过类似情况，调完这两个参数基本就稳了。

这情况我也踩过坑，问题大概率不在显存分配，而是vLLM的KV cache会按最大并发预分配。你试试加--max-num-seqs 8或者调低点，把并发数限制住，再配合--enable-chunked-prefill，能省不少显存。另外--gpu-memory-utilization别拉太高，0.85左右留点余量给CUDA context，不然一有波动直接崩。

试试把max-num-seqs调小，默认256太高了，20并发用不到那么多。

显存利用率和max-num-seqs是两码事，vLLM会按上限预分配KV cache，调低点试试。

20并发就崩，感觉是max-num-seqs吃满了，限制到64应该能稳不少。

我之前也踩过这坑，vLLM的显存分配不是单纯看模型权重，KV cache和预分配的内存块占大头。你把gpu-memory-utilization拉到0.9，等于把所有显存都吃进去做预分配，并发一上来每个请求都要抢KV cache，直接爆掉。建议降到0.7左右，同时减少max-model-len到4096试试，或者开上--enable-chunked-prefill，能显著降低峰值显存。另外也可以考虑用PagedAttention的默认分页策略，别手动调太激进，我之前调参调半天不如直接按官方recommended配置来。

试试把--max-num-seqs调小到4-8，再配合--max-model-len砍到4096，并发OOM多半是KV cache预留太满了。

OOM大概率不是显存分配的问题，而是KV cache的预分配机制没调好。你只设了max-model-len但没限制max-num-seqs，vLLM默认会按最大并发数预估KV cache空间，20个请求×8k长度直接把剩余显存吃满了。试试把--max-num-seqs设成4或8，再配合--enable-chunked-prefill，应该能压住峰值。另外如果QPS要求不高，可以开--enforce-eager省掉CUDA graph的额外开销，显存能再腾出1-2G。我之前用同样配置跑过，把max-num-seqs降到6后并发30都没崩，你可以先从这个参数调起。