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

我们组之前也踩过类似的坑，A100 80G塞20个实例纯属理论值，实际跑起来KV cache和显存碎片会让你怀疑人生。建议先量化到AWQ 4bit试试，知识库问答这种场景掉点其实感知不强，但并发能翻倍。另外别急着上4卡张量并行，2卡各跑一个实例做负载均衡更灵活，单实例崩了还有兜底，TTFT也能稳在1秒左右。你们有没有试过pipeline并行？感觉小模型上收益不大，但显存占用会好看点。

说实话你这个场景我太有同感了，之前折腾过类似的RAG项目，7B看起来小，真上生产全是坑。单卡A100塞20个实例那种说法基本是理想状态下的理论值，实际跑起来KV cache和预填充的峰值能把显存干爆，尤其是知识库问答长上下文场景，TTFT直接崩到3秒开外。我建议你别纠结4卡张量并行，那东西对小模型收益真不大，通信开销反而拖后腿，2卡各跑一个实例做负载均衡更稳，还能顺便扛单点故障。AWQ 4bit我实测过，Qwen2.5的掉点主要在长尾知识和复杂推理上，如果你们的问答都是短答案匹配，基本无感，但要是涉及多跳推理或者需要引用原文，建议先拿测试集跑一遍对比，别拍脑袋。另外你响应2秒内的话，vLLM的continuous batching参数和max_num_seqs得调，别默认值，我这边调完并发从8路提到15路，TTFT还稳在1.5秒内。最后提醒下，预热和显存碎片也是个坑，建议先压测再上生产，别急着切流量。

实际经验是2卡各跑实例比4卡张量并行稳，TTFT短很多，AWQ 4bit在知识库场景掉点不明显。

2卡各跑实例更稳，AWQ 4bit跑知识库问答基本够用，别太纠结掉点。

2卡各跑一个实例更稳，AWQ 4bit在知识库场景基本无感，TTFT能压进1秒。

4卡张量并行延迟更稳，AWQ 4bit跑知识库问答基本无感掉点，实测过可以放心上。

我们团队实测过Qwen2.5-7B在A100上的表现，显存占用高大概率是vLLM默认预分配了KV cache，建议先调gpu_memory_utilization到0.9再测。单卡并发30路以内TTFT能压住1.5秒，超过就明显劣化，所以2卡负载均衡比4卡张量并行划算，毕竟你瓶颈在延迟不在吞吐。AWQ 4bit在知识库问答这种短文本场景掉点基本无感，但记得用量化版本重新跑一遍评测集，别直接拿原权重改配置。

我们组之前也踩过类似的坑，7B用vLLM默认配置显存预留太多，实际跑起来并发10路左右TTFT就飙到3秒+，后来开了continuous batching和prefix caching才压回2秒内。你这场景如果知识库问题高度相似，强烈建议试试prefix caching，收益比上多卡更明显。AWQ 4bit我测过Qwen系列，掉点大概在3-5%的EM，但知识库问答这种生成式任务体感差距不大，倒是显存能省一半，2卡各跑实例的性价比大概率比4卡张量并行高，毕竟张量并行对单请求延迟没帮助，只提吞吐。另外你测显存高是不是没设max-model-len？默认8K会吃爆，砍到4K能多塞不少并发。

别光看显存，TTFT瓶颈一般在prefill，4卡张量并行对长文档知识库提升比2实例负载均衡明显得多。

我们组之前也踩过类似的坑，vLLM的显存预分配比想象中激进，尤其是开了continuous batching之后，20个实例那个说法基本是理想状态下的数字，实际跑起来显存碎片化很严重。我个人建议先别急着上4卡，A100的NVLink带宽做张量并行确实香，但如果你单卡能塞下2个实例，2卡各跑一个再挂个简单的nginx负载均衡，实测并发吞吐反而更稳，而且某个实例崩了还能自动摘除，运维省心不少。

至于AWQ 4bit，知识库问答这种场景我觉得可以试，但得看你的prompt模板和system prompt有多长，量化后长上下文的首token延迟会明显恶化。我们之前用Qwen2.5-7B做过对比，4bit在短query（<200 token）下确实只掉3-5个点，但一旦涉及多轮对话或者RAG拼接长文档，回答质量会显得“飘”。如果TTFT卡在2秒内是硬指标，我建议你优先用FP8或者KV cache量化，别直接上4bit，然后显存省下来的额度全给max_num_seqs，让vLLM自己调度并发。

还有个容易被忽略的点——你的知识库检索如果不在同一张卡上做embedding，那响应时间会被RPC拖累。最好是检索和生成共用同一张卡，或者至少在同一台机器上，不然2秒根本不够用。最后想问下你测过首token延迟的p99吗？我怀疑你现在遇到的瓶颈不是显存，而是vLLM的调度策略默认给长序列留了太多preempt空间。

