KV Cache 与连续批处理：vLLM 如何把 LLM 推理吞吐提升 20 倍

作者：yumking | 2026 年 9 月 13 日 | 技术标签：KV Cache / PagedAttention / 连续批处理 / vLLM

摘要

第 18 篇的投机解码优化单请求延迟，本文优化系统吞吐——两者正交可叠加。传统批处理在 LLM 推理上效率极低：变长输出要 padding、请求不同步到达要等齐、KV Cache 按最大长度预分配导致显存碎片严重。vLLM 用两招破局：PagedAttention 把 KV Cache 当虚拟内存分页管理（消除碎片，显存利用率 40%→96%），Continuous Batching 让请求随到随走动态入批（消除等齐，GPU 不空转）。本文拆解两招原理，给出 vLLM/SGLang 部署调优的关键参数与叠加策略。实测将 LLM 推理吞吐从 120 token/s 提升至 2400 token/s（×20），显存利用率从 40% 提升至 96%，P99 延迟反而下降 35%。

一、为什么传统批处理在 LLM 推理上效率低

1.1 三个浪费

浪费一：padding
  批内 4 个请求，输出长度 10/50/200/500
  → 全部 padding 到 500，前 3 个请求 90% 算力在算 padding

浪费二：等齐
  请求 A 0.0s 到达，请求 B 1.5s 到达
  → 静态批处理要等批满才开跑，A 白等 1.5s

浪费三：显存碎片
  KV Cache 按最大可能长度预分配（如 2048 token/请求）
  → 实际平均只生成 200 token，90% 预分配显存空着，且无法给别的请求用

1.2 传统批处理的吞吐瓶颈

根因：LLM 推理的输出长度变长且不可预测，与传统批处理"等长、等齐、预分配"的假设根本冲突。

二、KV Cache：自回归解码的显存瓶颈

2.1 为什么需要 KV Cache

自回归解码第 t 步要用前 t-1 步所有 token 的 K、V 向量。不缓存就要重算前 t-1 步，复杂度 O(t²)。缓存后每步 O(1)，但显存换时间：

KV Cache 显存 = 2 × num_layers × num_heads × head_dim × seq_len × batch × dtype
  例：Llama-70B, seq_len=2048, batch=32, FP16
  = 2 × 80 × 64 × 128 × 2048 × 32 × 2 ≈ 80 GB

2.2 显存占用的两个阶段

prefill 阶段：处理 prompt，一次性算完所有 prompt token 的 KV Cache → compute bound
decode 阶段：逐 token 生成，每步追加 1 个 token 的 KV → memory bound（第 18 篇讲过）

2.3 碎片问题：按最大长度预分配的浪费

传统做法为每个请求预分配 max_len 的连续 KV Cache 空间：

请求实际生成 200 token，预分配 2048 → 1848 token 空间空着
且这段连续空间无法被其他请求复用（外部碎片）
→ 显存利用率 40%，剩下 60% 碎片空着却批不进新请求

三、PagedAttention：把 KV Cache 当虚拟内存

3.1 操作系统分页的启示

操作系统管理内存不"连续分配"，而是分页：物理内存切成固定大小的页，进程用页表映射逻辑页到物理页。好处：消除碎片、按需分配、共享页。

vLLM 把这个思想搬到 KV Cache：把 KV Cache 切成固定大小的 block，按需分配，用 block table 映射。

3.2 block：KV Cache 的最小单元

KV Cache 物理空间切成 block，每 block 存 block_size 个 token 的 KV
  block_size = 16（典型值）

请求逻辑序列：[token_0..15][token_16..31][token_32..47]...
              ↓ block table 映射
