解析 ONNX Runtime 源码：C++ 是如何编排跨硬件平台的模型执行计划的？ - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位同仁、技术爱好者们，大家好！

今天，我们将深入探讨一个在现代AI部署中至关重要的话题：ONNX Runtime 的核心机制。具体来说，我们将聚焦于C++层面，揭示ONNX Runtime是如何精密地编排跨硬件平台的模型执行计划的。这不仅仅是一个关于API调用的故事，更是一个关于底层架构、内存管理、以及异构计算协调的深度剖析。

1. 引言：AI部署的挑战与ONNX Runtime的应答

在人工智能时代，我们训练出的模型往往是计算密集型的，需要部署到各种各样的硬件环境中，从高性能的GPU服务器到边缘设备上的CPU、NPU乃至FPGA。一个模型的训练可能在PyTorch或TensorFlow上完成，但部署时我们希望它能在TensorRT、OpenVINO、DirectML或简单的CPU上高效运行。这种多样性带来了巨大的挑战：

模型格式碎片化： 各个框架有自己的模型格式，导致互操作性差。
硬件平台异构性： 每种硬件都有其独特的指令集、内存模型和优化方法。
性能优化复杂性： 为每种硬件手动优化模型的工作量巨大且容易出错。

ONNX（Open Neural Network Exchange）应运而生，旨在提供一个开放的模型表示格式，促进AI模型在不同框架和硬件之间的可移植性。然而，仅仅有一个统一的模型格式是不够的。我们需要一个运行时（Runtime）来真正地执行这些ONNX模型，并且要能智能地利用目标硬件的优势。这就是 ONNX Runtime 的使命。

ONNX Runtime 是一个高性能、跨平台的推理引擎，它能够执行ONNX格式的模型。其核心优势在于：

高性能： 通过集成各种硬件加速库（Execution Providers），它能够充分利用目标硬件的计算能力。
跨平台： 支持Windows、Linux、macOS，以及各种嵌入式系统。
灵活性： 允许用户自定义操作符、集成新的硬件后端。
统一接口： 提供C++、C#、Python等多种语言接口，但底层核心是纯C++实现。

今天，我们将深入其C++源码，探究它如何从一个ONNX模型文件，构建出能在CPU、GPU或其他加速器上高效运行的执行计划。

2. ONNX Runtime 核心架构概览

在深入细节之前，我们先鸟瞰一下ONNX Runtime的整体架构。理解这些核心组件及其职责，有助于我们后续理解其精妙的编排策略。

graph TD
    A[ONNX Model (.onnx)] --> B[InferenceSession::Load]
    B --> C[Graph (Internal Representation)]
    C --> D[Graph Transformers/Optimizers]
    D --> E[Graph Partitioner]
    E --> F[Execution Providers (EPs)]
    F --> G[Op Kernels (EP specific)]
    F --> H[Memory Managers (EP specific)]
    E --> I[Execution Plan (ExecutableGraph)]
    I --> J[InferenceSession::Run]
    J --> K[ExecutionFrame]
    K --> G
    K --> H
    J --> L[Output Tensors]

核心组件及其职责：

InferenceSession： 用户与ONNX Runtime交互的主要入口。负责加载模型、管理会话选项、执行推理。
Graph： ONNX模型在内存中的内部表示。包含节点（Node）、输入/输出（NodeArg）以及它们之间的连接。
Graph Transformers/Optimizers： 对加载的图进行静态分析和优化，如节点融合、消除死代码、常量折叠等，以提高执行效率。
Execution Providers (EPs)： ONNX Runtime异构计算的核心。每个EP负责管理特定硬件（如CPU、CUDA、TensorRT、OpenVINO）上的计算资源、实现部分ONNX操作符，并能够对图进行分区。
Graph Partitioner： 依据注册的EPs的能力，将一个大图拆分成多个子图。每个子图分配给最适合执行它的EP。
Op Kernels： 特定ONNX操作符（如Add, Conv, Relu）在特定EP上的具体实现。
Memory Managers： 每个EP都有自己的内存分配器，用于管理其设备的内存。ONNX Runtime通过抽象接口统一管理。
Execution Plan (或 ExecutableGraph)： 经过优化和分区后的最终执行计划，包含了哪些节点由哪个EP执行、以及数据如何在EP之间流动的信息。
ExecutionFrame： 在实际推理过程中，管理中间激活张量和输入/输出张量的生命周期和存储位置。

