想象你是一家跨国物流公司的老板，仓库里堆积着来自不同工厂的 AI 模型：PyTorch 打的是木箱，TensorFlow 装的是纸箱，Caffe 捆的是麻袋。而边缘现场是一连串口味各异的港口——x86 工控机只认某种吊车，GPU 泊位要求托盘，VPU 码头偏爱视觉小件。要把这些货顺利卸下，过去只能给每种组合写专门的搬运方案，耗时耗力且容易出错。Intel OpenVINO 就是为解决这场“物流混战”而生的统一通关系统：模型优化器把不同框架的模型装进标准集装箱 IR，推理引擎调度所有吊装作业，设备插件负责适配 CPU、GPU、VPU 等不同泊位。本文会沿着“换包装—过海关—调码头—上系统”的路线，带你读懂边缘 AI 推理的完整链路。

岗位关联

学完你将掌握 OpenVINO 的模型转换、推理 API 与性能调优思路，能快速在 Intel 边缘设备上完成 AI 落地，为工业质检、智慧零售等场景提供可直接上线的推理服务。

目录
  1. 可视化演示
  2. 边缘算力困境：没有统一通关规则，部署寸步难行
  3. 初识OpenVINO：从三座设施看懂工具链全景
  4. 模型优化器转换：装箱师傅的精打细算
  5. 推理引擎调用：调度塔里的固定动作
  6. 设备插件生态：不同泊位的专用吊具
  7. 性能调优策略：港口运营的提速秘籍
  8. 边缘部署实战：把港口搬进工厂车间
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示OpenVINO工具链流程（模型转换→IR→推理引擎执行）、Intel硬件目标与插件（CPU/GPU/VPU/NPU统一API）、图优化与INT8量化（层融合+量化压缩加速），三模式切换理解OpenVINO推理优化全貌。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+C1+'

边缘算力困境：没有统一通关规则，部署寸步难行

你是一家跨国物流公司的老板，仓库里的 AI 模型形态各异：PyTorch 是实木箱，TensorFlow 是瓦楞纸箱，Caffe 是编织袋。它们要运到 x86 工控机、GPU 显卡、VPU 视觉芯片这些“海外港口”，可每个港口只认自己的装卸规格。没有统一规则，就只能为每种组合写一套专属搬运程序，货越堆越多，工期越拖越长。

边缘 AI 部署正是这样的尴尬局面。Intel 平台上的 CPU 擅长通用计算，集成 GPU 适合并行任务，VPU 则是低功耗视觉处理单元；而训练框架又各有各的算子与权重格式。如果每次部署都为“某个框架 + 某个设备”单独开发接口，代码会迅速变成一团乱麻，维护成本随设备数量爆炸式增长。

更关键的是，边缘应用考核的不是单次模型计算有多快，而是整条链路的端到端时延。从摄像头取图到结果上抛，每一步都可能成为瓶颈：

所以，与其继续写各种“港口专属方案”，不如先建一套统一通关系统。OpenVINO 的使命，正是让不同框架的模型进入 Intel 边缘设备时，都能走同一条标准化通道。

T总时延=T传输+T推理+T后处理T_{\text{总时延}} = T_{\text{传输}} + T_{\text{推理}} + T_{\text{后处理}}
通俗理解：港口总交付时间 = 货物转运到码头的时间 + 吊机作业的时间 + 重新装箱送出厂的时间。
  1. 传输时延图像或信号在网络、总线上搬运的耗时，数据量越大、带宽越低，时延越高。
    T传输=DBT_{\text{传输}} = \frac{D}{B}
  2. 推理时延模型在设备上执行算子、计算输出的耗时，是 OpenVINO 重点优化的对象。
    T推理=compute(f,x)T_{\text{推理}} = \text{compute}(f, x)
  3. 后处理时延把裸输出转成目标框、类别等业务结果的耗时，常被忽略却同样关键。
    T后处理=NMS(P)T_{\text{后处理}} = \text{NMS}(P)

初识OpenVINO：从三座设施看懂工具链全景

OpenVINO 就像一座覆盖多国港口的统一通关网络：报关打包楼叫模型优化器（Model Optimizer，MO），负责把各家模型装成统一集装箱；中枢调度塔叫推理引擎（Inference Engine，IE），负责指挥所有吊装流程；各泊位的专用吊具叫设备插件，负责把集装箱放到 CPU、GPU、VPU 上。三座设施各司其职，货主只要记住一个流程。

