先记住一句话
先数 work、关键路径和搬运字节，再看硬件峰值；没有 workload、batch、shape 与 percentile 的“快了 3 倍”几乎没有意义。
1. Latency 与 throughput
| 指标 | 问题 | 常见单位 |
|---|---|---|
| Latency | 一个任务多久完成？ | μs/ms/s |
| Throughput | 单位时间完成多少任务？ | samples/s、tokens/s |
| Bandwidth | 单位时间搬多少数据？ | GB/s |
| Compute rate | 单位时间完成多少运算？ | FLOP/s、OP/s |
| Efficiency | 达到理论峰值的多少？ | % peak、J/token |
batching 常提高 throughput 却增加 queueing 和单请求 latency。在线服务看 p50/p95/p99 与 SLO，离线训练更关心 tokens/s 和 time-to-target-quality。
2. Work、span 与可用并行度
T₁ 是单处理器总 work，T∞ 是无限处理器下的关键路径（span），平均可用并行度约为：
parallelism = T₁ / T∞并行 reduction 的 work 仍是 O(N)，span 可从 O(N) 降到 O(log N)。GPU 只能加速有足够 independent work 的部分，data dependency 不会因线程多而消失。
3. Amdahl：固定问题的上限
speedup(N)=1 / [s+(1−s)/N]s 是无法并行的时间比例。即使 parallel part 无限快，speedup 也不超过 1/s。host preprocessing、Python、kernel launch、通信、串行 decoder loop 都可能成为新的 serial fraction。
4. Gustafson：资源变多也扩大问题
若随处理器数量增加 problem size，parallel work 增长而 serial part 近似不变，scaled speedup 可继续提高。这对应 weak scaling：每 GPU 保持固定 batch/domain size；strong scaling 则固定总 problem，GPU 越多，每卡工作越小，通信/launch 占比越大。
5. 理论峰值不是可达性能
GPU 标称 FLOPS 假设特定 dtype、指令、频率和足够大、对齐良好的矩阵；真实 kernel 还受 bandwidth、dependency、occupancy、instruction mix 与 shape 限制。吞吐上限常写成：
time ≥ max(FLOPs / peak_compute, bytes_moved / peak_bandwidth)这就是 Roofline 的起点，后面会细化 arithmetic intensity。
6. Little’s Law 与服务队列
in-flight requests ≈ arrival_rate × average_latency吞吐接近 capacity 时，queueing latency 会非线性上升。continuous batching 能填满 GPU，但 max batch/token budget 太激进会伤害 TTFT 与 tail latency。
7. Scaling efficiency
efficiency(N)=speedup(N)/N8 GPU 比 1 GPU 快 6.4 倍，parallel efficiency 是 80%。要同时报告 local/global batch、通信、gradient accumulation 与是否改变数值 recipe；否则“扩展效率”混入了 workload 改变。
8. 优化顺序
- 定义 end-to-end metric 与 correctness tolerance；
- 分解 wall time：CPU、copy、kernel、communication、queue；
- 找最大项与 critical path，不先猜；
- 建立理论/roofline 上限，判断可优化空间；
- 一次改一个变量并保留 baseline；
- 用真实 shapes/distribution 与 tail percentiles 复测。
9. 四个 scaling 手算
例 1：latency 与 throughput
单请求 latency=20 ms，串行服务最多 50 req/s；若 batch=8 仍耗 30 ms，batch throughput=8/0.03=266.7 req/s，但每个请求至少等待 30 ms 加排队。
例 2：Amdahl 上限
程序 10% 串行、90% 可无限加速，极限 speedup=1/0.1=10×。用 8 workers 时 1/(0.1+0.9/8)=4.71×。
例 3：Little’s Law
服务吞吐 λ=200 req/s、平均系统时间 W=50 ms，平均在途请求数 L=λW=200×0.05=10。Concurrency 远小于 10 就喂不满，远大于 10 只会增加排队。
例 4：strong-scaling efficiency
1 GPU 耗时 100 s，4 GPUs 耗时 30 s，speedup=3.33×，efficiency=3.33/4=83.3%。剩余损失来自 serial work、communication 和 imbalance。
GPU utilization 100% 只说明某段时间 GPU 忙，不说明在做有用计算、是否 memory stalled、是否选了低效 kernel，也不代表用户端 latency 达标。
自测
1. 1% serial fraction 的理论最大 speedup 是多少？
按 Amdahl 定律，即使并行部分无限快也最多约 100 倍。
2. strong scaling 为什么最终变差？
每个设备的 useful work 变小，而通信、同步、launch 和 serial overhead 不同比例缩小。
3. throughput 上升为什么 p99 可能恶化？
更大 batch/更高负载增加等待时间，capacity 附近 queueing 对尾延迟尤其敏感。
学习资料
NVIDIA CUDA Best Practices Guide从性能测量、并行化、bandwidth 与 memory access 建立优化方法；后续各篇用同一套量纲展开。