EP选择策略：AI执行提供者

可视化演示

交互式展示ONNX Runtime执行提供者(EP)选择机制：路由模式展示算子如何分配到CUDA/TensorRT/CPU等EP执行，性能模式对比各EP的推理延迟和吞吐量，切换模式查看EP回退策略与混合执行。

EP机制认知：分派单背后的规则

调度中心墙上贴着一张巨大的城市送货路线图，每条街、每个路口都画得清清楚楚。你手下有十几支车队，但每一支车队能跑的路段各不相同：有的只上高速，有的只能在老城区小巷里穿行。每天收到新包裹时，你的第一项工作不是急着发车，而是对着路线图做“路段切分”——把一整条送货路线拆成一段段，再标注每段路适合哪支车队。

这就是 ONNX Runtime 里 EP 机制的核心。模型被表示成一张计算图（Computation Graph），每个运算（卷积、矩阵乘法、激活函数）就像路线图上的一个路段节点。ONNX Runtime 负责把整张计算图切分成若干子图，然后为每个子图分配一个执行提供者——也就是一段路的承运车队。这个“切分 + 分配”的过程叫作图分区（Graph Partitioning），它是整个 EP 机制的地基。

在实际代码里，我们创建推理会话（InferenceSession）时传入 providers 参数，列表的顺序就是车队的优先级：排得越靠前的 EP 越先承接子图，剩下的算子自动交给 CPU 兜底。比如 providers=['TensorrtExecutionProvider', 'CUDAExecutionProvider', 'CPUExecutionProvider']，表示优先让 TensorRT 接单，接不了的路段给 CUDA，最后剩余路段全部交给 CPU。会话注册 API 就是这张派单表的填写入口。

这张派单表一旦确定，调度中心就按表发车：能上高速的绝不堵在小巷，能抄近道的绝不绕远路。而你要做的，就是把这张派单表排得足够聪明——这正是后面几节要讲的选车学问。

主流EP盘点：认识你的四支车队

你手下的车队各有性格。第一支是 NVIDIA 专属的“高速电车车队”（CUDA），只要显卡是 N 家的，它就能把大部分路段跑得飞快；第二支是“赛道改装车队”（TensorRT），同样只服务 NVIDIA 显卡，但经过深度调校，能把弯道、坡道都优化到极致；第三支是“苹果园区小三轮”（CoreML），在 iPhone、Mac 上灵巧穿梭；第四支是“Windows 全地形越野车”（DirectML），不挑路况，只要是 Windows 系统的显卡它都能跑。

对应到 ONNX Runtime，这四个名字分别是 CUDAExecutionProvider、TensorrtExecutionProvider、CoreMLExecutionProvider、DirectMLExecutionProvider。每一个 EP 都是一个独立的执行后端，它实现了针对特定硬件优化过的算子内核，把 ONNX 模型的计算真正映射到硬件上跑起来。它们的存在让“一份模型，多端运行”成为可能。

四种 EP 的定位差异很大：CUDA EP 覆盖面广、上手快，是 NVIDIA GPU 上的通用选择；TensorRT EP 在 CUDA 基础上做了层融合、内核自动调优、FP16/INT8 量化，推理延迟通常最低，但构建引擎需要额外时间，算子兼容范围也更严格；CoreML EP 在苹果生态内调用神经引擎（ANE）和 GPU，是 iOS/macOS 部署的首选；DirectML 是 Windows 平台上跨厂商（NVIDIA/AMD/Intel）的通用方案，兼容性最强，但单点性能通常不如专属 EP。

四支车队各有所长，但要在实战中选谁，不能听销售吹牛，得拉出来实际跑一跑、测一测——这正是调度总监的“赛车计时器”要做的事。

性能对比基准：给车队掐秒表

车队到底谁快，调度总监从不听宣传册，而是亲自拿秒表在封闭路段计时。同一批货、同一条路线，让每支车队分别跑一趟，记录送达时间；再让它们在高峰期连续跑一小时，数一数各自送了多少单。有了这些数字，选谁不选谁就有了底气。

