AI Infra 推理必知必会：LLM 请求生命周期、KV Cache 与 GPU 调度

AI Infra 推理工程的核心任务，是把一个已经训练好的模型变成稳定、低延迟、高吞吐、可扩展、可观测、成本可控的线上服务。云栈社区梳理了这份推理知识地图，帮工程师建立一套可以迁移的分析方法。

本文只讨论推理相关知识，不展开训练集群、反向传播和训练并行。目标是建立一套可以迁移到不同模型、GPU 和推理引擎上的分析方法：

业务请求
-> Tokenizer
-> 显存与计算估算
-> Prefill / Decode
-> KV Cache
-> Batching 与调度
-> GPU Kernel 与并行
-> 监控、压测、容量和成本

推理 Infra 的知识不是孤立的。模型结构会影响 KV Cache，Tokenizer 会影响 token 数，token 数会影响 Prefill、KV、并发、延迟和成本。

1. 推理请求生命周期

一次大模型请求通常经历：

请求到达
-> 网关、鉴权、限流
-> 排队
-> Tokenizer
-> Prefill
-> Decode 循环
-> 流式返回
-> 释放 KV Cache

阶段	主要工作	典型指标	主要瓶颈
Tokenizer	文本转 token id	tokenize time、token 数	CPU、规则和词表
Prefill	一次处理输入 Prompt	TTFT、Input TPS	GPU 算力、Attention、KV 写入
Decode	逐 token 生成输出	TPOT、Output TPS	HBM 带宽、KV 读取、调度

最重要的延迟公式：

E2E Latency
= Queue Time
+ TTFT
+ 输出 token 数 × TPOT

一个请求慢，可能有三种完全不同的原因：排队慢、首 token 慢、持续输出慢。

2. 业务负载建模

优化前至少收集：

平均 RPS、峰值 RPS、突发系数
平均和 P95/P99 输入 token 数
平均和 P95/P99 输出 token 数
最大上下文长度
流式还是非流式
是否 RAG、Agent、工具调用、多轮对话
是否存在共享 System Prompt
TTFT、TPOT、E2E 的 P95/P99 SLO
单租户和多租户配额

RPS 必须转换成 token 吞吐：

Input TPS = RPS × 平均输入 token
Output TPS = RPS × 平均输出 token

例如：

RPS = 100
平均输入 = 1,200 token
平均输出 = 300 token

Input TPS = 100 × 1,200 = 120,000 token/s
Output TPS = 100 × 300 = 30,000 token/s

不能只看 RPS。100 RPS 的短问答和 100 RPS 的 10k 长 Prompt 服务，对 GPU 的压力完全不同。

3. Tokenizer 与序列长度

模型不直接读取字符，而是读取 token id。Tokenizer 会影响：

输入 token 数
输出 token 数
上下文占用
Prefill FLOPs
KV Cache
Attention 的 N² 项
计费和吞吐
中文、代码、emoji 和罕见字符的表达效率

BPE、WordPiece、SentencePiece、Byte-level BPE 等算法都属于 Tokenizer 生态，但实际部署必须使用与模型训练匹配的 tokenizer 文件和配置。

应关注：

tokenizer.json、vocab、merges
特殊 token 和 chat template
中文、英文、代码、URL、emoji 的 token 效率
平均 token 数以及 P95/P99 token 数
[UNK] 或 byte fallback 比例

如果 token 数增加 20%，线性 Prefill 主项约增加 20%，KV Cache 约增加 20%，Attention 理论平方项可能增加：

1.2² = 1.44

即约 44%。

4. 模型权重显存

最基本公式：

权重显存 ≈ 参数量 × 每参数字节数

精度	每参数字节数	70B 权重
FP32	4	280GB
BF16 / FP16	2	140GB
FP8 / INT8	1	70GB
INT4	0.5	35GB

实际运行显存还需要加上：

