单卡跑满Qwen2.5-72B量化版：vLLM多并发流式推理与显存压榨实录

6次阅读

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

最近团队的内部代码助手和业务 Agent 需求激增，OpenAI API 账单蹭蹭往上涨，加上涉密代码上云的合规红线，私有化部署开源顶流大模型成了刚需。Qwen2.5-72B 发布后，其代码和逻辑能力已经逼近闭源第一梯队，但 72B 模型的体量摆在这里：FP16 权重光加载就需要将近 145GB 显存，这非一般小团队所能承受。

我的目标很明确：在单台配备单卡 48GB 显存（A6000 Ada / RTX 6000 Ada）或双卡 RTX 3090/4090（48GB 总显存）的服务器上，跑起 Qwen2.5-72B-Instruct 的 INT4/GPTQ/AWQ 量化版本，并且支撑起 20+ 人团队的高频并发提问与流式（SSE）长文本输出。折腾了一周，踩遍了显存碎裂、KV Cache 爆仓和流式响应卡顿的坑，今天把这套经过压测验证的生产级部署方案完整整理出来。

很多小伙伴在本地部署时第一反应是 Ollama，开发调试确实方便，一键拉取镜像就能跑。但一旦接入多人协作、多 Agent 并发或者长 Context（比如丢一个上万行的工程上下文）时，Ollama 底层基于 llama.cpp 的吞吐量瓶颈就会原形毕露：

显存碎片化严重： 连续几个长 prompt 输入，显存没释放完全，直接报 CUDA Out of Memory。
并发吞吐孱弱： 没有连续批处理（Continuous Batching）支持，请求排队等待严重，并发一多，首字延迟（TTFT, Time To First Token）直奔 10 秒以上。
流式首字抖动： Ollama 在高负载下的 SSE 推流经常卡顿断流，严重影响 IDE 补全插件体验。

相比之下，vLLM 的 PagedAttention 机制将 KV Cache 像操作系统的虚拟内存一样分页管理，显存浪费率能从 60% 降到 4% 以下。配合 Continuous Batching，单卡极限吞吐量是 Ollama 的 4-7 倍。对于团队生产环境，vLLM 几乎是目前唯一的自建正解。

72B 模型的 INT4 量化主要有 AWQ 和 GPTQ 两种方案。实测来看：

GPTQ-Int4： 静态量化，对显存要求极致，48GB 显存卡（如 RTX 6000 Ada 48G）加载完权重仅占约 39-41GB，留给 KV Cache 的余量在 6-8GB 左右。
AWQ-Int4： 推理吞吐通常比 GPTQ 略快 5%-10%，但在长窗口下激活值的波动偶发会多吃一点显存。

这里以兼容性最好、显存占用极其扎实的 Qwen/Qwen2.5-72B-Instruct-GPTQ-Int4 为例。系统环境基线如下：

# 基础环境建议：Ubuntu 22.04 LTS, CUDA 12.4, Python 3.11
# 务必升级最新驱动与 pip，避免 FlashAttention 编译踩坑
conda create -n vllm-py311 python=3.11 -y
conda activate vllm-py311

# 推荐直接安装预编译的 vLLM 和 FlashInfer
pip install --upgrade pip
pip install vllm>=0.6.2
pip install flashinfer -i https://flashinfer.ai/whl/cu124/torch2.4/

很多开发者直接运行 vllm serve 结果一上来就 OOM，原因在于 vLLM 默认会尝试霸占 90% 显存作为 Cache 池。面对 72B 这种巨无霸，必须手动精细化切割每一兆显存。

下面是我实测下来最稳健的单卡 48G 启动脚本 start_server.sh：

#!/usr/bin/env bash
export VLLM_USE_FLASHINFER=1  # 开启 FlashInfer 加速 Decode 阶段
export CUDA_VISIBLE_DEVICES=0

python3 -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-72B-Instruct-GPTQ-Int4 \
    --served-model-name qwen2.5-72b \
    --quantization gptq \
    --dtype float16 \
    --tensor-parallel-size 1 \
    --gpu-memory-utilization 0.95 \
    --max-model-len 16384 \
    --max-num-batched-tokens 16384 \
    --max-num-seqs 64 \
    --kv-cache-dtype auto \
    --enable-chunked-prefill \
    --host 0.0.0.0 \
    --port 8000

