VLLM部署Qwen2.5 7B，并发一高就OOM怎么办？

这个情况我也碰到过，3090显存24G跑7B模型其实挺极限的，尤其VLLM的显存管理虽然好但也不是万能的。你max_num_seqs设到256太大了，并发10个请求根本用不到那么多slot，反而会提前把显存占满，建议先降到64甚至32试试。另外gpu_memory_utilization 0.8其实偏保守，可以拉到0.9甚至0.95，只要不跑其他任务基本稳得住。如果还不行的话，强烈建议用AWQ或者GPTQ量化到4bit，显存占用直接砍半，精度损失在对话场景里基本感觉不出来，而且VLLM原生支持量化模型，改个路径就行。拆多副本也不是不行，但3090单卡拆两个实例的话，每个只能分到12G，还不如量化后单实例跑得舒服。还有就是检查一下你的请求长度是不是特别长，context window开太大也会炸，Qwen2.5 7B默认32K，如果实际用不到可以设短一点省显存。说实话你这情况大概率调调参数就能解决，量化是性价比最高的方案。

我也遇到过类似的情况，max_num_seqs设太高反而容易爆显存，尤其是7B模型，建议先降到64或者32试试。另外gpu_memory_utilization可以再大胆一点调到0.95，VLLM对显存管理其实挺激进的。如果还不行，上AWQ或者GPTQ量化版本，4bit能省差不多一半显存，单张3090跑并发会稳很多。

max_num_seqs设256太高了，3090显存24G根本扛不住，建议砍到64或者32试试。另外gpu_memory_utilization提到0.9甚至0.95也没问题，我试过Qwen2.5 7B用AWQ 4bit量化，同时压20个请求都没爆。你这预算不想加卡的话，直接上量化版本最省事。

这个问题我也踩过坑，3090显存24G跑7B模型理论上够，但VLLM的显存分配策略其实挺敏感的。max_num_seqs设成256对于7B来说太高了，实际上10并发根本用不到这个数，反而会让预分配显存膨胀，建议先降到64试试。另外gpu_memory_utilization只留0.2给KV cache和其他开销，在7B上可能还是偏紧，可以调到0.85甚至0.9看看，只要不触发碎片化就行。

不过我觉得最根本的解法还是上量化，AWQ 4bit能把7B压到4-5G显存，剩下的空间给并发调度就从容多了，而且精度损失在对话场景里几乎感觉不到。如果不想换模型，也可以考虑把VLLM的调度策略改成preemption模式，配合swap到CPU内存，虽然会慢一点但至少不崩。

还有一个容易被忽略的点——检查一下是不是用了--enable-prefix-caching，这个开起来有时会额外吃显存，对并发帮助不大。反正3090要撑10并发，量化几乎是必须的，或者你可以拆两个端口各跑一个副本，每个扛5路，资源利用率反而更高。

max_num_seqs调低到32试试，3090显存扛不住那么多并行。

一张3090扛10并发确实到极限了，max_num_seqs设256反而可能让显存碎片化更严重，试试降到32-64看看。另外7B模型用FP16大概得14G显存，你gpu_memory_utilization调到0.8剩16G左右，但VLLM的KV Cache加上调度开销很容易超，建议开量化比如AWQ或GPTQ，显存直接砍半，同时也能提点并发量。如果不想动模型，拆成两个副本用不同端口部署，再拿nginx做负载均衡也是个省钱的办法，但记得把每个副本的max_num_seqs调低。

3090跑7B并发10个确实有点极限了，max_num_seqs设256反而可能让显存碎片化更严重，试试压到32或者64，配合gpu_memory_utilization拉到0.95看看。另外建议换AWQ或GPTQ量化版，4bit下显存占用能降一半，我实测同样配置从8个请求撑到20个才崩。要是还不行，干脆用vLLM的分布式推理搞两个副本，每张卡各跑几个请求，比单卡硬扛稳得多。

max_num_seqs设太高了，3090扛不住，降到32试试，OOM能缓解不少。

