12.4 从这门课到推理研究：路线图

本节位置：模块 12 · 进阶｜前置：11.7、12.3 ｜预计：30 分钟

一句话：你已经有读懂推理论文的数学底座；接下来缺的不是更多定理，而是「把公式映射到系统瓶颈」的经验。

0. 场景引入

周一早上，你要判断一篇 KV Cache 压缩论文值不值得复现。7B 模型， $L = 32, H = 32, d_{k} = 128$ ，fp16，上下文 131072 token。摘要里堆着低秩、量化、稀疏、带宽、吞吐、延迟——每个词你都认得，但拼不成一个系统。

按第 11.7 节的公式，每 token 的 KV 是 $2 \cdot 32 \cdot 32 \cdot 128 \cdot 2 B = 0.5$ MiB；乘 131072 得 64 GiB。权重 14 GB（约 13 GiB），合计约 77 GiB——80 GB 卡只剩 3 GiB 给激活和碎片，batch 只能等于 1。论文声称 2× 压缩：64 → 32 GiB，总量降到 45 GiB，看起来终于能开并发了。

但「2× 压缩」到底能换来多少 tokens/s？如果 KV 只占每步读取总量的一半，2× 压缩最多省三分之一时间；如果只占 1/6，省下的连 10% 都不到。

决策：花 2 周 × 8 卡 ≈ 2688 卡·时复现这篇，还是先做 GQA + int8 KV 的组合？判据其实只有一条：这个优化省下的字节，占每步读取总量的多少。代价是选错方向后三周过去，只得到一句「在我们负载上没收益」——而这句结论本来用一张纸就能算出来。

读完本节，你应该能回答三件事：

一个推理优化该在什么阶段、什么负载下才有收益；
怎样用算术强度和字节数，在 10 分钟内估出收益上限；
从这门课出发，6 个月该按什么顺序补系统与实验能力。

1. 直觉

推理研究可以分成三层：

数学层：矩阵形状、秩、谱、误差——这门课给了你；
系统层：显存层次、带宽、并行、kernel——需要补；
实验层：基准、指标、消融、可复现——需要练。

三层缺一不可。只懂数学，会提出「理论上很美但跑不起来」的方法；只懂系统，会做「工程上很快但数学上没保证」的优化。

💡 一句话直觉：推理研究 = 用数学找结构，用系统实现结构，用实验证明结构真的省了。

1.1 它在现实世界里对应什么：一趟物流

数学层 = 货物的体积和形状（秩、精度、压缩率）；
系统层 = 卡车、仓库、装卸口（HBM、SRAM、带宽）；
实验层 = 实际送达时间与破损率（TTFT、TPOT、质量）。

优化的第一步是分清「装不下」还是「运得慢」：装不下就压缩体积（量化/低秩/驱逐），运得慢就换车或减少搬运（fuse、batching、更大的 batch 摊薄权重读取）。

1.2 这个类比在哪里失效

物流把货物压小不会改变货物本身；量化/稀疏/低秩会改变数值，质量可能掉，所以「省了字节」和「没坏事」必须一起验。物流的瓶颈是静态的，推理的瓶颈随 batch、序列长度和阶段在算力与带宽之间切换。还有，物流加车就行，推理加卡要过通信与并行这一关，收益经常不是线性的。

1.3 量级

decode 每 token 要读一遍全部权重：7B fp16 = 14 GB，而算力只花 $2 N \approx 1.4 \times 1 0^{10}$ FLOP（ $N = 7 \times 1 0^{9}$ ），算术强度 $14 GFLOP /14 GB \approx 1$ FLOP/byte。按 H100 级别的算力 1000 TFLOP/s、带宽 3 TB/s 估算，屋脊点约 300 FLOP/byte——decode 离屋脊点差两个数量级，所以它几乎必然是带宽受限。

2. 定义

2.1 推理的两个阶段

Prefill：处理 prompt，计算密集， $M = T$ 的大 GEMM；
Decode：逐 token 生成，带宽密集， $M = 1$ 的瘦 GEMM + KV Cache 读取。

2.2 核心指标

指标	含义
TTFT	首 token 延迟（prefill）
TPOT/ITL	每输出 token 延迟（decode）
吞吐	tokens/s（整体）
显存	权重 + KV Cache + 激活
质量	困惑度/任务准确率

2.3 主要优化方向

