企业官网建设流程全解析

1. 面试官问"这卡能跑多大模型"时，他到底在问什么

如果你面过AI Agent、大模型推理或者训练相关的岗位，大概率被问过这么一类问题："给你一张卡，你怎么判断它能跑多大的模型？""为什么有些模型明明参数量不大，跑起来却特别慢？""显存带宽和算力，哪个更卡脖子？"

很多人第一反应是去背参数表：多少TFLOPS、多少GB显存、带宽多少TB/s。但面试官真正想听的，不是你把规格书复述一遍，而是你能不能把算力峰值、显存带宽、算术强度这三件事串起来，用一个统一的框架去解释"瓶颈到底在哪"。这个框架就是Roofline模型。

我面过也带过人，发现一个规律：能把Roofline讲清楚的人，往往对推理优化、算子融合、量化、批处理这些工程手段的理解是成体系的；而只会背参数的人，一追问"那为什么这个算子跑不满算力"就卡壳了。所以这篇我打算用一个"工厂"的类比，把这三个概念和Roofline模型彻底讲透，顺便把面试里常见的追问链路也梳理一遍。不管你是准备面试，还是单纯想搞懂自己手里的卡为什么"跑不满"，这套逻辑都用得上。

先说结论性的直觉：算力峰值决定工厂的理论产能上限，显存带宽决定原料进出的速度，而算术强度决定你这个活儿到底是"缺工人"还是"缺物流"。Roofline模型就是把这三者画在一张图上，让你一眼看出当前负载卡在哪一侧。下面我们一层层拆。

2. 把GPU想象成一家工厂：算力、带宽、算术强度的物理直觉

2.1 算力峰值：工厂里所有工人每秒能拧多少颗螺丝

算力峰值，通常用FLOPS（每秒浮点运算次数）衡量，比如一张卡标称几十TFLOPS。你可以把它理解成：工厂里有几万个工人（计算核心），每个工人每秒能完成固定次数的操作（拧螺丝、焊接）。所有工人满负荷运转时，每秒能完成的总操作数，就是算力峰值。

这里有个面试常考的坑：标称的算力峰值往往是特定精度下的理论值。比如FP16的峰值可能是FP32的两倍甚至更多，因为很多架构里FP16可以用Tensor Core加速，而FP32走的是普通CUDA核心。所以当面试官问"这卡算力多少"，你得先反问一句"你说的是哪种精度"。这个反问本身就是加分项，说明你知道算力不是一个单一数字。

另外，理论峰值和实际能跑到的算力之间，通常有个折扣。就像工厂标称产能是理想状态下所有机器不停机、原料永远充足、没有换线损耗才能达到的。实际生产中总有各种损耗，能跑到峰值的六七成就算不错了。这个折扣从哪来，后面讲Roofline时会解释清楚。

2.2 显存带宽：原料仓库到流水线的传送带速度

显存带宽，单位是GB/s或TB/s，指的是数据从显存搬到计算核心的速度。用工厂类比，就是原料仓库（显存）到流水线（计算核心）之间那条传送带的运力。

这个类比的关键在于：工人再快，如果传送带送原料的速度跟不上，工人也只能干等着。这就是所谓的"内存墙"（Memory Wall）问题。过去几十年算力的增长速度远远快于显存带宽的增长速度，导致很多计算任务其实不是被算力卡住，而是被带宽卡住。

举个具体的量级感受一下：一张主流推理卡，算力可能是几百TFLOPS，带宽可能是几TB/s。看起来带宽数字也很大，但你要注意单位——算力是"每秒多少次运算"，带宽是"每秒多少字节"。一次运算往往需要读取多个字节的数据，所以这两个数字不能直接比大小，得换算到同一个维度上才能比较。这个换算，就是算术强度要干的事。

2.3 算术强度：每搬一公斤原料，能干多少活

算术强度（Arithmetic Intensity）的定义是：每读取一字节数据，能完成多少次浮点运算，单位是FLOPs/Byte。用工厂类比，就是"每搬进来一公斤原料，工人能干出多少活"。

这个指标是理解Roofline的核心。它把"算力"和"带宽"这两个不同维度的东西，通过"数据搬运量"这个桥梁联系了起来。一个算子的算术强度高，意味着它读一次数据能干很多活，那它就更可能受限于算力；算术强度低，意味着它读一次数据只干一点点活，那它就更可能受限于带宽。

