📚 课程目录第4章 OpenVINO推理流程回顾

4. OpenVINO推理流程回顾

在深入OpenVINO异步推理与多路视频处理之前，必须对同步推理的完整生命周期建立精确的心智模型。异步改造并非推翻原有流程，而是在既有Pipeline的“等待”间隙插入并行任务。如果对同步流程中的每一个环节（尤其是张量布局、设备拷贝、请求状态机）缺乏清晰认知，异步改造极易引入数据竞争、设备过载或隐式同步等难以排查的问题。本章将拆解从模型加载到输出解析的四个核心阶段，并指出每个阶段在异步化时的关键观察点。

上图展示了OpenVINO推理的完整生命周期。在同步模式下，这四个阶段严格串行；而在异步模式下，阶段二与阶段三可以跨请求重叠，阶段四的回调可以立即释放请求供下一帧使用。理解每个阶段内部的操作及其耗时特征，是决定哪些环节可以并行、哪些环节必须加锁的关键。

4.1 模型加载与编译：构建推理的“基础设施”

核心原理：模型加载阶段的目标是将ONNX、TensorFlow或PaddlePaddle格式的模型文件转换为OpenVINO中间表示（IR），并针对特定硬件设备（CPU、GPU、VPU等）生成优化的执行图。这一阶段由两个关键API完成：ov::Core::read_model()负责解析模型文件并构建原始计算图；ov::Core::compile_model()则执行图优化、层融合、权重量化等操作，生成设备可执行的推理请求对象。

操作流程：

创建ov::Core核心对象，它管理所有已注册的设备插件。
调用read_model(model_path)加载模型文件，此时模型仍处于“平台无关”状态。
可选：设置输入输出的动态形状（reshape）或精度（convert_precision），为多路不同分辨率输入做准备。
调用compile_model(model, device_name)，其中device_name可以是"CPU"、"GPU"或"AUTO"。编译过程可能耗时数百毫秒到数秒，因此必须只执行一次，并复用返回的CompiledModel对象。
从CompiledModel创建InferRequest。在异步场景中，通常需要创建多个请求（请求池），数量取决于设备并发能力与CPU/GPU负载。

异步改造观察点：编译后的CompiledModel是线程安全的，可以被多个线程共享。但InferRequest不是线程安全的——同一时刻只能有一个线程调用其start_async()或wait()。因此，请求池中的每个请求必须由单一工作线程独占，或者通过锁机制保护。

API	同步模式耗时占比	异步模式角色	线程安全
read_model()	约5%	仅初始化一次	是
compile_model()	约20%（首次）	仅初始化一次，可缓存	是
创建InferRequest	约2%	预创建请求池	创建时安全
InferRequest操作	约73%	异步调度的核心	否，需独占或加锁

4.2 输入预处理：从像素到张量的“格式工厂”

核心原理：输入预处理将原始视频帧（通常是BGR格式的cv::Mat）转换为模型期望的张量格式。这包括颜色通道转换（BGR→RGB）、数据类型转换（uint8→float32）、归一化（除以255或使用均值/方差）、尺寸缩放（resize到模型输入尺寸）以及布局转换（HWC→NCHW）。OpenVINO提供了PrePostProcessor类，可以将这些操作绑定到模型输入端口，由推理引擎在内部自动执行，从而减少显式代码。

判断方法：在异步改造前，需要明确预处理是在CPU上执行还是卸载到设备端。对于GPU设备，将resize和归一化操作放入PrePostProcessor可以利用GPU的DMA引擎，释放CPU资源。判断标准是：如果预处理耗时超过单帧推理耗时的30%，则强烈建议使用PrePostProcessor或独立的预处理线程。

// 使用PrePostProcessor将预处理绑定到模型
ov::preprocess::PrePostProcessor ppp(model);
ppp.input().tensor()
   .set_element_type(ov::element::u8)
   .set_layout("NHWC")
   .set_color_format(ov::preprocess::ColorFormat::BGR);
ppp.input().preprocess()
   .convert_element_type(ov::element::f32)
   .convert_color(ov::preprocess::ColorFormat::RGB)
   .resize(ov::preprocess::ResizeAlgorithm::RESIZE_LINEAR)
   .scale(255.0f);
ppp.input().model().set_layout("NCHW");
model = ppp.build();

案例拆解：假设一个1080p视频流，模型输入为640×640。在CPU上直接执行resize+归一化约耗时3ms，而模型推理本身仅需5ms。若使用PrePostProcessor将resize卸载到GPU（在GPU推理前由设备端执行），CPU预处理时间降至0.5ms（仅需将原始帧拷贝到GPU锁页内存）。在多路视频场景下，这2.5ms的节省乘以8路视频，意味着CPU可以多处理约20%的额外负载。

