15 篇论文导读 · 两圈阅读顺序

第一圈 10 篇打地基 + 第二圈 5 篇追前沿。每篇 1-2 小时，读法：找出"问题—方法—代码对应"三段。

AI infra 这条线，读完第一圈 10 篇 ≈ 拿到 80% 的工程语言，能当 framework 去快速吸收新论文； 第二圈 5 篇把这两年最热的方向（投机解码、PD 分离、量化）补上。 顺序经过设计：每一篇都引出下一篇要回答的新问题——下面的 坐标系、关系图和几个可交互的小实验（online softmax、投机解码加速比）就是帮你把这张网看清。

00先建坐标系：4 条优化轴

下面这些论文乍看很散——有的讲内存，有的讲调度，有的写 CUDA。 但它们其实都在攻同一台机器上的 4 个瓶颈之一。先把这张坐标系装进脑子， 之后每读一篇，第一件事就是问："它在动哪条轴？" 这是把孤立论文连成知识网的关键。

论文关系图 · 每一篇引出下一篇

顺序不是随机的：解决一个瓶颈，会把下一个瓶颈顶到台面上。 hover 节点看它"逼出了谁"，点节点跳到对应导读。点上方色块可按轴筛选。

01必读 7 篇 · 按月对齐

① PagedAttention (vLLM) · SOSP 2023 M2 显存

Kwon et al. · "Efficient Memory Management for Large Language Model Serving with PagedAttention"
arxiv.org/abs/2309.06180 · github.com/vllm-project/vllm

三段摘要

• 问题：朴素 KV cache 给每请求预分配 max_len 连续段，内/外部碎片 + 无法共享 prefix，显存利用率 ~20-40%。
• 方法：固定 block (16 token) + block table，OS 虚拟内存的 GPU 重写。Attention kernel 内通过 block table indirection 读取 KV。配合 prefix caching 实现 COW-like 共享。
• 结果：throughput 提升 2-4×（相比 FasterTransformer），显存利用率 ~96%。

关键图

• Fig 2：朴素 KV cache 利用率分布——20-40% 是论文给出的"未优化前数字"。
• Fig 5：block table 示意图，跟 OS 页表完全平行。
• Fig 18 (§6.4)：block size 消融实验，4-32 几乎一样，64+ 掉。

看完读的代码

• vllm/v1/core/kv_cache_manager.py — 总管
• vllm/v1/core/block_pool.py — free list + hash 共享
• csrc/attention/paged_attention_v1.cu — kernel 端的 indirection

追问

1. block size 为什么是 16？(论文 §6.4，回看 M2 §5.3)
2. 为什么 prefill 通常不用 PagedAttention kernel？
3. swap-out 比 recompute 在哪些 workload 下更优？(论文 §5.4)

② Orca · OSDI 2022 M3 调度

Yu et al. · "Orca: A Distributed Serving System for Transformer-Based Generative Models"
usenix.org/conference/osdi22

三段摘要

• 问题：传统 batching 等齐再跑（request-level scheduling），长短不齐时 batch 中"短请求要等长请求结束"，浪费严重。
• 方法：iteration-level scheduling —— 每个 token step 重新决定 batch 成员。selective batching —— 同一 batch 中不同请求的 prefill/decode 可以混跑。
• 结果：throughput vs latency Pareto 优于静态 batching 大约 2-4×（数据集而异）。

关键图

• Fig 1：朴素 batching vs iteration-level，能直观看出"等待时间"的差异。
• Fig 6：selective batching 的逻辑——同 step 内不同请求阶段不同。

看完读的代码

• vllm/v1/core/sched/scheduler.py · schedule() — vLLM 的 iteration-level scheduler
• 注意 vLLM 没用 selective batching 的全部细节（chunked prefill 是另一种思路，见 Sarathi-Serve）

追问

1. Orca 的 selective batching 跟 Sarathi-Serve 的 chunked prefill 解的是同一个问题吗？哪个更通用？
2. iteration-level scheduling 的代价是什么？(每 step 都要 reschedule + 重组 batch tensor)

