部署像Qwen-32B这样的大模型时，显存（VRAM）是最宝贵的资源。许多开发者在从Hugging Face加载量化模型后，直接使用默认参数启动vLLM，结果频繁遇到“CUDA out of memory”错误。这通常是因为忽略了不同量化格式（AWQ vs GPTQ）对底层算子和内存占用的细微影响。本文将指导你如何根据量化方式精准调整GPU内存利用率和并发参数，避免显存溢出陷阱。

核心差异：为什么AWQ和GPTQ需要不同的配置？

虽然AWQ和GPTQ都能将模型压缩至4-bit，显著降低权重显存占用（约16-17GB），但它们在推理时的行为有所不同：

• AWQ：激活感知权重量化。它在推理时通常需要更少的额外显存开销，且在vLLM中对AWQ算子的优化较为成熟，往往能支持更高的并发数。
• GPTQ：基于生成式预训练的量化。虽然精度保持极好，但在某些旧版本的vLLM或特定硬件上，GPTQ可能因为反量化算子或中间激活值的计算产生额外的显存峰值。

因此，不能简单地用一套参数通吃所有量化模型。

场景一：部署AWQ量化版本（推荐高并发场景）

AWQ版本通常被认为是vLLM上的“甜点”选择，因为它在速度和显存效率上表现均衡。对于Qwen-32B AWQ版本，我们的目标是最大化吞吐量。

首先，你需要确保gpu_memory_utilization设置得足够高，但不要顶格。建议设置为0.90到0.95。这是因为AWQ的权重加载非常紧凑，剩余的显存主要被用于KV Cache（键值缓存）。

其次，关于并发参数max_num_seqs。这是最容易被忽视的“坑”。默认的256对于32B模型来说可能过高，尤其是在长文本场景下。对于AWQ版本，建议从128开始测试。如果你的上下文长度（max_model_len）限制在4096以内，可以尝试提升至192。

最后，务必开启enforce_eager=False（默认即为False），允许vLLM使用CUDA Graph进行加速，这对AWQ模型的推理延迟有显著提升。

示例命令：

bash

编辑

python -m vllm.entrypoints.api_server \
    --model Qwen/Qwen-32B-AWQ \
    --quantization awq \
    --tensor-parallel-size 2 \
    --gpu-memory-utilization 0.95 \
    --max-num-seqs 128 \
    --max-model-len 4096

场景二：部署GPTQ量化版本（追求极致精度）

当你选择GPTQ版本时，必须更加保守地管理显存。GPTQ在解码过程中可能会产生比AWQ稍高的瞬时显存峰值。

首要调整的是gpu-memory-utilization。建议将其下调至0.85或0.88。预留更多的显存缓冲空间（Buffer）可以有效防止在处理长提示词（Prompt）时发生OOM。

其次，严格控制max-num-seqs。对于Qwen-32B GPTQ，建议将该值限制在64到96之间。过高的并发会导致KV Cache迅速填满预留的显存空间，进而触发崩溃。

此外，如果遭遇不稳定的显存溢出，尝试增加block-size或使用enable-chunked-prefill（如果vLLM版本支持）。分块预填充可以将巨大的输入提示词切分成小块处理，削峰填谷，避免因单次分配过大显存而失败。

示例命令：

bash

编辑

python -m vllm.entrypts.api_server \
    --model Qwen/Qwen-32B-GPTQ \
    --quantization gptq \
    --tensor-parallel-size 2 \
    --gpu-memory-utilization 0.85 \
    --max-num-seqs 64 \
    --max-model-len 4096

关键参数速查表

表格

总结与监控

无论选择哪种量化方式，部署后的第一步都应该是使用nvidia-smi监控显存使用情况。如果你发现显存长期处于满载状态且伴有大量重计算，说明并发数设置过高；如果出现间歇性OOM，则应降低gpu-memory-utilization并检查是否有超长文本请求。记住，对于32B级别的模型，稳定性优先于极限并发，合理的参数配置能让你的服务运行得更加持久高效。