--gpu-memory-utilization 0.95： 压榨到极致。48GB 显存分配 45.6GB。40GB 分配给模型权重与运行时上下文，剩余约 5.6GB 全部划拨给 PagedAttention 作为 KV Block。
--max-model-len 16384： Qwen2.5 原生支持 128K 窗口，但在单卡 INT4 下千万不要无脑开满 128K！一个满载 128K 的 Context 就能吃掉上百 GB 的 KV Cache。在日常工程代码补全中，16K 已经能覆盖 95% 的业务需求，留出的显存能让并发支撑能力翻数倍。
--enable-chunked-prefill： 极其关键的参数！开启分块预填充后，大 Prompt 不会一次性独占 Compute，而是分片送入计算流，避免在有超长 Prompt 进来时，其他并发请求的流式输出发生“假死”。
--tensor-parallel-size： 如果你是两张 24G 显卡（如 2x RTX 3090/4090），将此参数改成 2，CUDA 环境变量改成 export CUDA_VISIBLE_DEVICES=0,1，vLLM 会自动用 NCCL 进行张量并行切分。

vLLM 自带的 Python ASGI Server 在极高并发下处理网络连接会有一定开销。直接将 8000 端口暴露给公网或局域网非常危险，且无法优雅处理客户端断开连接导致的算力浪费问题。我们在前端挂一层 Nginx，专门为 Server-Sent Events (SSE) 优化长连接。

下面是专属的 Nginx 流式代理配置片段：

upstream vllm_backend {
    server 127.0.0.1:8000;
    keepalive 64; # 保持长连接池，避免频繁握手消耗文件描述符
}

server {
    listen 80;
    server_name llm.nassky.internal;

    location /v1/ {
        proxy_pass http://vllm_backend;
        proxy_http_version 1.1;

        # 核心：必须禁用缓冲，否则流式打字机效果会变成整段吐出
        proxy_buffering off;
        proxy_cache off;
        proxy_set_header Connection '';
        chunked_transfer_encoding on;

        # 针对长思考时间，放宽超时限制
        proxy_read_timeout 600s;
        proxy_send_timeout 600s;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

这里踩过一个大坑：如果 proxy_buffering 保持默认的 on，Nginx 会尝试凑满一个 buffer chunk 才向客户端冲刷数据，前端看到的效果就是“先卡死 5 秒，然后突然崩出一大段文字”，彻底失去了流式打字的顺滑感。

我在局域网内使用开源负载工具进行基准测试，模拟不同并发用户下的流式请求情况。测试设定：输入 Prompt 均值 1500 tokens（模拟一段 Python 业务逻辑与报错追踪），输出限制 512 tokens。

并发量 (Concurrent)	首字延迟 (TTFT P95)	生成速度 (Tokens/sec)	显存使用率 (48G 卡)	请求成功率
1 (单请求)	210 ms	38.4 tok/s	88.2%	100%
8 并发	480 ms	165.2 tok/s (总吞吐)	93.1%	100%
16 并发	890 ms	210.5 tok/s (总吞吐)	94.8%	100%
32 并发	2.1 s	228.1 tok/s (总吞吐)	95.0%	99.2% (少数排队)

从实测数据可以看出，在开启了 chunked-prefill 后，即使并发数打到 16，TTFT 依然保持在 1 秒以内，这完全在人类交互感知的舒适区内。总吞吐量稳定在 200 tokens/s 以上，这意味着 15 到 20 个人同时在 Cursor 或 Continue 中进行代码生成，后端依然稳如老狗。

杜绝 CPU Swap 干扰：
大模型加载时如果物理内存不足，系统会把数据置换到 Swap，导致加载直接挂起半小时甚至超时崩溃。启动前务必确认物理内存至少有 64GB，并建议临时调低虚拟内存置换激进度：
```
sudo sysctl vm.swappiness=1
```
客户端主动断开的算力回收：
写代码时，如果生成的内容方向偏了，用户通常会点 Stop。vLLM 默认需要客户端主动断开 HTTP 连接并触发服务端 abort。如果使用了网关，务必确保网络栈能正确透传 TCP RST 信号，避免 GPU 还在吭哧吭哧推理已经被丢弃的请求。
长尾请求导致 KV Cache 耗尽防护：
如果某位同事丢了一个极其庞大的 PDF 进来做 RAG 检索，直接把所有 KV Blocks 占满，后面的轻量级请求会全部进入 Waiting 队列。如果你的业务场景多长文本，建议在启动参数中加入 --max-seq-len-to-capture 并严格在 API 层做 Prompt 长度限流拦截。

开源模型生态演进到 Qwen2.5 这一代，代码和指令遵循能力已经足以承担起中小团队 80% 的日常研发提效。利用好现代量化（GPTQ/AWQ）与高性能推理框架（vLLM），我们完全不必仰仗昂贵的多卡 H100 集群。

单张 48G 工作站显卡，只要把 max-model-len、chunked-prefill 以及 Nginx 的反向代理调教得当，就能搭建出一套媲美商用服务的高吞吐、低延迟 LLM 流式中枢。后续我会继续分享基于这套架构接入内部向量数据库（RAG）的生产踩坑实录，感兴趣的朋友可以保持关注。

正文完