部署7B大模型到服务器，显存明明够却报OOM，有老哥遇到过吗？

遇到过，大概率不是量化的问题，vLLM对显存预分配很激进，默认会按最大并发预留KV cache，你那张卡上其他进程哪怕占几百兆，它也会直接判定OOM。建议先设gpu_memory_utilization=0.6试试，或者用vllm serve时加--kv-cache-dtype fp8，能省不少空间。另外你查下是不是CUDA_VISIBLE_DEVICES没设好，两张卡之间通信也要吃显存，单卡跑反而更稳。版本的话最近0.6.x确实有已知bug，换个0.5.5的稳定版说不定就通了。

vLLM默认会预分配整块显存，试试--gpu-memory-utilization设到0.8，八成是这问题。

我之前也卡这，把max_model_len调小点，KV cache占得比你想的多。

我之前也卡在这过，后来发现是vLLM的pre-allocate机制默认把显存吃满了，得设gpu_memory_utilization降到0.85左右。另外你没提模型路径是不是safetensors，有些合并模型带奇怪的分片会突然多占几个G。还有，两张卡之间通信也有开销，建议先用CUDA_VISIBLE_DEVICES=0单卡跑个最低配置试试，排除多卡同步问题。量化的话FP16够了，别急着换AWQ。

显存碎片和CUDA context占坑很容易被忽略，试试先开个空进程占满显存再加载模型，能缓解不少。

我以前也卡这过，后来发现是vLLM默认给每个序列预留的显存太激进，你把gpu_memory_utilization调到0.85以下试试，别让它吃到100%。另外7B在4090上其实没必要上双卡，单卡24G用FP16加4096上下文完全够，可能是你张量并行设置搞出了额外开销。还有个小坑，检查下是不是PagedAttention的块大小没对齐，新版本有时候默认值会抽风，换个0.6.3的稳定版试试。

之前跑7B也遇到过类似情况，最后发现是vLLM的默认torch.compile和CUDA graph抢占显存太猛，改成禁用或者调低gpu_memory_utilization到0.85就稳了。另外你检查下是不是pytorch的缓存碎片化，设个PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True试试，比清空显存管用。量化的话FP16没问题，别急着上AWQ，先排除这两个变量再折腾。

我之前也卡在这过，后来发现是vLLM默认会给每个序列预留挺大显存，光调max_num_seqs不够，得把gpu_memory_utilization设成0.9以下试试。另外你这双卡情况，确认下是不是张量并行把模型切得有问题，有时候单卡跑反而更稳。还有，别用最新版vLLM，我换回0.6.3就正常了，新版本对8系卡支持有点迷。

显存占用这个事儿挺玄学的，光看模型权重14G没用，vLLM默认会预分配不少CUDA context和显存池，加上paged attention的block管理，实际占用比你想的夸张得多。我之前跑8B模型，24G卡上开默认参数直接爆，后来把gpu_memory_utilization降到0.85才稳，你这双卡还得注意NCCL通信也要吃显存，单卡跑反而可能更省心。

另外你提到“全清空也只撑半分钟”，这感觉像是跑起来之后KV cache慢慢涨上去才崩的，不是启动瞬间爆的。可以试试把max_model_len调小，比如4096或者2048，别用默认的32K，Qwen2.5那个长上下文能力在vLLM里会疯狂占显存。GQA那块你调整过没？vLLM新版对GQA的优化有点迷，有时候反而会多分配几倍缓存，建议你直接锁num_heads=32试试。

至于量化方式，FP16本来就没毛病，但vLLM的FP16实现会额外开一个activation buffer，你要是用AWQ或者GPTQ反而可能省点。版本的话，我最近从0.6.3升到0.7.2也遇到过奇怪OOM，回退到稳定版直接好了，别追新。最后查一下是不是有僵尸进程占着显存没释放，torch_cache别清太干净，有时候重新加载反而更省。卡住很正常，我上次搞了三天才发现是BIOS里Resizable BAR没开，你慢慢排查吧。

