vLLM 推理参数调优全攻略：从 gpu_memory_utilization 到 max_num_batched_tokens 的性能优化实战

在大模型推理部署中，vLLM 凭借 PagedAttention、Continuous Batching 等核心技术成为了最流行的推理框架之一。然而，很多开发者在部署 vLLM 时仅仅使用了默认参数，并没有深入理解每个启动参数对吞吐量、延迟和显存的影响。本文将从 vLLM 的核心调度参数入手，系统地讲解如何通过参数调优将推理性能提升 2-3 倍。

无论你是在单卡 A100 上部署 Llama 3，还是在多卡集群上运行 Qwen2.5，掌握 vLLM 的参数调优都是最大化硬件利用率的关键。我们将覆盖显存管理、批处理调度、Prefill/Decode 平衡、Prefix Caching、量化加速等五大维度，每个参数都配有真实 benchmark 数据和调优建议。

一、显存管理参数：gpu_memory_utilization 与 block_size

vLLM 的显存管理核心在于如何将有限的 GPU HBM 显存合理分配给模型权重和 KV Cache。两个最关键的参数是

和

，它们直接决定了系统可以同时服务多少并发请求。

1.1 gpu_memory_utilization：显存预算的核心旋钮

控制 vLLM 允许使用的 GPU 显存比例，默认值为 0.90（即 90%）。vLLM 在启动时会进行一次显存 profiling，先加载模型权重，然后将剩余显存全部预留给 KV Cache 池。

这个参数的调优逻辑如下：

1
2
3
4
5
6
7
8
# 默认配置：预留 10% 显存给 CUDA context 和临时张量

vllm serve meta-llama/Llama-3-8B --gpu-memory-utilization 0.90



# 激进配置：最大化 KV Cache 空间，适合纯推理场景

vllm serve meta-llama/Llama-3-8B --gpu-memory-utilization 0.95



# 保守配置：在同一张 GPU 上运行其他任务时使用

vllm serve meta-llama/Llama-3-8B --gpu-memory-utilization 0.70

以 A100 80GB 为例，不同

值下的 KV Cache 可用空间如下：

调优建议：在生产环境中，建议从 0.90 开始，通过监控工具观察峰值显存使用情况。如果显存余量始终大于 5GB，可以逐步提升到 0.93-0.95。如果出现偶发 OOM，则下调到 0.85。注意，当在同一张 GPU 上运行 TensorBoard、DCGM exporter 等辅助进程时，需要额外预留 2-5GB 显存。

1.2 block_size：KV Cache 分页粒度

是 PagedAttention 的核心参数，控制 KV Cache 的分页粒度。vLLM 默认使用 16，这意味着每个 KV Cache block 包含 16 个 token 的 Key 和 Value 张量。

1
2
3
4
5
6
7
8
9
# block_size 对显存碎片和访问效率的影响

# 以 Llama-3-8B 为例（num_heads=32, head_dim=128, num_kv_heads=8）



# FP16 下单个 token 的 KV Cache 大小：

# 2 (K+V) * num_kv_heads * head_dim * 2(bytes) * num_layers

# = 2 * 8 * 128 * 2 * 32 = 131072 bytes ≈ 128KB per token



# block_size=16 时，每个 block 大小：128KB * 16 = 2MB

# block_size=32 时，每个 block 大小：128KB * 32 = 4MB

block_size 的选择需要在显存碎片率和 kernel 效率之间权衡：

• block_size=16（默认）：碎片率最低（最差情况下浪费 15 个 token 的空间），但 kernel launch 开销稍高
• block_size=32：kernel 效率更好，适合长序列场景，但短序列场景碎片率增加
• block_size=8：极致低碎片，但 PagedAttention kernel 效率下降约 10-15%

调优建议：大多数场景保持默认 16 即可。如果你的业务以长文本（32K+）为主，可以尝试 32。如果你的场景中短请求非常多且并发极高，可以降低到 8 来减少显存浪费。

二、批处理调度参数：max_num_seqs 与 max_num_batched_tokens

vLLM 的 Continuous Batching 调度器在每个 iteration 中决定处理哪些请求以及处理多少 token。两个核心参数

和

直接控制了调度器的行为，是吞吐量和延迟之间的关键平衡点。

2.1 max_num_seqs：最大并发序列数

限制 vLLM 同时处理的最大请求数，默认值为 256。这个参数不仅受限于显存（KV Cache 池大小），也受限于 GPU 计算能力。

1
2
3
4
5
6
7
8
# 默认配置：最多 256 个并发序列

