单卡搞定私有化Agent推理：vLLM + Qwen2.5 极致调优与高并发避坑指南

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

很多朋友在本地跑大模型做 Agent 自动化工作流时，第一反应往往是装个 Ollama。对于个人随便聊两句，Ollama 确实开箱即用；但只要你把并发请求拉上来，或者让 Agent 挂载几个工具连续执行 Multi-turn 对话，Ollama 就会因为缺乏针对高并发的细粒度显存调度机制，导致 TTFT（首字延迟）急剧拉长，甚至直接爆显存崩掉。

上周我在公司的一台单卡 RTX 4090（24GB）工作站上重构推理集群，将底层的推理引擎彻底切到了 vLLM，结合 Qwen2.5-14B-Instruct-AWQ 模型，通过精细调教 PagedAttention 和 Nginx 流式代理，不仅将 10 并发下的流式吐字延迟从 1.8 秒压到了 200ms 以内，还彻底根治了长上下文导致的 OOM。今天把这套经过压测验证的生产级配置与踩坑细节完整复盘出来。

一、为什么 Ollama 不适合做并发 Agent 推理底座？

在讨论配置之前，先说清楚核心痛点。Agent 工作流不同于普通单轮对话：

• Prompt 极长：System Prompt 塞入了一堆 Tool Schema、Few-shot 示例，初始上下文动辄 3k~6k tokens。
• KV Cache 膨胀剧烈：Agent 每一次 ReAct 循环都会把上一轮的思考与工具返回拼接进去，KV Cache 随着轮数呈线性甚至指数级上升。
• 并发吞吐瓶颈：Ollama 底层的 llama.cpp 默认动态批处理（continuous batching）调度粒度较粗，多客户端并发请求排队严重。

而 vLLM 依靠 PagedAttention 技术，把显存中的 KV Cache 像操作系统的虚拟内存分页一样管理，几乎消除了显存碎片。配合 Continuous Batching，同样一张 24G 显存的卡，吞吐量至少能翻 3 倍以上。

二、基于 Docker 部署 vLLM + Qwen2.5 服务

为了环境干净，直接采用 Docker 容器化启动。先别急着 docker run，模型权重推荐使用 AWQ 4-bit 量化版。对于 14B 模型，FP16 纯权重就占了 28GB，4090 根本吃不下；而 AWQ 量化后权重仅占约 9GB，留出足足 14GB 的显存完全分配给 KV Cache，能够轻松撑住 32k 的长上下文。

1. 核心启动脚本

创建 start_vllm.sh 并执行：

#!/usr/bin/env bash

# 挂载宿主机的 HuggingFace 缓存目录与模型存储
MODEL_PATH="/data/models/Qwen2.5-14B-Instruct-AWQ"

docker run -d \
  --name vllm-qwen \
  --runtime nvidia \
  --gpus all \
  -v ${MODEL_PATH}:/model \
  -p 8000:8000 \
  --ipc=host \
  vllm/vllm-openai:v0.6.3.post1 \
  --model /model \
  --served-model-name qwen2.5-14b \
  --quantization awq \
  --dtype half \
  --gpu-memory-utilization 0.92 \
  --max-model-len 16384 \
  --max-num-seqs 16 \
  --enforce-eager \
  --disable-log-requests

2. 核心启动参数避坑解析

这里的每一个参数都是我踩过坑换来的经验，千万不要照抄官方默认值：

• --gpu-memory-utilization 0.92：默认是 0.90。设为 0.92 意味着在 24GB 显存中，扣除 CUDA runtime 预留显存和模型静态显存后，最大化分配给 KV Cache。但切记 不要设成 0.98 或更高，否则 PyTorch 运行时遇到突发动态分配会立刻抛出 CUDA out of memory。
• --max-model-len 16384：Qwen2.5 原生支持 128k 上下文，如果这里不主动截断，vLLM 会默认尝试预分配长上下文所需的 KV Cache 槽位，直接导致启动时报错显存不足。Agent 场景下，16k 已经足够应付 95% 的自动化调用。
• --max-num-seqs 16：限制最大并发推理请求数。设置太高会导致多任务排队平摊算力，Token 吐字速度被稀释到不可用；16 是单张 4090 在 14B 模型下的甜点并发值。
• --enforce-eager：非常关键！ vLLM 默认会开启 CUDA Graph 捕获优化，这会占用近 1~2GB 的显存用来做图捕获缓存。在 24GB 临界显存下，加上这个参数强制使用 Eager 模式，可以把这部分显存腾出来给上下文，代价仅是微乎其微的推理延迟增加。

三、Nginx 反代流式输出（SSE）卡顿排障

