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

3090跑7B并发10就炸挺正常，试试awq量化再把max_num_seqs砍到64，显存预留别超0.7。

max_num_seqs设太高反而容易爆，建议开个--enable-prefix-caching，再把请求排队限流一下。

说实话max_num_seqs=256在3090上跑7B本身就是个矛盾配置，这参数是给H100那种80G显存准备的。你单卡24G显存，塞下KV cache之后实际能并行处理的序列数大概就二三十，硬撑256只会让显存碎片化更严重，OOM反而来得更快。建议先把max_num_seqs压到32甚至16，配合gpu_memory_utilization降到0.7试试，很多时候并发高不是模型装不下，是调度器把显存预分配搞爆了。

另外你提到量化版本，这个方向其实比拆副本靠谱。AWQ或者GPTQ的4bit量化能把7B压到5G左右，这样KV cache能留出更多空间，实测并发能翻倍。不过注意别用GPTQ的动态量化，VLLM对AWQ支持更稳。还有个偏方，如果你请求长度比较短（比如几百token以内），可以把max_model_len从默认的32k砍到8k，这操作对显存释放立竿见影，很多内部工具根本用不到长上下文。

最后关于拆副本，单卡就别想了，多副本反而会加剧显存争抢。真到瓶颈的话，不如考虑vLLM的continuous batching配合PagedAttention，把swap到CPU的阈值调低点，让部分请求排队而不是同时驻留显存。3090虽然拉胯但没到跑不动7B的程度，大概率是配置策略问题，先别急着换硬件。

3090显存就24G，跑7B full精度加KV cache本来就很吃紧，max_num_seqs设256基本是给A100准备的，你这并发10个都OOM说明显存分配已经到极限了。建议先把max_num_seqs降到32左右，同时把gpu_memory_utilization再压到0.7试试，给KV cache留点余量。另外可以试试AWQ或GPTQ的4bit量化，显存占用能砍一半，但注意得用vllm官方支持的量化格式，不然反而容易出兼容问题。实在不行就拆两个进程各占一半显存，用负载均衡顶一下，比单卡硬扛稳得多。

你这配置单看没啥大毛病，问题大概率出在max_num_seqs和显存策略的配合上。7B模型在3090上本身KV cache就吃紧，256个并行序列直接把显存撑爆了，建议先降到32或者64试试，顺便把gpu_memory_utilization调到0.9看看。另外不用急着换量化，可以先开下vllm的--enable-prefix-caching，对这类内部工具的重叠prompt效果挺明显，能省不少显存。要是还顶不住，那就只能拆成两个副本用负载均衡，3090跑7B也就这个并发量了。

3090跑7B说实话并发10个到OOM太正常了，你这max_num_seqs=256纯属是给A100那种大显存准备的，3090就24G，显存带宽和容量都扛不住这么多序列的KV cache。我建议先把max_num_seqs压到8或者16，gpu_memory_utilization调到0.9试试，因为vllm会预分配显存，你设太高反而容易在峰值时候爆掉。另外Qwen2.5 7B本身FP16就要14G左右权重，加上激活和KV cache，24G真的紧巴巴，换成AWQ或者GPTQ量化到4bit能省一半显存，但vllm对量化支持有时候会慢一点，你可以先试试不量化只调并发参数能不能撑住。如果还是不行，那就得考虑拆成两个vllm实例，每个实例挂一半显存，前面用nginx或者自己写个简单负载均衡，这样至少一个崩了另一个还能顶上。还有个坑是vllm的preemption策略，默认是swap，显存不够会往CPU换页，但3090和内存之间带宽不够，反而会拖垮延迟，你可以在启动参数里加--swap-space=0试试强制拒绝请求而不是OOM。最后提醒下，单卡3090跑在线服务本来就很极限，内部工具的话不如直接用vLLM的offline batch模式，或者干脆用FastAPI自己实现个简单的动态batching，把并发控制在你显存能承受的范围，比盲目堆配置靠谱。