③ Sarathi-Serve · OSDI 2024 M3 调度

Agrawal et al. · "Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve"
arxiv.org/abs/2403.02310

三段摘要

• 问题：Continuous batching 里 prefill 跟 decode 混 batch 时，prefill 的高 compute 让整个 batch 慢下来 —— decode 请求 TTFT/ITL 翻倍。
• 方法：chunked prefill —— 把一个长 prompt 的 prefill 切成多个固定大小的 chunk，每个 chunk 跟若干 decode 一起跑。这样每个 step 的计算量稳定。
• 结果：固定 ITL（inter-token latency）下 throughput 提升 2-3×。

关键图

• Fig 1：prefill 混入 decode batch 后单步 latency 暴涨的真实测量。
• Fig 4：chunked prefill 的调度时间线，跟 vLLM 实现完全对得上。

看完读的代码

• vLLM scheduler.py 里搜 chunked_prefill 或 num_computed_tokens
• SchedulerOutput.scheduled_tokens 字段

追问

1. chunk size 怎么选？跟 token budget 是什么关系？
2. chunked prefill 啥时候不该开？(很短 prompt 的 workload；chunk 太多 overhead 反而升)

④ SGLang / RadixAttention · NeurIPS 2024 M2 显存

Zheng et al. · "SGLang: Efficient Execution of Structured Language Model Programs"
arxiv.org/abs/2312.07104

三段摘要

• 问题：vLLM 的 prefix caching 只能命中"整块前缀"。在结构化场景（多 agent 分支、tree of thoughts、self-consistency 多采样）下，prefix 在 token 级别分叉，块级命中浪费。
• 方法：用 radix tree（基数树）做 token 级 KV 索引。每个 prompt 的 KV 沿 tree 路径存储，分叉点自然共享，叶子节点不同则各自占用。
• 结果：在多分支推理 workload 下，throughput 2-5× of vLLM 同期版本。

关键图

• Fig 5：Radix tree 示意 —— prompt 的 KV 像 trie 一样组织。
• Fig 9：vs vLLM 在 tree-of-thoughts workload 上的吞吐对比。

看完读的代码

• sglang/srt/mem_cache/radix_cache.py
• 跟 vLLM 的 block_pool.py 对照学

追问

1. RadixAttention 对 system-prompt-only 共享场景有优势吗？(几乎没有；vLLM 的整块命中已经够)
2. Radix tree 的 lookup 开销是 O(树深)，会成为瓶颈吗？(实测一般不会，因为同 prefix 的请求会聚集)
3. vLLM 社区有人在做 RadixAttention 风格的改进吗？(搜 issue tracker)

⑤ FlashAttention (v1) · NeurIPS 2022 M4 算力

Dao et al. · "FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness"
arxiv.org/abs/2205.14135

三段摘要

• 问题：朴素 attention 把 N×N 的 attention matrix 实例化到 HBM，对长序列（N=4K-32K）HBM 流量爆炸，attention 变成 memory-bound。
• 方法：tile 划分 Q/K/V，在 SRAM 里增量计算 + online softmax 校正，N×N matrix 从不落 HBM。
• 结果：长序列 attention 提速 2-4×；HBM 流量从 O(N²) 降到 O(N·d / SRAM)。

关键图

• Fig 1：HBM 流量对比 —— 朴素 vs FlashAttention 的关键 trade-off。
• Fig 2：tile 划分示意。
• Alg 1：完整的 forward 伪代码 —— 这是面试的高频考点。
• Appendix A：online softmax 等价性证明 —— 不必背公式，但要知道"为什么可分块"。

看完读的代码

• Dao-AILab/flash-attention 的 csrc 是工业级 CUDA，先看 Triton 实现（如果有）
• vLLM 的 Triton attention kernel：vllm/v1/attention/ops/...

追问

1. FlashAttention 不省 FLOPs，省什么？
2. v1 → v2 主要改了什么？(work partitioning，把 head 维度的归约放到 outer loop)
3. v3 加了什么 Hopper 特性？(TMA + WGMMA + 异步)