我举个具体例子帮你建立手感。矩阵乘法（GEMM）是典型的高算术强度操作：两个N×N矩阵相乘，计算量是O(N³)，而需要读取的数据量是O(N²)。N越大，每读一个数据能做的运算就越多，算术强度随N线性增长。所以大矩阵乘法通常能跑满算力，是"计算密集"的。

反过来，像逐元素操作（element-wise），比如给一个张量每个元素加1，读一个数、写一个数、做一次加法，算术强度极低，基本就是1 FLOP/Byte级别。这种操作几乎必然受限于带宽，是"访存密集"的。面试里如果问"为什么ReLU、LayerNorm这些算子优化空间有限"，答案就在这里——它们天生算术强度低，你优化计算没用，瓶颈在搬数据。

3. Roofline模型：一张图看懂你的任务卡在哪一侧

3.1 屋顶线的两条边：斜线和水平线分别代表什么

Roofline模型的图，横轴是算术强度（对数坐标），纵轴是实际能达到的性能（FLOPS，也是对数坐标）。图上有两条线组成一个"屋顶"：

• 斜线部分：性能 = 算术强度 × 带宽。这条线代表带宽受限区。在这个区域，你的性能上限由带宽决定，算术强度越高，能达到的性能越高。
• 水平线部分：性能 = 算力峰值。这条线代表算力受限区。在这个区域，性能上限就是算力峰值，再高的算术强度也没用，因为工人已经满负荷了。

两条线的交点，对应的算术强度叫做拐点算术强度（Ridge Point）。它的物理意义是：刚好能让算力和带宽都不浪费的那个算术强度。低于它，带宽是瓶颈；高于它，算力是瓶颈。

用工厂的话说：拐点就是"传送带送原料的速度，刚好够所有工人满负荷干活"的那个平衡点。原料送得比这慢，工人就闲着（带宽受限）；送得比这快，工人也干不完，原料堆着（算力受限）。

3.2 拐点怎么算：一个能直接背下来的公式

拐点算术强度的计算公式非常简洁：

拐点算术强度 = 算力峰值 ÷ 显存带宽

注意单位要统一。算力峰值用FLOPs/s，带宽用Byte/s，除出来的单位就是FLOPs/Byte。

我拿一组常见的量级数字演示一下（具体数值我用近似值，重点是方法）。假设某卡FP16算力约300 TFLOPS，带宽约2 TB/s：

• 算力峰值 = 300 × 10¹² FLOPs/s
• 带宽 = 2 × 10¹² Byte/s
• 拐点 = 300 / 2 = 150 FLOPs/Byte

这意味着：算术强度低于150 FLOPs/Byte的算子，受限于带宽；高于150的，受限于算力。这个数字很有用，你可以拿它去对照各种典型算子的算术强度，立刻判断出瓶颈在哪。

面试里如果面试官给你一组参数让你现场算拐点，记住这个公式就够了。但更重要的是，你要能接着说出"所以对于这张卡，哪些算子会卡在带宽上，该怎么优化"。

3.3 为什么实际性能总在屋顶线下方：那些"损耗"从哪来

理论屋顶线是上限，实际跑出来的点总在它下方。面试官很爱追问这个"差距从哪来"。主要有几个来源：

第一，访存效率不是100%。传送带运原料，不可能每次都满载，可能有空载、有绕路。对应到硬件上，就是缓存命中率、内存访问模式（是否连续、是否对齐）的问题。访问不连续的数据，实际有效带宽会大打折扣。

第二，计算单元利用率不是100%。工人之间要协调、要等指令、要处理依赖关系，不可能所有人每一刻都在干活。对应到硬件上，就是指令发射、流水线停顿、warp调度等问题。

第三，算子之间的边界开销。一个模型由很多算子组成，算子之间要启动、要同步、要读写中间结果。这些开销不产生有效计算，但消耗时间和带宽。

第四，精度和累加的影响。低精度计算虽然峰值高，但累加、转换都有额外开销。

理解了这些损耗来源，你就能理解为什么"算子融合"是推理优化的核心手段之一——它减少的正是第三类开销，把多个低算术强度的小算子合并成一个，减少中间结果的读写。

4. 拿几个真实算子套一遍：谁卡带宽，谁卡算力

光讲理论容易飘，我们拿几个大模型里最常见的算子，实际套一遍Roofline，看看结论是否符合直觉。

4.1 大矩阵乘法：为什么它是"算力友好型"选手

