单卡4090跑满吞吐：vLLM生产级流式推理与反向代理实战调优

3次阅读

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

在自己的工作站或边缘服务器上用单张 RTX 4090（24GB）跑开源大模型时，很多同学一上来就直奔 Ollama。作为开发测试工具，Ollama 确实开箱即用，但在稍微有几十个并发请求的内部协作或者 Agent 密集调用场景下，你会发现 GPU 利用率忽高忽低，显存被大模型上下文塞满后排队剧增，TTFT（Time To First Token，首字延迟）直接飙到好几秒。为了把 24GB 显存压榨到极致，我最终将生产环境的推理引擎全面换成了 vLLM，并搭配了一套轻量级的异步流式反向代理。

大模型推理的瓶颈从来不在显卡算力，而在显存带宽与 KV Cache 显存管理。传统 HuggingFace 原生 Transformers 生成文本时，KV Cache 需要连续的显存块分配。一旦多用户并发发起请求，显存碎片化极其严重，单张 24GB 卡跑个 8K 上下文的 7B/8B 模型，并发往往被卡在 3~5 个，稍微超载就抛出 CUDA out of memory。

vLLM 核心的 PagedAttention 机制类似操作系统的虚拟内存分页，将 KV Cache 拆解为非连续的内存块，大幅消除了内部显存碎片。但在实际部署时，如果不根据模型架构和量化格式细调调度参数，很容易出现启动时显存就被吃光、或者稍微遇到长 Prompt 就直接触发抢占（Preemption）导致吞吐暴跌的情况。

以当前表现优异的 Qwen/Qwen2.5-7B-Instruct 和 meta-llama/Llama-3.1-8B-Instruct（推荐采用 AWQ 或 GPTQ 4-bit 量化版）为例，单张 24GB 显卡推荐使用 Docker 容器化隔离启动，既能锁定 CUDA 环境，也方便后续自动化运维。

# 拉取官方最新容器镜像
docker run -d --gpus all \
  --name vllm-server \
  --restart unless-stopped \
  -p 8000:8000 \
  -v /root/.cache/huggingface:/root/.cache/huggingface \
  --ipc=host \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen2.5-7B-Instruct-AWQ \
  --quantization awq \
  --gpu-memory-utilization 0.92 \
  --max-model-len 8192 \
  --max-num-seqs 64 \
  --swap-space 4 \
  --enforce-eager \
  --trust-remote-code

–gpu-memory-utilization 0.92： 预分配给 vLLM 的显存比例。千万不要拉满到 1.0，否则 PyTorch 运行时稍有临时分配就会 OOM。设为 0.92 留出约 1.9GB 显存给 CUDA 核心上下文与算子缓存。
–max-model-len 8192： Qwen2.5 官方原生支持到 32K 或 128K 上下文。如果单卡直接放开默认长度，vLLM 会预先分配巨大的 KV 槽位，导致并发序列数（KV Cache Blocks）锐减，甚至直接无法启动。强制限制在 8192 是保障单卡高并发的最佳平衡点。
–max-num-seqs 64： 允许同时处理的最大序列并发数。如果不限制，瞬时并发飙高会导致批量任务发生抢占换入换出，首字响应时间急剧劣化。
–enforce-eager： 在显存极为紧张或特定量化算子容易引发 CUDA Graph 捕获失败时开启。实测开启后显存能省出接近 1.5GB，虽然微损了极端低并发下的极限吞吐，但多并发稳定性大幅提升。

在企业内网或公网暴露大模型时，绝不能直接裸露 vLLM 的 8000 端口，必须在前面挂一层 API 网关进行鉴权、速率限制、敏感词过滤以及 Token 消耗统计。这里使用 FastAPI 构建一个高性能的流式代理层，确保流式打字机效果（Server-Sent Events）毫秒级吐出。

# proxy_server.py
from fastapi import FastAPI, Request, HTTPException
from fastapi.responses import StreamingResponse
import httpx
import json

app = FastAPI(title="LLM Edge Gateway")

VLLM_UPSTREAM_URL = "http://127.0.0.1:8000/v1/chat/completions"
# 复用全局异步客户端连接池
client = httpx.AsyncClient(timeout=httpx.Timeout(connect=5.0, read=120.0, write=10.0, pool=60.0))

@app.post("/v1/chat/completions")
async def forward_chat(request: Request):
    # 1. 简单的 Token 鉴权（根据业务可接 Redis 或 JWT）auth_header = request.headers.get("Authorization")
    if not auth_header or not auth_header.startswith("Bearer sk-nassky-"):
        raise HTTPException(status_code=401, detail="Invalid API Key")

    try:
        body = await request.json()
    except Exception:
        raise HTTPException(status_code=400, detail="Invalid JSON body")

    # 强制将 stream 设为 True 以降低首字等待体验
    body["stream"] = True

    async def stream_generator():
        try:
            req = client.build_request("POST", VLLM_UPSTREAM_URL, json=body)
            r = await client.send(req, stream=True)
            
            # 持续向前端透传流式 SSE 块
            async for chunk in r.aiter_raw():
                if chunk:
                    yield chunk
        except httpx.RequestError as exc:
            err_msg = json.dumps({"error": f"Upstream communication failure: {str(exc)}"})
            yield f"data: {err_msg}\n\n"
        finally:
            if 'r' in locals():
                await r.aclose()

    return StreamingResponse(stream_generator(),
        media_type="text/event-stream",
        headers={
            "Cache-Control": "no-cache",
            "Connection": "keep-alive",
            "X-Accel-Buffering": "no" # 关键：告诉 Nginx 禁用响应缓冲
        }
    )

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=9000, workers=4)

很多开发者在搭建完代理服务后，会发现流式输出依然会“卡顿”——前端总是一下子憋出几百个字，完全丧失了流式生成的逐字打字机效果。我在实际排查中发现，90% 的原因出在最外层的 NGINX 默认开启了 Proxy Buffering。

在 NGINX 的 location 块中必须做如下显式声明：

location /v1/chat/completions {
    proxy_pass http://127.0.0.1:9000;
    
    # 彻底关闭反向代理缓冲区，避免 SSE 数据包被凑成 4KB/8KB 才吐出
    proxy_buffering off;
    proxy_cache off;
    
    # 长连接保活与协议升级支持
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    
    # 超时时间放宽，防止模型长文本思考或输出时被切断
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
}

在单张 RTX 4090 显卡上，针对 Qwen2.5-7B-Instruct-AWQ，使用 Locust 进行并发压测（Prompt 长度约 512 Tokens，生成长度约 256 Tokens），实测结果对比显著：

部署方案	并发数 (Concurrency)	平均首字延迟 (TTFT)	每秒处理总 Token 数 (TPS)	GPU 显存利用状态
Ollama (默认配置)	16	2.48 s	142 tokens/s	单任务排队，显存空置多
vLLM (未调参默认)	16	1.12 s	380 tokens/s	容易报 CUDA OOM
vLLM (本文生产调优参数)	32	0.38 s	795 tokens/s	稳定在 92%，显存块分页高效

在单卡消费级显卡部署场景中，永远不要相信模型权重的裸参数吞吐。从工程角度来看，控制上下文上限（max-model-len）以换取并发深度 、 合理预留 PyTorch 临时算子显存 ，以及 彻底排查网关层（NGINX/HTTP 客户端）的缓冲区阻滞，是提升整套推理集群承载力的黄金三要素。这套架构目前支撑团队内部几十个自动化 Agent 每天数十万次请求，整体运行稳定，GPU 利用率维持在平滑的高位，是性价比极高的小团队落地解法。

===END===

正文完