单卡4090跑满极限：vLLM高并发流式推理架构调优与避坑实战

5次阅读

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

上周帮一个做客服 Agent 的兄弟团队排查性能瓶颈，他们直接用 HuggingFace 原生 pipeline 裸启了一个 Qwen2.5-7B-Instruct 服务，外面套了层 FastAPI 走 SSE（Server-Sent Events）做流式输出。跑 Demo 时丝滑得很，但压测并发刚拉到 8 个，首字延迟（TTFT，Time To First Token）直接飙到 4.2 秒，紧接着就是经典的 CUDA out of memory。

很多开发者在玩本地大模型时，容易把“能跑通”等同于“能上生产”。实际上，在流式高并发场景下，原生 PyTorch 推理框架在显存管理（尤其是动态 KV Cache）和调度机制上非常原始。本文将结合我自己在单卡 RTX 4090（24G）环境下的压测数据，分享如何基于 vLLM 搭建一套稳定抗打的高并发流式推理网关，把单卡吞吐榨干到极限。

大模型推理是典型的 显存带宽受限（Memory-Bound）与 显存容量受限 任务，主要分为两个阶段：

Prefill（预填充阶段）：处理输入的 Prompt，显存计算密集型。
Decode（解码阶段）：自回归逐字生成，受限于显存带宽与 KV Cache 增长。

原生架构的核心痛点在于：每个并发请求的输出长度不可预估，为了避免频繁分配显存，系统往往会预先分配一块连续的显存空间（如按照 max_seq_len=4096 分配）。当并发稍微一涨，显存中充斥着大量未使用的显存碎片，明明只输出了十几个 token，显存池却已被占死，这就是为什么你 24G 的显存连 10 个并发都撑不住的原因。

解决这个死结的核心在于 PagedAttention 机制（vLLM 的基石），它借鉴了操作系统的虚拟内存分页思想，将 KV Cache 切片存放在不连续的物理显存块（Block）中，显存利用率能直接从不足 40% 暴力拉升至 95% 以上。

不要直接用纯 Python 脚本去跑 LLM(model=...)，生产环境下建议直接使用 vLLM 内置的高性能 OpenAI 兼容服务（基于 C++ 和 Triton 优化），配合 Docker 隔离环境。以下是我在单卡 RTX 4090 上验证过最稳定的 Docker Compose 配置：

version: '3.8'

services:
  vllm-engine:
    image: vllm/vllm-openai:v0.6.3.post1
    container_name: vllm-qwen7b
    runtime: nvidia
    environment:
      - CUDA_VISIBLE_DEVICES=0
      - NCCL_IGNORE_DISABLED_P2P=1
    ports:
      - "8000:8000"
    volumes:
      - /data/models/Qwen2.5-7B-Instruct:/model
      - ~/.cache/huggingface:/root/.cache/huggingface
    ipc: host
    command: >
      --model /model
      --served-model-name qwen-7b
      --trust-remote-code
      --dtype bfloat16
      --max-model-len 4096
      --gpu-memory-utilization 0.92
      --max-num-seqs 64
      --block-size 16
      --enable-chunked-prefill
      --disable-log-requests
    restart: unless-stopped

--gpu-memory-utilization 0.92：默认是 0.90。在 24G 显存下，模型权重占用约 14.5G，留给 KV Cache 的空间从 24 * 0.9 = 21.6G 提升到 24 * 0.92 = 22.08G，看似只多了 480MB，但在 block-size=16 下足以多容纳数百个并发请求的中间状态。注意不要设成 0.98，否则 CUDA Context 初始化或突发显存抖动会导致瞬时崩溃。
--enable-chunked-prefill：极其关键的参数。在大并发场景下，如果突然来一个长输入（比如 3000 tokens），传统处理方式会卡住整个推理线程去跑 Prefill，导致正在流式输出的请求出现明显的“打字停顿感”。开启分块预填充后，大输入会被切分为小 Chunk 与解码步骤并行，直接削平首字延迟波动。
--max-num-seqs 64：硬限制当前批次处理的最大并发序列数。根据你实际的业务 SLO（服务质量目标）设定，在 4090 上跑 7B 模型，设为 48 到 64 是性价比最高的区间。

