单卡4090跑满吞吐：vLLM与FastAPI流式网关高并发工程化改造实战

8次阅读

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

最近我把团队内部的几个知识库问答和代码补全任务，从公有云 API 全量迁移到了自建的单卡 RTX 4090（24G）机器上。原本以为上了业界标配的 vLLM 就万事大吉，结果并发压测刚加到 20，直接教我做人：显存频繁 OOM、前端打字机效果卡死在半路、首字延迟（TTFT）一路飙到了 3.8 秒。

很多开源教程教你在命令行跑一行 python -m vllm.entrypoints.openai.api_server 就算完工，但这套配置放到真实业务场景下脆得像饼干。为了搞定高并发流式传输（SSE）、降首字延迟并防止长上下文把显存吃爆，我花了整整一个周末重新重构了推理层与接入网关。今天把这套经过压测验证的生产级部署方案和填坑经验完整掏出来。

在排查问题时，我用 Locust 模拟并发请求抓取性能指标，发现了三个致命瓶颈：

KV Cache 预留分配激进：vLLM 默认会把 gpu_memory_utilization 设为 0.9。对于 24G 显存的 4090 来说，加载 14B Q4_K_M 或 7B FP16 模型后，剩余显存几乎被 KV Cache 强行占满。如果模型运行时有临时显存尖峰，CUDA 瞬间爆显存挂掉。
HTTP 网关长连接泄露：当客户端在流式输出中途关闭浏览器或断开连接时，上游 FastAPI 如果没有捕获到 ClientDisconnect 信号，vLLM 后端依然会在后台把所有 token 生成完毕，导致 GPU 算力严重白白浪费。
调度器争抢导致 TTFT 恶化：如果不做请求队列优先级与 Chunk 聚合，高并发下所有请求并发争抢 Pre-fill 阶段资源，所有人的第一个字都出不来。

针对 24GB 显存，我们以 Qwen2.5-7B-Instruct（或同等尺度的 Llama-3-8B）为例。下面是我调试出来的最优启动参数，重点在于权衡 Pre-fill 吞吐与显存碎片率：

#!/usr/bin/env bash
# 启动生产级 vLLM 推理节点
python3 -m vllm.entrypoints.openai.api_server \
    --model /data/models/Qwen2.5-7B-Instruct \
    --served-model-name qwen-7b \
    --host 127.0.0.1 \
    --port 8000 \
    --dtype bfloat16 \
    --max-model-len 8192 \
    --gpu-memory-utilization 0.85 \
    --block-size 16 \
    --swap-space 4 \
    --max-num-seqs 64 \
    --max-num-batched-tokens 4096 \
    --disable-log-requests

--gpu-memory-utilization 0.85：不要贪心设 0.9 或 0.95。4090 扣掉显存上下文和 CUDA Context 后，留 15% 的缓冲余量（约 3.6GB）是防御 CUDA OOM 的生命线。
--block-size 16：PageAttention 内存块默认是 16。对于长短文本混杂的对话场景，16 比 32 造成的内部显存碎片更少。
--max-num-batched-tokens 4096：控制单次迭代中最多处理的输入 token 数量。如果不设上限，一个突然进来的 6k token 提示词会直接打断正在运行的 Decoding 批处理，导致已连上用户的流式输出瞬间掉帧。

直接把 vLLM 暴露给前端是极其危险的。我们需要一层高性能代理，用于处理 API Key 校验、请求限流、敏感词拦截以及 客户端断流时即时中断推理。以下是我自研的核心流式代理网关核心实现：

import httpx
from fastapi import FastAPI, Request, HTTPException
from fastapi.responses import StreamingResponse
from contextlib import asynccontextmanager

VLLM_BACKEND_URL = "http://127.0.0.1:8000/v1/chat/completions"

# 维护全局持久连接池，避免频繁握手消耗系统 FD
client: httpx.AsyncClient = None

@asynccontextmanager
async def lifespan(app: FastAPI):
    global client
    limits = httpx.Limits(max_keepalive_connections=100, max_connections=200)
    timeout = httpx.Timeout(connect=5.0, read=60.0, write=5.0, pool=5.0)
    client = httpx.AsyncClient(limits=limits, timeout=timeout)
    yield
    await client.aclose()

