SemidirectX

附加讲 A3 · 课程项目指南：从想法到 MLSys 论文 · Course Project Guide

Advanced Topics in Machine Learning Systems (LLM Edition) · 附录 A3。个人学习讲义与配套实验，按主题整理并持续修订。

Systems

课程源码 ZIP ↓

个人整理的学习笔记，非官方讲义；课程来源与整理说明见课程介绍。配套示例未逐一运行验证。

本篇目录

对应 Maps to：原课第 15 周（12/3、12/5）是期末项目展示；Logistics 页给出了项目的要求和评分细则。原课课表里没有单独讲”怎样做项目”的一次课，本讲把这门课反复用到的方法论整理成一份指南。 依据说明：项目的要求（分组、一页开题、中期检查、8–10 分钟录播展示、最多 8 页的 MLSys 格式报告）、评分比例和展示的评分细则来自原课的 Logistics 页，只做转述。Logistics 页还链接了一份项目点子清单（Google 文档），它需要登录才能访问，我们没有用上；本讲和 03_scoping.py 里的点子是按本课各讲的主题自己整理的。论文写作和实验方法学的建议综合了本课各讲论文的写法和下面”延伸阅读”里的公开材料，不代表原课的官方要求。

bench.py 和三个脚本都是本讲义自己设计的：01 号脚本在本机上 ⏱ 实测”计时为什么会骗人”，02、03 号脚本复用前面各讲的模拟器。 配套代码 Code：code/appendixA3/（3 个脚本 + 一个小模块；需要 numpy 和 torch；每个都在 10 秒以内） 预计阅读时间：1.5 小时

0. 本讲导航 · How to read this lecture

0.1 学习目标

学完这一讲，你应该能够：

  1. 说出原课项目的四个交付物和评分方式，按要求写一页开题报告。
  2. 从”瓶颈 + 被忽视的工作负载 + 新硬件特性”三个方向找题目，并在动手之前用”光速上限”判断值不值得做。
  3. 写出一篇 MLSys 论文的骨架，回答评审最常问的问题。
  4. 设计一个可信的实验：预热、重复、交替测量、置信区间、全组合的消融、强基线、扫工作负载。
  5. 安排一个 8–10 分钟的展示。

0.2 本讲地图

§1  原课的项目要求
§2  怎样找题目：三个方向；动手前先算上限          ← 代码 03
§3  一页开题报告
§4  MLSys 论文的结构与评审常问的问题
§5  实验方法学                                    ← 代码 01、02
§6  展示
§7 小结  §8 常见误区  §9 练习  §10 延伸阅读  §11 结语

1. 原课的项目要求 · Requirements

成绩构成：课程项目 50%、论文评审 30%、课堂参与（展示、Piazza）20%。没有编程作业和考试。

项目：1–3 人一组，可以从老师给的点子清单里选，也可以做和自己研究相关的题目。四个阶段：

阶段占比要求（转述）
一页开题（10/10）5%题目和成员；引言（核心想法）；问题（要解决什么、清楚的定义）；现状（已有方法和局限、和你的关系、你能改进什么）；实施计划（怎样实现和评测、用什么框架、什么数据）
中期检查（11/7）不计分来答疑时间讨论，或者发一段简短的进展说明；目的是帮你解决问题、确保进度
录播展示（12/15）15%8–10 分钟；评分：引言和概述 4、问题 3、相关工作 3、方法 4、评测 4、时间控制 2（共 20 分）
最终报告（12/15）30%最多 8 页（不含参考文献），MLSys 格式；题目和成员、引言（动机和贡献）、问题、相关工作、概述（一张图讲清系统）、方法（自己做了什么、用了什么现成的，分清楚）、评测（硬件、数据、指标、超参数）、结论；连同代码一起提交