从技术上看，MO 能理解 TensorFlow、ONNX、Caffe 等常见格式，PyTorch 模型一般先导出为 ONNX 再交给 MO。MO 转换后得到的是中间表示（Intermediate Representation，IR）。IE 只认 IR，不关心模型来自哪个框架、算子长成什么样，这让算法工程师可以专注业务，而不是反复适配框架差异。

IR 并不是神秘文件，而是两个标准文件构成的“集装箱组合”：

有了这个统一集装箱，物流公司再也不用为每个港口重写方案。算法团队只要维护一条转换流水线，就能覆盖主流 Intel 边缘设备，后续开发效率成倍提升。

IR={拓扑.xml,权重.bin}IR = \{ \text{拓扑}.xml, \text{权重}.bin \}
通俗理解：.xml 是集装箱货物清单，.bin 是货物本体，两者一起才能通关。
  1. 拓扑.xml记录网络结构、算子连接、输入输出信息，像一张标注清晰的海关申报单。
    拓扑.xml=网络结构描述\text{拓扑}.xml = \text{网络结构描述}
  2. 权重.bin按二进制顺序存放模型权重，是真正参与计算的数值。
    权重.bin=浮点参数序列\text{权重}.bin = \text{浮点参数序列}
  3. 两者缺一不可只有清单没有货无法验放，只有货没有清单则无法清点。
    IR=拓扑.xml+权重.binIR = \text{拓扑}.xml + \text{权重}.bin

模型优化器转换：装箱师傅的精打细算

MO 是报关打包楼里的资深装箱师傅。接到原模型后，他先检查箱内有没有“违禁品”——比如某个不被支持的算子；再确认货主申报的尺寸——也就是输入张量的形状；接着按货主要求选择 FP16 或 FP32 精度；最后打包放出 .xml 和 .bin 两个文件。

在命令行中，转换通常只靠一条命令完成。以 ONNX 模型为例：

--input_model 指定源模型文件，--input_shape 明确模型期望的输入尺寸，--data_type FP16 则让权重以半精度存储。转换完成后，源框架模型便不再参与边缘推理，所有设备统一使用 IR。

精度配置会直接影响边缘设备的内存占用。FP32 每个权重占 4 字节，FP16 每个权重只占 2 字节，因此存在一个简单关系：

转换完成后，源框架模型就可以“退役”了。后续所有 Intel 设备都从这批标准集装箱出发，省去大量重复适配，这也是 OpenVINO 能提升团队交付速度的核心原因。

MFP16=12MFP32M_{\mathrm{FP16}} = \frac{1}{2} M_{\mathrm{FP32}}
通俗理解：100MB 的 FP32 权重转成 FP16 后约 50MB，边缘工控机可以装下更大模型或多路并发。
  1. FP32 权重占用一个模型如果有 n 个权重，全部用 32 位浮点保存时占 4n 字节。
    MFP32=n×4M_{\mathrm{FP32}} = n \times 4
  2. FP16 权重占用换成半精度后，每个权重只用 2 字节。
    MFP16=n×2M_{\mathrm{FP16}} = n \times 2
  3. 两者关系把两个式子作比，正好得到二分之一。
    MFP16=24MFP32=12MFP32M_{\mathrm{FP16}} = \frac{2}{4} M_{\mathrm{FP32}} = \frac{1}{2} M_{\mathrm{FP32}}
bash1 行
mo --input_model model.onnx --input_shape [1,3,224,224] --data_type FP16

推理引擎调用：调度塔里的固定动作

IE 调度塔不关心集装箱来自哪家物流公司，只认统一编码。开发者要做的，是把箱子放上传送带（输入），告诉调度塔用哪台吊机（设备），再决定是一台一台吊（同步）还是流水线并行（异步）。调用流程固定，学一次便能处处使用。

典型 API 流程是：创建 Core 对象 → read_model 读取 IR → compile_model 编译到目标设备 → create_infer_request 创建推理请求 → 填入输入张量并执行 infer → 从输出张量取结果。Python 接口中，compiled_model(input_data) 也能一步完成推理，但底层走的是同一套流程。

同步与异步的取舍直接影响吞吐。同步模式下，一次推理完成后才开始下一次；异步模式则让预处理、推理、后处理重叠进行。若一个批次包含 N 个样本，单批推理耗时为 L 毫秒，则每秒吞吐量可写成：

