部署7B模型到生产环境，显存和并发到底怎么权衡？

2卡各跑一个实例负载均衡吧，4卡张量并行延迟也没好到哪去，AWQ 4bit知识库问答够用。

我们组之前用7B做过类似场景，4bit量化掉点其实没想象中严重，知识库问答这种任务完全能打，但AWQ对中文长文本偶尔会有点犟，建议自己拿测试集跑一遍看case。显存这块别光看模型权重，kvcache和并发序列长度才是大头，vLLM配好continuous batching之后，单卡A100撑30路左右没问题，但TTFT确实会随着并发涨，想稳2秒内建议还是2卡各跑一个实例做负载均衡，扩缩容也灵活。张量并行延迟低但带宽瓶颈明显，4卡有点浪费，除非你要上更大模型。

说实话你这场景我建议直接2卡各跑一个实例，A100单卡塞20个实例纯属扯淡，Qwen2.5的KV cache吃显存很凶，实测16路并发TTFT就飙到1.5秒了。AWQ 4bit掉点没那么玄乎，知识库问答这种抽取式任务基本无感，但如果你要做长上下文或者复杂推理，还是老老实实FP16。另外vLLM记得开continuous batching，不然并发一上来调度开销直接把你2秒的预算吃光。

说实话我最近刚把7B模型量化到AWQ 4bit跑过，掉点没想象中那么夸张，知识库问答这种场景基本感知不到，但显存确实能省下一大截。你那个20个实例的说法太理想了，实际还要算上KV cache和vLLM的预留，建议你直接用2卡各跑一个实例做负载均衡，这样单卡压力小，TTFT也更稳。另外A100跑7B其实没必要上4卡张量并行，通信开销反而拖慢速度，除非你的并发真的高到单卡扛不住。

我们组之前用7B做过压测，单卡A100 80G跑16并发左右TTFT就开始飘了，跟显存关系不大，主要是算力瓶颈。建议你先别纠结量化，AWQ 4bit在知识库场景掉点其实能接受，但RAG检索质量对最终效果影响更大。如果预算允许，4卡张量并行对单请求延迟更友好，2卡负载均衡则是吞吐上限高，但你要求2秒内响应，我倾向后者，因为知识库问答请求通常短而密集。顺便问下，你vLLM的max-num-seqs调过没？默认值可能太保守了。

看你这个场景，2卡各跑一个实例做负载均衡更稳，张量并行虽然单请求快，但并发一高卡间通信反而拖后腿。AWQ 4bit在知识库问答这种短文本场景掉点真不明显，但记得把max_seq_len调小点能省不少显存。另外TTFT变长大概率是vLLM的continuous batching没调好，试试把--max-num-seqs锁到16左右，体感会好很多。

建议直接上4卡张量并行，AWQ 4bit在知识库场景掉点不明显，TTFT比双实例稳多了。

4卡张量并行延迟更稳，AWQ 4bit在知识库场景掉点其实能接受，建议先量化试跑。

我们最近也踩过这个坑，vLLM的连续批处理会吃满KV cache，显存和你说的20个实例完全对不上。建议先开--max-num-seqs压到32，再把--gpu-memory-utilization调到0.9，实测单卡A100能扛住50路左右，TTFT能压在1.5秒内。AWQ 4bit在知识库问答这种短文本场景掉点其实不明显，但如果你要检索长文档还是得用8bit，不然引用细节会丢。另外别上4卡张量并行，跨卡通信延迟在低并发下反而更糟，2卡各跑一个实例做负载均衡更稳，出问题也好排查。

实测过Qwen2.5-7B在A100上，AWQ 4bit大概能压到6-7G显存，但20个实例纯属理论值，vLLM的KV cache和PagedAttention一开，实际并发到8路TTFT就开始飘了。知识库问答如果检索占时间，建议2卡各跑一个实例加负载均衡，比4卡张量并行稳，单点故障影响也小。4bit掉点看场景，实体抽取和短问答基本无感，长文本生成偶尔会丢细节，你先拿自己知识库跑个评测集对比下再定。