ONNX Runtime Mobile专为移动和边缘设备设计，通过精简运行时和算子包按需加载机制大幅降低端侧推理的内存占用。文章介绍其包大小优化策略、硬件加速器集成方式以及与完整版ONNX Runtime的功能差异，为移动端AI应用的轻量化部署提供技术路径和实际配置指导。

岗位关联

需要学习ONNX Runtime Mobile，ONNX Runtime Mobile专为移动和边缘设备设计，通过精简运行时和算子包按需加载机制大幅降低端侧推理的内存占用。边缘AI计算 > 端侧推理涵盖的这一知识点，是从概念认知走向工程落地的桥梁。

目录
  1. 可视化演示
  2. ONNX Runtime Mobile的基本概念与核心定义
  3. ONNX Runtime Mobile的工作原理与核心机制
  4. ONNX Runtime Mobile的主要类型与分类体系
  5. ONNX Runtime Mobile的实际应用场景与案例分析
  6. ONNX Runtime Mobile的优缺点分析与选型建议
  7. ONNX Runtime Mobile的进阶话题与发展趋势
  8. ONNX Runtime Mobile的实践指南与最佳实践
  9. AI 应用场景
  10. Python 演示
  11. 常见问答
  12. 常见误区
  13. 参考来源

可视化演示

动态展示精简运行时架构、算子按需加载、硬件加速器集成与包大小优化对比四个视角，直观理解移动端AI轻量化部署。

本节配有交互动效（进入视口后自动加载，约 3KB）。

ONNX Runtime Mobile的基本概念与核心定义

ONNX Runtime Mobile是ONNX Runtime的轻量级版本，专为移动端和边缘设备上的AI推理场景设计。它继承了ONNX Runtime跨平台、高性能的推理能力，同时通过选择性算子注册等机制大幅缩减二进制体积，使其能够嵌入资源受限的移动应用中。ONNX（Open Neural Network Exchange）作为开放的模型交换格式，使得来自PyTorch、TensorFlow、scikit-learn等多种框架训练的模型可以统一转换为ONNX格式，进而由ONNX Runtime Mobile在端侧执行推理。

ONNX Runtime Mobile与完整版ONNX Runtime的核心关系在于「同源轻量化」。两者共享相同的C++核心代码库和推理引擎架构，但Mobile版本通过编译期裁剪未使用的算子内核、移除训练相关代码、精简依赖库等方式，将运行时体积从数十MB压缩到几MB甚至更小。这种设计使得开发者可以在移动应用中无缝集成AI推理能力，而不会显著增加APK/IPA的安装包大小。

在端侧推理的定位上，ONNX Runtime Mobile填补了「云端推理」与「端侧原生推理」之间的空白。相比于将数据上传云端处理带来的隐私风险、网络延迟和带宽成本，端侧推理能够在设备本地直接执行模型推理，实现低延迟、隐私安全和离线可用。移动端AI部署的需求日益增长——从实时滤镜、人脸识别到端侧NLP和语音助手——ONNX Runtime Mobile为这些场景提供了统一且高效的推理基础设施。

ONNX Runtime Mobile的工作原理与核心机制

ONNX Runtime Mobile的工作原理围绕四个核心机制展开。第一是选择性算子注册（Selective Operator Registration）：在构建运行时库时，工具链会扫描目标ONNX模型实际使用的算子集合，仅将这些算子的内核实现编译进二进制，未使用的算子代码被完全排除。这一机制可以从根本上减小二进制体积，因为完整版ONNX Runtime包含数百个算子实现，而一个典型移动端模型可能仅使用其中十几个。

第二是执行提供者（Execution Provider, EP）机制：ONNX Runtime Mobile通过EP抽象层将算子分发到不同的硬件后端执行。在Android平台上，NNAPI EP将支持的算子委托给设备的NPU、DSP或GPU加速；在iOS平台上，Core ML EP调用Apple Neural Engine进行加速；当特定算子不被硬件EP支持时，系统自动回退到CPU EP或XNNPACK EP执行。第三是模型优化器：在推理前对计算图进行图优化，包括算子融合（如Conv+BN+ReLU融合）、常量折叠、冗余节点消除等，减少运行时的计算量和内存访问。第四是内存管理：通过内存arena机制预分配内存池，复用中间张量的内存空间，降低峰值内存占用和内存分配开销。