两点值得注意：

  • 报告的”方法”部分允许没有新方法，只要能给这个领域带来有意义的洞见（原课举的例子是”评测多种联邦学习算法、探究通信与计算的取舍”）。一个扎实的测量研究也是好项目。
  • “分清楚自己实现的和直接用的”是明确要求——评审最先问的也是这个。

论文评审（第 1 讲 §9 详细讲过）：每次课前交，三段：概括第一篇、概括第二篇、两篇之间的联系（比较、用一篇的想法解决另一篇的问题、或者结合两篇的新想法）；每段 0 / 1 / 2 分（缺失或照抄 0 分、没抓住要点 1 分、理解清楚 2 分），满分 6 分。不需要写长，抓住要点就行。

2. 怎样找题目 · Finding a topic

2.1 三个方向

这门课里几乎每一篇论文都可以归到下面三个方向之一（或者它们的组合）：

  1. 一个被量化清楚的瓶颈：先 profile，找出时间或显存花在哪里，再对准它。
    • FlashAttention：注意力的瓶颈是读写 N² 的中间矩阵；
    • vLLM：KV 缓存的显存浪费限制了批大小；
    • MegaBlocks：补齐浪费了计算和显存；
    • mega-kernel：小批量解码时内核启动的间隙。
  2. 一个被忽视的工作负载：主流系统为某种负载优化，新的负载打破了它的假设。
    • 长上下文（KV 缓存、序列并行）；
    • MoE（动态路由、all-to-all）；
    • RL 后训练（生成和训练交替、长尾，第 19 讲）；
    • 结构化的 LLM 程序（SGLang 的前缀共享）；
    • 推测解码的验证（批量下不再免费）。
  3. 一个新的硬件特性：新硬件让旧的取舍不再成立。
    • Hopper 的 TMA 和 warp 特化（FlashAttention-3）；
    • FP8 / FP4 Tensor Core；
    • 2:4 稀疏；
    • GH200 的 NVLink-C2C（附加讲 A1：重算还是卸载的答案变了）；
    • 更大的 NVLink 域。

这门课还有一条暗线（第 1 讲）：把专家的手工技巧变成”搜索空间 + 代价模型 + 正确性验证”——TASO、PET、Mirage、FlexFlow、Alpa、Ansor 都是这样。如果你在某个领域里看到大家都在手调同一类东西，那可能就是一个自动化的题目。

2.2 本课各讲可以延伸的点子（本讲义整理，不是原课的清单）

讲次一个可以试的点子
5、6、8给某种新的注意力变体（滑动窗口、MLA、稀疏注意力）写 Triton 内核，和 FlashAttention 比
7给 MoE 模型或推测解码的验证步骤做 mega-kernel
9、11把 Ansor / Mirage 式的搜索用到一个新的算子（例如分组 GEMM）
15在 Alpa 式的搜索空间里加入专家并行或激活卸载
16、17推测解码在大批量下的调度（什么时候关掉它）
18多 LoRA 服务时的显存管理和批处理
19RL 后训练里生成长尾的调度（按长度预测分批）
21专家放置和冗余专家的在线调整
A1“存 / 重算 / 卸载”三选一的规划器，按目标硬件建代价模型
A2量化方法在长上下文或推理密集的任务上的表现（不只看困惑度）

2.3 动手之前先算上限（代码 03）

一个点子值不值得做？先回答两个问题：

  1. 它对准的那部分占总时间（或显存）多少？
  2. 如果它做得完美，整体最多能好多少？一个现实的估计是多少？

用前面各讲的模型算了 6 个点子：

点子上限现实估计判断
解码 mega-kernel（Llama-1B，第 7 讲的模型）1.31×1.31×值得做
KV 缓存 4 比特（批 16、上下文 4096）3.05×2.02×值得做
更好的推测解码草稿（α 0.6 → 0.8）10.4×1.61×值得做
MoE 分组 GEMM（对比补齐的基线）3.00×2.90×值得做
专家并行的通信重叠（单节点）1.08×1.06×上限太低
激活卸载代替完全重计算（s = 8192）1.13×1.06×上限太低

