单卡跑满千级并发：基于 vLLM + FastServe 构建私有 LLM 流式网关实战

2次阅读

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

很多朋友自己买了单张 RTX 4090 或租了 A100/H100 跑本地大模型，用 Ollama 或者纯 HuggingFace Transformers 写个 FastAPI 接口，单人测试时响应飞快；可一旦接入 Dify、FastGPT 或者内部业务系统，并发上到 20 个人同时问答，就会出现诡异的假死： 显存瞬间暴涨 OOM、首字输出延迟（TTFT）从 200ms 飙到 8 秒以上，甚至客户端直接收到 Connection Reset。

上个月我给一家做智能客服方案的团队重构底层推理集群时，就撞上了这个典型场景：模型选用 Qwen2.5-14B-Instruct，业务高峰期要求支撑 800+ 活跃长连接 SSE（Server-Sent Events）流式并发。今天这篇文章不谈空洞的概念，直接拿我们在生产环境跑通的 vLLM 引擎参数调优 + 边缘流式反向网关架构 ，手把手拆解如何榨干单卡的每一兆显存与算力。

在动手改代码前，必须搞清楚传统方案到底死在哪里。标准 Transformers 推理在长会话流式交互时，有两个致命短板：

KV Cache 静态显存预分配导致碎片化 ：传统实现通常给每个并发请求分配固定上限的 KV Cache 内存空间。一个支持 8K 上下文的模型，哪怕用户只输入了 10 个 token，系统也可能按大容量去占位，导致单卡并发只要超过 16 个就触发显存溢出。
Naive Streaming 阻塞 Event Loop：很多工程师在 Python 里使用 TextIteratorStreamer 并直接丢进 StreamingResponse。由于 GIL 和生成器调度的影响，几十个并发生成循环同时 yield，异步事件循环直接被 CPU 密集型的 tokenizer 解码锁死。

解决这个问题的底座是 vLLM 的 PagedAttention 与连续批处理（Continuous Batching）。它把显存当成操作系统的虚拟内存分页来管理，KV Cache 不再需要连续显存空间，极大降低了显存碎片，直接让显存利用率逼近 96% 以上。

不要直接裸跑 vllm serve 默认参数，生产环境下这几个参数必须根据显卡规格精细计算：

#!/usr/bin/env bash
# 启动生产级 vLLM 服务节点（以 24G 显存单卡 RTX 4090 运行 AWQ 量化版 Qwen2.5 为例）python3 -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-14B-Instruct-AWQ \
    --quantization awq_marlin \
    --host 127.0.0.1 \
    --port 8000 \
    --max-model-len 8192 \
    --gpu-memory-utilization 0.92 \
    --max-num-seqs 256 \
    --max-num-batched-tokens 8192 \
    --block-size 16 \
    --swap-space 8 \
    --disable-log-requests \
    --enable-chunked-prefill

--quantization awq_marlin：AWQ 配合 Marlin 内核，在现代 Ampere/Ada 架构 GPU 上比单纯 AWQ 解量化推理吞吐高出 30%~50%，显存占用从 FP16 的 28GB 骤降至 9.5GB 左右。
--gpu-memory-utilization 0.92：千万不要拉满到 1.0，留出 8% 给 CUDA runtime、激活层临时缓冲区以及系统上下文，否则长序列忽然暴增时必爆 CUDA illegal memory access。
--enable-chunked-prefill：这是 vLLM 近期版本最实用的优化项之一。它把长 prompt 的 Prefill 过程切块，与正在进行 Decode 的请求混批， 彻底消除了因为某个用户发了 4000 字长文本而导致其他所有人输出卡顿几秒的“霸屏延迟”。

vLLM 自带的 API Server 满足了基本的 OpenAI 协议，但在高并发流式业务中，直接暴露它依然有隐患：无法平滑限流、缺乏客户端断开的主动取消（Cancelation）、缺少针对通用前缀的缓存层。我们需要在前端挂一层轻量级的 Python 异步网关。

