压榨每一个 FLOP · roofline · 内存带宽 vs 算力 · profiling

0. 一个反直觉的故事:换更快的卡,decode 却没快

假设你在运营一个 LLM 服务,decode 阶段慢得让你肉疼,用户盯着字一个一个往外蹦。这时候有人给你出主意:换卡啊,新一代 GPU 的算力(每秒能做的浮点运算次数)翻了一倍多,生成肯定快。你咬咬牙换了,跑下来一测,decode 几乎没变快 —— 钱花了,字还是那个速度。问题出在哪?

答案是,你的 decode 从一开始就没在用算力。它绝大部分时间不是在算,而是在等数据从显存搬过来。一张卡的算力翻倍,对一个根本没把算力用满、而是卡在数据搬运上的任务来说,几乎没有意义。这就像你嫌厨房出菜慢,于是雇了个手速快一倍的厨师,可真正的瓶颈是食材从仓库运到灶台太慢 —— 厨师再快,也只能站在灶台前干等。这一章要给你的,正是那张能在换卡之前就告诉你「钱该不该花、花在哪」的图。

这背后是一切性能工程的母题:盲目优化,往往优化错地方。你以为慢是因为算得不够快,埋头去堆算力;真实的瓶颈却在另一条完全不同的线上。一个计算到底卡在哪,不是拍脑袋猜的,而是可以用一张图精确判断的,这张图叫 roofline。学会读它,你就有了 serving 性能工程里最基本的判断力:面对任何一个慢的 workload,先分清它是被算力卡住、还是被显存带宽卡住,再决定动手优化什么。这一节先把那个反直觉的事实摆在这,后面四节带你一步步推到这张图,并亲手用它把第四章那句 decode 是 memory-bound 从结论变成你能自己算出来的位置。

roofline 这套思维,是「盲目优化总优化错地方」这堵墙的产物 —— 每一代硬件都让一种资源变便宜、另一种变稀缺,roofline 是你在花钱、改代码之前,先看清对你这个 workload 而言到底哪种资源稀缺的尺子。

1. 加速器的执行模型:两种资源,两种速度

要理解一个计算为什么会卡,先得知道一张 GPU 跑一个计算时,到底在调用哪些资源。你不需要会写 CUDA,也不需要懂 kernel 怎么实现,只需要一个最小的执行模型,而这个模型只有两个角色。第一个角色是计算单元,它负责做浮点运算,能力用每秒多少次浮点运算来衡量,单位是 FLOP/s。第二个角色是显存(就是你在第四章反复见到的 HBM),它负责存放权重、KV cache、激活值;计算单元要算什么,数据都得先从这里搬过去,搬运的快慢用每秒多少字节来衡量,单位是 GB/s,这个量叫显存带宽。

任何一个计算,都必须同时用到这两个角色:先把要算的数据从显存搬进计算单元(花的是带宽),再做实际的运算(花的是算力)。关键来了,这两件事的速度天差地别。拿第四章一直用的那张 H100 来说,它的算力约是每秒 989 万亿次浮点运算(BF16 精度),而显存带宽约是每秒 3.35 万亿字节。把这两个数一除你会发现:计算单元每从显存读进一个字节,就有能力对它做将近 300 次浮点运算。换句话说,如果一个计算每读一个字节、配不上将近 300 次运算的活,它就一定喂不饱计算单元,昂贵的算力只能闲着,因为数据来不及送进来。

这就引出了那个决定一切的比值:一个计算每从显存读一个字节,平均要做多少次浮点运算。这个比值有个名字,叫算术强度(arithmetic intensity),单位是 FLOP/字节。它衡量的是一个计算划不划算:搬一次数据,能换回多少计算。算术强度高,说明数据搬一次能算很久,计算单元忙得过来,瓶颈在算力;算术强度低,说明数据刚搬来就算完了、计算单元立刻又要等下一批,瓶颈在带宽。一个 workload 到底卡在哪,本质上就由它的算术强度,和这张卡那个「每字节配多少算力」的临界值,谁高谁低来决定。下一节我们就把这两个量画到一张图上,让这个判断一目了然。

2. Roofline:一张图判断瓶颈在哪

现在把上一节的两个量画到一张图上,你就得到了性能工程里最有用的一张图 —— roofline(屋顶线)。它最早由 Williams、Waterman、Patterson 三人在 2009 年提出,本是用来分析多核处理器的,如今成了判断任何加速器 workload 瓶颈的通用工具。图的横轴是算术强度(每字节配多少 FLOP,从左到右递增),纵轴是这个 workload 实际能达到的速度(FLOP/s,越高越快)。整张图的精髓,是两条「屋顶」—— 你能达到的速度,被这两条线里更低的那条死死压住。

