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

这个坑我太熟了，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。

显存计算确实容易踩坑，除了模型权重，KV cache和中间激活值才是大头，尤其长文本场景下显存会暴涨。我之前用vLLM部署7B模型，INT4量化配合动态batch，8G单卡跑128上下文勉强够用，但开长文本直接跪。延迟敏感的话试试TGI的continuous batching，比vLLM省显存但吞吐低点。建议你实测时把max_num_seqs和max_model_len调小，先拿一个样本跑通再慢慢加压力。

INT4算5-6G其实是静态权重占用的理论值，但实际跑起来attention的KV cache才是大头，尤其你上下文一长直接翻倍。我之前用7B模型做摘要，8K长度+4的batch size，INT4下实测要9-10G才稳。框架的话，延迟敏感建议用vLLM，它那个PagedAttention对显存管理更精细，TGI虽然方便但内存碎片多一点。多卡部署记得调tensor parallelism，单卡不够就拆两层，别直接全塞一张卡上。

这坑我也踩过，INT4理论值确实容易忽略attention cache和中间激活值，尤其上下文拉到2048以上时，显存会肉眼可见地涨。我自己的经验是，7B模型INT4量化后想稳定跑，至少要留8G余量，然后上下文长度按每token约2M算额外开销。vLLM和TGI我最后选了vLLM，它对连续批处理和显存管理优化得更好，延迟也低，不过得注意PagedAttention的配置参数，调不好反而会多占资源。你要是QPS不高但求低延迟，可以试试把max_num_seqs设小点，牺牲点吞吐换速度。

显存大头其实在KV cache，batch size开1试试，vLLM对低延迟更友好。

INT4量化那个公式确实容易踩坑，实际显存还得把kv cache和激活值算进去，我试过同样7B模型，序列长度拉到2048时INT4能吃掉快8G。vLLM和TGI我推荐vLLM，它的paged attention对长文本友好，延迟也更稳，多卡部署直接上tensor parallelism就行。建议你先把batch size压到1跑通，再慢慢加，不然OOM排查起来很头疼。

说实话你碰到的问题太典型了，INT4算出来5-6G那是理论权重占用的理想状态，实际部署时KV Cache才是吃显存的大户，尤其上下文长了以后。我之前试过7B模型，sequence length设到2048的时候，batch size哪怕只有1，KV Cache也能吃掉接近2G，你跑OOM大概率是这块没算进去。vLLM和TGI我都跑过，如果你对延迟敏感的话建议优先vLLM，它对PagedAttention的优化在长上下文场景下显存利用率明显比TGI高，而且动态batch处理小请求时延迟也更稳。不过vLLM对量化格式支持没那么全，AWQ或者GPTQ的兼容性得提前测一下。另外你QPS不高的话，可以试试把max_num_seqs设小一点，比如4或者8，配合vLLM的抢占式调度，能压住显存峰值。还有个小技巧，如果你用多卡，vLLM的tensor parallelism比pipeline parallelism更适合低延迟场景，不过记得显卡间带宽要够，PCIe 4.0 x16以上最稳。

显存大头其实在KV cache，batch size设小点用vLLM试试，延迟能压下来。

显存大头其实是kv cache，你算模型参数时漏了这个，7B模型4bit量化加8k上下文至少得再加2G。

显存这个坑我也踩过，INT4理论值确实容易忽略kv cache和中间激活，尤其你上下文拉到2k以上，那部分能吃掉将近1-2G。建议先用vLLM的--max-model-len参数压一下上下文长度，再观察实际占用，batch size就设1跑跑看延迟能不能接受。TGI和vLLM我偏向vLLM，它对连续批处理和PagedAttention优化得更彻底，低延迟场景下首token速度会好一些。

vLLM对长上下文支持更好，记得把预填充和显存预留也算进去，光算模型权重容易翻车。

INT4实际跑起来还要算上KV Cache和CUDA context，预留至少8G才稳，vLLM对长文本支持更好些。

显存这块我踩过一样的坑，INT4理论值确实容易忽略KV Cache和中间激活值，建议直接用vLLM的--max-model-len和--gpu-memory-utilization参数跑一遍压力测试，它会自动告诉你实际占用。文本摘要的话vLLM延迟控制比TGI好一些，特别是用PagedAttention能省不少显存碎片。多卡部署可以试试张量并行加流水线并行混搭，QPS不高的话单机双卡用vLLM的TP=2应该够用，记得调低--max-num-seqs防止突发OOM。

int8其实比int4稳得多，显存翻倍但省心，vllm对长文本支持更友好。

INT4跑7B模型，batch size设1、上下文2k以内才稳，vLLM对长文本更友好。