⑥ H2O · NeurIPS 2023 M2/M3 之间 显存

Zhang et al. · "H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models"
arxiv.org/abs/2306.14048

三段摘要

• 问题：长 context（>32K）下 KV cache 撑爆显存，单序列就能吃掉一张卡。能不能丢一些 token 的 KV？
• 方法：观察 attention score 分布 —— 只有少数 "heavy hitter" token 被频繁关注。基于历史 attention score 选 top-k 保留，其他丢弃。
• 结果：KV cache 减少 5-10×，精度损失 <1% (BLEU/ROUGE)。

OS 对照

这其实是 working set theory + LRU 的现代版。OS 上 "working set" 指进程实际用到的页面集合；H2O 上 "heavy hitter" 指 attention 实际关注的 token。eviction 决策从"最少用"变成"最低 attention score"。

追问

1. vLLM 当前 evict 策略是 H2O 风格吗？(不是，vLLM 用整块 LRU。H2O 思想在 SnapKV、StreamingLLM 等论文里更接近)
2. "丢 KV"会损失什么？什么 workload 不能用？(需要长期记忆的任务，如代码、长文档 QA)

⑦ S-LoRA · MLSys 2024 M5+ 显存

Sheng et al. · "S-LoRA: Serving Thousands of Concurrent LoRA Adapters"
arxiv.org/abs/2311.03285

三段摘要

• 问题：LoRA 让每个用户都能有一个 fine-tune 的小补丁（<1% 参数）。但 1000 个用户 = 1000 个 adapter，怎么同时 serve？朴素切换 adapter 的开销巨大。
• 方法：unified memory pool 存所有 adapter；custom CUDA kernel 让一个 batch 内不同请求用不同 adapter；统计上多 adapter 可以共 batch。
• 结果：1000+ LoRA 同时 serve，throughput 比 PEFT 朴素 serving 高 30×。

OS 对照

多租户隔离 + 资源共享。OS 的 namespace / cgroup 让不同租户用同一份内核；S-LoRA 让不同 adapter 用同一份 base model。

看完读的代码

• vllm/lora/ — vLLM 的 LoRA 实现
• punica kernel — multi-LoRA 的 fused matmul kernel

02选读 3 篇 · 看兴趣选支

⑧ ZeRO · SC 2020 训练向 并行

Rajbhandari et al. · "ZeRO: Memory Optimizations Toward Training Trillion Parameter Models"
arxiv.org/abs/1910.02054

• 大模型训练的内存分片经典。把 optimizer state（最大头）、gradient、parameter 分别 shard 到多卡。
• OS 思维浓 —— 跟"虚拟内存 + RDMA 远程内存"是同一个抽象。
• 推理岗面试也可能问，知道 ZeRO-1/2/3 的差异即可（state / +gradient / +param 分级）。
• 看完读：DeepSpeed 仓库 README + 一篇 ZeRO-Infinity 综述。

⑨ Megatron-LM (TP/PP) · 系列论文 训练向 并行

• Tensor parallelism (TP)：把单个矩阵切片到多卡协同算（典型：把 W_qkv 沿 head 维度切 N 份）。
• Pipeline parallelism (PP)：把模型层切到多卡，流水执行 batch 的不同 micro-batch。
• vLLM 的多卡推理用 TP（PP 在推理里少见，主要训练）。看 vllm/distributed/。
• 追问：为什么 inference 主要用 TP？(PP 的 bubble 在小 batch 下太大；TP 通信量大但 inference 数据小)

⑩ torch.compile / Inductor · ASPLOS 2024 编译器向 算力

Ansel et al. · "PyTorch 2: Faster Machine Learning Through Dynamic Python Bytecode Transformation and Graph Compilation"
pytorch.org/assets/pytorch2-2.pdf

• 如果你想往编译器方向走，这是入口。Dynamo（前端 trace）+ Inductor（后端 codegen，生成 Triton）。
• vLLM 在某些路径已经用 torch.compile（model forward 部分）。看 vllm/compilation/。
• 当成 Month 7+ 的桥梁论文读，决定是不是要深入编译器线。