说实话AWQ 4bit在这种知识库问答场景下掉点真没那么夸张，尤其Qwen2.5本身指令跟随能力挺强，可以先量化跑一版看下badcase再决定。你说的20个实例那个数据我也见过，但那是纯显存理论值，实际vLLM还要留KV cache和中间buffer，我这边8卡A100跑7B也就敢开16个实例，TTFT还得压在300ms以内才行。要我说2卡各跑实例负载均衡比张量并行稳，毕竟并发上来时单实例吞吐瓶颈很明显，而且你2秒响应时间其实余量不小，重点得把max_num_seqs调小点。

4卡张量并行更适合你，2秒响应比省显存重要，AWQ掉点换速度挺值的。

4卡张量并行延迟更稳，2卡负载均衡吞吐高但TTFT难控，AWQ 4bit知识库问答基本无感。

4卡张量并行对7B来说太浪费了，2卡各跑一个实例负载均衡更划算，AWQ 4bit在知识库场景基本无感。

vLLM默认的continuous batching吃显存确实比想象中猛，A100单卡跑7B满并发别被网上那些数字忽悠了，实测20路都容易爆。我建议你先用AWQ 4bit试试，Qwen2.5的量化损失在知识库场景基本感知不到，但显存能省快一半。至于并行方案，2卡各跑实例做负载均衡比4卡张量并行更灵活，毕竟你TTFT敏感，张量并行反而增加通信开销。另外可以调下vLLM的max-num-seqs和gpu-memory-utilization，别让KV cache把显存全占了。

说实话你这问题我太有同感了，之前我们内部做类似迁移时也卡在显存和并发的坑里。单卡A100 80G塞20个实例基本是理论值，实际跑起来KV cache和中间激活值会吃掉一大块，我建议你先用vLLM的--gpu-memory-utilization参数压到0.9再观察，别一上来就信网上的数字。关于2秒响应，我的经验是4卡张量并行对TTFT改善非常有限，因为通信开销会吃掉一部分收益，反而2卡各跑实例做负载均衡对吞吐更友好，尤其你们是知识库问答这种短文本场景。AWQ 4bit我试过，掉点通常在可接受范围内，但qwen的指令跟随会稍微变笨一点，建议你拿用户真实query做对比测试，别只看benchmark。最后提醒下，并发压力大时优先开vLLM的continuous batching，配合--max-num-seqs调成32左右，比盲目堆实例靠谱。如果你能接受稍微牺牲点显存，上8bit量化加2卡负载均衡可能是最稳的解法。

实测过Qwen2.5-7B在A100上的情况，20个实例纯属理论值，实际开16并发左右TTFT就开始飙了，跟上下文长度关系特别大。你如果知识库问答要拼检索长文本，建议直接上2卡各跑实例做负载均衡，比4卡张量并行灵活，单卡挂了还有冗余。AWQ 4bit在知识库场景掉点不明显，但注意要开--kv-cache-dtype fp8_e5m2，能省不少显存。另外vLLM记得开continuous batching，不然并发一上来首字延迟肯定爆炸。

我们生产环境也是7B，实测单卡A100 80G上vLLM开8个实例，并发压到20路左右TTFT就飙到1.5秒以上了，2秒内根本稳不住。后来改成张量并行4卡，单实例吞吐反而上去了，延迟也稳，感觉比堆实例划算。AWQ 4bit我试过，知识库问答这种场景掉点不明显，但如果你有复杂推理或长上下文，最好还是留着FP16。你现在的知识库检索是不是单独服务？如果检索快，模型压力小点，2卡负载均衡可能也够用。

我们生产环境用的就是Qwen2.5-7B，单卡A100跑16并发差不多就到顶了，TTFT确实会飙到1.5秒往上，2秒内只能压到12路左右。4bit AWQ在知识库问答这种场景基本无感，但你要是对长文本细节敏感，建议保留FP8，体感比AWQ稳。张量并行和双实例这事儿，我推荐先试2卡各跑一个，调度上更灵活，单卡挂了还能顶一下，TP4反而把故障域扩大了。

我们生产环境跑7B用的就是2卡各跑实例做负载均衡，比4卡张量并行稳得多，单卡延迟还低。AWQ 4bit掉点看场景，知识库问答这种短文本其实感知不强，但最好拿你们自己的测试集跑一遍。显存别只看模型权重，kv cache和中间激活才是大头，vLLM建议把max-num-seqs调低点，20并发以内单卡A100完全够。响应2秒的话，建议把max-model-len限制在8k以内，实测TTFT能压到300ms左右。