执行提供者：ROCm Provider

可视化演示

通过EP架构、算子映射与显存池机制，直观展示ONNX Runtime借助ROCm平台在AMD GPU上的推理加速。

EP 基本概念

ORT 集团的瑞士总部最清楚一件事：再完美的流程图，也得有人在地面上把它干出来。于是总部设计了「执行提供者」制度——每一项任务（算子）最终由哪个本地团队执行，都在这个框架下决定。本地团队不必关心总部如何制定流程，总部也不必关心每个国家的砂石水泥——这种双向解耦，就是执行提供者的核心价值。

把目光落到技术上：ONNX Runtime 是一个跨平台推理引擎，它接收 ONNX 格式的模型（即一张计算图），然后交给不同的后端执行。这个「后端」在 ORT 中就叫 Execution Provider。每个 EP 实现统一的接口，负责把图上的算子映射到自己的硬件上。CPU EP 是哪里都能干的通用后勤队，CUDA EP 是 NVIDIA 领地的精英队，而 ROCm Provider 则是 AMD 领地的王牌队。

EP 采用插件化机制，多个 EP 可以在同一个会话中共存。ORT 为每个算子挑选「最合适」的 EP：优先队列里排在前面的 EP 先尝试，若某个算子不支持，就自动落到下一个 EP。这就像一个跨国项目同时雇佣了好几家本地承包商，各家的专长不同，总部按任务类型和优先级灵活分派。

$$\text{Execute}(op_i) = \text{EP}_j(op_i), \quad \text{EP}_j \in \{ \text{CPU},\ \text{CUDA},\ \text{ROCm} \}$$

1. 算子任务 \(op_i\)：计算图中编号为 \(i\) 的算子，是流程表里的一个具体任务步骤。

$$\text{op}_i$$

2. 执行函数 Execute：ORT 集团决定「这个任务由谁来干」的调度器。

$$\text{Execute}(\cdot)$$

3. EP 接管：把第 \(j\) 个执行提供者套在算子上，表示任务被交给第 \(j\) 个本地团队。

$$\text{EP}_j(\text{op}_i)$$

4. 候选集合：EP 的候选范围，通常包括 CPU 兜底、NVIDIA 的 CUDA 和 AMD 的 ROCm。

$$\text{EP}_j \in \{ \text{CPU},\ \text{CUDA},\ \text{ROCm} \}$$

这套机制的妙处在于：模型作者只面对 ONNX 这一套「国际标准流程」，完全不用关心 AMD 还是 NVIDIA；而各家 EP 团队专注把自己的硬件潜能榨干。就像总部只管下发通用流程，巴黎团队和东京团队各自优化本地的执行细节，最终交付的成品质量都由 ORT 统一验收。

ROCm 平台基础

AMD 团队再厉害，也离不开当地的基础设施。AMD GPU 的领地里，这套基础设施有一个总名字——ROCm。它是 AMD 开源的 GPU 计算平台，相当于「AMD 版 CUDA」：既提供编程语言（HIP）、编译器，也提供 runtime、驱动和性能工具，是 ROCm Provider 赖以生存的水电管网。

ROCm 中的 HIP 编程框架是一套「官方方言」，程序员可以用它写出同时兼容 NVIDIA 与 AMD 的代码；编译器负责把 HIP 代码翻译成 AMD GPU 能执行的机器指令；runtime 与驱动则负责运行时调度、显存管理和设备交互；再往上还有 rocprof、rocm-smi 等体检工具，帮工程师测量 GPU 温度、利用率与 kernel 耗时。

如果把 ROCm 的层次拆开看，可以这样理解它：

$$\text{ROCm Stack} = \underbrace{\text{HIP}}_{\text{语言}} + \underbrace{\text{Compiler}}_{\text{翻译}} + \underbrace{\text{Runtime}}_{\text{调度}} + \underbrace{\text{Tools}}_{\text{体检}}$$

1. ROCm Stack：AMD 领地的全套公共基础设施，统称 ROCm 软件栈。

$$\text{ROCm Stack}$$

2. HIP 语言：当地官方语言，一种可移植的 C++ 风格 GPU 编程框架。

$$\text{HIP}$$

3. 编译与调度：编译器和运行时配合，把代码转译成 GPU 指令并排队上卡执行。

$$\text{Compiler} + \text{Runtime}$$

4. 性能工具：工程验收用的体检设备，用于定位瓶颈与验证加速效果。

$$\text{Tools}$$

ROCm Provider 正是踩在 ROCm 平台之上的「土著团队」。没有这层水电管网，EP 就是巧妇难为无米之炊。我们可以这样对比：CUDA 是 NVIDIA 封闭自建的豪华园区，而 ROCm 是 AMD 开源共建的公共新区——基础设施架构不同，但目的都是一样的：让 GPU 高效跑起来。

算子映射机制

总部下发的流程图里包含几百项任务，AMD 团队拿到手后的第一件事，就是逐项核对「这活儿我能不能干、要怎么干」。这个过程在技术上叫算子映射：把 ONNX 标准算子对应到 ROCm 平台上具体可执行的 kernel（内核程序）。

