PagedAttention

大模型推理的性能瓶颈不是计算，而是内存。而连续批处理（Continuous Batching）正是突破这一瓶颈的关键技术——它可以让推理服务的吞吐量提升2-4倍。本文将深入解析这项技术的原理与实现。 一、传统批处理的困境 1.1 静态批处理的问题 传统批处理将多个请求组成一个batch一起推理。问题在于：大模型生成是自回归的，每个请求的生成长度不同。 请求A: 输入50 token, 生成200 token (总时长: 3秒) 请求B: 输入30 token, 生成20 token (总时长: 0.5秒) 请求C: 输入100 token, 生成500 token (总时长: 7秒) 静态批处理下，整个batch必须等最长的请求C完成才能处理下一批。请求B在0.5秒就完成了，但GPU资源被空占了6.5秒。GPU利用率可能低至20-30%。 1.2 内存碎片化 更深层的问题在KV Cache的内存管理。每个请求需要预分配最大生成长度的KV Cache空间，即使实际只生成了很少的token，预分配的空间也无法被其他请求使用。 二、连续批处理的核心思想 2.1 动态插入与驱逐 连续批处理的核心：不等整个batch完成，而是在每一步推理后动态调整batch组成。 Step 1: batch = [A, B, C] → 各生成第1个token Step 2: batch = [A, B, C] → 各生成第2个token Step 3: batch = [A, B, C] → B完成！B退出batch Step 4: batch = [A, D, C] → D是新请求，加入batch Step 5: batch = [A, D, C] → A完成！A退出 Step 6: batch = [E, D, C] → E加入 ... 这样GPU始终满载运行，没有空等。 ...

大模型推理的KV Cache优化全解 KV Cache是大模型推理中最重要的优化技术，也是最大的内存瓶颈。理解KV Cache的工作原理和优化方法，是构建高效推理服务的基础。 KV Cache是什么 在Transformer的自回归生成中，每生成一个新token，需要计算它对所有之前token的注意力。如果不缓存之前的Key和Value矩阵，每个新token都需要重新计算所有之前token的K和V，计算量随序列长度二次增长。 KV Cache通过缓存之前计算过的K和V矩阵，将每步的计算复杂度从O(n²)降到O(n)。代价是内存占用线性增长——对于Llama-70B模型，生成4K token的KV Cache约占40GB显存。 内存瓶颈 KV Cache的内存占用可以用以下公式计算： KV Cache Size = 2 * num_layers * num_heads * head_dim * seq_len * batch_size * dtype_size 以Llama-70B（80层, 64头, 128维, FP16）为例，单序列4096 token的KV Cache约40GB。这意味着一个80GB显存的A100只能服务两个并发请求——这是制约推理吞吐量的最大瓶颈。 PagedAttention：分页管理 vLLM团队提出的PagedAttention是KV Cache管理的革命性创新。灵感来自操作系统的虚拟内存分页机制。 传统分配的问题 传统方法为每个序列预分配一块连续的KV Cache空间，按最大序列长度分配。这导致严重的内存碎片——大多数序列不会用满预分配的空间，但多余的空间不能被其他序列使用。内存利用率通常只有20-40%。 分页方案 PagedAttention将KV Cache划分为固定大小的"页"（通常16个token），每个序列通过页表映射到物理页。页按需分配——序列增长时才分配新页。 效果是显著的：vLLM的内存利用率提升到90%以上，并发吞吐量提升2-4倍。碎片问题被彻底解决，因为不同序列的页可以散布在物理内存中的任意位置。 页的大小选择 页太小（如1 token）会增加页表开销，页太大（如256 token）则回到预分配的问题。16 token是在大多数场景下的最优选择——页表开销不到1%，内存浪费也不显著。 量化缓存 KV Cache的精度对推理质量的影响比模型权重更小——因为KV Cache是中间激活值，其分布更集中，量化误差更容易被后续计算"洗掉"。 FP8 KV Cache 将KV Cache从FP16量化到FP8，内存减半，几乎无损。现代GPU（H100及以后）原生支持FP8运算，所以推理速度也几乎不受影响。这可能是最简单且性价比最高的KV Cache优化。 INT4 KV Cache 更激进的方案是将KV Cache量化到INT4。内存减少到1/4，但精度损失开始显著——在长序列和需要精确注意力的任务上，INT4 KV Cache可能导致输出质量下降。 ...

