vLLM 详解：Agent 技术栈的推理引擎

TL;DR — vLLM 是大多数生产级 Agent 技术栈底层的开源推理引擎。它的核心技巧 PagedAttention 借鉴了操作系统的虚拟内存分页机制来消除 KV cache 浪费，相比朴素的 HuggingFace 推理可实现最高 24 倍的吞吐提升。如果你的 Agent 在规模化消耗 token，vLLM 大概率就是那个把 GPU 显存变成可用输出的层。

为什么 Agent 开发者要关心推理引擎

大多数 Agent 教程对推理层挥挥手就过去了。你把 Agent 指向一个 API 端点，token 回来了，皆大欢喜。我也曾经很开心——直到我同时跑 50 个 Agent 会话，每个都在 32K token 上下文里循环调工具，然后眼睁睁看着 p95 延迟爬到 12 秒，而 GPU 利用率才 40%。不是模型慢，是服务层慢。

我想聊的就是这一层。推理引擎位于 GPU 和 Agent 运行时之间，决定如何批处理请求、管理显存、调度生成。vLLM 是定义了现代做法的那一个，如果你在任何真实量级跑 Agent，它大概率已经在你的栈里了——不管是不是你放进去的。

vLLM 是什么

vLLM 是 UC Berkeley Sky Computing Lab 构建的高吞吐 LLM 推理引擎。2023 年发布，引入了 PagedAttention——一种像操作系统管理 RAM 一样管理 KV cache 的算法：按页分配、释放、共享，无需连续内存。

2026 年的关键数据：

指标	数值
GitHub stars	55K+
OpenRank（2026年5月）	885.72
活跃贡献者	898
当前版本	v0.7.x
支持模型架构	100+
许可证	Apache 2.0

vLLM 不是模型，不是框架。它是让模型高效服务请求的引擎。类比的话，它是你应用的数据库引擎——你不直接跟它交互，但它慢了一切都崩。

核心思想：PagedAttention

每个 LLM 生成 token 时都维护一个 KV cache——一个不断增长的缓冲区，存储过去的注意力状态以避免重复计算。问题是：传统推理方式预先分配一块连续内存，大小等于最大可能序列长度。一个 70B 模型的 32K 上下文窗口，每个请求可能吃掉 4GB 显存，即使实际序列只用了 2K token。

这就像对一个 200 字节的字符串 malloc 了 32GB。

PagedAttention 把 KV cache 切成固定大小的页（block）。页按需分配，非连续存储在显存中，请求完成后立即释放：

传统方式:      [████████████████████████░░░░░░░░]  ← 70% 浪费
PagedAttention: [██][██][██][██][ ][ ][ ][ ][ ]  ← 按需分配

结果是 vLLM 在相同 GPU 上能服务 3-5 倍的并发请求。对 Agent 工作负载——几十个会话同时跑，每个因为工具调用有不同的上下文长度——这是 8 张 GPU 和 2 张 GPU 的区别。

生产架构中的位置

vLLM 在典型 Agent 部署中的位置：

┌─────────────────────────────────────────────┐
│  Agent 运行时（你的代码）                      │
│  Claude Code / OpenHands / 自定义 Agent       │
├─────────────────────────────────────────────┤
│  API 网关 / 路由                              │
│  LiteLLM / SandBase / OpenRouter             │
├─────────────────────────────────────────────┤
│  推理引擎                                     │
│  vLLM  ←── 你在这里                           │
├─────────────────────────────────────────────┤
│  硬件                                        │
│  H100 / A100 / L40S / AMD MI300X            │
└─────────────────────────────────────────────┘

vLLM 开箱就暴露 OpenAI 兼容 API。你可以直接把 https://api.openai.com/v1 换成 http://your-vllm-server:8000/v1，Agent 代码零改动。这就是它能无摩擦接入现有架构的原因。

对 Agent 工作负载最重要的特性

Continuous batching（连续批处理） — 传统批处理等 N 个请求到齐再一起处理。连续批处理在 GPU 有空闲容量时动态加入新请求。对 Agent 来说，你的工具调用响应不用排在别人的 4K token 长文后面等。

Prefix caching（前缀缓存） — 当多个请求共享相同 system prompt（Agent 场景中极其常见，每个会话开头都是同样的指令），vLLM 缓存该前缀的 KV 状态并复用。100 个会话共享 2K token 的 system prompt，只计算一次而不是 100 次。

Tensor parallelism（张量并行） — 把模型拆到一台机器的多张 GPU 上。70B 参数模型 FP16 需要 ~140GB 显存。两张 H100（各 80GB）设 TP=2 就能跑。vLLM 自动处理拆分和通信。

