vLLM部署Qwen2.5-7B，并发一高就OOM，是量化问题还是我参数没调对？

max-num-seqs确实关键，试试调低到4或8，KV cache就不会爆了，AWQ本身没问题。

这波大概率是max-num-seqs没限制，并发8时KV cache直接吃满，调成4再压测看看稳不稳。

试试把--max-num-seqs调小到4，另外gpu-memory-utilization降到0.85留点余量，OOM大概率是动态batching把KV cache撑爆了。

显存涨满大概率是max-num-seqs没控住，默认值在并发上来后会把KV cache撑爆，你可以先把它压到16甚至8试试，A100跑7B量化模型其实很宽裕。AWQ本身没问题，GPTQ同精度下占用差不多，不用折腾换格式。另外vLLM对动态batching的显存预算是按最大可能seq len算的，你max-model-len设8192的话每个seq的KV cache预留就很大，建议把max-num-seqs和max-model-len一起调，比如把model-len降到4096看看。

max-num-seqs确实得手动调，vLLM默认会按模型和显存算一个值，但并发一高它就可能把KV cache撑爆。你试试设成4或者8，同时把gpu-memory-utilization降到0.85留点余量。AWQ本身占用不大，问题大概率在KV cache的预分配策略上，跟GPTQ还是8bit关系不大。另外你压测的时候可以留意下vLLM的日志，看它有没有提示KV cache的剩余量，那个比nvidia-smi更直观。

这问题我踩过一模一样的坑，A100 80G跑7B AWQ按理说绰绰有余，问题大概率不在量化格式上。你设了mem-util 0.9但没动max-num-seqs，vLLM默认会按这个比例给KV cache预分配，并发8时每个序列的context窗口都撑到8192，显存直接就被预分配吃满了，这时候模型权重反而只占一小部分。建议先把max-num-seqs压到4试试，同时把--block-size调成16甚至8，vLLM的page管理粒度越细，碎片化越少。另外AWQ和GPTQ在7B这个规模上显存差距很小，换8bit只会更糟，没必要。真正关键的是看你的实际输入长度，如果压测时每个请求的prompt都很长，那8192的max-model-len就太浪费了，可以按真实分布砍到4096或2048，能省出一大块KV cache。还有个骚操作是开--enable-prefix-caching，如果压测请求有公共前缀，能显著降低重复计算。我猜你OOM日志里应该还有vLLM的警告提示实际KV cache需求，下次可以先观察下那个数字再调参。

max-num-seqs确实是个关键参数，默认值可能是64，并发8时每个seq能分到的显存就很小，KV cache自然会爆。你可以先试着把它调到16或8，再配合gpu-memory-utilization 0.85看看，我上次跑7B就是这么压下来的。另外AWQ在vLLM里对长上下文的显存优化不如GPTQ，但你这场景4bit应该够，问题大概率还是batch策略没调好。动态batching其实vLLM默认开着，但并发高时它不会主动限制seq数量，反而会拼命塞请求，所以你得手动卡一下上限。

max-num-seqs确实关键，默认值在并发高时会把KV cache撑爆，建议按显存余量手动调小试试。

AWQ本身没问题，你这配置跑8并发应该够，重点还是得限制batch大小和KV cache预留。

max-num-seqs确实得手动控，我调到4后并发稳多了，另外KV cache可以试试设个上限。

把max-num-seqs降到4或者8试试，AWQ本身没问题，你gpu-memory-utilization给太高反而容易爆。

这问题我踩过一模一样的坑，--max-num-seqs确实得手动调，vLLM默认值对7B来说太激进了，并发一高KV cache直接爆掉，建议先压到16试试。AWQ本身没问题，但你这情况模型权重占比其实不大，大头全在KV cache上，换GPTQ或者8bit解决不了根源。另外--gpu-memory-utilization 0.9留的余量还是不够，可以试着降到0.85，配合--max-num-seqs一起调，再把--swap-space设个8G左右，应该能稳不少。动态batch这块vLLM会自动做，但前提是显存预算得给它留够，不然反而会触发频繁的抢占和重算，更吃资源。

