最近在用vLLM部署Qwen2.5-7B做内部demo，单卡A100 80G，模型用AWQ 4bit量化。平时单路请求挺流畅，但压测时并发到8左右，显存直接涨满然后OOM，日志里有“CUDA out of memory”。我已经设置了--max-model-len 8192，也开了--gpu-memory-utilization 0.9，但感觉还是不够稳。看了下nvidia-smi，好像KV cache占得特别凶，但我没手动调--max-num-seqs，这个是不是关键？还是说AWQ量化后显存占用模型本身还是太大，应该换成GPTQ或者干脆上8bit？另外，vLLM是不是对动态batch的显存预留机制有什么坑？求有经验的大佬指点下排查方向，或者分享下你们生产环境的类似配置。先谢过。
楼主
2026-08-12
vLLM部署Qwen2.5-7B，并发一高就OOM，是量化问题还是我参数没调对？
请 登录 后发表回复
全部回复
共 87 条
2楼
25天前
调大--max-num-seqs前先降--max-model-len，8192太吃KV cache了，压测8路根本扛不住。
3楼
25天前
你这情况大概率不是量化的锅，AWQ 4bit在A100上跑7B其实很轻。核心问题是vLLM默认max-num-seqs挺大的，并发一上来KV cache按seq数预分配，显存直接爆。建议先把--max-num-seqs压到4或8试试，再配合--max-model-len降一点，基本能稳住。另外gpu-memory-utilization 0.9已经偏高了，留点余量反而更稳，别死磕那个数。
4楼
25天前
先调 --max-num-seqs 限一下并发批次，KV cache 才是 OOM 主因，跟量化关系不大。
5楼
22天前
这个OOM大概率不是量化格式的锅，AWQ 4bit在7B模型上权重占用其实很小，真正吃显存的是KV cache随并发线性增长。你开了--gpu-memory-utilization 0.9只是告诉vLLM能用多少显存，但没限制它怎么分配，--max-num-seqs才是控制同时跑多少请求的关键，不设的话vLLM会按显存上限去塞，压测一上来自然爆。8192的max-model-len在并发8的时候KV cache开销相当可观，7B大概是每token每层几十KB量级，乘起来很容易把80G吃满。建议先把--max-num-seqs压到4或6试试，再配合--max-model-len降到4096看看曲线，基本能定位是不是KV的问题。换成GPTQ或者8bit不会解决并发问题，反而权重占用更大，方向反了。另外vLLM的动态batching确实会随着请求堆积不断扩张KV block，你可以看下日志里gpu_cache_usage那个指标，超过0.9就离OOM不远了。真要扛并发，要么加卡做TP，要么上chunked prefill和prefix caching这些省显存的开关。
6楼
22天前
你这个问题大概率不是量化的问题，AWQ 4bit 在 A100 上跑 7B 模型本身占不了多少显存，权重撑死也就 5-6G。真正吃显存的是 KV cache，vLLM 默认会按 gpu-memory-utilization 把剩下的显存几乎全预留给 KV cache，但 max-num-seqs 不设的话它会按一个比较激进的默认值去算并发块数，压测一上来请求排队，cache 块分配直接顶满就 OOM 了。你可以先把 --max-num-seqs 压到 4 或 6 试试，同时用 --max-model-len 配合看，8192 其实挺吃 KV 的，如果业务不需要那么长可以降到 4096。另外 vLLM 的调度是 continuous batching，并发高的时候 prefill 和 decode 混在一起，瞬时显存峰值比稳态高不少，所以 gpu-memory-utilization 0.9 在压测场景反而容易踩线，调到 0.85 留点余量更稳。换 GPTQ 或 8bit 意义不大，瓶颈根本不在权重精度上，先把 seqs 和 len 这两个调明白再说。
7楼
21天前
你这个问题大概率不是量化格式的锅，AWQ 4bit 在 A100 上跑 7B 模型本身占用很低，权重也就 5G 左右，真正吃显存的是 KV cache。并发一上来 vLLM 会按 max-num-seqs 和 max-model-len 预分配大量 KV block，默认 max-num-seqs 可能到 256，你设了 8192 的上下文，那每个序列预留的 cache 就很夸张，8 路并发直接把 80G 撑爆很正常。先别急着换 GPTQ 或 8bit，那个方向解决不了根本问题，反而权重更大。可以试着把 max-num-seqs 压到 16 或 32，同时把 max-model-len 降到实际业务需要的长度，比如 4096，再看 nvidia-smi 里 KV cache 的占用曲线。另外 gpu-memory-utilization 0.9 只是让 vLLM 尽量用满，不是限制它别 OOM，真正控制并发内存的是 block 数量和调度策略。还有个容易被忽略的点，压测工具如果没做流式消费或者客户端读取太慢，请求会堆积在 running 队列里，也会让 KV cache 迟迟不释放。建议先上 --max-num-seqs 和 --max-model-len 这两个硬约束，基本就能稳住，量化格式留到最后再考虑。
8楼
15天前
你这个问题大概率不是量化方式的问题，AWQ 4bit 在 A100 上跑 Qwen2.5-7B 其实挺轻松的，模型权重本身占不了多少，OOM 的元凶基本就是 KV cache。--max-model-len 8192 和 --gpu-memory-utilization 0.9 只是给了个上限，真正决定并发时显存峰值的是 --max-num-seqs，你不设的话 vLLM 会按默认值去批，默认往往偏大，8 路并发一上来 KV cache 就按最长序列预分配，80G 也扛不住。建议先把 --max-num-seqs 压到 4 或 6 试试，同时可以用 --block-size 调小一点，配合 --enable-chunked-prefill 让长 prompt 分块进，峰值会平滑很多。另外你说的动态 batching，vLLM 的 continuous batching 确实是默认开的，但它不会帮你省 KV cache 的空间，只是让 GPU 利用率更高，所以别指望它解决 OOM。真要压并发，还可以考虑把 max-model-len 降到 4096，或者用 --kv-cache-dtype fp8，A100 支持 FP8，能直接砍一半 KV 显存，代价是精度略掉一点，demo 场景完全够用。换 GPTQ 或者 8bit 意义不大，权重那点显存跟 KV cache 比是零头，方向搞反了。