模型权重
+ KV Cache
+ CUDA Graph
+ Attention / GEMM Workspace
+ NCCL 通信 Buffer
+ Runtime
+ 显存碎片
+ 安全余量

“模型能加载”只是启动条件，不代表它能承载线上并发。

KV Cache 是动态区域，随并发和上下文增长；运行时 Buffer 与安全余量不能被忽略。

5. Attention Head、MHA、GQA、MQA

常见参数：

Hq：Query Head 数
Hkv：Key / Value Head 数
d_head：每个 Head 的维度

三种结构：

MHA：Hkv = Hq，每个 Query Head 使用独立 K/V
GQA：1 < Hkv < Hq，多组 Query Head 共享 K/V
MQA：Hkv = 1，所有 Query Head 共享一组 K/V

通用 KV 公式：

KV Bytes / token
= 2 × Layer 数 × Hkv × d_head × bytes_per_element

GQA/MQA 最确定的推理收益来自 KV Cache 容量和历史 K/V 访存减少。但 Query Head 数通常不变，因此不能简单理解为 Attention FLOPs 也按 Hkv/Hq 等比例减少。

6. KV Cache

KV Cache 保存历史 token 在每层 Attention 中的 Key 和 Value，供后续 Decode 读取。它不保存历史 Q。

单 token、全模型的 KV Cache：

KV Bytes / token
= 2 × L × Hkv × d_head × bytes

KV Cache 的增长方向：

Layer 数越多，KV 越大
Hkv 越多，KV 越大
上下文越长，KV 越大
活跃请求越多，KV 越大

KV Cache 接近上限会导致：

新请求无法准入
Waiting Queue 增长
TTFT 上升
请求抢占或重算
显存分配失败和 OOM

Paged KV Cache 将缓存切成 Block，按需分配和释放，主要解决连续分配、内部浪费和显存碎片问题。它不能创造额外显存。

7. Prefill 计算

Prefill 一次处理整个输入 Prompt，并构建输入 token 的 KV Cache。

线性层主项：

Prefill FLOPs_linear ≈ 2 × P × N

其中 P 是参数量，N 是输入 token 数，2 来自乘加 FLOPs 计数。

例如 70B 模型处理 4k token：

2 × 70B × 4,000
= 560 TFLOPs

Attention 的全矩阵上界：

FLOPs_attention_full ≈ 4 × L × N² × d_model

其中 N 是序列长度（token数量，上下文长度），d_model 是模型隐层维度，L 是 Transformer 层数。

它来自两次矩阵乘法：

Q × Kᵀ
Attention Score × V

Causal Attention 的逻辑有效区域约为下三角，理想计算量约减半，但实际是否跳过无效 Tile 要看 Kernel。

Prefill 典型特点：

输入 token 可以组成大矩阵并行处理
GPU Tensor Core 利用率通常较高
输入越长，TTFT 越高
长上下文会放大 Attention 和 KV 写入
过多 Prefill 会挤占在线 Decode

8. Decode 计算与显存带宽

Decode 每次只生成一个或少量 token，但需要反复读取模型权重和历史 KV Cache。

低 Batch、权重带宽主导时：

Decode tokens/s 上限
≈ HBM 带宽 / 每轮读取的权重数据

70GB 权重、3TB/s HBM：

3,000GB/s / 70GB
≈ 42.8 token/s

这是只考虑权重读取的理想上界，不是可承诺的实际速度。完整单轮数据量还包括：

权重读取
++ 历史 KV 读取
++ 新 KV 写入
++ 激活与 Workspace
++ TP 通信
++ 调度与采样

Decode 常见是显存带宽受限，而不是 FLOPS 受限。增加 Batch 可以让一次权重读取服务多个活跃序列，提高聚合 Output TPS，但不一定提高单个请求的流式速度。

9. Prefill 与 Decode 对比