ORT 内部维护着一张「算子注册表」，相当于团队的能力清单表。每个 EP 会声明自己支持哪些算子、每个算子支持哪些数据类型和版本。当模型加载时，ORT 遍历计算图，通过这张表给每个算子匹配 EP；遇到 ROCm EP 不支持的算子，就自动回退到 CPU EP，避免整个任务卡死。这便是多团队协作的兜底机制。

除了逐算子匹配，EP 还会做图编译优化：把相邻的多个算子合并成一个融合算子，减少 kernel 启动次数和数据搬移；把 NCHW 布局转换成 ROCm 更高效的 NHWC 布局。这些操作就像本地团队把「搬砖—砌墙—抹灰」三个工序合并成一支队伍一口气干完，省去中间交接时间。

$$\mathcal{M}: \text{Op}_{\text{ONNX}} \xrightarrow{\text{MIOpen}} \text{Kernel}_{\text{ROCm}}$$

1. ONNX 算子：总部标准流程表中的任务类型，比如卷积、矩阵乘法、归一化。

$$\text{Op}_{\text{ONNX}}$$

2. 映射函数：AMD 团队的分工决策器，把每个标准任务指派成具体环节。

$$\mathcal{M}: \cdot \mapsto \cdot$$

3. MIOpen 加速：常见任务直接查速查手册，由 MIOpen 提供预制的高效内核。

$$\xrightarrow{\text{MIOpen}}$$

4. ROCm 内核：最终在 AMD GPU 上执行的程序片段，也就是落地后的具体工序。

$$\text{Kernel}_{\text{ROCm}}$$

这套映射机制决定了加速的上限：能被 ROCm EP「认领」的算子越多，GPU 参与度越高，整体就越快；无法认领的算子则落到 CPU 上，形成整个流程里相对较慢的环节。就像团队里某些特殊工种必须外包，外包越多，整体工期就越不可控。

MIOpen 加速库

AMD 团队手里有一本厚厚的「常用任务速查手册」——这就是 MIOpen，AMD 官方的深度学习加速库。它专门为 GPU 上的常见算子提供高度优化的实现，尤其是卷积、池化、归一化、RNN 这类神经网络里的高频操作。ROCm Provider 在映射算子时，会优先查这本手册，而不是现场即兴写 kernel。

为什么手册里的方案更快？因为 MIOpen 针对不同 AMD GPU 架构（如 CDNA、RDNA）预先实现了多种算法变体，并内置自动调优机制：在首次调用某个算子时，它会自动运行若干候选算法、逐一计时，选出当前 GPU 上最快的那一个，并把结果缓存下来。这相当于本地老师傅拿着秒表，把从仓库到工地的几条路线都走一遍，然后记住最短路。

MIOpen 还负责内存管理：通过缓存分配器复用显存块，减少反复申请释放的开销。对 ROCm Provider 而言，MIOpen 就是最核心的加速引擎，卷积类算子的绝大多数性能优势都来自这本手册。

$$S = \frac{T_{\text{baseline}}}{T_{\text{MIOpen}}}$$

1. 普通基线耗时：不用手册、现场写通用实现所需的总时间。

$$T_{\text{baseline}}$$

2. MIOpen 耗时：查手册使用预制优化方案所需的总时间。

$$T_{\text{MIOpen}}$$

3. 相除求比值：两者相除得到加速比，衡量手册的「含金量」。

$$S = \frac{T_{\text{baseline}}}{T_{\text{MIOpen}}}$$

MIOpen 的自动调优第一次运行会多花一些时间，但之后就会把最优方案缓存下来，后续推理直接走捷径。前面动画里那些落入 ROCm EP 的绿色小球，之所以比紫色小球跑得更顺畅，靠的就是这本手册在背后发力。

推理部署流程

新店开张，AMD 团队要完整走一遍「接单—备料—施工—验收」的流程。在 ONNX Runtime 中启用 ROCm Provider 也一样：创建推理会话、配置会话选项、指定 providers 优先级、加载模型、运行推理、验证性能。

首先，模型文件通过 InferenceSession 加载，ORT 会解析 ONNX 模型并构建计算图。然后进入图优化阶段：ORT 可以执行常量折叠、算子融合等优化；如果配置了 optimized_model_filepath，还会把优化后的模型导出，方便下次直接加载。随后是 EP 分配：ORT 根据用户传入的 providers 顺序，把每个算子分派给首个支持的 EP——我们把 "ROCmExecutionProvider" 放在最前，CPU 殿后兜底。

设备分配策略也很关键：输入数据是 CPU 侧的内存，要送入 GPU 就需要先拷贝到显存；推理结束后，输出又要拷回主机。数据搬运的时长被计入端到端延迟。因此，实际工程中常通过「热身运行」让显存池与调优缓存先就绪，再开始正式计时，得到更接近稳态的推理性能数据。

$$T_{\text{total}} = T_{\text{parse}} + T_{\text{opt}} + T_{\text{exec}} + T_{\text{copy}}$$