几点教训：

  • 基线决定空间：MoE 分组 GEMM 对”按最忙的专家补齐”的基线有 2.9 倍的空间，但如果基线已经是分组 GEMM，只剩 1.03 倍——先查清楚最强的基线是什么。
  • 工作负载和硬件决定价值：KV 缓存量化在批 1、短上下文时几乎没用（1.05×），在大批量、长上下文时很有用；专家并行的通信重叠在单节点 NVLink 上没什么空间，跨节点时才重要（DeepSeek-V3 的 DualPipe）。
  • 上限模型也要和真实系统核对：mega-kernel 的模型上限是 1.31 倍，但 HazyResearch 的实测比 vLLM 快近 2.5 倍——真实的逐算子实现还有模型里没有的 CPU 调度开销。
  • 上限低不等于不能做：它可能省显存、省钱、让原来做不了的事变得可行（ZeRO-Offload 的卖点是”一块卡训 13B”），但要换成对应的指标去评测。

3. 一页开题报告 · The one-page proposal

按原课的四个部分写，每部分几句话。下面是一个示例（用 §2.3 的 MoE 点子，内容是虚构的计划，不是已有的结果）：

题目：用块稀疏内核做不丢 token、不补齐的 MoE 推理

引言：MoE 模型每个专家分到的 token 数不一样。主流的推理实现要么按容量丢 token，要么按最忙的专家补齐。我们想把 MegaBlocks 的块稀疏思路用到推理的预填充阶段，并在负载不均时也保持接近稠密矩阵乘法的效率。

问题：给定一批 token 的路由结果，怎样在一个内核里算完所有专家？目标是：不丢 token；执行的 FLOPs 接近有用的 FLOPs；在 2–64 个专家、Zipf 偏斜 0–1.5 的负载下，吞吐不低于 cuBLAS 批量矩阵乘法的 90%。

现状：

  • Tutel 的动态容量按最忙的专家补齐，负载不均时浪费 2–3 倍（我们的 roofline 估算）；
  • MegaBlocks 面向训练、块大小固定为 128，细粒度专家（每个专家只分到几十个 token）时补齐的比例很大；
  • vLLM / SGLang 里的分组 GEMM 实现不同、没有系统的比较。

我们的改进：按专家的 token 数自适应地选块大小，并把置换（前缀和）融合进内核。

实施计划：

  • 用 Triton 实现；在 H100 上用 Mixtral-8x7B 和一个 64 专家的细粒度配置评测；
  • 负载用真实路由轨迹（ShareGPT 提示词上采集）和合成的 Zipf 负载；
  • 基线：Tutel、MegaBlocks、vLLM 的 fused MoE 内核、逐专家循环；
  • 指标：每层延迟、端到端预填充吞吐、显存；
  • 消融：块大小自适应、置换融合各自的贡献。

第 4 周前完成内核的正确性测试，第 8 周前完成对比实验。

写开题时最容易犯的错：问题没有可检验的定义（“让 MoE 更快”）、现状只罗列论文不说局限、实施计划没有基线和指标。

4. MLSys 论文的结构与评审常问的问题 · Writing the paper

4.1 结构

这门课读过的论文大多是这个骨架：

  1. 引言：
    • 一段讲背景和动机（为什么重要）；
    • 一段讲已有方法为什么不行（最好有一个量化的观察，例如”补齐让 MoE 层的计算翻倍”）；
    • 一段讲你的核心想法；
    • 一个贡献列表（3–4 条，每条可检验）；
    • 一句话说结果（“端到端快 X 倍，在 Y 上”）。
  2. 背景 / 问题：读者需要的最少背景，加上问题的精确定义（输入、输出、目标、约束）。
  3. 概述：一张系统图，讲清楚组件和数据流，以及哪些是你做的。
  4. 方法 / 设计：每个设计决策说明”为什么”，最好对应一个瓶颈；有正确性保证的给出证明或验证方法（这门课很多论文的特点：TASO 的验证、SpecInfer 的无偏性）。
  5. 实现：用什么语言、库、多少行代码、哪些是现成的。
  6. 评测：
    • 设置（硬件、软件版本、模型、数据、基线及其配置）；
    • 端到端结果；
    • 微基准；
    • 消融；
    • 敏感性（扫工作负载和超参数）；
    • 开销（额外的显存、编译时间、调优时间）。
  7. 相关工作：按类别组织，每类说清楚”它解决什么、和我们的区别”。
  8. 结论：一段，包括局限和未来工作。