vllm serve meta-llama/Llama-3-8B --max-num-seqs 256



# 高吞吐场景：增大并发数，但需要足够显存

vllm serve meta-llama/Llama-3-8B --max-num-seqs 512



# 低延迟场景：减小并发数，每个请求获得更多计算资源

vllm serve meta-llama/Llama-3-8B --max-num-seqs 32

实际测试中，max_num_seqs 对性能的影响如下（Llama-3-8B，A100 80GB，输入512 tokens，输出128 tokens）：

可以看到，当 max_num_seqs 从 32 提升到 256 时，吞吐量几乎翻了 3 倍，但 P99 延迟也从 120ms 飙升到 680ms。从 256 提升到 512 时，吞吐量几乎没有增长，但延迟急剧增加——说明 GPU 计算能力已经饱和，额外的并发只会增加排队延迟。

调优建议：先测量你的 SLA 要求。如果 P99 延迟要求 < 500ms，建议 max_num_seqs 设置在 128-192 之间。如果追求最大吞吐且延迟不敏感，可以设到 256-384。超过 384 后边际收益极小。

2.2 max_num_batched_tokens：单次迭代的 Token 预算

控制 vLLM 在单次前向传播中处理的最大 token 数量（包括 prefill 和 decode），默认值取决于模型配置，通常为 2048 或 8192。这个参数是 Chunked Prefill 技术的核心控制旋钮。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# vLLM 调度器的工作逻辑（简化版）

def schedule_iteration(self, running_seqs, waiting_seqs):

    # 1. 优先处理 decode 阶段的序列（每个序列 1 token）

    decode_tokens = len(running_seqs)  # 每个运行中的序列贡献 1 token



    # 2. 剩余预算用于 prefill 新请求

    remaining_budget = max_num_batched_tokens - decode_tokens



    # 3. 从等待队列中取出请求进行 prefill

    # 如果请求的 prompt 长度 > remaining_budget，则进行 chunked prefill

    while remaining_budget > 0 and waiting_seqs:

        seq = waiting_seqs[0]

        chunk_size = min(seq.remaining_prefill_tokens, remaining_budget)

        schedule_prefill(seq, chunk_size)

        remaining_budget -= chunk_size



    return scheduled_batch

这个参数对 Prefill 和 Decode 的混合调度有深远影响：

1
2
3
4
5
6
7
8
# 场景1：小预算，Prefill 被切分成多块，Decode 延迟低

vllm serve meta-llama/Llama-3-8B --max-num-batched-tokens 2048



# 场景2：默认值，平衡 Prefill 和 Decode

vllm serve meta-llama/Llama-3-8B --max-num-batched-tokens 8192



# 场景3：大预算，Prefill 快速完成，但 Decode 可能被阻塞

vllm serve meta-llama/Llama-3-8B --max-num-batched-tokens 16384

调优建议：对于交互式聊天场景（首 token 延迟敏感），建议设置为 2048-4096，让 Prefill 被切分成小块，避免长时间阻塞 Decode。对于批量处理场景（吞吐优先），可以设为 8192-16384，让 Prefill 快速完成。如果启用了 Chunked Prefill（vLLM v0.5+ 默认启用），这个参数尤为重要。

三、Prefill/Decode 平衡：enable_chunked_prefill 与调度策略

vLLM 从 v0.5 版本开始默认启用 Chunked Prefill，它允许将长 prompt 的 Prefill 阶段切分成多个小块，与正在进行的 Decode 请求交替执行。这从根本上改变了 Prefill 和 Decode 之间的资源分配方式。

3.1 enable_chunked_prefill 的效果

1
2
3
4
5
6
7
8
9
# 显式启用 Chunked Prefill（vLLM v0.5+ 默认已启用）

vllm serve meta-llama/Llama-3-8B \

  --enable-chunked-prefill \

  --max-num-batched-tokens 4096



# 禁用 Chunked Prefill（不推荐，除非你有特殊需求）

vllm serve meta-llama/Llama-3-8B \

  --no-enable-chunked-prefill \

  --max-num-batched-tokens 8192

启用 Chunked Prefill 后的性能对比（Llama-3-8B，混合负载：50% 短请求 + 50% 长请求）：

数据表明，启用 Chunked Prefill 并将 token budget 设置为 2048-4096 时，首 Token 延迟（TTFT）改善最显著——P99 从 2100ms 降至 420-580ms，同时吞吐量也提升了 14-21%。

3.2 长上下文场景的特殊调优

当处理 32K-128K 的超长上下文时，Chunked Prefill 的配置需要特别关注：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 长上下文场景的推荐配置

