各位大佬，小弟最近在实验室的A100 40G上试着用vLLM部署Qwen2.5-7B-Instruct做推理服务。单条请求测着都挺正常，但用locust模拟到大概20个并发的时候，服务就直接报CUDA out of memory崩了。我启动命令里设置了--gpu-memory-utilization 0.9，--max-model-len 4096，--tensor-parallel-size 1。看日志显存确实快满了，但感觉7B模型不该这么吃显存啊。是不是我max-num-seqs没设对，还是block_size这些参数需要根据并发调？有没有有经验的老哥指点一下，这种情况下一般怎么排查和调参？跪谢！
楼主
20天前
刚用vLLM部署了Qwen2.5-7B，并发一高就OOM，是我参数没调对吗？
请 登录 后发表回复
全部回复
共 3 条
2楼
18天前
20并发就OOM确实有点快，A100 40G跑7B按理说没那么紧张。你那--gpu-memory-utilization 0.9基本把显存吃干了，KV cache一涨就没余量了，建议压到0.85左右。max-num-seqs默认好像挺大的，高并发时KV cache爆得飞快，直接限到16或32试试。另外max-model-len 4096如果实际请求没这么长，调小点也能省不少显存。
3楼
18天前
A100 40G 跑 7B 确实不该这么容易炸，问题大概率出在 KV cache 的并发峰值上。vLLM 默认的 max-num-seqs 是 256，你 20 并发一上来它可能直接把一堆请求塞进 running batch，每个序列按 max-model-len 4096 预留 KV 空间，7B 的 GQA 虽然省，但 40G 卡扣掉权重和激活，留给 KV 的余量其实没想象中大。gpu-memory-utilization 0.9 意味着 vLLM 会尽量把显存吃满来放 KV block，日志显示快满反而是它的正常行为，真正崩的是 block 分配不过来时的抢占失败。你可以先把 max-num-seqs 压到 16 或 24 试试，再配合 max-model-len 降到 2048 看并发能撑到多少，基本能定位是不是 KV 预留的问题。另外 block_size 默认 16 一般不用动，改大反而浪费；enable-chunked-prefill 开了对长 prompt 并发更友好。还有个容易忽略的点，locust 如果用默认的 keep-alive 短连接猛打，请求堆积速度会超过 vLLM 的调度回收速度，加个固定并发上限或者用 asyncio 客户端会更贴近真实场景。实在不行就上 AWQ 或 GPTQ 量化版，40G 上 7B 跑 4bit 能把 KV 空间翻一倍多，20 并发轻松得很。
4楼
15天前
A100 40G跑7B其实挺宽裕的，问题多半出在vLLM默认的max-num-seqs（一般256）上，20并发时它会拼命塞满batch，KV cache一膨胀显存就炸了。你可以试着把它压到32或者64，再配合gpu-memory-utilization降到0.85左右，留点余量给CUDA上下文。另外max-model-len 4096如果是按最长预估的，KV cache占用会很猛，实际请求短的话调小点也能省不少。