模型大小缩减率
R=Sfull−SmobileSfull×100%R = \frac{S_{full} - S_{mobile}}{S_{full}} \times 100\%
S_full为完整版ONNX Runtime的二进制大小，S_mobile为Mobile版大小，R为体积缩减百分比。
推理延迟计算
Tinfer=Tload+Tpreprocess+Tcompute+TpostprocessT_{infer} = T_{load} + T_{preprocess} + T_{compute} + T_{postprocess}
总推理延迟T_infer由模型加载时间T_load、输入预处理时间T_preprocess、核心计算时间T_compute和输出后处理时间T_postprocess之和构成。

ONNX Runtime Mobile的主要类型与分类体系

ONNX Runtime Mobile可以从多个维度进行分类。按目标平台分类，主要分为Android版（支持NNAPI、XNNPACK EP）、iOS版（支持Core ML EP）和嵌入式Linux版（支持CPU及特定硬件EP）。不同平台的构建配置、依赖库和加速路径各不相同，开发者需要根据目标平台选择对应的预编译包或自行交叉编译。

按执行提供者分类，ONNX Runtime Mobile支持CPU EP（通用回退，跨平台兼容）、NNAPI EP（Android硬件加速）、Core ML EP（iOS硬件加速）和XNNPACK EP（优化的CPU算子库）。不同的EP在延迟、功耗和算子覆盖范围上存在权衡：硬件EP通常延迟更低但算子覆盖有限，CPU EP兼容性最好但性能相对较低。按量化方式分类，支持FP32（全精度，精度最高但体积和延迟最大）、INT8（8位整数量化，体积减小约4倍，延迟显著降低）和INT4（4位量化，体积更小但精度损失更大，需要硬件支持）。开发者需要在包大小、推理性能和模型精度之间做出权衡。

在实际选型中，包大小与功能的权衡是核心决策点。启用更多EP会增加二进制体积但提升硬件利用率；采用更激进的量化会减小模型体积和延迟但可能损失精度；注册更多算子能提升模型兼容性但增大包体。典型的移动端配置会选择1-2个EP、INT8量化、选择性算子注册，将运行时体积控制在2-5MB范围内。

量化误差
Equant=1N∑i=1N(xi−x^i)2E_{quant} = \frac{1}{N} \sum_{i=1}^{N} (x_i - \hat{x}_i)^2
x_i为原始浮点权重值，\hat{x}_i为量化后再反量化恢复的值，N为权重元素总数，E_quant为均方误差(MSE)。
内存占用计算
M=Smodel+Binput×Nbatch+BintermediateM = S_{model} + B_{input} \times N_{batch} + B_{intermediate}
M为总内存占用，S_model为模型权重内存，B_input为单样本输入张量大小，N_batch为批大小，B_intermediate为推理中间张量的峰值内存。

ONNX Runtime Mobile的实际应用场景与案例分析

ONNX Runtime Mobile在移动端图像分类场景中有广泛应用。以ResNet-50和MobileNet系列模型为例，开发者将PyTorch训练的模型导出为ONNX格式后，通过ONNX Runtime Mobile在手机端执行推理。MobileNetV2经过INT8量化后，模型体积从约14MB缩减到约3.5MB，在支持NNAPI的Android设备上推理延迟可低至10-20ms，满足实时图像分类的需求。

在端侧NLP场景中，BERT和MiniLM等模型通过ONNX Runtime Mobile实现移动端文本理解。通过对Transformer层进行算子融合和INT8量化，BERT-Base模型在移动端的推理延迟可从数百毫秒降至50ms以内，使得端侧情感分析、文本分类和智能回复成为可能。在实时目标检测场景中，YOLO系列模型经过ONNX转换和量化优化后，能够在移动端实现实时目标检测，结合NNAPI或Core ML加速，帧率可达15-30 FPS。此外，在语音识别场景中，声学模型和语言模型可以部署在ONNX Runtime Mobile上，实现离线语音转文字功能，保护用户语音数据的隐私。

ONNX Runtime Mobile的优缺点分析与选型建议

ONNX Runtime Mobile的优势体现在四个方面：跨平台一致性（同一ONNX模型可在Android、iOS等多平台运行）、小体积（通过选择性算子注册将运行时压缩到几MB）、低延迟（通过硬件EP加速和图优化实现毫秒级推理）和量化支持（INT8/INT4量化大幅减小模型体积和推理开销）。这些特性使其成为移动端AI推理的强有力选择。

