3. 边缘AI推理软件栈总览
在Ryzen Embedded平台上部署边缘AI推理，软件栈的选择往往比模型本身更影响最终能否落地。同一颗APU，用不同推理框架跑同一个YOLOv8n模型，端到端延迟可能相差2～3倍，内存占用也可能相差数百MB。本节先把四条主流路线——ROCm、OpenVINO、ONNX Runtime、DirectML——在Ryzen Embedded上的支持边界讲清楚，再给出可操作的选型依据。
四条路线各自“吃”什么硬件
Ryzen Embedded（如V2000、V3000、8000系列）内部集成了CPU（Zen核心）、GPU（RDNA或Vega）、以及部分型号的NPU（XDNA）。四条软件栈对这三类计算单元的覆盖并不一致：
- ROCm：AMD自家的开源计算平台，面向GPU的HIP编程与MIOpen库。在Ryzen Embedded上，ROCm对集显的支持长期受限——官方支持列表主要覆盖Instinct与部分Radeon独显，嵌入式APU的gfx目标（如gfx90c、gfx1033）常需自行编译或依赖社区补丁。适合需要自定义算子、做底层优化的团队。
- OpenVINO：Intel主导的推理工具链，但通过其“GPU插件”可借助OpenCL在AMD GPU上运行，CPU插件则对x86通用。在Ryzen Embedded上，OpenVINO的CPU路径最稳，GPU路径依赖驱动与OpenCL运行时，性能不如在Intel核显上理想。优势是模型优化器（MO）与NNCF量化工具链成熟。
- ONNX Runtime：跨厂商的推理运行时，提供CPU EP、DirectML EP、ROCm EP、OpenVINO EP等多种执行提供器。在Ryzen Embedded上，ONNX Runtime是“一个接口、多种后端”的折中方案，切换EP只需改一行代码，非常适合做框架对比与快速验证。
- DirectML：微软的DirectX 12计算后端，通过ONNX Runtime的DML EP或Windows ML调用。它不依赖厂商专属SDK，只要驱动支持D3D12即可，因此在Ryzen Embedded的Windows IoT版本上兼容性最好，但Linux下不可用。
支持矩阵与关键约束
把上述关系整理成一张支持矩阵，能快速看出每条路线的“可用性”与“代价”。下表为基于公开文档与常见工程经验的归纳，具体版本请以实际驱动与SDK发布说明为准。
| 软件栈 | CPU支持 | GPU支持 | NPU支持 | 操作系统 | 典型适用场景 |
|---|---|---|---|---|---|
| ROCm | 不涉及 | 有限/需适配 | 否 | Linux为主 | 自定义算子、底层优化 |
| OpenVINO | 好 | 通过OpenCL，一般 | 否 | Linux/Windows | Intel生态迁移、量化部署 |
| ONNX Runtime | 好 | ROCm EP/DML EP | 否 | Linux/Windows | 多后端对比、快速验证 |
| DirectML | 不涉及 | 好（D3D12） | 否 | Windows | Windows IoT、免厂商SDK |
需要特别注意的是：Ryzen Embedded上的NPU目前尚未被这四条主流栈直接统一支持，若项目必须用NPU，通常要走AMD Ryzen AI软件栈（基于ONNX Runtime的Vitis AI EP或专用工具链），这属于另一条路线，本节不展开。
选型依据：从约束反推框架
选型不是比“谁性能高”，而是先锁定不可妥协的约束，再在剩余选项里比较。建议按以下顺序判断：
- 操作系统是否已定？ 若必须用Windows IoT，DirectML与ONNX Runtime(DML EP)是首选；若用Linux，ROCm与ONNX Runtime(ROCm EP)才有意义，OpenVINO的CPU路径也可用。
- 是否必须用GPU？ 若模型算力需求大、CPU推理延迟不达标，则优先考虑GPU路径。Windows下选DirectML，Linux下选ROCm或ONNX Runtime的ROCm EP。
- 团队是否已有框架积累？ 已有OpenVINO模型与量化流程的团队，迁移到Ryzen Embedded时优先保留OpenVINO CPU路径，避免重做量化校准。
- 是否需要多后端对比？ 若处于选型验证阶段，用ONNX Runtime统一接口，分别切换CPU EP、DML EP、ROCm EP跑同一ONNX模型，是最省事的对比方式。
一个可复现的对比验证示例
下面给出一个在Ryzen Embedded V3000 + Windows IoT上，用ONNX Runtime对比CPU EP与DirectML EP的最小验证流程。示例参数为教学假设，实际数值请以你的板卡与模型为准。
# 1. 准备环境（示例）
pip install onnxruntime onnxruntime-directml numpy
# 2. 导出或获取一个ONNX模型，例如 yolov8n.onnx
# 输入: images [1,3,640,640] float32
# 输出: output0 [1,84,8400]
# 3. 对比脚本 compare_ep.py
import onnxruntime as ort
import numpy as np, time
model = "yolov8n.onnx"
x = np.random.rand(1,3,640,640).astype(np.float32)
for ep in ["CPUExecutionProvider", "DmlExecutionProvider"]:
sess = ort.InferenceSession(model, providers=[ep])
# 预热
for _ in range(5):
sess.run(None, {"images": x})
t0 = time.perf_counter()
for _ in range(50):
sess.run(None, {"images": x})
dt = (time.perf_counter() - t0) / 50 * 1000
print(f"{ep}: {dt:.2f} ms/帧")
运行后你会得到两个数字。判断依据不是“谁快就用谁”，而是：若DML EP比CPU EP快不到20%，而CPU EP的功耗与散热更可控，则CPU路径可能更合适；若DML EP显著更快且GPU占用率未饱和，则优先GPU。同时观察任务管理器中的GPU显存占用，若接近上限则需降低batch或输入分辨率。
选型决策图
把上述判断逻辑画成一张决策图，便于在项目初期快速定位候选框架。图中从操作系统出发，经过“是否必须GPU”“是否有既有工具链”两个关键分叉，最终落到推荐栈。
这张图的价值在于把“选型”从主观偏好变成可执行的判断路径。实际项目中，建议在锁定框架后，把ONNX Runtime、驱动、SDK的版本号一并写入部署清单，因为边缘设备一旦量产，版本漂移带来的兼容性问题往往比性能差异更难排查。
总结来说，四条路线没有绝对优劣：ROCm适合愿意投入底层优化的团队，OpenVINO适合已有Intel工具链积累的项目，ONNX Runtime适合需要多后端对比与快速验证的场景，DirectML适合Windows IoT且不想引入厂商专属SDK的部署。选型的核心是先锁定操作系统与是否必须用GPU这两个硬约束，再用目标板实测数据做最终决策。