理解了这些，我们就可以开始深入挖掘ONNX Runtime是如何将这些组件编排起来的。

3. 模型加载与内部图表示

一切的起点都是一个 .onnx 模型文件。当用户调用 Ort::Env::CreateSession 或 Ort::InferenceSession 的构造函数时，ONNX Runtime会加载并解析这个模型。

#include <onnxruntime_cxx_api.h>
#include <iostream>
#include <vector>
#include <numeric>

// 示例：创建会话并加载模型
void load_model_example(const std::string& model_path) {
    Ort::Env env(ORT_LOGGING_LEVEL_WARNING, "TestSession");
    Ort::SessionOptions session_options;
    session_options.SetIntraOpNumThreads(1);
    session_options.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL);

    // 默认会使用CPU Execution Provider
    // 如果有GPU，可以注册CUDA EP：
    // OrtCUDAProviderOptions cuda_options{};
    // session_options.AppendExecutionProvider_CUDA(cuda_options);

    try {
        Ort::Session session(env, model_path.c_str(), session_options);
        std::cout << "Model loaded successfully from: " << model_path << std::endl;

        // 获取输入信息
        std::vector<char*> input_names;
        std::vector<Ort::TypeInfo> input_types;
        Ort::AllocatorWith</*...*/> allocator = Ort::AllocatorWith</*...*/>(session, /*...*/>); // Simplified allocator access

        size_t num_inputs = session.GetInputCount();
        for (size_t i = 0; i < num_inputs; ++i) {
            input_names.push_back(session.GetInputNameAllocated(i, allocator).get());
            input_types.push_back(session.GetInputTypeInfo(i));
        }
        std::cout << "Number of inputs: " << num_inputs << std::endl;
        // ... 进一步处理输入输出信息

    } catch (const Ort::Exception& e) {
        std::cerr << "Error loading model: " << e.what() << std::endl;
    }
}

// int main() {
//     load_model_example("path/to/your/model.onnx");
//     return 0;
// }

在 Ort::Session 内部，加载过程会创建一个 Graph 对象。这个 Graph 对象是ONNX模型在内存中的C++抽象。它由一系列 Node 组成，每个 Node 代表一个ONNX操作符（如 Conv、Relu、Add 等）。Node 之间通过 NodeArg 连接，NodeArg 代表张量（tensor）或序列（sequence）等数据流。

Graph 的核心数据结构大致如下（简化概念）：

// onnxruntime/core/graph/graph.h (概念性简化)
class Graph {
public:
    // ... 构造函数、加载方法
    const Node& GetNode(NodeIndex node_index) const;
    const NodeArg& GetNodeArg(const std::string& name) const;

    // 迭代器访问节点
    const std::vector<std::unique_ptr<Node>>& Nodes() const;

    // 获取图的输入/输出
    const std::vector<const NodeArg*>& GetInputs() const;
    const std::vector<const NodeArg*>& GetOutputs() const;

    // ... 其他方法
private:
    std::string name_;
    std::string description_;
    // 存储所有节点
    std::vector<std::unique_ptr<Node>> nodes_;
    // 存储所有NodeArg（张量）
    std::vector<std::unique_ptr<NodeArg>> node_args_;
    // 图的输入/输出 NodeArg 引用
    std::vector<const NodeArg*> graph_inputs_;
    std::vector<const NodeArg*> graph_outputs_;
    // ... 其他内部管理数据
};

