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

显存这账真不能只按权重算，KV cache才是隐藏大户，尤其你文本摘要输入输出都不短，7B模型INT4下8K上下文随便就吃2-3G。建议用vLLM，它自带显存监控，PagedAttention能把KV cache利用率拉高不少，先跑个小batch试出真实峰值。多卡的话TGI部署更省心，但vLLM对QPS不高场景延迟优化更极致，你这需求直接单卡A10或L20试试，别急着上多卡。

显存这块我踩过一样的坑，公式算的只是权重，KV cache才是隐形杀手，尤其你文本摘要场景输入输出都不短，建议直接按最大序列长度算一下，7B的int4加8k上下文，batch size给1，预留个10G比较稳。框架的话，vLLM对显存管理更省心，TGI的延迟控制更细，但你QPS不高，我推荐先试vLLM，paged attention对长文本友好很多。另外别忽略CUDA context本身也吃几百M，多卡的话优先张量并行，别用流水线并行，通信开销小很多。

显存这事儿我踩过一样的坑，公式算的只是权重，KV cache才是大头，尤其你摘要场景输入输出都不短。建议直接按最大上下文先预留个2-3G，再用vLLM的--gpu-memory-utilization参数让它自己算，比手动估靠谱多了。框架选型的话，延迟敏感就vLLM，TGI现在优势不大了，连续批处理在低QPS下反而有点浪费。另外多卡的话优先考虑张量并行而不是数据并行，虽然7B单卡勉强能塞，但留点余量给长文本爆发会稳很多。

显存这块我踩过一样的坑，你漏算的是KV cache和激活值，7B模型INT4权重确实只要5G左右，但上下文一长，KV cache能吃掉好几G，建议直接按峰值token数乘层数乘隐藏维度再乘2字节来粗算。框架的话，低延迟就无脑vLLM，TGI的continuous batching在长上下文下更稳，但QPS不高的话其实差别不大。你这场景建议先固定max_length=2048试跑，把prefill和decode分开看显存，实测比任何公式都靠谱。

显存这块我踩过一样的坑，公式算的只是权重，KV cache才是隐藏大头。你文本摘要如果输入长文本，7B模型INT4量化后建议直接按8G+预留，batch设1试试。框架的话，低延迟场景vLLM的continuous batching更稳，TGI在量化兼容性上稍好，但你这需求直接vLLM就行。另外多卡部署别用tensor parallel，7B模型单卡就能跑，优先把显存余量堆上去。

显存大头其实在KV cache，7B满血部署至少留12G，建议直接上vLLM开paged attention。

显存这坑我太懂了，公式算的只是权重部分，KV cache和激活值才是隐藏杀手。你试试把max_seq_len设成实际业务最长长度，别按模型默认的2048算，光这块就能差出2-3G。vLLM对连续请求的批处理确实省显存，但如果你QPS不高，TGI的延迟会更稳一些，建议拿同样的prompt压测下看首token时延。

还有个野路子，用flash-attention能省不少KV cache，配合paged attention的vLLM，7B模型INT4在单张3090上跑过8K上下文是没问题的。你那个OOM多半是预分配缓存设太大了，调低gpu_memory_utilization参数试试，0.85起步慢慢往上加。

公式算的只是权重本身，KV cache和中间激活才是大头，你文本摘要如果输入长，KV cache轻松吃几个G。我上次跑7B INT4，context设4K，batch 1，实测峰值8G多，建议你直接按权重+context层数2*字节数来粗估。框架的话，延迟敏感就vLLM，TGI的continuous batching在某些卡上调度更稳，但你这QPS不高其实差别不大，先拿vLLM试，OOM就降并发或换AWQ。

公式算的只是权重本身，KV cache那部分才是大头，你7B模型就算INT4，上下文拉到2K以上batch一到8基本要吃4-6G额外显存，建议直接用vLLM的--max-num-seqs限制并发然后看它启动时打印的显存预估。框架我两个都试过，TGI对Qwen支持更省心，vLLM调优空间大但坑也多，你延迟敏感的话建议先用TGI的continuous batching跑个benchmark。另外多卡部署别直接tensor parallel，7B单卡能塞下就优先单卡，跨卡通信那点延迟对摘要这种任务真不值当。

显存这块我当初也栽过跟头，光算权重没用，KV cache才是隐藏大户，特别是长文本摘要场景，上下文一拉长直接翻车。你按公式估的时候得把max_seq_len和并发数乘进去，建议直接拿实际数据压测一轮，比啥公式都准。框架的话，低延迟选vLLM没错，TGI在动态batch上更灵活，但你QPS不高的话其实vLLM够用了，记得开continuous batching。另外INT4别光看显存，还得看推理速度，实在不行就上AWQ量化，比GPTQ稳一点。

Qwen2.5-7B的KV cache按层数×头数×维度×长度×batch算，公式里漏了它就必OOM。延迟低直接上vLLM，TGI吞吐好但首token慢。

INT4算5G那是权重，KV cache随上下文和并发涨得飞快，延迟敏感直接上vLLM吧。

INT4跑出5-6G是理论值，实际还得加上KV cache和框架本身的开销，7B模型上下文拉到4k、batch开到8，光KV cache就能吃掉好几个G。你延迟要求高、QPS不高的话，vLLM的continuous batching其实挺合适，TGI也不差但显存优化上感觉vLLM更激进些。建议先用nvidia-smi盯一下实际占用，再倒推能开多大batch，别硬套公式。多卡的话注意张量并行会额外增加通信开销，不一定是线性省显存。

显存这东西真的不能光看权重，INT4量化完模型本身确实就5G左右，但推理框架还要预分配KV Cache，这块才是吃显存的大头。你那个OOM八成是vLLM默认gpu_memory_utilization给太高了，它会把剩余显存几乎全吃掉，得手动压一下。KV Cache的估算大概是2乘层数乘隐藏维度乘序列长度乘batch再乘精度字节数，7B模型开4K上下文单条请求差不多就要1G多，你要是并发几条直接爆。做摘要延迟要求低的话其实可以考虑TGI，它对首token延迟优化得不错，vLLM更偏向高吞吐场景，QPS不高的话未必划算。多卡的话如果单卡能放下就别折腾张量并行了，通信开销反而拖延迟，实在要切就注意NVLink有没有，走PCIe会很难受。

Qwen2.5-7B的KV cache确实容易被忽略，我实测INT4权重加1k上下文、batch=4，显存直接飙到10G左右，公式只算了权重肯定不够。文本摘要延迟要求高的话，vLLM的PagedAttention对KV管理更细，单卡跑7B量化够用了，TGI在多卡扩展上省心些但小规模没必要。建议先按max_model_len和并发数反推KV显存，再留2G余量给CUDA和临时缓冲区，基本就不会OOM了。

INT4量化后权重是5-6G没错，但你漏了KV cache这块，7B模型在4k上下文、batch size稍大点就容易多占好几个G，OOM基本都出在这。vLLM的PagedAttention对KV cache管理更细，延迟敏感场景我更推荐它，TGI配bitsandbytes有时反而不够灵活。建议先用vLLM跑起来，把gpu_memory_utilization调到0.85左右试试，再根据实际显存占用反推能扛多长上下文和并发。

刚入门，这个对我帮助很大。

刚入门，这个对我帮助很大。

写得挺好，建议补充一些性能数据。

KV cache按上下文长度和并发数算才是大头，量化权重那点省的不够塞牙缝。