告别OOM与高延迟：基于vLLM与Prefix Caching的高并发流式Agent代理实战

6次阅读

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

最近团队在把本地 Agent 接入知识库工作流时，遇到了一个极其恶心的瓶颈：只要三个以上并发任务同时跑长 Prompt（包含系统提示词、长文档注入与多轮对话历史），显存瞬间告急 OOM，首字延迟（Time-To-First-Token, TTFT）甚至直接飙到了 8 秒以上。

很多同学在搭建模型服务时，习惯直接丢一个 Ollama 或者未经调优的 HuggingFace TGI。对于单人本地玩具 Demo 确实够用，但在 Agent 多智能体协同、工具循环调用这种“长上下文、重复前缀”的高频场景下，原生推理机制的显存和算力浪费触目惊心。我在两张 RTX 4090 上针对主流开源模型（Qwen2.5-14B 与 Llama-3.1-8B）反复压测调优了两周，最终采用 vLLM + Prefix Caching + 异步 FastAPI 流式反代 的架构，把平均 TTFT 从 3800ms 压到了 240ms，吞吐量提升了将近 4 倍。下面把这套硬核落地细节完整拆解开来。

Agent 系统的底层本质是：极其冗长的固定前缀 + 微量的新生成 Token + 反复多次的请求循环。比如我们注入的代码规范、格式化约束（JSON Schema）以及外挂检索返回的 Top-K 文档，每次对话这部分内容几乎是静态不变的，往往占据 2k~6k Token。

传统推理框架对于每一个请求，哪怕前面 4000 个 Token 一模一样，也会从头重新做一次完整的 Self-Attention 计算，并分配新的 KV Cache 显存块。当 5 个并发请求过来，显存不仅重复存储了 5 份相同的 KV 缓存，计算单元还在疯狂做毫无意义的重复矩阵乘法，算力和显存双双被掏空。

解决这个痛点的关键在于 Automatic Prefix Caching (APC)。vLLM 自带的 PagedAttention 机制本身把显存管理做成了类似操作系统的虚拟内存分页，而 APC 则在此基础上把相同前缀的 KV Cache 做成了全局共享页。

如果请求 A 和请求 B 有相同的 System Prompt 和检索上下文，请求 B 会直接复用请求 A 已经算好的 KV 缓存，不仅跳过了庞大的 Prefill 计算阶段，而且几乎不额外占用这部分显存。要把它榨干，关键在于启动参数的精细控制：

# 启动优化后的 vLLM 服务端（以 Qwen2.5-14B-Instruct-AWQ 为例）python3 -m vllm.entrypoints.openai.api_server \
    --model /data/models/Qwen2.5-14B-Instruct-AWQ \
    --served-model-name qwen-agent \
    --gpu-memory-utilization 0.92 \
    --max-model-len 8192 \
    --max-num-seqs 64 \
    --enable-prefix-caching \
    --swap-space 16 \
    --enforce-eager \
    --port 8000 \
    --host 0.0.0.0

--enable-prefix-caching：核心开关，必须显式开启。注意：只有 prompt 中 从头部开始严格匹配 的部分才会命中缓存。
--gpu-memory-utilization 0.92：默认是 0.9。在 24G 显存卡上，留 8% 足够应对 CUDA Context 和临时的激活值开销，给 KV Cache 预留最大空间。
--swap-space 16：划出 16GB 的系统内存（CPU RAM）作为显存换入换出缓冲区。当并发过载时，暂时不用的 KV Cache 会被换出到内存，而非直接 crash 报 OOM。
--enforce-eager：对于 Agent 这种输入长度极其不规则（从 500 到 8000 波动）的场景，建议加上该参数跳过 CUDA Graph 的预编译，避免因为输入维度变化导致的显存碎片化与初始化假死。

后端模型稳了，如果前端和 API 网关层处理不当，客户端断开连接后后端还在死命生成，或者大并发下内存被挂起连接吃空，也是灾难。我们在模型与业务前端之间架设了一层轻量的高并发流式网关（FastAPI）：

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

app = FastAPI(title="LLM Stream Proxy Gateway")
VLLM_UPSTREAM_URL = "http://127.0.0.1:8000/v1/chat/completions"

