GPU推理深度拆解：KV Cache视角

Deep Dive

GPU推理深度拆解

以 KV Cache 为线索，拆解推理阶段、性能瓶颈与全栈优化方案

导读

本笔记从 KV Cache 视角审视 GPU 推理的计算形态，覆盖推理阶段划分、性能瓶颈、缓存管理与优化、PagedAttention、MLA、长上下文稀疏注意力及 DeepSeek 全栈推理设计。

KV Cache PagedAttention MLA PD分离投机解码长上下文

核心概念：推理阶段与自回归

prefill→ decode→ verify

严格意义分为 prefill、draft、verify 三阶段，现代演进已分离 draft 与 verify。
自回归特性：新 token 依赖全部历史 token，该依赖不随新 token 加入而改变 —— 这是 KV Cache 合法性的前提。
双向 encoder 模型无法用缓存减少计算。
缓存 K 和 V 而非 Q：Q 仅当前 token 使用，历史读取需要 K 和 V；丢弃 KV Cache 后只能重算，无法从 token ID 直接映射。

KV Cache 就是 Transformer 的循环状态

性能指标与瓶颈

MFU

有效 flops / 硬件峰值 flops，衡量 compute bound 下的性能

MBU

衡量 memory bound 下算子质量

Serving 延迟指标

TTFT（首 token 时间）、TPOT（每 token 时间）、ITL、End-to-end latency
需按 P50 / P90 / P99 分位报告，不能只看均值

关键洞察

batch size 对吞吐和延迟通常是权衡关系
online 负载有延迟约束，约束下的吞吐才叫 goodput
延迟要求越高，吞吐一般越低；工业界更关心延迟足够前提下的吞吐
「prefill 是 compute bound，decode 是 memory bound」需批判性看待，限制因素变化后需 case by case 分析

性能下界推导

以 70B 模型 + H100 为例的简化模型：

140GB

70B BF16 权重

3.35TB/s

H100 HBM 带宽

≈42ms

每 token 延迟下限

≈24 tps

理论上限

缓解方式：大 batch 同时服务多个请求、压缩权重、投机解码、提高硬件带宽。

读一次权重只产生一个 token，是 decode 性能差的核心原因；大 batch 是核心优化手段。

KV Cache 大小与分配演进

Llama 3.3 70B 示例

2 × 80层 × 8 KV heads × 128 dim × 2 bytes ≈ 320KB / token

MLA 通过压缩 latent（512 维 + 64 维 RoPE）使 KV Cache 小约一个数量级。

分配演进

早期按 max sequence length 预留 → 严重内碎片
PagedAttention 引入 OS 虚拟内存思想：block table 逻辑块→物理块映射，内碎片降为单个 block
block 大小权衡：大 block 利于合并与 TMA 传输，小 block 浪费少但不利 bulk transfer

缓存命中与复用

token 级完全一致可复用 KV block，以 block 为粒度做命中管理
vLLM 用 block cache、SGLang 用 radix tree 表达共享分层前缀
逐出策略常用 LRU，正在处理请求的 cache 不可逐出

Offload 层级

GPU显存→ CPU内存→ NVMe→ 远端存储

越远容量越大但带宽越低
需比较传输时间与重算时间，传输必须满足 SLO
P2P 传输（如 MoonCake、VM-Air、UCX）实现搬运与计算流水重叠

如果传输时间不满足 SLO，搬回来也没用，吞吐是无效的。

长上下文优化

53K

qkv计算与权重参数交叉点（Llama为例）

56%

DeepSeek 输入 cache 命中率

Agent + coding 场景命中率可能达 90%–95%，此时 prefill 甚至不再是 compute bound。

模型层：稀疏注意力

NSA / DSA：相邻 token 块压缩成粗粒度 + 按重要性 top-k + sliding window attention
稀疏损失需通过训练修正；training-free 方法可能让模型变笨很多

系统层：Context Parallel