config = {

    "model": "Qwen/Qwen2.5-32B-Instruct",

    "gpu_memory_utilization": 0.92,

    "max_num_seqs": 64,          # 降低并发数，因为每个序列的 KV Cache 很大

    "max_num_batched_tokens": 8192,  # 适中的预算，平衡 prefill 速度和 decode 延迟

    "enable_chunked_prefill": True,

    "max_model_len": 131072,     # 支持最大 128K 上下文

    "tensor_parallel_size": 4,   # 4 卡张量并行

}



# KV Cache 容量计算

# Qwen2.5-32B: num_layers=64, num_kv_heads=8(GQA), head_dim=128

# 单 token KV Cache (FP16): 2 * 8 * 128 * 2 * 64 = 262144 bytes ≈ 256KB

# 128K 上下文的单个序列 KV Cache: 256KB * 131072 ≈ 32GB

# 4 张 A100 80GB (TP=4): 每卡 20GB 权重, 剩余 53GB 用于 KV Cache

# 每卡可容纳: 53GB / (32GB/4卡) ≈ 6 个 128K 序列

四、Prefix Caching 与 KV Cache 复用优化

Prefix Caching 是 vLLM 中一个极其有效但经常被忽视的优化手段。当多个请求共享相同的 system prompt 或前缀时，Prefix Caching 可以直接复用已计算的 KV Cache，避免重复计算。

4.1 enable_prefix_caching 的启用与效果

1
2
3
4
5
6
7
# 启用 Prefix Caching（vLLM v0.5+ 默认启用）

vllm serve meta-llama/Llama-3-8B \

  --enable-prefix-caching \

  --gpu-memory-utilization 0.90



# 验证 Prefix Caching 是否生效

# 在 vLLM 日志中查找 "Cached prompt" 相关信息

Prefix Caching 在不同场景下的加速效果：

调优建议：如果你的应用有固定的 system prompt 或频繁的多轮对话，务必确保 Prefix Caching 已启用。在 vLLM v0.5+ 中默认已开启，但如果使用旧版本或被显式关闭，需要手动启用。注意 Prefix Caching 会略微增加显存开销（需要维护 LRU 缓存元数据），但对整体性能的影响微乎其微。

4.2 KV Cache 量化与显存扩展

当显存不足以支撑所需的并发数时，KV Cache 量化是一个有效的扩展手段。vLLM 支持将 KV Cache 从 FP16 量化到 FP8 或 INT8，理论上可以将 KV Cache 显存占用减半。

1
2
3
4
5
6
7
8
9
10
# 启用 FP8 KV Cache 量化（需要 Ampere+ 架构）

vllm serve meta-llama/Llama-3-8B \

  --kv-cache-dtype fp8 \

  --gpu-memory-utilization 0.90



# 启用 INT8 KV Cache 量化（通过 quantization 配置）

vllm serve meta-llama/Llama-3-8B \

  --kv-cache-dtype fp8 \

  --quantization fp8 \

  --gpu-memory-utilization 0.90

不同 KV Cache 量化精度下的效果对比：

1
2
3
4
5
6
7
8
9
10
11
12
# KV Cache 量化对显存和质量的影响（Llama-3-8B, 8K上下文）



# FP16 (默认): 每 token KV Cache = 128KB

#   总 KV Cache (8K): 128KB * 8192 ≈ 1GB per sequence

#   A100 80GB 可容纳: ~56GB / 1GB ≈ 56 个并发序列



# FP8: 每 token KV Cache = 64KB (减半)

#   总 KV Cache (8K): 64KB * 8192 ≈ 512MB per sequence

#   A100 80GB 可容纳: ~56GB / 512MB ≈ 112 个并发序列



# 质量影响: FP8 KV Cache 在大多数任务上几乎无损

# 但在超长上下文(64K+)场景下，可能出现轻微精度下降

五、CUDA Graph 与量化加速：enforce_eager 与 quantization

5.1 CUDA Graph 加速：enforce_eager 参数

vLLM 默认启用 CUDA Graph 来消除 kernel launch 开销。CUDA Graph 通过预先录制一组 CUDA kernel 的执行序列，然后在每次推理时直接重放，避免了每次 kernel launch 带来的 CPU-GPU 同步开销。

1
2
3
4
5
# 默认行为：启用 CUDA Graph（推荐）

vllm serve meta-llama/Llama-3-8B



# 禁用 CUDA Graph（仅在调试或兼容性问题时使用）

vllm serve meta-llama/Llama-3-8B --enforce-eager