说实话你这配置单张3090跑7B模型，10并发就已经到极限了，max_num_seqs设256其实没啥用，因为显存瓶颈不在调度队列长度，而是每个请求的KV Cache占用的显存。你试试把gpu_memory_utilization调到0.9以上，同时把max_num_batched_tokens设小一点，比如1024或者2048，这样VLLM就不会一次性塞太多token进显存。另外建议开--enable-prefix-caching，如果对话有重复前缀能省不少显存。量化确实是个好方向，AWQ或者GPTQ的4bit版本能在3090上把7B模型压到6GB左右，这样并发余量就大很多。不过要注意VLLM对量化支持不太一样，AWQ兼容性更好一些。如果还是撑不住，可以试试在VLLM启动时加--num-scheduler-steps 2或者3，让调度器分批处理请求，减少瞬时显存峰值。拆多副本的话成本太高了，一张卡跑两个实例反而会因为显存碎片更不稳定。

max_num_seqs设256在3090上跑7B确实太激进了，8G显存根本扛不住，建议先砍到32或者64试试。另外可以开vllm的prefix caching，对重复对话场景能省不少显存。如果还不行，直接上AWQ或GPTQ量化版，4bit下7B在3090上跑并发会稳很多。

max_num_seqs设256确实太高了，7B模型在3090上跑，并发10左右建议先压到32甚至16试试，显存碎片化严重的话照样爆。gpu_memory_utilization0.8也可以再降点，留出swap空间。另外建议开--enable-prefix-caching和--use-v2-block-manager，能省不少显存。量化的话AWQ或者GPTQ的4bit版本在3090上兼容性不错，推理速度也够用。

3090 24G显存跑7B全精度确实有点吃紧，并发10个OOM挺正常的。建议先把max_num_seqs降到32或64试试，这参数不是越大越好，同时把gpu_memory_utilization调到0.9或者0.95。如果还不行，直接上AWQ或GPTQ量化版，4bit下显存占用能砍一半，并发能力会明显改善。

一张3090扛7B模型加10并发确实有点极限了，max_num_seqs设256反而容易爆显存，可以试试降到8-16，让请求排队进队列而不是全挤进去。另外gpu_memory_utilization提到0.9或者0.95试试，同时开个swap或者用--swap-space参数给CPU内存分担一下。如果还不行，建议换成AWQ或者GPTQ的4bit量化版本，显存占用直接砍半，流畅度影响不大。

max_num_seqs设256太激进了，3090显存扛不住，先降到64试试。

max_num_seqs设太高了，256对7B来说压力太大，先降到32试试，再配合量化。

max_num_seqs设256对7B模型来说太激进了，3090的24G显存扛不住那么多prefill，建议先降到32或64试试。gpu_memory_utilization可以提到0.95，VLLM留的显存余量其实偏保守。另外量化确实值得搞，AWQ或GPTQ的4bit版能省一半显存，吞吐能翻倍，网上有现成的量化权重可以直接用。

max_num_seqs调低到64试试，3090显存扛不住256个并行。

我也遇到过类似情况，3090 24G跑7B其实挺极限的。可以试试把gpu_memory_utilization再压到0.7以下，同时把max_num_seqs降到8-16，毕竟10并发不需要256的预分配。另外建议直接用AWQ或GPTQ量化到4bit，显存能省一半，单卡扛20个并发都没问题。实在不行就用vLLM的自动调度加swap，把部分请求暂存到CPU内存里，虽然慢点但至少不OOM。

3090 24G显存跑7B模型，并发10个确实容易炸，max_num_seqs设256太激进了，建议先砍到32试试，gpu_memory_utilization可以提到0.9。如果还不行，直接上4bit量化，vllm对AWQ支持很好，显存占用能降一半，单卡撑20并发问题不大。另外注意下请求长度，别让上下文累积太多，开个max_model_len限制一下能省不少显存。

3090上扛7B并发10个确实极限了，max_num_seqs设256反而容易爆显存，VLLM会预分配KV cache，建议先砍到32试试。另外gpu_memory_utilization别拉太高，留点给torch本身，0.7左右稳些。量化的话AWQ 4bit能省不少，但注意Qwen2.5的激活层可能掉点，内部工具够用就行。实在不行就拆两个进程各占半张卡，负载均衡一下，比单副本硬扛靠谱。