大模型推理的KV Cache优化全解 KV Cache是大模型推理中最重要的优化技术，也是最大的内存瓶颈。理解KV Cache的工作原理和优化方法，是构建高效推理服务的基础。 KV Cache是什么 在Transformer的自回归生成中，每生成一个新token，需要计算它对所有之前token的注意力。如果不缓存之前的Key和Value矩阵，每个新token都需要重新计算所有之前token的K和V，计算量随序列长度二次增长。 KV Cache通过缓存之前计算过的K和V矩阵，将每步的计算复杂度从O(n²)降到O(n)。代价是内存占用线性增长——对于Llama-70B模型，生成4K token的KV Cache约占40GB显存。 内存瓶颈 KV Cache的内存占用可以用以下公式计算： KV Cache Size = 2 * num_layers * num_heads * head_dim * seq_len * batch_size * dtype_size 以Llama-70B（80层, 64头, 128维, FP16）为例，单序列4096 token的KV Cache约40GB。这意味着一个80GB显存的A100只能服务两个并发请求——这是制约推理吞吐量的最大瓶颈。 PagedAttention：分页管理 vLLM团队提出的PagedAttention是KV Cache管理的革命性创新。灵感来自操作系统的虚拟内存分页机制。 传统分配的问题 传统方法为每个序列预分配一块连续的KV Cache空间，按最大序列长度分配。这导致严重的内存碎片——大多数序列不会用满预分配的空间，但多余的空间不能被其他序列使用。内存利用率通常只有20-40%。 分页方案 PagedAttention将KV Cache划分为固定大小的"页"（通常16个token），每个序列通过页表映射到物理页。页按需分配——序列增长时才分配新页。 效果是显著的：vLLM的内存利用率提升到90%以上，并发吞吐量提升2-4倍。碎片问题被彻底解决，因为不同序列的页可以散布在物理内存中的任意位置。 页的大小选择 页太小（如1 token）会增加页表开销，页太大（如256 token）则回到预分配的问题。16 token是在大多数场景下的最优选择——页表开销不到1%，内存浪费也不显著。 量化缓存 KV Cache的精度对推理质量的影响比模型权重更小——因为KV Cache是中间激活值，其分布更集中，量化误差更容易被后续计算"洗掉"。 FP8 KV Cache 将KV Cache从FP16量化到FP8，内存减半，几乎无损。现代GPU（H100及以后）原生支持FP8运算，所以推理速度也几乎不受影响。这可能是最简单且性价比最高的KV Cache优化。 INT4 KV Cache 更激进的方案是将KV Cache量化到INT4。内存减少到1/4，但精度损失开始显著——在长序列和需要精确注意力的任务上，INT4 KV Cache可能导致输出质量下降。 ...

操作系统启发：虚拟内存 PagedAttention的核心灵感来自操作系统的虚拟内存管理。在OS中，进程的虚拟内存被分成固定大小的页（Page），物理内存不必连续分配。 PagedAttention将这一思想应用于KV Cache管理： 传统KV Cache: [token0, token1, ..., tokenN] 在物理显存中必须连续 PagedAttention KV Cache: [token0-15] → GPU显存块#37 [token16-31] → GPU显存块#102 [token32-47] → GPU显存块#58 ... （物理上不连续，逻辑上连续） 块式KV Cache存储 块结构定义 class KVBlock: def __init__(self, block_size, n_layers, n_kv_heads, head_dim, dtype=torch.float16): self.block_size = block_size # 每块存储的token数（如16） self.n_layers = n_layers self.n_kv_heads = n_kv_heads self.head_dim = head_dim # 每块的形状: [n_layers, block_size, n_kv_heads, head_dim] self.k = torch.zeros( n_layers, block_size, n_kv_heads, head_dim, dtype=dtype ) self.v = torch.zeros_like(self.k) self.ref_count = 0 # 引用计数（用于共享） self.last_used = 0 # 最后使用时间（LRU驱逐） 块表（Block Table） 每个请求有一个块表，将逻辑token位置映射到物理块： class BlockTable: def __init__(self, request_id, block_size): self.request_id = request_id self.block_size = block_size self.physical_blocks = [] # 物理块索引列表 self.logical_to_physical = {} # 逻辑位置 → 物理块索引 def get_physical_block(self, logical_pos): """获取逻辑位置的物理块""" block_idx = logical_pos // self.block_size offset = logical_pos % self.block_size if block_idx >= len(self.physical_blocks): return None, None # 尚未分配 return self.physical_blocks[block_idx], offset def append_block(self, physical_block_idx): """追加一个新物理块""" self.physical_blocks.append(physical_block_idx) 物理块管理 块池（Block Pool） 所有物理块由中央块池管理： ...

