如何定位大模型推理中的显存、算力与内存带宽瓶颈？

面试时怎么答

推理瓶颈必须把 Prefill 和 Decode 分开，因为前者常偏算力，后者常偏内存带宽。用 Trace 拆排队、Host、Kernel、通信，再借 Roofline 判断算力或带宽上限；GPU 利用率只是表象。追问时再讨论增大 Batch、量化或压缩 KV 会把瓶颈移到哪里。

可以这样答：

定位推理瓶颈不能只看 GPU 利用率，要把 Prefill 和 Decode 分开，并判断是算力、内存带宽、显存容量还是调度受限。用 Trace 拆出排队、Host 到 Device、Kernel 和通信时间，用 Roofline 看算术强度离硬件上限多远。还要权衡增大 Batch 能提高吞吐，却会拉高 TTFT；压缩 KV 能省带宽，但转换可能抵消收益。排查时要用真实长度与并发压测，报告 TTFT、TPOT、Goodput、HBM 带宽利用率和显存碎片率。

核心回答

先把问题拆成端到端、Prefill、Decode 和非 GPU 阶段，再用真实请求的 Trace 与 GPU profiler 找证据。显存容量瓶颈表现为 OOM、KV Cache 无法继续分配或 Batch 被迫很小；算力瓶颈是算术强度较高的 kernel 接近可用计算吞吐；内存带宽瓶颈则是计算单元未满、但 HBM 流量接近平台能力。Roofline 模型用“算术强度 = 运算量 / 数据搬运量”帮助判断 kernel 更受计算还是带宽限制。

一般而言，长输入和较大 Batch 的 Prefill 更可能形成高效大矩阵计算，低 Batch 的逐 token Decode 更容易反复读取权重而受带宽影响；这是诊断起点，不是对所有模型、硬件和并发都成立的定律。

展开说明

排查顺序可以是：

排除外围：分别测分词、网络、排队、调度、检索与 GPU 时间，避免把 CPU 或队列问题误判为模型慢。
分阶段度量：用 TTFT 观察排队与 Prefill，用 TPOT 观察 Decode；按输入长度、输出长度和并发切片。
核对显存账：权重、KV Cache、临时工作区、CUDA Graph 和通信 buffer 分开统计，观察碎片与峰值而非只看平均。
分析 kernel：查看 Tensor Core 使用、occupancy、访存吞吐、kernel launch 空洞、算子回退和 CPU-GPU 同步。
多 GPU 通信：把 All-Reduce/All-to-All 时间与计算重叠情况单列；互联或拓扑可能成为第四类瓶颈。

GPU 利用率是聚合信号，不能单独区分有效计算、忙等和低效 kernel。

工程实践

用固定模型版本和生成参数建立长度×并发矩阵，先做低开销线上指标，再对代表性窗口采集 profiler，避免全量分析扰动生产。针对证据选择优化：容量不足可量化权重或 KV、减少并发上下文；带宽受限可用低位宽、算子融合或提高有效 Batch；计算受限应检查 Tensor Core dtype、kernel、融合、模型规模和并行度；通信受限则调整并行度与拓扑。推测解码更适合作为低并发、带宽受限 Decode 的候选；高 Batch 已经计算受限时，draft 与验证开销可能降低吞吐。每次只改一类变量并复测质量和 SLO。

常见追问

为什么 GPU 利用率高不一定代表推理效率高？ 利用率只表示一段时间内有 Kernel 在运行，不代表计算单元或带宽接近峰值，也可能被低效小 Kernel 和同步填满。
Prefill 与 Decode 的瓶颈为什么常常不同？ Prefill 对长 Prompt 做大矩阵运算，算术强度高；Decode 每步矩阵较小且反复读取权重与 KV，通常更偏带宽受限。
怎样从 Roofline 图判断应优化计算还是数据搬运？ 工作点落在斜线段说明带宽受限，应减少搬运或提高复用；接近平顶段说明算力受限，应优化算子与计算效率。

一句话复习

先分阶段测量，再用显存账、Roofline 和 kernel/通信 Trace 把“慢”定位为可验证的具体瓶颈。

参考资料

面试题来源：AI Engineering Interview Questions 的 LLM 推理 Profiling 题
技术依据：Roofline 原论文（作者机构存档）、NVIDIA Nsight Compute Profiling Guide、FlashAttention 的 IO 分析