维度	Prefill	Decode
处理方式	一次处理 N 个输入 token	每轮生成 1 个 token
用户指标	TTFT	TPOT
主要资源	GPU 计算、Attention	HBM 带宽、KV 读取
关键输入	Prompt 长度	活跃并发、上下文长度
典型优化	FlashAttention、Chunked Prefill、Prompt 压缩	Continuous Batching、量化、Speculative Decoding
主要风险	长输入独占 GPU	输出过长占用 slot 和 KV

在线服务必须同时保护 TTFT 和 TPOT：Prefill 太多，Decode 会卡顿；Decode 太多，新请求 TTFT 会排队。

10. Batching 与调度

Static Batching

固定数量请求一起执行，实现简单，但容易被最长请求拖住，Padding 浪费大，在线流式体验通常较差。

Dynamic Batching

在短等待窗口内合并请求，在吞吐和 TTFT 之间折中。

Continuous Batching

每轮 Decode 重新调度：完成请求释放 slot，新请求及时加入，短请求不必等待最长请求完成。

常用控制量：

max_num_seqs
max_num_batched_tokens
GPU memory utilization
Prefill token budget
Chunked Prefill

Batch 不是越大越好。超过吞吐甜点区后，KV 读取、排队、TPOT 和 P99 可能快速恶化。

11. Chunked Prefill

Chunked Prefill 把长 Prompt 的计算拆成多个 Chunk，在 Chunk 之间穿插 Decode。

100k 输入，Chunk = 4k
Chunk 数 = ceil(100,000 / 4,000) = 25

它切的是计算时机，不是上下文语义。后续 Chunk 仍然通过已有 KV Cache 看到前缀。

收益：

• 避免长 Prefill 一次独占 GPU
• 保护在线请求 TPOT P95/P99
• 适合 RAG、长文档、代码库和 Agent

代价：

• 调度更复杂
• 纯 Prefill 吞吐可能下降
• Chunk 太小会增加 Kernel Launch 和调度开销
• Chunk 太大仍会阻塞 Decode

12. Prefix Cache 与 Paged KV

Prefix Cache

对共享 System Prompt、工具定义、固定 RAG 前缀，Prefix Cache 可以复用已经计算好的 K/V：

共享前缀命中
-> 跳过重复 Prefill
-> 只计算动态后缀
-> 降低 TTFT 和 Input TPS

命中要求：

输入字节一致
Tokenizer 配置一致
特殊 token 一致
前缀 token ID 一致

Paged KV Cache

将 KV Cache 切成固定大小 Block，按需申请和释放：

请求增长 -> 申请新 Block
请求完成 -> 释放 Block

它减少显存碎片和按最大长度预分配的浪费，但不能解决真实容量不足。

13. 并行策略

Tensor Parallel，TP

按层内矩阵切分到多张 GPU：

权重本地大小 ≈ 完整权重 / TP size

优点是单卡显存压力降低；代价是每层可能需要 All-Reduce 或 All-Gather。优先使用 NVLink/NVSwitch，跨节点 TP 必须压测。

Pipeline Parallel，PP

按层切分：

GPU 1：Layer 1-20
GPU 2：Layer 21-40
GPU 3：Layer 41-60
GPU 4：Layer 61-80

可以放下更大模型，但会增加流水线空泡和端到端路径长度。

Data Parallel，DP

部署多个完整模型副本，通过负载均衡分发请求。适合高 RPS 横向扩展和故障隔离。

常见组合：

单副本内部 TP
多个副本之间 DP

14. 量化

量化降低权重、激活或 KV Cache 的数值位宽。

精度	70B 权重粗估	典型取舍
BF16	140GB	质量和兼容性基线
FP8 / INT8	70GB	生产性能和质量折中
INT4	35GB	显存和成本优先，需验证质量

量化收益：

权重显存下降
HBM 权重流量下降
GPU 数量可能下降
单位 token 成本下降

量化风险：