4.2 评审常问的问题（写完对照一遍）

  1. 问题重要吗？在真实的工作负载里，这个瓶颈占多大？
  2. 想法新吗？和最接近的工作差在哪里？
  3. 基线够强吗？用的是最新版本、推荐配置、同样的硬件和精度吗？
  4. 加速来自哪里？消融能不能把收益分解到每个设计上？
  5. 在哪些情况下不好用？（批大小、序列长度、模型大小、硬件）
  6. 正确性：结果和基线一样吗（数值误差多大）？质量（准确率、困惑度）有没有变？
  7. 开销：额外的显存、预处理、编译、调优要多久？摊销得开吗？
  8. 可复现吗？代码、数据、配置是否公开？

5. 实验方法学 · Experimental methodology（代码 01、02）

5.1 计时为什么会骗人（代码 01，⏱ 本机实测）

坑本机上看到的怎么办
计时器的分辨率time.time() 约 0.7 µs、perf_counter() 约 40 ns；对 100 个数求和（约 300 ns），time.time() 1000 次里约 680 次读到 0用 perf_counter()；短操作在循环里跑很多次（timeit）
第一次调用第一次写新分配的 256 MB 数组比第二次慢约 2.6 倍（缺页）先预热几次再计时
惰性求值m.T 只要约 100 ns（只创建视图），m.T.copy() 约 9 ms量”结果真的被用到”的那一步；GPU 上要同步
噪声和长尾512³ 矩阵乘法 200 次：中位数约 106 µs、平均约 114 µs、第 95 百分位约 155 µs、变异系数约 16%报告中位数（或最小值）和分布 / 置信区间，不要只报平均数
顺序效应A/A 测试（同一个函数量两次）重复 40 遍：顺序测量时 12%–60% 的区间”显著”，交替测量 0%–5%交替、随机化测量顺序
后端这台机器上 PyTorch 的矩阵乘法交给了 Accelerate，torch 的线程数对它几乎没影响；exp 用 12 线程快约 6 倍报告硬件、库、版本、线程数

GPU 上还有几个 CPU 上看不到的坑：

  • 内核是异步发射的，不调用 torch.cuda.synchronize()（或用 CUDA 事件计时）量到的只是”发射”的时间；
  • 第一次调用会加载内核、做 cuDNN / cuBLAS 的算法选择；
  • GPU 的频率随温度和功耗变化；
  • 多卡时还有通信的抖动。

一个 3% 的真实优势，在本机上要交替测量、重复几十到上百次才能看出来。改进只有几个百分点时，要么多跑很多次，要么换一个噪声更小的指标（数指令、数字节、用模拟器）——这门课的很多结论用”计数”和 roofline，就是这个原因。

5.2 端到端 vs 微基准（代码 02 演示 1–2）

Amdahl 定律：占总时间 f 的部分快了 s 倍，整体快 1 / ((1 − f) + f/s) 倍。只占 30% 的部分，即使快到无穷，整体也只快 1.43 倍。所以：

  • 同时报告微基准（这个内核快多少）和端到端（整个任务快多少），并说明被加速的部分占多大比例；
  • 扫工作负载：Llama-2-7B 在 H100 上解码时，批 1、上下文 512 时 KV 缓存只占 2%（KV 4 比特只快 1.01 倍，权重 4 比特快 2.38 倍）；批 32、上下文 8192 时 KV 占 91%（KV 4 比特 3.02 倍，权重 4 比特 1.07 倍）。只报告一个点的论文，结论可能完全取决于你选的那个点。