max-num-seqs确实是个关键点，默认值可能偏大，并发8时每个序列分到的KV cache预算被摊薄了，试试降到4或6，配合gpu-memory-utilization调低到0.85看看。AWQ 4bit在7B上模型权重只占4-5G，按理说不是瓶颈，OOM大概率是KV cache预分配和动态batch膨胀的锅。另外你max-model-len设8192但实际对话长度可能远达不到，可以考虑动态长度限制或者用--kv-cache-dtype fp16看看。如果压测场景长上下文多，GPTQ的显存效率不一定比AWQ好，建议先调参数再换量化。

你这个问题我前几天刚踩过类似的坑，先说结论：max-num-seqs大概率是关键，但也不全是它的锅。vLLM默认会按max-num-seqs和max-model-len预估KV cache空间，你只设了max-model-len 8192，但没限制并发序列数，它可能为了吞吐把显存预分配拉满，到8并发时实际KV cache膨胀速度远超你预期。AWQ 4bit本身模型权重只占大概4-5G，理论上A100 80G绰绰有余，所以问题不在量化位数，而是你给KV cache留的余量不够。我建议你把max-num-seqs压到4或者6试试，同时把gpu-memory-utilization降到0.85，给CUDA context和碎片留点缓冲。另外动态batching确实会加剧显存峰值，因为vLLM会拼命往一个step里塞seq，你可以考虑加--enable-prefix-caching看能不能复用公共前缀的KV，减少重复计算。至于换GPTQ还是8bit，我觉得没必要折腾，AWQ在7B上效果已经够用，OOM跟量化格式关系不大，除非你怀疑是量化kernel的临时缓冲问题，但那一般不会直接爆显存。最后建议你开--max-num-batched-tokens，比如限制在4096，强制它分小批，牺牲一点吞吐换稳定，demo阶段完全够用。

max-num-seqs确实得调，8并发按默认值算KV cache直接爆，建议压到4试试。

max-num-seqs确实是关键，默认值在vLLM里会根据模型和显存自动算，但并发8的时候每个序列的KV cache加上激活值很容易把预算吃满。你开了gpu-memory-utilization 0.9，但vLLM预留的KV cache池可能没按你的并发需求分配，建议手动设成8或者16试试，同时把--max-num-batched-tokens也调低点，比如4096，这样能强制限制单次前向的token总量，比只调max-num-seqs更直接。AWQ 4bit本身不是问题，Qwen2.5-7B量化后权重才4-5GB，显存大头全在KV cache和中间激活上，换成GPTQ或者8bit只会更糟，除非你换更小模型。另外，你提到动态batch，vLLM默认就是continuous batching，但压测时如果序列长度波动大，显存碎片化也可能触发OOM，可以试试--enable-chunked-prefill，把长prompt切成chunk处理，能明显降低峰值显存。还有个小坑，nvidia-smi看到的显存占用可能包含CUDA context和碎片，实际可用比你看到的低，0.9的利用率在A100 80G上等于留了8G余量，按理说够，但如果日志里显示“free memory不足”，那就说明是KV cache预留策略太激进，优先限制max-num-seqs。你可以先跑个单请求，看vLLM启动日志里KV cache分配的显存大小，再反推并发8需要多少，手动配比默认值更稳。

max-num-seqs确实得手动调，默认值吃显存很猛，我压到4就稳了。

另外AWQ4bit模型权重不大，瓶颈全在KV cache，建议开--enable-prefix-caching试试。

这问题我上次也踩过，--max-num-seqs确实得手动调，默认值在并发上来后会把KV cache撑爆，A100 80G跑7B其实容量很富裕，但vLLM动态batch的显存分配策略有时候就是很激进。另外AWQ本身没问题，4bit和8bit在显存占用上差距没你想的那么大，重点还是seq数量控制。你可以试试把--max-num-seqs压到4-6，再把--gpu-memory-utilization降到0.85，给torch和CUDA context留点余量，应该能稳很多。