前面说过，N×N矩阵乘法的算术强度随N线性增长。当N足够大（比如几千），算术强度轻松超过拐点，进入算力受限区。这就是为什么GEMM是各家芯片厂商重点优化的对象，也是为什么大模型里矩阵乘法部分通常能跑得比较满。

但这里有个面试常考的细节：批处理（batch size）会显著影响矩阵乘法的算术强度。推理时如果batch很小，矩阵乘法的某个维度被压得很扁，算术强度会骤降，从算力受限掉到带宽受限区。这就解释了为什么小batch推理效率低、吞吐上不去——不是算力不够，是每个样本摊到的数据搬运成本太高。增大batch能把算术强度拉回来，这也是continuous batching这类技术存在的根本原因。

4.2 LayerNorm和Softmax：天生的"带宽困难户"

LayerNorm、Softmax、ReLU、Dropout这些算子，算术强度都极低。以LayerNorm为例，它要对每个样本的隐藏维度做归一化，需要读取整个向量、算均值方差、再写回。计算量很小，但读写的数据量和向量本身一样大，算术强度基本在个位数FLOPs/Byte。

对照拐点150，这些算子妥妥地在带宽受限区，而且离拐点很远。这意味着你优化它们的计算逻辑几乎没用，唯一的出路是减少数据搬运。具体手段包括：算子融合（把LayerNorm和相邻的矩阵乘法或激活函数合并，避免中间结果落显存）、原地操作（in-place，省掉一次写回）、以及量化（减少每个数据占的字节数，直接提升有效带宽）。

我面试时喜欢问"为什么LayerNorm很难优化"，能答出"算术强度低、带宽受限、优化方向是融合而非计算"的人，基本就过关了。

4.3 Attention：一个随序列长度"变脸"的典型

Attention是个特别有意思的算子，因为它的算术强度会随序列长度变化，属于"变脸型"选手。

标准Attention的计算涉及QK^T、Softmax、再乘V。当序列长度较短时，中间那个注意力矩阵不大，整体算术强度偏低，偏带宽受限。当序列长度很长时，注意力矩阵变成O(N²)规模，计算量上去了，但读写量也上去了，情况变得复杂。

这正是FlashAttention这类技术要解决的问题：它通过分块计算、避免把完整的注意力矩阵写回显存，大幅减少了数据搬运，把Attention从带宽受限往算力受限方向推。面试里如果聊到长上下文优化，从Roofline角度切入解释FlashAttention为什么有效，会比单纯说"它减少了显存访问"更有说服力。

4.4 一张对照表：常见算子的瓶颈归属

我把上面几个算子整理成一张表，方便你面试前快速回忆：

这张表的核心价值是：看到任何算子，先估它的算术强度，再对照拐点，就能判断瓶颈。这是面试里最实用的思维工具。

5. 面试追问链路：从Roofline能延伸出哪些高频问题

Roofline本身是个框架，面试官往往会顺着它往下追问。我把常见的追问链路和应答思路整理一下，这部分是真正的"面试干货"。

5.1 "怎么判断一个模型是算力受限还是带宽受限"

标准答法分三步：第一步，估算模型的总计算量（FLOPs）和总数据搬运量（Bytes）；第二步，两者相除得到整体算术强度；第三步，和这张卡的拐点算术强度比较。

但更聪明的答法是补充一句："整体算术强度会掩盖局部差异，实际模型里不同层瓶颈不同，要分层看。"这句话能体现你不是死记公式，而是理解模型的异构性。比如Transformer里，FFN部分偏算力受限，LayerNorm和残差连接偏带宽受限，整体性能是这些层叠加的结果。

5.2 "显存带宽不够，有哪些优化手段"

这个问题几乎是必问的。按有效性排序，我一般这么答：

• 算子融合：把多个带宽受限的小算子合并，减少中间结果的读写次数。这是收益最大、最通用的手段。
• 量化：把FP16降到INT8甚至INT4，每个数据占的字节数减少，等效带宽直接翻倍甚至更多。但要注意量化带来的精度损失和反量化开销。
• 原地操作：能原地更新的就不新分配内存，省掉一次写回。
• 改善访存模式：让内存访问连续、对齐，提升有效带宽利用率。
• 增大batch：把算术强度拉高，让算子从带宽受限区往算力受限区移动。

答的时候最好能说清楚每个手段"为什么有效"，比如量化为什么等效于提升带宽——因为带宽是按字节算的，每个数据字节数少了，同样带宽每秒能搬的数据个数就多了。

