ONNX Runtime 算子内核支持矩阵详解OperatorKernels.md 的生成机制、执行提供程序差异与源码级解析【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntimeOperatorKernels.md 是 ONNX Runtime 仓库中一张算子 × 执行提供程序Execution ProviderEP× OpSet 版本 × 数据类型的支持矩阵总表直接决定了某个模型在某条硬件路径上能不能跑、用哪种精度跑。本文以该文档为主体逐节解读其结构版本记号法、EP 章节、算子域分组结合 gen_opkernel_doc.py 的生成逻辑与 build.py 的 CI 流程还原这张表是如何从内核注册表中自动产出的并以 Clip、Cast、Gemm 等真实算子为线索对照 CPU 实现、CUDA 与 DML 的注册代码说明三个 EP 在类型覆盖上的关键差异如 CUDA 的 fp16/bf16 优先策略、DML 的 float/float16 限定与com.microsoft.dml专属融合算子域帮助你在选型 EP、排查算子不支持/类型不支持错误时快速定位依据。一、文档主体三个执行提供程序的算子支持总览OperatorKernels.md 的目录部分只列出三个 EPCPUExecutionProviderCPU第 23 行起锚点#cpuexecutionproviderCUDAExecutionProviderCUDA第 661 行起锚点#cudaexecutionproviderDmlExecutionProviderDirectML第 1194 行起锚点#dmlexecutionprovider这不是因为 ONNX Runtime 只有这三个 EP而是文档生成时被刻意限制了一个子集build.py 中generate_documentation第 23662396 行在构建后调用python gen_opkernel_doc.py --output_path source/docs/OperatorKernels.md \ --providers CPU CUDA DML源码注释写得很直白we currently limit the documentation created by a build to a subset of EPs. Run get_opkernel_doc.py directly if you need/want documentation from other EPs that are enabled in the build.第 23822383 行。也就是说XNNPACK、TensorRT、ROCM、OpenVINO、CoreML 等 EP 的支持表不会出现在这份 checked-in 文档里若你的构建里启用了这些 EP可以自行完整运行生成脚本不带--providers过滤得到全量表格。每个 EP 章节内部按算子域domain分块用一行加粗的分隔行标注例如|**Operator Domain:** *ai.onnx*|||。三个 EP 的域覆盖各有侧重执行提供程序文档中出现的算子域特点CPUExecutionProviderai.onnx、ai.onnx.ml、com.microsoft基线实现最全com.microsoft域含 MoE、BeamSearch、MatMulNBits 等 70 余个贡献算子CUDAExecutionProviderai.onnx、ai.onnx.ml、com.microsoft、com.ms.internal.nhwc额外覆盖 NHWC 内部域Conv/ConvTranspose/BatchNormalization等 NHWC 变体第 11531188 行DmlExecutionProviderai.onnx、com.microsoft、com.microsoft.dml独有com.microsoft.dml域第 1618 行起DmlFusedAdd、DmlFusedConv、DmlFusedGemm、DmlFusedMatMul等 9 个融合算子均为tensor(float), tensor(float16)注意ai.onnx.ml传统机器学习域TreeEnsemble、LinearClassifier、SVM 等只有 CPU EP 提供了完整实现CUDA 域里仅列了LabelEncoder第 10661068 行——这也印证了 CUDA EP 聚焦深度学习算子的定位。二、版本记号法Version Notation如何读文档开头第 512 行定义了 OpSet Version 列的三种记号这与生成脚本 gen_opkernel_doc.py 的format_version_range第 1421 行一一对应记号含义生成逻辑N如13仅注册到 opset N 这一个版本v[0] v[1]时输出单值[N, M]如[6, 12]注册到 opset N 到 M含两端区间且终点为有限值N如16从 opset N 起注册并延续到后续版本直到被更新的注册接管终点 2147483647即 INT_MAX时输出NN的被更新注册接管这一点在真实表格里随处可见。例如 CPU EP 的Acos第 3031 行同时存在22tensor(float)与[7, 21]两行opset 22 的算子 Schema 变化后内核注册拆成了新的版本段。而 CUDA 的Acos只有7一行文档中 CUDA 章节按类型列出DML 则显示7——同一算子在不同 EP 的版本切分粒度不同直接反映各 EP 注册内核时选择的start~end版本区间写法。三、表格的生成机制从注册表到 MarkdownOperatorKernels.md 是自动生成的文件头声明Do not modify directly对应生成器 gen_opkernel_doc.py。其核心数据流是拉取算子 Schemartpy.get_all_operator_schema()第 114 行遍历所有 ONNX 算子定义把每个算子的输入/输出名与类型串拼成 Parameters 列文本*in* X:**T**形式第 122139 行按domain.name存进paramdict。同一算子在不同 opset 下 Schema 可能不同如Clip的input/min/max三输入形态与单输入形态脚本用集合去重后以brbrorbrbr分隔并列展示——这就是表格里or多形态的来源。拉取内核注册表rtpy.get_all_opkernel_def()第 149 行返回所有已注册内核按provider → domain → op_name三级索引第 148153 行。合并类型约束对每个算子把各版本区间op.version_range下的类型约束op.type_constraints聚合成version_type_index[opset 区间][T] {类型集合}第 181185 行再按版本从新到旧输出reverseTrue第 188 行——所以表格中同一算子的多行总是最新版本段在最上。插件 EP 扩展--plugin-ep NAME:PATH第 6193、219226 行会通过ort.register_execution_provider_library加载插件 EP 动态库例如CUDAExecutionProvider:/path/to/libonnxruntime_providers_cuda.so再经get_registered_ep_kernel_defs把其内核并入索引。这是为插件化 EP以独立动态库形式分发的 EP补充支持表的官方途径。CI 的防漂移校验build.py 第 23982422 行在文档生成后会git diff比对 docs/OperatorKernels.md 与docs/ContribOperators.md若有差异即抛出BuildErrorGenerated documents have diffs。也就是说任何改动了内核注册的 PR新增算子、增删类型约束、调整版本区间都必须重新生成该文档否则 CI 直接失败——这也是文档与实现永不失同步的保证。四、注册链路一张表背后的源码结构表格里的每一条记录源头都是各 EP 在编译期通过KernelDefBuilder注册的内核。以 CPU EP 的Clip为例clip.cc 第 1252 行ONNX_CPU_OPERATOR_VERSIONED_KERNEL( Clip, 6, 10, KernelDefBuilder().MayInplace(0, 0) .TypeConstraint(T, DataTypeImpl::GetTensorTypefloat()), Clip_6float); // opset 11 允许 floatopset 12 起扩展为 double/MLFloat16/int8/... ORT_SPECIFY_OP_KERNEL_ARG_DEFAULT_TYPES( kCpuExecutionProvider, kOnnxDomain, Clip, 12, Input, 0, float, MLFloat16, double, int8_t, uint8_t, int32_t, uint32_t, int64_t, uint64_t);要点宏的第一个版本段Clip, 6, 10恰好对应文档 CPU 表格中Clip的[6, 10]行**T** tensor(float)OperatorKernels.md 第 85 行下方op_kernel_type_control命名空间的ORT_SPECIFY_OP_KERNEL_ARG_DEFAULT_TYPES声明了启用类型列表再由BuildKernelDefConstraintsFromTypeList...()展开为TypeConstraint——文档第 8285 行Clip的13含tensor(int32)...tensor(uint8)十种类型、12、11仅tensor(float)、[6, 10]四行正是不同版本段启用类型列表的并集呈现EP 名称常量统一维护在 constants.h如第 3234 行的kCpuExecutionProvider CPUExecutionProvider这正是gen_opkernel_doc.py --providers参数注释中Matches provider names from constants.h所指的来源内核定义KernelDef含version_range与type_constraints即文档生成脚本直接消费的两个字段集中在 kernel_registry.h / kernel_info.h会话装配时由 kernel_registry_manager.h 管理查找。从源码结构看文档表格就是注册表字段 → Markdown 行的直译。运行时语义模型中的算子节点要能在某个 EP 上执行需同时满足三条——算子在 EP 的内核注册表中存在、模型的算子 opset 落在该内核的version_range内、实际张量类型属于该版本段的类型约束集合。三者任一不满足算子就会落回其它 EP通常是 CPU。五、逐 EP 解读支持矩阵5.1 CPUExecutionProvider类型覆盖最广的基线CPU 章节第 23657 行覆盖ai.onnx全量主干算子 大量扩展量化/反量化QuantizeLinear的25段支持float8e4m3fn、float8e5m2、int2、int4、uint2、uint4等低位宽与 FP8 目标类型第 329 行DequantizeLinear对应段支持int2/int4源类型第 121 行——CPU EP 是低比特量化的参考实现LLM 基础设施Attention24Q/K 为float, float16第 54 行、TensorScatterKV cache 写入第 510 行、RMSNormalization、RotaryEmbeddingai.onnx 域23以及com.microsoft域的GroupQueryAttention、MoE、QMoE、BeamSearch、GreedySearch、Sampling、PagedAttention之外的多种 attention 变体第 570643 行控制流与序列If/Loop/Scan的V类型约束覆盖了optional(...)与seq(...)组合类型第 210、246、418 行Sequence*全家族齐备字符串StringConcat、StringNormalizer、StringSplit、RegexFullMatch以及Cast对tensor(string)的支持第 72 行。5.2 CUDAExecutionProviderfp16/bf16 优先CUDA 章节第 6611189 行的类型列表呈现明显的半精度优先策略Gemm/MatMul的13段为bfloat16, double, float, float16第 777、846 行对比 CPU 的Gemmdouble, float两种第 177 行——CUDA 多出的float16/bfloat16是 Tensor Core 路径的前提Cast的25段额外出现tensor(float4e2m1)第 690 行这是 CPU EP 没有的 FP4 类型对应 CUDA 硬件新特性独有com.ms.internal.nhwc域第 1153 行起Conv、ConvTranspose、BatchNormalization、MaxPool等的 NHWC 布局变体float, float16从源码结构看是 CUDA EP 内部用于布局优化重写NCHW→NHWC的中间层算子不对外暴露ai.onnx.ml域仅LabelEncoder一项第 1067 行。5.3 DmlExecutionProviderfloat/float16 限定与 DML 融合域DML 章节第 1194 行起类型基本限定在tensor(float), tensor(float16)个别算子扩展到 int 系列如Add的14段覆盖 10 种数值类型第 1203 行无 bfloat16、无 FP8 主线路径com.microsoft.dml域算子亦仅为float, float16独有com.microsoft.dml域第 1618 行起的 9 个DmlFused*算子DmlFusedConv、DmlFusedGemm、DmlFusedMatMul、DmlFusedAdd、DmlFusedBatchNormalization、DmlFusedInstanceNormalization、DmlFusedMeanVarianceNormalization、DmlFusedSum等是把计算 激活/归一化融合的 DirectML 专属算子配合com.microsoft域的FusedMatMulActivation、NhwcConv等共同构成 DML 路径的融合算子族版本记号更粗很多算子直接写N如Reshape的21/19/14/13/5说明 DML 的内核注册习惯上以更宽的版本段承接后续 opset。六、实战查询、再生成与插件 EP 支持表6.1 查表决策流判断模型算子能否走 EP X在 docs/OperatorKernels.md 对应 EP 章节找到算子注意域ai.onnx之外需核对com.microsoft等确认模型 opset 落在某个版本段N、[N, M]、N内核对实际张量类型是否在该行Types Supported中。例如Clip想走 DML 用int32其13段包含tensor(int32)第 1244 行可以若用double则不在列表内会被重划到 CPU。6.2 本地再生成文档前提已构建出包含 Python 绑定的 ONNX Runtime并在构建目录下import onnxruntime可用。# 全量构建中启用的所有 EP python tools/python/gen_opkernel_doc.py --output_path /tmp/OperatorKernels.md # 只看 CPU 与 CUDA--providers 大小写不敏感自动补全 ExecutionProvider 后缀 python tools/python/gen_opkernel_doc.py --providers cpu cuda --output_path /tmp/opk_cpu_cuda.md # 纳入以插件形式分发的 EP 动态库 python tools/python/gen_opkernel_doc.py --output_path /tmp/opk_plugin.md \ --plugin-ep CUDAExecutionProvider:/path/to/libonnxruntime_providers_cuda.so参数细节来自 gen_opkernel_doc.py 第 210233 行的 argparse 定义--providers可选过滤、--plugin-epNAME:PATH形式可多个、--output_path必填。CI 中使用的正是CPU CUDA DML这一固定组合见第三节若本地构建启用了更多 EP不带--providers即可得到更全的表格——但请注意此时产物与仓库 checked-in 版本不一致是预期行为。6.3 常见缺失排查某个 EP 的章节整体不存在因为生成时被--providers过滤掉了按 6.2 自行生成算子在某 EP 缺席该 EP 未注册对应内核如 CUDA 无RegexFullMatch、DML 无MoE/BeamSearch运行时该算子会落回 CPU类型不在列表需要 EP 侧补充类型约束注册参考 clip.cc 中ORT_SPECIFY_OP_KERNEL_ARG_DEFAULT_TYPES的写法并同步重新生成 OperatorKernels.md 以通过 build.py 的git diff校验。七、小结docs/OperatorKernels.md 是 ONNX Runtime 算子内核注册表的单一事实来源文档N/[N, M]/N三种版本记号精确刻画每个内核的版本适用域三张 EP 表格分别呈现了 CPU全类型基线、CUDAfp16/bf16 NHWC 内部域、DMLfloat/fp16 DmlFused 融合域三条硬件路径的能力边界而 gen_opkernel_doc.py 与 build.py 的生成 diff 校验闭环保证了它与源码注册KernelDefBuilder/ORT_SPECIFY_OP_KERNEL_ARG_DEFAULT_TYPES等严格一致。对使用者它是 EP 选型与精度决策的速查表对贡献者它是每次内核注册变更都必须同步更新的交付物。【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考