app = FastAPI(lifespan=lifespan)

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

    async def event_generator():
        try:
            req = client.build_request("POST", VLLM_BACKEND_URL, json=payload)
            response = await client.send(req, stream=True)
            
            if response.status_code != 200:
                yield f"data: {{\"error\": \"Upstream returned {response.status_code}\"}}\n\n"
                return

            async for line in response.aiter_lines():
                # 核心避坑点：主动探测客户端断连，立即中止生成
                if await request.is_disconnected():
                    # 终止迭代，httpx 离开上下文将切断请求，释放 vLLM 算力
                    break
                
                if line:
                    yield f"{line}\n\n"
        except httpx.RequestError as exc:
            yield f"data: {{\"error\": \"Proxy error: {str(exc)}\"}}\n\n"
        finally:
            if 'response' in locals():
                await response.aclose()

    return StreamingResponse(event_generator(),
        media_type="text/event-stream",
        headers={
            "Cache-Control": "no-cache",
            "Connection": "keep-alive",
            "X-Accel-Buffering": "no" # 彻底禁用 Nginx 反向代理缓存
        }
    )

代码中注意看 X-Accel-Buffering: "no"。如果你的网关外层套了 Nginx 反向代理，Nginx 默认会积攒大约 4KB 响应后才一次性冲刷给浏览器。前端看到的效果就是“先卡 5 秒，然后一大坨字瞬间刷出来”。加上这个 Header，Nginx 才会真正实现零缓冲逐字推送。

为了让整套环境一键拉起并支持热重启，我把 vLLM 与 FastAPI 网关编排成同一套 docker-compose.yml。这里重点配置了 NVIDIA Container Toolkit 的显存锁定参数：

version: '3.8'

services:
  vllm-engine:
    image: vllm/vllm-openai:v0.6.3
    container_name: vllm-engine
    restart: unless-stopped
    ipc: host
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    volumes:
      - /data/models:/data/models
    environment:
      - HUGGINGFACE_HUB_CACHE=/data/models
    command: >
      --model /data/models/Qwen2.5-7B-Instruct
      --served-model-name qwen-7b
      --host 0.0.0.0
      --port 8000
      --gpu-memory-utilization 0.85
      --max-model-len 8192
      --max-num-seqs 64
    networks:
      - ai-internal

  api-gateway:
    build:
      context: ./gateway
    container_name: api-gateway
    restart: unless-stopped
    ports:
      - "8080:80"
    environment:
      - VLLM_BACKEND_URL=http://vllm-engine:8000/v1/chat/completions
    depends_on:
      - vllm-engine
    networks:
      - ai-internal

networks:
  ai-internal:
    driver: bridge

这里必须设置 ipc: host。vLLM 底层利用 PyTorch 分布式通信和共享内存，如果 Docker 默认 shm 空间太小（默认只有 64M），多线程数据传输会直接触发莫名其妙的 Bus error (core dumped)。

我在本地用客户端通过 1000 轮请求进行了压力测试，对比默认原生配置与经过上述参数优化 + 网关代理后的表现（测试模型：Qwen2.5-7B-Instruct，平均 Prompt 长度 800 tokens，生成长度 300 tokens）：

性能指标	原生直接暴露	经过工程调优与网关管控	改善幅度
并发 30 下 OOM 次数	14 次崩溃重启	0 次	完美稳定
平均首字延迟 (TTFT)	3,120 ms	480 ms	降低 84.6%
系统吞吐量 (Tokens/s)	112.4	286.7	提升 155%
中途断连资源浪费率	~40% 显卡空转	< 2%（即刻中断）	大幅节省算力

折腾私有化大模型部署，千万不要迷信“参数拉满就是性能最强”。单张 24G 消费级显卡虽然核心算力不错，但显存带宽和容量是绝对的物理天花板。总结三条核心经验：

留出显存安全边际：gpu-memory-utilization 别拉过 0.88，宁可在并发超载时让网关返回 429 限流，也坚决不要让推理引擎抛出 CUDA OOM 导致全盘崩溃。
长连接必须主动监控中断：大模型按 Token 计费和消耗算力。网关层监听客户端生命周期并主动打断生成，在实际多人高频使用中能省下一半的 GPU 算力。
善用系统共享内存：使用容器部署时牢记配置 ipc: host，否则在高并发共享内存交换数据时，随处可见诡异段错误。

这套方案已经在我的小型团队服务器上连续稳定跑了三周，CPU 负载平稳，显卡风扇也不会再神经质地骤停暴转。如果你也在用单卡搭建业务接口，不妨按照这套架构重构试试。

===EOF===

正文完