大佬们，vLLM部署Qwen2.5服务老报OOM，是我配置有问题吗？

这问题我上周刚踩过坑，说几个可能的方向。你设的gpu_memory_utilization=0.9其实偏保守了，A100 80G单卡跑7B模型，很多人直接拉到0.95甚至0.98都没问题，但关键是Qwen2.5的kv cache显存占用比预期的狠，尤其是并发请求时prefill和decoding会抢显存。建议你先关掉所有并发，单条请求测一下实际显存占用，如果单条也报错，那可能是vLLM的版本问题——0.6.x之后有个显存碎片优化的改动，旧版本可能没处理好。另外tensor_parallel_size不用动，单卡设1就行，设错了反而会触发跨卡通信开销。swap空间不用调，那个是给CPU内存用的，和CUDA OOM无关。还有个冷门原因：检查下你的模型是不是用FP16加载的，如果默认用了FP32，显存直接翻倍。最后实在不行，试试把max_num_batched_tokens调小到2048，这参数控制一次处理的token上限，能缓解突发显存压力。

你这配置按理说跑7B模型应该很宽裕啊，单卡A100 80G跑4096长度都崩确实不太正常。我怀疑问题可能出在vLLM的预分配机制上，它默认会按max_model_len和gpu_memory_utilization的乘积来预留显存，但你设了0.9反而可能因为某些算子（比如长序列的attention）导致峰值显存超过阈值。建议先试试把gpu_memory_utilization降到0.7或0.8，同时检查下是不是开了多余的功能比如prefix caching或者triton attention，这些在高并发时容易吃显存。另外tensor_parallel_size单卡必须设成1，设多了反而会触发跨卡通信的显存开销。最后可以看看vLLM的日志里有没有“block manager”相关的warning，有时候是显存碎片化导致实际可用的连续块不够，这种情况调大max_num_seqs或者换用更激进的swap策略能缓解。你跑之前用nvidia-smi确认过其他进程没占显存吗？我上次就是被hidden的python后台坑过。

同样配置跑32K长度那个，我怀疑他可能开了连续批处理或者用了PagedAttention的默认显存分配策略，vLLM有个prefill阶段显存占用峰值挺高的，你设的gpu_memory_utilization=0.9其实已经留了10%余量，但如果是多并发请求同时触发prefill，显存会被瞬间打满。建议你试试把max_num_seqs调小一点，比如从默认的256降到32或64，这样能减少同时进入的请求数量。另外tensor_parallel_size单卡必须设成1，设成2反而会报错。swap空间那个选项是给CPU offload用的，对显存OOM没什么帮助，别折腾。还有一个隐蔽的点：Qwen2.5的attention实现默认用flash_attn，但你如果没装对版本或者编译参数不对，它会回退到原生实现，显存占用直接翻倍。最后检查下vLLM版本，0.6.0之后对Qwen家族有专门优化，旧版本可能有内存泄漏。

这个思路不错，收藏了。

按你描述的情况，感觉问题大概率不在tensor_parallel_size上，毕竟单卡A100跑7B模型不需要切分。可以试试把gpu_memory_utilization调到0.95，同时检查一下是不是Qwen2.5的预填充阶段显存开销比预期高，或者看看vLLM版本是不是太旧了。另外，如果开了长上下文窗口，建议显式设置--max-num-seqs为较小的值（比如8或16），能有效控制显存峰值。我上次遇到类似问题，调完这些后32K长度也能稳住了，你可以先试试这几个方向。

max_model_len设4096太保守了，试下调到2048或者gpu_memory_utilization降到0.8，可能显存碎片问题。

这配置跑7B应该够的，我猜问题可能出在max_model_len和gpu_memory_utilization的配合上。你试试把gpu_memory_utilization降到0.85，同时确保Qwen2.5的rope_scaling没被意外加载。另外vLLM的prefill阶段对显存有额外开销，如果并发请求多，建议先调小max_num_seqs或者加个—enforce-eager模式跑跑看。tensor_parallel_size单卡设1就行，别动这个。

试试把gpu_memory_utilization降到0.85，然后确认下是不是开了太多冗余的显存预留。

试试把gpu_memory_utilization调到0.85，然后检查下是否开启了prefix caching，这俩经常暗吃显存。

检查下vLLM的block大小和prefill chunk，调小点试试，或者把gpu_memory_utilization降到0.85看看。

这情况我遇到过，大概率不是tensor_parallel_size的问题，单卡不用设那个。你检查下vLLM的版本，0.6.0之后对Qwen2.5的支持有优化，老版本会有显存泄漏。另外gpu_memory_utilization可以试着降到0.85，留点余量给KV cache分配，32K能跑可能人家用了多轮对话的chunked prefill或者开启了prefix caching，你试试加上--enable-prefix-caching。还有别开swap，那玩意儿碰上OOM反而更慢。