vLLM新版本有个坑，试试降级到0.6.x，另外确认下是不是把两张卡都指定给模型了。

我之前也卡在过这步，后来发现是vLLM默认会预留一部分显存给torch的缓存池，你设个gpu_memory_utilization=0.9试试。另外7B模型跑起来实际占用比理论值大不少，尤其长上下文时KV Cache膨胀得厉害，建议先拿max_model_len=1024跑通流程再往上加。还有个小坑是两张卡之间通信也会吃显存，单卡反而更稳。实在不行换个老版本vLLM，新版有时候会搞些激进的内存预分配。

显存碎片化+context窗口默认开太大，试试--max-model-len砍到4096，能救一半。

试试把gpu_memory_utilization调低到0.85，vLLM默认会预吃到90%以上，跟别的进程抢就崩了。

遇到过类似的坑，问题多半不在显存总量，而是vLLM默认会预留一部分显存给KV cache和CUDA context，实际可用比你想的少。试着启动时加个--gpu-memory-utilization 0.85，强制限制占用比例，别让它自己全试一遍。另外两张卡的话，检查下NVLink和PCIe带宽，有时候跨卡通信反而会卡住导致OOM误报。量化方面建议先别动，FP16跑通了再考虑AWQ，不然排查起来更乱。你用的vLLM版本是多少，0.4.x和0.5.x在显存管理上差挺多的。

检查下vLLM的gpu_memory_utilization，默认会预留90%显存，调低到0.7试试。

试试把gpu_memory_utilization调到0.9，另外确认下是不是被别的进程抢了显存，我之前也踩过这坑。

我之前也栽在过这上面，后来发现是vLLM默认会把张量并行开起来，两张卡各分配一份模型权重，等于显存需求直接翻倍。你先试试--tensor-parallel-size 1强制单卡跑，或者干脆用transformers原生加载看能不能起来，先排除框架问题。另外你这7B如果是FP16，光权重就14G，但KV Cache加上CUDA context和碎片，24G单卡其实很紧张，建议开--max-model-len降到2048，再不行就换AWQ量化版，4bit大概7G，稳得很。

这问题我上个月刚踩过坑，你大概率不是vLLM版本问题，而是显存碎片化加上预分配策略的锅。vLLM默认会按max_num_seqs和max_model_len预先申请一整块连续显存，即便你设了GQA，KV Cache的预留空间还是按最大序列长度算的，7B模型实际峰值很容易超过20G。我之前用单卡跑7B，max_model_len设4096，结果它直接给我预留了18G的KV空间，再加上权重和激活值，24G卡直接炸。你试试把max_model_len强制降到2048，然后vLLM里有个--gpu-memory-utilization参数，给它调成0.85以下，别让它自动占满。另外检查下是不是有CUDA context没释放，比如torch或者tensorflow的残留进程，用fuser -v /dev/nvidia*查一下。还有一个反直觉的点，两张卡跑反而更容易OOM，因为张量并行会复制一部分中间激活，如果代码里没开--tensor-parallel-size 2，默认单卡跑反而更稳。实在不行就换llama.cpp的GGUF量化版，Q4_K_M才5G显存，虽然慢点但绝对不崩。

显存碎片化加CUDA context吃显存，试试先设CUDA_VISIBLE_DEVICES=0再用--gpu-memory-utilization 0.9锁死比例。

大概率是vLLM预分配显存策略的问题，试试把gpu_memory_utilization调到0.8，别让KV Cache吃满。

我之前也踩过这坑，vLLM对显存的预分配比想象中激进，尤其新版本默认会预留一部分做显存池，可以试试设置--gpu-memory-utilization到0.85，别用默认值。另外检查下是不是CUDA版本和pytorch不匹配，我换到11.8之后就没再莫名其妙OOM了。还有个小建议，先跑个最简单的加载测试，排除模型文件损坏的可能。