Speculative decoding（投机解码） — 用小的 draft 模型预测多个 token，再用目标模型并行验证。实际可以给延迟敏感的 Agent 交互带来 1.5-2 倍加速。

Structured output（结构化输出） — Agent 需要 JSON，不是自由文本。vLLM 支持语法约束的引导生成，确保工具调用响应每次都能正确解析。

最小启动方式

# Docker 一行启动
docker run --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 2 \
  --max-model-len 32768

# 测试
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-3.3-70B-Instruct",
    "messages": [{"role": "user", "content": "Hello"}],
    "max_tokens": 100
  }'

一条命令拿到生产级推理端点。你的 Agent 代码像调任何 OpenAI 兼容 API 一样调它。

生产调优：真正重要的那些参数

Docker 一行命令能跑起来。生产环境会让你栽跟头。下面这些设置是”能用”和”扛得住负载”的区别：

docker run --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  --ipc=host \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --enable-prefix-caching \
  --max-num-seqs 128 \
  --gpu-memory-utilization 0.92 \
  --enable-chunked-prefill \
  --disable-log-requests

每个参数的作用和原因：

• --enable-prefix-caching — 对 Agent 工作负载是免费的性能。100 个会话共享同样的 2K token system prompt，这个前缀的 KV cache 只算一次。不开的话每个请求都重算。我们在有共享指令的 Agent 集群上测到 30-40% 的 TTFT 降低。

• --max-num-seqs 128 — 默认 256，听起来没问题，直到你意识到每个序列预留 KV cache 槽位。70B 模型 32K 上下文下，256 个并发序列还没填满就会 OOM。128 是更安全的起点——根据实际峰值并发往上调。

• --gpu-memory-utilization 0.92 — 默认 0.9。提到 0.92 在 80GB H100 上多给你 ~1.6GB 可用 KV cache。风险：模型权重 + KV cache 超过限制时请求开始被拒。盯紧 metrics 里的 gpu_cache_usage_perc。

• --enable-chunked-prefill — 把长 prefill 请求切成块，可以和 decode 操作交错。不开的话，单个 32K token 的 prefill 会阻塞 GPU 2-3 秒，所有排队的 decode 请求都得等。开了之后，即使来长 prompt，decode 延迟也保持有界。

• --ipc=host — 多 GPU 张量并行需要。不加的话 NCCL 进程间通信会静默失败或退化到慢路径。

• --disable-log-requests — 生产环境 100+ req/s 时，记录每个请求会拖慢 5-10% 吞吐。把请求日志交给网关。

没人提醒你的坑：--max-model-len 默认用模型 config 里的值（现代模型常常是 128K）。但 KV cache 内存随最大序列长度线性增长。实际最大只用 32K 却设成 128K，浪费了 75% 的 KV cache 预算。永远把这个设成你实际预期的最大上下文长度。

监控：该盯什么

vLLM 在 /metrics 暴露 Prometheus 指标。对 Agent 工作负载重要的：

指标	告诉你什么	告警阈值
vllm:num_requests_waiting	队列深度	持续 > 50 = 加容量
vllm:gpu_cache_usage_perc	KV cache 压力	> 0.95 = 请求会被拒
vllm:avg_generation_throughput_toks_per_s	输出速度	突降 = 有问题
vllm:e2e_request_latency_seconds	每请求总延迟	Agent 场景 p99 > 10s = 体验差
vllm:num_preemptions_total	生成中途被驱逐的请求	任何非零值 = 容量问题

抢占（preemption）是隐形杀手。KV cache 满了的时候，vLLM 驱逐进行中的请求腾空间给新请求。被驱逐的请求从头重启。看到 preemption，要么降 --max-num-seqs，要么加 GPU。

vLLM vs SGLang：真正的取舍

SGLang 是 vLLM 最主要的竞争对手，benchmark 接近到选择取决于你的工作负载：

维度	vLLM	SGLang
吞吐量（大 batch）	略高	略低
p95 延迟（streaming）	~85ms	~48ms
前缀复用策略	Block 级前缀缓存	RadixAttention（基数树）
结构化生成	语法引导	LMFE + jump-forward
社区规模	更大（55K stars，898 贡献者）	较小但增长快（415 贡献者）
最佳场景	高吞吐服务、大规模集群	低延迟、复杂前缀复用

具体到 Agent 场景，SGLang 的 RadixAttention 在分支 prompt 结构时更高效——比如 Agent 频繁用修改过的 prompt 重试，这些 prompt 共享很长的公共前缀。vLLM 的前缀缓存处理简单场景没问题，但做不到 SGLang 那种基数树级别的去重。