掌握这套 API 之后，无论设备是 CPU、GPU 还是 VPU，调用方式都保持统一。硬件的差异被插件挡在调度塔之外，这正是 OpenVINO 能成为边缘推理“通用语言”的原因。

Q=N×1000LbatchQ = \frac{N \times 1000}{L_{\mathrm{batch}}}
通俗理解：吊机一次吊 N 个箱子，每吊耗时 L 毫秒，一秒钟能吊的次数就是吞吐量。
  1. 批大小 N一次送入模型并行处理的样本数量。
    N=batch sizeN = \text{batch size}
  2. 单批耗时 L完整处理这一批样本所用的毫秒数。
    Lbatch=单批推理用时L_{\mathrm{batch}} = \text{单批推理用时}
  3. 吞吐量 Q把毫秒换成秒后，每秒可以完成的样本数。
    Q=NLbatch/1000Q = \frac{N}{L_{\mathrm{batch}} / 1000}

设备插件生态：不同泊位的专用吊具

港口最终要落货，CPU 泊位通吃各种散货，GPU 泊位擅长成批重箱，VPU 泊位像视觉专用的小型快艇码头。每个泊位的吊具形态不同，但它们都遵循同一个集装箱标准。这就是 OpenVINO 插件机制的生动写照。

在代码中，设备选择通常就是一个字符串：device='CPU' 使用 CPU 插件，device='GPU' 调用集成显卡，device='VPU' 对应 Intel Movidius 等视觉处理芯片，device='AUTO' 则让 OpenVINO 自动选设备。更复杂的场景还可以用 HETERO 模式，把网络的不同层拆分到多个设备执行，让“CPU 带不动、VPU 很合适”的分工成为可能。

选择设备时，核心是比较单位任务的耗时。假设模型单次推理的计算量为 W，设备 d 的实际算力为 R_d，则可做如下估算：

插件系统让“模型不变、设备可变”成为现实。新增一台设备时，只需安装对应插件并修改一行配置；AUTO 调度员还能按负载实时选泊位，边缘部署的灵活性大大提升。

td=WRdt_d = \frac{W}{R_d}
通俗理解：货量固定时，设备算力越强，预计耗时越短；AUTO 插件会按这个“耗时预估”自动泊位。
  1. 计算量 W模型一次前向推理需要的浮点运算次数，可视为货物总重量。
    W=FLOPsW = \text{FLOPs}
  2. 设备算力 R_d设备在特定精度和内存带宽下的实际处理速度。
    Rd=设备吞吐能力R_d = \text{设备吞吐能力}
  3. 预计耗时 t_d用货量除以算力，得到单次推理的时间估计。
    td=WRdt_d = \frac{W}{R_d}

性能调优策略：港口运营的提速秘籍

繁忙港口提升吞吐，不是简单让吊车飞转，而是把同方向货物攒成一堆同时吊、固定专用泊位减少换轨、把常用单据提前存档。OpenVINO 的性能调优，本质上就是这套“港口运营思想”的软件实现。

常用手段包括：设置 PERFORMANCE_HINT='THROUGHPUT' 或 'LATENCY' 切换优化目标；调整批处理大小让计算更饱满；用 NUM_STREAMS 增加并行流；用 CPU_THREADS_NUM 指定线程数；用 CPU_BIND_THREAD 把线程绑定到物理核；开启模型缓存 CACHE_DIR，避免每次启动都重复编译模型。这些策略组合起来，能在不大改业务代码的前提下显著提速。

调优是否有效，需要一个可量化的指标。假设调优前每秒处理 Q_base 个样本，调优后为 Q_opt，则提升比例：

这几招组合使用后，工控机的算力利用率会明显提升。但要注意，调优不是无限加大 batch；硬件有内存和延迟上限，业务有响应时间要求，找到平衡点才是优秀调优工程师的本事。