第一条是平的横顶,它就是这张卡的算力上限(峰值 FLOP/s)。再高的算术强度,你也不可能算得比卡的物理算力还快,所以这条横线是个绝对天花板。第二条是斜的屋顶,它代表显存带宽的限制:你能达到的速度,最多等于带宽乘以算术强度。算术强度越低,每搬一字节配的运算越少,这条斜线把你压得越狠。两条线一合,可达速度就是「峰值算力」和「带宽 × 算术强度」这两者里小的那个。这就是 roofline 模型唯一的公式。

两条屋顶相交的那个点,叫脊点(ridge point)。它的横坐标,正是上一节那个临界值:峰值算力除以带宽,也就是「要喂饱这张卡的计算单元,每字节至少得配多少 FLOP」。对那张 H100 来说,这个值约是 300 FLOP/字节。脊点把整张图劈成两半,而这一刀,就是第四章那个 memory-bound 与 compute-bound 区分的正式版本:一个 workload 的算术强度落在脊点左边(强度低),它就被压在斜屋顶下面、卡在带宽上,是 memory-bound;落在脊点右边(强度高),它就被压在平屋顶下面、卡在算力上,是 compute-bound。

有了这张图,第四章那两段脾气相反的计算,现在成了图上两个有坐标的点。prefill 一次并行处理成百上千个 token,每个从显存搬来的权重都被这一大批 token 反复使用,算术强度很高,稳稳落在脊点右边的平屋顶下,它是 compute-bound,这也是为什么第四章里它能把 H100 的算力吃到约 92%。decode 则相反,它的算术强度低得惊人(下一节算给你看),远远落在脊点左边的斜屋顶上,它是 memory-bound,这也是为什么第四章里它只能用上约 30% 的算力。同一张卡、同一个模型,两个阶段落在脊点两侧,要的资源、该优化的方向完全不同。

3. 为什么 decode 注定在屋顶左边:算给你看

上一节说 decode 的算术强度低得惊人,这一节就把它算出来,算完你会发现,decode 的位置不是偶然,而是被它的计算方式钉死在那的。回到 decode 的每一步:为了生成一个新 token,GPU 必须把整个模型的全部权重从显存搬进来过一遍。假设模型有 N 个参数,用 BF16 存、每个参数 2 字节,那么搬运量就是 2N 字节。而这一步真正做的计算呢?每个参数大约参与一次乘法、一次加法,也就是约 2N 次浮点运算。把两者一除,算术强度等于 2N 次运算除以 2N 字节,约等于 1 FLOP/字节。

请盯住这个结果:大约 1。它把参数量 N 完全约掉了 —— 不管模型是 80 亿参数还是 6710 亿参数,单条序列 decode 的算术强度都是大约 1 FLOP/字节。而上一节我们算过,那张 H100 的脊点在大约 300。也就是说,decode 落在脊点左边将近 300 倍的地方,深深陷在斜屋顶的最左端。这就是为什么开头那个换卡的故事注定失败:算力翻倍是把平屋顶抬高,可 decode 根本够不到平屋顶,它被压在斜屋顶上,真正决定它速度的是带宽这条斜线 —— 你该换的是显存带宽更高的卡,不是算力更猛的卡。

算个具体的数让这件事落地。还是那张 H100、那个第四章用过的 700 亿参数级模型:BF16 下权重约 140 GB,每生成一个 token,就得把这 140 GB 从显存里整个搬一遍。H100 的带宽是每秒 3.35 万亿字节,140 GB 搬完要约 42 毫秒。这意味着单条序列的生成速度有一个纯由带宽决定的硬上限:每秒约 24 个 token,而此时计算单元基本在打盹。你换一张算力翻倍、但带宽没怎么涨的卡,这 42 毫秒纹丝不动 —— 故事里那笔钱,就是这么白花的。

顺带说一句时间坐标。我们一直拿 H100 当例子,是为了跟第四章连贯,也因为它的规格公开得最全;但 H100 是 2022 年的 Hopper 架构,到 2026 年它已是两代前的卡。当下的旗舰是 Blackwell Ultra(B300,2026 年初出货:288 GB 显存、带宽约每秒 8 万亿字节,并原生支持 FP4 这种 4 比特精度),再往后 Rubin 一代正在铺开。原理一个字没变,变的只是两个屋顶都更高、数字更大。而「把权重的精度降下来、让它更小、从而抬高算术强度」这条思路,恰恰是下一章 Ch9 的题目,这里先埋着。

