部署7B模型微调后推理变慢一半，是量化问题还是显存瓶颈？

vLLM加载LoRA确实有这个毛病，动态合并权重会打断连续的batch推理，尤其你max_model_len拉到4096，显存碎片化和KV cache重新分配的开销会进一步放大。我上次跑医疗QA也碰到类似情况，原版30 token/s，挂上LoRA直接腰斩，后来发现是vLLM对LoRA的底层实现不是走融合算子，而是每次前向都做一次显存拷贝，这个损耗在7B模型上特别明显。

你提到gptq量化，其实微调后的权重分布会偏移，4bit量化对偏移后的激活值敏感度更高，可能导致反量化操作变频繁，但这通常不会让速度掉一半，所以我觉得主因还是LoRA的调度开销。建议试试先别急着上生产，用官方脚本把LoRA权重merge回基座，再重新做一遍gptq量化，这样就能用普通vLLM加载，速度应该能回到20 token/s以上。如果必须动态加载多个LoRA，可以试试把max_model_len降到2048，或者用S-LoRA这类专门优化多LoRA推理的框架，但工程复杂度会上去。另外确认下vLLM版本，0.4.2之后的LoRA支持有性能修复，更新下说不定有惊喜。

大概率是LoRA动态合并的锅，vLLM对这块优化一般，试试把adapter固化进base权重再量化部署。

大概率是LoRA动态合并的锅，vLLM对QLoRA的支持本来就带额外调度开销，而且7B模型微调后激活分布变了，gptq量化矩阵的误差敏感度也会上升。可以试试把LoRA权重先合并进基座再量化导出，或者换AWQ看看速度有没有回升。我之前做医疗问答也遇到过类似情况，合并后推理能回到20 token/s以上，显存占用还低了一点。另外max_model_len如果业务允许，砍到2048说不定也能挤点性能出来。

vLLM加载LoRA确实会有额外开销，但你这速度直接砍半不太像纯动态合并的问题。我之前跑过类似的QLoRA微调模型，vLLM对LoRA的支持其实已经优化得不错了，除非你同时加载了多个LoRA adapter，否则单adapter的推理开销应该控制在10%-15%以内。你提到显存才用到14GB，说明模型本身没占满，所以更可能是量化敏感性问题——微调后的权重分布会偏移，GPTQ的校准矩阵是基于原版模型算的，对LoRA合并后的权重可能就不那么友好了，导致实际推理时出现更多的反量化或重计算。建议你试试把基座换成AWQ量化，或者用FP16基座直接推理（如果显存够的话），同时检查下vLLM的调度配置，比如把max_num_seqs调低点，或者确认下是不是prefill阶段变长了。另外有个骚操作，你可以把LoRA权重静态合并回基座，然后重新做一次量化，这样部署时就不走动态合并了，速度能回来不少，代价是牺牲一点灵活性。你那个法律问答场景如果业务变化不频繁，静态合并其实挺香的。