注意力：FlashAttention、稀疏/滑窗、线性注意力；
缓存：GQA/MQA、KV 量化、驱逐、PagedAttention、prefix caching；
权重：量化、蒸馏、剪枝、低秩；
解码：投机解码、并行解码、beam；
系统：批处理、continuous batching、张量/流水并行。

2.4 每个方向的一个问题、一个数字、一个失败模式

方向	具体问题	一个数字	失败模式
注意力	分数矩阵有没有落回 HBM？	$T = 2048$ 时每头 $T^{2} \times 2 B = 8.4$ MB，乘 $B \cdot H$ 后每层 2.15 GB（ $B = 8$ ）	不 fuse 就一直带宽受限，FLOPs 再省也没用
缓存	每 token 的 KV 是多少字节？	0.5 MiB/token（ $L = 32, H = 32, d_{k} = 128$ ，fp16）	长上下文 OOM，并发上不去
权重	量化省字节还是省 FLOPs？	int8 把 14 GB 降到 7 GB	prefill 算力受限时收益接近 0，反量化还可能变慢
解码	投机解码的接受率够高吗？	每步要付 draft + 验证的前向，产出受接受率限制	接受率低时比基线更慢
系统	并发上去后瓶颈在哪？	16 并发 × 4096 token = 32 GiB KV	显存碎片让可用 batch 只有一半

这张表的作用不是背结论，而是拿到一篇论文时先找它动的是哪一行。

3. 为什么这样定义

因为推理的瓶颈会随阶段变化：

prefill 看算力（FLOPs）；
decode 看带宽（bytes/s）；
长上下文看 KV Cache 显存；
高并发看调度与批处理。

同一个优化，在不同阶段/负载下收益完全不同。 所以必须先定位瓶颈，再选数学工具。

3.1 反事实一：只按 FLOPs 做规划，会把 decode 算成「便宜」

Prefill：2048 token 的 7B 前向约 $2 \times 7 \times 1 0^{9} \times 2048 = 2.9 \times 1 0^{13}$ FLOP；按有效 500 TFLOP/s 算 57 ms，摊到每 token 约 0.028 ms。
Decode：每 token 也要 $2 N \approx 1.4 \times 1 0^{10}$ FLOP，但只为 1 个 token 读 14 GB 权重，按 2 TB/s 算 7 ms。

每 token 的 FLOPs 其实一样多（prefill 摊薄后也是 $2 N$ ），时间却差了 250 倍（ $7/0.028$ ）——差别在算术强度：prefill 一份权重喂 2048 个 token，decode 一份权重只喂 1 个。如果只按 FLOPs 排优先级，你会去优化 prefill 的矩阵乘，而用户真正等待的是 decode。这个反例不用跑实验，两行除法就能算出来。

3.2 反事实二：2× 压缩 ≠ 2× 加速

Decode 每 token 要读「权重 + KV」。权重 14 GB（约 13 GiB）：

$T = 4096$ ：KV 2 GiB，读取总量 15 GiB；KV 量化 2× 只省 1 GiB，上限 $15/14 \approx 1.07$ 倍。
$T = 131072$ ：KV 64 GiB，总量 77 GiB；量化 2× 省 32 GiB，上限 $77/45 \approx 1.71$ 倍。

同一个 2× 压缩，在短上下文只值 7%，在 128k 上下文值 71%。 把「压缩率」当「加速比」是推理优化里最常见的空头支票；正确算法是「省下的字节 ÷ 总读取字节」。

反过来，int8 权重在短上下文是 $15/8.5 \approx 1.76$ 倍，在 128k 只有 $77/70.5 \approx 1.09$ 倍。优化的收益由负载决定，不由方法决定。

4. 性质与推导

4.1 算术强度

arithmetic intensity = \frac{FLOPs}{bytes}

GPU 的算力/带宽比决定了「多高的强度才能跑满算力」。这个判据就是 Roofline 模型：算术强度落在屋脊点左侧时，性能由带宽封顶，而不是由算力封顶。Decode 的强度低，所以是带宽受限。

4.2 KV Cache 的 Scaling

cache \propto B \cdot H_{k v} \cdot T \cdot d_{k} \cdot L \cdot bytes

四个旋钮：头数、长度、层数、精度。

4.3 量化的收益边界

量化减少 bytes，但不减少 FLOPs；只有当瓶颈是带宽/显存时，收益才明显。若 prefill 算力受限，量化收益有限（甚至因反量化变慢）。