1. 模型解析耗时：接单后拆解流程表（解析 ONNX 模型结构）的耗时。

$$T_{\text{parse}}$$

2. 图优化耗时：流程编排优化（算子融合、布局转换）的耗时。

$$T_{\text{opt}}$$

3. 执行耗时：真正在 ROCm EP 上执行算子的 GPU 计算耗时。

$$T_{\text{exec}}$$

4. 拷贝耗时：输入输出数据在主机内存与 GPU 显存间搬运的耗时。

$$T_{\text{copy}}$$

部署完成后，工程师通常会对比 CPU EP 与 ROCm EP 的延迟，验证加速比是否达标。值得提醒的是：小模型或 IO 密集场景下，数据拷贝与 kernel 启动开销可能压倒计算收益，这时 GPU 未必比 CPU 快。所以部署流程的最后一步永远是「实测验收」，而不是拍脑袋。

AMD 生态优势

ROCm Provider 之所以是 AMD 平台的首选方案，不只是因为它自带 MIOpen，更因为它身处整个 AMD 生态的中心。AMD 选择了开源路线：ROCm 的多个核心组件在 GitHub 上公开维护，开发者可以查看源码、提交 issue、参与贡献。相比闭源的 CUDA 生态，这更像一座透明开放的公共园区。

原生代码路径是另一大优势：ROCm Provider 不经过任何转译或兼容层，直接调用 ROCm 底层的 HIP 与 MIOpen 接口，避免了中间翻译的开销。随着 AMD 持续迭代 ROCm 版本，EP 也会同步升级算子支持列表、引入新的图优化策略，让老模型在新生代 GPU 上继续受益。

选型建议可以这样概括：如果企业的推理服务器选用 AMD GPU，ROCm Provider 就是第一选择；如果模型算子覆盖率高、计算密集，加速收益尤其明显；如果模型非常小或算子很冷门，则要结合 CPU EP 兜底策略综合评估。

$$\text{Coverage} = \frac{|\{ op \in \text{模型} : op \in \text{EP 支持表} \}|}{|\{ op \in \text{模型} \}|}$$

1. 分子——被支持算子数：模型中能被 ROCm EP 直接认领的算子总个数。

$$|\{ op \in \text{模型} : op \in \text{EP 支持表} \}|$$

2. 分母——全部算子数：模型中所有算子的总个数。

$$|\{ op \in \text{模型} \}|$$

3. 覆盖率比值：两者相除，得到 0 到 1 之间的覆盖率数值。

$$\text{Coverage} = \frac{\text{支持数}}{\text{总数}}$$

把 ROCm Provider 放在 AMD 生态的大棋盘上看：它是 ONNX Runtime 与 AMD GPU 之间最短的那座桥。桥面越宽（算子覆盖越全）、桥墩越稳（ROCm 平台越成熟），模型在 AMD 上跑得就越快。对于 AI 基础设施工程师来说，理解这座桥的建造原理，才能在 AMD 平台上做出有底气的部署决策。

AI 应用场景

Python 演示

import onnxruntime as ortimport numpy as npimport time # 1. 检查当前环境可用的执行提供者print("可用 EP:", ort.get_available_providers()) # 2. 配置会话，打开全量图优化so = ort.SessionOptions()so.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALLso.optimized_model_filepath = "optimized_model.onnx" # 3. 创建会话：优先使用 ROCm EP，CPU 兜底sess = ort.InferenceSession(    "resnet50.onnx",    sess_options=so,    providers=["ROCmExecutionProvider", "CPUExecutionProvider"]) # 4. 构造模拟输入并热身input_name = sess.get_inputs()[0].namex = np.random.randn(1, 3, 224, 224).astype(np.float32)for _ in range(5):    sess.run(None, {input_name: x}) # 5. 正式计时，计算平均推理耗时t0 = time.perf_counter()for _ in range(50):    sess.run(None, {input_name: x})dt = (time.perf_counter() - t0) / 50print("平均推理耗时: {:.2f} ms".format(dt * 1000))

1. print("可用 EP:", ort.get_available_providers())打印当前环境支持哪些执行提供者，确认 ROCm 是否就位
2. so.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL开启全量图优化，让 ORT 做算子融合与布局优化
3. so.optimized_model_filepath = "optimized_model.onnx"导出优化后的模型，下次可直接复用
4. providers=["ROCmExecutionProvider", "CPUExecutionProvider"]把 ROCm EP 放在最前面，CPU EP 作为不支持算子的兜底
5. sess.get_inputs()[0].name获取模型的输入张量名，用于构造推理输入
6. np.random.randn(1, 3, 224, 224).astype(np.float32)生成一张符合 ResNet 输入的随机图片数据
7. for _ in range(5): sess.run(...)热身循环，触发 MIOpen 自动调优与显存池初始化
8. time.perf_counter()使用高精度计时器统计推理耗时
9. sess.run(None, {input_name: x})执行一次端到端推理，返回模型输出列表

常见误区

面试题