引言 大模型的推理成本通常占AI总成本的70%以上。高效的推理框架不仅能够降低运营成本，还能提升用户体验。2026年，主流推理框架在性能、功能和易用性上都有显著提升。本文对vLLM、SGLang、TensorRT-LLM、TGI四大框架进行深度对比。 框架概览 vLLM 定位： 高吞吐、低延迟的LLM推理引擎 核心技术： PagedAttention：解决KV Cache碎片化问题 Continuous Batching：请求级动态批处理 Tensor Parallelism：模型并行 优势： 吞吐量比HuggingFace Transformers高24倍 社区最大，生态最丰富 支持多种量化格式（AWQ、GPTQ、SqueezeLLM） 局限： 主要优化标准生成场景 高级功能（如Speculative Decoding）仍在演进 SGLang 定位： 面向复杂推理场景的高性能框架 核心技术： RadixAttention：分层缓存的KV Cache管理 结构化输出：JSON、正则表达式约束 推理+训练一体化 优势： 复杂推理场景性能突出 结构化输出支持完善 支持Speculative Decoding 局限： 社区相对较小 文档和生态不如vLLM丰富 TensorRT-LLM 定位： NVIDIA官方的高性能推理优化库 核心技术： 算子级优化：针对NVIDIA GPU深度优化 量化：FP8、INT4、FP4支持 多GPU/多节点分布式推理 优势： NVIDIA硬件上的极致性能 工业级稳定性 与NVIDIA全栈生态集成 局限： 仅支持NVIDIA GPU 配置复杂，学习曲线陡 非NVIDIA硬件兼容性差 TGI (Text Generation Inference) 定位： HuggingFace的推理服务器 核心技术： 动态批处理 张量并行 连续批处理 优势： 与HuggingFace生态无缝集成 部署简单 支持Safetensors模型 局限： ...

引言 KV Cache（键值缓存）是大模型推理中显存占用的最大头。一个512K上下文的推理，KV Cache可能占用数十GB显存。2026年，KV Cache优化技术已经非常成熟，从vLLM的PagedAttention到DeepSeek的MLA，各种创新层出不穷。本文将全面解析KV Cache的优化技术，帮助开发者深入理解并合理选择。 KV Cache基础 为什么需要KV Cache？ Transformer的自注意力机制： Attention(Q, K, V) = softmax(QK^T / √d_k) × V 问题：生成第t个token时，需要K_1, K_2, …, K_{t-1}和V_1, …, V_{t-1}。如果每次都重新计算，复杂度O(n²)。 解决：缓存历史K和V → KV Cache KV Cache的显存占用 对于Llama 4 70B（32层，hidden_size=8192）： 上下文长度 FP16 KV Cache INT8 KV Cache INT4 KV Cache 2K 512MB 256MB 128MB 8K 2GB 1GB 512MB 32K 8GB 4GB 2GB 128K 32GB 16GB 8GB 512K 128GB 64GB 32GB 关键观察：上下文长度每增加4倍，KV Cache增大4倍。 优化技术全景 技术分类 技术路线 核心思路 压缩比 质量损失 注意力优化 减少KV Cache占用 - - ├─ Multi-Query Attention (MQA) 多查询共享KV 1/n_heads 0% ├─ Grouped-Query Attention (GQA) 分组共享KV 1/group_size <0.5% └─ Multi-Head Latent Attention (MLA) 低维潜在表示 8-10× <1% 分页管理 动态内存管理 - - ├─ PagedAttention 分页管理KV Cache 减少碎片 0% └─ RadixAttention 前缀树缓存 复用公共前缀 0% 量化压缩 降低精度 - - ├─ INT8量化 8-bit量化 2× <1% ├─ INT4量化 4-bit量化 4× 2-3% └─ FP8量化 8-bit浮点 2× <0.5% 稀疏化 只保留重要token - - ├─ StreamingLLM 保留初始+近期token 可变 1-3% ├─ H2O 动态淘汰低注意力token 2-4× 2-5% └─ ScissorHands 基于重要性的稀疏化 2-3× 2-4% 注意力优化 1. Multi-Query Attention (MQA) 原理：所有查询头共享同一组KV。 ...

KV Cache是大模型推理中最关键的优化技术，也是最大的内存瓶颈。在70B模型、128K上下文的典型配置下，KV Cache占用超过40GB显存，远超模型权重本身。2026年，KV Cache管理已成为推理系统的核心竞争力。 1. KV Cache基础 1.1 为什么需要KV Cache Transformer自回归生成时，每生成一个新token需要关注之前所有token的Key和Value。为了避免重复计算，将历史K,V缓存下来： $$\text{KV Cache}_t = {(K_1, V_1), (K_2, V_2), …, (K_t, V_t)}$$ 1.2 内存占用计算 KV Cache的显存占用公式： $$\text{Memory}_{KV} = 2 \times L \times H \times S \times d_h \times P \times b$$ 其中： $L$：层数 $H$：注意力头数 $S$：序列长度 $d_h$：每头维度 $P$：精度字节（fp16=2） $b$：batch size 以Llama-4-70B为例（$L=80, H=64, d_h=128$），128K上下文、batch=1： $$2 \times 80 \times 64 \times 131072 \times 128 \times 2 = 274\text{GB}$$ 这个数字远超单GPU显存容量。 2. PagedAttention：分页KV Cache 2.1 核心思想 vLLM提出的PagedAttention借鉴了操作系统的虚拟内存管理，将KV Cache组织为固定大小的页（block），按需分配： ...