常见误区：不要在每个推理请求中重复创建PrePostProcessor或重复执行ppp.build()。预处理配置应在模型编译前一次性完成。此外，对于动态输入形状，预处理中的resize操作会自动适配，但需确保输入张量内存足够大。

4.3 推理执行：同步等待与异步调度的分水岭

核心原理：推理执行阶段是OpenVINO Pipeline的核心。同步模式下，infer_request.infer()会阻塞当前线程，直到推理完成并返回输出张量。异步模式下，infer_request.start_async()立即返回，推理在后台执行；随后通过infer_request.wait()阻塞等待结果，或通过回调函数在推理完成时自动触发后续处理。异步请求的状态机为：IDLE（空闲）→ BUSY（执行中）→ DONE（完成）→ 重置为IDLE。

操作流程（异步模式）：

从请求池中获取一个状态为IDLE的InferRequest。
将预处理后的张量通过infer_request.set_input_tensor()写入请求。
调用infer_request.start_async()，推理立即开始。
立即返回主循环，处理下一路视频帧的预处理或采集。
当需要结果时，调用infer_request.wait()（阻塞）或设置回调函数（非阻塞）。
处理完输出后，将请求状态重置为IDLE，归还请求池。

案例拆解：以4路1080p视频分析为例，每路帧率25fps，单帧推理耗时8ms。同步模式下，每路视频需要8ms推理+2ms预处理+1ms输出解析=11ms，4路串行处理总耗时44ms，无法满足40ms帧间隔要求。改为异步模式后，创建4个InferRequest（每路一个），主循环依次对4路视频执行start_async()，然后统一wait()。由于GPU可以并行处理多个推理请求，4路推理总耗时仅需12ms（GPU并发），加上预处理和解析的12ms，总耗时24ms，满足实时性要求。

经验提醒：请求池大小并非越大越好。对于GPU，建议请求数不超过设备支持的最大并发数（可通过ov::device::properties查询）。过多的请求会导致GPU显存溢出或调度开销增大。对于CPU，请求数通常等于物理核心数的一半到三分之二，避免线程切换开销。

4.4 输出解析：从张量到业务结果的“最后一公里”

核心原理：输出解析将推理产生的原始张量转换为业务可用的结果。对于目标检测模型，输出通常是一个形状为[1, num_detections, 6]的张量，其中每个检测框包含[x1, y1, x2, y2, confidence, class_id]。解析步骤包括：读取张量数据、应用置信度阈值过滤、执行非极大值抑制（NMS）、将归一化坐标映射回原始图像尺寸，最终封装为结构化的检测结果对象。

判断方法：输出解析的耗时与检测框数量成正比。当画面中目标较多时（例如人群密集场景），NMS可能成为瓶颈。此时应考虑使用OpenVINO自带的NMS插件（如ov::op::v8::MatrixNms）将NMS操作放入模型内部，由设备端加速执行，而非在CPU上手动实现。

// 异步回调中解析输出
auto output = infer_request.get_output_tensor(0);
const float* data = output.data<float>();
size_t num_detections = output.get_shape()[1];
for (size_t i = 0; i < num_detections; ++i) {
    float confidence = data[i * 6 + 4];
    if (confidence > 0.5f) {
        float x1 = data[i * 6 + 0] * frame_width;
        float y1 = data[i * 6 + 1] * frame_height;
        float x2 = data[i * 6 + 2] * frame_width;
        float y2 = data[i * 6 + 3] * frame_height;
        int class_id = static_cast<int>(data[i * 6 + 5]);
        results.emplace_back(x1, y1, x2, y2, confidence, class_id);
    }
}

常见误区与总结复盘：

误区一：在回调函数中执行耗时操作（如日志写入、数据库存储）。回调函数运行在OpenVINO内部的工作线程中，阻塞它会延迟后续推理请求的完成。正确做法是回调中仅做轻量级解析，将结果放入线程安全队列，由业务线程异步消费。
误区二：忽略输出张量的生命周期。在异步模式下，输出张量的内存由InferRequest管理。如果在wait()返回后立即将请求归还池中，而业务线程仍持有输出张量的指针，则可能访问已释放的内存。解决方案是深度拷贝输出数据，或确保业务线程在请求归还前完成读取。
误区三：所有请求共用一个输出回调。在多路视频场景中，回调必须能够区分结果属于哪一路视频。可以通过std::bind将通道ID绑定到回调参数中，或在请求对象中存储上下文指针。

总结：同步推理流程是异步改造的基石。模型加载阶段决定了请求池的创建策略；预处理阶段决定了哪些操作可以卸载到设备端；推理执行阶段是同步与异步的分水岭，核心在于请求状态机的管理；输出解析阶段则需要注意回调的轻量化和张量生命周期。只有将这四个阶段彻底理解，才能在多路视频场景中设计出高效、无数据竞争、可扩展的异步推理Pipeline。