最近在折腾基于vLLM的本地部署,用的Qwen2.5-7B,单卡A100 40G。单轮推理没问题,但一旦做连续对话(比如保持5轮以上历史),显存就蹭蹭往上涨,最后直接OOM。查了官方文档,试了调整max_num_batched_tokens和gpu_memory_utilization,好像效果不明显。
有没有老哥遇到过类似问题?是不是需要对历史对话做显存回收,或者vLLM本身有什么参数控制历史缓存?另外,我看到有人提到flash attention能省显存,但我这个版本好像默认就启用了?
求大佬指点,实在不想每次对话都重新加载模型…
楼主
2小时前
vLLM部署Qwen2.5-7B,连续对话总是显存溢出怎么办?
请 登录 后发表回复
全部回复
共 1 条
2楼
1小时前
遇到同样的问题,A100 40G跑Qwen2.5-7B连续对话确实容易爆,这跟vLLM的PagedAttention机制有关——它虽然按页管理KV cache,但历史轮次一多,cache累积起来还是会吃满显存。你调的max_num_batched_tokens其实主要影响批处理时的预填充,对历史缓存的释放帮助不大。我试过把gpu_memory_utilization降到0.75,同时手动限制max_num_seqs=1,稍微好一点,但超过8轮对话还是会崩。
有个取巧的办法:在每次新对话前用vLLM的abort_request接口强制清空当前request的KV cache,相当于手动回收历史。或者更粗暴一点,在连续对话时通过修改sampling_params里的max_tokens来限制单次生成长度,避免无意义的缓存膨胀。另外你提到flash attention,vLLM新版确实默认启用,但它优化的是计算效率而非显存总量,对KV cache的压缩效果有限。
我后来换了个思路,用vLLM的LoRA切换功能,把历史对话拆成多轮独立的LoRA适配层,每轮只加载当前需要的权重,虽然麻烦点但显存稳定在32G以内。不过如果你坚持用全量模型,建议试试把历史对话的embedding定期做一次平均池化然后丢弃原始token序列,vLLM好像没有内置这个功能,得自己写个wrapper。最后问下,你用的vLLM版本是0.6.x还是0.7.x?不同版本对cache回收的处理差异挺大的。