题目重点：Nvidia DevTech 电面提到 Amdahl 定律；本文从公式假设、数值例子、CPU/GPU 传输与 profiling 解释何时并行化收益有限。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练例采用固定总工作量、原始运行时间归一化为 1、可并行部分比例 p、用 N 个等效处理单元且忽略额外并行开销，才得到经典加速比公式。
- CPU→GPU 数据传输、kernel launch、同步和负载不均衡在真实系统里另计；不能把公式算出的速度当作实际测量值。
- 面经只写概念题，没有给 p 或 N；下文 p=0.8、N=8 为教学例子。
解题路线
- 把时间拆为串行部分 1−p 与理想可并行部分 p。N 个处理单元下理想新时间为 (1−p)+p/N，所以加速比 S(N)=1/((1−p)+p/N)。当 N 趋于无穷时，上限为 1/(1−p)。
- 先用 profiler 从完整请求端到端量出各阶段耗时，再界定能被本次改动加速的比例。训练和推理常有数据加载、Host↔Device 传输、调度、kernel 计算与同步；只优化 matmul kernel，收益受其他阶段限制。
- 把真实额外开销记为 h(N)：新时间是 (1−p)+p/N+h(N)，h 可能随 N 上升。若 GPU 利用率低，可能优先改 batch、数据流水线或传输，而不是增加 GPU 数。
- 比较强扩展与弱扩展：Amdahl 固定问题规模讲强扩展；若增加设备同时增大工作量，吞吐可能提升，但不能用同一个加速上限直接解释。
手动走一遍
训练例 p=0.8、N=8，理想新时间为 0.2+0.8/8=0.3，速度为原来的 1/0.3≈3.33 倍；即使 N 无限大也最多 5 倍。若再有 0.05 的传输和同步开销，新时间 0.35，实际估计变成约 2.86 倍。应继续 profile 这 0.2 串行部分和新增开销。
规模与取舍
公式计算本身 O(1)。工程优化的规模取决于被 profile 的请求数、设备数和负载分布；对于固定工作量的理想模型，增加 N 的边际收益递减。端到端吞吐与 p95 延迟可能响应不同，不能用一个平均加速比代表两者。
易错点与追问
容易失分的边界
- 把 GPU kernel 内的可并行比例当作整条训练/推理流水线的 p，忽略数据准备和同步。
- 把无限核上限 1/(1−p) 说成真实集群能达到的值，忽略 h(N) 与通信瓶颈。
- 用增加工作量后的吞吐提升证明固定任务延迟满足 Amdahl 的强扩展预测。
- 只比较 kernel 时间，未复测端到端延迟、显存与成本。
继续深挖
- 若 CUDA kernel 已提速 4 倍但请求只快 10%，用局部耗时占比反推瓶颈，而不是继续优化同一个 kernel。
- 若多 GPU 通信占比升高，量测 all-reduce、PCIe/NVLink 与计算重叠，再比较数据并行和模型并行。
- 若推理峰值并发增加，分别追踪每请求延迟与总体吞吐，并在真实 batch 分布下重新估计。
