vLLM部署Qwen2.5-7B，显存占用比预期高很多，正常吗？

显存占用高大概率是vLLM预分配了整卡显存，TP=2没生效可能和模型格式有关，试试加--enforce-eager。

实不相瞒我前几天刚踩过类似的坑，你这显存占用大概率是vLLM默认给每个request预留了很大的KV cache空间，而且7B模型就算int8实际权重也得9-10G，再加上CUDA graph和碎片，单卡22G真不算离谱。第二卡没用起来的话，检查下启动命令里有没有加--enforce-eager，还有环境变量CUDA_VISIBLE_DEVICES是不是只看到了单卡。速度20 tokens/s确实偏低，但tensor parallel在4090这种卡上因为NVLink带宽不够，有时候反而会拖慢，你可以试试单卡跑对比下。长上下文我体感SGLang在显存控制和调度上更稳一点，但vLLM生态成熟，如果你主要做短对话其实差别不大。

你这个问题我当初也踩过，先说结论：显存占用高大概率是正常的。vLLM默认会预分配KV cache，而且你设了0.9的利用率，它基本会把能用的显存都吃满，22G+不算离谱。真正的问题在tensor-parallel-size=2没生效——你得确认模型权重路径下有没有分布式的索引文件，或者启动日志里有没有报“rank”相关的警告，很多时候是两张卡之间通信没建立起来，导致第二张卡空转。另外20 tokens/s这个速度，如果是没开continuous batching且并发低，其实也说得过去，benchmark那种40+通常是高并发+prefill和decode分离优化过的结果，你可以试试加--max-num-seqs和--enable-prefix-caching。至于SGLang和vLLM，长上下文下SGLang的radix attention确实更省显存，但vLLM胜在生态稳，真要选我建议你先拿自己数据跑个压力测试，别光看benchmark。最后检查一下CUDA_VISIBLE_DEVICES是不是只设了一张卡，这个坑我遇到过两次。

22G是预先把权重和KV cache全塞进去了，TP=2要看下模型是否真的支持，速度瓶颈大概率在数据并行没生效。

你这情况挺典型的，vLLM默认会把gpu-memory-utilization当成显存池上限来预分配，不是按实际用量慢慢涨，所以你设0.9它两张卡各吃22G左右是符合预期的，并不是真的用满了。第二张卡没被利用，多半是tensor-parallel-size没生效，检查一下启动日志里有没有TP=2的字样，有些版本对--tensor-parallel-size的位置或者和环境变量冲突会静默忽略。速度只有20 tokens/s，如果batch size是1，那TP=2反而可能因为通信开销拖慢，单卡跑7B int8在4090上本来就能到40+，你可以先试试TP=1对比一下。KV cache那块，vLLM是按block预分配的，gpu-memory-utilization给太高就会把剩余显存全吃掉，实际并发不高的话调到0.7到0.8更合适。至于vLLM和SGLang，长上下文下SGLang的RadixAttention对前缀复用确实更友好，但vLLM生态和稳定性更成熟，看你更在意吞吐还是省心。

gpu-memory-utilization=0.9就是会预分配90%显存，跟你模型实际占多少没关系，vLLM是先把KV cache池子占满再说的，所以22G很正常。第二张卡没用上可能是tp没生效，看看日志里有没有报tensor parallel相关的东西，两张4090没有NVLink走PCIe通信也会拖速度。20 tokens/s确实偏低，不过4090跑7B如果没开chunked prefill、batch又小的话也差不多这数。长上下文我这边体感SGLang的radix cache更省显存一些，但vLLM生态更成熟，看你更在意哪头了。

gpu-memory-utilization=0.9本来就是按单卡总显存的90%去预分配KV cache，不是按模型实际需要多少来算的，所以你看到22G+完全正常。第二张卡没吃上大概率是tensor-parallel-size没生效，检查下启动日志里有没有TP=2的信息，或者模型是不是被判定成单卡能放下了。速度20 tokens/s偏低，先确认下是不是没开chunked prefill或者enable-prefix-caching，另外4090跑7B想上40+一般得看batch size和并发。长上下文这块SGLang的RadixAttention确实更省显存，但vLLM最近版本也不差，建议先用vLLM把参数调通再对比。