5.3 消融：做全组合（代码 02 演示 3）

第 16 讲的服务模拟器，OPT-13B、每秒 2 个请求，每个配置 5 个随机种子：

批处理KV 缓存吞吐（token/s，均值 ± 95% 区间）
静态按最大长度预留119 ± 2
静态分页153 ± 3
连续按最大长度预留245 ± 5
连续分页514 ± 49

分页 KV 在静态批处理下只带来 1.29 倍，在连续批处理下带来 2.10 倍——两个优化有交互：连续批处理想把批做大，正好被显存浪费卡住，分页把显存还给它。如果只报告”基线 → +A → +A+B”的累加表，交互效应会被错误地归到后加的那一项上。所以消融至少要做”逐个去掉”，能做全组合最好；每个配置多个种子，报告均值和区间。

5.4 基线（代码 02 演示 4）

同一个”新系统”（连续批处理 + 分页 KV）：

基线加速比
静态批处理 + 按最大长度预留（很弱）4.32×
连续批处理 + 按最大长度预留（Orca (Max)）2.10×
连续批处理 + 按 2 的幂预留（Orca (Pow2)）1.30×
事先知道长度（Orca (Oracle)，不现实的上限）1.08×

vLLM 论文和 Orca 的三个变体比，正是为了说明”不是因为基线太弱”。用基线作者推荐的配置、同样的硬件和精度；如果基线不支持某个场景，就说明并解释，而不是悄悄换一个更弱的。和一个”上限”（Oracle）比，可以告诉读者还剩多少空间。

5.5 一份检查清单

  • 硬件（GPU 型号、显存、互连）、软件（驱动、CUDA、框架、库的版本）、线程数都写了；
  • 每个数字都说明了重复次数和统计量（中位数 / 均值、区间）；
  • 预热了；GPU 上同步了；测量顺序交替或随机化了；
  • 基线用的是推荐配置，并说明了版本；
  • 同时有端到端和微基准；被加速的部分占比写清楚了；
  • 扫了工作负载（批大小、序列长度、模型大小）和硬件；
  • 消融能把收益分解到每个设计上；
  • 正确性 / 质量没有变（或者变了多少）；
  • 开销（显存、编译、调优时间）报告了；
  • 代码和配置可以复现。

6. 展示 · The presentation

8–10 分钟（不含问答），超时或太短都会扣”时间控制”的 2 分。按评分细则分配时间：

部分分值建议时长要讲什么
引言和概述41.5 分钟一句话的问题、一句话的想法、一个最重要的结果
问题31.5 分钟一个量化的观察（瓶颈有多大），问题的精确定义
相关工作31 分钟最接近的 2–3 个工作和它们的局限
方法42.5 分钟一张系统图 + 一两个关键的设计决策和”为什么”
评测42.5 分钟端到端一张图、消融一张图、一句话的局限

几条经验：

  • 每张图只讲一件事，标题就是结论（“分页 KV 让连续批处理的吞吐翻倍”，而不是”吞吐对比”）；
  • 先讲结论再讲细节；
  • 数字要有单位和基线；
  • 录播的好处是可以重录——用它把时间控制好。

7. 小结 · Summary

  1. 原课项目：1–3 人；一页开题 5%、录播展示 15%、8 页 MLSys 格式报告 30%；扎实的测量研究也可以是好项目；分清自己做的和用的。
  2. 找题目的三个方向：量化清楚的瓶颈、被忽视的工作负载、新的硬件特性；这门课的暗线是把手工技巧变成”搜索 + 代价模型 + 验证”。
  3. 动手之前先算上限：对准的部分占多少、完美时最多快多少、最强的基线是什么、在什么工作负载和硬件上。
  4. 论文：引言里有量化的观察和可检验的贡献；方法里每个设计都对应一个瓶颈；评测里有端到端、微基准、消融、敏感性、开销。
  5. 实验：perf_counter、预热、同步、多次重复、交替测量、报告中位数和区间；全组合的消融；强基线；扫工作负载。

