1.1 OpenVINO 定义与技术演进

1.1 OpenVINO 定义与技术演进

本节摘要：OpenVINO 是英特尔开源的推理工具套件，覆盖模型优化、格式转换与跨硬件推理执行，本身不做训练。本节先给出一个不含营销词的工作定义，再沿着 DLDT 到 2024.x 的版本脉络，讲清它为什么长成今天的样子——这直接决定你后面用哪套 API、踩哪些坑。

导读里我们把部署说成一连串选择题，而做选择的前提是认识选项本身。这一节是全书的地基：先把 OpenVINO 的边界划清楚——它管什么、不管什么；再顺着它的演进史，解释为什么 2023 年前的老教程今天大半不能照抄。读完这一节，1.2 节拆组件、1.3 节看硬件时，你就有了一张能对上号的地图。

一、先划边界：它管什么，不管什么

一个常见的误会是把 OpenVINO 当成「加速库」，以为接进去模型就自动变快。准确的定位是：一套以中间表示为中心的推理基础设施，工作分三段。

第一段是转换。训练框架产出的模型（PyTorch 的权重、ONNX 的计算图、TensorFlow 的冻结图）先被转换成 OpenVINO 自己的中间表示，也就是 IR——通常是一对文件，.xml 存网络结构，.bin 存权重。这个阶段做算子规整、常量折叠、精度标记，为执行做准备。

第二段是编译。IR 加载进内存后，针对你指定的目标设备做图优化：算子融合、布局变换、按指令集生成内核。同一个 IR，编译给 CPU 和编译给核显，产物完全不同——这一步决定了性能上限的大头。

第三段是执行。编译产物包装成可推理对象，你的代码往里喂数据、取结果，运行时负责线程调度、内存复用和异步请求管理。

它不管什么，同样要心里有数：不做训练、不做训练侧加速；不替代 PyTorch 或 ONNX 的建模过程；也不是所有硬件的万能钥匙——它的优化深度按英特尔硬件排序，CPU 与核显最深，NPU 次之，其他厂商 GPU 走插件机制可用但算子覆盖需逐个验证。把「管三段、不管两头」记牢，后面遇到「为什么转完模型变小了」「为什么编译要等几秒」这类现象，都能归到对应的阶段去理解。

二、演进脉络：五个关键节点

OpenVINO 的历史只有几年，但接口形态变化很大。网上资料新旧混杂的原因就在这里——2019 年的命令、2021 年的 API、2023 年的工具名，搜出来都能排在一起。下面这张表按时间捋出五个节点，每一行都标注「对你意味着什么」。

两个节点值得多说两句。前端解耦是 2020 年前后的关键一步：在此之前，支持一个训练框架就得把它的解析器内置进主工程；解耦之后，前端变成插件，PyTorch、ONNX、TensorFlow 各有独立前端，主工程只面向 IR。这解释了一个今天的日常现象——read_model 可以直接吞 ONNX 甚至 PyTorch 权重，转换和读取的界限在变模糊。工具链换代则是 2023 年的阵痛：mo 与 POT 被标记为过渡路线，官方文档明确建议新项目用 ovc 与 NNCF。你如果照着 2021 年的博客敲命令，装的可能是一个已被绕过的旧管道。

三、API 2.0：委托式变成契约式

接口层面最大的分水岭是 API 2.0。用一段对照代码看差异最直接：

// API 1.x 风格：委托式，细节黑盒
InferenceEngine::Core core;
auto network = core.ReadNetwork("model.xml");
auto executable = core.LoadNetwork(network, "GPU");
// 设备怎么选、精度怎么定、线程开几个，都是引擎内部说了算

// API 2.0 风格：契约式，关键决策显式声明
ov::Core core;
std::shared_ptr<ov::Model> model = core.read_model("model.xml");
ov::CompiledModel compiled = core.compile_model(model, "GPU",
    ov::hint::performance_mode(ov::hint::PerformanceMode::LATENCY),
    ov::hint::inference_precision(ov::element::f16));
// 延迟优先还是吞吐优先、内部算到什么精度，由你签字确认
​

差异不在写法好看与否，而在责任划分。旧 API 里，你只说「给我跑在 GPU 上」，系统替你拿主意，出了性能问题很难说清是哪层决策造成的；API 2.0 把设备选择、精度策略、调度倾向都变成可声明的属性，每一条都能在文档里查到默认值和取值范围。我们更愿意把它理解成一份可以逐条核对的合同：延迟不达标时，你能逐项检查是哪一条没兑现，而不是对着黑盒猜。第 3 章讲运行时时，这套属性体系会反复出现，这里先记住「关键行为都可显式声明」就够了。

Python 侧是同一套语义。ov.Core()、core.read_model()、core.compile_model() 三个调用构成主干，属性以关键字参数形式传入，和 C++ 侧一一对应。全书示例以 Python 为主，遇到只有 C++ 才讲得清的细节时再给对照。

四、演进的因果：三个推力

把版本史串起来看，会发现每个大版本都对应一个外部推力，不是单纯堆功能。

推力一：训练框架多元化。PyTorch 势大、ONNX 成为交换标准之后，推理引擎再抱着自家的解析器就是自我孤立，前端插件化是必然。推力二：硬件碎片化。从酷睿 CPU 到核显、独显、NPU，加上边缘侧的各种 SoC，设备差异一年比一年大，统一设备抽象与 AUTO 自动调度是被逼出来的——让「选设备」从一个开发问题变成一个配置问题。推力三：端侧确定性要求。边缘场景要的不是平均延迟低，而是每次都低，于是性能模式、执行模式这些原本隐式的策略被显式化成属性，交给开发者签字。

看懂因果链有个实际好处：可以预判它下一步往哪走。设备抽象继续加厚、大模型路径继续加重、旧接口继续退场——2023 年以来每个版本的更新说明都在验证这个判断。选型时你要评估的不是某个孤立版本的功能列表，而是这条轨迹的方向和速度。

本节要点回顾

• 定位：OpenVINO 是「转换、编译、执行」三段式的推理基础设施，不碰训练，优化深度按英特尔硬件递减。
• IR 是核心：.xml 加 .bin 的中间表示是所有后续工作的载体，转换与执行都围绕它展开。
• 五个节点：DLDT 起家、更名 OpenVINO、API 2.0、工具链换代（ovc 与 NNCF）、NPU 成为一等公民。
• API 2.0 的本质：从委托式变成契约式，设备、精度、调度策略全部显式声明，出了问题可逐条核对。
• 资料时效：2022 年前的 API 代码与 2023 年前的转换、量化命令，今天都不该直接照抄。

下一节把这三大段里的角色一个个拆开：Core、Model、CompiledModel、InferRequest 各管什么，ovc、benchmark_app、NNCF 这些命令行工具在流水线的哪个位置——组件认全了，动手才不会迷路。