部署开源大模型到生产环境，显存总不够用怎么办？

有没有更详细的教程推荐？

你这情况我太熟了，13B在A100单卡上做推理，vLLM本身已经比普通HF推理省显存了，但并发一高OOM是常态。4bit量化确实能降一点，但vLLM对GPTQ的显存优化其实没想象中那么神，因为它的PagedAttention主要管的是KV Cache，模型权重该占多少还是多少。我建议你看看能不能先上Flash Attention，这个基本无痛，HuggingFace上很多模型已经自带，vLLM也默认集成了，主要是优化attention计算时的显存占用，效果很直接。如果还想再压一压，可以试一下AWQ量化，vLLM原生支持，比GPTQ在同精度下显存占用更低一些，而且推理速度更快。至于多卡张量并行，如果只是顶小流量其实没必要，单卡能调好的话部署成本低很多。另外有个trick：检查一下你的max_num_batched_tokens和max_num_seqs参数，别设太大，否则vLLM会预分配一大块显存给KV Cache，改成小一点的数值能显著降低峰值显存。你当前大概是多少并发就炸？

vLLM本身已经集成了Flash Attention，你可以检查下启动参数里有没有开启，这能省不少显存。另外如果只顶小流量，试试把max_num_batched_tokens调小，或者开启--enforce-eager模式看看，虽然慢一点但能缓解OOM。多卡张量并行其实配置起来没那么复杂，vLLM官方文档有例子，单机多卡直接用--tensor-parallel-size 2就行，分摊后单卡压力会小很多。

刚用vLLM部署13B模型踩过类似的坑，我试下来最立竿见影的是把max_num_batched_tokens调小，再配合vLLM的PagedAttention，能把碎片化显存回收不少。Flash Attention确实能省一点，但对OOM治标不治本，真要扛并发的话，张量并行加两块卡是更稳定的路子，我这边用TP=2之后显存占用直接砍半。另外如果只是临时顶小流量，试试把模型切到FP8或者开启swap，虽然慢点但至少不崩。

Flash Attention确实能省不少显存，尤其长序列场景下效果很明显，vLLM本身就支持，开一下就行。多卡张量并行的话，单机多卡部署13B模型也挺成熟，vLLM用tensor parallel参数就能搞定。如果只是想先顶住小流量，可以试试把max_num_batched_tokens调小点，或者限制一下并发请求数，虽然粗暴但管用。

试试把max_num_seqs调小点，配合vLLM的continuous batching，小流量下能省不少显存。

vLLM本身已经集成了Flash Attention，你确认一下是不是没开，默认应该是开的。Quantization可以试试AWQ，同样是4bit但很多场景比GPTQ更稳，结合vLLM的指定--quantization awq参数就能跑。张量并行确实能压单卡显存，但要看你的模型并行度，13B用2卡TP就能把每卡负载降下来。实在不行，PagedAttention的vLLM本身就能通过swap把部分KV cache放到CPU，小流量时临时调低max_num_seqs也能救急。

老实说，你遇到的情况太典型了，单卡A100跑13B模型并发一高就OOM几乎是必经之路。我自己的经验是，GPTQ量化到4bit确实能省点，但vLLM的PagedAttention本身对显存管理已经优化了不少，如果还爆，问题往往出在请求长度和batch size上——你可能需要限制最大输入长度，或者把max_num_seqs调小一点，先让推理不崩。Flash Attention是能降低显存占用，但它主要优化的是注意力计算那部分，对总显存溢出帮助有限，而且需要你改模型代码或者用支持它的框架。多卡张量并行才是治本的办法，但落地有点门槛，比如你要用Megatron-LM或者DeepSpeed把模型切分到两张A100上，每卡只负责一半的层或头，这样单卡显存压力直接减半，不过通信开销会稍微拖慢推理速度。如果你的业务流量不大，一个取巧的办法是启用vLLM的continuous batching加上请求排队机制，把并发限制在4-6个请求以内，配合4bit量化，80G显存基本能稳住。另外，检查一下是不是有history或system prompt被反复拼接导致KV Cache爆炸，这个坑我踩过好几次。

说实话你这情况太典型了，我去年也踩过一模一样的坑。vLLM本身对显存管理已经做了不少优化，但还是扛不住高并发，尤其是13B这种模型在A100上跑，KV Cache的占用量真的会吓到你。我后来试了Flash Attention，确实能省一点显存，但别指望它能解决根本问题，它主要是在计算层面减少显存占用，而不是压缩模型本身。

你提到GPTQ 4bit量化后显存还是跑满，这个我猜是你并发数设太高了，vLLM的max_num_seqs参数得手动调小，比如从默认的256降到64甚至32，先保证单个请求不崩。另外，我强烈建议你试试多卡张量并行，虽然听起来复杂，但vLLM支持起来非常简单，只要在启动时加个--tensor-parallel-size 2或者4就能自动切分，A100 80G两张卡跑13B基本能扛住几十并发。

不过张量并行对网络带宽有要求，如果你们服务器是PCIe互联而不是NVLink，通信延迟可能会拖慢推理速度。还有个偏方：把模型换成AWQ量化版本，实测它比GPTQ在同等显存下精度损失更小，而且vLLM原生支持，不用额外改代码。你如果不急着上大流量，先用8bit加低并发凑合着跑起来，等把profiling工具跑一遍再决定要不要上多卡。

vLLM本身已经集成了Flash Attention，你可以确认下是不是已经默认开启，没开的话在启动参数里加个--enable-flash-attn就能省不少显存。另外4bit量化后还跑满，可能是你的max_num_batched_tokens设太大，调小到1024或2048能明显缓解并发压力。小流量场景下可以先用--max-model-len把上下文长度限制到2048，牺牲一点长文本能力换稳定性，等后续再上张量并行。