CUDA Graph 对 Decode 阶段的加速尤为明显，因为 Decode 阶段每次只生成 1 个 token，kernel 非常小但频繁，kernel launch 开销占比可达 30-50%。

调优建议：绝大多数情况下保持默认（启用 CUDA Graph）。只有在以下场景需要使用

：1) 调试自定义 kernel 时；2) 显存极度紧张时（节省 1-2GB）；3) 遇到 CUDA Graph 不兼容的动态形状问题时。CUDA Graph 对 Prefill 阶段几乎没有影响（因为 Prefill 的 kernel 足够大，launch 开销占比很小），但对 Decode 阶段有 30-50% 的加速。

5.2 模型量化：AWQ、GPTQ 与 FP8

模型量化是另一个重要的推理加速手段。vLLM 支持 AWQ、GPTQ、FP8 等多种量化格式，可以将模型权重量化到 4-bit 或 8-bit，显著减少显存占用和提升推理速度。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# AWQ 量化模型（4-bit）

vllm serve TheBloke/Llama-3-8B-Instruct-AWQ \

  --quantization awq \

  --gpu-memory-utilization 0.90



# GPTQ 量化模型（4-bit）

vllm serve TheBloke/Llama-3-8B-Instruct-GPTQ \

  --quantization gptq \

  --gpu-memory-utilization 0.90



# FP8 量化（需要 Hopper 架构如 H100/H200）

vllm serve meta-llama/Llama-3-8B-Instruct \

  --quantization fp8 \

  --gpu-memory-utilization 0.90



# BitsAndBytes 量化（4-bit，适合快速部署）

vllm serve meta-llama/Llama-3-8B-Instruct \

  --quantization bitsandbytes \

  --gpu-memory-utilization 0.90

不同量化方案的综合对比：

调优建议：如果有 H100/H200，优先使用 FP8 量化——速度和质量兼得。如果只有 A100/A10 等 Ampere 架构 GPU，AWQ 是最佳选择，它通过激活感知的权重量化保持了更好的精度。GPTQ 适合需要广泛兼容性的场景。BitsAndBytes 适合快速原型验证，但不推荐用于生产环境（速度反而可能下降）。

六、生产环境综合调优方案

了解了各个参数的作用后，我们来看几个典型场景的综合调优方案。这些方案基于实际的部署经验和 benchmark 数据，可以直接作为起点使用。

6.1 交互式聊天服务（低延迟优先）

1
2
3
4
5
6
7
8
9
# 场景：在线聊天，要求首 Token < 200ms，Decode < 50ms/token

vllm serve meta-llama/Llama-3-8B-Instruct \

  --gpu-memory-utilization 0.90 \

  --max-num-seqs 128 \

  --max-num-batched-tokens 2048 \

  --enable-chunked-prefill \

  --enable-prefix-caching \

  --kv-cache-dtype fp8 \

  --tensor-parallel-size 1

这个配置的核心思路是：通过小 token budget（2048）确保 Prefill 不会长时间阻塞 Decode，通过 Prefix Caching 加速重复前缀的计算，通过 FP8 KV Cache 量化将并发容量翻倍。适合智能客服、AI 助手等交互式场景。

6.2 批量处理服务（吞吐量优先）

1
2
3
4
5
6
7
8
9
10
# 场景：批量文档处理、数据标注，不敏感延迟，追求最大吞吐

vllm serve meta-llama/Llama-3-70B-Instruct-AWQ \

  --gpu-memory-utilization 0.95 \

  --max-num-seqs 256 \

  --max-num-batched-tokens 16384 \

  --enable-chunked-prefill \

  --enable-prefix-caching \

  --quantization awq \

  --tensor-parallel-size 4 \

  --max-model-len 8192

批量场景下，我们使用大 token budget（16384）让 Prefill 快速完成，使用 AWQ 量化在 4 张 A100 上运行 70B 模型，并将 gpu_memory_utilization 提升到 0.95 以最大化 KV Cache 空间。适合离线数据处理、批量内容生成等场景。

6.3 长上下文推理服务

1
2
3
4
5
6
7
8
9
10
# 场景：支持 128K 上下文的文档分析、代码理解

vllm serve Qwen/Qwen2.5-32B-Instruct \

  --gpu-memory-utilization 0.92 \

  --max-num-seqs 32 \

  --max-num-batched-tokens 8192 \

  --enable-chunked-prefill \

  --enable-prefix-caching \

  --kv-cache-dtype fp8 \

  --tensor-parallel-size 4 \

  --max-model-len 131072

