2、OpenVINO推理基础：模型加载、编译选项、推理请求（InferRequest）的基本概念

在OpenVINO工具套件的使用流程中，模型加载、编译选项配置与推理请求管理是构建高效推理管线的三大基石。理解这三者的关系与底层机制，是后续掌握异步执行与请求队列优化的前提。本章将围绕“如何将一个静态的模型文件转化为可高效运行的推理任务”这一主线，深入剖析Core对象、CompiledModel与InferRequest的职责边界，并结合实际代码与性能指标，帮助您建立清晰的工程化认知。

2.1 模型加载：从文件到内存图

核心原理

模型加载是推理管线的起点，其本质是将磁盘上的模型文件（如OpenVINO IR格式的.xml与.bin，或ONNX格式的.onnx）解析为内存中的ov::Model对象。这一过程由ov::Core类负责，它是OpenVINO运行时环境的全局入口，负责管理设备插件、模型缓存与全局配置。需要特别强调的是，read_model()仅完成模型结构的解析与权重数据的载入，此时模型尚未与任何具体硬件绑定，也不涉及算子映射或内核编译。

操作流程与代码示例

#include <openvino/openvino.hpp>
// 创建Core对象（全局唯一，可复用）
ov::Core core;
// 加载IR模型（.xml + .bin 或 单个 .onnx）
std::shared_ptr<ov::Model> model = core.read_model("resnet50.xml");
// 可选：查看模型输入输出信息
for (auto& input : model->inputs()) {
    std::cout << "Input name: " << input.get_any_name() << std::endl;
    std::cout << "Shape: " << input.get_shape() << std::endl;
}

常见误区

• 误区1：每次推理都重新加载模型。正确做法是复用ov::Model对象，仅在模型更新时重新加载。
• 误区2：忽略模型输入输出的动态形状。若模型支持动态维度（如-1），需在编译前通过reshape()或set_input_shape()明确具体形状，否则可能影响编译优化。
• 误区3：在多线程环境中共享同一个Core实例而不加锁。虽然Core是线程安全的，但read_model()内部可能涉及全局资源竞争，建议在初始化阶段完成所有模型加载。

2.2 编译选项：从模型到可执行程序

核心原理

编译是将ov::Model转换为特定硬件可执行代码的过程，产物为ov::CompiledModel对象。此阶段会执行算子融合、内存布局优化、内核选择与精度校准（如FP16/INT8）。编译选项通过ov::AnyMap（即std::map<std::string, ov::Any>）传入compile_model()，这些选项直接影响推理性能与资源占用。

判断方法与调优策略

选择编译选项的核心依据是业务性能目标。若追求最低单次推理延迟，应设置PERFORMANCE_HINT为LATENCY，并关闭NUM_STREAMS（设为1）；若追求最大吞吐量，则使用THROUGHPUT模式并适当增加流数量。实际工程中，建议通过OpenVINO提供的benchmark_app工具进行基线测试，再根据结果调整配置。

案例拆解：视频分析服务的编译配置

假设我们部署一个8路视频流实时分析服务，每路视频帧率为25FPS，使用YOLOv8s模型（FP16）。初始配置为默认参数，实测单路延迟为35ms，但CPU占用率高达90%，且偶发丢帧。分析发现，默认配置下OpenVINO为每路视频创建了独立编译模型，且未限制线程数，导致CPU资源争抢。

优化操作如下：

1. 将PERFORMANCE_HINT设为THROUGHPUT，并设置NUM_STREAMS为4（与CPU物理核数匹配）。
2. 设置CPU_THREADS_NUM为6，预留2个核给系统与采集线程。
3. 启用CACHE_DIR，避免每次重启服务重新编译。

优化后，单路延迟上升至42ms（仍在25FPS预算内），但CPU占用率降至65%，丢帧现象消失，整体吞吐量从6路提升至8路。此案例说明，编译选项并非单纯追求“快”，而是要在延迟、吞吐与资源占用间取得平衡。

2.3 推理请求（InferRequest）：执行与数据交互

核心原理

ov::InferRequest是实际执行推理的句柄，它绑定到特定的CompiledModel，负责管理输入/输出张量、触发推理执行以及获取结果。每个InferRequest拥有独立的张量内存空间，这意味着多个请求可以并行运行而互不干扰。推理请求支持两种执行模式：同步（infer()）与异步（start_async() + wait()），后者是构建请求队列的基础。

操作流程与代码示例

// 创建推理请求（每个请求独立）
ov::InferRequest req = compiled_model.create_infer_request();
// 获取输入/输出张量
auto input_tensor = req.get_input_tensor(0);
auto output_tensor = req.get_output_tensor(0);
// 填充输入数据（假设为NCHW布局的float数据）
float* data = input_tensor.data<float>();
memcpy(data, image_data, sizeof(float) * 1 * 3 * 224 * 224);
// 同步执行（阻塞直到完成）
req.infer();
// 读取输出
float* result = output_tensor.data<float>();

异步执行与请求复用

异步执行的核心优势在于重叠计算与数据传输。当使用start_async()提交任务后，CPU可以立即返回执行其他操作（如预处理下一帧图像），而推理在后台进行。通过set_callback()注册回调函数，可以在推理完成时自动处理结果，无需阻塞等待。

常见误区与复盘

• 误区1：为每次推理创建新的InferRequest。创建请求本身有开销（如内存分配），高频创建会拖慢性能。正确做法是预创建请求池，循环复用。
• 误区2：混淆infer()与start_async()的线程安全性。同一个InferRequest对象不能同时被多个线程调用，但不同请求对象可以并行执行。
• 误区3：忽略输出张量的形状变化。若模型输出为动态形状，每次推理后需检查get_shape()，避免越界访问。

小型场景化说明：请求池的初步设计

假设我们需要处理来自摄像头的连续帧，每帧推理耗时约10ms，而预处理需要5ms。若采用同步方式，每帧总耗时15ms，帧率上限约66FPS。改用异步方式后，我们可以创建2个InferRequest：请求A处理第N帧时，CPU同时预处理第N+1帧；当A完成后，立即用B处理第N+1帧，同时预处理第N+2帧。通过这种流水线重叠，帧率可提升至接近100FPS（受限于最慢阶段）。这正是后续章节“请求队列”的核心思想——通过多个请求的轮转调度，隐藏预处理与后处理延迟。

2.4 三阶段协同与性能基线

核心原理

模型加载、编译与推理请求并非孤立阶段，而是存在紧密的依赖关系。加载阶段决定了模型的结构灵活性；编译阶段决定了硬件适配与优化程度；推理请求阶段则决定了运行时资源利用效率。一个常见的性能分析方法是：分别测量三个阶段耗时，定位瓶颈所在。

实战建议

在工程初始化阶段，应一次性完成模型加载与编译，并将CompiledModel与InferRequest池作为全局资源管理。对于延迟敏感型应用，建议将PERFORMANCE_HINT设为LATENCY并绑定CPU核心；对于吞吐型应用，则优先考虑THROUGHPUT模式与多流并行。此外，务必利用OpenVINO的ov::Core::get_property()查询设备支持的能力（如最大线程数、精度支持列表），避免设置无效选项。