说实话max_num_seqs=256在3090上基本是个摆设，7B模型光权重就占14G左右，你还有KV cache要算，并发10个请求每个序列长度稍微一长，显存直接爆穿。我建议先把max_num_seqs降到32甚至16试试，这个参数不是越大越好，它决定了显存里能同时缓存多少条序列的KV，256这个值在24G卡上纯属找死。

另外gpu_memory_utilization调到0.8其实有点保守，3090有24G，你不如直接拉到0.92，给PyTorch留点碎片空间就行。但更关键的是检查一下你的请求长度，如果上下文都很长，比如每轮对话都带历史，那KV cache增长速度远超你预期，建议把max_model_len限制在4096或2048，能省出好几个G。

至于量化版本，我强烈建议试一下AWQ或者GPTQ的4bit，7B量化后权重只占4G左右，显存压力直接减半，而且VLLM对量化支持很成熟，精度损失在对话场景基本感知不到。不过要注意量化后吞吐会稍微降一点，但换来的是并发能力大幅提升，你这场景明显是并发优先。

拆多个副本我觉得没必要，3090跑7B单卡就够了，拆了反而增加显存碎片和调度开销，不如先优化单卡配置。最后提醒一下，OOM被Kill有时候不是显存问题，可能是CPU内存不够导致换页，你留意下系统日志是不是真被cgroup杀了。

说实话max_num_seqs=256这个值在3090上有点激进了，24G显存跑7B满血版本来KV cache就吃紧，建议先压到32试试。另外你gpu_memory_utilization调到0.8其实给显存留的余量不大，vllm的调度碎片加上torch的缓存很容易就爆了，可以试试0.7加--enforce-eager。如果还不行就别硬扛了，直接上AWQ或者GPTQ的4bit量化，3090跑7B量化后排并发能稳不少，单卡撑20个问题不大。

3090带7B本来就吃紧，max_num_seqs=256这个值对24G显存太激进了，实际并发10个的时候KV cache直接爆炸。建议先降到32试试，另外gpu_memory_utilization别拉满，留点给CUDA context和碎片。量化的话AWQ 4bit能省一半显存，但vLLM对AWQ支持有点小坑，实测GPTQ稍微稳一点。如果还不行，就拆成两个副本各占12G，用--tensor-parallel-size 1跑两个实例，比硬撑单实例强多了。

你这配置我熟，3090的24G跑Qwen2.5 7B本来就得精打细算。OOM八成是max_num_seqs设太高，每多一个seq就要额外分配KV cache，256个并发槽位直接把显存吃穿了，先砍到64看看。另外vLLM的continuous batching会动态申请显存，建议把--swap-space设成0，或者干脆换awq量化版，4bit下同样显存能多扛一倍请求。要是还不行，就上两个实例做负载均衡，成本比换卡低多了。

max_num_seqs设太高了，3090显存扛不住，先降到32试试，OOM大概率是这个。

3090就24G显存，跑7B满血版其实挺吃紧的，你max_num_seqs开到256等于给自己挖坑，并发一高KV cache直接爆。先降到32或者64试试，再把gpu_memory_utilization拉到0.9，大概率能缓解。另外可以看看是不是vllm版本太老，新版本对显存碎片管理好不少。实在不行就上AWQ或GPTQ的4bit量化，精度损失不大，但并发能翻倍。

3090也就24G显存，跑7B其实挺紧的，max_num_seqs=256这个值设太大了，实际并发10个就能把KV cache撑爆，建议先砍到32-64试试。另外gpu_memory_utilization=0.8不够激进，可以试试0.95，但得留点给CUDA context。

我之前也遇到过类似问题，后来发现是prompt长度波动大，长上下文请求会瞬间吃满显存，你可以把max_model_len限制一下，比如4096或2048，效果会好很多。

要是还不行，就上AWQ或GPTQ的4bit量化，显存占用能降一半，3090跑7B量化版带几十并发问题不大，速度损失其实可以接受。

别急着拆多副本，那玩意儿调度开销不小，单卡先把参数调明白了再说，我踩过坑。