上面的 benchmark 数字需要上下文，因为裸对比会误导。~85ms vs ~48ms 的 p95 数据来自 streaming、小 batch（并发低于 8）、Llama 3.3 70B FP8、单张 H100。换成大 batch 吞吐（batch 128+），vLLM 反超 5-10%——连续批处理调度器在饱和状态下更成熟。诚实的解读：低并发 SGLang 赢延迟，高并发 vLLM 赢吞吐，中间地带两者在误差范围内。任何说某一个”普遍快 2 倍”的人，都是在引用一个调成符合自己结论的 benchmark。

实践中，很多生产环境两个都用：vLLM 跑高吞吐批处理（embedding、摘要），SGLang 跑延迟敏感的交互式 Agent 会话。网关层（LiteLLM 或 SandBase）负责路由。

vLLM 的短板

真实痛点：

冷启动 — 加载 70B 模型需要 60-90 秒。如果你的基础设施缩到零，对交互式 Agent 来说不可接受。需要保持热实例或预加载策略。

Agentic 工作负载下的 KV cache 扩展 — SGLang 团队的路线图（issue #21846）明确指出 agentic workloads 正在把 KV cache 存储量推到当前 PD 分离方案的瓶颈之外。长时间运行的 Agent 会话累积历史，对缓存系统的压力和无状态聊天请求完全不同。

规模化时的级联故障 — SGLang issue #20252 记录了一个真实事故：90 prefill + 30 decode 节点的 H20 集群，部分节点重启导致健康检查失败、router 移除 worker、流量集中到剩余节点，最终全集群 503。vLLM 面临同类问题。工业级推理需要引擎之外的精心 router、健康检查和容量规划。

多节点开销 — 跨机器的流水线并行引入节点间网络延迟。能放单机就放单机，跨节点只对超大模型（400B+）有意义。

如何融入你的 Agent 基础设施

如果你在构建调用自托管模型的 Agent——无论出于成本、隐私还是延迟——vLLM 是默认起点：

1. 只用云 API（OpenAI、Anthropic、Google）？ → 你不直接需要 vLLM。但你的 API 提供商大概率在跑它。
2. 为 Agent 集群自托管一个模型？ → vLLM + Docker，前面挂网关做认证/路由。
3. 跑多个模型（按任务复杂度路由强/弱模型）？ → 多个 vLLM 实例挂在 router 后面。
4. 需要 sub-50ms 延迟？ → 延迟敏感路径考虑 SGLang，吞吐路径用 vLLM。

网关层（LiteLLM、SandBase）在选项 3 之后变得关键。你不希望 Agent 代码知道哪个物理端点在跑哪个模型——那是基础设施该干的事。

FAQ

消费级 GPU 能跑 vLLM 吗？

可以，用小模型。4090（24GB）跑量化后的 7-13B 模型很舒服。70B+ 需要数据中心 GPU 或多卡。

vLLM 支持 AMD GPU 吗？

支持，MI200/MI300 系列通过 ROCm 支持。新硬件上性能和 NVIDIA 有竞争力。

vLLM 和 llama.cpp 有什么区别？

用途不同。llama.cpp 优化的是 CPU/边缘/本地推理，用激进量化。vLLM 是 GPU 优先，优化的是数据中心规模的多用户并发服务。本地笔记本跑 Agent 用 llama.cpp；服务 1000 用户的 Agent 平台用 vLLM。

vLLM 生产就绪了吗？

几十家公司在生产环境跑它，包括推理服务商和模型实验室。LMSYS Chatbot Arena 用的就是 vLLM。作为开源推理引擎它已经足够成熟——但和所有基础设施一样，你仍需要围绕它做监控、健康检查和容量规划。

vLLM 和 NVIDIA Dynamo 的关系是什么？

Dynamo 是 NVIDIA 的编排层，位于 vLLM 等引擎之上。它处理多模型调度、KV cache 路由和集群级扩缩容。vLLM 是单节点内的引擎；Dynamo 是跨节点的集群管理器。

核心要点

• vLLM 是大多数生产级 LLM 部署的底层推理引擎。PagedAttention 消除 KV cache 内存浪费，同 GPU 上可服务 3-5 倍并发请求。
• 对 Agent 工作负载最重要的特性：连续批处理（工具调用不排队）、前缀缓存（共享 system prompt）、结构化输出（可靠 JSON）。
• 真正的竞品是 SGLang，后者在延迟和复杂前缀复用上占优。很多生产环境两者都跑，挂 router 分流。
• vLLM 是基础设施——位于 Agent 运行时和 API 网关的下方。自托管模型跑 Agent，它是起点。