OpenVINO 在 Intel CPU 上性能不佳主因是模型导出与配置不当：需用 mo/ov.convert_model 转静态 shape 的 IR 模型，显式指定 input_shape，启用 PERFORMANCE_HINT= LATENCY，正确解析 ov.Output 输出，FP16 输出需转 float32，INT8 校准需匹配预处理并限制样本量。
OpenVINO 在 Intel CPU 上跑不比 PyTorch 快？
多数情况下，不是 OpenVINO 不行，而是模型没导出对、推理配置没关对。PyTorch 默认用 float32 + 动态 shape，OpenVINO 要的是静态 shape + int8/FP16 优化过的 IR 模型，直接拿 torch.jit.script 或 ONNX 模型扔进去，性能大概率倒退。
- 必须用
mo.convert_model（或ov.convert_model）重新转换，不能跳过中间 IR 步骤 - 输入 shape 必须显式指定，
input_shape=[1,3,224,224]这种写法在 CPU 推理时影响极大，动态 batch 会强制 fallback 到慢路径 - CPU 推理默认不开 AVX512 优化，得手动设
config={"PERFORMANCE_HINT": "LATENCY"}，否则可能走纯标量路径
用 ov.Core 加载模型后输出乱码或维度错？
OpenVINO 2023.3+ 的 Python API 改了输出解析逻辑：模型输出是 ov.Output 对象，不是 NumPy 数组；直接 print 会看到内存地址，取值必须调 tensor.data 或 ov.Tensor 显式拷贝。
- 别写
result = compiled_model(inputs)就完事——它返回的是 dict ofov.Output，要先output_port = list(result.keys())[0]，再result[output_port].data - 如果模型有多个输出（比如 YOLO 的 boxes + scores），
compiled_model.output(0)和compiled_model.output("boxes")行为不同：后者依赖模型里是否写了name属性，没写就报RuntimeError: No output with name 'boxes' - FP16 模型输出仍是
float16类型，NumPy 默认不识别，得先.astype(np.float32)再后续处理，否则 cv2.imshow 会黑屏
Intel GPU（iGPU）上 ov.compile_model 报 NOT_IMPLEMENTED？
不是驱动或 OpenVINO 版本问题，而是当前模型用了 iGPU 不支持的算子，比如 GroupNorm、SoftmaxV2 或某些自定义插件。OpenVINO 的 GPU plugin 不是全算子覆盖，尤其对较新的 PyTorch 1.13+ 导出的 ONNX。
- 先用
benchmark_app -m model.xml -d GPU -api async测，它会明确打出 unsupported ops 列表 - 换 backend：把
device="GPU"改成device="AUTO"，让 OpenVINO 自动 fallback 到 CPU + iGPU 混合，比纯 GPU 失败强 - 避免用
torch.export直接导 ONNX——它生成的 control flow op 太多，改用torch.onnx.export+opset_version=14更稳
INT8 量化后精度暴跌，但 pot 工具又卡在 calibration 阶段？
pot（Post-Training Optimization Tool）默认用 full dataset 做校准，但实际只需 100–200 张有代表性的图；更关键的是，它对预处理 pipeline 极其敏感——OpenVINO 的 preprocess 步骤和你训练时用的 torchvision.transforms 稍有差异（比如归一化顺序、BGR/RGB），就会导致校准统计失真。
立即学习“Python免费学习笔记（深入）”；
- 校准前务必确认：输入 tensor 是
uint8 [0,255]还是float32 [0,1]？pot默认按前者，而很多 PyTorch 模型导出 ONNX 时已做了归一化 - 用
--sample-size 128限制校准样本数，加--progress看进度，不然容易以为卡死 - 如果校准后 mAP 掉 >5%，别硬扛——回退到 FP16，Intel 第 12 代以后 CPU 上 FP16 推理吞吐只比 INT8 低 10%～15%，但稳定性高得多
真正卡住人的从来不是“能不能跑”，而是模型导出链路里哪一层悄悄改了数据 layout、哪一行 config 开关没对齐硬件能力。OpenVINO 的优化点很细，但每处都要求前后端严格契约一致——差一个 np.ascontiguousarray，就可能让 AVX 指令全部失效。
