3、核心概念：深入理解延迟（Latency）、吞吐量（Throughput）、批处理（Batch）、并发（Concurrency）等关键术语，以及它们对性能的影响
在OpenVINO性能工程中，延迟、吞吐量、批处理和并发是四个最基础也最容易被混淆的概念。它们共同决定了推理系统在真实业务场景中的表现：是让单个请求尽快返回结果，还是让整体系统在单位时间内处理尽可能多的请求。理解这些术语的本质差异及其相互作用，是进行Benchmark测试、性能调优和架构设计的前提。本章将从定义出发，剖析它们对性能指标的影响路径，并通过对比表格和案例拆解，帮助你在实际项目中做出正确的配置决策。
3.1 核心原理：四个术语的准确定义与度量
延迟（Latency）衡量的是从请求发出到响应返回所经历的总时间。在推理场景中，它通常包括网络传输时间、排队等待时间、预处理时间、推理计算时间和后处理时间。延迟是一个随机变量，因此不能只看平均值，必须关注百分位点（如P50、P95、P99）。P99延迟表示99%的请求都在该时间以内完成，它比平均值更能反映系统的尾部性能。
吞吐量（Throughput）表示系统在单位时间内成功处理的请求数量，常用FPS（Frames Per Second）或req/s表示。吞吐量反映的是系统的整体处理能力，它与延迟有关联但并非简单反比关系——通过增加并发或批处理，可以在延迟略有上升的情况下大幅提升吞吐量。
批处理（Batch）是指将多个输入样本合并为一次推理调用。现代CPU和GPU的SIMD（单指令多数据）架构以及专用AI加速器（如NPU）对批量数据计算效率更高。例如，处理8张图片的批处理时间可能只是处理1张图片时间的3-4倍，而不是8倍，因此单位样本的平均计算成本显著下降。
并发（Concurrency）描述的是系统同时处理的请求数量。在OpenVINO中，并发可以通过多线程、多流（Stream）或多实例的方式实现。并发并不等同于并行——如果CPU只有4个物理核心，那么8个并发请求实际上是在时间片轮转中交替执行，每个请求的延迟会因资源竞争而增加。
关键认知：延迟和吞吐量是系统外部表现，而批处理和并发是系统内部配置手段。外部表现由内部配置决定，但并非线性关系。理解这四者的关系，是进行Benchmark测试和性能调优的第一步。
3.2 判断方法与操作流程：如何选择Batch和Concurrency
在实际项目中，选择Batch和Concurrency的流程可以归纳为以下五个步骤：
- 明确业务SLA：首先确定延迟上限。例如，实时视频分析要求P99延迟小于50ms，而离线批量处理可能允许P99延迟达到2秒。
- 评估硬件资源：查看CPU核心数、内存带宽、GPU显存大小。CPU推理时，Batch大小通常受限于内存带宽；GPU推理时，Batch大小受限于显存容量。
- 从Batch=1开始：先测量单请求延迟基线，记录P50和P99值。这是后续所有对比的基准。
- 逐步增大Batch：以2的幂次递增（1→2→4→8→16），观察吞吐量变化和延迟增长曲线。当吞吐量增长趋缓或延迟急剧上升时，即为该硬件上的Batch上限。
- 调整并发数：在固定Batch下，从Concurrency=1开始，逐步增加并发请求数。观察吞吐量是否线性增长，以及延迟的P99是否突破SLA阈值。
| 配置参数 | 影响吞吐量 | 影响延迟 | 适用场景 |
|---|---|---|---|
| Batch=1, Concurrency=1 | 最低 | 最低（最优延迟） | 实时交互、单请求响应 |
| Batch=8, Concurrency=1 | 中等（计算效率提升） | 中等（排队等待增加） | 离线批量处理 |
| Batch=1, Concurrency=8 | 中等（多核并行） | 中等（资源竞争） | 在线服务、多用户并发 |
| Batch=8, Concurrency=4 | 高（计算+并行叠加） | 较高（双重排队） | 高吞吐量优先的批处理服务 |
3.3 案例拆解：视频分析服务的性能调优
某智慧城市项目需要部署视频流分析服务，硬件平台为单颗Intel Xeon Gold 6338（32核），使用OpenVINO Runtime进行YOLOv5模型推理。初始配置为Batch=1、Concurrency=1，实测P50延迟为12ms，P99延迟为18ms，吞吐量为83 FPS。业务要求是同时分析16路视频流，每路25 FPS，总需求为400 FPS，且P99延迟不超过100ms。
初步分析：当前吞吐量远低于需求，必须通过调整Batch和Concurrency来提升。但直接增大Batch会导致延迟上升，需要找到平衡点。
调优过程：
- 第一步：固定Concurrency=1，将Batch从1逐步增加到16。实测数据：Batch=4时，吞吐量达到210 FPS，P99延迟为35ms；Batch=8时，吞吐量达到320 FPS，P99延迟为58ms；Batch=16时，吞吐量达到380 FPS，但P99延迟飙升至120ms，已超过SLA。
- 第二步：固定Batch=8，将Concurrency从1增加到4。Concurrency=2时，吞吐量达到450 FPS，P99延迟为72ms；Concurrency=4时，吞吐量达到520 FPS，但P99延迟达到95ms，接近SLA上限。
- 第三步：尝试Batch=4、Concurrency=4的组合，吞吐量为480 FPS，P99延迟为68ms，留有一定余量。
最终方案：选择Batch=4、Concurrency=4，实际吞吐量480 FPS，满足400 FPS的需求，P99延迟68ms，低于100ms的SLA。相比初始配置，吞吐量提升了5.8倍，延迟仅增加了3.8倍。
经验提醒：在调优过程中，不要同时改变Batch和Concurrency两个变量。每次只调整一个参数，记录完整的性能数据（吞吐量、P50、P95、P99），才能准确判断每个参数的影响。另外，CPU推理时，Concurrency不宜超过物理核心数的一半，否则线程切换开销会显著增加。
3.4 常见误区与总结复盘
误区一：认为Batch越大越好。虽然大Batch能提升计算效率，但会显著增加延迟，且当Batch超过硬件缓存容量时，性能提升会急剧衰减甚至下降。例如，在内存带宽受限的平台上，Batch从32增加到64时，吞吐量可能不升反降。
误区二：混淆并发与并行。并发是逻辑上的同时处理，并行是物理上的同时执行。在4核CPU上设置Concurrency=16，并不会带来16倍的吞吐量提升，反而会因为上下文切换导致延迟恶化。
误区三：只关注平均延迟。在真实业务中，P99延迟往往比平均延迟更重要。一个平均延迟为20ms但P99为200ms的系统，用户体验可能比平均延迟30ms但P99为50ms的系统差得多。
误区四：忽略预处理和后处理的开销。在Benchmark中，如果只测量推理时间而忽略图像解码、归一化、结果解析等环节，实际部署时的延迟会远高于测试值。建议在Benchmark中包含完整的预处理和后处理流程。
风险提示：在调整Batch和Concurrency时，务必监控CPU利用率和内存带宽。如果CPU利用率已经接近100%，继续增加并发只会增加排队延迟；如果内存带宽已饱和，增大Batch会导致缓存命中率下降，性能反而恶化。建议使用perf或vtune工具进行硬件计数器分析。
总结复盘：延迟、吞吐量、批处理和并发构成了推理性能优化的核心框架。延迟是用户体验的硬指标，吞吐量是系统效率的体现，批处理通过提高计算密度来提升吞吐量，并发通过利用多核资源来提升吞吐量。在实际项目中，必须根据业务SLA、硬件资源和模型特性，通过系统化的Benchmark实验找到最优配置组合。记住一个核心原则：在满足延迟约束的前提下，最大化吞吐量——这是所有性能调优工作的最终目标。