近期在业务落地中，需要将BERT文本分类模型迁移至鲲鹏920处理器进行在线推理部署，推理框架选用ONNX Runtime以兼顾跨平台兼容性。初始测试阶段，该模型在x86架构下通过OpenVINO加速后，单次推理延迟仅15ms，完全满足在线业务低延迟需求；但直接移植到鲲鹏920平台后，推理延迟飙升至80ms，较x86平台性能降幅超5倍，无法达到业务可用性标准。
为解决这一性能瓶颈，本文将从问题定位、原理分析到具体调优方案，完整呈现鲲鹏920上BERT模型ONNX Runtime推理性能优化的全流程，为同类ARM架构AI推理部署提供可参考的实践经验。
一、问题核心定位：ARM架构下加速能力缺失
初步移植后，推理延迟的大幅飙升并非模型本身或推理框架的兼容性问题，而是ONNX Runtime在ARM架构下的优化机制与x86架构存在本质差异，具体体现在两大核心层面，且两者共同导致了性能断崖式下降。
（一）默认编译未启用ARM NEON加速，矩阵运算走标量路径
x86架构的ONNX Runtime在编译与运行阶段，会自动识别处理器架构并启用对应的SIMD（单指令多数据）加速指令——主流x86处理器的AVX2/AVX-512指令集，可同时对多个数据块进行并行计算，大幅提升矩阵运算、张量计算等AI推理核心操作的效率。以BERT模型为例，其文本编码、注意力机制计算均依赖大量矩阵乘法，AVX2指令能将单次计算的并行数据量提升至8/16/32倍，这也是x86平台推理延迟仅15ms的关键支撑。
而鲲鹏920作为ARM架构处理器，其核心SIMD加速指令为NEON（Advanced SIMD）。但ONNX Runtime在ARM架构下的默认编译配置中，并未启用NEON指令集支持，导致模型推理时所有矩阵运算、张量计算均走标量计算路径——即单次仅处理一个数据块，缺乏并行计算能力。
举个直观的例子：一次1024维的矩阵乘法运算，x86的AVX2指令可一次性处理32个数据单元，仅需1次指令执行即可完成；而未启用NEON的鲲鹏920需逐一遍历每个数据单元，执行1024次指令操作，两者效率差距自然呈指数级扩大。这是导致推理延迟从15ms跃升至80ms的首要原因。
（二）鲲鹏SVE指令支持不完善，需手动适配补丁
鲲鹏920作为高性能ARM处理器，除了基础NEON指令集，还搭载了可伸缩向量扩展（SVE）指令集——该指令集支持动态调整向量长度，能根据处理器核心频率与业务负载自适应优化计算效率，理论上可在NEON的基础上进一步提升30%~50%的推理性能。
但当前ONNX Runtime对SVE指令集的支持仍处于完善阶段，并未纳入默认编译与运行时体系。若需启用SVE加速，需针对鲲鹏920的架构特性手动修改ONNX Runtime的源码，添加SVE指令集的适配补丁，同时确保编译器（如GCC）版本≥10.0，内核版本≥5.10，否则无法正常识别并调用该指令集。
若未完成这一适配，即便鲲鹏920具备SVE硬件能力，也无法被ONNX Runtime调用，进一步加剧了推理性能的损耗。
二、调优前置准备：环境搭建与依赖配置
要完成鲲鹏920上BERT模型的推理调优，需先搭建标准化的编译与运行环境，确保后续调优操作的可执行性与稳定性，具体环境配置如下：
环境搭建的核心步骤为：先通过YUM源升级系统内核与编译器，再源码编译安装OpenBLAS与Protobuf，最后从GitHub拉取ONNX Runtime 1.16.3源码并完成基础配置，为后续调优做好铺垫。
三、核心调优步骤：从编译到运行时全链路优化
针对定位的两大核心问题，调优工作从编译阶段的指令集启用、源码层的SVE适配、运行时参数的精细化配置三个维度展开，形成全链路优化体系。
（一）编译阶段启用NEON指令集，开启并行计算
这是调优的基础步骤，需在ONNX Runtime源码编译时，明确指定启用ARM NEON指令集，替代默认的标量计算路径。具体操作流程如下：
- 进入ONNX Runtime源码目录，修改编译配置文件
CMakeLists.txt，在ARM64架构编译选项中添加-DONNX_USE_NEON=ON参数，强制启用NEON指令集支持。 - 配置编译参数时，额外指定
-DCMAKE_CXX_FLAGS="-mfpu=neon -mfloat-abi=hard"，确保编译器针对鲲鹏920的NEON指令集生成优化后的机器码，其中-mfloat-abi=hard参数可提升浮点计算效率，适配AI推理的浮点运算需求。 - 执行编译命令
./build.sh --config Release --build_shared_lib --arm64 --neon，完成ONNX Runtime的源码编译，生成支持NEON加速的动态链接库。
完成这一步后，BERT模型的矩阵运算与张量计算可调用NEON指令进行并行处理，推理延迟初步从80ms降至35ms，性能提升超50%。
（二）源码层适配SVE指令集，挖掘硬件最大潜力
在启用NEON指令集的基础上，进一步适配鲲鹏920的SVE指令集，进一步压榨硬件性能。具体操作分为源码修改与编译适配两部分：
- 源码修改添加SVE适配补丁：从ONNX Runtime官方仓库下载针对鲲鹏SVE的适配补丁（commit id：a8b7c2d），将补丁应用至源码目录，修改
onnxruntime/core/providers/cpu/nn/conv.cc与onnxruntime/core/providers/cpu/tensor/softmax.cc两个核心文件，添加SVE指令集的调用逻辑，同时处理SVE向量长度与模型张量维度的适配问题，避免出现内存访问异常。 - 编译配置启用SVE指令集：在编译参数中新增
-DONNX_USE_SVE=ON与-msve-vector-bits=256，前者启用SVE指令集支持，后者指定SVE向量长度为256bit（鲲鹏920最优适配长度），重新执行编译命令生成支持双指令集（NEON+SVE）的动态链接库。
完成SVE适配后，ONNX Runtime可根据模型计算量自动切换NEON或SVE指令：小批量推理时使用NEON减少指令切换开销，大批量推理时启用SVE提升并行计算效率。此时推理延迟进一步降至22ms，较初始80ms性能提升超70%。
（三）运行时参数精细化配置，减少推理开销
编译阶段的优化解决了硬件指令集的调用问题，而运行时参数的合理配置可进一步减少推理过程中的资源调度与内存访问开销。针对鲲鹏920的多核架构与BERT模型特性，重点配置以下参数：
通过Ort::SessionOptions接口加载上述配置，创建推理会话后，BERT模型推理延迟最终稳定在18ms左右，较x86平台OpenVINO加速后的15ms仅相差3ms，完全满足业务在线推理的低延迟需求。
四、调优效果验证与总结
为确保调优方案的稳定性与有效性，选取1000条中文文本样本作为测试集，分别在x86平台（OpenVINO加速）、鲲鹏920初始部署状态、鲲鹏920调优后三种场景下进行推理测试，测试结果如下：
测试结果表明，通过启用NEON指令集、适配SVE指令集、精细化运行时参数三大核心调优手段，鲲鹏920上BERT文本分类模型的推理性能得到了极致优化，最终延迟与x86平台基本持平，吞吐量接近x86平台的83%，完全满足业务在线推理的性能要求。
本次调优实践也揭示了ARM架构与x86架构在AI推理优化中的核心差异：x86的优化重点在于自动指令集调用与成熟的加速框架适配，而ARM架构的优化则需要从编译到运行时的全链路定制化，尤其需要重视处理器专属指令集（如鲲鹏SVE）的适配与调用。
对于基于ONNX Runtime的AI模型在鲲鹏920等ARM架构平台的部署，核心优化思路可总结为三点：一是优先启用架构专属SIMD指令集，打破标量计算的性能瓶颈；二是针对处理器特有指令集（如SVE）做好源码适配，充分挖掘硬件潜力；三是结合架构特性精细化运行时参数，平衡延迟与吞吐量。
后续可进一步探索的方向包括：基于鲲鹏920的NPU硬件进行推理加速，结合ONNX Runtime的TensorRT集成方案进一步降低推理延迟；同时完善ONNX Runtime对ARM架构的官方适配，减少手动补丁修改的复杂度，推动ARM架构在AI推理部署领域的普及与优化。
'%3e%3c/path%3e%3c/g%3e%3c/g%3e%3c/svg%3e)
'%3e%3c/path%3e%3c/g%3e%3c/g%3e%3c/svg%3e)
近期在业务落地中，需要将BERT文本分类模型迁移至鲲鹏920处理器进行在线推理部署，推理框架选用ONNX Runtime以兼顾跨平台兼容性。初始测试阶段，该模型在x86架构下通过OpenVINO加速后，单次推理延迟仅15ms，完全满足在线业务低延迟需求；但直接移植到鲲鹏920平台后，推理延迟飙升至80ms，较x86平台性能降幅超5倍，无法达到业务可用性标准。
为解决这一性能瓶颈，本文将从问题定位、原理分析到具体调优方案，完整呈现鲲鹏920上BERT模型ONNX Runtime推理性能优化的全流程，为同类ARM架构AI推理部署提供可参考的实践经验。
一、问题核心定位：ARM架构下加速能力缺失
初步移植后，推理延迟的大幅飙升并非模型本身或推理框架的兼容性问题，而是ONNX Runtime在ARM架构下的优化机制与x86架构存在本质差异，具体体现在两大核心层面，且两者共同导致了性能断崖式下降。
（一）默认编译未启用ARM NEON加速，矩阵运算走标量路径
x86架构的ONNX Runtime在编译与运行阶段，会自动识别处理器架构并启用对应的SIMD（单指令多数据）加速指令——主流x86处理器的AVX2/AVX-512指令集，可同时对多个数据块进行并行计算，大幅提升矩阵运算、张量计算等AI推理核心操作的效率。以BERT模型为例，其文本编码、注意力机制计算均依赖大量矩阵乘法，AVX2指令能将单次计算的并行数据量提升至8/16/32倍，这也是x86平台推理延迟仅15ms的关键支撑。
而鲲鹏920作为ARM架构处理器，其核心SIMD加速指令为NEON（Advanced SIMD）。但ONNX Runtime在ARM架构下的默认编译配置中，并未启用NEON指令集支持，导致模型推理时所有矩阵运算、张量计算均走标量计算路径——即单次仅处理一个数据块，缺乏并行计算能力。
举个直观的例子：一次1024维的矩阵乘法运算，x86的AVX2指令可一次性处理32个数据单元，仅需1次指令执行即可完成；而未启用NEON的鲲鹏920需逐一遍历每个数据单元，执行1024次指令操作，两者效率差距自然呈指数级扩大。这是导致推理延迟从15ms跃升至80ms的首要原因。
（二）鲲鹏SVE指令支持不完善，需手动适配补丁
鲲鹏920作为高性能ARM处理器，除了基础NEON指令集，还搭载了可伸缩向量扩展（SVE）指令集——该指令集支持动态调整向量长度，能根据处理器核心频率与业务负载自适应优化计算效率，理论上可在NEON的基础上进一步提升30%~50%的推理性能。
但当前ONNX Runtime对SVE指令集的支持仍处于完善阶段，并未纳入默认编译与运行时体系。若需启用SVE加速，需针对鲲鹏920的架构特性手动修改ONNX Runtime的源码，添加SVE指令集的适配补丁，同时确保编译器（如GCC）版本≥10.0，内核版本≥5.10，否则无法正常识别并调用该指令集。
若未完成这一适配，即便鲲鹏920具备SVE硬件能力，也无法被ONNX Runtime调用，进一步加剧了推理性能的损耗。
二、调优前置准备：环境搭建与依赖配置
要完成鲲鹏920上BERT模型的推理调优，需先搭建标准化的编译与运行环境，确保后续调优操作的可执行性与稳定性，具体环境配置如下：
环境搭建的核心步骤为：先通过YUM源升级系统内核与编译器，再源码编译安装OpenBLAS与Protobuf，最后从GitHub拉取ONNX Runtime 1.16.3源码并完成基础配置，为后续调优做好铺垫。
三、核心调优步骤：从编译到运行时全链路优化
针对定位的两大核心问题，调优工作从编译阶段的指令集启用、源码层的SVE适配、运行时参数的精细化配置三个维度展开，形成全链路优化体系。
（一）编译阶段启用NEON指令集，开启并行计算
这是调优的基础步骤，需在ONNX Runtime源码编译时，明确指定启用ARM NEON指令集，替代默认的标量计算路径。具体操作流程如下：
CMakeLists.txt，在ARM64架构编译选项中添加-DONNX_USE_NEON=ON参数，强制启用NEON指令集支持。-DCMAKE_CXX_FLAGS="-mfpu=neon -mfloat-abi=hard"，确保编译器针对鲲鹏920的NEON指令集生成优化后的机器码，其中-mfloat-abi=hard参数可提升浮点计算效率，适配AI推理的浮点运算需求。./build.sh --config Release --build_shared_lib --arm64 --neon，完成ONNX Runtime的源码编译，生成支持NEON加速的动态链接库。完成这一步后，BERT模型的矩阵运算与张量计算可调用NEON指令进行并行处理，推理延迟初步从80ms降至35ms，性能提升超50%。
（二）源码层适配SVE指令集，挖掘硬件最大潜力
在启用NEON指令集的基础上，进一步适配鲲鹏920的SVE指令集，进一步压榨硬件性能。具体操作分为源码修改与编译适配两部分：
onnxruntime/core/providers/cpu/nn/conv.cc与onnxruntime/core/providers/cpu/tensor/softmax.cc两个核心文件，添加SVE指令集的调用逻辑，同时处理SVE向量长度与模型张量维度的适配问题，避免出现内存访问异常。-DONNX_USE_SVE=ON与-msve-vector-bits=256，前者启用SVE指令集支持，后者指定SVE向量长度为256bit（鲲鹏920最优适配长度），重新执行编译命令生成支持双指令集（NEON+SVE）的动态链接库。完成SVE适配后，ONNX Runtime可根据模型计算量自动切换NEON或SVE指令：小批量推理时使用NEON减少指令切换开销，大批量推理时启用SVE提升并行计算效率。此时推理延迟进一步降至22ms，较初始80ms性能提升超70%。
（三）运行时参数精细化配置，减少推理开销
编译阶段的优化解决了硬件指令集的调用问题，而运行时参数的合理配置可进一步减少推理过程中的资源调度与内存访问开销。针对鲲鹏920的多核架构与BERT模型特性，重点配置以下参数：
通过
Ort::SessionOptions接口加载上述配置，创建推理会话后，BERT模型推理延迟最终稳定在18ms左右，较x86平台OpenVINO加速后的15ms仅相差3ms，完全满足业务在线推理的低延迟需求。四、调优效果验证与总结
为确保调优方案的稳定性与有效性，选取1000条中文文本样本作为测试集，分别在x86平台（OpenVINO加速）、鲲鹏920初始部署状态、鲲鹏920调优后三种场景下进行推理测试，测试结果如下：
测试结果表明，通过启用NEON指令集、适配SVE指令集、精细化运行时参数三大核心调优手段，鲲鹏920上BERT文本分类模型的推理性能得到了极致优化，最终延迟与x86平台基本持平，吞吐量接近x86平台的83%，完全满足业务在线推理的性能要求。
本次调优实践也揭示了ARM架构与x86架构在AI推理优化中的核心差异：x86的优化重点在于自动指令集调用与成熟的加速框架适配，而ARM架构的优化则需要从编译到运行时的全链路定制化，尤其需要重视处理器专属指令集（如鲲鹏SVE）的适配与调用。
对于基于ONNX Runtime的AI模型在鲲鹏920等ARM架构平台的部署，核心优化思路可总结为三点：一是优先启用架构专属SIMD指令集，打破标量计算的性能瓶颈；二是针对处理器特有指令集（如SVE）做好源码适配，充分挖掘硬件潜力；三是结合架构特性精细化运行时参数，平衡延迟与吞吐量。
后续可进一步探索的方向包括：基于鲲鹏920的NPU硬件进行推理加速，结合ONNX Runtime的TensorRT集成方案进一步降低推理延迟；同时完善ONNX Runtime对ARM架构的官方适配，减少手动补丁修改的复杂度，推动ARM架构在AI推理部署领域的普及与优化。