其局限性同样需要关注：算子覆盖范围不如完整版ONNX Runtime，部分复杂或新算子可能不被Mobile版本支持；不支持模型训练，仅适用于推理场景；GPU加速依赖平台EP能力，在某些设备上加速效果有限；INT4量化对硬件支持要求较高，通用性不如INT8。

与竞品对比：TensorFlow Lite（TFLite）生态成熟、工具链完善但绑定TensorFlow框架；MACE专注移动端高性能推理但社区较小；Core ML是Apple原生方案但仅限iOS平台。ONNX Runtime Mobile的独特价值在于基于ONNX开放标准、跨平台、支持多框架模型转换。选型建议：如果模型来自PyTorch且需要跨Android/iOS部署，ONNX Runtime Mobile是首选；如果已深度使用TensorFlow生态，TFLite可能更便捷；如果仅需iOS平台且追求极致原生体验，Core ML是合理选择。

ONNX Runtime Mobile的进阶话题与发展趋势

ONNX Runtime Mobile的技术生态持续演进。在WebAssembly（WASM）支持方面，ONNX Runtime提供了WASM后端，使得ONNX模型可以在浏览器中直接运行推理，结合WebGPU和WASM SIMD指令集，Web端AI推理性能不断提升。ONNX IR格式的演进也在持续推进，新版本引入了更丰富的类型系统、更灵活的子图表达和更高效的序列化格式，为ORT Mobile带来新的优化机会。

自适应量化是前沿研究方向：系统根据各网络层对量化的敏感度自动选择最优位宽和量化策略，在精度损失可控的前提下最大化压缩率。联邦学习集成方面，ONNX Runtime Mobile作为端侧推理引擎，可以与联邦学习框架配合，在设备本地执行模型推理和本地更新，再通过安全聚合上传参数，实现隐私保护的分布式AI。与NPU芯片的深度适配也是重要趋势：随着移动NPU算力增长，ONNX Runtime Mobile需要更好地利用专用AI加速器的算力，包括算子映射优化、数据布局转换和流水线调度等。

ONNX Runtime Mobile的实践指南与最佳实践

模型转换流程是使用ONNX Runtime Mobile的第一步。标准流程为：在训练框架（PyTorch/TensorFlow）中训练并导出模型，使用框架的ONNX导出工具转换为ONNX格式，然后使用ONNX Runtime的模型优化工具生成ORT格式模型（可选），最后在移动端集成ONNX Runtime Mobile库加载模型执行推理。在转换过程中需要注意算子版本兼容性、动态维度处理和模型验证。

包大小优化策略包括：使用选择性算子注册仅包含模型所需算子；对模型进行INT8量化减小权重体积；使用ORT格式替代ONNX格式以获得更紧凑的序列化；按需选择EP避免引入不必要的库。性能profiling方面，ONNX Runtime提供内置的profiling API，可以生成包含各算子执行时间的JSON时间线文件，帮助开发者定位性能瓶颈。

量化最佳实践包括：优先尝试训练后量化（PTQ），使用具有代表性的校准数据集获取激活值统计；如果PTQ精度损失过大，考虑量化感知训练（QAT）；对于对量化敏感的层（如首尾层、注意力机制）保持FP32精度；对比不同量化方案在目标设备上的实际延迟和精度，选择最优配置。在部署前务必在目标硬件上进行端到端性能测试，因为不同设备的EP加速能力差异显著。

AI 应用场景

ONNX Runtime Mobile在移动端AI模型训练管线中的应用

解决的问题：在移动端AI模型的训练管线中，ONNX Runtime Mobile虽然不直接参与训练，但在训练完成后的模型验证、量化校准和端侧性能预估环节发挥关键作用。训练完成后，模型需经过ONNX转换、量化优化和端侧部署验证，ONNX Runtime Mobile提供了推理验证和性能基准测试的能力。

具体案例：某团队训练了一个MobileNetV3图像分类模型，在完成PyTorch训练后，将模型导出为ONNX格式。随后使用ONNX Runtime Mobile的量化工具对模型进行INT8训练后量化，使用包含5000张代表性图片的校准数据集获取激活值统计信息。量化后的模型在ONNX Runtime Mobile上运行推理验证，确认精度损失在可接受范围内（Top-1准确率下降不超过1%），同时模型体积从22MB缩减到5.8MB，满足移动端部署的体积和延迟要求。整个训练管线中ONNX Runtime Mobile承担了量化验证和性能预估的角色，确保最终部署的模型在端侧表现达标。

