torch.cuda.event比time.time()更准，因其直接捕获gpu kernel启停时刻，避免cpu-gpu异步导致的±10ms误差，精度达±0.02ms；需配对record、同步、预热并确保同stream。
torch.cuda.Event 为什么比 time.time() 更准
GPU 运算和 CPU 是异步的，time.time() 测的是 CPU 发出指令和返回的时间，中间 GPU 可能还没开始跑、或还在后台计算。用 torch.cuda.Event 能真正捕获 GPU 上 kernel 启动和结束的时刻，尤其对小模型或单次前向这种毫秒级任务，误差可从 ±10ms 压到 ±0.02ms。
实操建议：
- 必须配对使用
record()：一个startEvent 和一个endEvent，不能复用同一个 Event 对象多次record() - 调用
end.elapsed_time(start)前，要确保 GPU 已完成所有前置操作，否则结果是未定义的（常见表现：返回 0 或极小值） - 首次运行会包含 CUDA 初始化开销，务必预热：执行一次
model(input)再开始测
正确写法：带同步与预热的最小闭环
下面这段代码能稳定测出单次推理延迟，不是“看起来像在测”，而是 GPU 真正完成了计算并返回了耗时：
import torch
model = model.cuda().eval()
input = torch.randn(1, 3, 224, 224).cuda()
<h1>预热</h1><p>_ = model(input)
torch.cuda.synchronize() # 确保预热完成</p><h1>正式测量</h1><p>start = torch.cuda.Event(enable_timing=True)
end = torch.cuda.Event(enable_timing=True)</p><p>start.record()
_ = model(input)
end.record()</p><p>torch.cuda.synchronize() # 关键：等 GPU 真正跑完
latency_ms = start.elapsed_time(end)
print(f"Latency: {latency_ms:.3f} ms")</p>
注意：torch.cuda.synchronize() 出现在两个地方——预热后、end.record() 后。少任何一个，测出来的数都不可信。
batch size 变化时 latency 不线性增长？
这是正常现象。GPU 利用率、内存带宽、kernel 启动开销都会随 batch_size 改变。比如 batch_size=1 时，可能只用上 5% 的 SM，但 batch_size=16 就拉到 80%，此时单样本平均延迟反而下降。
实操建议：
- 不要只测
batch_size=1就推断服务性能；按真实部署场景选 batch（如 API 服务常用 1–4，离线推理常用 16–64） - 测多组 batch：分别记录
batch_size=1, 4, 8, 16下的latency_ms，再算throughput = batch_size / (latency_ms / 1000) - 避免用
torch.no_grad()外层包整个测速块——它不保证 forward 内部子模块没开 grad，老老实实用model.eval()+ 显式torch.no_grad()包 inference 调用
常见错误：Event 被意外重用或跨 stream
错误现象：多次运行结果波动极大（比如 0.03ms / 12ms / 0.04ms 交替出现），或者始终返回 0。
原因和修复：
-
start.record()和end.record()必须在同一个 CUDA stream，默认是torch.cuda.default_stream()；如果模型用了自定义 stream（如某些混合精度或 pipeline 实现），要显式传入：start.record(stream=my_stream) - 别在循环里反复 new Event：Event 对象可以复用，但每次测之前要重新
record()，不能跳过 - 别把 Event 创建放在
model(input)后面——顺序反了，end.record()就录不到任何东西
最易被忽略的一点：elapsed_time() 返回单位是毫秒，但它是浮点数，直接参与除法或取整前，先确认是否需要 round() 或保留三位小数——日志里写成 {latency_ms:.0f}ms 可能把 0.98ms 四舍五入成 1ms，掩盖掉 kernel 启动抖动问题。
