部署开源大模型到生产环境，显存到底怎么算才靠谱？

这个坑我太熟了，INT4理论值确实容易误导人，因为模型权重只占一部分，KV Cache才是真正的显存大头。你上下文长度设到2048以上，加上batch size哪怕只设4，KV Cache就能吃掉2-3G，加上权重和激活值，7B模型实际跑起来8G显存都不一定稳。建议你直接用vLLM，它对显存管理比TGI更激进，会自动根据剩余显存动态调整KV Cache的分配，而且支持PagedAttention，能把碎片化显存利用起来。你的场景QPS不高但要求低延迟，vLLM的连续批处理很合适，甚至可以考虑把batch size设成1来保延迟，显存占用能压到5G左右。另外多卡部署的话，除非你模型实在塞不进单卡，否则别折腾张量并行，通信开销对延迟影响挺大的，单卡用vLLM加AWQ量化基本够用。还有个小技巧，你可以在vLLM启动时设--max-model-len限制最大上下文长度，比如只处理1024长度的文本，这样KV Cache能省一大半。要是还爆显存，试试GPTQ量化，虽然精度比AWQ稍差，但显存占用更稳定。

显存计算确实容易踩坑，INT4的理论值通常只算了模型权重，但KV Cache和激活值才是隐藏的显存大户，尤其是长文本场景。我试过vLLM，它对显存管理比TGI更激进，支持PagedAttention能动态分配KV Cache，但7B模型单卡跑长文本还是得留足余量。建议先用vLLM的--max-model-len和--gpu-memory-utilization参数压测，比如设0.85预留15%显存给batch和碎片，另外多卡部署时TGI的tensor parallelism对低延迟更友好，vLLM的高并发优势在QPS不高时反而可能增加延迟抖动。

显存这块我踩过类似的坑，关键是你漏算了KV Cache的占用，上下文长度一长这个吃得很凶，建议用vLLM的--max-model-len和--gpu-memory-utilization参数先手动限一下试试。框架的话低延迟场景vLLM比TGI稳，特别是配合PagedAttention，多卡部署也更省心。另外INT4量化建议用AWQ或者GPTQ，动态量化在推理时反而可能多占缓存，不如直接压静态的。

INT4量化后跑起来OOM太正常了，我之前也是被显存计算坑过，后来发现上下文长度和batch size才是大头，尤其是长文本摘要场景，随便开到2048 tokens，显存直接翻倍。vLLM和TGI我都试过，延迟敏感的话建议vLLM，它的PagedAttention在显存管理上更灵活，小batch下延迟控制得更好。多卡部署可以先试试单机张量并行，用vLLM的--tensor-parallel-size参数就行，省事很多。

算显存确实容易踩坑，很多人只盯着模型权重，忘了KV Cache和中间激活值才是大头。像Qwen2.5-7B这种，就算INT4量化后权重大概4-5G，但上下文长度拉到2048以上，KV Cache轻松吃掉2-3G，再加上batch size和CUDA context的固定开销，OOM太正常了。我建议你直接拿vLLM跑一下它的内存估算工具，它会把prompt和生成的显存分开算，比手工公式准不少。至于框架，低延迟场景我更推荐vLLM，它的PagedAttention对变长请求友好，而且最近更新的FP8支持能进一步压显存；TGI虽然生态成熟，但处理小batch时调度开销略高。另外，你这7B模型其实单卡3090或A10基本够用，但记得把max_num_seqs设小点（比如8），别让并发把显存撑爆。文本摘要这种任务，试试把输入长度限制在1024以内，输出控制在256，延迟能明显降下来。

显存估算得把kv cache算进去，我8B模型int4跑8k上下文，batch size设4直接吃了10G。