ONNX Runtime Mobile在AI推理服务中的部署优化

解决的问题：在AI推理服务的部署中，ONNX Runtime Mobile用于在移动端和边缘设备上执行优化后的模型推理。通过选择性算子注册、执行提供者配置和量化优化，实现低延迟、低功耗的端侧推理服务，减少对云端推理服务的依赖。

具体案例：某短视频应用需要在用户设备上实时进行人脸关键点检测，用于AR滤镜效果渲染。团队将训练好的106点人脸关键点模型转换为ONNX格式，通过选择性算子注册仅保留Conv、DepthToSpace、Resize等7种算子，将运行时库体积从完整版的38MB压缩到2.3MB。在Android端配置NNAPI EP优先、CPU EP回退的执行策略，在iOS端配置Core ML EP。INT8量化后模型推理延迟在高端Android设备上从32ms降至11ms，在iPhone上从28ms降至9ms，帧率达到60FPS以上，满足实时AR渲染需求。同时端侧推理避免了每帧上传图像到云端的带宽消耗和隐私风险。

ONNX Runtime Mobile在数据预处理与特征工程中的应用

解决的问题：在端侧AI应用中，数据预处理和特征提取往往也需要在设备本地完成。ONNX Runtime Mobile可以部署预处理模型（如归一化、特征提取网络），在移动端实时将原始传感器数据转换为模型输入特征，减少数据传输和云端处理开销。

具体案例：某健康监测应用需要在手机端实时分析加速度传感器数据以识别用户活动类型（步行、跑步、静坐等）。团队将数据预处理流程（包括滑动窗口分割、FFT变换、标准归一化）编码为一个轻量级ONNX预处理模型，与分类模型一同部署在ONNX Runtime Mobile上。端侧每秒采集100Hz的三轴加速度数据，预处理模型将原始数据转换为频域特征向量，再由INT8量化的分类模型进行活动识别。整个预处理和推理流程在移动端完成，单次推理延迟低于5ms，无需上传传感器数据到云端，既保证了实时响应又保护了用户隐私。通过将预处理也纳入ONNX Runtime Mobile的推理图，实现了端到端的优化和统一的执行调度。

Python 演示

