本地vLLM+Nginx流式网关高并发调优：突破TTFT延迟与显存瓶颈实战

3次阅读

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

在私有服务器上给团队跑开源模型（如 Qwen2.5-7B/32B 或 DeepSeek-R1 蒸馏版），不少开发者第一反应是用 Ollama 快速起一个服务。但当并发数从 2 爬升到 30，前端对接聊天界面的 SSE（Server-Sent Events）流式输出就会开始像便秘一样卡顿，首字延迟（TTFT）从几百毫秒飙升到十几秒，显存还动不动直接抛出 CUDA Out of Memory。想要撑起生产级或高频内部业务的流式请求，我们需要一套严肃的推理引擎与反代组合：vLLM + 针对 SSE 优化的 Nginx 网关 。

在搭建这套架构之前，我带团队压测时踩过三个极具隐蔽性的坑：

反向代理的 Buffer 陷阱 ：Nginx 默认会把后端的响应全部缓存到 proxy_buffers 中，直到凑满一定数据块或者后端连接关闭才推给客户端。这直接导致前端的流式打字机效果失效，用户在屏幕前干等五六秒，最后“啪”一下整段弹出来。
PagedAttention 显存超额分配与碎片 ：vLLM 的核心优势是 PagedAttention，但默认的 --gpu-memory-utilization 0.90 配合长上下文（如 32k），在多请求交叉打进来时，K-V Cache 很容易被打爆，触发引擎内部的主动熔断或直接崩溃。
调度策略与 Prefill/Decode 冲突 ：大并发下，新进来的请求（Prefill 阶段，算力密集）会持续打断正在逐步吐字（Decode 阶段，显存带宽密集）的请求，造成正在输出的流严重丢帧、抖动。

抛弃默认启动命令，针对单卡 RTX 4090（24G）跑 Qwen/Qwen2.5-7B-Instruct（Awq/GPTQ 量化或 FP16）或者双卡 A6000 跑 32B，我在生产环境下固化了一套兼顾吞吐量和延迟的 Docker 启动配置：

# Docker 生产启动命令范式
docker run -d \
  --name vllm-inference \
  --runtime nvidia \
  --gpus all \
  -v /data/models:/models \
  -p 8000:8000 \
  --ipc=host \
  vllm/vllm-openai:latest \
  --model /models/Qwen2.5-7B-Instruct \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.88 \
  --max-model-len 8192 \
  --max-num-seqs 64 \
  --max-num-batched-tokens 4096 \
  --enable-chunked-prefill \
  --disable-log-requests

--gpu-memory-utilization 0.88：强烈建议不要填满 0.95。留出 12% 的显存冗余，是为了防止 CUDA Context 突增、PyTorch 底层内存碎片或系统额外开销导致 OOM。
--max-num-seqs 64：硬限制当前显卡上同时处于 active 状态的并发请求数。超过该数量的请求会在 vLLM 内部排队，避免把 K-V Cache 彻底挤爆。
--enable-chunked-prefill： 最核心的优化项 。将大 Prompt 的 Prefill 过程切片，穿插在各并发的 Decode 阶段中，避免长输入突然卡死所有当前正在生成的流式输出。实测能让 P99 首字延迟下降 40% 以上。
--disable-log-requests：高并发下 stdout 频繁写日志会成为严重的 CPU 阻塞瓶颈，关闭后推理吞吐提升明显。

很多开发者把 vLLM 跑起来后，直接用官方的 proxy_pass http://127.0.0.1:8000; 转发，结果不是流式断裂就是报 504 Gateway Timeout。支持 SSE 的高并发反代配置需要彻底重写：

upstream vllm_backend {
    server 127.0.0.1:8000;
    keepalive 64; # 维持与后端推理实例的长连接池，消除握手开销
}

server {
    listen 80;
    server_name ai-api.nassky.local;

    # 针对 SSE / 流式生成 API 路径的核心配置
    location /v1/chat/completions {
        proxy_pass http://vllm_backend;
        
        # 1. 彻底禁用响应缓冲，确保流式 Token 实时下发
        proxy_buffering off;
        proxy_cache off;
        chunked_transfer_encoding on;

        # 2. 维持 HTTP/1.1 长连接
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        
        # 3. 透传真实客户端信息与 SSE 协议头
        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_set_header Accept-Encoding ""; # 避免开启 gzip 导致流式输出被截留压缩

        # 4. 延长推理超时时间（避免长思考模型如 DeepSeek-R1 导致网关掐线）proxy_connect_timeout 60s;
        proxy_read_timeout 600s;
        proxy_send_timeout 600s;
    }
}

在这套配置中，proxy_buffering off; 是第一条红线。同时，必须显式重设 Accept-Encoding ""，因为如果上游 Nginx 或客户端默认请求了 gzip/br，某些反代中间件会自动尝试把整个 body 读全再压缩发送，这会从协议层直接扼杀流式体验。

为了验证这套工程化架构的有效性，我使用开源压测脚本，对单张 RTX 4090 运行 Qwen2.5-7B-Instruct（4-bit AWQ）进行了两轮压测（Prompt 长度统一为 1024 tokens，生成长度为 256 tokens，并发逐步提升至 32）：

指标参数	默认配置 (Ollama/ 原生 vLLM)	vLLM 调优 + Nginx 穿透	优化幅度
TTFT (首字延迟) P50	840 ms	210 ms	降低 75.0%
TTFT (首字延迟) P99	14,200 ms	1,850 ms	降低 86.9%
Token 吞吐量 (tokens/s)	420 tokens/s	1,150 tokens/s	提升 173.8%
32 并发请求成功率	78.1% (显存溢出重试)	100% (排队平滑处理)	彻底消除 OOM

从数据可以清晰看出：开启 --enable-chunked-prefill 配合限制合理的队列长度后，尽管在极限并发下系统整体吞吐逼近硬件物理极限，但每个用户感知的首字吐出速度（TTFT）维持在毫秒至 1 秒级，体验平滑，彻底告别了“前一个人发个大 prompt，全办公室所有人屏幕跟着卡死”的窘境。

在长期部署运维中，建议配置以下检查流程：

排查客户端假死 ：如果用户反馈界面完全不吐字，首先检查浏览器 DevTools 的 Network 面板。如果 chat/completions 请求的状态一直是 Pending 且没有收到任何 EventStream 数据帧，90% 是 Nginx 层的 proxy_buffering 没有成功生效，或者前置 CDN（如 Cloudflare）开启了 Auto Minify / Polish 等压缩缓存特性。
监控显存排队比率 ：vLLM 自带 Prometheus 监控接口（默认 /metrics）。重点盯住 vllm:num_requests_waiting（等待队列）和 vllm:gpu_cache_usage_factor（K-V Cache 使用率）。如果 GPU Cache 长时间处于 95% 以上且排队数激增，说明当前模型参数量或上下文上限已经超过单卡负载，必须通过增加卡数部署 Tensor Parallelism 或直接配置上游限流（如 Nginx limit_req）。

把大模型从“单人玩具”变成“高并发生产工具”，核心从来不是一味堆砌显卡硬件，而是在整个流量链路——从客户端 SSE 协议解析、Nginx 网关穿透、到 vLLM 的 PagedAttention 显存池划分——做好全链路优化。对于中小型开发团队或自建私有化算力的极客来说，先用好 Chunked Prefill 和 Nginx 的流式零缓冲，往往比盲目升级集群更具性价比。

===END===

正文完