长上下文场景的瓶颈在于 KV Cache 显存——单个 128K 上下文的序列可能占用 32GB 显存。通过 FP8 KV Cache 量化将这个数字减半到 16GB，同时将并发数降低到 32 以避免 OOM。Chunked Prefill 在这里尤为重要，因为 128K 的 Prefill 如果一次性执行会阻塞所有 Decode 请求长达数秒。

七、参数调优的验证与监控

调优不是一次性的工作，需要通过持续的监控来验证参数效果。vLLM 提供了丰富的监控指标，可以通过 Prometheus + Grafana 进行可视化。

7.1 关键监控指标

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# vLLM 暴露的 Prometheus 指标（默认端口 8000/metrics）

# 关键指标列表：



# 1. 吞吐量指标

vllm:num_requests_swapped        # 被换出到 CPU 内存的序列数（应为 0）

vllm:num_requests_running        # 正在运行的序列数

vllm:num_requests_waiting        # 等待队列长度



# 2. 延迟指标

vllm:time_to_first_token_seconds  # 首 Token 延迟

vllm:time_per_output_token_seconds  # 单 Token 生成时间

vllm:e2e_request_latency_seconds  # 端到端请求延迟



# 3. 资源使用指标

vllm:gpu_cache_usage_perc        # KV Cache 使用率

vllm:cpu_cache_usage_perc        # CPU 缓存使用率



# 4. 调度器指标

vllm:num_preemption               # 抢占次数（应为 0，否则说明显存不足）

7.2 Benchmark 工具使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 使用 vLLM 自带的 benchmark 工具

# 启动 vLLM 服务后，运行 throughput benchmark

python -m vllm.entrypoints.openai.api_server \

  --model meta-llama/Llama-3-8B-Instruct \

  --gpu-memory-utilization 0.90 \

  --max-num-seqs 128



# 运行吞吐量测试

python benchmarks/benchmark_serving.py \

  --backend vllm \

  --model meta-llama/Llama-3-8B-Instruct \

  --num-prompts 1000 \

  --request-rate 10 \

  --dataset-name random



# 运行延迟测试

python benchmarks/benchmark_latency.py \

  --model meta-llama/Llama-3-8B-Instruct \

  --batch-size 1 \

  --output-len 128

调优流程建议如下：

1. 先用默认参数运行 benchmark，记录基线性能
2. 每次只调整一个参数，运行相同的 benchmark
3. 对比吞吐量、P50/P99 延迟、GPU 利用率
4. 选择最优值后，再调整下一个参数
5. 最终用真实业务负载验证（benchmark 工具的 synthetic 负载可能与真实负载有差异）

特别需要注意的是

指标。如果这个值不为 0，说明 vLLM 正在进行序列抢占（将正在运行的序列的 KV Cache 换出以腾出空间给新请求），这会导致严重的延迟抖动。解决方案是降低

或提高

。

总结

vLLM 的参数调优是一个系统工程，需要综合考虑显存管理、批处理调度、Prefill/Decode 平衡和量化加速等多个维度。以下是本文的核心要点：

• 显存管理：

  1	gpu_memory_utilization

  从 0.90 起步，根据监控数据微调；

  1	block_size

  默认 16 适合大多数场景

• 批处理调度：

  1	max_num_seqs

  控制并发上限，低延迟场景设 128，高吞吐场景设 256；

  1	max_num_batched_tokens

  控制 Prefill/Decode 混合比例

• Chunked Prefill：务必启用，配合

  1	max_num_batched_tokens=2048-4096

  可将首 Token 延迟降低 60-70%

• Prefix Caching：默认启用即可，对多轮对话和固定 system prompt 场景有 4-7 倍加速
• CUDA Graph：保持默认启用，对 Decode 有 30-50% 加速
• 量化加速：H100 用 FP8，A100 用 AWQ，KV Cache 用 FP8 量化可翻倍并发容量
• 持续监控：关注

  1	num_preemption

  、

  1	gpu_cache_usage_perc

  和 TTFT 指标，动态调整参数

最后要强调的是，参数调优没有万能公式——最优参数组合取决于你的模型大小、硬件配置、负载特征和 SLA 要求。本文提供的数值和建议是基于典型场景的基准测试结果，建议在实际部署中通过 benchmark 工具验证后再投入使用。如果你对 vLLM 与 SGLang 的架构对比感兴趣，也可以参考我们之前的深度分析文章。更多关于 Continuous Batching 动态批处理和 PD 分离部署架构的内容，也欢迎延伸阅读。