η=Qopt−QbaseQbase×100%\eta = \frac{Q_{\mathrm{opt}} - Q_{\mathrm{base}}}{Q_{\mathrm{base}}} \times 100\%
通俗理解：把优化前后的吞吐量相减，再除以原始值，就能看出港口改造带来了多少个百分点的提升。
  1. 原始吞吐 Q_base未调优时每秒能处理的样本数。
    Qbase=初始吞吐量Q_{\mathrm{base}} = \text{初始吞吐量}
  2. 优化后吞吐 Q_opt应用批处理、多流、绑定等策略后的每秒样本数。
    Qopt=调优后吞吐量Q_{\mathrm{opt}} = \text{调优后吞吐量}
  3. 提升比例 η两者之差与原始值的百分比，是边缘项目验收的常用指标。
    η=Qopt−QbaseQbase×100%\eta = \frac{Q_{\mathrm{opt}} - Q_{\mathrm{base}}}{Q_{\mathrm{base}}} \times 100\%

边缘部署实战：把港口搬进工厂车间

一台工控机，就是一座迷你港口。把港务软件（OpenVINO runtime）装进系统，把 IR 集装箱放在指定堆场，业务程序定时启动、按班运行。大港口的全套流程被压缩到小盒子里，却依然井然有序。

在真实部署中，通常先在 Ubuntu/CentOS 上安装 OpenVINO runtime，再用 mo 把模型转换为 IR，放进业务目录。业务进程通过 IE 加载 IR，启用模型缓存和异步推理。更新模型时，只需替换 IR 文件并平滑重启进程，业务代码完全不动。若使用容器化，还能把 runtime、依赖、模型打包为镜像，让每一台新的边缘设备都能快速复制出相同环境。

边缘项目上线前，还要做一笔经济账。假设系统每天节省的人工成本为 S，计划运行 T 天，硬件与开发维护总投入为 C，则投资回报率可表示为：

当一条产线的部署流程跑通，第二条、第三条产线就能复制同样的模板。统一标准让模型更新、设备扩容、人员培训都变得可预期，这才是边缘 AI 真正产生规模效益的时刻。

ROI=S节省×T运行天数C硬件+C开发维护ROI = \frac{S_{\text{节省}} \times T_{\text{运行天数}}}{C_{\text{硬件}} + C_{\text{开发维护}}}
通俗理解：分子是系统省下的真金白银，分母是建港口的投入；比值大于 1，项目才值得推广。
  1. 节省成本 S自动化质检、监控等功能每天带来的人力节省。
    S节省=每日人力成本降低S_{\text{节省}} = \text{每日人力成本降低}
  2. 运行天数 T系统计划服役的时间周期。
    T运行天数=生命周期T_{\text{运行天数}} = \text{生命周期}
  3. 总投入 C包括工控机采购、OpenVINO 集成和长期运维的总支出。
    C总=C硬件+C开发维护C_{\text{总}} = C_{\text{硬件}} + C_{\text{开发维护}}

AI 应用场景

工业质检：工控机上的缺陷检测

阶段：模型部署与推理优化

解决的问题：传统方案把图片传到 GPU 服务器检测，网络延迟高、数据隐私风险大；改用 Intel 工控机后，必须让模型在本地 CPU 上跑出足够快的速度。

具体案例：某电子制造厂用 OpenVINO 将 YOLO 缺陷检测模型转为 IR，在工控机上以 batch=8 执行推理，并开启 THROUGHPUT 模式，最终达到产线要求的 30 FPS。模型更新时只需替换 IR，业务进程平滑重启即可。

智慧零售：边缘盒子里的客流统计

阶段：模型转换与多设备适配

解决的问题：门店场景设备型号复杂，有 CPU 盒子也有带集成 GPU 的迷你主机，传统方式需要为每种硬件单独编译。

具体案例：服务商使用 ONNX 训练目标检测模型，再用 MO 转成 IR，通过 AUTO 插件自动选择 CPU 或 GPU。容器化部署后，所有门店镜像一致，运维只需按设备下发配置。

安防监控：多路视频流的并行推理

阶段：性能调优与低功耗部署

解决的问题：NVR 设备需要同时分析多路摄像头画面，单纯加大 CPU 使用率会导致整体卡顿，需要更高效地调度算力。

具体案例：某安防项目将人脸检测模型转为 IR，利用 VPU 插件承接视觉任务，并通过异步推理与多流模式，让 16 路视频流稳定保持在 25 FPS，单路功耗大幅下降。

Python 演示