ring attention + online softmax 保证正确性
三角划分实现负载均衡
chunked prefill 解决调度干扰；典型形态：prefill 实例开 CP + PD 分离，decode 实例不开 CP

无论做多好的常数级优化（如 MLA），随上下文长度变化的算法复杂度并未改变。

推理引擎创新

Lightning Indexer

轻量打分机制，常数级开销，扩展至 200K / 128K 上下文

三层 Attention（1M 上下文）

compress + sparse + fully compressed 与 sliding window 结合，弥补稀疏性导致的 Transformer 状态损失

PD 分离

解决 prefill 与 decode 的资源冲突，但需高速传输 KV Cache
显式传输 KV，可逐层传输 + 非阻塞单边操作隐藏延迟
IB 带宽有限，传输 40GB KV 需约 2.8 秒

并行策略选择：TP 节点内、PP 跨节点、EP 用于 MoE、CP 用于长上下文；decode 侧通常不开 CP，但 EP 可提高 batch size。

算子优化要点

FlashAttention 利用 memory hierarchy + online softmax，同时保证数学等价与硬件友好
CUDA Graph 消除 launch overhead：需静态 shape 与地址，必须 pad 到最近桶
Group GEMM 用 mask 布局替代 continuous 布局（兼容 CUDA Graph）
H100 上打满算力所需 arithmetic intensity 很高；decode batch size=1 时 SM 利用率极差

DeepSeek 全栈优化

DeepGEMM

FP8、Group GEMM；FP8 需扩大 core 解决累计精度不足

DeepEP

normal 模式先 NVLink 去重再 RDMA；low latency 模式直发 + hook 重叠

MLA 将 dispatch + gemm1 + 记过 + gemm2 + combine 融合为单 kernel，需 symmetric memory 支持远端 load/store
Work specialization：dispatch / gemm / all-to-all 三类 warp 角色
通信发起者为 GPU（IBDA）而非 CPU proxy（IBRC）
Blackwell B200：权重 FP4 + 激活 FP8 精度配置
节点间带宽比节点内慢约一个数量级

全栈设计才能提供场景 dependent、模型 dependent 的高性能推理方案。

投机解码

加速比 = τ / (1 + draft 开销)

EAGLE 支持草稿树，dFlash 基于 block diffusion 做并行 draft，解决串行限制
MTP 训练自带，开源模型默认享受收益
dSpark：帕累托最优的参数动态调整，根据接受率与 batch 大小实时决策
小 batch 时 decode 是 memory bound，有充足算力做投机解码；大 batch 接近 compute bound 时需重新评估

推理引擎生态

vLLM

PagedAttention，借鉴 OS 页面表思想

SGLang

RadixAttention 前缀复用

TensorRT-LLM

NVIDIA 官方，算子级极致调优

Dynamo

编排层，统筹调度

各引擎更多是各自演进，花心思多的场景支持就好。

金句墙

KV cache 就是 Transformer 的循环状态。

读一次权重只产生一个 token，是 decode 性能差的核心原因；大 batch 是核心优化手段。

cache 命中率足够高时，prefill 甚至不再是 compute bound。

延迟要求越高，吞吐一般越低；工业界更关心延迟足够前提下的吞吐。

如果传输时间不满足 SLO，搬回来也没用，因为吞吐是无效的。

通用的 draft model 肯定比不上针对自己场景训的专用的。

如果模型智力差距很大，无脑选最聪明；差不多则选最低成本——serving 的目标是满足 SLO 的前提下最低成本最高吞吐。

总结

从 KV Cache 视角看，GPU 推理优化是一项系统工程：

模型层决定缓存合法性与稀疏可能性；
系统层管理缓存分配、复用与 offload；
硬件层约束带宽、显存与计算强度；

最终在「算力、显存、带宽」之间寻找最优平衡。全栈设计才是高性能推理的终极答案。

由 CuteNote.app 颜值笔记生成