8. 常见误区 · Common misconceptions

  1. “跑 3 次取平均就够了。” 在本机上，3 次重复的 bootstrap 区间本身就不可靠；一个 3% 的真实差别要几十到上百次交替测量才能看出来。
  2. “重复次数越多，结论越可靠。” 如果测量是顺序的，机器状态的漂移会被当成差别，次数越多、区间越窄，越容易”显著”地报出一个假的结论——A/A 测试里顺序测量的假阳性率达到 12%–60%。
  3. “内核快 10 倍，论文就能写快 10 倍。” 要按 Amdahl 换算成端到端的数字，并说明被加速的部分占比。
  4. “消融就是一项一项往上加。” 优化之间有交互（分页 KV 的收益取决于有没有连续批处理），累加表会把交互效应归错。
  5. “和最常见的开源实现比就行。” 要和最强的基线比，用推荐配置；和弱基线比得出的 4 倍，和强基线比可能只有 1.3 倍。
  6. “上限低的点子不值得做。” 它可能省显存、省钱、让原来做不了的事变得可行——但要换成对应的指标评测。
  7. “CPU 上的计时能代表 GPU。” 不同的瓶颈、不同的库（这台机器的矩阵乘法根本不走 PyTorch 自己的代码）；这门课的 GPU 结论一律来自模型，并且标明。

9. 练习 · Exercises（含参考答案）

练习 1（Amdahl）：一个推理系统里注意力占 40%、前馈层占 45%、其他 15%。你把注意力内核加速了 3 倍，端到端快多少？要让端到端快 1.5 倍，注意力要快多少倍？

答案：1 / (0.6 + 0.4/3) ≈ 1.36 倍。1.5 倍需要 0.6 + 0.4/s = 1/1.5 ≈ 0.667，即 0.4/s = 0.067，s = 6 倍。只加速注意力，端到端最多 1 / 0.6 ≈ 1.67 倍。

练习 2（上限）：你想优化某个模型的 LayerNorm，profile 显示它占 4% 的时间。完美时端到端最多快多少？这个点子在什么情况下仍然值得做？

答案：1 / 0.96 ≈ 1.04 倍。仍然值得做的情况：它是更大的融合工作的一部分（例如融合 LayerNorm 和后面的矩阵乘法、省掉一次读写），或者在某种工作负载下占比高得多（小 batch、窄模型），或者你的贡献是一种通用的技术而不是这一个算子。

练习 3（统计）：你测了基线 5 次：100、102、99、130、101 ms；新方法 5 次：96、97、95、96、98 ms。用平均数和中位数分别算加速比。哪个更可信？还缺什么？

答案：平均数：106.4 / 96.4 ≈ 1.10；中位数：101 / 96 ≈ 1.05。130 ms 那次是离群值（可能被打断），中位数更稳健。还缺：置信区间（5 次太少）、测量是否交替进行、预热了没有、硬件和版本。

练习 4（A/A）：为什么在发布”快 3%“之前要做 A/A 测试？如果 A/A 测试本身就显示”快 2%“，说明了什么？

答案：A/A 测试给出”什么都没变时测量能差多少”的基准。如果同一个函数也能”快 2%“，说明测量方法有系统偏差（顺序效应、预热不足、频率变化），3% 的结论不可信——要先修好测量（交替测量、更多重复、更稳定的环境）。

练习 5（消融设计）：你的系统有三个优化 A、B、C。全组合要跑多少个配置？如果每个配置要 3 个种子、每次 20 分钟，要多久？有没有更省的设计？