这里给出一份基于 httpx + FastAPI 的流式透明转发与客户端断连感知代理核心实现：

# gateway.py
import asyncio
from fastapi import FastAPI, Request
from fastapi.responses import StreamingResponse
import httpx

app = FastAPI()

# 维持到后端 vLLM 的长连接池
BACKEND_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=500, max_connections=1000)
)

@app.post("/v1/chat/completions")
async def proxy_chat_completions(request: Request):
    req_body = await request.json()
    is_stream = req_body.get("stream", False)

    if not is_stream:
        # 非流式直接转发
        resp = await BACKEND_CLIENT.post("/v1/chat/completions", json=req_body)
        return resp.json()

    # 流式传输处理：支持客户端断开检测与上游取消
    async def event_generator():
        try:
            req = BACKEND_CLIENT.build_request("POST", "/v1/chat/completions", json=req_body)
            response = await BACKEND_CLIENT.send(req, stream=True)
            
            async for chunk in response.aiter_raw():
                # 检查客户端是否已断开连接（如用户在界面点击了“停止生成”）if await request.is_disconnected():
                    # 及时中止生成，释放 vLLM 的 Decode 算力
                    await response.aclose()
                    break
                yield chunk
        except asyncio.CancelledError:
            # 客户端连接重置触发
            pass

    return StreamingResponse(event_generator(),
        media_type="text/event-stream",
        headers={
            "Cache-Control": "no-cache",
            "Connection": "keep-alive",
            "X-Accel-Buffering": "no"  # 禁用 Nginx 默认的 4k 缓冲，关键！}
    )

避坑高光点： 注意响应头中的 X-Accel-Buffering: no。如果你的架构外层挂了 Nginx，Nginx 默认会把 SSE 的响应攒够 4KB 或者换行才统一刷新给浏览器，这会导致前端用户眼里的流式输出变成“卡死 3 秒后一口气吐出一大坨”，毫无打字机效果。

为了验证这套组合拳的实际效果，我在单张 A10 (24GB) 实例上，使用 locust 对同一模型（Qwen2.5-7B-Instruct）在不同配置下进行了阶梯并发压测（Prompt 长度统一为 512 tokens，生成长度为 256 tokens）：

部署方案	并发用户数	首字延迟 (TTFT P95)	端到端生成吞吐 (tokens/s)	显存占用率
Transformers + FastAPI 裸写	30	6,820 ms	94	99% (偶发 OOM)
vLLM (默认参数单进程)	100	840 ms	520	89%
vLLM (优化配置 + 异步网关)	300	310 ms	1,480	92% (平稳无溢出)

实测数据一目了然：在 chunked-prefill 和 AWQ Marlin 内核的配合下，高并发状态下的 TTFT 缩短了超过一半，整体吞吐提升了近 3 倍，并且成功抵抗住了 300 并发同时请求的冲击，没有发生任何显存泄露或崩盘。

搭建本地模型高并发服务时，很多新手容易一上来就陷入“买更多卡”的硬件陷阱。事实上，单张消费级显卡或中端推理卡的潜能远未被榨干。回顾这次落地过程，有三点教训值得牢记：

流式响应切忌绕远路 ：不要在网关层对 SSE 的 chunk 随意做 json.loads() 再 json.dumps()，直接按 Raw Byte 流式透传，CPU 占用率能直降 40%。
一定要处理 Client Disconnect：前端用户关掉标签页或点击“重新生成”是高频操作。如果后端网关没有感知机制，模型就会在后台默默把后面的几百个 token 全部跑完，严重浪费宝贵的计算周期。
善用 Prefix Caching：如果有固定的 System Prompt（比如几十条预设规则的 Agent），在 vLLM 启动参数加上 --enable-prefix-caching，多轮对话的上下文匹配延迟几乎能降至接近 0ms。

整套链路打通后，无论是接入前端 Web 还是支撑自动化 Agent 工作流，都能做到低延迟、高韧性，这才是单机本地部署真正实用化的正确姿势。

正文完