5.3 "算力峰值那么高，为什么实际跑不到"

这个问题的答案就是前面讲的"损耗来源"。我一般会分两个层面答：

硬件层面：计算单元利用率受指令调度、流水线停顿、依赖关系影响，不可能100%。访存效率受缓存命中率、访问模式影响，有效带宽低于标称带宽。

软件层面：算子边界开销、框架调度开销、kernel启动开销、精度转换开销，都会吃掉一部分性能。

然后补一句关键的："所以优化不是去追那个理论峰值，而是先找到当前瓶颈在哪一侧，把瓶颈那一侧改善，性能自然提升。"这句话体现了Roofline思维的精髓——优化要对着瓶颈做，而不是盲目堆算力。

5.4 "给你一个具体场景，你怎么做容量规划"

这类问题通常给一个模型规模和一个硬件规格，让你判断能不能跑、能跑多大batch。思路是：

先算模型权重占多少显存（参数量 × 每参数字节数），再算激活值、KV Cache占多少，加起来看是否超过显存容量。然后从带宽角度估算推理速度上限（总数据搬运量 ÷ 带宽），从算力角度估算计算时间上限（总计算量 ÷ 算力），取较大者作为理论延迟下限。

这里有个经验：大模型推理往往是带宽受限的，因为自回归生成时每生成一个token都要把整个模型权重读一遍，算术强度很低。这就是为什么推理优化里量化、KV Cache优化这么重要——它们直接减少数据搬运量。

6. 我在实际工作和面试中踩过的几个认知坑

讲完框架，分享几个我自己踩过或者见别人踩过的坑，这些是文档里不会写的。

6.1 别把标称算力当成"能用的算力"

刚入行时我特别迷信规格书上的算力数字，觉得数字大就是好。后来做实际推理才发现，标称算力是在最理想精度、最理想数据布局下测出来的，实际业务里根本达不到。判断一张卡适不适合某个任务，要看的是"这个任务的算术强度落在Roofline的哪个位置"，而不是单纯比算力大小。一张算力稍低但带宽更高的卡，跑带宽受限的推理任务可能反而更快。

6.2 优化前先定位瓶颈，别上来就改代码

我见过太多人一遇到性能问题就开始调各种参数、换各种库，折腾半天没效果。正确的做法是先做profiling，看当前算子的算术强度落在Roofline哪一侧，确认瓶颈是算力还是带宽，再针对性优化。对着非瓶颈做优化，投入产出比极低。这个习惯我从做第一个推理优化项目时就养成了，受益至今。

6.3 面试时"算一遍"比"背结论"更有说服力

面试官给你参数让你分析时，别急着下结论。当着面试官的面把拐点算出来，把算子的算术强度估出来，再对照着说瓶颈在哪、怎么优化。这个过程本身就展示了你的思维方式。哪怕数字估得不够准，只要逻辑对，面试官也会认可。我面人的时候，最看重的就是这个"能现场推演"的能力。

6.4 记住几个数量级，比记住精确数字更有用

你不需要记住每张卡的确切参数，但要对数量级有感觉：主流推理卡算力在百TFLOPS量级，带宽在TB/s量级，拐点算术强度在百FLOPs/Byte量级。有了这些数量级，你就能快速判断一个算子是偏算力还是偏带宽。面试时如果记不清精确值，说"大概在百这个量级"也比瞎编一个精确数字强。

7. 把这套框架变成你自己的直觉

Roofline模型最大的价值，不是让你会画那张图，而是给你一个判断性能瓶颈的思维习惯。遇到任何性能问题，先问三个问题：这个任务的计算量多大？数据搬运量多大？两者相除的算术强度，和硬件的拐点比，落在哪一侧？

这三个问题问下来，瓶颈基本就定位了，优化方向也就清楚了。算力受限就去提升计算效率，带宽受限就去减少数据搬运。听起来简单，但真正养成这个习惯需要刻意练习。

我的建议是，找几个你熟悉的算子，自己动手估一遍它们的算术强度，对照你手上硬件的拐点，看看结论是否符合你的实际观察。估上十来个算子，这套直觉就建立起来了。到那时候，面试官再问"这卡能跑多大模型""为什么这个算子慢"，你脑子里会自动浮现出那张Roofline图，答案自然就出来了。

这套东西说到底就一句话：算力是工人的手速，带宽是传送带的运力，算术强度决定了你的活儿到底卡在哪一头。把这句话刻进脑子里，比背一百个参数都管用。