# 维持一个长连接复用的 HTTP 客户端池，避免频繁握手消耗系统 fd
client_pool = httpx.AsyncClient(timeout=httpx.Timeout(connect=5.0, read=60.0, write=5.0, pool=10.0),
    limits=httpx.Limits(max_keepalive_connections=50, max_connections=200)
)

async def stream_generator(payload: dict, client_disconnect_event):
    """带断开探测与背压感知的流式转发器"""
    try:
        async with client_pool.stream("POST", VLLM_UPSTREAM_URL, json=payload) as upstream_resp:
            upstream_resp.raise_for_status()
            async for chunk in upstream_resp.aiter_bytes():
                # 关键：检查客户端是否已经挂断（例如前端关闭了页面或点击了取消生成）if await client_disconnect_event():
                    # 触发下游中断，上游连接上下文退出，通知 vLLM 取消生成
                    break
                yield chunk
    except httpx.HTTPError as exc:
        yield f'data: {{"error":"Upstream error: {str(exc)}"}}\n\n'.encode('utf-8')

@app.post("/v1/agent/chat")
async def agent_chat_proxy(request: Request):
    payload = await request.json()
    # 强制开启流式传输并配置参数对齐缓存命中规则
    payload["stream"] = True

    return StreamingResponse(stream_generator(payload, request.is_disconnected),
        media_type="text/event-stream",
        headers={
            "Cache-Control": "no-cache",
            "Connection": "keep-alive",
            "X-Accel-Buffering": "no" # 禁用 Nginx 缓冲区，保证打字机实时性
        }
    )

@app.on_event("shutdown")
async def shutdown():
    await client_pool.aclose()

这里有两个至关重要的实操细节：第一是 X-Accel-Buffering: no，如果外层套了 Nginx，没有这个 header 会导致 Nginx 强行攒够一个 buffer 块才发给前端，造成肉眼可见的“卡顿 - 爆发式输出”；第二是 request.is_disconnected 检测，一旦用户关闭窗口，连接立刻切断，vLLM 内部会捕获断连并立即终止当前 Sequence 的 Decode 阶段，瞬间释放算力。

我们使用 Locust 模拟 20 个高并发客户端，持续发送 3500 Token 上下文（含 3000 Token 固定 System/RAG 前缀 + 500 Token 随机提问），限制输出为 256 Token。硬件环境为单张 RTX 4090 24GB。

架构方案	Prefix Cache 状态	平均 TTFT (首字延迟)	系统生成吞吐量	并发峰值显存占用
原生 Ollama / 基础运行	未开启	4120 ms	28 tokens/s	OOM 崩溃 (>24GB)
vLLM 基础参数 (关闭 APC)	关闭	2850 ms	95 tokens/s	21.8 GB (排队严重)
vLLM + APC + 异步网关	命中率 ~88%	245 ms	360 tokens/s	18.5 GB (显存平稳)

从数据可以非常清晰地看出：当 Prefix Cache 命中后，TTFT 直接出现了数量级的暴降。对于 Agent 来说，用户几乎感觉不到后端正在经历长达 3k 词的提示词注入。

想要真正在生产环境把这套架构跑顺，务必牢记以下三条硬规则：

Prompt 结构严格规范化： Prefix Caching 的匹配是“从左至右逐字匹配”的。如果你的 Prompt 里把带有动态时间戳（如 Current time: 2026-10-26 22:01:05）放在了最开头，那么恭喜你，后面的几千字上下文缓存将全部失效。正确的做法是：绝对静态的系统人设与格式声明放在最顶层，随后是静态文档，最后才是会变动的历史上下文与当前时间戳。
警惕量化模型的精度陷阱： 使用 AWQ 或 GPTQ 量化时，部分早期版本的 Kernel 在支持 Prefix Caching 时存在显存泄漏 Bug。生产环境建议锁定 vLLM 核心依赖的稳定版本，优先选用 FP8（如果在 Ada/Hopper 架构上）或高质量的 AWQ 权重。
连接池的超时防御： Agent 工具调用有时候可能发生死循环或单步挂起，网关层的 read timeout 必须有兜底机制，防止个别异常任务霸占 vLLM 的 Sequence Slot 导致整体服务排队雪崩。

用成熟的系统级优化思维替代盲目的堆砌算力硬件，才能在有限的资源配额下，搭建出真正抗打的高并发 Agent 基础设施。

===EOF===

正文完