推理请求队列原理：队列的作用、任务调度、请求状态机（IDLE、BUSY、DONE）

在OpenVINO的异步推理架构中，推理请求队列是连接应用层与推理设备（CPU、GPU、NPU等）的核心枢纽。它并非简单的“任务列表”，而是一个承载着状态流转、资源分配与优先级控制的调度系统。理解队列原理，是避免推理管线出现“假死”、CPU空转或显存溢出等问题的前提。本章将深入剖析队列的三大支柱：队列的缓冲与解耦作用、任务调度的核心策略，以及请求状态机的完整生命周期。

上图展示了推理请求队列在应用层与设备层之间的桥梁作用。队列中的每个请求都遵循“IDLE→BUSY→DONE→IDLE”的循环状态流转。下面我们将从队列的缓冲作用、调度策略和状态机细节三个维度展开。

4.1 队列的核心作用：缓冲、解耦与流量整形

推理请求队列的首要价值在于缓冲。当应用层以突发方式产生推理请求（例如视频流中突然出现多帧关键目标）时，队列能够吸收瞬时峰值，避免设备因过载而崩溃。其次，队列实现了解耦：应用层无需等待设备完成当前推理即可继续执行其他逻辑，设备也无需感知应用层的业务复杂度。最后，队列具备流量整形能力，通过限制队列深度或请求数量，可以平滑推理负载，使设备始终工作在高效区间。

4.2 任务调度策略：从FIFO到优先级抢占

OpenVINO的调度器默认采用FIFO（先进先出）策略，保证请求按提交顺序执行。但在多模型或多设备场景下，FIFO可能导致低优先级任务阻塞高优先级任务。为此，OpenVINO提供了两种调度增强手段：

• 设备优先级设置：通过 ov::device::priorities 属性，将不同模型绑定到不同设备，实现设备级并行调度。
• 请求优先级标签：在 ov::InferRequest 上设置 ov::priority 属性，调度器会优先将高优先级请求分配给空闲设备。

实际调度流程如下：

1. 应用层调用 async_infer_queue.start_async() 提交请求。
2. 调度器检查目标设备是否空闲，若空闲则立即执行；否则将请求放入等待队列。
3. 当设备完成当前推理，调度器从等待队列中按优先级和FIFO顺序选取下一个请求。
4. 若设置了回调，设备完成推理后自动触发回调函数，应用层在回调中回收结果。

4.3 请求状态机：IDLE、BUSY、DONE的完整生命周期

每个推理请求对象都维护一个内部状态机，理解其流转是避免资源泄漏和死锁的关键。

状态机的核心设计原则是禁止在BUSY状态修改输入数据。如果应用层在推理过程中覆盖了输入张量，会导致未定义行为（如推理结果错误或设备崩溃）。OpenVINO的 ov::InferRequest 提供了 wait() 方法，用于阻塞等待请求从BUSY转为DONE。

4.4 案例拆解：视频流多路并行推理的队列调优

假设我们有一个8路视频流分析系统，每路视频帧率为30FPS，使用OpenVINO在GPU上进行目标检测。初始实现为每路视频创建一个独立线程，每个线程内使用同步推理。结果发现GPU利用率仅40%，且CPU线程频繁阻塞。

初始现象与指标：

• GPU利用率：40%
• 端到端延迟：120ms（远超单帧33ms预算）
• CPU线程阻塞时间占比：65%

分析判断： 同步推理导致线程在等待GPU时完全阻塞，无法提交下一帧请求。GPU因缺乏足够的并行请求而空闲。

优化方案： 引入 ov::AsyncInferQueue，设置队列深度为16（每路视频2个请求），并注册回调函数用于回收结果。

ov::AsyncInferQueue q(compiled_model, 16);
q.set_callback([&](std::shared_ptr<ov::InferRequest> req, size_t id) {
    // 从req中读取输出，关联到对应的视频流id
    auto output = req->get_tensor("output");
    process_result(id, output);
});
// 提交请求
for (int frame_id = 0; frame_id < total_frames; ++frame_id) {
    int stream_id = frame_id % 8;
    auto req = q.get_idle_request();
    if (req != nullptr) {
        req->set_tensor("input", frames[stream_id]);
        q.start_async(stream_id);
    }
}
q.wait_all();

结果对比：

风险与代价： 队列深度增加会占用更多显存（每个请求约200MB），16个请求需3.2GB显存。若显存不足，需降低队列深度或改用CPU推理。

复盘经验： 队列深度并非越大越好。当队列深度超过设备并行能力时，反而会增加调度开销。建议通过 ov::compiled_model.get_property(ov::optimal_number_of_infer_requests) 获取设备推荐值。

4.5 常见误区与总结复盘