那批处理呢?第四章末尾留过一个伏笔:多塞几个请求拼成一批,能不能把 decode 喂忙?现在你能用 roofline 精确回答了。拼批的好处是,权重只需要从显存搬一次,却能给批里的好几个序列共用:如果一批有 B 个序列,那么搬一次权重(2N 字节)就做了 2N×B 次运算,算术强度涨到了大约 B。也就是说,批越大,decode 在图上就沿着斜屋顶往右爬,朝脊点靠近。这正是第五章连续批处理拼命要把批攒大的原因。

但这里有个第四章已经点过、现在能讲透的天花板:能被批摊薄的,只有权重那部分搬运;每个序列自己的 KV cache 是它独有的,必须为它单独从显存读一遍,不会因为同批还有别人就省掉。所以当批变大、上下文变长,真正主宰每一步耗时的,渐渐从搬权重变成了搬各自的 KV cache,而这部分的算术强度并不随批升高。结果就是,拼批能把 decode 往右推一段,却推不到脊点,它撞上 KV cache 这堵墙、停在了脊点左边。2025 年一项研究(论文题就叫 Mind the Memory Gap)和 DeepMind 的推理分析都给出同一个结论:上下文超过约两千 token 之后,KV cache 的搬运就在各种批大小下主导了每步耗时。所以诚实的结论是 —— 大批量能缓解 decode 的算力浪费,但 decode 在规模上依然是 memory-bound。这不是工程没做到位,而是这门计算的本质。

4. MFU:理论与实际的差距,就是性能工程的活

现在你会判断一个 workload 卡在哪了,下一个问题是:它离卡的极限还有多远?也就是,这张昂贵的卡,你到底用上了几成?度量这件事的头号指标,叫 MFU(model FLOPs utilization,模型浮点运算利用率)。它的定义很直白:你实际达到的那个「模型必需的」运算速度,除以这张卡的峰值算力。比方说卡的峰值是每秒 989 万亿次,而你实测每秒只做了 450 万亿次模型该做的运算,那 MFU 就是约 46%。

这里有个干净的换算,你以后到处会用到:一个有 N 个参数的模型,推理时每生成一个 token 大约需要 2N 次浮点运算(就是上一节那个一乘一加),训练时因为多了反向传播,大约是 6N(前向 2N 加反向 4N)。有了这个,你拿「每秒生成多少 token,乘以每 token 的运算量」就能算出实际运算速度,再除以峰值,就得到 MFU。这个指标的妙处在于,它只数模型定义本身要求的运算,不数任何重复计算或实现取巧,所以它是跨系统、跨硬件可比的:一个团队报的 MFU,另一个团队能直接拿来比。

那现实里 MFU 能到多少?这是这一节最该建立的直觉:它远没有你想的那么高。当年那篇提出 MFU 的 PaLM 论文(2022),在六千多块 TPU 上训练,MFU 是 46.2% —— 注意,这是一个被当成标杆、写进论文里炫耀的好成绩。前沿大模型训练的 MFU,普遍就落在三成到五成多这个区间;能稳定做到一半以上,团队就很自豪了。就连 DeepSeek-V3 这种工程做到极致的训练,论文报的 FP8 MFU 也只在两成上下(换算到 BF16 口径约四成)。从这个数到 100% 之间那一大段差距去哪了?去了机器之间通信的等待、流水线的气泡、显存带宽的停顿、kernel 没榨干的边角。性能工程师每天在做的事,本质上就一件:缩小实际与理论屋顶之间的这道差距。

这正是前沿实验室招人时反复在说的话。OpenAI 的推理团队把目标直白地写成「榨干每一个 FLOP、每一 GB 显存」;Anthropic 的 Inference System Dynamics 团队干脆把整份工作框定为「量化实际集群性能与理论 roofline 的差距,并定位根因」,招聘要求里明确点名 profiling 和 roofline 分析(这些岗位描述收录在本路书的 research 笔记里)。换句话说,roofline 不是教科书概念,它就是这些岗位每天用的语言。还有一个配套指标值得记住:decode 这种 memory-bound 阶段,用 MFU 去量天生就低(算力本来就没打算用满),所以这时候更该看的是 MBU(model bandwidth utilization,带宽利用率),也就是你把带宽那条斜屋顶用上了几成。看哪个屋顶,就用哪个利用率。这又回到了 roofline 那张图。

5. 怎么找到瓶颈:不猜,先 profile