03第二圈 · 2023–2025 前沿（再读 5 篇）

上面 10 篇是地基。但 serving 这两年最热的几个方向，地基里只埋了伏笔没展开。 走完第一圈、能用 4 条轴给论文归类之后，再来读这 5 篇——你会发现它们每一篇都精确地站在前面某篇的"追问"上。这就是螺旋上升的第二圈。

⑪ Speculative Decoding · ICML 2023 M3/M4 算力

Leviathan et al. · "Fast Inference from Transformers via Speculative Decoding"（Google）· 同期 DeepMind 有等价的 "Accelerating LLM Decoding with Speculative Sampling"
arxiv.org/abs/2211.17192

三段摘要

• 问题：autoregressive decode 一次只出 1 个 token，每个 token 都要把整个模型的权重 + KV 从 HBM 过一遍。大模型 decode 是 memory-bound，算力闲着，纯粹被带宽卡住。
• 方法：用一个小 draft 模型便宜地猜 γ 个 token，再用大 target 模型一次 forward 并行验证这 γ 个。配合一个精心设计的接受/拒绝采样，保证输出分布跟"只用大模型"完全一致（无损）。猜对的连发，猜错的从分歧点重来。
• 结果：典型 2–3× 端到端加速，输出分布零偏差。后续 Medusa / EAGLE / draft-free 把"哪来的 draft"做得更省。

关键直觉

• 它不省 FLOPs，反而多算（draft + 部分被拒的 token 白算了）。它换的是：把"N 次 memory-bound 的小 forward"压成"少数几次能吃满算力的大 forward"。跟 FlashAttention 一样，都是拿闲置算力换带宽。
• 接受率 α 越高、draft 越便宜，越赚。下面这个小算盘把这层关系做成可调的：

看完读的代码

• vllm/v1/spec_decode/ — vLLM 的投机解码（ngram / EAGLE / Medusa 多种 proposer）
• 搜 num_speculative_tokens、rejection_sampler —— 接受/拒绝的核心逻辑
• 对照看：proposer 接口怎么插进 scheduler 的一个 step

追问

1. 为什么接受采样能保证"分布无损"？（提示：modified rejection sampling，对 draft 概率高估的部分按比例回退）
2. 什么 workload 下投机解码反而变慢？（α 低 + γ 大 + draft 不便宜——拉上面的算盘到 α=0.4、γ=8 试试）
3. EAGLE / Medusa 跟原始投机解码差在哪？（draft 不再是独立小模型，而是复用 target 的隐藏态做轻量预测头）

⑫ Prefill–Decode 分离 · OSDI 2024 等 M3 调度 并行

DistServe（Zhong et al., OSDI 2024）· Splitwise（ISCA 2024）· Mooncake（Moonshot/Kimi, FAST 2025）
DistServe arxiv.org/abs/2401.09670 · Mooncake arxiv.org/abs/2407.00079

三段摘要

• 问题：prefill 是 compute-bound（一口气算长 prompt），decode 是 memory-bound（一步一个 token）。两者塞进同一组 GPU、同一个 batch，互相拖累——Sarathi 的 chunked prefill 是在"混着跑"里调和，但天花板还在。而且 TTFT 和 ITL 想分别保 SLO，本质需求是冲突的。
• 方法：干脆把两阶段拆到不同的 GPU 池。prefill 池专心吃算力，decode 池专心保低延迟，各自独立扩缩容、独立选并行度。KV cache 通过高速互联（NVLink / RDMA）从 prefill 节点传给 decode 节点。Mooncake 更进一步：以 KV cache 为中心做全局缓存池 + 调度。
• 结果：在严格 TTFT/ITL 双 SLO 下，有效吞吐（goodput）显著优于合跑；大规模线上（Kimi）验证了 KV-centric 架构的可行性。

OS / 系统对照

这是把"一个进程干所有活"拆成专用流水线阶段 + 阶段间显式传递中间态——很像 OS 里把通用 CPU 路径拆成 DMA 引擎 / 专用协处理器，再用共享内存或总线传数据。瓶颈也随之从"计算"挪到"KV cache 怎么搬得快、放得下"。

