在端侧和边缘设备上部署深度学习模型最头疼的往往不是网络设计而是怎么把训练好的模型在别人的CPU上跑得又快又稳。如果你的目标是“在一台普通x86机器上让模型推理速度翻倍、代码改动尽量小”那OpenVINO确实是个值得认真考虑的工具。它不是用来训练模型的而是专门做推理加速和跨平台部署的运行时套件尤其在英特尔CPU集显上表现相当突出。这篇文章我会把自己的使用经验从头捋一遍覆盖安装、模型转换、Runtime推理、性能调参以及老遇到的那些坑尽量让刚开始接触的新手能按步骤跑通也让已经在用的人看到一些平时文档里不太会写的细节。1. 为什么选择OpenVINO核心思路与适用场景先搞清楚一件事OpenVINO全称是Open Visual Inference And Neural Network Optimization本质是把训练好的模型不管来自PyTorch还是TensorFlow转换成一套中间表示IR然后通过自家Runtime在目标硬件上调度执行。它的思路听起来不复杂但背后做了大量工作包括算子融合、内存复用、指令集适配甚至在某些硬件上把网络编译成更底层的专用代码。我最早接触OpenVINO是因为一个很现实的场景客户要求在无独显的工控机上运行一个目标检测模型机器配置是i5处理器加8GB内存操作系统是Windows 10。直接用OpenCV的DNN模块跑YOLO一帧推理耗时大概是200毫秒左右勉强能动但一旦同时开摄像头流处理和可视化界面抖动非常明显。当时第一反应是换TensorRT但工控机根本没有NVIDIA显卡TensorRT压根装不上。后来才转向OpenVINO在完全相同的硬件上同一份转换后的模型推理耗时从200毫秒降到了大概120到130毫秒而且CPU占用率没有暴涨。这两年的版本迭代之后新版的延迟还能再低一些。这个例子其实已经把OpenVINO最核心的优势说清楚了它不是和TensorRT正面竞争的东西而是填补了非NVIDIA硬件上的高性能推理空白。如果你手头只有CPU、集成显卡或者Movidius这类算力设备OpenVINO几乎是绕不开的选择。它天然能利用英特尔CPU上的AVX指令集能自动完成层融合与常量折叠内存分配策略也是为端侧推理优化的。另一个容易忽略的点是模型格式覆盖面。OpenVINO本身接受ONNX、TensorFlow、PyTorch等导出模型基本涵盖了主流训练框架。而且转换过程很宽容很多在TensorRT那边会直接报错不支持的算子OpenVINO往往会回退到一些兼容实现。当然兼容实现速度没有原生算子快但至少能把流程跑通这在工程交付中非常重要。适用场景上我总结了几个典型情况边缘盒子、工控机等无独立显卡的设备。需要在CPU上同时跑多路视频流的监控场景。现有x86服务器希望提高吞吐量、降低单路推理延迟。不想引入太重的推理框架依赖又需要跨平台部署Windows/Linux都支持。嵌入式或物联网设备对功耗敏感且算力有限。不建议的场景也很明确如果你手里的机器有性能不错的NVIDIA显卡且显存充足TensorRT或vLLM体系往往在速度上有优势如果你处理的是纯动态图且模型结构变化频繁OpenVINO的转换流程反而会拖慢迭代速度。另外要注意OpenVINO加速效果高度依赖模型类型。CNN类网络通常收益很大Transformer类的收益相对小一些但一般也不会比原始实现慢。这是由算子类型决定的CNN的卷积和池化算子特别适合融合与缓存优化而自注意力机制涉及大量矩阵运算虽然也会被优化但提升幅度不同。所以我的建议是先明确自己的部署约束再决定工具。如果约束条件里写着“只能用本机CPU”那就直接用OpenVINO做一次性能基线大概率比裸跑的PyTorch要快两到三倍这个收益足够推翻很多犹豫。2. 环境准备安装、版本选择与常用组件OpenVINO的安装现在比早期版本友好太多了。早期都是手动配环境变量甚至要自己编译。现在核心安装步骤已经简化到几条命令以内且有多种方式可选我分别说下思路。2.1 选择安装方式Python包、Runtime库还是完整工具包OpenVINO在实际使用中至少分成两套能力一是把模型从原始格式转换到IR格式的“模型优化”能力二是将IR模型跑起来的“推理运行时”能力。对于大部分场景我推荐直接使用Python包。它同时包含了模型转换API和Runtime适合写脚本快速验证。一条pip install openvino就能装完自己会带好依赖的Python库。如果部署环境比较纯净、不想装Python那就用Runtime安装包。它的体积更小以C库和动态链接库为主但要注意C部署时模型转换仍然需要另一台机器提前完成部署端只做推理加载。还有一个离线安装选项有些生产环境完全断网pip在线安装根本行不通。OpenVINO官方确实提供了离线wheel包在官网下载页面选择对应平台和Python版本下载后本地pip安装。我建议有断网部署需求的人提前下载好版本选定后还能直接锁死依赖避免后续环境漂移。2.2 版本卡点别盲目追新先看兼容性OpenVINO的版本迭代很快新版本自然会增加新算子、新优化但也会调整API。很多网上旧教程里的代码在新版本会跑不通主要就是API变化导致。比如在2022.3相对稳定的版本里模型加载通常还是ie_core Core()、ie_core.read_model()这样的流程。到了2023以上版本API依然是这一套大框架但内部行为、插桩参数、编译选项都有调整。如果你的项目是老代码迁移不妨直接跳到2024 LTS或更新的版本用新版API重写一遍比逐个接口适配要省心。内存和资源方面Windows上要保证至少有8GB可用内存Linux服务器够用的话也建议同样水平。虽然模型权重大小通常在几十到几百MB但推理时的临时显存/内存开销、多路并发时的峰值占用都会比模型本身大很多。强烈建议生产项目锁定一个OpenVINO版本后不要频繁升级。升级带来的性能提升通常有限但回归测试成本很高尤其是复杂模型结构下可能出现意料之外的精度变化。2.3 快速验证环境是否装好装完之后跑一个最小流程验证确保Model Optimizer和Runtime都能正常加载。可以在Python交互环境执行import openvino as ov core ov.Core() print(core.available_devices)如果打印出的列表包含CPU基本说明安装成功。如果你打算用GPU列表中会出现GPU字样对于新版本集显还会显示类似GPU.0这样的编号。这个输出还能顺便确认设备可见性在装驱动不完整的Windows环境上非常有用。我在最开始试OpenVINO时踩过一个很尴尬的坑Python包安装正常但运行转换脚本时报找不到openvino模块。后来发现是conda环境路径与pip安装路径不一致pip装到了base环境但当前在另一个环境里跑脚本。解决办法是直接用python -m pip install openvino确保装进当前解释器或者用which python和pip show openvino对照检查。3. 模型转换到IR格式整体流程与关键操作拿到模型之后第一步不是直接加载进Runtime而是先把模型转换成OpenVINO自己的IR格式。IR格式包含两个关键文件.xml描述网络结构包括各层的名称、类型、数据流。.bin存储权重和偏移量。转换工作以前依赖独立的mo命令新版本里改成了PythonAPI调用openvino.convert_model。二者最终产物一致但新API在自动化流水线里更好接入尤其适合写脚本批量处理多个模型。3.1 从一个ONNX模型开始转换假设你已经有一个标准的ONNX文件比如model.onnx。最简单的转换方式如下import openvino as ov ov_model ov.convert_model(model.onnx) ov.save_model(ov_model, model.xml)执行完成之后工作目录下会出现model.xml和model.bin。这样转换是默认基于ONNX模型原始输入尺寸如果后续推理时要动态改变输入分辨率需要在转换时显式指定。3.2 指定输入形状与动态维度这是一个非常常见的刚需。很多检测分割模型需要不同尺寸的输入如果直接以静态尺寸转换换一张不同分辨率的图片就报错。此时有两种方案第一种转换时直接指定一个固定的、推理时常用的分辨率适合生产环境已经确定了摄像头的分辨率。代码里加一句ov_model ov.convert_model(input_model, input[1, 3, 640, 640])第二种保留某个维度的动态性让运行时接受多个尺寸ov_model ov.convert_model(input_model, input[[1, 3, -1, -1]])其中-1表示该维度可变。这种动态模型在运行时会增加一次输入形状推断会有一点额外开销但灵活度非常高。我一般只在确实需要多种输入尺寸时使用否则尽量固定能省则省。3.3 转换中的数据处理预处理嵌入很多模型需要输入做过归一化比如除以255或者使用ImageNet的均值方差。如果每次推理都在应用层用Python做预处理开销其实会被放大。OpenVINO的转换阶段支持把预处理操作绑定到模型中这样应用层直接输入原图即可。from openvino import PrePostProcessor ppp PrePostProcessor(ov_model) ppp.input().tensor().set_layout(NHWC).set_element_type(ov.Type.u8) ppp.input().model().set_layout(NCHW).set_element_type(ov.Type.f32) ppp.input().preprocess().convert_element_type(ov.Type.f32).scale(255.0) ov_model ppp.build()这段配置表达的意思很直白模型本身要NCHW且float32但应用层喂入的是NHWC的uint8图像OpenVINO会在推理前自动完成通道顺序调整、uint8转float32、除以255三步操作。写完之后Python代码里就把预处理全部省掉直接把图像Mat或numpy数组丢给推理接口。这个设计在实际多路视频处理中非常有用。预处理从Python层下沉到Runtime层以后既减少了Python的开销又统一了整个流程的逻辑。我强烈建议只要尺寸和类型匹配尽量把归一化放到这个阶段。3.4 权重压缩与INT8量化思路模型转换只是格式变化还有一个更重要的手段是精度压缩。OpenVINO支持INT8量化尤其用于CPU推理时有显著的吞吐收益。传统做法是训练后量化通过一个小的校准数据集统计每层激活值的分布范围再把网络权重改成INT8表示。OpenVINO提供了一套NNCF工具做训练后量化虽然属于进阶玩法但收益很大。我之后会在实战部分专门展开一次量化流程这里先记住一个结论同一个模型在CPU上INT8推理通常比FP32快一到两倍但精度损失一般能控制在几个百分点以内且几乎不需要更改推理代码。4. Runtime推理CPU与GPU的完整使用模型转换好之后就到了实际使用阶段。Runtime的核心概念是Core、CompiledModel与InferRequest三层关系。通俗一点理解Core是引擎负责识别设备和加载插件CompiledModel是把IR模型针对特定设备编译后的产物InferRequest才是实际产生推理结果的载体。在Python里最常见的使用方式如下import openvino as ov core ov.Core() compiled core.compile_model(model.xml, CPU) # 或者直接传入ov_model对象 # compiled core.compile_model(ov_model, CPU)compile_model完成一个非常大的工作量它会把整个网络的算子按目标设备能力做重新调度包含算子融合、内存规划以及指令集选择。这一步很耗时所以应该只做一次后续多张图片复用同一个compiled模型。4.1 单张图片推理的完整流程假设输入图片已经读成一个numpy数组shape是(1, 3, 640, 640)类型为float32且已完成归一化。推理代码如下import numpy as np input_data np.random.rand(1, 3, 640, 640).astype(np.float32) request compiled.create_infer_request() request.infer(inputs{0: input_data}) output request.get_output_tensor().data这里有个细节inputs可以传字典key对应输入端口编号或名称也可以用位置参数的列表形式。对于多输入模型比如两个输入分支推荐按名字传避免序号混淆。获取输出时用get_output_tensor(0)取第一个输出或者按名字获取模型结构复杂时用名字反而更稳妥。如果只是简单跑一次可以不用显式创建infer request直接用compiled(input_data)。但是循环处理多张图时创建request并复用会有更好的性能因为可以避免重复分配中间缓冲区。4.2 C调用的基本结构生产环境里C集成比例不低。OpenVINO的C API和Python几乎是一一对应的#include openvino/openvino.hpp ov::Core core; auto compiled core.compile_model(model.xml, CPU); auto request compiled.create_infer_request(); auto input_tensor request.get_input_tensor(); auto* data input_tensor.datafloat(); // 填充data request.infer(); auto output_tensor request.get_output_tensor(); auto* result output_tensor.datafloat();这段代码是单线程单请求的写法核心步骤和Python一样。C部署时要注意生命周期管理ov::Core、ov::CompiledModel、ov::InferRequest对象最好都在主类里持有成员变量避免局部析构带来的额外开销。4.3 GPU设备的切换与注意事项OpenVINO的GPU插件主要用于英特尔核显调用方式非常直接compiled core.compile_model(model.xml, GPU)代码层面几乎不需要改动但有几件事要注意。首先Intel GPU的驱动必须装好。Windows下通常安装Intel显卡驱动即可Linux下需要安装对应发行版的Intel计算运行时。如果驱动有问题调用available_devices时根本看不到GPU。其次GPU内存与系统内存之间的数据拷贝有开销。对于小模型或低延迟要求场景GPU不一定比CPU快。我实测过一个很小的人脸关键点模型CPU推理2毫秒走GPU反而需要4到5毫秒很大一部分开销就耗在数据往返上。如果你的模型是重卷积网络推理帧率上GPU会有优势如果模型小到一两百毫秒内就能跑完CPU反而省掉了传输阶段的额外延迟。还有一个非常实用的选择让CPU和GPU同时参与推理。OpenVINO支持“Multi-Stick”或“HETERO”模式把模型的不同子图分配到不同设备执行。常规做法是HETERO比如指定前几层在CPU上跑卷积主体在GPU上跑。不过这个属于调优进阶新手不建议上手就用先把单设备的性能摸透了再说。5. 性能调优从数据布局到并行线程很多人拿到OpenVINO之后第一反应是想知道“默认速度是不是最优的”。答案还真不一定。OpenVINO的默认设置是通用合理但距离极值总有一段距离。调优这件事说穿了就是围绕几个关键旋钮做实验。5.1 输入数据布局与类型模型转换阶段指定什么样的输入布局推理阶段就应该按这个布局准备数据。如果你在模型里绑定的是NHWCuint8输入numpy数组就应是[1, height, width, 3]且类型uint8。反过来如果模型期望NCHWfloat32那就是[1, 3, height, width]且float32。布局和类型不匹配时Runtime会做隐式转换但这一步消耗时间且容易产生精度上的隐性问题。5.2 推理线程数限制默认情况下OpenVINO的CPU推理会尝试利用所有可用核心。但在多路并发场景下每个请求都占满所有核反而会造成资源争抢所以需要手动限制。config {NUM_STREAMS: 1, INFERENCE_NUM_THREADS: 4} compiled core.compile_model(model.xml, CPU, config)这里的INFERENCE_NUM_THREADS控制线程数NUM_STREAMS控制并行流的数量。我实测下来在一个8核平台上跑单路摄像头检测把线程数限制到8仍然正常但并发4路视频时每路的线程数限制到4反而总吞吐更高。原因是线程切换和缓存竞争导致有效计算能力下降。简单说要结合具体机器和路数来实验。有些框架里有锁线程池、绑定CPU核心的选项但OpenVINO这边我日常不太折腾核心绑定因为收益不够稳定在某些平台上还可能引发运行错误。5.3 吞吐模式与延迟模式的选择OpenVINO明确提出两种推理模式LATENCY和THROUGHPUT。默认为LATENCY模式即以最低单次延迟为目标。当你需要并发处理多路输入时切换成THROUGHPUT模式往往更有用。config {PERFORMANCE_HINT: THROUGHPUT} compiled core.compile_model(model.xml, CPU, config)THROUGHPUT模式下Runtime会尝试把计算切成多个并行流多路视频时能有效摊满整个CPU资源。但要注意切完流之后单路延迟会升高如果某一路要求实时性极高还是要按LATENCY来配置。5.4 内存复用与异步推理如果你的业务是“边采集边推理”一定要用异步推理模式。异步推理的核心在于上一帧在推理时CPU可以去干下一帧的预处理和网络传输。如果只有同步调infer()则每一帧都有一段纯粹的等待整体帧率上不去。request compiled.create_infer_request() # 设置回调或者等待 request.start_async() request.wait() output request.get_output_tensor().data实际项目中我用的是请求队列加线程池采集线程负责填数据推理线程常驻在OpenVINO的infer request上通过start_asyncwait循环完成流水线。这种模式已经足够支撑中等规模视频墙项目不需要自己在业务里额外做多进程分布式。5.5 用benchmark工具做基线测试调优前先了解当前机器和模型的性能上限这是基本功课。OpenVINO自带的benchmark_app命令行工具非常方便一条命令即可测试纯推理性能benchmark_app -m model.xml -d CPU -t 10参数含义依次为指定模型文件、指定设备、执行时间10秒。执行结束后会输出平均延迟和吞吐量。这个工具的妙处在于它完全帮你隔离了Python和业务层的干扰能直接看到Runtime层面的真实水平便于判断业务瓶颈是不是在推理之外。我建议在调优开始时记录一个基准数字每做一项改动再跑一次尽量做到每次只改动一个变量。6. 精度保障与量化案例模型加速的重要加分项性能提升再高精度崩了也是白搭。这一节专门聊聊精度和量化这是个很容易被忽视但收益巨大的方向。6.1 推理精度变化的主要来源精度变化可能来自三个阶段转换阶段算子替换导致的数值差异。比如某些Sigmoid实现、归一化参数拼接过猛可能引起较小偏差。输入预处理差异训练时和部署时归一化参数不一致比如训练时用的是ImageNet均值[0.485, 0.456, 0.406]部署时却直接除以255效果差别很大。量化阶段INT8表示范围有限权重和激活的舍入误差累积。排查思路是用同一张输入图片分别在原始框架PyTorch或TensorFlow和OpenVINO上跑前向对比输出张量的最大绝对误差或余弦相似度。如果差异在1e-4量级说明转换没问题如果输出差距明显基本可以断定预处理不一致或特殊算子没处理好。6.2 INT8量化实操NNCF训练后量化训练后量化是最好入门的提速手段。NNCF是OpenVINO官方的模型压缩工具它可以直接读取原始模型和校准数据集输出一个INT8 IR模型。流程大致如下准备200到500张有代表性的图片覆盖模型实际使用的主要分布然后跑NNCF量化脚本。这里有一个经验点校准数据的多样性非常关键不要只用自己录的几段视频帧要混合不同场景、不同光照的图片否则量化后可能在特定场景下精度掉得厉害。我实际做过一个检测模型的量化FP32版本在CPU上单帧推理约150毫秒INT8版本降到约70毫秒检测mAP下降大概1.5个百分点肉眼效果几乎没有变化。对于大多数业务场景这种程度的影响完全可接受。有的团队担心INT8精度损失大会采用感知量化训练即QAT。这样做精度保持更好但它要求模型在训练阶段就加入量化感知逻辑对训练代码侵入性较强而且训练耗时明显增加。我的建议是先跑PTQ确认精度损失不可忍受时再考虑QAT大多数项目到不了后一步。6.3 动态量化与逐层精度比较调优过程中可以借助NNCF提供的逐层灵敏度分析工具找出对量化最敏感的那几个层。常见的做法是先把所有层量化再逐个把敏感层保持为FP32混合精度推理。这个操作能换来更好的精度和速度平衡不过对实操经验要求高新手阶段可以先不碰。7. 常见问题与排查技巧实录实际操作中几乎每天都能碰到项目文档里根本不会写的坑这一节我按自己遇到的高频问题整理出来给大家排雷。7.1 转出来的模型尺寸很大怎么处理IR文件夹的bin文件通常不会比原模型权重大太多但如果你用FP32格式转换模型包含大量卷积核体积确实偏大。解决方案有两条一是转换成FP16格式让权重体积减半部分CPU推理有轻微加速二是直接做INT8量化体积约缩小到四分之一推理速度提升明显。FP16在OpenVINO中有个特殊点并不是所有CPU算子都支持FP16原生计算部分场景下整个网络会以兼容方式运行性能不一定比FP32快。所以不要盲目切FP16先看设备支持。7.2 出现“Cannot get memory for tensor”之类的报错这类报错大多不是你代码写错而是系统内存或GPU显存不足。排查顺序看模型尺寸是否正常、看显卡当前被谁占用、看系统虚拟内存是否被调得太小。很多无界面Linux服务器默认限制共享内存也会导致此类问题。可以在启动命令前加ulimit -l unlimited或者在容器环境里设置更大--shm-size。7.3 多线程环境下程序偶发崩溃如果是C部署多线程同时访问同一个CompiledModel或同一个InferRequest大概率出问题。CompiledModel和InferRequest设计上都不是线程安全的正确做法是每个线程各持有一个infer request或者用锁保护请求的创建和销毁。OpenVINO文档里明确写着InferRequest不是线程安全的但仍然有很多人在多线程里共享同一个request导致报错。7.4 动态输入模型推理变慢动态形状模型的好处是灵活代价是推理前需要动态推断内存布局和算子形状。如果业务场景固定尺寸建议转换时就固定下来。我见过有人为了方便一直用动态模型后面实测比固定尺寸模型慢了20%左右。对于视频流应用固定尺寸几乎总能满足需求。7.5 第一次推理很慢后面变快这是正常现象不是故障。compile_model阶段包含了模型编译和算子优化首次执行时还要加载所有动态库、申请内存、初始化线程池。工业项目如果对冷启动时间有要求可以在程序启动时先跑一张待机图做“预热”之后正式推理就不会受首次开销影响。7.6 摄像头视频流GPU模式掉帧严重这个我踩过几次摄像头分辨率高、帧率又高GPU虽然计算速度快但图像从内存传到GPU显存需要拷贝这个拷贝本身也是带宽开销。如果瓶颈在拷贝单纯提高GPU算力并没有用。可以考虑把预处理之后的tensor直接放在GPU内存里或者直接降分辨率。还有一个隐蔽的问题Intel集成显卡在笔记本电脑上会动态调频和切换省电策略插着电源和使用电池时的推理性能差别很大。在线调试时先用稳定电源跑数据不要拿着续航模式下的数据对比别人台式机的结果。8. 部署落地经验与扩展方向基础使用跑通之后真正的工作才刚刚开始。将一个模型装进OpenVINO只是第一步围绕它建立稳定高效的推理服务才会涉及更多工程细节。8.1 容器化部署要点OpenVINO官方提供了镜像可以直接基于它构建服务。自己构建时要注意几个点镜像体积完整安装包括编译器和调试工具可能超过2GB精简部署时只拷贝Runtime库可以降到几百MB。动态库依赖验证镜像里所有依赖是否齐全。缺少libgomp等底层库时推理时通常报错但信息不直观。设备挂载GPU设备在容器内使用需要挂载/dev/dri等设备路径并正确配置用户组权限。8.2 推理服务架构把OpenVINO包装成一个HTTP或gRPC服务是常见做法。服务端维持一个推理线程池每个线程持有一个infer request。接收请求后把输入tensor上传到请求队列由空闲线程取出并执行推理最后返回结果。这里我特意使用“上传到请求队列”而不是“直接在请求线程里推理”是因为CPU上推理本身耗时长占用请求线程会导致并发处理能力下降。多路视频场景下比较推荐“一个视频流对应一个轻量线程”的模型。每条流持有自己的infer request互不阻塞。这种架构直观、易于调试也方便单路断开退出时做资源回收。8.3 与OpenCV的结合应用OpenCV与OpenVINO常配套使用OpenCV负责图像采集和绘制OpenVINO负责推理。需要注意Mat的内存布局与OpenVINO输入格式的转换。现在numpy和cv2都基于内存连续的特性浅拷贝或直接转numpy数组往往零拷贝关键点在于确保数据维度顺序匹配不匹配时再做np.transpose。这个细节直接影响到端到端帧率能省则省。8.4 从单机到多机分布式当单台设备的CPU性能彻底不够时可以考虑多机拆流每台机器负责几路视频预处理和推理汇总节点只做结果聚合。这种方案比在一台机器上疯狂压榨更可靠故障影响面也更小。分布式的粒度可以在OpenVINO层面研究比如某些特定设备管线也可以直接在前端多级网关分流。具体选什么取决于网络带宽和业务实时性这个方向比较开阔暂时不做深入展开。最后说几句个人体会用OpenVINO这几年我最大的体会是它解决的从来不是“模型能不能跑”的问题而是“在有限硬件上跑得够不够快”的问题。许多刚接触的开发者容易陷入一个误区花大量时间纠结框架细节却忽略了对实际业务来说更重要的东西——稳定的输入输出格式、可预期的延迟、紧凑的部署体积。如果你正在做边缘端视觉应用手头又正好是x86平台我建议先别急着到处找优化算法老老实实把模型转成IR、让CPU设备跑通、确认精度无损失这本身就是一次大胆的、有效的起步。之后再根据性能数据决定是否上量化、异步、多路流水线一步步来比一次堆满所有技巧更靠谱。作为实战中的小建议一定要维护一份自己整理的性能基线记录表把每个模型的FP32、INT8、CPU和GPU的延迟都记下来。两个星期前你还能准确记得模型的性能数值可能两个星期后就会混淆。有了这个记录之后不管是做模型升级还是硬件换代对比评估都能立刻看出价值提升。这个习惯不止适用于OpenVINO所有推理框架的实战项目都适用。