到这你已经有了判断瓶颈的模型,但还差最后、也最关键的一步:真实系统里,你怎么知道时间到底花在哪了?答案只有两个字,别猜。性能工程第一条铁律是,不要凭直觉去优化你没测量过的东西 —— 人的直觉在性能问题上错得离谱是常态。你以为慢在模型计算,一测发现是调度开销(第四章那个 Anthropic 追了约 350 毫秒、最后定位到 server 调度的案例,就是活生生的例子)。测量这件事有个专门的动作,叫 profiling(性能剖析):把一次真实运行录下来,看每个操作花了多少时间、搬了多少数据,然后把它放到 roofline 上读出它卡在哪条屋顶,再决定动手优化什么,改完再测一遍。这是一个测量、定位、优化、复测的闭环。

工具上你不必从零造。最常用的入门工具是 PyTorch Profiler,它能录下每个操作在 CPU 和 GPU 上的耗时,导出成一个 trace 文件,你用浏览器里的 Perfetto 或者 chrome://tracing 打开,就能看到一条时间线,哪个操作占了多长一目了然。要更深,有 NVIDIA 的 Nsight Systems 看整体时间线(计算和通信有没有重叠)、Nsight Compute 钻进单个 kernel。后者甚至内置了一张 roofline 图,直接把每个 kernel 标在屋顶下面,你刚学的这套判断,专业工具早做成了按钮。vLLM 这类推理引擎也内置了 profiling 钩子,设一个环境变量(VLLM_TORCH_PROFILER_DIR)就开始录。

profiling 不只是个人调试的手艺,它已经是前沿团队对外公开的一等资产。一个绝好的例子是 DeepSeek 在 2025 年开源周里放出的 profile-data 仓库:他们把 V3/R1 真实跑出来的 profiling trace 直接公开了,里面有三份,分别对应训练、prefill、decode 三种负载(配置都标得清清楚楚,比如 decode 那份用的是 128 路专家并行、每卡 128 个请求)。你用 chrome://tracing 打开,就能看到一个前沿 MoE 模型在真实部署里,计算和通信是怎么逐毫秒重叠的 —— 这种第一手的真实 trace,是过去外人根本看不到的东西。能读懂这样一份 trace、自己也能给系统插上探针把瓶颈测出来,正是 serving 性能工程从会搭到会调的分水岭。

综合 · 你现在有了一把判断性能的尺子

回头看这一章给了你什么。你先从一个反直觉的故事出发 —— 换更快的卡,decode 却没快,因为它从没在用算力。然后你建立了加速器最小的执行模型:计算单元和显存,两种资源、两种速度,谁跟不上谁就是瓶颈;它们的比值,就是算术强度。接着你把这一切画成了 roofline:平的算力顶、斜的带宽顶、中间的脊点,一个 workload 落在脊点哪一侧,就决定了它是 compute-bound 还是 memory-bound。你亲手算出 decode 的算术强度约等于 1、远在脊点左边将近 300 倍 —— 第四章那句 decode 是 memory-bound,至此不再是要背的结论,而是你能推出来的位置。你还看清了拼批为什么能把它往右推、又为什么被 KV cache 这堵墙挡在脊点之前。最后你拿到了度量与定位的工具:用 MFU 和 MBU 量你离屋顶还有多远,用 profiling 闭环把真正的瓶颈测出来,而不是猜。

这一整套合起来,就是一把判断性能的尺子。它最值钱的地方,和第四章那张解剖图是一个道理 —— 它让优化变得有的放矢。当你面对一个慢的系统,你不再凭感觉堆硬件,而是先问几句:这个 workload 落在脊点哪一边?该追的是算力还是带宽?该看 MFU 还是 MBU?瓶颈在计算、在通信、还是在调度?答得出这几个问题,你就从一个会搭系统的人,变成了一个会调系统的人。

学完这一章,你已经能把任何 LLM workload 放到 roofline 上判断瓶颈、能估算单卡 decode 的带宽上限、能解释为什么前沿团队把性能工程框定成缩小与理论屋顶的差距、也知道该用哪些工具去 profile 一个真实系统。这就是你该合上书、准备走进下一章的地方。下一章我们顺着这把尺子往下走:既然 decode 卡在带宽、权重越小搬得越快,那把数字的精度降下来、用更少的比特存权重,会发生什么?这就是 FP8、FP4 与量化的世界,也是抬高那两个屋顶最直接的一根杠杆。

本章关键术语

本章引入的 canonical 术语,点进术语表看更完整的解释:

• roofline 屋顶线模型 一张判断计算瓶颈的图:横轴算术强度、纵轴可达速度,平屋顶是算力上限、斜屋顶是带宽上限,可达速度取两者小的那个。两顶相交处是脊点,左侧 memory-bound、右侧 compute-bound
• 算术强度 arithmetic intensity 一个计算每从显存读一个字节,平均做多少次浮点运算(FLOP/字节)。它和这张卡的脊点临界值谁高谁低,决定 workload 卡在算力还是带宽;decode 约等于 1,prefill 高得多
• MFU 模型浮点运算利用率 model FLOPs utilization:实测的「模型必需」运算速度除以硬件峰值算力。只数模型定义要求的运算,所以跨系统可比;前沿训练普遍三到五成,PaLM 标杆 46.2%。memory-bound 的 decode 该改看 MBU(带宽利用率)
• profiling 性能剖析 把一次真实运行录下来、看时间和数据流向哪,而不是凭直觉猜瓶颈。工具如 PyTorch Profiler、Nsight Systems/Compute、Perfetto;DeepSeek 的 profile-data 是公开的真实 trace 范例
• 承自第四章:memory-bound / compute-bound —— roofline 把这条区分线正式画了出来

参考文献

Mode A · 引用出处(正文 inline,集中列在此)

• Roofline: An Insightful Visual Performance Model for Multicore Architectures(Williams, Waterman, Patterson · CACM 2009)· roofline 模型原始论文:可达性能 = min(峰值算力, 带宽 × 算术强度),脊点 = 峰值算力 / 带宽
• Making Deep Learning Go Brrrr From First Principles(Horace He, PyTorch)· 把性能分成 compute-bound / memory-bandwidth-bound / overhead-bound 三种 regime 的第一性讲解 + 工厂类比;本章执行模型的思路来源
• PaLM: Scaling Language Modeling with Pathways(Chowdhery et al., 2022 · 附录 B)· MFU 的正式定义出处;6144 块 TPU v4 上 46.2% MFU 这个标杆数字
• Mind the Memory Gap(2025)· 实证:拼批能抬高 matmul 的算术强度,但注意力/KV cache 读取不被摊薄,大批量 decode 依然 memory-bound
• How To Scale Your Model · 推理篇(DeepMind)· 上下文超过约 2048 token 后 KV cache 加载在各种批大小下主导每步耗时的分析
• deepseek-ai/profile-data(DeepSeek, 2025 开源周)· V3/R1 真实 training/prefill/decode 三份 profiling trace(用 PyTorch Profiler 录、chrome://tracing 打开)
• OpenAI · Inference (Scaling) JD「utilize every FLOP and every GB of GPU RAM」、监控 MFU(收录于 research/system-design/job-postings/openai.md)
• Anthropic · Inference System Dynamics JD「量化实际集群性能与理论 roofline 的差距并定位根因」、要求 profiling + roofline 分析(收录于 research/system-design/job-postings/anthropic.md)
• NVIDIA H100 数据手册 + Inside NVIDIA Blackwell Ultra(NVIDIA)· 本章算账用的 H100 规格(BF16 ~989 TFLOP/s · HBM3 ~3.35 TB/s)+ 2026 当下旗舰 B300(288 GB · ~8 TB/s · 原生 FP4)

深 dive 资源(可选 · 想往下走再看)

• NVIDIA Nsight Compute · Roofline 分析(NVIDIA)· 专业工具里内置的 roofline 图:把每个 kernel 标到屋顶下面,正是本章这套判断的工程化按钮
• LLM Inference Performance Guide(Baseten)· 把 prefill/decode 的算术强度、带宽上限、batch 影响一步步算给你看的工程向长文

说明:本章没有 Mode B 视频站 —— roofline 与性能工程这类硬核系统主题,目前缺少合格的、人讲解的系统化教学长视频;原始论文、Horace He 的第一性博文与厂商 profiling 文档在上方按需列出,由 Mode A 原创讲解扛主线。

下一章

下一章 Ch9 顺着这把尺子往下走,进到精度的世界。你这一章想通了 decode 卡在带宽、权重越小搬得越快,那一个最直接的念头就是:把存权重的数字精度降下来,从 16 比特降到 8 比特、甚至 4 比特(就是这一章一直提到的 FP8、FP4),不就一举两得,既省显存、又因为搬的字节少了而抬高算术强度吗?Ch9 就讲这件事的系统视角:为什么降精度是 serving 吞吐最直接的杠杆、它怎么同时抬高 roofline 的两个屋顶,以及一个关键的工程纪律 —— 降了精度不是完事,你得把数值正确性当成一门学科来管,否则省下来的吞吐会以模型质量悄悄退化的形式还回去。