ONNX Runtime React Native 端到端测试test_types 模型的 ONNX/ORT 双格式生成与转换实战【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntime导读本文围绕 ONNX Runtime 仓库中 React Native 端到端e2e测试所使用的test_types_*.onnx/test_types_*.ort系列模型展开说明为什么同一组数据类型测试模型需要同时准备 ONNX 与 ORT 两种格式、二者分别服务于什么样的构建形态并给出从 Node.js 测试数据一键批量转换生成移动端测试资产的完整命令、工具参数解读与底层实现分析。读完本文你将掌握convert_onnx_models_to_ort转换工具的核心机制理解Fixed与Runtime两种优化风格的适用场景并能复现 React Native 端各数据类型的推理验证流程。一、为什么同一组模型需要 ONNX 与 ORT 两种格式在 js/react_native/e2e/src/test_types_models.readme.md 中项目明确给出了这一设计决策ONNX 格式模型用于仅在完整构建full build中才支持的数据类型ORT 格式模型用于在完整构建和移动构建mobile build中都支持的数据类型。ORT 格式.ort是 ONNX Runtime 的原生序列化格式它在模型加载时省去了 ONNX protobuf 解析环节并能内嵌预先完成的图优化结果因此是移动端Android/iOS 上的 React Native 环境首选的模型载体。由于移动构建会对算子集合进行裁剪某些数据类型的 kernel 只存在于完整构建中这部分类型就只能继续使用.onnx模型来测试。该策略的落地证据清晰可见——查看 js/react_native/e2e/src 目录实际存放的测试资产为数据类型文件e2e/src格式booltest_types_bool.onnxONNXdouble (float64)test_types_double.onnxONNXfloat (float32)test_types_float.ortORTfloat16test_types_float16.ortORTint8test_types_int8.ortORTuint8test_types_uint8.ortORTint32test_types_int32.ortORTint64test_types_int64.ortORT同一套文件也被复制到 Android 的 assets 目录 js/react_native/e2e/android/app/src/main/assets 供原生端打包使用而 iOS 侧 js/react_native/e2e/ios 的测试资产则全部采用.ort格式如test_types_bool.ort、test_types_double.ort从侧面印证了不同平台对模型格式装载方式的差异。二、模型来源从 Node.js 测试数据到移动端测试资产文档指出所有test_types_*.ort模型均转换自js/node/test/testdata/test_types_*.onnx。在 js/node/test/testdata 中共维护了 13 个原始 ONNX 模型覆盖 bool、double、float、float16、int16、int32、int64、int8、string、uint16、uint32、uint64、uint8 全部基础张量类型它们是 Node.js 侧 API 测试的公共数据参见 js/node/test/api/simple-api-tests.ts 中的引用。移动端 e2e 测试只选用了其中的 8 种类型形成一张清晰的类型覆盖矩阵Node 测试数据源.onnx转换后的 e2e 资产使用场景test_types_bool.onnxtest_types_bool.onnx完整构建下的 booltest_types_double.onnxtest_types_double.onnx完整构建下的 float64test_types_float.onnxtest_types_float.ort完整/移动构建共有的 float32test_types_float16.onnxtest_types_float16.ort完整/移动构建共有的 float16test_types_int8.onnxtest_types_int8.ort完整/移动构建共有的 int8test_types_uint8.onnxtest_types_uint8.ort完整/移动构建共有的 uint8test_types_int32.onnxtest_types_int32.ort完整/移动构建共有的 int32test_types_int64.onnxtest_types_int64.ort完整/移动构建共有的 int64三、批量转换convert_onnx_models_to_ort 命令实战3.1 原始转换命令完整复现依据文档在仓库根目录下执行以下两步即可完成转换注意两条命令的输出目录不同分别对应src与 Android assets 两个位置cd repo root/js python -m onnxruntime.tools.convert_onnx_models_to_ort \ --optimization_style Fixed \ --output_dir ./react_native/e2e/android/app/src/main/assets \ ./node/test/testdata python -m onnxruntime.tools.convert_onnx_models_to_ort \ --optimization_style Fixed \ --output_dir ./react_native/e2e/src \ ./node/test/testdata其中输入./node/test/testdata模型路径既可以是一个目录也可以是单个.onnx文件--output_dir指定 ORT 模型与配置文件输出位置--optimization_style Fixed采用固定优化风格详见下文 3.3 节。文档同时提醒转换过程会额外生成一些文件这些文件可以安全删除。要理解额外文件是什么需要查看工具的实际实现。3.2 转换工具的源码实现转换入口位于 tools/python/util/convert_onnx_models_to_ort.py。从源码结构看其核心行为包括批量处理目录下所有.onnx扩展名文件含子目录都会被处理见parse_args中的model_path_or_dir参数说明配置清单输出除 ORT 模型外还会为每个模型生成一份.config配置文件其中汇总了所有转换模型所需的算子列表供 minimal build最小化构建通过--include_ops_by_config参数使用命名规则转换产物文件名带有优化风格后缀——_optimization_suffix()函数会为Runtime风格追加.with_runtime_opt同时会区分.config、.ort与.optimized.onnx等不同产物这正是文档所提到额外生成文件的来源优化级别默认优化级别为all可通过环境变量ORT_CONVERT_ONNX_MODELS_TO_ORT_OPTIMIZATION_LEVEL调整目标平台开关--target_platform支持arm与amd64选择arm时会通过会话配置session.qdqisint8allowed1启用 ARM 上 QDQ 的 int8 支持同时影响 NCHWc/NHWC 等格式选择。3.3 两种优化风格Fixed 与 Runtime--optimization_style是转换中最关键的行为开关源码给出的语义如下Fixed固定优化在保存 ORT 格式模型之前直接运行优化将平台相关的优化结果烘焙进模型文件。适用于目标运行环境与转换环境一致、且节点分配在转换时即可确定的场景也是本仓库 React Native e2e 测试所选用的风格Runtime运行时优化仅保存基础优化将部分优化留待运行时应用。这适用于 NNAPI、CoreML 这类编译型执行提供方EP——因为这类 EP 在模型转换时可能还不知道最终会承接多少个节点运行时再回放优化可以进一步优化未被编译 EP 承接的节点。使用该风格时需在会话选项中启用session.enable_saved_runtime_optimizations且仅应对可信模型开启。命令行默认同时转换Fixed与Runtime两种风格default[OptimizationStyle.Fixed.name, OptimizationStyle.Runtime.name]本文场景显式指定Fixed可以只生成移动端直接可用的单一产物。此外工具还支持--enable_type_reduction向配置清单写入算子级别的类型信息进一步裁剪类型、--custom_op_library注册自定义算子 kernel 库、--save_optimized_onnx_model额外保存与 ORT 同级优化的.onnx版本与--allow_conversion_failures遇到转换失败继续处理其余模型等参数供更复杂的定制化转换场景使用。四、测试资产在 React Native 端的实际消费方式转换出的模型最终由 js/react_native/e2e/src/BasicTypesTest.tsx 消费。该组件内部定义了TEST_MODELS数组将 8 个资产文件与对应的 Tensor 数据类型一一绑定其加载与推理流程可作为 React Native 中加载 ORT 模型的规范参考读取资产Android 平台通过react-native-fs的readFileAssets(asset, base64)读取 assets 中的模型二进制iOS 则从RNFS.MainBundlePath下读取统一转成Buffer后交给InferenceSession.create(bytes)创建会话构造输入张量按数据类型构造对应长度的 TypedArray——bool 用Uint8Array0/1 交替填充、float32 用Float32Array、float16 用Uint16Array按 half 位模式、int64 用BigInt64ArrayBigInt 值等再通过new Tensor(dataType, data, [1, 5])封装为形状[1, 5]的张量运行推理并校验以session.inputNames[0]作为 feed 键调用session.run(feeds)检查session.outputNames[0]对应的输出张量是否存在并记录耗时ms将每个测试项的状态pending/running/success/error渲染到界面离开页面或重跑测试时统一调用session.release()释放会话。值得注意的实现细节int64 在 JavaScript 侧使用BigInt64Array承载这避免了 Number 精度损失也印证了 int64 模型在移动端测试中必须具备端到端可用的完整链路。五、验证与回归从 Node 到移动端的一致性test_types_*.onnx源模型并非只为移动端服务它们同时是 Node.js 侧 API 测试的公共数据js/node/test/api/simple-api-tests.ts 中对 13 个类型模型均有引用另有 js/node/test/unittests/lib/inference-session.ts 使用test_types_float.onnx验证 session 行为。这意味着Node 侧测试保证了源模型与类型语义的正确性移动端 e2e 测试验证了同一批语义在 ORT 格式与裁剪构建下的可用性两套测试共享同一模型源头形成同一数据、双端验证的回归闭环这正是test_types_models.readme.md所描述工作流的工程价值所在。在实际开发中若需新增一个数据类型例如补齐 uint16/uint32/uint64/string 的移动端覆盖只需在 Node 测试数据目录放置对应的.onnx模型运行第二节的转换命令将产物输出到 js/react_native/e2e/src 与 js/react_native/e2e/android/app/src/main/assets再在BasicTypesTest.tsx的TEST_MODELS中登记新条目即可整个流程无需手工编写任何模型文件。【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ONNX Runtime React Native 端到端测试：test_types 模型的 ONNX/ORT 双格式生成与转换实战
ONNX Runtime React Native 端到端测试test_types 模型的 ONNX/ORT 双格式生成与转换实战【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntime导读本文围绕 ONNX Runtime 仓库中 React Native 端到端e2e测试所使用的test_types_*.onnx/test_types_*.ort系列模型展开说明为什么同一组数据类型测试模型需要同时准备 ONNX 与 ORT 两种格式、二者分别服务于什么样的构建形态并给出从 Node.js 测试数据一键批量转换生成移动端测试资产的完整命令、工具参数解读与底层实现分析。读完本文你将掌握convert_onnx_models_to_ort转换工具的核心机制理解Fixed与Runtime两种优化风格的适用场景并能复现 React Native 端各数据类型的推理验证流程。一、为什么同一组模型需要 ONNX 与 ORT 两种格式在 js/react_native/e2e/src/test_types_models.readme.md 中项目明确给出了这一设计决策ONNX 格式模型用于仅在完整构建full build中才支持的数据类型ORT 格式模型用于在完整构建和移动构建mobile build中都支持的数据类型。ORT 格式.ort是 ONNX Runtime 的原生序列化格式它在模型加载时省去了 ONNX protobuf 解析环节并能内嵌预先完成的图优化结果因此是移动端Android/iOS 上的 React Native 环境首选的模型载体。由于移动构建会对算子集合进行裁剪某些数据类型的 kernel 只存在于完整构建中这部分类型就只能继续使用.onnx模型来测试。该策略的落地证据清晰可见——查看 js/react_native/e2e/src 目录实际存放的测试资产为数据类型文件e2e/src格式booltest_types_bool.onnxONNXdouble (float64)test_types_double.onnxONNXfloat (float32)test_types_float.ortORTfloat16test_types_float16.ortORTint8test_types_int8.ortORTuint8test_types_uint8.ortORTint32test_types_int32.ortORTint64test_types_int64.ortORT同一套文件也被复制到 Android 的 assets 目录 js/react_native/e2e/android/app/src/main/assets 供原生端打包使用而 iOS 侧 js/react_native/e2e/ios 的测试资产则全部采用.ort格式如test_types_bool.ort、test_types_double.ort从侧面印证了不同平台对模型格式装载方式的差异。二、模型来源从 Node.js 测试数据到移动端测试资产文档指出所有test_types_*.ort模型均转换自js/node/test/testdata/test_types_*.onnx。在 js/node/test/testdata 中共维护了 13 个原始 ONNX 模型覆盖 bool、double、float、float16、int16、int32、int64、int8、string、uint16、uint32、uint64、uint8 全部基础张量类型它们是 Node.js 侧 API 测试的公共数据参见 js/node/test/api/simple-api-tests.ts 中的引用。移动端 e2e 测试只选用了其中的 8 种类型形成一张清晰的类型覆盖矩阵Node 测试数据源.onnx转换后的 e2e 资产使用场景test_types_bool.onnxtest_types_bool.onnx完整构建下的 booltest_types_double.onnxtest_types_double.onnx完整构建下的 float64test_types_float.onnxtest_types_float.ort完整/移动构建共有的 float32test_types_float16.onnxtest_types_float16.ort完整/移动构建共有的 float16test_types_int8.onnxtest_types_int8.ort完整/移动构建共有的 int8test_types_uint8.onnxtest_types_uint8.ort完整/移动构建共有的 uint8test_types_int32.onnxtest_types_int32.ort完整/移动构建共有的 int32test_types_int64.onnxtest_types_int64.ort完整/移动构建共有的 int64三、批量转换convert_onnx_models_to_ort 命令实战3.1 原始转换命令完整复现依据文档在仓库根目录下执行以下两步即可完成转换注意两条命令的输出目录不同分别对应src与 Android assets 两个位置cd repo root/js python -m onnxruntime.tools.convert_onnx_models_to_ort \ --optimization_style Fixed \ --output_dir ./react_native/e2e/android/app/src/main/assets \ ./node/test/testdata python -m onnxruntime.tools.convert_onnx_models_to_ort \ --optimization_style Fixed \ --output_dir ./react_native/e2e/src \ ./node/test/testdata其中输入./node/test/testdata模型路径既可以是一个目录也可以是单个.onnx文件--output_dir指定 ORT 模型与配置文件输出位置--optimization_style Fixed采用固定优化风格详见下文 3.3 节。文档同时提醒转换过程会额外生成一些文件这些文件可以安全删除。要理解额外文件是什么需要查看工具的实际实现。3.2 转换工具的源码实现转换入口位于 tools/python/util/convert_onnx_models_to_ort.py。从源码结构看其核心行为包括批量处理目录下所有.onnx扩展名文件含子目录都会被处理见parse_args中的model_path_or_dir参数说明配置清单输出除 ORT 模型外还会为每个模型生成一份.config配置文件其中汇总了所有转换模型所需的算子列表供 minimal build最小化构建通过--include_ops_by_config参数使用命名规则转换产物文件名带有优化风格后缀——_optimization_suffix()函数会为Runtime风格追加.with_runtime_opt同时会区分.config、.ort与.optimized.onnx等不同产物这正是文档所提到额外生成文件的来源优化级别默认优化级别为all可通过环境变量ORT_CONVERT_ONNX_MODELS_TO_ORT_OPTIMIZATION_LEVEL调整目标平台开关--target_platform支持arm与amd64选择arm时会通过会话配置session.qdqisint8allowed1启用 ARM 上 QDQ 的 int8 支持同时影响 NCHWc/NHWC 等格式选择。3.3 两种优化风格Fixed 与 Runtime--optimization_style是转换中最关键的行为开关源码给出的语义如下Fixed固定优化在保存 ORT 格式模型之前直接运行优化将平台相关的优化结果烘焙进模型文件。适用于目标运行环境与转换环境一致、且节点分配在转换时即可确定的场景也是本仓库 React Native e2e 测试所选用的风格Runtime运行时优化仅保存基础优化将部分优化留待运行时应用。这适用于 NNAPI、CoreML 这类编译型执行提供方EP——因为这类 EP 在模型转换时可能还不知道最终会承接多少个节点运行时再回放优化可以进一步优化未被编译 EP 承接的节点。使用该风格时需在会话选项中启用session.enable_saved_runtime_optimizations且仅应对可信模型开启。命令行默认同时转换Fixed与Runtime两种风格default[OptimizationStyle.Fixed.name, OptimizationStyle.Runtime.name]本文场景显式指定Fixed可以只生成移动端直接可用的单一产物。此外工具还支持--enable_type_reduction向配置清单写入算子级别的类型信息进一步裁剪类型、--custom_op_library注册自定义算子 kernel 库、--save_optimized_onnx_model额外保存与 ORT 同级优化的.onnx版本与--allow_conversion_failures遇到转换失败继续处理其余模型等参数供更复杂的定制化转换场景使用。四、测试资产在 React Native 端的实际消费方式转换出的模型最终由 js/react_native/e2e/src/BasicTypesTest.tsx 消费。该组件内部定义了TEST_MODELS数组将 8 个资产文件与对应的 Tensor 数据类型一一绑定其加载与推理流程可作为 React Native 中加载 ORT 模型的规范参考读取资产Android 平台通过react-native-fs的readFileAssets(asset, base64)读取 assets 中的模型二进制iOS 则从RNFS.MainBundlePath下读取统一转成Buffer后交给InferenceSession.create(bytes)创建会话构造输入张量按数据类型构造对应长度的 TypedArray——bool 用Uint8Array0/1 交替填充、float32 用Float32Array、float16 用Uint16Array按 half 位模式、int64 用BigInt64ArrayBigInt 值等再通过new Tensor(dataType, data, [1, 5])封装为形状[1, 5]的张量运行推理并校验以session.inputNames[0]作为 feed 键调用session.run(feeds)检查session.outputNames[0]对应的输出张量是否存在并记录耗时ms将每个测试项的状态pending/running/success/error渲染到界面离开页面或重跑测试时统一调用session.release()释放会话。值得注意的实现细节int64 在 JavaScript 侧使用BigInt64Array承载这避免了 Number 精度损失也印证了 int64 模型在移动端测试中必须具备端到端可用的完整链路。五、验证与回归从 Node 到移动端的一致性test_types_*.onnx源模型并非只为移动端服务它们同时是 Node.js 侧 API 测试的公共数据js/node/test/api/simple-api-tests.ts 中对 13 个类型模型均有引用另有 js/node/test/unittests/lib/inference-session.ts 使用test_types_float.onnx验证 session 行为。这意味着Node 侧测试保证了源模型与类型语义的正确性移动端 e2e 测试验证了同一批语义在 ORT 格式与裁剪构建下的可用性两套测试共享同一模型源头形成同一数据、双端验证的回归闭环这正是test_types_models.readme.md所描述工作流的工程价值所在。在实际开发中若需新增一个数据类型例如补齐 uint16/uint32/uint64/string 的移动端覆盖只需在 Node 测试数据目录放置对应的.onnx模型运行第二节的转换命令将产物输出到 js/react_native/e2e/src 与 js/react_native/e2e/android/app/src/main/assets再在BasicTypesTest.tsx的TEST_MODELS中登记新条目即可整个流程无需手工编写任何模型文件。【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