很多工程师用 Python 转发流式请求时，习惯性写出同步阻塞代码，导致客户端请求在代理层排队，白白浪费了后端的吞吐。这里贴一个经过生产考验的异步流式转发客户端：

import httpx
from fastapi import FastAPI, Request
from fastapi.responses import StreamingResponse

app = FastAPI()

# 维持长连接池，严禁每次请求新建 Client
client = httpx.AsyncClient(
    base_url="http://127.0.0.1:8000",
    timeout=httpx.Timeout(connect=5.0, read=60.0, write=5.0, pool=10.0),
    limits=httpx.Limits(max_keepalive_connections=100, max_connections=200)
)

@app.post("/v1/chat/completions")
async def chat_proxy(request: Request):
    req_body = await request.json()
    req_body["stream"] = True  # 强制流式响应

    async def stream_generator():
        async with client.stream(
            "POST",
            "/v1/chat/completions",
            json=req_body,
            headers={"Authorization": "Bearer EMPTY"}
        ) as upstream_response:
            async for chunk in upstream_response.aiter_raw():
                # 直接按原始字节流推给前端，避开多余的反序列化与编码开销
                yield chunk

    return StreamingResponse(stream_generator(),
        media_type="text/event-stream",
        headers={
            "Cache-Control": "no-cache",
            "X-Accel-Buffering": "no" # 关键：防止 Nginx 缓冲区积攒导致流式失效
        }
    )

为了验证效果，我使用 Locust 编写了一个压测脚本，模拟真实交互场景（Prompt 长度 400~600 tokens，生成长度 200~300 tokens），在单张 RTX 4090 上对比原生 HuggingFace Text-Generation-Inference (TGI) 默认配置与本文优化后的 vLLM 方案：

指标	原生 PyTorch / TGI 默认	vLLM 极限调优版	提升幅度
最大支撑稳定并发 (Concurrency)	8 ~ 10	48	480%
平均首字延迟 (TTFT @ 并发 =30)	OOM 崩溃	320 ms	从不可用变为可用
生成吞吐量 (Total Tokens/s)	~ 180 tokens/s	1,150 tokens/s	6.38 倍
显存碎片占用率 (Fragmentation)	~ 45%	< 4%	近乎零碎片

可以看到，显存瓶颈被 PagedAttention 彻底解决后，GPU 的 Tensor Core 才算真正跑满，整体系统吞吐达到了 1150 tokens/s 以上，这对于单卡消费级显卡而言已经能够应对大部分中小规模生产环境的并发峰值。

在折腾本地推理和流式代理的过程中，有几个隐蔽的大坑一定要防范：

反向代理的 Buffer 陷阱：如果你的推理服务前面挂了 Nginx，必须在 location 块中加入 proxy_buffering off;。否则 Nginx 会等搜集到几 KB 数据后才刷给客户端，流式打字机效果瞬间全无。
KV Cache 量化需谨慎：虽然 vLLM 支持 --kv-cache-dtype fp8，能进一步把并发容量翻倍，但在我们实测中，小参数模型（如 7B/8B）在 FP8 KV Cache 下的推理长文本准确率有轻微崩塌（尤其在提取 JSON 结构化数据时）。除非显存吃紧，否则建议首选保持 bfloat16。
IPC 共享内存溢出：Docker 启动时千万别忘了加 ipc: host 或给足 --shm-size。当多进程 / 多并发处理张量传递时，默认的 64MB shm 会直接让底层 PyTorch 崩溃且报错日志极其隐晦。

单卡 4090 的算力上限远比我们想象的高，关键在于拒绝粗暴堆硬件，从调度底层的内存池切片与网络栈层面精细化榨取。这套方案不管是跑 Qwen、Llama3 还是 DeepSeek-R1 的蒸馏版，都能直接无缝套用。

正文完