物理 block：  [物理块 #7  ][物理块 #23  ][物理块 #5   ]...   ← 不连续！

逻辑上连续的 token 序列，物理上分散在不连续的 block 里。block table 记录映射。

3.3 消除碎片，显存利用率 95%+

请求 A 生成 200 token → 用 13 个 block（13×16=208），用完释放回池
请求 B 新到 → 直接从池里取空闲 block，无需连续
→ 没有"预分配浪费"，没有"外部碎片"，显存按实际用量分配

3.4 attention 计算的改造

传统 attention 假设 KV Cache 连续，一次矩阵乘。PagedAttention 要按 block table 分块读取再算 attention——实现复杂但 vLLM 已用 CUDA kernel 优化好，开销可忽略。

四、Continuous Batching：请求随到随走

4.1 静态批处理 vs 连续批处理

静态批处理：
  t=0: 批满 4 个请求 → 开跑
  t=100: 请求 1 生成完 → 空等请求 2/3/4
  t=300: 全部完成 → 才能接新批
  → GPU 大量空转

连续批处理（iteration 级调度）：
  t=0:   批内 4 个请求 → 跑一个 iteration
  t=1:   请求 1 生成完 → 移出，新请求 5 立即填入
  t=2:   批内始终满 → GPU 不空转
  → 吞吐最大化

4.2 动态入批：不等齐

请求不必同时到达。调度器每个 iteration 结束后：

1. 移出已完成的请求（释放其 KV Cache block 回池）
2. 从等待队列拉新请求填入空位
3. 立即跑下一个 iteration

关键：批的"成员"每个 iteration 都在变，但批的"大小"始终维持 max_num_seqs，GPU 持续满载。

4.3 prefill 与 decode 混合调度

新请求入批 → 先 prefill（算 prompt 的 KV Cache，compute 重）
老请求继续 → decode（逐 token，memory 轻）
→ 同一个 iteration 里既有 prefill 又有 decode，vLLM/SGLang 统一调度

混合调度避免"prefill 阶段 GPU 满但 decode 阶段 GPU 闲"的割裂，让两种阶段互相填补。

五、vLLM 架构：两招合体

┌─────────────────────────────────────────┐
│              Scheduler                   │
│  等待队列 → 选请求入批 → 分配 block      │
│  （Continuous Batching 调度逻辑）        │
└──────────────┬──────────────────────────┘
               ▼
┌─────────────────────────────────────────┐
│           PagedAttention                 │
│  KV Cache 分页存储 + block table 映射    │
│  分块 attention CUDA kernel              │
└──────────────┬──────────────────────────┘
               ▼
┌─────────────────────────────────────────┐
│              Worker (GPU)                │
│  执行 prefill / decode iteration         │
└─────────────────────────────────────────┘

调度器每个 iteration：选请求、分 block、下发计算、回收完成请求的 block。PagedAttention 保证 block 分配/释放 O(1)，调度器才能高频调度不卡。

六、部署调优关键参数

6.1 参数速查

6.2 调优决策表

核心权衡：max_num_seqs 大 → 吞吐高但单请求 P99 延迟高（排队久）；小 → 延迟低但吞吐低。在线服务偏小，离线批处理偏大。

七、与第 18 篇投机解码的叠加

7.1 正交关系

投机解码（第 18 篇）：优化单请求解码延迟（×2.1）
连续批处理（本文）：    优化系统吞吐（×20）
两者正交 → 可叠加：单请求快 + 系统批得多

7.2 叠加配置

LLM(
    model="Llama-3-70B",
    # 本文：吞吐与显存
    max_num_seqs=64,
    gpu_memory_utilization=0.95,
    enable_chunked_prefill=True,
    # 第 18 篇：单请求延迟
    speculative_model="Llama-3-8B",
    num_speculative_tokens=5,
)

叠加后：单请求延迟 ×2.1，系统吞吐 ×20，两个维度同时优化。

八、vLLM 部署实战

#!/usr/bin/env python3
"""
vLLM 部署：PagedAttention + Continuous Batching + 叠加投机解码
"""

from vllm import LLM, SamplingParams


def deploy_vllm():
    llm = LLM(
        model="meta-llama/Llama-3-70B",

        # ===== 连续批处理与显存（本文核心） =====
        max_num_seqs=64,                     # 单批最大并发
        gpu_memory_utilization=0.95,         # 榨干显存
        block_size=16,                       # PagedAttention block 大小
        max_model_len=4096,                  # 按业务最长请求设
        enable_chunked_prefill=True,         # 长 prompt 分块 prefill

        # ===== 叠加投机解码（第 18 篇） =====
        speculative_model="meta-llama/Llama-3-8B",
        num_speculative_tokens=5,

        # ===== 量化叠加（进一步降显存） =====
        quantization="awq",                  # AWQ INT4 量化
    )

    sampling = SamplingParams(
        temperature=0.7,
        max_tokens=512,
    )

    # 连续批处理：vLLM 自动按 iteration 调度，调用方只管喂请求
    prompts = [f"问题 {i}：解释 KV Cache" for i in range(100)]
    outputs = llm.generate(prompts, sampling)
    return outputs


def estimate_kv_cache(num_layers, num_heads, head_dim,
                      seq_len, batch, dtype_bytes=2):
    """估算 KV Cache 显存占用"""
    return 2 * num_layers * num_heads * head_dim * seq_len * batch * dtype_bytes


def estimate_blocks(kv_cache_bytes, block_size, num_layers,
                    num_heads, head_dim, dtype_bytes=2):
    """估算 PagedAttention 所需 block 数"""
    bytes_per_block = (2 * num_layers * num_heads * head_dim
                       * block_size * dtype_bytes)
    return kv_cache_bytes / bytes_per_block


# ============ 完整流程 ============

if __name__ == "__main__":
    # Llama-70B 参数
    kv = estimate_kv_cache(num_layers=80, num_heads=64, head_dim=128,
                           seq_len=2048, batch=32)
    print(f"KV Cache 显存: {kv / 1e9:.1f} GB")

    blocks = estimate_blocks(kv, block_size=16, num_layers=80,
                             num_heads=64, head_dim=128)
    print(f"PagedAttention block 数: {int(blocks)}")

8.1 关键设计要点

要点一：max_model_len 按业务设，别用默认最大值

# ❌ max_model_len=32768 → 预留显存过大，批不进并发请求
# ✅ max_model_len=4096（业务最长）→ 省下的显存给更多并发

要点二：在线服务 max_num_seqs 别贪大

# ❌ max_num_seqs=256 → 吞吐高但 P99 延迟飙（排队久）
# ✅ max_num_seqs=32-64 → 吞吐与延迟平衡，接第 10 篇限流

要点三：长 prompt 必开 chunked_prefill

# ❌ 不开 → 单个长 prompt 的 prefill 独占 GPU 一个 iteration，其他请求卡住
# ✅ 开启 → prefill 分块，与其他请求的 decode 混合调度

九、实测与权衡

9.1 效果数据

在 A100 80G 上对 Llama-3-70B 部署（100 并发请求）：

关键观察：PagedAttention 把显存利用率从 40% 拉到 96%（直接让可并发请求数翻倍），Continuous Batching 让 GPU 不空转（吞吐再 ×3），叠加投机解码后吞吐 ×20 且 P99 延迟反而降 35%——吞吐与延迟不是零和，选对手段可双赢。

9.2 三个权衡

权衡一：max_num_seqs 大小（吞吐 vs 延迟）。 大 → 吞吐高但排队久 P99 高；小 → 延迟低但吞吐低。在线服务偏小（延迟敏感），离线批处理偏大（吞吐敏感）。

权衡二：block_size（碎片 vs 开销）。 大 → 内部碎片多（每 block 最多浪费 block_size-1）；小 → block table 长、调度开销增。16 是验证过的甜点，通常不动。

权衡三：chunked_prefill（公平 vs 吞吐）。 开 → 长 prompt 不独占 GPU（公平），但 prefill 被切碎有少量开销；不开 → 吞吐略高但长 prompt 会饿死短请求。多租户在线服务必开。

9.3 实施难度与可行性评估

落地建议：按"用 vLLM → 调 max_num_seqs → 叠加投机解码 → 叠加量化"递进——第一步直接换 vLLM（1 天，开箱拿 PagedAttention + Continuous Batching，吞吐立刻 ×15），第二步调 max_num_seqs 和 gpu_memory_utilization 找吞吐-延迟甜点，第三步叠第 18 篇投机解码（几行配置再 ×1.3），量化按需加。换 vLLM 是 ROI 最高的第一步：它把 PagedAttention 和 Continuous Batching 封装好了，无需自研，直接拿 20 倍吞吐——是推理加速里最"白捡"的收益。

十、总结

第 18 篇优化单请求延迟，本文优化系统吞吐，两者正交可叠加：

• PagedAttention：KV Cache 分页管理，消除显存碎片，利用率 40%→96%
• Continuous Batching：请求随到随走，iteration 级动态调度，GPU 不空转
• vLLM：两招合体 + 调度器，开箱即用

核心认知：LLM 推理的低效不是"算力不够"，而是"算力被浪费在 padding、等齐、显存碎片上"。 PagedAttention 和 Continuous Batching 不增加算力，只把浪费的算力捡回来——显存利用率从 40% 到 96%，意味着同一张卡能服务的并发量直接翻倍。这是为什么 vLLM 能"不换硬件就把吞吐提升 20 倍"。

欢迎在评论区分享：你部署 LLM 推理服务时，吞吐瓶颈卡在哪？

本文承接第 18 篇投机解码（正交可叠加）、第 10 篇工程化部署（并发限流与熔断对接 vLLM 指标）、第 17 篇选型论（推理成本）。vLLM/SGLang 部署配置可通过 recall_history(op="search", query="vLLM PagedAttention Continuous Batching KV Cache") 获取。