在 AI 部署里，这个“掐秒表”就是基准测试（Benchmark）。两个最核心的指标是延迟（Latency）和吞吐量（Throughput）。延迟是单次推理从输入到输出的毫秒耗时，对应单趟送货时间；吞吐量是单位时间内能完成的推理次数（比如每秒处理多少张图片），对应高峰期的送货单量。

性能对比不能只看一两次数据，因为 GPU 有冷启动、CPU 有频率波动，单次测量噪声很大。行业惯例是先预热几次再计时，然后跑多轮取中位数或平均值。另外要区分同步推理和批量推理：批量推理把多张输入打包一起送，GPU 利用率更高、吞吐量显著提升，但单次延迟可能略有增加。加速比 S 是直观参考，但最终判断必须以真实业务负载的实测数据为准。

有了秒表数据，你就能把四支车队的能力画成一张对比表，谁适合单件快送、谁适合批量搬运，一目了然。但“快”不是唯一标准，接下来还得看任务本身的要求。

选择决策因素：调度决策手册

选车队不能只看快。如果客户的目的地在老城区，赛道改装车再快也进不去；如果客户要求货物不能颠簸（对精度敏感），那些爱抄近道、急刹车的车队就得慎重；如果客户现场连充电桩都没有，纯电车再环保也白搭。每个场景都有自己的约束条件。

对应到 EP 选择，四个核心决策因素是：硬件类型、算子支持度、精度要求、部署限制。硬件类型决定了可选 EP 的集合——NVIDIA 显卡才能用 CUDA/TensorRT，苹果设备才有 CoreML；算子支持度决定了模型能否完整交给某个 EP——如果某个算子不在 TensorRT 的实现清单里，相关子图就只能整体回退或换用 CUDA。

精度要求影响你能否启用 FP16/INT8 等低精度优化：TensorRT 的 INT8 需要专门的校准数据集，精度可能轻微下降，视觉模型尚且可接受，但在医疗、金融等场景必须谨慎评估。部署限制包括安装包体积、驱动依赖、离线环境等：TensorRT 引擎构建需要 GPU 环境，有些客户现场不允许；DirectML 则几乎没有额外依赖。实践中最科学的做法，是把这些维度量化打分、乘以权重后求和。

这份加权评分表，就是调度总监的“选车决策手册”。手册在手，任何新情况来了都能快速算出最优解。不过，最优方案也有临时掉链子的时候，应急预案同样不能少。

回退策略设计：应急预案不能少

再靠谱的车队也有抛锚的时候。某个暴雨天，赛道临时封闭，你立刻掏出应急预案：能跑的路段继续让改装车送，被封的路段马上转给高速电车，电车也进不去的小巷就交给三轮车队。整批货没有停摆，只是部分路段换了个承运方。

这就是 EP 的回退策略（Fallback）。ONNX Runtime 的图分区机制天然支持回退：当某个算子不被首选 EP 支持时，该算子连同它所在的子图会回退到下一个 EP，最终兜底的一定是 CPU。这个过程对上层业务完全透明，模型不会因此报错，但性能会有变化——回退比例越高，加速效果越差。

好的回退策略要分层设计：首选快 EP 承接大部分算子，第二优 EP 承接边缘算子，CPU 只兜底剩余部分。用 providers 列表的顺序就能控制回退层级。需要特别留意的是混合执行时的数据拷贝：GPU 上的算子输出要拷贝回 CPU，才能喂给 CPU 算子，这个拷贝开销在算子频繁交替时会显著拉高延迟。因此应当尽量让回退的子图保持连续，避免“快-慢-快”的碎片化切分。

应急预案的意义不是让每段路都跑得最快，而是让整批货稳妥送达。回退策略设计得越精细，模型在真实环境中的表现就越稳定。

最佳实践流程：调度总监的作战手册