python45 行
import timeimport numpy as np  class MiniMO:    """模拟 OpenVINO 模型优化器，把权重包装成 IR 文件。"""     def convert(self, weights, xml_path, bin_path):        weights.astype(np.float32).tofile(bin_path)        with open(xml_path, 'w') as f:            f.write('<ir name="mini" weights_size="%d" />\n' % weights.nbytes)        print('[MO] 已生成 %s 和 %s' % (xml_path, bin_path))  class MiniIE:    """模拟 OpenVINO 推理引擎，读取 IR 并执行矩阵乘法。"""     def __init__(self, xml_path, bin_path):        self.W = np.fromfile(bin_path, dtype=np.float32).reshape(4, 4)     def infer(self, x):        return x @ self.W  def measure_throughput(ie, batch):    x = np.random.randn(batch, 4).astype(np.float32)    start = time.perf_counter()    for _ in range(50):        ie.infer(x)    elapsed = (time.perf_counter() - start) / 50    return batch * 1000.0 / elapsed  def main():    w = np.random.randn(4, 4).astype(np.float32)    mo = MiniMO()    mo.convert(w, 'demo.xml', 'demo.bin')    ie = MiniIE('demo.xml', 'demo.bin')    for batch in [1, 8, 32]:        qps = measure_throughput(ie, batch)        print('batch=%2d  throughput=%.1f it/s' % (batch, qps))  if __name__ == '__main__':    main()
目的：模拟 OpenVINO 模型优化器与推理引擎的完整链路，并比较不同批处理大小对吞吐量的影响。
  1. weights.astype(np.float32).tofile(bin_path)把权重以 FP32 二进制写入 .bin，模拟 MO 生成 IR 权重文件。
  2. open(xml_path, 'w')写入极简 XML 描述文件，模拟 .xml 结构文件。
  3. np.fromfile(bin_path, dtype=np.float32).reshape(4, 4)读取 .bin 还原权重，模拟 IE 加载 IR。
  4. ie.infer(x)执行矩阵乘法，模拟一次前向推理输出。
  5. batch * 1000.0 / elapsed按吞吐公式把单次毫秒延迟换算为每秒样本数。
  6. for batch in [1, 8, 32]对比不同批大小，对应正文中的性能调优策略。

常见误区

误区我以为 OpenVINO 是 Intel 出的，肯定只能跑 Intel 自己的模型，别的框架根本转不了。

正解模型优化器恰恰是为“跨框架”设计的，支持 TensorFlow、ONNX、Caffe 等；PyTorch 模型先导出为 ONNX 再转换即可。就像海关打包楼接受各国货物，只认统一集装箱。某些冷门算子可能不支持，但常见视觉模型基本都能转。

为何常见：看到“Intel 官方工具”就容易联想起封闭生态，忽略了 OpenVINO 对开放模型格式的兼容。

误区模型只要经过 OpenVINO 优化器转换，精度就会掉一截，所以不敢用。

正解默认 FP32 转换几乎无损；FP16 只是缩小了权重数值范围，大多数视觉任务差异可忽略。真正的精度风险来自 INT8 量化，需要校准集调优。集装箱运输虽然换了包装，但货物本身没变，只有换更轻的材质才可能影响强度。

为何常见：很多教程强调“转换后更小更快”，让人误以为转换过程做了有损压缩。

误区我看到的教程都是 `device='CPU'`，就觉得 OpenVINO 是 CPU 专用工具。

正解OpenVINO 插件机制覆盖 CPU、集成 GPU、VPU，还能用 AUTO 自动选择设备。CPU 适合通用场景，GPU 适合并行计算，VPU 适合低功耗视觉任务。同一份 IR 可以跨设备部署，就像同一个集装箱能吊装到不同泊位。

为何常见：Intel 的 CPU 最常见，教程示例多以 CPU 演示，容易忽略其他插件。

误区既然批量可以提高吞吐，那就把 batch 调到最大，反正机器能跑。

正解batch 过大会导致延迟飙升、内存不足，而且边缘设备算力有限，存在边际收益递减。正确做法是结合性能模式、线程数、CPU 绑定和业务延迟要求找到平衡点。港口不是一次吊起的货越多越好，还要考虑吊机承载上限。

为何常见：调优时容易凭“越多越好”的直觉，缺少对延迟和内存瓶颈的建模。

面试题

Q1. OpenVINO 中负责将训练好的模型转换为统一中间表示（IR）的组件是？

单选题 · easy

  • A.模型优化器← 正确答案
  • B.推理引擎
  • C.设备插件
  • D.数据加载器

