Paddle-Lite 端侧推理性能优化最佳实践从模型选型到异构加速的完整指南【免费下载链接】Paddle-LitePaddlePaddle High Performance Deep Learning Inference Engine for Mobile and Edge (飞桨高性能深度学习端侧推理引擎项目地址: https://gitcode.com/GitHub_Trending/pa/Paddle-Lite移动端与嵌入式设备的算力、内存和能耗都极其有限如何让深度学习模型在资源受限的硬件上跑得快、占用少是端侧推理部署的核心挑战。本文以 Paddle-Lite飞桨高性能深度学习端侧推理引擎为背景系统梳理端侧模型性能优化的完整方法论从「按任务选择模型」开始到使用内置 Profiler 定位性能瓶颈再分别从模型与算法思想、硬件特点、特定应用场景三个维度展开优化手段最后介绍第三方性能分析工具与 GPU/NPU/APU 异构加速方案。读完本文你将掌握一套「选模型 → 分析 → 优化 → 验证」的可复现流程并能够借助仓库内文档与源码快速落地。一、为什么端侧推理必须讲求性能优化移动设备和嵌入式设备的计算资源有限电池容量、散热能力与内存带宽都远逊于服务器。Paddle Lite 作为面向服务器端、边缘端和移动端场景的推理引擎见 lite/core 目录下的核心实现其性能优化的出发点正是在不改变模型功能的前提下提高应用的资源效率——包括降低单次推理耗时、减少内存占用、控制功耗与发热。Paddle Lite 的整个推理流程可以分成**分析Analysis与执行Execution**两个阶段分析阶段完成模型加载解析、计算图转化、图分析与优化Pass、运行时程序生成执行阶段则按拓扑顺序运行指令。图优化阶段中诸如算子融合、内存复用等 Pass 都会直接作用于端侧性能因此理解这些优化手段是掌握性能优化方法的前提。更多架构细节可参考 docs/develop_guides/architecture-intro.md。二、第一步基于任务选择最佳模型性能优化的起点不是调优而是选型。您需要根据任务在模型复杂性和模型大小之间进行权衡如果任务需要高准确率例如医学影像、精细分割那么可能需要一个大而复杂的模型对于准确率要求较低的任务例如实时手势识别、基础目标检测则最好使用较小的模型。小模型不仅占用的磁盘空间和内存更少而且通常速度更快、更节能。选型时建议遵循「够用即最优」的原则先确定业务可接受的准确率下限再在该约束下选择参数量与计算量最小的候选模型。这一步直接决定了后续所有优化的天花板——再优秀的推理引擎也无法让一个超大模型在低端设备上达到实时帧率。三、第二步基于模型进行性能分析Profiler 定位瓶颈在选定候选模型后下一步是量化分析其性能。Paddle Lite 内置的 Profiler 工具 带有性能分析器可以展示每个算子的性能分析数据帮助理解性能瓶颈在哪一层、哪些算子占据了大部分计算时间。3.1 性能 Profiler 的开启方式性能 Profiler 用于逐层耗时统计可获取模型逐层在 ARM CPU / X86 CPU / OpenCL 上的 kernel 耗时信息。编译 full_publish 预测库时加入编译选项--with_profileON即可开启。例如 Android 平台./lite/tools/build_android.sh \ --archarmv8 \ --toolchainclang \ --android_stlc_static \ --with_profileON \ full_publishx86 Linux 平台./lite/tools/build_linux.sh \ --with_profileON \ full_publish其它平台可参照各平台的编译文档如 docs/source_compile 下的各平台编译指南同时加上--with_profileON选项即可。3.2 Profiler 输出数据的解读编译完成后进入build.lite.android.armv8.clang/inference_lite_lib.android.armv8/demo/cxx/mobile_light/目录执行make将生成的可执行文件mobilenetv1_light_api、动态库libpaddle_light_api_shared.so与模型mobilenet_v1.nb通过 ADB 发送到手机同一目录执行./mobilenetv1_light_api ./mobilenet_v1.nb会打印三类日志Detailed Dispatch Profiler Summary单次推理的逐 OP 底层 Kernel 层运行耗时即在KernelBase::Run()的前后统计耗时会排除第一次的计时第一次相当于 warm-upConcise Create Profiler Summary汇总统计的创建 Op 的耗时即从Instruction::Run()开始到KernelBase::Run()执行前会排除前 10 次推理Concise Dispatch Profiler Summary汇总统计的运行 Op 的耗时在KernelBase::Run()前后统计为 Lite 具体设备的底层 Kernel 层完整耗时会排除前 10 次推理。命令默认推理 100 次。最后一次的 Detailed Dispatch Profiler Summary 示例截取关键行如下 Detailed Dispatch Profiler Summary: N/A, Exclude 1 warm-ups OperatorType KerneAttr(Place) KernelFuncName Remark InDim FilterDim OutDim Avg(ms) Min(ms) Max(ms) Last(ms) Avg(%) GOPs GOPS conv2d arm/float/NCHW conv_3x3s2_direct_fp32 3x3p1s2g1d1BiasRelu 1x3x224x224 32x3x3x3 1x32x112x112 0.735 0.709 0.865 0.718 2.60% 0.022 29.50 conv2d arm/float/NCHW conv1x1s1_gemm_fp32 1x1p0s1g1d1BiasRelu 1x32x112x112 64x32x1x1 1x64x112x112 1.370 1.347 1.445 1.368 4.85% 0.051 37.51 conv2d arm/float/NCHW conv1x1s1_gemm_fp32 1x1p0s1g1d1BiasRelu 1x128x56x56 128x128x1x1 1x128x56x56 2.436 2.410 2.526 2.433 8.62% 0.103 42.19 conv2d arm/float/NCHW conv1x1s1_gemm_fp32 1x1p0s1g1d1BiasRelu 1x512x14x14 512x512x1x1 1x512x14x14 2.360 2.316 2.401 2.357 8.35% 0.103 43.55 pool2d arm/float/NCHW NotImpl globalavgEXPLICIT 1x1024x7x7 N/A 1x1024x1x1 0.014 0.012 0.029 0.013 0.05% 0.000 3.63 fc arm/float/NCHW NotImpl Bias 1x1024x1x1 1024x1000 1x1000 0.287 0.271 0.324 0.293 1.01% 0.003 10.71 softmax arm/float/NCHW NotImpl axis-1 1x1000 N/A 1x1000 0.006 0.005 0.008 0.006 0.02% 0.000 0.95逐行字段含义OperatorType为算子类型KerneAttr(Place)为目标设备/精度/数据排布KernelFuncName为实际调用的底层 kernel 函数名例如conv1x1s1_gemm_fp32、conv_3x3s2_direct_fp32Remark描述了卷积参数3x3 核、pad1、stride2、group1、含 Bias 与 ReluInDim/FilterDim/OutDim给出输入/权重/输出维度Avg/Min/Max/Last为耗时统计毫秒Avg(%)是该算子占总耗时的百分比GOPs为浮点运算量GOPS为每秒十亿次运算数吞吐。此外还有汇总输出例如 Concise Dispatch Profiler Summary Concise Dispatch Profiler Summary: N/A, Exclude 10 warm-ups OperatorType KerneAttr(Place) KernelFuncName Avg(ms) Min(ms) Max(ms) Avg(%) GOPs CalledTimes conv2d arm/float/NCHW conv1x1s1_gemm_fp32 25.381 24.985 25.896 89.79% 1.079 13 conv2d arm/float/NCHW conv_3x3s2_direct_fp32 0.727 0.709 0.793 2.57% 0.022 1 depthwise_conv2d arm/float/NCHW conv_depthwise_3x3_fp32 1.855 1.810 2.160 6.56% 0.035 13 fc arm/float/NCHW NotImpl 0.285 0.277 0.318 1.01% 0.003 1 pool2d arm/float/NCHW NotImpl 0.013 0.012 0.015 0.05% 0.000 1 softmax arm/float/NCHW NotImpl 0.006 0.005 0.008 0.02% 0.000 1上面是 Android 端 ARM CPU 的性能 Profiler 结果。可以看到conv1x1s1_gemm_fp32一个 kernel 就占了总耗时的 89.79%此时优化重点应明确指向 1x1 卷积的 GEMM 实现。3.3 精度 Profiler 与逐层数据核验除了耗时还可以用精度 Profiler编译时加--with_precision_profileON逐层统计每个 Op 输出 tensor 的精度信息用于排查模型在特定设备上精度是否异常。其输出对每个 output tensor 提供三个数值均值mean该 tensor 所有元素的和值除以元素个数反映整体平均值标准差std_deviationtensor 距离均值的波动程度一般来说均值和标准差就能确定该 tensor 的正确性序列值ave_grow_rate反映 tensor 从起始元素到最后一个元素的序列变化情况。当两组 tensor 均值和标准差一样但元素位次不同时该值不同。序列值的计算伪代码为// compute ave_grow_rate of tensor output for (size_t i 1; i output.length; i) { ave_grow_rate (output[i] - output[i - 1]) / (output[i - 1] eps); } ave_grow_rate / output.length;若需保存每个 OP 的每个输出到文件可在 ADB Shell 中执行前加入export PADDLELITE_PRECISION_WRITE_TO_FILE1每层输出会以PaddleLite前缀加时间戳的命名方式保存在不同文件夹中。从源码结构看Profiler 的信息采集分为两层Op 层信息通过Instruction::SetProfileRuntimeOpInfo调用OpLite-GetOpRuntimeInfo(profile::OpCharacter*)获取例如 lite/operators/conv_op.h 中ConvOpLite重写了该方法Kernel 层信息则通过KernelBase::SetProfileRuntimeKernelInfo(profile::OpCharacter* ch)这一虚函数借助多态机制获取具体底层 Kernel 名例如ReluCompute等派生 Kernel 类。最终通过profile::OpCharacter结构体把 Op 层与 Kernel 层信息串联起来。关于 Profiler 的架构设计细节可查看 docs/user_guides/profiler.md。3.4 由 Profiler 结果驱动的三个优化方向获得每个算子的性能数据后可按照以下三个方面完成模型性能优化基于模型和算法思想的性能优化基于硬件特点的性能优化基于特定场景/特定模型的性能优化。下面分别展开。四、基于模型和算法思想的性能优化4.1 优先选择最小模型与量化首先根据需求选择最小的模型进行推理因为这些模型通常更快、更节能。Paddle Lite 支持量化等多种优化技术具体细节可查看 量化文档。Paddle 模型的量化包含三种方法动态离线量化主要用于减小模型体积、静态离线量化和量化训练二者既可以减小模型体积也可以加快性能性能加速基本相同。建议首先使用静态离线量化方法docs/user_guides/quant/quant_post_static.md如果量化模型精度损失较大再尝试量化训练。量化训练需要预训练模型和较多训练数据通常大于 5000 样本其思想是在训练阶段使用模拟量化更新权重从而减小量化误差。以在安卓手机 ARM 端进行量化模型预测为例先用模型转换工具 OPT 将量化模型转换为移动端预测模型./OPT --model_dir./mobilenet_v1_quant \ --optimize_out_typenaive_buffer \ --optimize_outmobilenet_v1_quant_opt \ --valid_targetsarm转换后的.nb模型即可在 Android/iOS App 中加载预测。量化对于端侧的意义在于不仅减小模型体积与内存占用而且 int8 计算在 ARM CPU 上可通过 SIMD/DOTPROD 指令显著提速是「基于算法思想」这一维度性价比最高的优化手段。4.2 分析模型结构寻找可融合算子其次分析模型结构查看是否有可融合的算子如convolution和batchnorm可融合成单个convolution实现或可并行计算的分支以减少模型的计算量或 I/O 操作。这种情况一般不多见因为 Paddle Lite 已完成大部分融合算子添加——这一点可以从RunDefaultOptimizer的 Pass 列表中得到验证见 lite/core/optimizer/optimizer.cc 中的 Pass 顺序列表其中包含lite_conv_elementwise_fuse_pass、lite_conv_bn_fuse_pass、lite_conv_activation_fuse_pass等一系列融合 Pass。典型融合示例fc_fuse_pass将相邻的mul算子与elementwise_add算子融合成一个FC算子mul(X) X * W elementwise_add( mul(x) ) X * W Bias //---------- after fusion FC(X) X * W BiasPass 层面对这种「mul elementwise_add → fc」的图结构替换属于典型的图优化。Paddle Lite 中每一类 Pass 定义一种优化过程包括 kernel 选取、OP 融合、冗余 OP 去除、子图创建、内存优化、类型推导与类型转换等详见 新增 Pass 文档。如果您发现了更好的融合算子支持可参考 docs/develop_guides/add_new_pass.md 添加新的融合算子支持。4.3 深挖热点算子的算法实现最后分析模型中占比高算子的算法思想查看是否还有可优化的空间。例如针对 Profiler 中耗时占比最高的conv1x1s1_gemm_fp32其本质是 1x1 卷积转化为 GEMM通用矩阵乘法。Paddle Lite 在 lite/backends/arm/math 下实现了多种卷积算法变体包括conv3x3_winograd_fp32_c4.cc/conv_winograd_3x3.ccWinograd 变换加速 3x3 卷积conv3x3s2_direct_fp32.cc3x3 stride2 的直接卷积packed_sgemm.cc及sgemm系列ARM 汇编级矩阵乘并在__aarch64__且开启LITE_WITH_ARM8_SVE2时使用 SVE2 指令在WITH_ARM_DOTPROD时使用点积指令见 lite/backends/arm/math/conv_impl.cc。这些实现覆盖 fp32/fp16/int8 等多种精度正是「算法思想优化」在 Kernel 层面的落地。目前 Paddle Lite 已为大多数算子提供了优化版本如果您有更好的实现方法可以参考 新增 OP 文档 添加实现该文档以 Argmax 为例完整介绍了从 OpParam、OpLite 注册到各后端 Kernel 绑定与单测的全流程。五、基于硬件特点的性能优化5.1 针对处理器微架构的优化根据您使用的硬件设备结构特点查看热点算子是否仍有优化空间。目前 Paddle Lite 已支持大部分硬件优化。以 ARM CPU 为例针对不同微架构处理器如 A53、A35 等小核处理器以及 A73、A75 等大核处理器提供了三类处理器的优化实现——这类针对性的指令调度与寄存器分配优化能够最大化利用目标 CPU 的乱序执行能力与访存带宽。从源码上看ARM 后端在 lite/backends/arm 下集中实现了数学库gemm、conv、pool、activation 等并通过编译期宏如__aarch64__、LITE_WITH_ARM8_SVE2、WITH_ARM_DOTPROD在运行时精度与指令集层面做分支选择从而适配不同芯片能力。如果您发现其他硬件可进一步优化也欢迎参考 新增硬件文档 或 新增 OP 文档 添加新的硬件优化实现。5.2 硬件接入的两类方式延伸值得说明的是针对「新硬件」的优化Paddle Lite 提供了两类接入方式详见 docs/develop_guides/add_hardware.md算子 Kernel 接入方式在 lite/kernels 下为新增硬件实现各算子的 Kernel并建议在 lite/backends 下封装统一的数学运算接口剥离硬件细节子图接入方式依据硬件支持能力将计算图分割为若干子图通过「算子标记 → 子图检测反向 DFS→ 子图融合」把可转换的算子交给硬件 IR 执行框架中实现参考 NNAdapterSubgraphPass。六、基于特定场景/特定模型的性能优化6.1 从整机视角定位可优化环节基于您目前的使用场景分析各部分应用耗时占比选择占比高的部分用其他方法优化实现进而提高整个应用程序的性能。性能瓶颈往往不只在模型推理本身还分布在图像采集、数据预处理、前后处理、结果显示等环节。例如应用包含前后预处理实现时可以基于硬件添加前后预处理的优化实现。Paddle Lite 已提供部分图像算子的优化实现如用 ARM 汇编实现 OpenCV 图像处理算子可供直接调用从而将「解码 → 缩放 → 归一化 → 推理」整条流水线的耗时一并压下来。6.2 端到端性能测试工具支撑为了支撑上述「场景级」优化Paddle Lite 提供了 Benchmark 工具详见 docs/performance/benchmark_tools.md可输出初始化耗时、首帧耗时、平均耗时等指标并支持以 Paddle combined/uncombined 格式或.nb格式模型作为输入支持单输入和多输入模型、从文本读取输入数据支持设置不同运行时精度支持时间 profile 和精度 profile。以 Android 设备为例编译与运行方式如下# 编译需开启 with_benchmark ./lite/tools/build_android.sh --toolchainclang --with_benchmarkON full_publish # 上传模型与 benchmark_bin 后执行 adb shell cd /data/local/tmp/benchmark; ./benchmark_bin \ --model_fileMobileNetV1/inference.pdmodel \ --param_fileMobileNetV1/inference.pdiparams \ --input_shape1,3,224,224 \ --warmup10 \ --repeats20 \ --backendarm输出中的Perf Info一节会给出 init/first/min/max/avg 五组耗时单位 ms其中init反映模型加载与图优化的开销first反映首帧含预热耗时avg则是稳定后的平均单次推理耗时——这三个指标分别对应端侧应用冷启动、首帧延迟与稳态吞吐三个关注点。建议在同一设备、同一模型、固定线程数与功率模式下记录基线数据每次优化后重测对比形成量化闭环。七、基于第三方工具进行性能分析除了 Paddle Lite 内置的 Profiler第三方工具如 Android Profiler 和 Instruments也提供了丰富的可用于调试应用的性能分析信息。有时错误可能不在模型中而在与模型交互的部分应用代码中例如输入数据在 CPU 与 GPU 之间的频繁拷贝每帧都重新创建预测器或重新分配输入张量前处理未充分利用多线程或 SIMD推理线程与 UI 线程互相抢占 CPU。请务必熟悉平台特定的性能分析工具和适用于该平台的最佳做法把「模型内」与「模型外」的耗时分开看才能避免在错误的方向上做优化。八、基于异构硬件进行性能优化Paddle Lite 提供了多个使用速度更快的硬件如 GPU、NPU 和 APU 等来加速模型的新方式也支持多种异构硬件加速方法例如 ARM CPU 与 NPU 异构加速检测模型性能。在 lite/backends 下可以看到已支持的后端包括 arm、opencl、metal、xpu、nnadapter 等NNAdapterlite/kernels/nnadapter则是一套统一的异构适配层可对接华为昇腾/麒麟 NPU、联发科 APU、芯原 TIM-VX、昆仑芯 XPU、寒武纪 MLU 等多种新硬件。使用异构加速时请注意有些加速器更适合不同类型的模型例如 GPU 擅长高并行度的卷积而轻量级模型在 GPU 上的启动与拷贝开销可能反噬收益有些新硬件只支持浮点模型或以特定方式优化的模型需要确认目标 NPU/GPU 对算子、精度fp16/int8与数据排布的约束请务必对每个硬件类型进行基准测试以查看它是否适合您的应用。例如如果您有一个非常小的模型将该模型放在 GPU 可能不值得——GPU 的 kernel 启动、上下文创建与数据搬运开销会占据主导相反对于具有高运算强度compute-intensive的大型模型来说GPU 就是很好的选择。这一点同样适用于 NPU只有当子图中可卸载算子的计算量足够大、足以摊薄「算子标记 → 子图检测 → 硬件 IR 组网 → 模型生成」的开销时异构加速才有意义。具体到某个 NPU 的接入与实测可结合对应 demo 指南如 docs/demo_guides 下的 huawei_ascend_npu、qualcomm_qnn、kunlunxin_xpu 等以及 性能数据文档 进行验证。九、总结一套可复用的性能优化流程综合全文面向 Paddle-Lite 端侧部署的性能优化可以收敛为如下闭环流程选型按任务精度需求选择尽量小的模型必要时配合量化优先静态离线量化测基线用内置 Profiler 工具 或 Benchmark 工具 在目标真机上取得逐算子耗时与整体耗时基线定位热点依据 Detailed/Concise Dispatch Profiler Summary 中Avg(%)找出 Top 热点算子分层优化算法层检查融合 Pass 是否已生效、能否进一步融合新增 Pass算子层为热点算子选择/实现更优算法新增 OP硬件层利用不同微架构A53/A73/A75 等与指令集SVE2/DOTPROD的针对性实现新增硬件场景层优化前后处理等模型外代码善用 图像算子异构加速对运算强度高的大模型评估 GPU/NPU 子图卸载并用基准测试确认收益回归验证固定线程数、功率模式与预热次数对比优化前后 avg/first 耗时与精度指标。这套流程同时覆盖了「模型算法、硬件特性、应用场景」三个优化维度配合仓库中的 Profiler、Benchmark 工具与各类开发指南可以帮助你在资源受限的端侧设备上把每一个算子的耗时和每一次整机优化的收益都变成可度量、可复现的数据。【免费下载链接】Paddle-LitePaddlePaddle High Performance Deep Learning Inference Engine for Mobile and Edge (飞桨高性能深度学习端侧推理引擎项目地址: https://gitcode.com/GitHub_Trending/pa/Paddle-Lite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Paddle-Lite 端侧推理性能优化最佳实践：从模型选型到异构加速的完整指南
Paddle-Lite 端侧推理性能优化最佳实践从模型选型到异构加速的完整指南【免费下载链接】Paddle-LitePaddlePaddle High Performance Deep Learning Inference Engine for Mobile and Edge (飞桨高性能深度学习端侧推理引擎项目地址: https://gitcode.com/GitHub_Trending/pa/Paddle-Lite移动端与嵌入式设备的算力、内存和能耗都极其有限如何让深度学习模型在资源受限的硬件上跑得快、占用少是端侧推理部署的核心挑战。本文以 Paddle-Lite飞桨高性能深度学习端侧推理引擎为背景系统梳理端侧模型性能优化的完整方法论从「按任务选择模型」开始到使用内置 Profiler 定位性能瓶颈再分别从模型与算法思想、硬件特点、特定应用场景三个维度展开优化手段最后介绍第三方性能分析工具与 GPU/NPU/APU 异构加速方案。读完本文你将掌握一套「选模型 → 分析 → 优化 → 验证」的可复现流程并能够借助仓库内文档与源码快速落地。一、为什么端侧推理必须讲求性能优化移动设备和嵌入式设备的计算资源有限电池容量、散热能力与内存带宽都远逊于服务器。Paddle Lite 作为面向服务器端、边缘端和移动端场景的推理引擎见 lite/core 目录下的核心实现其性能优化的出发点正是在不改变模型功能的前提下提高应用的资源效率——包括降低单次推理耗时、减少内存占用、控制功耗与发热。Paddle Lite 的整个推理流程可以分成**分析Analysis与执行Execution**两个阶段分析阶段完成模型加载解析、计算图转化、图分析与优化Pass、运行时程序生成执行阶段则按拓扑顺序运行指令。图优化阶段中诸如算子融合、内存复用等 Pass 都会直接作用于端侧性能因此理解这些优化手段是掌握性能优化方法的前提。更多架构细节可参考 docs/develop_guides/architecture-intro.md。二、第一步基于任务选择最佳模型性能优化的起点不是调优而是选型。您需要根据任务在模型复杂性和模型大小之间进行权衡如果任务需要高准确率例如医学影像、精细分割那么可能需要一个大而复杂的模型对于准确率要求较低的任务例如实时手势识别、基础目标检测则最好使用较小的模型。小模型不仅占用的磁盘空间和内存更少而且通常速度更快、更节能。选型时建议遵循「够用即最优」的原则先确定业务可接受的准确率下限再在该约束下选择参数量与计算量最小的候选模型。这一步直接决定了后续所有优化的天花板——再优秀的推理引擎也无法让一个超大模型在低端设备上达到实时帧率。三、第二步基于模型进行性能分析Profiler 定位瓶颈在选定候选模型后下一步是量化分析其性能。Paddle Lite 内置的 Profiler 工具 带有性能分析器可以展示每个算子的性能分析数据帮助理解性能瓶颈在哪一层、哪些算子占据了大部分计算时间。3.1 性能 Profiler 的开启方式性能 Profiler 用于逐层耗时统计可获取模型逐层在 ARM CPU / X86 CPU / OpenCL 上的 kernel 耗时信息。编译 full_publish 预测库时加入编译选项--with_profileON即可开启。例如 Android 平台./lite/tools/build_android.sh \ --archarmv8 \ --toolchainclang \ --android_stlc_static \ --with_profileON \ full_publishx86 Linux 平台./lite/tools/build_linux.sh \ --with_profileON \ full_publish其它平台可参照各平台的编译文档如 docs/source_compile 下的各平台编译指南同时加上--with_profileON选项即可。3.2 Profiler 输出数据的解读编译完成后进入build.lite.android.armv8.clang/inference_lite_lib.android.armv8/demo/cxx/mobile_light/目录执行make将生成的可执行文件mobilenetv1_light_api、动态库libpaddle_light_api_shared.so与模型mobilenet_v1.nb通过 ADB 发送到手机同一目录执行./mobilenetv1_light_api ./mobilenet_v1.nb会打印三类日志Detailed Dispatch Profiler Summary单次推理的逐 OP 底层 Kernel 层运行耗时即在KernelBase::Run()的前后统计耗时会排除第一次的计时第一次相当于 warm-upConcise Create Profiler Summary汇总统计的创建 Op 的耗时即从Instruction::Run()开始到KernelBase::Run()执行前会排除前 10 次推理Concise Dispatch Profiler Summary汇总统计的运行 Op 的耗时在KernelBase::Run()前后统计为 Lite 具体设备的底层 Kernel 层完整耗时会排除前 10 次推理。命令默认推理 100 次。最后一次的 Detailed Dispatch Profiler Summary 示例截取关键行如下 Detailed Dispatch Profiler Summary: N/A, Exclude 1 warm-ups OperatorType KerneAttr(Place) KernelFuncName Remark InDim FilterDim OutDim Avg(ms) Min(ms) Max(ms) Last(ms) Avg(%) GOPs GOPS conv2d arm/float/NCHW conv_3x3s2_direct_fp32 3x3p1s2g1d1BiasRelu 1x3x224x224 32x3x3x3 1x32x112x112 0.735 0.709 0.865 0.718 2.60% 0.022 29.50 conv2d arm/float/NCHW conv1x1s1_gemm_fp32 1x1p0s1g1d1BiasRelu 1x32x112x112 64x32x1x1 1x64x112x112 1.370 1.347 1.445 1.368 4.85% 0.051 37.51 conv2d arm/float/NCHW conv1x1s1_gemm_fp32 1x1p0s1g1d1BiasRelu 1x128x56x56 128x128x1x1 1x128x56x56 2.436 2.410 2.526 2.433 8.62% 0.103 42.19 conv2d arm/float/NCHW conv1x1s1_gemm_fp32 1x1p0s1g1d1BiasRelu 1x512x14x14 512x512x1x1 1x512x14x14 2.360 2.316 2.401 2.357 8.35% 0.103 43.55 pool2d arm/float/NCHW NotImpl globalavgEXPLICIT 1x1024x7x7 N/A 1x1024x1x1 0.014 0.012 0.029 0.013 0.05% 0.000 3.63 fc arm/float/NCHW NotImpl Bias 1x1024x1x1 1024x1000 1x1000 0.287 0.271 0.324 0.293 1.01% 0.003 10.71 softmax arm/float/NCHW NotImpl axis-1 1x1000 N/A 1x1000 0.006 0.005 0.008 0.006 0.02% 0.000 0.95逐行字段含义OperatorType为算子类型KerneAttr(Place)为目标设备/精度/数据排布KernelFuncName为实际调用的底层 kernel 函数名例如conv1x1s1_gemm_fp32、conv_3x3s2_direct_fp32Remark描述了卷积参数3x3 核、pad1、stride2、group1、含 Bias 与 ReluInDim/FilterDim/OutDim给出输入/权重/输出维度Avg/Min/Max/Last为耗时统计毫秒Avg(%)是该算子占总耗时的百分比GOPs为浮点运算量GOPS为每秒十亿次运算数吞吐。此外还有汇总输出例如 Concise Dispatch Profiler Summary Concise Dispatch Profiler Summary: N/A, Exclude 10 warm-ups OperatorType KerneAttr(Place) KernelFuncName Avg(ms) Min(ms) Max(ms) Avg(%) GOPs CalledTimes conv2d arm/float/NCHW conv1x1s1_gemm_fp32 25.381 24.985 25.896 89.79% 1.079 13 conv2d arm/float/NCHW conv_3x3s2_direct_fp32 0.727 0.709 0.793 2.57% 0.022 1 depthwise_conv2d arm/float/NCHW conv_depthwise_3x3_fp32 1.855 1.810 2.160 6.56% 0.035 13 fc arm/float/NCHW NotImpl 0.285 0.277 0.318 1.01% 0.003 1 pool2d arm/float/NCHW NotImpl 0.013 0.012 0.015 0.05% 0.000 1 softmax arm/float/NCHW NotImpl 0.006 0.005 0.008 0.02% 0.000 1上面是 Android 端 ARM CPU 的性能 Profiler 结果。可以看到conv1x1s1_gemm_fp32一个 kernel 就占了总耗时的 89.79%此时优化重点应明确指向 1x1 卷积的 GEMM 实现。3.3 精度 Profiler 与逐层数据核验除了耗时还可以用精度 Profiler编译时加--with_precision_profileON逐层统计每个 Op 输出 tensor 的精度信息用于排查模型在特定设备上精度是否异常。其输出对每个 output tensor 提供三个数值均值mean该 tensor 所有元素的和值除以元素个数反映整体平均值标准差std_deviationtensor 距离均值的波动程度一般来说均值和标准差就能确定该 tensor 的正确性序列值ave_grow_rate反映 tensor 从起始元素到最后一个元素的序列变化情况。当两组 tensor 均值和标准差一样但元素位次不同时该值不同。序列值的计算伪代码为// compute ave_grow_rate of tensor output for (size_t i 1; i output.length; i) { ave_grow_rate (output[i] - output[i - 1]) / (output[i - 1] eps); } ave_grow_rate / output.length;若需保存每个 OP 的每个输出到文件可在 ADB Shell 中执行前加入export PADDLELITE_PRECISION_WRITE_TO_FILE1每层输出会以PaddleLite前缀加时间戳的命名方式保存在不同文件夹中。从源码结构看Profiler 的信息采集分为两层Op 层信息通过Instruction::SetProfileRuntimeOpInfo调用OpLite-GetOpRuntimeInfo(profile::OpCharacter*)获取例如 lite/operators/conv_op.h 中ConvOpLite重写了该方法Kernel 层信息则通过KernelBase::SetProfileRuntimeKernelInfo(profile::OpCharacter* ch)这一虚函数借助多态机制获取具体底层 Kernel 名例如ReluCompute等派生 Kernel 类。最终通过profile::OpCharacter结构体把 Op 层与 Kernel 层信息串联起来。关于 Profiler 的架构设计细节可查看 docs/user_guides/profiler.md。3.4 由 Profiler 结果驱动的三个优化方向获得每个算子的性能数据后可按照以下三个方面完成模型性能优化基于模型和算法思想的性能优化基于硬件特点的性能优化基于特定场景/特定模型的性能优化。下面分别展开。四、基于模型和算法思想的性能优化4.1 优先选择最小模型与量化首先根据需求选择最小的模型进行推理因为这些模型通常更快、更节能。Paddle Lite 支持量化等多种优化技术具体细节可查看 量化文档。Paddle 模型的量化包含三种方法动态离线量化主要用于减小模型体积、静态离线量化和量化训练二者既可以减小模型体积也可以加快性能性能加速基本相同。建议首先使用静态离线量化方法docs/user_guides/quant/quant_post_static.md如果量化模型精度损失较大再尝试量化训练。量化训练需要预训练模型和较多训练数据通常大于 5000 样本其思想是在训练阶段使用模拟量化更新权重从而减小量化误差。以在安卓手机 ARM 端进行量化模型预测为例先用模型转换工具 OPT 将量化模型转换为移动端预测模型./OPT --model_dir./mobilenet_v1_quant \ --optimize_out_typenaive_buffer \ --optimize_outmobilenet_v1_quant_opt \ --valid_targetsarm转换后的.nb模型即可在 Android/iOS App 中加载预测。量化对于端侧的意义在于不仅减小模型体积与内存占用而且 int8 计算在 ARM CPU 上可通过 SIMD/DOTPROD 指令显著提速是「基于算法思想」这一维度性价比最高的优化手段。4.2 分析模型结构寻找可融合算子其次分析模型结构查看是否有可融合的算子如convolution和batchnorm可融合成单个convolution实现或可并行计算的分支以减少模型的计算量或 I/O 操作。这种情况一般不多见因为 Paddle Lite 已完成大部分融合算子添加——这一点可以从RunDefaultOptimizer的 Pass 列表中得到验证见 lite/core/optimizer/optimizer.cc 中的 Pass 顺序列表其中包含lite_conv_elementwise_fuse_pass、lite_conv_bn_fuse_pass、lite_conv_activation_fuse_pass等一系列融合 Pass。典型融合示例fc_fuse_pass将相邻的mul算子与elementwise_add算子融合成一个FC算子mul(X) X * W elementwise_add( mul(x) ) X * W Bias //---------- after fusion FC(X) X * W BiasPass 层面对这种「mul elementwise_add → fc」的图结构替换属于典型的图优化。Paddle Lite 中每一类 Pass 定义一种优化过程包括 kernel 选取、OP 融合、冗余 OP 去除、子图创建、内存优化、类型推导与类型转换等详见 新增 Pass 文档。如果您发现了更好的融合算子支持可参考 docs/develop_guides/add_new_pass.md 添加新的融合算子支持。4.3 深挖热点算子的算法实现最后分析模型中占比高算子的算法思想查看是否还有可优化的空间。例如针对 Profiler 中耗时占比最高的conv1x1s1_gemm_fp32其本质是 1x1 卷积转化为 GEMM通用矩阵乘法。Paddle Lite 在 lite/backends/arm/math 下实现了多种卷积算法变体包括conv3x3_winograd_fp32_c4.cc/conv_winograd_3x3.ccWinograd 变换加速 3x3 卷积conv3x3s2_direct_fp32.cc3x3 stride2 的直接卷积packed_sgemm.cc及sgemm系列ARM 汇编级矩阵乘并在__aarch64__且开启LITE_WITH_ARM8_SVE2时使用 SVE2 指令在WITH_ARM_DOTPROD时使用点积指令见 lite/backends/arm/math/conv_impl.cc。这些实现覆盖 fp32/fp16/int8 等多种精度正是「算法思想优化」在 Kernel 层面的落地。目前 Paddle Lite 已为大多数算子提供了优化版本如果您有更好的实现方法可以参考 新增 OP 文档 添加实现该文档以 Argmax 为例完整介绍了从 OpParam、OpLite 注册到各后端 Kernel 绑定与单测的全流程。五、基于硬件特点的性能优化5.1 针对处理器微架构的优化根据您使用的硬件设备结构特点查看热点算子是否仍有优化空间。目前 Paddle Lite 已支持大部分硬件优化。以 ARM CPU 为例针对不同微架构处理器如 A53、A35 等小核处理器以及 A73、A75 等大核处理器提供了三类处理器的优化实现——这类针对性的指令调度与寄存器分配优化能够最大化利用目标 CPU 的乱序执行能力与访存带宽。从源码上看ARM 后端在 lite/backends/arm 下集中实现了数学库gemm、conv、pool、activation 等并通过编译期宏如__aarch64__、LITE_WITH_ARM8_SVE2、WITH_ARM_DOTPROD在运行时精度与指令集层面做分支选择从而适配不同芯片能力。如果您发现其他硬件可进一步优化也欢迎参考 新增硬件文档 或 新增 OP 文档 添加新的硬件优化实现。5.2 硬件接入的两类方式延伸值得说明的是针对「新硬件」的优化Paddle Lite 提供了两类接入方式详见 docs/develop_guides/add_hardware.md算子 Kernel 接入方式在 lite/kernels 下为新增硬件实现各算子的 Kernel并建议在 lite/backends 下封装统一的数学运算接口剥离硬件细节子图接入方式依据硬件支持能力将计算图分割为若干子图通过「算子标记 → 子图检测反向 DFS→ 子图融合」把可转换的算子交给硬件 IR 执行框架中实现参考 NNAdapterSubgraphPass。六、基于特定场景/特定模型的性能优化6.1 从整机视角定位可优化环节基于您目前的使用场景分析各部分应用耗时占比选择占比高的部分用其他方法优化实现进而提高整个应用程序的性能。性能瓶颈往往不只在模型推理本身还分布在图像采集、数据预处理、前后处理、结果显示等环节。例如应用包含前后预处理实现时可以基于硬件添加前后预处理的优化实现。Paddle Lite 已提供部分图像算子的优化实现如用 ARM 汇编实现 OpenCV 图像处理算子可供直接调用从而将「解码 → 缩放 → 归一化 → 推理」整条流水线的耗时一并压下来。6.2 端到端性能测试工具支撑为了支撑上述「场景级」优化Paddle Lite 提供了 Benchmark 工具详见 docs/performance/benchmark_tools.md可输出初始化耗时、首帧耗时、平均耗时等指标并支持以 Paddle combined/uncombined 格式或.nb格式模型作为输入支持单输入和多输入模型、从文本读取输入数据支持设置不同运行时精度支持时间 profile 和精度 profile。以 Android 设备为例编译与运行方式如下# 编译需开启 with_benchmark ./lite/tools/build_android.sh --toolchainclang --with_benchmarkON full_publish # 上传模型与 benchmark_bin 后执行 adb shell cd /data/local/tmp/benchmark; ./benchmark_bin \ --model_fileMobileNetV1/inference.pdmodel \ --param_fileMobileNetV1/inference.pdiparams \ --input_shape1,3,224,224 \ --warmup10 \ --repeats20 \ --backendarm输出中的Perf Info一节会给出 init/first/min/max/avg 五组耗时单位 ms其中init反映模型加载与图优化的开销first反映首帧含预热耗时avg则是稳定后的平均单次推理耗时——这三个指标分别对应端侧应用冷启动、首帧延迟与稳态吞吐三个关注点。建议在同一设备、同一模型、固定线程数与功率模式下记录基线数据每次优化后重测对比形成量化闭环。七、基于第三方工具进行性能分析除了 Paddle Lite 内置的 Profiler第三方工具如 Android Profiler 和 Instruments也提供了丰富的可用于调试应用的性能分析信息。有时错误可能不在模型中而在与模型交互的部分应用代码中例如输入数据在 CPU 与 GPU 之间的频繁拷贝每帧都重新创建预测器或重新分配输入张量前处理未充分利用多线程或 SIMD推理线程与 UI 线程互相抢占 CPU。请务必熟悉平台特定的性能分析工具和适用于该平台的最佳做法把「模型内」与「模型外」的耗时分开看才能避免在错误的方向上做优化。八、基于异构硬件进行性能优化Paddle Lite 提供了多个使用速度更快的硬件如 GPU、NPU 和 APU 等来加速模型的新方式也支持多种异构硬件加速方法例如 ARM CPU 与 NPU 异构加速检测模型性能。在 lite/backends 下可以看到已支持的后端包括 arm、opencl、metal、xpu、nnadapter 等NNAdapterlite/kernels/nnadapter则是一套统一的异构适配层可对接华为昇腾/麒麟 NPU、联发科 APU、芯原 TIM-VX、昆仑芯 XPU、寒武纪 MLU 等多种新硬件。使用异构加速时请注意有些加速器更适合不同类型的模型例如 GPU 擅长高并行度的卷积而轻量级模型在 GPU 上的启动与拷贝开销可能反噬收益有些新硬件只支持浮点模型或以特定方式优化的模型需要确认目标 NPU/GPU 对算子、精度fp16/int8与数据排布的约束请务必对每个硬件类型进行基准测试以查看它是否适合您的应用。例如如果您有一个非常小的模型将该模型放在 GPU 可能不值得——GPU 的 kernel 启动、上下文创建与数据搬运开销会占据主导相反对于具有高运算强度compute-intensive的大型模型来说GPU 就是很好的选择。这一点同样适用于 NPU只有当子图中可卸载算子的计算量足够大、足以摊薄「算子标记 → 子图检测 → 硬件 IR 组网 → 模型生成」的开销时异构加速才有意义。具体到某个 NPU 的接入与实测可结合对应 demo 指南如 docs/demo_guides 下的 huawei_ascend_npu、qualcomm_qnn、kunlunxin_xpu 等以及 性能数据文档 进行验证。九、总结一套可复用的性能优化流程综合全文面向 Paddle-Lite 端侧部署的性能优化可以收敛为如下闭环流程选型按任务精度需求选择尽量小的模型必要时配合量化优先静态离线量化测基线用内置 Profiler 工具 或 Benchmark 工具 在目标真机上取得逐算子耗时与整体耗时基线定位热点依据 Detailed/Concise Dispatch Profiler Summary 中Avg(%)找出 Top 热点算子分层优化算法层检查融合 Pass 是否已生效、能否进一步融合新增 Pass算子层为热点算子选择/实现更优算法新增 OP硬件层利用不同微架构A53/A73/A75 等与指令集SVE2/DOTPROD的针对性实现新增硬件场景层优化前后处理等模型外代码善用 图像算子异构加速对运算强度高的大模型评估 GPU/NPU 子图卸载并用基准测试确认收益回归验证固定线程数、功率模式与预热次数对比优化前后 avg/first 耗时与精度指标。这套流程同时覆盖了「模型算法、硬件特性、应用场景」三个优化维度配合仓库中的 Profiler、Benchmark 工具与各类开发指南可以帮助你在资源受限的端侧设备上把每一个算子的耗时和每一次整机优化的收益都变成可度量、可复现的数据。【免费下载链接】Paddle-LitePaddlePaddle High Performance Deep Learning Inference Engine for Mobile and Edge (飞桨高性能深度学习端侧推理引擎项目地址: https://gitcode.com/GitHub_Trending/pa/Paddle-Lite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考