看完读的代码 / 实战

• vLLM 的 disaggregated prefilling / kv_transfer 模块（搜 connector、KVConnector）
• 跑一个 1P1D（1 prefill + 1 decode）的最小 demo，量一下 KV 传输占了多少时间

追问

1. KV cache 跨节点传输的开销，什么时候会吃掉分离带来的收益？（短 prompt / 小模型时）
2. 分离架构下，PagedAttention 的 block 还需要吗？（需要——但现在还多了一层"跨节点的块迁移"）
3. 跟 Sarathi 的 chunked prefill 是替代还是互补？（互补：一个管"合跑时怎么调和"，一个管"该不该合跑"）

⑬ 量化：AWQ / SmoothQuant / FP8 / KV 量化 M2/M4 显存 算力

SmoothQuant（Xiao et al., ICML 2023）· AWQ（Lin et al., MLSys 2024 best paper）· KIVI（KV cache 量化, 2024）
AWQ arxiv.org/abs/2306.00978 · SmoothQuant arxiv.org/abs/2211.10438

三段摘要

• 问题：权重和 KV cache 用 fp16 太占显存 + 太占带宽。直接量到 int8/int4 会掉精度，难点在少数 outlier 通道幅值极大，一刀切量化会把它们毁掉。
• 方法：SmoothQuant 把激活的难度"搬"一部分到权重上（等价变换），让两边都好量化。AWQ 观察到不是所有权重一样重要——按激活幅值找出 ~1% 的 salient 通道，给它们留更高精度（per-channel scaling），其余 int4。KIVI 把这套思路用到 KV cache（key 按通道、value 按 token 量化）。
• 结果：W4A16（4-bit 权重）几乎无损 + 显存腰斩；KV 量化让长 context 容量翻几倍。FP8（Hopper/Blackwell 原生支持）则是另一条更"硬件友好"的路。

关键直觉

• 量化省两样东西，看场景：decode 是 memory-bound，W4 主要省的是「搬权重」的带宽（顺带省显存）→ 直接加速 decode；prefill compute-bound 时，得靠 FP8/INT8 的低精度 Tensor Core 才真省算力。
• 量化和 PagedAttention 是正交的：一个减每个 token 的字节数，一个管这些字节怎么排布。两者叠加。

看完读的代码

• vllm/model_executor/layers/quantization/ — awq / gptq / fp8 等后端
• 跑一次：同一个模型 fp16 vs AWQ-int4，量 throughput / 显存 / 输出质量三个数

追问

1. 为什么 KV cache 量化里 key 和 value 用不同的量化粒度？（提示：outlier 在 key 上沿通道分布）
2. W4A16 在 prefill（compute-bound）阶段还省时间吗？（不一定——反量化开销可能吃掉收益）
3. 量化和投机解码能叠加吗？draft 模型用量化是不是天作之合？

⑭ FlashAttention-2 / 3 M4 算力

Dao, "FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning"（2023）· Shah et al., "FlashAttention-3"（NeurIPS 2024，Hopper 专用）
FA2 arxiv.org/abs/2307.08691 · FA3 arxiv.org/abs/2407.08608

原页把 v2/v3 塞进了 FlashAttention 的"追问"，但它们其实是读懂现代 GPU 编程的钥匙，值得单列：

• v1 → v2：减少非 matmul 的浮点运算、把 work partition 换到沿 sequence 维度并行（更好喂满 SM）、warp 之间少同步。GPU 利用率从 v1 的 ~30% 提到 ~70%。这是"算法没变、把硬件喂饱"的典范。
• v2 → v3：吃满 Hopper 的新特性——TMA（异步搬数据）、WGMMA（warpgroup 级矩阵乘）、warp 专精 + 计算/搬运重叠流水，并用上 FP8。
• 读法：先把 v1 的 online softmax（上面那个交互）吃透，再看 v2 的伪代码 diff，最后 v3 当"Hopper 编程模型导读"读。

追问