答案：2³ = 8 个配置，× 3 个种子 = 24 次，共 8 小时。更省的设计：“逐个去掉”——全开、去掉 A、去掉 B、去掉 C，再加全关，共 5 个配置（15 次，5 小时），能看出每个优化在其他都开时的贡献；怀疑两两有交互时再补那几个组合。

练习 6（基线）：你的推测解码系统在批 1 时比”不用推测解码”快 2.8 倍。评审说”和 Medusa、EAGLE 比呢？批 32 时呢？“你应该怎样补实验？

答案：加上 Medusa / EAGLE（用它们发布的草稿头和推荐配置）作为基线，报告相对它们的加速比；扫批大小（1、4、16、32、64），说明在哪个批大小之后推测解码不再划算（第 17 讲：批变大以后验证不再免费）；如果在大批量时会关掉推测，就说明这个策略并把它算进端到端。

练习 7（开题）：把”让 LLM 推理更快”改写成一个可检验的问题定义。

答案（一种写法）：“在 H100 上服务 Llama-3-8B、上下文 32K、批 16 的解码时，KV 缓存的读取占每步时间的 X%（我们测得）。我们要在 WikiText / LongBench 上的质量下降不超过 1% 的前提下，把每步的延迟降低 1.5 倍以上。“——有工作负载、有量化的瓶颈、有目标、有质量约束。

练习 8（读自己的结果）：你的新内核在微基准上比 cuBLAS 快 1.2 倍，但端到端只快 1.01 倍。列出三种可能的原因，以及各自怎样验证。

答案： (1) 这个算子占端到端的比例很小——用 profile 看占比，按 Amdahl 算期望值； (2) 微基准的形状（批大小、维度）和端到端里的不一样——用端到端里实际的形状重新做微基准； (3) 端到端里有别的瓶颈（CPU 调度、通信、内存分配、同步）或者你的内核和相邻的算子之间多了一次格式转换 / 拷贝——用 timeline（Nsight Systems）看内核之间的间隙。

10. 延伸阅读 · Further reading

  • S. Keshav, How to Read a Paper（CCR 2007）——第 1 讲的必读材料，三遍阅读法。
  • B. Lampson, Hints for Computer System Design（SOSP 1983）——系统设计的经验法则。
  • T. Hoefler, R. Belli, Scientific Benchmarking of Parallel Computing Systems（SC 2015）——并行系统基准测试的一组规则：怎样报告、怎样做统计。
  • T. Mytkowicz et al., Producing Wrong Data Without Doing Anything Obviously Wrong!（ASPLOS 2009）——看似无关的实验设置（环境变量的大小、链接顺序）会系统性地改变测量结果。
  • G. Heiser, Systems Benchmarking Crimes（网页）——系统论文里常见的评测错误清单。
  • MLSys 会议的投稿指南和往年最佳论文——格式和写法的参照。
  • 本仓库 第 1 讲（读论文的方法、三段式评审）。

11. 结语 · Closing

这份讲义跟着原课走完了 21 讲和 3 篇附加讲：

  • 从 GPU 的线程和内存（第 3–7 讲）；
  • 到编译器的搜索（第 8–11 讲）；
  • 到成百上千块卡的并行（第 12–15 讲）；
  • 再到 LLM 的服务、微调、后训练、MoE（第 16–21 讲）；
  • 最后是显存、压缩和做研究的方法（A1–A3）。

贯穿始终的是第 1 讲列出的四个习惯：

  1. 先算账再动手（roofline、α-β、16 字节 / 参数、Amdahl）；
  2. 找瓶颈（计算、访存、通信、调度、空泡）；
  3. 把手工优化变成自动搜索（搜索空间 + 代价模型 + 正确性验证）；
  4. 模型、系统、硬件协同设计。

带着这四个习惯去读下一篇 MLSys 论文、做下一个项目。

← 返回课程目录