4.4 低秩的收益边界

低秩减少参数与计算，但需要额外的分解/训练；若秩不够，质量下降。收益取决于任务对低秩的容忍度。

5. 例子

5.1 估算一个 7B 模型的 decode 带宽

$D = 4096, L = 32$ ，权重 fp16 约 14 GB。每生成一个 token，至少要把所有 weight 读一遍：

14 GB （每生成一个 token 读一遍）

若 HBM 带宽 2 TB/s，理论下限 $14/2000 \approx 7$ ms/token，约 140 tokens/s（忽略 KV Cache 与开销）。这就是为什么 decode 很难「算得快」——它主要在搬数据。

5.2 估算 KV Cache

$B = 1, H = 32, T = 4096, d_{k} = 128, L = 32$ ，fp16：约 2 GiB（第 11.7 节）。若并发 16，约 32 GiB，已经超过很多卡的余量。

5.3 场景：选择优化手段

单请求、长上下文：先看 KV Cache 显存 → GQA/量化/驱逐；
高并发：看 batching 与调度 → continuous batching/PagedAttention；
低延迟：看 TTFT/TPOT → 投机解码、kernel 融合；
边缘设备：看权重显存 → 量化/蒸馏。

5.4 场景闭环：短上下文与长上下文的两套选型

输入：7B fp16（14 GB ≈ 13 GiB），80 GB 卡；负载 A 是 4096 token 的聊天，负载 B 是 131072 token 的文档问答；SLO 是 TPOT ≤ 50 ms、质量不低于 fp16 基线的 99%。

计算（2 TB/s）：

A：每 token 读 $13 + 2 = 15$ GiB，7.5 ms；int8 权重后 8.5 GiB → 4.3 ms；只做 int8 KV 则是 14 GiB → 7.0 ms。
B：每 token 读 $13 + 64 = 77$ GiB，约 39 ms；int8 KV 后 45 GiB → 23 ms；只做 int8 权重是 70.5 GiB → 35 ms。

输出决策：A 先量化权重（1.76×），B 先量化 KV（1.71×）；两者都做则 B 到约 38.5 GiB → 19 ms，但精度风险叠加，必须分开回归。单看收益，B 上 KV 量化是唯一能把 39 ms 压进 SLO 一半的动作。

成本：每套方案一次完整评测（长文检索、多轮对话）+ 约 2 周工程；B 的显存从 77 GiB 降到 45 GiB，才谈得上在单卡上稳定跑 batch=1；要真正并发，还得再叠 GQA。显存降不下来时，所有调度优化都是零。

失败条件：① 只测 tokens/s 不看 batch 与序列长度，复现结果无法比较；② kernel 不支持 int8 KV，理论省一半、实测不变；③ 质量在 needle-in-haystack 上掉点，平均分却看不出来。兜底：固定 batch/长度/硬件做 A/B，质量门禁卡在 fp16 基线的 99%，任何一项不过就回退。

6. 常见误区

误区：量化一定加速。纠正：只有带宽/显存受限时收益明显；算力受限时可能因反量化变慢。
误区：低秩一定省。纠正：分解/训练有成本；秩不足会掉质量；需要端到端测量。
误区：看论文的 tokens/s 提升就够了。纠正：还要看 batch、序列长度、硬件、质量指标；不同设置不可直接比较。
误区：数学推导对了，系统一定快。纠正：kernel 效率、内存布局、通信开销都会吞掉理论收益。

7. 概念网络

前置：11.7 KV Cache —— 显存公式。
前置：12.3 全景图 —— 五条主线。
关联：11.8 LoRA（Hu 等, 2021） —— 低秩。
关联：11.9 量化 —— 精度。
关联：10.3 GEMM —— 系统瓶颈。

8. 通往大模型：6 个月路线

第 1–2 月：补齐系统基础

计算机体系结构：cache、HBM、roofline；
CUDA 基础：kernel、shared memory、warp；
读 FlashAttention 论文 + 手写一个 naive attention。

第 3 月：复现一个推理优化

实现 KV Cache（含 GQA），测显存/延迟；
实现 int8 KV 量化，测质量/速度；
写清楚 baseline、指标、消融。

第 4 月：读论文 + 找问题

选 3 篇（KV 压缩、投机解码、量化），做复现笔记；
找「理论收益大但实现差」的点。

