告别显存溢出：单卡部署 Qwen2.5-Coder-32B 与 vLLM 高并发实战指南

2次阅读

共计 3102 个字符，预计需要花费 8 分钟才能阅读完成。

最近很多做开发的朋友都在吐槽，为了吃上 Qwen2.5-Coder-32B 这种代码推理天花板级别的开源模型，硬着头皮拉了多卡环境，或者忍受低速 CPU 卸载，成本和延迟双双爆炸。实际上，如果我们只要单并发吞吐满足日常 Copilot 需求，或者为小团队提供 10~20 人并发的内部 Coding Agent API，单张 RTX 4090 (24GB) 配合合理的量化方案和引擎调优，完全能把性能压榨到极致。

我在上周做模型底座重构时，针对单卡环境反复调优了 vLLM、TGI 和 SGLang，最终选定一套基于 vLLM + AWQ 量化的方案，不仅成功将显存锁死在 21.5GB 以内，还能稳定输出 45 tokens/s 的首字流式响应。这篇文章把我整理的完整工程化部署文件、显存参数计算逻辑以及压测数据和盘托出。

很多新手跑大模型，直接 git clone 官方 FP16 权重就往 4090 上塞，结果就是无情的 CUDA out of memory。我们先来算一笔硬账：

全精度 (FP16/BF16)： 每个参数占 2 字节，32B 纯权重就需要 32 × 2 = 64GB 显存，两张 A100 (40GB) 都不一定能跑顺畅。
AWQ / GPTQ (4-bit)： 每个参数只占 0.5 字节，32B 纯模型权重压缩到约 16GB~17GB。

剩下的 7GB~8GB 显存是关键战场。它必须分配给：CUDA Context（约 1GB~1.5GB）、动态 KV Cache（PagedAttention 缓存上下文）、以及激活值（Activation）。如果在启动 vLLM 时没有精准划定 KV Cache 边界，请求稍微带几千字的长上下文就会触发 OOM 宕机。

别自己花几个小时去跑 AWQ 量化，社区已经有高质量产物。推荐直接使用官方认证团队量化的 Qwen/Qwen2.5-Coder-32B-Instruct-AWQ。

我们采用 Docker 方式部署，隔离底层复杂的 CUDA 与 Python 依赖版本冲突。宿主机确保已安装 NVIDIA Driver (>= 535) 和 NVIDIA Container Toolkit。

# 拉取经过验证的稳定版 vLLM 镜像
docker pull vllm/vllm-openai:v0.6.3.post1

# 准备本地缓存目录
mkdir -p /data/models/huggingface
mkdir -p /data/vllm/logs

为了保证系统重启自愈以及参数版本控制，千万不要图省事直接敲 docker run。以下是我调试多轮后固化的 docker-compose.yml 生产配置：

version: '3.8'

services:
  qwen-coder:
    image: vllm/vllm-openai:v0.6.3.post1
    container_name: qwen25-coder-32b
    runtime: nvidia
    restart: unless-stopped
    environment:
      - CUDA_VISIBLE_DEVICES=0
      - HF_ENDPOINT=https://hf-mirror.com # 国内加速，海外机器可去除
    volumes:
      - /data/models/huggingface:/root/.cache/huggingface
    ports:
      - "8000:8000"
    ipc: host
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    command: >
      --model Qwen/Qwen2.5-Coder-32B-Instruct-AWQ
      --quantization awq
      --dtype auto
      --served-model-name qwen2.5-coder
      --max-model-len 8192
      --gpu-memory-utilization 0.90
      --max-num-seqs 16
      --trust-remote-code
      --enforce-eager

--gpu-memory-utilization 0.90： 默认是 0.9，意为给 vLLM 分配 90% 的可用显存。在 24GB 卡上相当于预留约 2.4GB 给系统和突发激活值。切忌为了图上下文强行拉到 0.98，极易引发底层 C++ 报错崩溃退出。
--max-model-len 8192： Qwen2.5-Coder 原生支持 32K 乃至 128K 上下文。但在单张 24G 显卡上，如果不缩短最大序列长度，KV Cache 预分配会极其吃紧。限制到 8192 token 足以应对单次代码补全与常规重构需求。
--enforce-eager： 在显存极为紧张时（如 RTX 4090），强烈建议开启该参数关闭 CUDA Graph 捕获。虽然轻微损失 3%~5% 的峰值解码吞吐，但能为你节省 1GB~1.5GB 的死板显存分配！
ipc: host： 必须加上，防止多线程处理内存映射时因为 Docker 默认 64MB 共享内存限制而直接 SIGBUS 暴毙。

容器启动后，查看日志直到出现 Application startup complete。我们可以使用 Python 脚本进行标准流式测试：

import openai

client = openai.Client(
    base_url="http://localhost:8000/v1",
    api_key="none"  # 本地部署无需鉴权
)

response = client.chat.completions.create(
    model="qwen2.5-coder",
    messages=[{"role": "system", "content": "你是一个资深系统架构师。"},
        {"role": "user", "content": "请用 Rust 编写一个高性能、无锁的环形缓冲区 RingBuffer 核心实现骨架。"}
    ],
    temperature=0.2,
    max_tokens=1024,
    stream=True
)

for chunk in response:
    content = chunk.choices[0].delta.content
    if content:
        print(content, end="", flush=True)

我在本地 RTX 4090 (24GB) 机器上，使用 vllm benchmark 针对不同并发进行了压力测试，测试 Prompt 长度为 2048 tokens，Generation 长度为 512 tokens：

并发数 (Concurrency)	平均首字延迟 (TTFT)	推理吞吐 (Tokens/s)	显存占用状态
1 (单用户编程)	120 ms	46.8	21.6 GB (稳定)
4 (小团队并行)	280 ms	89.2 (系统总吞吐)	22.1 GB (稳定)
16 (高负荷测试)	840 ms	114.5 (系统总吞吐)	22.8 GB (未触发置换)

实测表现非常亮眼：在单人使用 Continue 或 Cline 等插件辅助编程时，每秒 40 多词的吐字速度已经超越人类阅读极限，基本感受不到等待。

别盲目上双卡甚至四卡。在 AI 推理工程中，参数选型、量化方式和引擎机制的优化性价比远高于直接堆硬件。利用 AWQ 4-bit + vLLM 显存边界调控 ，我们完全可以用一张普通的消费级 4090 拿下目前代码能力最强开源 32B 模型的实际落地。如果你在接入过程中依然遇到了内存碎片问题，不妨优先调小 --max-model-len，把显存尽可能让给 Batch KV 处理，系统稳定度会有质的飞跃。

===END===

正文完