本文是AI Infra 面试题系列的 Level 1，覆盖 Q01-Q12。重点是GPU 瓶颈、显存、Roofline、拓扑、collective、精度与 benchmark。
2. Level 1：GPU 与性能基础
Q01. 一个 GPU workload 为什么可能算力利用率很低？
高分回答要点
- 先区分 SM active、Tensor Core 利用率和端到端 GPU utilization；
nvidia-smi的 busy 百分比不等于有效 FLOPs。 - 可能受 HBM/显存带宽、L2/共享内存、PCIe/NVLink、kernel launch、CPU dispatch、同步、依赖链、低 occupancy 或小矩阵限制。
- 用 roofline 的 arithmetic intensity 判断理论上偏 compute-bound 还是 bandwidth-bound，再用 profiler 验证，而不是只看一个 utilization 数字。
- 对小 batch decode，矩阵形状小、逐 token 串行和权重反复读取通常比峰值 FLOPs 更关键；大 batch prefill 更容易把 GEMM 做大。
追问：V100 的 Tensor Core 可用，为什么某个 FP16 模型仍可能跑不到 Tensor Core 峰值？应检查 dtype、矩阵维度、kernel 选择、对齐、融合和实际 Tensor Core 指令计数。
实验锚点：本项目中 TP 把单卡矩阵切小后吞吐下降，是“峰值算力相加不等于有效算力相加”的直接例子。
Q02. 如何估算一个模型训练时的显存？
高分回答要点
- 分开计算参数、梯度、optimizer state、master weight、activation、通信 bucket、临时 workspace 和 allocator 碎片。
- 对 AdamW，不应死记“每参数 16 bytes”；应按实现逐项算。例如 FP16 参数 2B、FP16 梯度 2B、FP32 master weight 4B、两个 FP32 moment 8B，合计常见为 16B/参数，但梯度 dtype、master weight 和 fused optimizer 会改变结果。
- activation 与 microbatch、sequence length、hidden size、layer 数和保存策略相关；attention 中某些中间量随序列平方增长，FlashAttention 会改变保存与 IO 方式。
- FSDP/ZeRO 只能分片特定状态；AllGather 临时参数、prefetch、未被 wrap 的模块和通信 buffer 决定峰值，不是简单除以 world size。
追问：为什么 FULL_SHARD 实测峰值不是 DDP 的八分之一？
实验锚点：约 368M 参数模型中，DDP 约 6.49 GiB，SHARD_GRAD_OP 约 1.55 GiB，FULL_SHARD 约 1.06 GiB；这个结果适合用组件法反推，而不是套比例。
Q03. 什么是 roofline model？它如何指导优化？
高分回答要点
- 横轴是 arithmetic intensity，即 FLOPs/搬运字节；纵轴是达到的 FLOP/s。上界为
min(peak_compute, bandwidth * intensity)。 - 位于斜线附近说明受带宽限制，优先减少 HBM 流量、融合 kernel、提高数据复用；位于水平屋顶附近才值得优化指令吞吐、Tensor Core 和并行度。
- roofline 是上界模型，不包含 launch latency、依赖、通信和调度，因此小 kernel 或分布式 workload 还需时间线分析。
- 必须说明字节统计在哪一级存储：HBM roofline、L2 roofline 和 shared-memory roofline结论可能不同。
追问：为什么 FlashAttention 不改变 attention 数学结果，却能显著加速？核心是 tiling 和 online softmax 减少 HBM 中间张量读写，而不是减少所有计算。
Q04. 如何读一张 8 GPU 拓扑图？
高分回答要点
- 识别 GPU 到 PCIe switch、CPU socket/NUMA、NIC 的路径，区分 PIX、PXB、PHB、SYS，以及是否存在 NVLink/NVSwitch。
SYS往往经过 CPU 互连，时延更高、共享链路更多；但实际 collective 性能还取决于 NCCL 拓扑建图、消息尺寸和并发流量。- 进程绑核、内存 NUMA 位置、NIC affinity 会改变 host staging、控制面和跨机路径。
- placement 应把高频通信组映射到快链路，例如同一 TP group 尽量局部，DP 可以承受更慢但带宽稳定的跨节点链路。
实验锚点：本机 512 MiB AllReduce 中 PIX 约 11.74 GB/s，PHB 约 7.07 GB/s，SYS 约 6.93 GB/s，是拓扑影响而非 GPU 型号差异。
Q05. AllReduce、ReduceScatter、AllGather、All-to-All 和 Send/Recv 分别做什么？
高分回答要点
- AllReduce：每个 rank 获得所有输入按操作归约后的完整结果，典型用于 DDP 梯度。
- ReduceScatter：先归约再把结果分片到各 rank；AllGather：把各 rank 分片拼成完整 tensor。两者组合可实现 AllReduce，也对应 FSDP 梯度分片和参数聚合。
- All-to-All：每个 rank 向每个 rank 发送不同分片，典型用于 MoE token dispatch/combine，流量和热点对负载不均衡敏感。
- Send/Recv 是点对点通信，pipeline stage activation/gradient 传递常用它。
- 要进一步说明 tensor shape、group 大小、每 rank 输入/输出布局和是否原地，避免只背名字。
追问：为什么不能用“项目里测了 AllReduce”代表掌握所有通信？不同 primitive 的消息模式、并发连接数和慢链路敏感性不同。
Q06. Ring AllReduce 的通信量和时间模型是什么？
高分回答要点
- 对
N个 rank、每 rank tensor 大小S，ring 通常有N-1步 ReduceScatter 和N-1步 AllGather；每步传S/N。 - 每 rank 总发送/接收量约
2(N-1)S/N。简化时间模型为2(N-1)alpha + 2(N-1)S/(N beta)，其中alpha是每步延迟，beta是有效链路带宽。 - 大消息时 bandwidth 项主导；小消息时 2(N-1) 次启动/同步使 latency 主导，tree 往往更有优势。
- 实际 NCCL 会按拓扑使用多 channel、协议和混合算法，不能把单环模型当完整实现。
追问：为什么 8 卡 ring 的性能可能由最慢路径或共享上行链路限制，而不是两卡最快带宽？
Q07. algbw 和 busbw 有什么区别？
高分回答要点
algbw通常是逻辑 payload 大小除以操作时间，便于从应用视角比较。busbw按 collective 算法实际搬运量做归一化，便于比较底层互连利用。Ring AllReduce 常用修正系数2(N-1)/N；AllGather/ReduceScatter 常用(N-1)/N。- 两个值都不是任意一条物理链路的精确瞬时速率；多 channel、双向流量和拓扑共享会使解释更复杂。
- 面试中必须确认工具定义和单位，不能把 GB/s、GiB/s、单向和双向带宽混用。
实验锚点：报告同时保留 nccl-tests 原始输出和归一化表，可以现场解释为什么比较拓扑时优先保持消息大小、rank 数和指标定义一致。
Q08. rank、local rank、world size 和 process group 是什么？
高分回答要点
- global rank 唯一标识整个 job 的进程；local rank 标识节点内设备位置；world size 是默认 group 的进程数。
- process group 定义 collective 的参与者与顺序。同一进程可属于 DP、TP、PP、CP、EP 等多个正交 group。
- group 构造错误会导致 silent wrong result 或 hang；所有 rank 必须以一致顺序进入匹配 collective。
CUDA_VISIBLE_DEVICES后的 local rank 是逻辑设备序号，不一定等于物理 PCI bus id，做拓扑放置时要显式核对。
追问：给定 TP=4, PP=2, DP=8，总 world size 是多少？如何为一个 rank 推导其三个坐标？
Q09. FP16、BF16、TF32 和 FP32 在训练中如何选择？
高分回答要点
- FP16 exponent 范围小，通常需要 loss scaling；BF16 与 FP32 exponent 范围相同，训练更稳但尾数更短；TF32 是 NVIDIA 对 FP32 matmul 的加速路径，不是通用存储 dtype。
- 参数存储、计算、梯度归约、optimizer state 可以使用不同 dtype。所谓“FP16 训练”必须拆解具体路径。
- V100 支持 FP16 Tensor Core，但不原生支持 BF16 Tensor Core；这会直接影响可复现配置和最新框架兼容性。
- 通信压缩能减少字节，但可能引入 cast、精度损失或额外 kernel，必须把算法公平性和性能收益分开报告。
实验锚点：FSDP 对比中 FP16 通信提高吞吐，但它不是与 FP32 通信完全相同的数值配置；报告明确把它作为独立变量。
Q10. 怎样设计一个可信的 GPU benchmark？
高分回答要点
- 固定软件版本、GPU 时钟/功耗策略、模型配置、精度、seed、输入分布、并行配置和环境变量。
- 区分冷启动、warmup 和 steady state；异步 CUDA 必须正确同步，服务 benchmark 还要排除模型加载与客户端瓶颈。
- 至少报告中位数和尾部/离散程度，保留原始样本；吞吐测试要验证输出正确，不能只求快。
- 一次只改变一个主变量，同时记录可能的混杂项，如 compile、cache、通信 dtype、batch token 数和 OOM 回退。
- 写明观测事实、机制推断和未验证假设；通过脚本、原始日志、解析器和 artifact 校验保证可复现。
追问：为什么单次最高值不可信？为什么服务端“发送完成”不等于客户端“请求成功”？
Q11. 训练性能应该报告哪些指标？
高分回答要点
- 核心是 global tokens/s 或 samples/s、step time 分布、每 GPU 吞吐、扩展效率、峰值/保留显存、MFU/HFU。
- 分解 data loading、forward、backward、optimizer、collective、checkpoint 时间，并看计算通信 overlap。
- 稳定性指标包括 loss、梯度 norm、overflow/skip step、straggler、hang、重试和有效训练 token。
- MFU 分母必须说明硬件峰值和精度，分子 FLOPs 模型必须说明是否计入 attention、embedding、recompute 和稀疏专家。
- 对长任务还要报告 uptime、故障间隔、恢复时间和 checkpoint 开销；短 microbenchmark 不能代表这些指标。
Q12. 推理服务应该报告哪些指标？
高分回答要点
- 区分 TTFT、TPOT/ITL、端到端 latency、output tokens/s、request throughput、并发和队列等待。
- 报告 p50/p90/p95/p99，而不是只有平均值；按输入/输出长度分桶，否则 workload mix 会掩盖结果。
- 把原始吞吐与 SLO goodput 分开：只有满足所有目标的请求才计入 goodput。
- 记录 KV cache 使用率/命中率、preemption、batch token、prefix reuse、GPU/CPU 利用率和错误率。
- 明确 open-loop arrival rate、closed-loop concurrency 或 trace replay；三者回答的问题不同。
实验锚点：本项目在 25 QPS 时 completed throughput 仍约 16.46 req/s，但满足 TTFT/TPOT SLO 的 goodput 只有约 0.40 req/s，说明“服务器很忙”不等于“服务可用”。