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

量化乱码多半是calibration没喂好，换AWQ试试，或者干脆上FP8，A10也支持。

并发50的话，8卡每卡分6-7个请求差不多，vLLM开个continuous batching能省不少显存。

看到你说GPTQ偶尔乱码，建议先排除是不是calibration数据集和实际业务分布差异太大导致的，换个更贴近真实场景的校准集试试，比如直接抽你们线上日志里的prompt。8张A10其实挺宽裕的，7B模型用FP16纯显存也就14G左右，单卡塞batch size 8-12没问题，关键是vLLM的KV cache会吃掉大头，你算一下每请求平均token长度，如果是长上下文场景，建议直接上PagedAttention的vLLM最新版，它默认会动态管理显存，不用手动调batch。并发50的话，更建议你试试多卡张量并行加连续batching，比如4卡跑一个实例，剩下4卡再起一个副本，用负载均衡分流量，比单实例硬扛并发稳得多。量化方面，AWQ通常比GPTQ更稳，或者试下FP8，A10不支持但可以看下有没有其他卡。估算公式其实很简单，总显存减去模型权重，剩下的除以每序列KV cache开销（大概2×层数×头维度×2字节×序列长度），再乘个0.8的安全系数就是能同时跑的序列数，你自己套下数据算算就清楚了。另外生产环境强烈建议开vLLM的--enable-prefix-caching，如果业务有公共系统提示词，并发能再提升一大截。

8张A10跑7B并发50其实有点紧，vLLM里开tensor parallel加continuous batching能压不少，但别只盯着batch size，把max-num-seqs和gpu-memory-utilization调一下，留点显存给KV cache，OOM会好很多。量化这块GPTQ偶发乱码挺常见的，可以试试AWQ或者FP8，稳定性会好一些，或者干脆用safetensors加载然后配合vLLM的量化参数调优。显存估算大概就是模型权重加KV cache，7B FP16权重约14G，KV cache按每token几百字节算，具体还得看max sequence length和并发数，建议先压测再逐步加并发，别一上来就顶满。

量化别碰GPTQ，试试AWQ或者FP8，乱码大概率是量化粒度问题。显存估算可以按参数量*2字节（FP16）+KV cache算，7B模型20G左右打底。

先跑个压测看实际峰值占用再调max-num-seqs，硬怼batch size不如限制并发数做排队。

我们这边之前也踩过类似的坑，7B量化后乱码大概率是GPTQ的group size没调好，试试128或者64，另外vLLM里加--quantization gptq参数时记得对应上。显存估算的话，差不多是模型权重（7B*2字节=14G）加KV cache（每个请求约0.5-1G），50并发至少得预留25G，所以单卡24G确实很紧。建议先上AWQ量化，稳定性比GPTQ好一些，或者把张量并行切成两卡跑，这样单卡压力小很多。你们业务方对首token延迟有硬性要求吗？如果容忍2秒左右，可以试试把max-num-seqs调低。

8张A10跑7B其实余量挺大的，瓶颈多半在vLLM的显存分配策略上，试试把gpu_memory_utilization调到0.9以上，再配合--max-num-seqs限制并发数。量化还是建议用AWQ或GPTQ但务必跑一遍量化前后的ppl对比，乱码多半是校准集没选好。估算公式的话，单卡显存需求大致是模型权重(4bit约4G)+KV cache(每token约0.5M乘以batch size和序列长度)，你可以按这个倒推最大并发。

这题我刚好踩过坑，8卡A10跑7B其实不用上量化，vLLM里把张量并行开成2，每张卡塞个20的并发，配合continuous batching，峰值显存大概能压到16G左右，实测50并发没问题。乱码大概率是GPTQ的group size没调好，建议换AWQ试试，或者干脆用FP8动态量化。估算公式的话，你按模型权重显存（7B大概14G）+KV cache（每token约0.5M乘总长度）算，再用总显存减去权重部分，剩下的除以单请求平均KV占用，基本就是单卡并发上限了。