1. v2 为什么把并行维度从 batch×head 扩到 sequence？（长序列、小 batch 时 SM 喂不满）
2. TMA 解决了 v2 的什么痛点？（搬数据和算 overlap 不起来，SM 等数据）

⑮ 看兴趣加餐 · 两条岔路 选读

• MoE serving（DeepSeek-V3 / Mixtral 工程）——稀疏激活把"显存装得下全部专家、但每 token 只算几个"变成新的调度+并行难题（expert parallelism、token routing 负载均衡）。vLLM 已支持，看 fused_moe kernel。
• 线性注意力 / SSM（Mamba, Mamba-2）——干脆绕开 KV cache 的 O(N) 增长，把状态压成固定大小。是"换掉 attention 本身"这条更激进的路，决定要不要深入再读。

04面试速测 · 主动回忆

页面里反复说"面试高频考点"。光看不算会——先在心里（或纸上）答完，再点开对答案。答不上来的，回对应论文重读。

05论文笔记模板

每篇读完，在 ~/infra/papers/ 建一个 .md 文件，固定 4 段：

# <论文名> · <会议> · <读完日期>

## 问题 (50 字)
现状是什么；现状不好在哪。最好一个具体数字（"X% 浪费" / "Y× 慢"）。

## 方法 (100 字)
核心 idea 一句话；最关键的 mechanism (机制) 一段。
画一张超简单的草图（手绘扫描或 ascii art）。

## 对账 (50 字)
跟 vLLM 哪行代码 / 哪个模块对得上？
找不到也写"对应模块是 X，但 vLLM 还没实现这个"。

## 我学到了 (100 字 可选)
反直觉点、巧妙工程、可以借用到 mini-vLLM 的地方。
对未来要不要深入这个方向的判断。

06跟踪谁的 Twitter / arXiv / blog

4.1 必关注的人 (vLLM/serving 圈)

• Woosuk Kwon · vLLM 第一作者，Twitter @woosuk_k
• Zhuohan Li · vLLM 创始人之一，Twitter @zhuohan123
• Tri Dao · FlashAttention v1/v2 作者，Twitter @tri_dao
• Lianmin Zheng · SGLang 作者，Twitter @lm_sys
• Hao Zhang (UCSD) · 推理优化系列论文，Twitter @haozhangml
• Amey Agrawal · Sarathi 作者

4.2 必关注的 blog

• blog.vllm.ai — 官方架构 + 性能文章
• lmsys.org/blog — Chatbot Arena / SGLang 团队
• horace.io (Horace He) — PyTorch / kernel 深度好文
• blog.eleuther.ai — 开源 LLM 训练实战
• Anyscale blog — 系统层 ML（continuous batching 原始博客就在这）

4.3 arXiv 关键分类

• cs.DC Distributed Computing — 分布式 serving / 训练
• cs.LG Machine Learning — 模型/算法
• cs.PF Performance — kernel / 优化
• cs.AR Architecture — 偶尔有 GPU 架构相关

用 arxiv.org/list/cs.DC/recent 每周扫一次标题。看到带 "LLM" / "serving" / "inference" / "KV" / "attention" / "speculative" / "disaggregat" / "quantization" / "MoE" 的，标个星，周末批量读。

07会议时间表

infra 论文集中在这几个会议，知道时间能预判什么时候关注什么：

读 paper 的实战：OSDI / SOSP / MLSys 出新 issue 时去翻 program，标几个跟你方向相关的，加进 papers/ todo。

08读论文的反原则

• ❌ 不要从第一作者最早的论文按时间读到最新。先读最有名的（被引最多 / SOTA 公认的）。
• ❌ 不要试图全篇看懂。一篇好 paper 你能用 5 句话讲清核心就过了。
• ❌ 不要光看 paper 不看代码。infra paper 的 design 和 code 经常对不上（paper 写得理想，code 长得现实）。
• ❌ 不要存 PDF 不写笔记。两周后你会忘 80%。写笔记是给未来的你看。
• ❌ 不要按 "AISys Fa2024" schedule 顺序读 24 篇。它是给学生 1 学期的，不是给你 6 个月的。