数学、代码和长上下文能力退化
结构化输出或工具调用失败率变化
量化 Kernel 效率不理想
scale / zero point 增加额外流量

KV Cache 也可使用 FP8/INT8，但必须验证真实业务质量。

15. Speculative Decoding

小模型先猜多个 token，大模型一次验证：

Draft Model -> 预测 k 个 token
Target Model -> 并行验证
接受正确 token

适合 Decode 主导、输出较长且 Draft Acceptance Rate 较高的场景。

Acceptance Rate
= 被接受的 Draft Token 数 / Draft Token 总数

如果输出很短、Draft 质量差或主要瓶颈是长 Prompt Prefill，收益可能有限。

16. GPU、Kernel 与通信

推理性能不能只看理论 FLOPS。还要看：

HBM 带宽利用率
Tensor Core 利用率
Kernel Launch 次数
Global Load / Store
L2 Cache 命中
NCCL 通信时间
PCIe / NVLink 拓扑
CPU Tokenizer 和调度耗时

Prefill 通常更容易达到高矩阵利用率；Decode 经常更接近 HBM 带宽问题。FlashAttention、Paged Attention 和量化 Kernel 会改变实际有效性能。

17. 性能指标体系

用户体验

TTFT P50 / P95 / P99
TPOT P50 / P95 / P99
E2E Latency P50 / P95 / P99
请求成功率
流式连接中断率

负载与调度

RPS / RPS
Input TPS
Output TPS
Waiting Queue Length
Queue Time
Active Sequences
Prefill / Decode Token 数
请求输入和输出长度分布

GPU 与显存

GPU Compute Utilization
HBM Bandwidth Utilization
GPU Memory Usage
KV Cache Usage
KV Free Blocks
OOM 次数
Preempt / Swap / Recompute
CUDA / NCCL Error

缓存与业务

Prefix Cache Hit Rate
每租户 RPS
每租户 token 使用量
每成功请求成本
每百万 Input / Output Token 成本

18. 故障诊断流程

常用判断：

Queue Time 高
=> 看容量、限流、实例数、请求突发、长请求和准入

TTFT 高但 Queue Time 低
=> 看 Prefill、输入长度、Prefix Cache、长 Prompt 调度

TPOT 高
=> 看 Decode 并发、显存带宽、TP 通信、Batch 策略

KV Cache 接近满
=> 看上下文、并发、KV 精度、Prefix Cache、显存预留

如果 GPU 利用率低但延迟高，还要检查：

CPU Tokenizer
网关和网络
调度器空转
Batch 太小
Python / RPC 开销

19. 容量规划

吞吐约束

实例数
= 业务 Output TPS / 单实例 Output TPS

并发约束

Little's Law：

并发数 ≈ RPS × 平均请求停留时间

KV 约束

实例数
= 业务并发 / 单实例安全并发

最终：

实例数
= max(吞吐约束实例数,
     并发约束实例数,
     KV 约束实例数)
× 冗余系数

冗余系数需要覆盖：

单实例故障
滚动发布
流量突刺
缓存失效
GPU 性能抖动
长请求比例上升

20. 成本计算

每百万 token 成本：

每百万 token 成本
= 每小时实例成本
/ (实例吞吐 token/s × 3,600)
× 1,000,000

必须区分：

Input Token 成本
Output Token 成本
混合 Token 成本
每请求成本
每成功业务任务成本

一个低价模型如果任务成功率更低、重试更多，真实业务成本可能反而更高。

21. 压测方法

单请求基线

测无排队时的：

TTFT
TPOT
单请求生成速度
显存占用
GPU 与 HBM 利用率

并发爬坡

1 -> 2 -> 4 -> 8 -> 16 -> 32 -> 64

记录：

Output TPS
TTFT P95/P99
TPOT P95/P99
Queue Time
KV Usage
OOM / Reject

长短请求混合

例如：