一眼看过去，gpu_memory_utilization=0.9其实挺保守的，但max_model_len=4096按理说不该崩。建议先检查一下vLLM版本，老版本对Qwen2.5支持有bug，升到0.6.0以上再试试。另外你看下实际预留给KV cache的显存是不是被其他进程吃了，跑之前用nvidia-smi确认下空闲显存。tensor_parallel_size单卡设成1就行，别多设，swap空间一般不用动。

你这配置按理说跑7B不会这么惨，建议先检查下vLLM版本，老版本对Qwen2.5的显存管理有bug，升级到最新版试试。另外gpu_memory_utilization别开太高，0.85左右更稳，留点余量给KV cache动态分配。还有你那个tensor_parallel_size是1吧？单卡不用设，设了反而有可能吃更多显存。swap空间基本不解决这种问题，不如调低max_num_seqs或加个--enforce-eager参数看看。

我最近也踩过这个坑，说下我的排查思路。Qwen2.5-7B默认用bf16时单卡A100理论能塞下32K，但vLLM的显存分配其实比看起来更激进——gpu_memory_utilization=0.9不是留了10%给其他进程，而是给KV cache留了动态余量，但prefill阶段会临时申请更多显存。你试试先把max_num_seqs设小点，比如设成1或者2，排除并发时显存碎片的问题。另外tensor_parallel_size=1就行，单卡不用设，设错了反而会让模型并行分片多占显存。还有个小技巧：检查一下vLLM版本，0.6.x之后对Qwen的sliding window支持有bug，会导致显存泄漏，换0.5.5或者升级到最新版试试。swap空间就别调了，OOM本质是CUDA显存满了不是系统内存不够。你跑个单请求看看显存实际占用，如果单请求也爆那可能是max_model_len实际被padding了，改成2048先快速验证下。

感觉你这问题可能是prefill阶段显存炸了，Qwen2.5的7B模型实际吃显存比理论值要高一些，尤其是attention部分。建议先把gpu_memory_utilization降到0.8试试，另外确认下vLLM版本是不是最新的，老版本对长上下文支持有bug。至于TP，单卡没必要开，除非你用多卡。swap空间倒不用动，非量化模型硬伤就是显存。

检查下是不是Qwen2.5的默认prefill chunk大小太大了，试试调低gpu_memory_utilization到0.8。

检查下vLLM的block_size是不是默认16，改成32能省显存，另外Qwen2.5的attention计算挺吃显存，试试把max_num_seqs调小。

是不是开了prefill的dynamic batching？关掉试试，或者把gpu_memory_utilization降到0.85。

这情况我也踩过坑，先说结论：你单卡A100 80G跑7B模型，max_model_len设4096还OOM，大概率不是tensor_parallel_size的问题（单卡设1就行），而是gpu_memory_utilization和预留给KV cache的内存打架了。vLLM默认会把0.9的显存全部分给模型权重和KV cache，但Qwen2.5的attention层对显存消耗比想象中敏感，特别是并发请求一多，每个请求都要独立分配KV cache块，哪怕长度只有4K，batch size稍微大一点显存就爆了。

建议你先试试把gpu_memory_utilization降到0.75左右，给系统留点余量，同时检查一下是不是误开了--enforce-eager（这个模式会禁用显存优化）。另外你提到别人跑32K长度，他们大概率用了--max-num-batched-tokens或者启动时加了--block-size 16之类的小块策略，甚至可能用的是多卡TP分摊显存。你单卡跑的话，可以试试把max_num_seqs设小一点（比如4），同时确认日志里有没有“swap”相关的提示——vLLM的swap其实是个软交换，靠CPU内存兜底，但性能会断崖下跌，除非你实在没办法才开。

还有个很容易忽略的点：检查一下你启动命令里有没有--kv-cache-dtype设为fp8_e5m2？如果没开半精度KV cache，7B模型在4K长度下每个token的缓存开销是线性增长的，并发多了确实扛不住。你先调低memory utilization和batch size试试，应该能稳住。

你这配置按理说跑7B模型4K长度不应该崩，可能是vLLM的预分配策略把KVCache吃太狠了。试试把gpu_memory_utilization降到0.8甚至0.75，同时显式设置max_num_batched_tokens和max_num_seqs小一点，比如128和32，避免多请求时突发显存占用。另外检查下是不是启动了多个服务进程或者tensor_parallel_size>1，单卡不需要开TP。如果还不行，开个swap虽然不能根治，但能防止极端情况直接崩掉。