max_num_seqs设太高了，3090带不动，砍到32试试，再上AWQ量化稳很多。

3090就24G显存，跑7B原版加长上下文确实紧，OOM不奇怪。你max_num_seqs调256太激进了，这参数不是越大越好，实际并发10个请求根本用不到这么多槽位，先降到32试试。另外gpu_memory_utilization 0.8其实已经把显存分光了，但KV cache还得吃内存，建议换个4bit量化版，AWQ或者GPTQ都行，显存占用能直接砍半。如果量化后还崩，再考虑拆两个VLLM实例，每个绑4个请求，总比一个进程被Kill强。

max_num_seqs调到32试试，3090显存扛不住256的，量化到4bit能稳不少。

3090也就24G显存，7B满血版硬上并发确实容易爆，max_num_seqs设256反而可能让显存碎片化更严重，先降到32试试。另外gpu_memory_utilization别拉太高，给KV cache留点余量，0.7左右更稳。如果还不行就上AWQ或GPTQ的4bit量化，显存占用能砍一半，精度损失对内部工具影响不大。单卡扛不住的话，不如直接拆两个副本挂负载均衡，比折腾一个进程省心。

这问题我上周刚踩过，3090就24G显存，max_num_seqs=256其实是给A100那种大卡准备的，你这并发10个就崩很正常。建议先降到32或者64试试，然后gpu_memory_utilization别调太高，留点给KV cache反而更稳。另外Qwen2.5 7B的BF16权重就快15G了，换AWQ 4bit量化能省一半多，实测并发能翻倍，不用拆副本。

3090也就24G显存，Qwen2.5 7B原生fp16光权重就占14G左右，加上KV cache和激活值，max_num_seqs=256这配置在3090上基本是给自己找事，这参数是给A100那种80G卡准备的。建议先把max_num_seqs压到32甚至16试试，同时把gpu_memory_utilization调到0.9，再不行就上AWQ或GPTQ的4bit量化，显存占用能砍一半多。另外你这场景如果单次推理延迟敏感，拆两个副本用ray跑也行，但3090单卡拆副本收益不大，优先优化调度和batch大小更实际。

你这情况我遇到过类似的，max_num_seqs=256看着是并发上限，但实际它决定的是单次batch能塞多少序列，显存不够时这值越大越容易爆。7B模型建议直接上int8或4bit量化，AWQ格式在VLLM里支持得挺好，显存占用能降到7-8G，剩下留给KV cache就宽裕多了。还有个坑是vllm默认会预分配显存，你可以把swap_space设成0，把内存换出去一部分。实在不行就把并发请求做排队，用FastAPI包装一层限流，比硬扛OOM省心多了。

3090跑7B并发10就OOM，

max_num_seqs调太高了，3090显存扛不住，先砍到64试试，OOM基本能解决。

说实话你这配置我太熟了，之前用3090跑7B也踩过一样的坑。max_num_seqs=256看着像预留了并发空间，但vllm实际会按这个值预分配KV cache，12G显存根本扛不住，尤其Qwen2.5的attention头数又多，建议直接砍到64或者32试试，吞吐不会掉太多。另外你说的gpu_memory_utilization=0.8其实有点保守，3090上跑7B可以试着干到0.92，但前提是把max_model_len也一起降下来，比如默认2048的对话场景就够用，长上下文才是显存杀手。还有个更直接的办法是上AWQ或GPTQ的4bit量化，我实测同样并发下显存占用能少一半还多，而且vllm对量化支持已经很成熟了，基本不损失精度。至于拆多副本，3090单卡就别想了，纯属给自己找麻烦，不如先检查下是不是paged attention没生效，有些老版本vllm要手动设enable_paged_attention=True，不然照样爆。最后提醒一句，OOM时看下是显存还是CPU内存，有时候是tokenizer或者post-processing的Python端瓶颈，把--enforce-eager打开能省不少显存。

3090跑7B并发10个就爆，max_num_seqs调小点试试，256太高了，设32-64稳得多。