python91 行
import timeimport random  class SelectiveOpRegistry:    """模拟ONNX Runtime Mobile的选择性算子注册机制"""     def __init__(self):        self.registered_ops = set()        self.op_sizes = {            "Conv": 120, "Relu": 15, "MaxPool": 80, "Gemm": 95,            "Softmax": 35, "BatchNorm": 60, "Add": 20, "Reshape": 25,        }     def register(self, op_name):        if op_name in self.op_sizes:            self.registered_ops.add(op_name)     def calculate_binary_size(self):        base_size = 1500        ops_size = sum(self.op_sizes[op] for op in self.registered_ops)        return base_size + ops_size  class ModelQuantizer:    """模拟FP32到INT8的量化过程"""     def __init__(self, weights):        self.weights = weights        self.fp32_size = len(weights) * 4     def quantize_to_int8(self):        max_val = max(abs(w) for w in self.weights)        scale = max_val / 127.0        quantized = [int(round(w / scale)) for w in self.weights]        self.int8_size = len(quantized) + 4        mse = sum((w - q * scale) ** 2 for w, q in zip(self.weights, quantized)) / len(self.weights)        return quantized, scale, mse  class ExecutionProviderBenchmark:    """模拟不同执行提供者的推理性能对比"""     def __init__(self):        self.providers = {            "CPU": {"latency_ms": 45.0, "overhead": 0},            "NNAPI": {"latency_ms": 18.0, "overhead": 5},            "CoreML": {"latency_ms": 16.0, "overhead": 5},            "XNNPACK": {"latency_ms": 28.0, "overhead": 2},        }     def benchmark(self, num_runs=10):        results = {}        for name, info in self.providers.items():            times = [info["latency_ms"] + random.uniform(-2, 2) for _ in range(num_runs)]            results[name] = {                "avg_latency": sum(times) / len(times),                "overhead_kb": info["overhead"],            }        return results  def estimate_mobile_latency(model_size_kb, compute_units, battery_impact=1.0):    """模拟移动端推理延迟评估"""    load_time = model_size_kb / 5000.0    compute_time = compute_units * 0.05    total = (load_time + compute_time) * battery_impact    return round(total, 3)  if __name__ == "__main__":    random.seed(42)    registry = SelectiveOpRegistry()    for op in ["Conv", "Relu", "MaxPool", "Gemm", "Softmax"]:        registry.register(op)    print(f"[包大小] 选择性注册算子数: {len(registry.registered_ops)}")    print(f"[包大小] 二进制体积: {registry.calculate_binary_size()} KB")     weights = [random.uniform(-1, 1) for _ in range(1000)]    quantizer = ModelQuantizer(weights)    quantized, scale, mse = quantizer.quantize_to_int8()    print(f"[量化] FP32大小: {quantizer.fp32_size} bytes, INT8大小: {quantizer.int8_size} bytes")    print(f"[量化] 缩放因子: {scale:.6f}, MSE: {mse:.8f}")     bench = ExecutionProviderBenchmark()    results = bench.benchmark(num_runs=10)    for name, res in results.items():        print(f"[EP对比] {name}: 平均延迟={res['avg_latency']:.2f}ms, 开销={res['overhead_kb']}KB")     latency = estimate_mobile_latency(model_size_kb=2000, compute_units=120, battery_impact=1.1)    print(f"[移动端延迟] 预估总延迟: {latency} ms")
  1. self.registered_ops = set()初始化已注册算子集合，用于记录模型实际需要的算子名称。
  2. scale = max_val / 127.0计算INT8对称量化的缩放因子，将浮点范围映射到[-127, 127]。
  3. quantized = [int(round(w / scale)) for w in self.weights]遍历所有FP32权重，除以缩放因子并取整，完成INT8量化。
  4. results[name] = {将每个执行提供者的基准测试结果存入字典。
  5. "avg_latency": sum(times) / len(times),对多次运行的延迟取平均，得到该执行提供者的平均推理延迟。
  6. load_time = model_size_kb / 5000.0根据模型大小估算加载时间，模拟移动端存储读取开销。
  7. compute_time = compute_units * 0.05根据计算单元数量估算纯计算耗时，模拟前向传播开销。
  8. total = (load_time + compute_time) * battery_impact综合加载与计算时间，并乘以电池影响系数得到预估总延迟。
  9. registry = SelectiveOpRegistry()创建选择性算子注册表实例，模拟ONNX Runtime Mobile的算子注册流程。
  10. quantized, scale, mse = quantizer.quantize_to_int8()执行FP32到INT8量化，返回量化结果、缩放因子和均方误差。

常见问答

ONNX Runtime Mobile与完整版ONNX Runtime的主要区别是什么？
ONNX Runtime Mobile是ONNX Runtime的轻量级版本，通过选择性算子注册在编译期裁剪未使用的算子内核，移除训练相关代码和冗余依赖库，将二进制体积从数十MB压缩到几MB。两者共享相同的C++核心推理引擎和架构，但Mobile版专注于移动端和边缘设备的推理场景，牺牲部分算子覆盖和训练功能来换取小体积和低资源占用。
什么是选择性算子注册？它是如何减小二进制体积的？
选择性算子注册是ONNX Runtime Mobile的核心体积优化机制。在构建运行时库时，工具链会扫描目标ONNX模型实际使用的算子集合，通过编译期宏和条件编译，仅将这些算子的内核实现编入二进制，未使用的算子代码被完全排除。完整版包含数百个算子实现，而典型移动端模型仅使用十几个，因此选择性注册可以从根本上大幅缩减二进制体积。
ONNX Runtime Mobile支持哪些执行提供者（EP）？各自用于什么平台？
ONNX Runtime Mobile主要支持四种执行提供者：CPU EP（通用回退，跨平台兼容）、NNAPI EP（Android平台，委托给NPU/DSP/GPU等硬件加速器）、Core ML EP（iOS平台，调用Apple Neural Engine加速）、XNNPACK EP（优化的CPU神经网络算子库，跨平台）。当指定EP不支持某个算子时，系统自动回退到CPU EP执行该算子。
INT8量化相比FP32有什么优势？量化误差如何衡量？
INT8量化将32位浮点权重映射为8位整数，模型体积减小约4倍，推理时使用整数运算速度更快、功耗更低，且硬件加速器对INT8计算支持更好。量化误差通常用均方误差（MSE）衡量：E = (1/N) * sum((x_i - x_hat_i)^2)，其中x_i为原始值，x_hat_i为量化后恢复的值。在校准数据集上评估量化前后模型输出的差异可以判断精度损失是否可接受。
如何将PyTorch模型转换为ONNX Runtime Mobile可用的格式？
标准流程为：首先在PyTorch中调用torch.onnx.export()将模型导出为ONNX格式，指定opset版本和动态维度；然后使用ONNX Runtime的量化工具对模型进行INT8训练后量化，使用代表性校准数据集；接着使用onnxruntime.tools生成选择性算子注册所需的算子列表，构建裁剪后的Mobile运行时库；最后将优化后的模型（ORT格式）和Mobile运行时库集成到移动应用中加载执行推理。
ONNX Runtime Mobile是否支持模型训练？为什么？
ONNX Runtime Mobile不支持模型训练，仅用于推理。这是因为Mobile版本的设计目标是轻量化和低资源占用，训练需要反向传播、梯度计算、优化器等大量额外代码和内存，与移动端的体积和资源约束相矛盾。如果需要端侧微调，通常使用训练框架的轻量版或联邦学习方案在端侧完成训练后将模型转换为ONNX格式再由ORT Mobile执行推理。
ONNX Runtime Mobile的图优化包括哪些操作？有什么作用？
图优化包括算子融合（如Conv+BatchNorm+ReLU融合为单个算子，减少内存访问和计算开销）、常量折叠（在编译期计算常量表达式，消除冗余计算）、冗余节点消除（移除对输出无影响的节点）、公共子表达式消除等。这些优化在推理前对计算图进行预处理，减少运行时的计算量和内存访问次数，显著提升推理速度。
在选型时，ONNX Runtime Mobile与TensorFlow Lite相比有何优劣？
ONNX Runtime Mobile的优势在于基于ONNX开放标准，支持PyTorch、TensorFlow等多框架模型转换，跨平台一致性好；TFLite的优势在于与TensorFlow生态深度集成，工具链成熟，社区资源丰富。如果模型来自PyTorch且需跨平台部署，ORT Mobile更合适；如果已深度使用TensorFlow生态，TFLite集成更便捷。两者在量化支持、硬件加速方面能力接近，选择取决于现有技术栈和跨平台需求。

常见误区

误区ONNX Runtime Mobile可以用于在移动端进行模型训练。

正解ONNX Runtime Mobile仅支持推理，不支持训练。它的设计目标是轻量化和低资源占用，训练所需的反向传播、梯度计算和优化器等代码被完全移除。

为何常见：很多人将「推理引擎」与「训练框架」混淆，且ONNX Runtime的完整版名称中带有「Runtime」容易让人联想到运行时计算包括训练。实际上ONNX Runtime系列（包括Mobile版）都是推理专用引擎。

误区ONNX Runtime Mobile支持ONNX规范中的所有算子。

正解ONNX Runtime Mobile通过选择性算子注册机制，在编译期仅包含模型实际使用的算子，未注册的算子不会被编入二进制。因此Mobile版本默认不包含所有ONNX算子，算子覆盖范围取决于构建时的注册配置。

为何常见：完整版ONNX Runtime确实支持绝大多数ONNX算子，而Mobile版与完整版共享同一代码库，容易让人误以为Mobile版也包含所有算子。实际上选择性注册正是Mobile版减小体积的核心手段。

误区INT4量化总是比INT8量化更好，因为体积更小。

正解INT4量化虽然模型体积更小（相比INT8再减半），但精度损失通常更大，且需要硬件支持4位计算才能获得实际加速。在很多设备上INT4权重需要反量化为INT8再计算，反而增加开销。INT8量化在精度和性能之间通常有更好的平衡。

为何常见：直觉上认为位数越少体积越小就越好，忽略了量化精度损失和硬件支持这两个关键因素。实际上量化方案的选择需要在精度、体积、延迟和硬件兼容性之间综合权衡。

误区ONNX Runtime Mobile只能运行在Android平台上。

正解ONNX Runtime Mobile是跨平台的，支持Android（NNAPI/XNNPACK EP）、iOS（Core ML EP）、嵌入式Linux等多种平台。虽然不同平台的执行提供者和构建配置不同，但同一ONNX模型可以在多平台上运行。

为何常见：NNAPI是Android特有的API，常与ONNX Runtime Mobile一起被提及，容易让人产生Android专属的印象。实际上ONNX Runtime Mobile的设计目标之一就是跨平台一致性。

参考来源