尧图网站建设 
ONNX Runtime 移动端部署完整指南Android 与 iOS 高性能推理实战【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntime在手机上运行图像识别、语音处理这类模型时推理耗时与内存占用是两个绕不开的硬约束。ONNX Runtime 是微软开源的跨平台推理引擎它让同一份 ONNX 模型在 Android 和 iOS 上都能直接加载并按设备条件把算子分发到 NNAPI、Core ML 或 CPU 执行。读完本文你能在自己的 App 中完成模型接入、执行提供器Execution Provider配置并掌握线程数、张量复用等关键调优手段。这张架构图说明了 ONNX Runtime 的定位训练框架产出的模型统一转成 ONNX 格式后可以在桌面、手机、云端等部署目标上选择 CPU、GPU、NPU 等不同硬件执行。理解执行提供器这个概念是后文所有配置的基础。先准备一个适合端侧的模型模型接入前先做两件事导出与瘦身。从 PyTorch、TensorFlow 等框架导出标准 ONNX 文件torch.onnx.export或tf2onnx。用 ONNX Runtime 自带的量化工具压缩模型。INT8 量化能显著减小体积并降低内存带宽压力对推理精度通常影响有限python -m onnxruntime.quantization.quantize_static \ --input mobilenetv2.onnx \ --output mobilenetv2_int8.onnx \ --quant_format QDQ如果目标设备确定如只跑 Android NNAPI还可以做一步感知的图优化把模型转成.ort格式再上设备流程如下图之所以先做这一步是因为端侧性能瓶颈大多在模型本身先量化、后集成比在应用层反复打补丁更有效。第一步Android 端接入依赖与版本通过 Maven 引入onnxruntime-android依赖。版本号必须与引擎源码中的 VERSION_NUMBER 保持一致当前仓库为 1.30.0混用不同小版本可能触发 JNI 符号不匹配表现为加载时崩溃而不是友好报错。核心推理流程OrtEnvironment是进程级单例SessionOptions用于配置会话OrtSession负责实际推理完整定义见 java/src/main/java/ai/onnxruntime/OrtSession.java。OrtEnvironment env OrtEnvironment.getEnvironment(); SessionOptions options new SessionOptions(); // 启用 NNAPI 执行提供器不支持的算子自动回退 CPU options.addExecutionProvider(OrtProvider.NNAPI); options.setIntraOpNumThreads(4); // 单算子内线程数 OrtSession session env.createSession(mobilenetv2.onnx, options); // 构建输入张量[1, 3, 224, 224] 的 RGB 浮点数据 long[] shape {1, 3, 224, 224}; OnnxTensor input OnnxTensor.createTensor(env, FloatBuffer.wrap(inputData), shape); try (OrtSession.Result outputs session.run(Collections.singletonMap(input, input))) { float[] scores (float[]) outputs.get(0).getValue(); int topClass argmax(scores); }注意session.run的返回值用 try-with-resources 关闭否则每次推理都会泄漏一份输出缓冲长运行应用内存会持续增长——这是新手最容易踩的坑。NNAPI 的两个标志位定义见 NNAPIFlags.java值得了解CPU_DISABLED禁止 NNAPI 使用 CPU 实现某算子遇到只能 CPU 执行的算子时模型直接加载失败。适合用来严格验证模型是否完整支持 NPU。CPU_ONLY强制 NNAPI 只用 CPU会明显损失性能仅在排查问题时临时开启。默认不加这两个标志即可NNAPI 遇到不支持的算子会自动回退 CPU保证功能正确。第二步iOS 端接入iOS 侧通过 CocoaPods 引入ONNXRuntime模型文件放入 Xcode target 后以路径方式加载。Objective-C 接口的核心类是ORTEnv、ORTSessionOptions、ORTSession完整声明在 objective-c/include/ort_session.h。接入思路与 Android 对称创建 env → 配置 options → 创建 session → 每帧运行推理。iOS 特有的选择是Core ML 执行提供器对应OrtProvider.CORE_ML它能把支持的子图交给 Apple 的 Core ML 框架执行在 Apple Silicon 设备上有明显收益。两点取舍建议Core ML 兼容性Core ML 对算子子集的覆盖随 iOS 版本变化如果你的模型包含它不支持的算子整体会回退 CPU功能不受影响但加速会打折。建议用真机 Instruments 实测而不是只看理论支持表。线程配置sessionOptions上同样可设 intra/inter 线程数移动端 CPU 核数少且大核小核功耗差异大线程数设为大核数附近通常比拉满更省电。降低推理耗时的三个手段线程数调优setIntraOpNumThreads控制单个算子内部的并行度setInterOpNumThreads控制算子之间的流水线并行。移动端经验值是 intra 设为大核数量、inter 保持 1线程越多上下文切换开销越大盲目拉高反而变慢。张量复用输入形状固定时如恒为 224×224在初始化阶段建好输入缓冲每帧只更新内容避免反复分配。内存池ONNX Runtime 内置 ArenaAllocator 内存池会话运行期间的中间张量会复用池内内存。遇到内存增长问题先看 docs/Memory_Optimizer.md 理解其分配策略再决定是否需要调整。常见坑与排查现象排查方向模型加载 OOM先量化模型再检查是否同时开了多个大内存占用特征如多线程 大 batch某设备加载直接失败检查是否误开了CPU_DISABLED类严格标志导致个别算子无法回退NNAPI/Core ML 加速不明显用 Instruments / 系统监控确认子图是否真的被分发到目标硬件再核对模型算子覆盖情况版本相关崩溃对比 App 依赖版本与 VERSION_NUMBER确保两侧一致小结与下一步回到开头的两个约束ONNX Runtime 通过统一的模型格式 可插拔执行提供器把同一模型跑遍不同硬件这件事变成了配置工作而非移植工作。你现在可以按这个顺序动手用quantize_static量化你的第一个模型在 Android 工程跑通上文的最小推理闭环先不启用 NNAPI确认 CPU 路径正确再打开OrtProvider.NNAPI对比前后耗时与掉帧情况iOS 侧复用同一模型文件接入 Core ML EP 做对照验证。Android 真机测试的编译与调试流程可参考仓库内的 docs/Android_testing.md。【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ONNX Runtime 移动端部署完整指南：Android 与 iOS 高性能推理实战
ONNX Runtime 移动端部署完整指南Android 与 iOS 高性能推理实战【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntime在手机上运行图像识别、语音处理这类模型时推理耗时与内存占用是两个绕不开的硬约束。ONNX Runtime 是微软开源的跨平台推理引擎它让同一份 ONNX 模型在 Android 和 iOS 上都能直接加载并按设备条件把算子分发到 NNAPI、Core ML 或 CPU 执行。读完本文你能在自己的 App 中完成模型接入、执行提供器Execution Provider配置并掌握线程数、张量复用等关键调优手段。这张架构图说明了 ONNX Runtime 的定位训练框架产出的模型统一转成 ONNX 格式后可以在桌面、手机、云端等部署目标上选择 CPU、GPU、NPU 等不同硬件执行。理解执行提供器这个概念是后文所有配置的基础。先准备一个适合端侧的模型模型接入前先做两件事导出与瘦身。从 PyTorch、TensorFlow 等框架导出标准 ONNX 文件torch.onnx.export或tf2onnx。用 ONNX Runtime 自带的量化工具压缩模型。INT8 量化能显著减小体积并降低内存带宽压力对推理精度通常影响有限python -m onnxruntime.quantization.quantize_static \ --input mobilenetv2.onnx \ --output mobilenetv2_int8.onnx \ --quant_format QDQ如果目标设备确定如只跑 Android NNAPI还可以做一步感知的图优化把模型转成.ort格式再上设备流程如下图之所以先做这一步是因为端侧性能瓶颈大多在模型本身先量化、后集成比在应用层反复打补丁更有效。第一步Android 端接入依赖与版本通过 Maven 引入onnxruntime-android依赖。版本号必须与引擎源码中的 VERSION_NUMBER 保持一致当前仓库为 1.30.0混用不同小版本可能触发 JNI 符号不匹配表现为加载时崩溃而不是友好报错。核心推理流程OrtEnvironment是进程级单例SessionOptions用于配置会话OrtSession负责实际推理完整定义见 java/src/main/java/ai/onnxruntime/OrtSession.java。OrtEnvironment env OrtEnvironment.getEnvironment(); SessionOptions options new SessionOptions(); // 启用 NNAPI 执行提供器不支持的算子自动回退 CPU options.addExecutionProvider(OrtProvider.NNAPI); options.setIntraOpNumThreads(4); // 单算子内线程数 OrtSession session env.createSession(mobilenetv2.onnx, options); // 构建输入张量[1, 3, 224, 224] 的 RGB 浮点数据 long[] shape {1, 3, 224, 224}; OnnxTensor input OnnxTensor.createTensor(env, FloatBuffer.wrap(inputData), shape); try (OrtSession.Result outputs session.run(Collections.singletonMap(input, input))) { float[] scores (float[]) outputs.get(0).getValue(); int topClass argmax(scores); }注意session.run的返回值用 try-with-resources 关闭否则每次推理都会泄漏一份输出缓冲长运行应用内存会持续增长——这是新手最容易踩的坑。NNAPI 的两个标志位定义见 NNAPIFlags.java值得了解CPU_DISABLED禁止 NNAPI 使用 CPU 实现某算子遇到只能 CPU 执行的算子时模型直接加载失败。适合用来严格验证模型是否完整支持 NPU。CPU_ONLY强制 NNAPI 只用 CPU会明显损失性能仅在排查问题时临时开启。默认不加这两个标志即可NNAPI 遇到不支持的算子会自动回退 CPU保证功能正确。第二步iOS 端接入iOS 侧通过 CocoaPods 引入ONNXRuntime模型文件放入 Xcode target 后以路径方式加载。Objective-C 接口的核心类是ORTEnv、ORTSessionOptions、ORTSession完整声明在 objective-c/include/ort_session.h。接入思路与 Android 对称创建 env → 配置 options → 创建 session → 每帧运行推理。iOS 特有的选择是Core ML 执行提供器对应OrtProvider.CORE_ML它能把支持的子图交给 Apple 的 Core ML 框架执行在 Apple Silicon 设备上有明显收益。两点取舍建议Core ML 兼容性Core ML 对算子子集的覆盖随 iOS 版本变化如果你的模型包含它不支持的算子整体会回退 CPU功能不受影响但加速会打折。建议用真机 Instruments 实测而不是只看理论支持表。线程配置sessionOptions上同样可设 intra/inter 线程数移动端 CPU 核数少且大核小核功耗差异大线程数设为大核数附近通常比拉满更省电。降低推理耗时的三个手段线程数调优setIntraOpNumThreads控制单个算子内部的并行度setInterOpNumThreads控制算子之间的流水线并行。移动端经验值是 intra 设为大核数量、inter 保持 1线程越多上下文切换开销越大盲目拉高反而变慢。张量复用输入形状固定时如恒为 224×224在初始化阶段建好输入缓冲每帧只更新内容避免反复分配。内存池ONNX Runtime 内置 ArenaAllocator 内存池会话运行期间的中间张量会复用池内内存。遇到内存增长问题先看 docs/Memory_Optimizer.md 理解其分配策略再决定是否需要调整。常见坑与排查现象排查方向模型加载 OOM先量化模型再检查是否同时开了多个大内存占用特征如多线程 大 batch某设备加载直接失败检查是否误开了CPU_DISABLED类严格标志导致个别算子无法回退NNAPI/Core ML 加速不明显用 Instruments / 系统监控确认子图是否真的被分发到目标硬件再核对模型算子覆盖情况版本相关崩溃对比 App 依赖版本与 VERSION_NUMBER确保两侧一致小结与下一步回到开头的两个约束ONNX Runtime 通过统一的模型格式 可插拔执行提供器把同一模型跑遍不同硬件这件事变成了配置工作而非移植工作。你现在可以按这个顺序动手用quantize_static量化你的第一个模型在 Android 工程跑通上文的最小推理闭环先不启用 NNAPI确认 CPU 路径正确再打开OrtProvider.NNAPI对比前后耗时与掉帧情况iOS 侧复用同一模型文件接入 Core ML EP 做对照验证。Android 真机测试的编译与调试流程可参考仓库内的 docs/Android_testing.md。【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考