// onnxruntime/core/graph/node.h (概念性简化)
class Node {
public:
    const std::string& OpType() const; // 例如 "Conv", "Relu"
    const std::string& Name() const;   // 节点名称
    const std::string& Domain() const; // ONNX 操作符的域，例如 "" (ai.onnx)

    // 获取输入/输出 NodeArg
    const std::vector<NodeArg*>& GetInputDefs() const;
    const std::vector<NodeArg*>& GetOutputDefs() const;

    // 获取节点属性，例如 Conv 的 "kernel_shape"
    const AttributeProto* GetAttribute(const std::string& name) const;

    // 所属的Execution Provider
    const std::string& GetExecutionProviderType() const; // 例如 "CPUExecutionProvider"

    // ...
};

// onnxruntime/core/graph/node_arg.h (概念性简化)
class NodeArg {
public:
    const std::string& Name() const;
    const ONNX_NAMESPACE::TypeProto* TypeAsProto() const; // 类型信息，例如张量维度和数据类型
    bool Is
    _constant() const; // 是否是常量输入
    // ...
};

这种内存表示是后续所有优化和执行计划生成的基础。

4. 图优化与转换

加载原始ONNX模型后，ONNX Runtime并不会直接执行它。相反，它会经历一系列的图优化和转换阶段。这些优化旨在减少计算量、内存占用，并提高缓存局部性，从而显著提升推理性能。这些优化由 GraphTransformer 接口及其具体实现完成。

SessionOptions::SetGraphOptimizationLevel 允许用户控制优化级别：

ORT_DISABLE_ALL
ORT_ENABLE_BASIC
ORT_ENABLE_EXTENDED
ORT_ENABLE_ALL (默认)
ORT_DISABLE_SPECIFIC_PASSES

一些常见的图优化技术包括：

节点融合 (Node Fusion)： 将一系列连续的小操作融合为一个大的操作。例如，Conv -> BatchNorm -> Relu 可以融合为一个 FusedConvBnRelu 操作。这减少了中间张量的创建和销毁，提高了计算效率。
常量折叠 (Constant Folding)： 如果一个操作的所有输入都是常量，那么该操作可以在模型加载时提前计算，将其结果作为常量存储，避免在推理时重复计算。
消除死代码 (Dead Code Elimination)： 移除对模型输出没有贡献的节点。
布局优化： 调整张量的数据布局（例如从NCHW到NHWC），以更好地匹配特定硬件的访问模式。

这些优化器通过遍历图，识别模式，然后修改图结构（添加、删除、替换节点）来完成。

示例：一个简化的图融合概念

假设我们有一个简单的ONNX图：Input -> Conv -> Relu -> Output。
一个 ConvReluFusion 转换器可能会：

找到一个 Conv 节点。
检查其输出是否连接到一个 Relu 节点。
如果满足条件，创建一个新的 FusedConvRelu 节点。
将 Conv 和 Relu 节点从图中移除。
将 FusedConvRelu 节点插入图中，并连接其输入和输出。

这个过程在C++中会涉及到对 Graph 对象的修改，例如 Graph::RemoveNode、Graph::AddNode 等方法。

// onnxruntime/core/graph/graph_transformer.h (概念性简化)
class GraphTransformer {
public:
    virtual ~GraphTransformer() = default;
    virtual Status Apply(Graph& graph, bool& modified) const = 0;
    virtual std::string Name() const = 0;
};

// onnxruntime/core/optimizer/conv_bn_fusion.h (概念性简化)
class ConvBatchNormFusion : public GraphTransformer {
public:
    // ... 构造函数
    Status Apply(Graph& graph, bool& modified) const override {
        modified = false;
        // 遍历图中的所有节点
        for (Node& node : graph.Nodes()) {
            if (node.OpType() == "Conv") {
                // 检查 Conv 节点的输出是否连接到 BatchNorm
                // ... 复杂逻辑来识别模式并进行融合
                // 如果成功融合，设置 modified = true 并修改图
            }
        }
        return Status::OK();
    }
    // ...
};