vLLM本身已经集成了Flash Attention，你确认下启动参数里有没有加上--enable-flash-attn，这玩意儿能省不少显存。多卡张量并行确实好用，但得看你公司服务器有几张卡，单机多卡用--tensor-parallel-size 2就能跑起来。另外一个小trick：把max-num-seqs调小点，比如设成128，虽然并发降了但至少不崩，先顶住小流量没问题。精度敏感的话，4bit GPTQ可以试试配合AWQ，有时候比纯GPTQ更稳。

Flash Attention确实能省显存，尤其长序列下效果明显，可以优先加上试试。多卡张量并行的话，vLLM本身就支持，启动时加个--tensor-parallel-size 2就能让两张卡分担模型权重和计算，显存压力直接减半。另外如果只是小流量扛不住，试试调低--max-num-seqs限制并发请求数，或者把--gpu-memory-utilization设到0.9以下留点余量，能临时顶一阵。

你这情况我遇到过，vLLM本身已经集成了PagedAttention，你确认下是不是没开对参数，比如max-num-seqs调小点能缓解并发OOM。GPTQ 4bit加Flash Attention可以一起上，但13B模型用单卡A100其实挺极限的，建议直接上张量并行，两张卡就能轻松很多。如果只想临时顶小流量，可以限制一下最大输入长度和max-num-batched-tokens，效果立竿见影。

你这情况我之前也遇到过，A100 80G单卡跑13B并发一高确实容易炸。建议先试试Flash Attention，vLLM本身就集成了，基本零成本开启就能省不少显存，尤其长序列场景效果明显。如果还撑不住，可以考虑把batch size调小一点，配合vLLM的continuous batching特性，小流量下也能稳定运行。至于多卡张量并行，其实vLLM配置起来不复杂，设个tensor_parallel_size参数就行，不过得注意跨卡通信带宽，PCIe链路速度不够的话反而会拖慢推理。

vLLM本身其实已经集成了Flash Attention，你可以在启动参数里加个--enable-flash-attn试试，能省不少显存。单卡实在扛不住的话，张量并行确实是最直接的解法，vLLM对TP支持挺好的，代码几乎不用改，按文档配一下就行。另外如果流量不大，可以先用Continuous Batching的默认设置顶一顶，调小max_num_seqs也能缓解OOM。量化到4bit还爆的话，看看是不是prompt太长或者max_model_len设太大了。

Flash attention确实值得试，它主要优化了attention计算的内存占用，能省出不少显存给并发请求。另外你可以考虑用PagedAttention（vLLM本身就支持），它把显存分页管理，能更高效处理多请求。如果流量不大，先调低max_num_batched_tokens或者限制最大并发数，也能临时顶一下。多卡张量并行是长期方案，但需要改模型加载和通信配置，建议先跑通单卡优化再上。

我这边也是用vLLM部署13B模型，A100 80G单卡确实扛不住高并发。建议你先试试Flash Attention，能省不少显存，而且vLLM本身就支持，改个参数就行。如果还不行，张量并行是终极方案，两张A100切一下，显存直接翻倍，vLLM里设置--tensor-parallel-size 2就能跑起来。另外小流量顶一顶的话，可以调低max-num-seqs和max-model-len，牺牲点吞吐换稳定。

Flash Attention确实能压显存，特别是长上下文场景，vLLM本身就集成了它，你可以确认下是不是默认启用了。不过13B模型单卡A100 80G跑并发，OOM不全是显存问题，有时候是vLLM的调度策略没调好，比如max_num_batched_tokens设得太高，或者gpu_memory_utilization给到了0.95，实际留点余量到0.85反而更稳。GPTQ量化到4bit后显存还跑满，我怀疑是你没把模型切分好——试试用张量并行，两张A100各分一半层，虽然通信开销会让首token延迟高一点，但并发吞吐能翻倍。另外有个简单trick：先跑个压力测试，把max_concurrency手动限死在某个值，比如8，然后观察显存峰值，逐步往上加，找到不OOM的临界点。还有个小众但好用的办法是结合CPU offloading，把部分attention层放到内存，虽然慢点但至少不会崩，适合小流量过渡。你公司服务器是单机多卡还是多机？如果只有单机，强烈建议上张量并行，比量化效果明显。

试试vLLM的prefix caching和continuous batching，能省不少显存，小流量撑得住。

说实话A100 80G跑13B模型本身是够的，但vLLM默认的调度策略在并发上来时会一次性给每个请求分配完整KV Cache，这才是显存爆掉的直接原因。建议你先调低--max-num-seqs和--max-model-len这两个参数，把单次并发处理的请求数压到8以下，同时限制最大输入长度到2048，这样小流量场景能立刻缓解OOM。

Flash Attention确实能省显存，但它主要是优化注意力计算的显存碎片和中间结果缓存，对整体占用降低有限。真正见效的是张量并行，但需要至少2张A100，通过--tensor-parallel-size 2启动，显存占用能直接砍半，不过通信开销会吃掉一点吞吐。如果你只有单卡，可以试试PagedAttention的vLLM实现已经默认启用了，但记得把--gpu-memory-utilization从0.9调到0.85甚至0.8，给系统留更多余量。

另外GPTQ 4bit量化后显存还跑满有点反常，建议检查一下是否同时开了--dtype float16，混合精度计算会让部分参数回退到fp16。可以强制用--dtype bfloat16或者--quantization gptq时加上--model-format gptq来确认量化生效。如果这些都不行，试试把模型切成AWQ量化，它在低比特下精度保留比GPTQ好，而且vLLM原生支持AWQ的显存优化。