两张卡跑7B用tp=2其实有点亏，通信开销把收益吃掉了，单卡就能塞下的话直接单卡跑更划算。gpu-memory-utilization=0.9是预分配，vLLM一上来就把90%显存圈走当KV cache池，不是真占满，跟你理解的“按需占用”不一样，调小到0.7试试。速度20 tok/s偏低，看看是不是没开chunked prefill或者dtype没指定成float16。长上下文这块SGLang的RadixAttention确实更省KV，但vLLM的PagedAttention也不差，主要看你的并发和长度分布。

gpu-memory-utilization 0.9 就是让 vLLM 把每张卡 90% 显存都预留下来，22G 左右很正常，不是实际用量。第二张卡没吃上大概率是张量并行没生效，可以看启动日志里有没有 tp=2 的提示，或者模型本身没走到并行路径。速度 20 tokens/s 偏慢，建议先确认是不是在跑量化版本，fp16 的 7B 在 4090 上也就这水平。长上下文的话 SGLang 的 radix cache 确实更省显存，但稳定性两边都在快速迭代，建议自己压测一下再定。

两张4090跑7B其实有点浪费，tp=2反而可能拖慢速度，因为卡间通信开销在那摆着。你第二张卡没用上大概率是vLLM的tp没生效或者被CUDA_VISIBLE_DEVICES限制了。gpu-memory-utilization=0.9就是预分配90%显存给KV cache池，实际模型权重才占多少，剩下全被cache吃了，这跟你看到的22G对得上。想省显存就调低这个值，比如0.5-0.6，或者干脆单卡跑，7B int8单卡完全够。长上下文的话SGLang的RadixAttention确实更省KV，但vLLM现在也有prefix caching了，差距没那么大。

TP=2没生效大概率是没加--enable-tensor-parallel或者两张卡之间没走P2P，可以看下启动日志里有没有tp相关的信息。gpu-memory-utilization=0.9本来就是预分配90%显存给KV cache，你把它当实际占用看就误会了，调成0.7试试能降不少。20 tokens/s确实偏慢，先确认下是不是只跑在单卡上，双卡PP通信没配好反而更慢。长上下文这块SGLang的RadixAttention确实有优势，但vLLM现在也有prefix caching，日常用差别没那么大。

第二张卡没吃上显存，基本就是tp没生效，可以看下日志里world_size是不是还是1，有时候vllm版本和环境变量会坑你一把。22G单卡占用其实挺正常的，gpu-memory-utilization=0.9就是把卡几乎占满，不是按模型实际需求分配的，KV cache会把你给的额度全吃掉。速度20 tokens/s偏低，先确认是不是单卡在跑，tp=2正常能到40以上。长上下文我这边SGLang的radix cache确实更省显存一点，但vllm生态更成熟，看你要不要折腾了。

gpu-memory-utilization 0.9就是预分配90%显存，跟实际用量两码事。tp=2没生效可以看看日志里是不是走了单卡。

你这个显存占用其实挺典型的，vLLM 的 gpu-memory-utilization 不是“按需分配”，而是预分配一个池子，0.9 在 24G 卡上就是直接吃掉 21-22G 起步，跟模型实际权重多大关系不大。7B 就算 int8 权重才 7-8G，剩下的全被 KV cache block 和激活占掉了，你想压下来就把这个值调到 0.7 左右试试，或者干脆用 --kv-cache-dtype fp8。第二张卡没吃上，八成是 tensor-parallel-size 没生效，你确认下启动日志里有没有 “TP=2” 之类的字样，另外 4090 没有 NVLink，走 PCIe 做 TP 通信本来就不划算，7B 单卡完全跑得动，双卡反而可能因为通信拖慢。20 tokens/s 确实偏低了，看看是不是 batch 太小或者没开 chunked prefill，单请求 decode 速度跟吞吐是两码事。长上下文这块我个人感觉 SGLang 在 radix attention 和前缀复用上确实更省显存，但 vLLM 生态和稳定性更成熟，看你更在意哪头。

第二张卡没吃上显存，tp=2怕是没生效，查下启动日志里有没有报错吧。