第 5–6 月：做一个完整项目

题目示例：长上下文 KV 驱逐策略、低秩 + 量化的联合压缩、投机解码的接受率分析；
要求：端到端 benchmark、质量评估、开源代码。

可检验结论：一个优化是否值得做，至少要看「理论收益（bytes/FLOPs）→ 实现收益（kernel 效率）→ 端到端收益（吞吐/延迟/质量）」三层，缺一层都可能是空头支票。

学错/选错时，下游看到什么：

把压缩率当加速比：论文复现「2× 压缩」成功，上线只快 7%，团队白做两周；
只按 FLOPs 选优化：时间花在 prefill 的 kernel 上，用户感知的 TPOT 没变；
不看 batch/长度就对比 tokens/s：不同设置的数字不可比，评审时被一问就穿；
忽略质量回归：吞吐达标，长文任务准确率掉 5 个点，最后还是回滚。

9. 练习

概念：为什么 decode 是带宽受限？用算术强度解释。
计算：7B 模型 fp16 权重 14 GB，HBM 2 TB/s，理论 decode 速度上限是多少 tokens/s？
计算：KV Cache 2 GiB，并发 8，需要多少显存？若量化到 int8 呢？
场景：长上下文 + 高并发，先优化哪个方向？为什么？
开放：选一个你感兴趣的推理优化，写出「理论收益—实现收益—端到端收益」的验证计划。

参考答案

每 token 只做一次瘦矩阵乘，FLOPs 相对读取的字节数很小，算术强度低，跑不满算力，瓶颈在带宽。
$2000/14 \approx 143$ tokens/s（理论上限，实际更低）。
16 GiB；int8 约 8 GiB。
先看 KV Cache（显存是硬约束），再考虑 batching/调度；否则并发上不去。
开放；示例：KV 量化 → 理论省 2× 字节 → 实现看 kernel 是否支持 → 端到端测吞吐/质量。

10. 一页速记

推理三阶段：prefill 算力、decode 带宽、长上下文显存。
优化先定位瓶颈，再选数学工具。
量化省字节、低秩省参数/计算，收益取决于瓶颈。
评估三层：理论、实现、端到端。
项目 > 论文数量；可复现 > 花哨。
物理意义/现实对应：算术强度 = 每搬 1 字节能做多少次运算；decode 是「搬得多、算得少」，所以优化的是卡车（带宽），不是发动机（FLOPs）。
判据：优化收益 = 省下的字节 ÷ 每步读取总字节；分母由负载决定，所以同一个方法在不同上下文长度下收益可以差 10 倍。

11. 参考文献与致谢

这一页的知识不是凭空来的。下面列出本页直接借用的原始工作与权威整理；正文中的人名、定理名已链接到对应条目。链接优先指向 DOI、arXiv 或可长期访问的原文存档。

Williams、Waterman 与 Patterson（2009）：Roofline: An Insightful Visual Performance Model for Multicore Architectures。把「算力屋顶 + 带宽斜坡」画成一张图，本页 §4.1 的算术强度判据与「decode 是带宽受限」的结论都出自这个模型。Communications of the ACM
Dao 等（2022）：FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness。按 HBM/SRAM 的读写次数而不是 FLOPs 来设计 attention kernel，本页 §2.3「注意力」方向与 §8 第 1–2 月的必读论文。arXiv:2205.14135
Kwon 等（2023）：Efficient Memory Management for Large Language Model Serving with PagedAttention。把 KV Cache 按页管理以消除显存碎片，是本页 §2.3「缓存」与 §5.3「高并发先看调度」的出处（vLLM）。arXiv:2309.06180
Hu 等（2021）：LoRA: Low-Rank Adaptation of Large Language Models。用 $B A$ （ $B \in R^{d \times r}$ 、 $A \in R^{r \times k}$ ， $r ≪ d, k$ ）的低秩增量替代全参数微调，是本页 §4.4「低秩的收益边界」的原型。arXiv:2106.09685

下一篇 → 返回课程首页

返回 M12 导览去练习场

随堂测 · 4 题

数值难度 2第 1 / 4 题

一个 7B 模型 fp16 权重共 14 GB，HBM 带宽 2 TB/s。忽略 KV Cache 与其他开销，decode 阶段每 token 需读一遍权重，理论速度上限约为多少 tokens/s？

没思路？看原文

源文件：12-进阶/04-研究路线.md