单卡RTX 4090跑满满血Agent：vLLM + DeepSeek多并发流式网关工程化实战

4次阅读

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

上个月给团队内部搭建一套代码审查与 SQL 自愈 Agent，后端接的是单张 RTX 4090（24GB 显存）。刚跑两台并发测试还好，接入 IDE 插件做实时联调后，服务频繁直接触发 OOM，首字延迟（TTFT）从几百毫秒飙升到 4 秒以上，客户端连接甚至频频超时断开。很多人在本地搞 Agent 往往只停留在用 Ollama 跑个 demo，但只要进入多 Agent 长上下文（Long-Context）调用和并发流式阶段，原生的轻量工具就完全撑不住了。

本文记录我将单卡 4090 压榨到极致、构建高并发流式推理网关的完整工程化方案，使用 vLLM 配合自定义异步反向代理，彻底解决 Prefix Cache 命中率、显存碎片以及客户端流式断开泄露连接的核心痛点。

跑 Agent 工作流与普通单轮聊天有本质区别：

上下文膨胀极快：Agent 通常携带大量 System Prompt、Few-Shot 样例以及复杂的 JSON Schema/Tool 定义，基础 Prompt 轻松突破 3K~4K tokens。
KV Cache 重复计算严重：在 ReAct 多步推理循环中，每一轮 Tool Calling 都在重复传回前面的 Prompt 前缀。如果推理引擎没有高效的跨请求 KV Cache 共享机制，GPU 算力全耗在重复预填充（Prefill）阶段。
流式响应挂起导致连接泄漏：前端或调用端网络不稳定时，如果客户端断开连接，后端的推理任务若没有主动感知取消，GPU 会白白生成无用 Token 直到达到最大长度。

对于单卡 24GB 显存，选用类似 DeepSeek-R1-Distill-Qwen-14B-AWQ 或 Qwen2.5-14B-Instruct-GPTQ-Int4 是能兼顾推理逻辑深度与并发吞吐的黄金比例（FP16 模型必须占 28GB 以上显存，4090 单卡无法承载，量化版本则是单卡首选）。

这是我反复测试后写进生产环境的 docker-compose.yml 启动配置，每一个核心参数都踩过深坑：

version: "3.8"
services:
  vllm-engine:
    image: vllm/vllm-openai:latest
    container_name: vllm-deepseek-backend
    runtime: nvidia
    environment:
      - CUDA_VISIBLE_DEVICES=0
      - NCCL_IGNORE_DISABLED_P2P=1
    ports:
      - "8000:8000"
    volumes:
      - /data/models/DeepSeek-R1-Distill-Qwen-14B-AWQ:/model
    command: >
      --model /model
      --served-model-name deepseek-14b
      --quantization awq
      --max-model-len 8192
      --gpu-memory-utilization 0.92
      --max-num-seqs 16
      --enable-prefix-caching
      --enforce-eager
      --disable-log-requests
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    restart: unless-stopped

--enable-prefix-caching：Agent 场景的救命神器。开启后，相同 System Prompt 和 Tool 定义的请求会自动复用显存中的 KV Cache。实测在第二轮工具循环时，首字延迟（TTFT）从 1200ms 断崖式下降到 120ms 以内。
--gpu-memory-utilization 0.92：默认是 0.90。4090 物理显存 24576MB，留出约 2GB 防显存波动，其余 22GB 交给模型权重和 KV Cache 块管理。
--max-num-seqs 16：限制并发槽位数。不要贪多，单卡在长上下文下并发超 16 后吞吐曲线会发生断崖，限制并发才能保证单个请求的 Token 生成速率稳定在 40+ tokens/s。
--enforce-eager：AWQ 量化模型在某些 CUDA 版本下编译 CUDA Graphs 耗时极长且容易爆显存，加此参数跳过 Graph Capture，冷启动从 5 分钟降为 15 秒。

如果直接将 vLLM 暴露给上层服务，只要客户端主动关闭（例如用户在前端点击了“停止生成”或 Agent 链路超时），vLLM 可能依旧在后台消耗显卡算力直到生成完毕。我们需要一层轻量但高吞吐的 FastAPI 反向代理做流式拦截与断开监听：

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

app = FastAPI(title="LLM-Streaming-Gateway")

VLLM_UPSTREAM_URL = "http://127.0.0.1:8000/v1/chat/completions"
# 建立长连接池，复用连接降低开销
client = httpx.AsyncClient(timeout=httpx.Timeout(connect=5.0, read=60.0, write=5.0, pool=30.0))

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

    if not is_stream:
        # 非流式直接转发
        resp = await client.post(VLLM_UPSTREAM_URL, json=body)
        return resp.json()

    # 流式处理并检测客户端连接状态
    async def event_generator():
        try:
            async with client.stream("POST", VLLM_UPSTREAM_URL, json=body) as upstream_response:
                async for chunk in upstream_response.aiter_bytes():
                    # 关键逻辑：检测调用方是否已经断开 TCP 连接
                    if await request.is_disconnected():
                        # 客户端断开，退出生成器，httpx 会自动断开上游连接通知 vLLM 终止
                        break
                    yield chunk
        except Exception as e:
            # 记录异常上下文，避免静默挂掉
            yield f"data: {{\"error\": \"Proxy stream error: {str(e)}\"}}\n\n".encode("utf-8")

    return StreamingResponse(event_generator(),
        media_type="text/event-stream",
        headers={
            "Cache-Control": "no-cache",
            "Connection": "keep-alive",
            "X-Accel-Buffering": "no"  # 关闭 Nginx 缓存，保证极致首字响应
        }
    )

避坑提示：如果你前面还挂了一层 Nginx，必须在 location 块中显式指定 proxy_buffering off; 和 proxy_read_timeout 600s;，否则 Nginx 会强制缓存 4KB 数据才向前端推送，导致流式打字机效果瞬间变成“憋大招突然弹出一堆字”。

我们采用 locust 模拟 Agent 场景：统一注入 4KB 的固定 System Prompt（内含各类工具规范）+ 动态的用户代码片段，并发从 1 逐渐加压到 12，测试开启 Prefix Caching 前后的指标差异：

测试场景（并发 =8，长上下文 4K）	首字延迟（TTFT）	解码速率（Decode/GPU）	显存占用稳定性
未开启 Prefix Cache (原生配置)	2480 ms	118 tokens/s	易抖动，高并发时频繁触发抢占
开启 Prefix Cache + PagedAttention 调优	830 ms (-66%)	312 tokens/s (+164%)	KV Cache 块固定平稳，显存无碎片

实测数据证明，在重复度极高的 Agent 调用链条下，Prefix Caching 几乎让显卡的预填充计算量降低了 60% 以上，省下来的算力直接反哺给解码吞吐。

在消费级显卡上榨取生产级性能，本质就是在 有限显存容量 与并发吞吐需求 之间做极限权衡：

模型选型别盲目求大：4090 单卡不要硬上 FP16 的 14B 或 32B，14B 量化版本（AWQ/GPTQ-Int4）在绝大部分内部 Agent 任务中的表现已经极其出色，留足 KV Cache 空间才是保障并发的基石。
必须重视客户端挂起：流式网关必须做断开侦测（is_disconnected），没有这套机制，单个 Agent 死循环能把整张显卡的算力队列卡死数分钟。
禁用一切上游缓存：从 Python 网关到 Nginx，再到前端 Client，一律关闭流式响应缓存，否则极速推理的优势会在网络栈上全被消耗掉。

===END===

正文完