连续批处理：推理吞吐的范式革命 在 LLM 推理系统中，如何高效处理并发请求是决定服务成本的核心问题。连续批处理（Continuous Batching）配合 PagedAttention，让 vLLM 实现了比传统推理框架高 5-20 倍的吞吐量。本文深入解析这项技术的原理与工程实现。 一、批处理的演进 1.1 静态批处理（Static Batching） 最简单的批处理方式：等待凑齐一批请求，然后一起推理，直到所有请求完成。 ┌────────────────────────────────────────────────────┐ │ 静态批处理 │ ├────────────────────────────────────────────────────┤ │ │ │ 时间→ 0 1 2 3 4 5 6 7 │ │ │ │ Req1 [G][G][G][G][G][D] ✓ │ │ Req2 [G][G][G][G][G][G][G][G] ✓ │ │ Req3 [G][G][D] ✓ │ │ Req4 [G][G][G][G][G][G][G][D] ✓ │ │ │ │ G=生成, D=完成(停止生成) │ │ │ │ 问题: Req3 在 t=2 就完成了, │ │ 但要等 Req2 到 t=7 整批才结束 │ │ GPU 利用率: ~35% │ └────────────────────────────────────────────────────┘ 核心问题：Padding 浪费 + 等待浪费。不同请求长度差异大，短请求要等长请求完成。 ...

KV Cache：大模型推理的内存瓶颈 如果说 Transformer 架构决定了一个模型的智力上限，那么 KV Cache 就决定了它在实际应用中的性能下限。在 2026 年，KV Cache 已经成为大模型推理系统最核心的优化对象——理解它，是掌握大模型工程的第一课。 一、什么是 KV Cache 1.1 问题：为什么需要缓存 在 Transformer 的自回归推理中，生成第 $t$ 个 Token 时需要计算它与之前所有 Token 的注意力： $$\text{Attention}(q_t, K_{1:t}, V_{1:t}) = \text{softmax}\left(\frac{q_t K_{1:t}^T}{\sqrt{d_k}}\right) V_{1:t}$$ 注意：$K_{1:t}$ 和 $V_{1:t}$ 包含了从第 1 到第 $t$ 个位置的 Key 和 Value。 如果没有缓存：每生成一个新 Token，都需要重新计算所有历史 Token 的 $K$ 和 $V$，这导致了 $O(t^2)$ 的重复计算。 有了缓存：只需计算当前 Token 的 $q_t$，从缓存中读取 $K_{1:t-1}$ 和 $V_{1:t-1}$，再计算新的 $k_t, v_t$ 并追加到缓存。 ┌─────────────────────────────────────────────┐ │ 自回归推理第 t 步 │ ├─────────────────────────────────────────────┤ │ │ │ 无缓存: X_1..t → 全部重新计算 → Y_t │ │ (计算量: O(t)) │ │ │ │ 有缓存: X_t → Q_t ───────────→ Y_t │ │ ↑ │ │ KV Cache (K_1..t-1, V_1..t-1) │ │ (计算量: O(1)) │ │ │ └─────────────────────────────────────────────┘ 1.2 KV Cache 的存储内容 每个 Transformer 层、每个 Token 需要存储： ...

KV Cache 是大模型推理的核心瓶颈。在 72B 模型上，一个 4K 上下文的请求需要 8GB 的 KV Cache；在 128K 上下文时，KV Cache 膨胀到 256GB——比模型权重还大。2026 年，KV Cache 优化已成为推理引擎的"第二战场"。本文将系统性解析从 PagedAttention 到 MLA 的全链路优化技术。 一、KV Cache 基础 为什么需要 KV Cache？ Transformer 自回归解码时，每生成一个 token 需要关注之前所有 token 的 Key 和 Value。如果不缓存，每步都要重算所有历史 token 的 K/V，复杂度 O(n²)；缓存后，每步只需计算新 token 的 K/V，复杂度 O(n)。 KV Cache 大小计算 KV Cache 大小 = 2 × num_layers × seq_len × num_kv_heads × head_dim × dtype_size 以 Qwen3.5-72B 为例： 参数 值 num_layers 80 num_kv_heads (GQA) 8 head_dim 128 dtype FP16 (2 bytes) 单 token KV Cache = 2 × 80 × 8 × 128 × 2 = 327,680 bytes ≈ 320KB 4K 上下文 = 320KB × 4096 = 1.25GB 32K 上下文 = 320KB × 32768 = 10GB 128K 上下文 = 320KB × 131072 = 40GB 关键问题：128K 上下文下，KV Cache（40GB）已接近模型权重大小（72B FP16 = 144GB），成为显存主要瓶颈。 ...