答案：A。模型优化器（MO）负责离线转换，把不同框架模型变成 IR；推理引擎负责在线推理，设备插件负责硬件适配。就像报关单由打包楼填写，调度塔只负责指挥吊装。

Q2. OpenVINO 的 IR 文件通常由哪两个文件组成？

单选题 · easy

  • A..xml 和 .bin← 正确答案
  • B..py 和 .json
  • C..h5 和 .pb
  • D..onnx 和 .caffemodel

答案：A。IR 由描述网络结构的 .xml 和保存权重的 .bin 组成，二者缺一不可。其他选项分别是 Python、Keras、TensorFlow 或源框架格式，不是 OpenVINO 的标准中间表示。

Q3. 以下哪个 API 顺序是正确的 OpenVINO 推理调用流程？

单选题 · mid

  • A.Core->read_model->compile_model← 正确答案
  • B.Core->compile_model->read_model
  • C.read_model->infer->create_request
  • D.compile_model->infer->read_model

答案：A。正确顺序是先创建 Core，再读取 IR，最后编译到设备。编译之后才能创建推理请求并执行。顺序错了就像先吊货再报关，港口流程必然乱套。

Q4. 在 OpenVINO CPU 上提升吞吐量，下列哪项最有效？

单选题 · mid

  • A.调低 batch size
  • B.开启 THROUGHPUT 模式← 正确答案
  • C.禁用所有线程
  • D.使用 FP64 精度

答案：B。THROUGHPUT 模式会让 OpenVINO 采用多流并行的优化策略，直接提升每秒处理量。调低 batch、禁线程、用 FP64 都会降低吞吐，属于反向操作。

Q5. --data_type FP16 转换后，权重内存约为 FP32 的多少？

单选题 · mid

  • A.四分之一
  • B.二分之一← 正确答案
  • C.两倍
  • D.保持不变

答案：B。FP32 每个权重占 4 字节，FP16 占 2 字节，因此内存约为原来一半。这不是压缩算法，而是用更低精度存储，满足边缘设备有限的内存预算。

Q6. 异步推理对比同步推理，主要收益是？

单选题 · hard

  • A.减少单次时延
  • B.提高整体吞吐← 正确答案
  • C.缩小模型体积
  • D.降低硬件成本

答案：B。异步推理让预处理、计算、后处理重叠执行，能在单位时间内完成更多任务，本质是提高吞吐。它不一定减少单次延迟，也不改变模型体积和硬件成本。

Q7. OpenVINO AUTO 插件的主要作用是？

单选题 · mid

  • A.自动转换模型格式
  • B.自动选择计算设备← 正确答案
  • C.自动标注训练数据
  • D.自动生成可视化

答案：B。AUTO 插件会根据可用硬件和性能表现自动选择 CPU、GPU 或 VPU 等设备。转换模型是 MO 的职责，标注数据、可视化都与推理插件无关。

Q8. 下列哪些设备可作为 OpenVINO 推理后端？

多选题 · easy

  • A.Intel CPU← 正确答案
  • B.Intel 集成 GPU← 正确答案
  • C.Intel VPU← 正确答案
  • D.NVIDIA CUDA 核心

答案：ABC。OpenVINO 专注于 Intel 硬件生态，支持 CPU、集成 GPU 和 VPU。NVIDIA CUDA 核心不属于 OpenVINO 官方后端，需要其他工具链支持。

Q9. 以下哪些模型可以交给 OpenVINO 模型优化器？

多选题 · mid

  • A.TensorFlow SavedModel← 正确答案
  • B.ONNX 导出模型← 正确答案
  • C.PyTorch 的 .pt 原文件
  • D.Caffe 模型文件← 正确答案

答案：ABD。MO 直接支持 TensorFlow、ONNX、Caffe 等格式。PyTorch 的 .pt 原生格式不能直接转换，需要先导出为 ONNX，因此选项 C 不正确。

Q10. 以下哪些属于 OpenVINO 性能调优手段？

多选题 · hard

  • A.使用模型缓存目录← 正确答案
  • B.设置批处理大小← 正确答案
  • C.绑定 CPU 线程核心← 正确答案
  • D.把输入通道数随意改大

答案：ABC。模型缓存能复用编译结果，批处理和 CPU 绑定可提升并行效率；输入通道数由模型结构决定，随意改大会导致维度不匹配，不是合法调优手段。