服务跑起来后，通常前置会加一个 Nginx 做统一鉴权、SSL 终结和反向代理。这时候你会遇到几乎 90% 工程师都会踩的坑：前端收到的 Token 输出不是一个字一个字流畅弹出来的，而是一卡一卡、最后一大坨突然吐出来的！

这是因为 Nginx 默认启用了响应缓冲区（Proxy Buffering），而 Server-Sent Events (SSE) 属于流式传输，必须强制关闭缓冲。下面是精简后的 Nginx 配置：

server {
    listen 80;
    server_name llm.internal.nassky.top;

    location /v1/ {
        proxy_pass http://127.0.0.1:8000/v1/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # 核心：关闭代理缓冲，保证流式 Token 实时传输
        proxy_buffering off;
        proxy_cache off;
        
        # 针对长思考 Agent 任务，调大超时时间（默认 60s 极易断开）proxy_read_timeout 300s;
        proxy_connect_timeout 60s;
        proxy_send_timeout 300s;

        # SSE 标准响应头传递
        proxy_set_header Connection '';
        proxy_http_version 1.1;
        chunked_transfer_encoding on;
    }
}

重新加载配置 nginx -s reload 后，前端对接 Dify、Open WebUI 或是自己写的 Agent 轮询客户端，流式打字效果瞬间变得丝般顺滑。

四、实操验证与并发压测对比

部署完成后，编写一段 Python 脚本直接模拟 8 个并发的 Agent 复杂查询任务，使用 OpenAI SDK 兼容协议进行测试：

import asyncio
import time
from openai import AsyncOpenAI

client = AsyncOpenAI(
    base_url="http://llm.internal.nassky.top/v1",
    api_key="EMPTY"
)

SYSTEM_PROMPT = "你是一个硬核全栈工程师，擅长通过拆解复杂架构解决分布式系统问题..." * 10 # 模拟长上下文

async def task(task_id):
    start = time.perf_counter()
    first_token_time = None
    token_count = 0

    response = await client.chat.completions.create(
        model="qwen2.5-14b",
        messages=[{"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": f"任务 #{task_id}: 详细解释 Linux 内核 epoll 的水平触发与边缘触发底层差异。"}
        ],
        stream=True,
        temperature=0.2
    )

    async for chunk in response:
        if chunk.choices[0].delta.content:
            if first_token_time is None:
                first_token_time = time.perf_counter() - start
            token_count += 1
            
    total_time = time.perf_counter() - start
    print(f"[Task {task_id}] TTFT: {first_token_time:.3f}s | 总耗时: {total_time:.2f}s | 生成 Tokens: {token_count} | 速度: {token_count/total_time:.1f} t/s")

async def main():
    tasks = [task(i) for i in range(8)]
    await asyncio.gather(*tasks)

if __name__ == "__main__":
    asyncio.run(main())

压测实测数据对比（8 并发，平均上下文 4k tokens）

• Ollama (Qwen2.5-14B-Instruct-Q4_K_M)：
  • 平均首字延迟 (TTFT)：2.41s
  • 多并发单任务平均吐字速度：8.3 tokens/s
  • 压测现象：显存占用剧烈波动，第 6 个任务开始出现明显的排队卡顿。
• vLLM (Qwen2.5-14B-Instruct-AWQ)：
  • 平均首字延迟 (TTFT)：0.28s（降低近 88%）
  • 多并发单任务平均吐字速度：34.6 tokens/s（提升 4 倍以上）
  • 压测现象：显存分配呈一条平直的直线（稳定在 22.1GB），8 个请求几乎同时吐字，各任务间无明显抖动。

总结与避坑心得

在单卡消费级显卡（24G 显存）的约束下构建私有化 Agent，核心原则就是“向显存要吞吐，向调度要延迟”：

1. 模型选型：放弃 FP16，优先选择经过 AWQ 算法优化的 4-bit 量化版本，它在保持逻辑推理和指令遵循能力几乎不掉队的同时，省下了一半以上的宝贵显存。
2. 显存分配克制：--max-model-len 一定要根据实际业务做封顶，不要盲信模型宣传的最大上下文；--enforce-eager 可以在边缘显存场景下作为救命稻草。
3. 链路排查：高并发流式 Agent 架构涉及客户端、Nginx、网关和推理后端，只要有一处缓冲（Buffering）未关，流式体验就会全盘崩塌。

按照这套方案搭建的底层，不管是挂接到 Dify 搭建自动化知识库管家，还是配合 AutoGen 处理多 Agent 协同，都能拥有极高且稳定的推理下限。对于小团队或极客开发者而言，单卡 4090/3090 跑这套栈，性价比直接拉满。