一位成熟的调度总监不会等到客户投诉才调整方案，而是有一套固定作战流程：新车队引进后先试跑（基准测试），根据数据定排班（配置优化），运营中持续看监控（监控调优）。这套三步流程，是 EP 选型的通用方法论。

第一步，在目标硬件上用代表性模型和数据跑基准测试，得到各 EP 的延迟、吞吐量数据；第二步，结合决策因素选出最合适的 EP 组合，配置 providers 顺序和 SessionOptions 的图优化级别；第三步，上线后持续监控推理耗时和回退比例，定期复测模型版本与依赖更新带来的性能变化。

实际项目中有两个典型取舍：TensorRT 引擎构建时间长（几分钟到十几分钟），适合服务器端长期驻留的场景，模型频繁更新时 CUDA EP 的部署成本更低；移动端优先选择 CoreML，但要处理模型转换时的算子兼容问题。每一次优化调整，都应当记录基准数据，用可量化的收益说话，而不是凭感觉拍脑袋。

三步流程走下来，你的调度中心就形成了一套可复制的选车方法论。每次新模型进门，不再手忙脚乱，而是胸有成竹地翻开数据、排好车队、持续跟进。

AI 应用场景

Python 演示

import timeimport numpy as npimport onnxruntime as ort  def probe_providers(model_path, input_data, runs=20):    """探测可用 EP 并对比推理延迟"""    available = ort.get_available_providers()    print('本机可用执行提供者:', available)     # 按优先级排列候选 EP, 只保留当前环境支持的    preference = [        'TensorrtExecutionProvider',        'CUDAExecutionProvider',        'CoreMLExecutionProvider',        'DirectMLExecutionProvider',        'CPUExecutionProvider',    ]    candidates = [ep for ep in preference if ep in available]    if not candidates:        candidates = available     session_options = ort.SessionOptions()    session_options.graph_optimization_level = (        ort.GraphOptimizationLevel.ORT_ENABLE_ALL    )     results = {}    for ep in candidates:        providers = [ep]        if ep != 'CPUExecutionProvider':            providers.append('CPUExecutionProvider')        session = ort.InferenceSession(model_path, session_options,                                       providers=providers)        feed = {session.get_inputs()[0].name: input_data}        # 预热 5 次, 让 GPU 完成初始化        for _ in range(5):            session.run(None, feed)        times = []        for _ in range(runs):            t0 = time.perf_counter()            session.run(None, feed)            times.append((time.perf_counter() - t0) * 1000)        results[ep] = float(np.median(times))        print('  {}: {:.2f} ms'.format(ep, results[ep]))     best = min(results, key=results.get)    cpu_ms = results.get('CPUExecutionProvider', max(results.values()))    speedup = cpu_ms / results[best]    print('推荐 EP: {}, 相对 CPU 加速比: {:.1f}x'.format(best, speedup))    return best  if __name__ == '__main__':    # 将 model.onnx 替换为你自己的模型文件    dummy_input = np.random.rand(1, 3, 224, 224).astype(np.float32)    probe_providers('model.onnx', dummy_input)

1. available = ort.get_available_providers()探测本机装了哪些“车队”（EP）。
2. candidates = [ep for ep in preference if ep in available]按优先级过滤出当前环境真正可用的 EP。
3. session_options.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL开启全量图优化，让模型先被 ORT 优化一遍。
4. providers.append('CPUExecutionProvider')给每个被测 EP 配上 CPU 兜底，避免算子不支持时直接报错。
5. for _ in range(5): session.run(None, feed)预热 5 次，让 GPU 完成初始化，避免首次推理的冷启动噪声。
6. results[ep] = float(np.median(times))取多轮延迟的中位数，抗抖动、更稳健。
7. best = min(results, key=results.get)选出延迟最低的 EP，相当于把“秒表冠军”挑出来。
8. cpu_ms / results[best]用 CPU 延迟除以最优 EP 延迟，得到加速比。

常见误区

面试题