80%：1k 输入，200 输出
15%：8k 输入，500 输出
5%：32k 输入，1k 输出

故障压测

副本下线
GPU 重启
Prefix Cache 清空
流量突然翻倍
上游重试风暴
超长请求集中进入

上线工作点应该位于吞吐拐点之前，而不是单纯追求峰值吞吐。

22. 推理优化优先级

建议按以下顺序推进：

1. 明确 RPS、输入输出长度和 SLO。
2. 建立单请求与并发基线。
3. 计算权重和 KV Cache 显存边界。
4. 开启 Continuous Batching 和 Paged KV。
5. 控制最大上下文和最大输出长度。
6. 调整 max_num_seqs 与 max_num_batched_tokens。
7. 使用 Chunked Prefill 保护 Decode。
8. 优化 Prompt、RAG、历史对话和输出长度。
9. 对共享前缀启用 Prefix Cache。
10. 评估 FP8、INT8、INT4 和 KV 量化。
11. 对 Decode 主导场景评估 Speculative Decoding。
12. 用 TP 承载单模型，用 DP 扩展流量。
13. 做长短请求、租户和优先级隔离。
14. 用真实压测结果做容量和成本核算。

23. 生产上线检查清单

模型与配置

模型权重精度已确认
Tokenizer 与模型严格匹配
特殊 token 和 chat template 正确
最大上下文已设置
最大输出已设置
MHA/GQA/MQA 配置已确认

显存与服务

权重、KV、Workspace 已估算
KV Cache 安全水位已设置
Paged KV 已启用
OOM 和拒绝策略已验证
滚动发布仍有容量余量

调度与性能

Continuous Batching 已验证
max_num_seqs 已压测
Prefill Budget 已设置
Chunked Prefill 已压测
短长请求隔离策略已确认

观测与应急

TTFT / TPOT / Queue Time 有 P95/P99
KV Free Blocks 可观测
Prefix Cache Hit Rate 可观测
OOM、拒绝、抢占有告警
限流、降级、扩容、回滚可执行

24. 必须记住的公式

权重显存
= 参数量 × bytes_per_parameter

KV Bytes / token
= 2 × Layer × Hkv × d_head × bytes

KV Bytes / request
= KV Bytes / token × context_tokens

Prefill FLOPs
≈ 2 × 参数量 × 输入 token 数

Attention FLOPs 全矩阵上界
≈ 4 × Layer × N² × d_model

Decode 权重带宽上界
≈ HBM Bandwidth / 权重字节数

并发
≈ RPS × 平均请求耗时

Input TPS
= RPS × 平均输入 token

Output TPS
= RPS × 平均输出 token

E2E
= Queue Time + TTFT + Output Tokens × TPOT

25. 最终知识地图

成为合格的 AI Infra 推理工程师，至少要能回答：

一个模型能否放进 GPU？
权重之外还剩多少 KV Cache？
一个 8k 请求需要多少 KV？
MHA、GQA、MQA 对并发有什么影响？
Prefill 和 Decode 谁是瓶颈？
为什么 GPU FLOPS 不高但 HBM 带宽很高？
Batch 增大为什么提高聚合吞吐？
为什么长 Prompt 会拖慢在线聊天？
Chunked Prefill 如何保护 TPOT？
Prefix Cache 为什么能降低 TTFT？
TP、PP、DP 应该如何选择？
量化省下的显存是否真的转化成吞吐？
实例数如何同时满足 RPS、并发、KV 和故障冗余？
线上 Queue Time、TTFT、TPOT、KV 满载分别怎么排查？

最终可以用一句话概括 AI Infra 推理：

把 token 变成 GPU 上可高效调度的数据流，
在显存、算力、带宽、通信、延迟、吞吐、稳定性和成本之间找到可持续的工作点。

思考题：在实际项目中，你是先优化 TTFT 还是先优化 TPOT？欢迎在云栈社区分享你的实战经验与踩坑记录。