max-num-seqs没调确实是个隐患，vLLM默认值在并发上来时会一次性塞太多请求进batch，KV cache直接爆掉，建议先压到16甚至8试试。另外AWQ 4bit本身没问题，但Qwen2.5的GQA结构在长上下文下KV cache开销比想象中大，你max-model-len设8192但实际输入如果普遍偏长，那0.9的utilization也会被吃穿。我之前遇到类似情况是把gpu-memory-utilization降到0.85，同时配合max-num-seqs=8，压测就稳了。你还可以看看是不是prompt里塞了太多历史对话，动态batching对这类场景的显存波动很敏感，最好统计一下实际输入token分布再调。

说实话这问题我上周刚踩过一遍，最后定位到就是max-num-seqs没动。vLLM默认会按并发请求数动态分配KV cache，但8并发时每个seq的预分配空间会指数级膨胀，尤其你max-model-len拉到8192，单条KV cache峰值能飙到1.5G以上，8条直接吃满。AWQ量化模型本身权重只占4-5G，但KV cache不吃量化这套，所以瓶颈肯定在序列长度和batch size的乘积上。

建议你先试试把max-num-seqs锁到4，同时把gpu-memory-utilization降到0.85，给PyTorch留点碎片缓冲。另外别迷信动态batch，vLLM的continuous batching在并发突变时反而容易触发显存碎片化，我这边固定max-num-seqs后压测20并发都没再OOM，只是延迟从80ms涨到140ms，但稳定多了。

至于GPTQ还是8bit，我觉得问题不在量化格式，你AWQ在单路请求下吞吐已经不错了，换成GPTQ大概率一个样。真要降显存，试试--kv-cache-dtype fp8，A100支持这个，KV cache直接砍半，代价是长文本下精度有轻微抖动，但内部demo完全够用。另外确认下你的vLLM版本，0.6.3之前有个显存泄漏bug，升级到0.6.6+能缓解不少。最后问下你压测用的什么工具？我之前用wrk开长连接也触发过类似问题，换Locust的keep-alive模式就正常了。

max-num-seqs确实是关键，并发8意味着vLLM默认会尽量把8个请求的KV cache都塞进显存，配合0.9的utilization很容易爆。我之前跑13B模型也遇到过，手动限到4或6，同时把block size调小点，OOM概率直接降一大截。AWQ本身没问题，7B量化后模型权重才5G左右，大头都在KV cache上，所以换GPTQ或8bit解决不了这个。你试试--max-num-seqs 4加--swap-space 8，应该能稳不少。另外动态batching对显存峰值影响很大，建议压测时观察下请求到达的分布，是不是突发集中导致的。

说实话你这个问题我踩过一模一样的坑，A100 80G跑AWQ 4bit的7B模型，理论显存完全够，但并发一上来就炸，大概率不是量化位宽的问题。--gpu-memory-utilization 0.9这个参数只是告诉vLLM最多能用90%显存，但实际上KV cache会优先抢占剩余空间，你设了max-model-len 8192，每个seq的KV cache计算下来比想象中要肥不少，8并发直接顶爆很正常。关键确实在--max-num-seqs，我建议你把它显式设成4或者6，再配合--max-num-batched-tokens限制一下单batch的总token数，让vLLM的调度器别一次性塞太多请求进显存。另外AWQ和GPTQ在7B这个规模上显存差异很小，换8bit反而可能更慢，没必要折腾。我自己的经验是，如果压测场景是短文本多请求，可以把--max-model-len降到4096试试，KV cache占用直接砍半，对内部demo来说基本没感知。还有个小技巧，开--enable-prefix-caching能复用公共前缀的KV，如果你demo里的prompt有固定模板，并发OOM能缓解一大块。但话说回来，8并发就OOM确实有点反常，你要不要看下是不是vLLM版本太老，老版本对于KV cache的预分配策略很笨，升级到0.6.x之后动态batch和显存管理会聪明太多。

max-num-seqs确实得手动看下，默认值在并发高时会疯狂堆积请求，KV cache直接爆掉。AWQ本身没问题，但7B模型4bit也就省一半多，真正吃显存的是长上下文下的KV cache，建议先把它调到4或8试试，配合gpu-memory-utilization降到0.85留点余量。另外动态batching在vLLM里是自动的，但并发高时每个seq的显存分配是固定的，你如果压测场景都是短文本，其实可以试下把max-model-len改小到4096，效果可能比换量化更直接。