44GB 显存部署 Qwen：vLLM 下 AWQ、FP8 与 KV Cache 怎么选

单卡大约 44GB 可用显存 时，能不能跑起来某个 Qwen 模型，不能只看参数量。还要同时算清：权重占用、KV Cache、上下文长度、并发，以及 vLLM 自身的预留与碎片。

下文以 NVIDIA L40S（约 44.4 GiB）、模型 cyankiwi/Qwen3.6-35B-A3B-AWQ-4bit、镜像 vllm/vllm-openai 为例说明调参思路。MoE 模型还要注意：总参数量 ≠ 每 token 激活参数量 ≠ 实际加载显存。

配置速查

项目	示例值
GPU	NVIDIA L40S
模型	cyankiwi/Qwen3.6-35B-A3B-AWQ-4bit
权重	AWQ 4-bit
KV Cache	fp8（需版本与 GPU 支持）
--max-model-len	65536（按业务下调）
API	OpenAI 兼容，8000

上线前在目标机器确认：

nvidia-smi
docker run --rm vllm/vllm-openai:<tag> --help   # 核对参数是否仍存在

生产环境请 固定镜像 tag，不要长期依赖未锁定的 nightly。

显存花在哪

部分	决定因素
权重	参数量、量化格式、未量化层与对齐开销
KV Cache	层数、KV heads、head dim、序列长度 × 并发、缓存 dtype
运行时	算子临时缓冲、CUDA/vLLM 分配、其他进程

经验上：权重能加载成功 ≠ 长上下文 + 多并发一定稳。OOM 发生在加载阶段还是请求阶段，对策不同。

AWQ 4-bit 与 FP8 别混为一谈

• AWQ 4-bit（权重）：主要压缩权重；显存不是简单的「参数量 × 0.5 字节」，还有 scale、未量化模块等开销。
• FP8：多指 8-bit 浮点；若用于权重，通常比 4-bit 占更多空间；若用于 **--kv-cache-dtype fp8**，则是压缩 KV Cache，与权重格式是两件事。
• 仓库名里的 FP8/AWQ 不能代替读 model card 和启动日志。

对比两种配置时，固定：模型版本、prompt、输出长度、并发、max-model-len、vLLM 与驱动版本，再记 启动峰值显存、稳态显存、decode tok/s、首 token 延迟。

KV Cache 为何吃显存

自回归生成要缓存历史 token 的 Key/Value。趋势上：

KV 占用 ∝ 2 × 层数 × token 数 × KV heads × head_dim × 每元素字节数

（2 为 K/V；GQA/MQA 以模型 config.json 为准。）
把 max-model-len 从 16K 提到 64K，往往明显挤压并发或直接导致分配失败。

关键 vLLM 参数

--max-model-len

设为业务真实需要的上限，不要「越大越好」。对话 8K～32K 够用时，不必强行 64K。

--gpu-memory-utilization

控制 vLLM 规划占用 GPU 显存的比例（例如 0.90～0.95）。提高它可能多留给 KV Cache，但若卡上还有别的进程，仍可能 OOM。改参时 一次只动一个变量。

--kv-cache-dtype fp8

在支持的组合上可降低 KV 占用；必须以 启动日志 确认生效，并用固定 prompt 对比质量与速度。

Docker 启动示例

docker run -d \
  --gpus all \
  --name qwen-vllm \
  -p 8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  vllm/vllm-openai:<固定tag> \
  --model cyankiwi/Qwen3.6-35B-A3B-AWQ-4bit \
  --served-model-name qwen-local \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92 \
  --kv-cache-dtype fp8

工具调用、reasoning 等能力需按 当前 vLLM 文档 追加 --enable-auto-tool-choice、--tool-call-parser 等参数，勿跨版本照搬 parser 名称。

验证：

docker logs -f --tail 100 qwen-vllm
curl -s http://127.0.0.1:8000/v1/models | jq .
curl -s http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen-local",
    "messages": [{"role": "user", "content": "用一句话解释 KV Cache。"}],
    "max_tokens": 128
  }'

OOM 排查顺序

1. nvidia-smi：是否有其他进程占显存。
2. 日志区分：加载权重 OOM vs 推理/长 prompt/高并发 OOM。
3. 确认实际加载的 checkpoint 与量化格式。
4. 降低 max-model-len 或并发，再试 kv-cache-dtype fp8。
5. 单次只改一项，保留日志便于对比。

建议记录的对比表（本机实测后填写）

配置	max-model-len	并发	稳态显存	decode tok/s	备注
AWQ + 默认 KV		1
AWQ + FP8 KV		1
业务目标配置

总结

44GB 级单卡跑 Qwen 35B 级 MoE，核心是 权重（AWQ）与 KV（长度 × 并发 × dtype）分开规划。先锁镜像与模型版本，用短上下文建立基线，再按需拉长上下文或提高并发；任何「能启动」的结论都应配上真实请求下的显存与延迟数据。

性能与参数兼容性随 vLLM/GPU 驱动变化，请在目标环境复测后再写进生产配置。