Interview: 一个7B模型FP16推理的理论吞吐量瓶颈在哪？是计算还是内存带宽？
题目解析
这道题需要用Roofline模型分析LLM推理的性能瓶颈。关键是区分prefill阶段和decode阶段的不同特性。7B模型FP16约14GB参数，需要分析在不同硬件上的算术强度(arithmetic intensity)来判断瓶颈。
解答思路
以A100 80GB为例：算力312 TFLOPS FP16，内存带宽2TB/s。Decode阶段：batch_size=1时，每生成一个token需要读取全部14GB参数，但每个参数只做一次乘加运算，算术强度=2 FLOPS/2 Bytes=1，远低于A100的ops:byte比=156，因此是严重的内存带宽瓶颈。理论decode速度=2TB/s÷14GB≈143 tokens/s。Prefill阶段：输入为n个token，每个参数被n个token共享，算术强度=2n/2=n，当n>156时变为计算瓶颈。因此prefill在长输入时是计算受限，decode几乎总是带宽受限。
关键要点
- 增大batch size可以提升decode阶段的算术强度，使其从带宽受限转向计算受限
- 临界batch size ≈ 算力/带宽 ÷ (2×参数量/2) ≈ 156对于A100
- 实际推理还受KV Cache显存限制，不能无限增大batch size
- 量化(如INT4)同时降低内存读取量和提高有效带宽利用，对decode阶段加速显著
加分回答
可以扩展讨论不同硬件的特性：H100的HBM3带宽3.35TB/s但算力989 TFLOPS，ops:byte比更高(295)，意味着需要更大的batch size才能计算受限。还可以分析MoE模型的情况——虽然总参数多但每个token只激活部分参数，实际带宽需求取决于活跃参数量。
常见踩坑
- 只分析计算量不考虑内存带宽，得出”GPU算力足够”的错误结论
- 混淆理论峰值和实际可达性能（通常只能达到峰值的60-80%）
- 忽略KV Cache的读取也占用内存带宽，尤其在长序列时不可忽视