应使用 time.perf_counter() 测量模型推理延迟，因其单调、高精度、不受系统时钟调整影响；必须包含预处理、前向传播、后处理全路径，预热1–3次，并连续测100+次取p50/p90/p99。
延迟怎么测：用 time.perf_counter() 而不是 time.time()
模型推理延迟（latency）指单次请求从输入送入到输出返回所耗时间，必须测的是「端到端实际耗时」，不是模型前向传播内部计时。用 time.perf_counter() 是因为它是单调递增、高精度、不受系统时钟调整影响的计时器；time.time() 在系统时间被 NTP 校正时可能跳变，导致负延迟或异常大值。
常见错误是只对 model(input) 包裹计时，忽略了数据预处理（如图像 decode、resize、to_tensor）和后处理（如 NMS、decode bbox）。真实服务中这些都在请求路径上，必须包含。
- 预热至少 1–3 次：GPU 上首次运行常含 kernel 编译、显存分配开销，不预热测出的延迟偏高且不稳定
- 连续测 100+ 次取 p50/p90/p99，别只看平均值——平均值掩盖长尾毛刺
- 避免在 Jupyter 或交互式环境里测：Python 的 GC、后台线程、IPython 自身开销会干扰结果
吞吐量怎么算：单位时间完成请求数，不是“总时间除以请求数”
吞吐量（throughput）单位是 QPS（queries per second），本质是并发能力的体现。直接用「总耗时 / 总请求数」反推 QPS 只在串行场景下成立，而实际服务必然是并发处理的。正确做法是启动固定并发数（如 4、8、16 个线程/进程），持续发送请求，统计单位时间内成功完成的请求数。
例如用 concurrent.futures.ThreadPoolExecutor 发起 1000 次请求，记录从第一个请求发出到最后一个响应返回的时间窗口（不是每个请求的耗时累加），再用 1000 / (end_time - start_time) 得到实际 QPS。
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 注意区分「吞吐量」和「吞吐率」：前者是稳态指标（如 sustained 120 QPS），后者可能是瞬时峰值（如 burst 300 QPS），报告时需注明测试模式
- CPU 绑核或 GPU 显存不足会导致吞吐非线性下降——比如从 8 并发升到 16 并发，QPS 只涨 10%，大概率是资源瓶颈而非模型本身
- 输入 batch size 影响极大：增大
batch_size通常提升 GPU 利用率，但也会增加单次延迟，需权衡
PyTorch/Triton 下容易漏掉的开销点
PyTorch 模型部署到生产时，很多延迟来自框架层而非模型计算本身。比如 torch.jit.script 模型首次调用仍要触发图优化；torch.compile（尤其是 with mode="reduce-overhead"）首次运行有编译延迟；Triton 推理服务器默认启用 dynamic batching，batch delay 参数（max_queue_delay_microseconds）若设得过大，会人为拉高 P99 延迟。
- 禁用 Python GC：
gc.disable()可减少推理中意外触发的停顿，尤其在小模型高频请求场景下明显 - 检查 CUDA 同步：若用
torch.cuda.synchronize()强制等待，会暴露真实延迟，但漏掉它则测出的是“异步提交耗时”，不是端到端延迟 - Triton 的
perf_analyzer工具默认测的是 server 端延迟，不含网络往返；若走 HTTP，需额外加curl或aiohttp客户端实测端到端
为什么本地测的延迟和线上差一倍？
根本原因在于环境不可控项太多：本地用 torch.load(..., map_location="cuda") 加载模型，但线上可能用了 TensorRT 引擎序列化；本地输入是 numpy array，线上是 base64 编码的 JPEG 字节流，解码开销没计入；更隐蔽的是，Docker 容器未设置 --gpus all --ulimit memlock=-1，导致 CUDA malloc 失败后回退到慢速路径。
真正可比的基准必须锁定三要素：输入格式（tensor shape + dtype）、硬件状态（nvidia-smi -q -d POWER,TEMPERATURE,CLOCK 必须稳定）、运行时配置（OMP_NUM_THREADS、CUDA_LAUNCH_BLOCKING=0、TF32 enabled 状态）。
最常被忽略的是 CPU 频率缩放。Linux 默认启用 ondemand governor，空闲时降频，首请求延迟飙升。上线前务必执行：sudo cpupower frequency-set -g performance。