这些优化器是独立于硬件的，它们对ONNX图进行通用优化。在这些通用优化之后，图将进入下一个关键阶段：硬件相关的优化和分区。

5. 执行提供者（Execution Providers, EPs）：异构计算的核心

ONNX Runtime实现跨硬件平台能力的核心机制是执行提供者 (Execution Providers, EPs)。每个EP负责与特定硬件后端进行交互，并提供在该硬件上执行ONNX操作符的能力。

ONNX Runtime 提供了多种内置的EPs：

Execution Provider	描述	适用硬件
`CPUExecutionProvider`	默认EP，使用MKL-DNN/Eigen/OpenBLAS等优化库	CPU
`CUDAExecutionProvider`	利用NVIDIA CUDA加速	NVIDIA GPU
`TensorRTExecutionProvider`	集成NVIDIA TensorRT，进行更深度的GPU优化	NVIDIA GPU
`OpenVINOExecutionProvider`	利用Intel OpenVINO工具套件进行推理加速	Intel CPU, GPU, VPU, FPGA
`DirectMLExecutionProvider`	利用DirectML API在Windows上加速	DirectX 12兼容的GPU
`ROCmExecutionProvider`	利用AMD ROCm加速	AMD GPU
`NNAPIEP`	利用Android NNAPI加速	Android设备上的加速器
`CoreMLEP`	利用Apple Core ML加速	Apple设备上的神经引擎
`XNNPACK`	针对移动端CPU优化的EP	移动端CPU

用户通过 SessionOptions::AppendExecutionProvider_XXX 方法注册他们希望使用的EPs。注册的顺序通常也很重要，因为它决定了ONNX Runtime在选择EP时的优先级。例如，如果你希望尽可能使用CUDA，就应该先注册CUDA EP。

// 在加载模型之前注册EPs
Ort::SessionOptions session_options;

// 1. 尝试使用TensorRT (最高优先级)
OrtTensorRTProviderOptions trt_options{};
// 设置TRT选项，例如fp16_enable, max_workspace_size等
// trt_options.trt_fp16_enable = 1;
// trt_options.trt_max_workspace_size = 1 << 30; // 1GB
session_options.AppendExecutionProvider_TensorRT(trt_options);

// 2. 如果TensorRT不支持，尝试CUDA
OrtCUDAProviderOptions cuda_options{};
session_options.AppendExecutionProvider_CUDA(cuda_options);

// 3. 如果CUDA也不支持，退回到CPU (通常不需要显式注册，它是默认的)
// session_options.AppendExecutionProvider_CPU();

每个EP都有以下关键职责：

实现ONNX操作符的内核 (Op Kernels)： EP必须提供其支持的ONNX操作符在特定硬件上的实现。例如，CUDAExecutionProvider 会提供 Conv 操作的CUDA核函数实现。
管理设备内存： EP负责在相应设备上分配、释放内存，并在必要时进行主机（CPU）与设备之间的内存传输。
图分区 (Graph Partitioning)： EP能够识别ONNX图中的子图，判断这些子图是否可以在其管理的硬件上高效执行。这是异构计算编排的关键一步。
提供能力报告： EP会告诉ONNX Runtime它支持哪些操作符、哪些操作符组合可以被加速。

IExecutionProvider 是所有EPs的基类接口，定义了这些通用行为。


// onnxruntime/core/framework/execution_provider.h (概念性简化)
class IExecutionProvider {
public:
    virtual ~IExecutionProvider() = default;

    // 获取EP的类型字符串，例如 "CUDA", "CPU"
    virtual const std::string& Get

1. 引言：AI部署的挑战与ONNX Runtime的应答

2. ONNX Runtime 核心架构概览

3. 模型加载与内部图表示

4. 图优化与转换

5. 执行提供者（Execution Providers, EPs）：异构计算的核心

发表回复 取消回复

发表回复取消回复