用vLLM部署7B模型，单卡A100推理速度只有20tokens/s正常吗？

20 tokens/s对于7B模型来说确实偏低了，但先别急着怀疑量化，我怀疑你可能是被QPS这个指标误导了——vLLM的throughput在连续请求下和单请求延迟是两回事，你测的是不是单条prompt的生成速度？如果只是单流，A100跑7B大概也就这个水平，20多其实算正常范围。

另外你提到显存只占了14GB，这有点奇怪，A100有40G或80G，vLLM默认会尽量用满空闲显存来做KV cache，如果只吃14G说明gpu_memory_utilization可能设得太保守，或者max_model_len太小导致显存分配受限。我建议你把utilization调到0.9以上，然后看一眼实际KV cache的block数有没有打满。

至于docker，性能损耗基本可以忽略，除非你网络模式用了bridge影响并发连接，但推理本身不依赖网卡。我觉得你更该检查的是微调后的模型是否带了奇怪的自定义op，导致vLLM没法走优化kernel——你可以试试用未微调的原版Qwen2.5-7B跑一下对比，如果原版能到50+，那就是你模型代码或tokenizer的问题。

还有个小坑，如果微调时改了特殊token或bos/eos，vLLM的模板配置不匹配会导致每次生成都触发很长的系统prompt，直接拖慢速度。你可以抓一下实际输入的prompt长度，如果超过1k tokens，那20/s就很合理了。先按这个思路查，大概率能定位到问题。

docker跑vllm性能损耗很小，先查下是不是输入长度太长拖慢了prefill，短请求下再测测看。

20 tokens/s确实不太对劲，我拿A100跑Qwen2.5-7B开flash attention随便都能到40+。你docker部署理论上损耗很小，但先检查下容器里是不是没开共享内存，shm-size给太小会严重影响vLLM的调度。另外你提到显存只占了14GB，这很可疑，A100有40G，试下把gpu_memory_utilization拉到0.9以上，别让它有空闲显存。还有微调过的模型如果是用PEFT那套，得确认下合并权重后有没有残留的adapter配置，有时会莫名拖慢推理。建议先用原版模型跑个基准对比下，排除模型本身的问题。

20tokens/s确实有点低，先看看是不是并发请求太少或者batch没跑满，单请求速度参考意义不大。

20tokens/s确实低了，先看看是不是开了流式输出但实际在等整句，另外docker默认共享内存小也会拖后腿。

20 tokens/s确实偏低，先看看是不是输出长度拉太长了，或者docker没挂GPU直通。

20 tokens/s如果是单请求的话确实偏低了，我这边7B模型在A100上单跑一般能到50-70。你确认下是不是在跑并发压测还是单条请求？单条请求看的是decode速度，跟并发吞吐是两码事。另外docker里记得加--gpus all和--shm-size，共享内存太小也会拖速度，这个坑我踩过。

20 tokens/s确实有点低了，A100跑7B不该是这个数。你先确认下是不是每次请求的输出长度特别短，如果就几十个token，那瓶颈可能在调度和首token延迟上，不是纯算力问题。另外docker默认可能没挂共享内存，试试加--shm-size或者--ipc=host，这个坑挺常见的。还有你并发多少？单请求串行跑的话20很正常，vLLM的吞吐优势得靠batch堆出来。

20 tokens/s确实偏低了，A100跑7B不该这么慢。你确认下是不是每次只发一个请求测的？单请求下吞吐本来就不高，vLLM的优势得靠并发才能体现出来。另外docker默认可能没挂上GPU的全部算力，建议跑一下nvidia-smi看看利用率，顺便确认下dtype是不是fp16，bf16在A100上一般更快些。