📚 课程目录第3章端侧推理基础

端侧推理基础：设备类型、推理引擎选择与性能评估指标

当ONNX模型完成训练与导出后，真正的挑战始于将其部署到资源受限的端侧设备。端侧推理与云端推理存在本质差异：云端拥有近乎无限的电力、散热与算力，而端侧必须在功耗、内存、延迟与精度之间寻找平衡。理解端侧设备的多样性、推理引擎的适配逻辑以及性能评估的量化方法，是模型落地前的必修课。

一、端侧设备类型与算力分层

端侧设备并非铁板一块，其计算能力跨度极大。按硬件架构与算力水平，可划分为三个层次：

轻量级MCU（微控制器）：如ARM Cortex-M系列、RISC-V内核，主频通常在几十MHz到200MHz之间，RAM仅几十到几百KB，Flash在1MB以内。这类设备只能运行极简的量化模型（如TinyML场景），推理引擎需为C语言库（如CMSIS-NN、TFLite Micro）。
中端嵌入式SoC：如树莓派、瑞芯微RK3588、高通骁龙600系列，配备多核ARM CPU（Cortex-A系列）和GPU（Mali、Adreno），部分集成NPU（如RKNN NPU）。系统内存通常在1~8GB，可运行轻量级Linux或Android，支持FP16与INT8量化模型。
高端移动/边缘设备：如旗舰手机（骁龙8 Gen系列、苹果A系列）、NVIDIA Jetson Orin、Intel Movidius。具备强大的GPU、专用NPU/TPU，内存8GB以上，支持混合精度推理与多模型并发。

设备分层直接决定了推理引擎的选择范围。下表对比了典型设备与适配引擎：

设备层级	代表硬件	可用推理引擎	典型量化精度
MCU	STM32F4, ESP32	TFLite Micro, CMSIS-NN	INT8, 二值化
嵌入式SoC	树莓派4, RK3588	ONNX Runtime, TFLite, RKNN	FP16, INT8
移动/边缘	Jetson Orin, 骁龙8	ONNX Runtime, TensorRT, CoreML	FP16, INT8, 混合精度

关键认知：引擎选择不是“哪个最好”，而是“哪个与硬件加速器匹配度最高”。例如，在Jetson上TensorRT性能优于ONNX Runtime，但在纯ARM CPU上ONNX Runtime的优化可能更均衡。

二、主流推理引擎对比与选型逻辑

在端侧场景中，ONNX Runtime（ORT）与TensorFlow Lite（TFLite）是最常见的两个选择，但它们的定位与优化路径差异显著。

ONNX Runtime的核心优势在于其执行提供程序（Execution Provider, EP）抽象层。通过EP机制，ORT可以将同一份ONNX模型分发到CPU、GPU、NPU甚至专用加速器上执行。例如，在Android设备上，可以通过NnapiExecutionProvider调用系统NNAPI；在Jetson上，则使用TensorrtExecutionProvider。这种灵活性使得ORT成为跨平台部署的首选中间层。

TensorFlow Lite则更强调端到端的工具链闭环。从TF模型转换到TFLite格式（.tflite）后，可以使用converter.optimizations进行训练后量化，配合Delegate机制（如GPU Delegate、Hexagon Delegate）实现硬件加速。TFLite在MCU领域有不可替代的优势——TFLite Micro提供了完整的算子集与内存管理方案。

选型时需遵循以下判断流程：

算子兼容性检查：使用onnxruntime.tools.convert_onnx_models_to_ort或netron查看模型算子，确认目标引擎是否支持。若包含自定义算子，需优先考虑支持自定义OP注册的ORT。
硬件加速器匹配：若目标设备有NPU，需确认引擎是否提供对应EP/Delegate。例如，瑞芯微NPU只能通过RKNN Toolkit转换，此时ORT与TFLite均不适用。
量化工具链成熟度：TFLite的量化工具链更成熟（支持训练时量化QAT），而ORT的量化依赖onnxruntime.quantization，对动态形状支持较弱。
包体大小与启动时间：MCU场景下TFLite Micro的二进制可控制在100KB以内，而ORT最小也需要约2MB。

  实际案例：某视觉检测模型需部署到RK3588平台。该设备有6 TOPS算力的NPU，但ORT的RKNN EP尚不完善。最终方案是：先用onnx2rknn工具将ONNX转为RKNN格式，同时保留ORT作为CPU回退方案。当NPU驱动异常时，自动切换至ORT的CPU执行，保证系统可用性。

三、性能评估指标体系

端侧推理性能不能只看“推理耗时”单一指标。一个完整的评估体系应覆盖以下维度：

延迟（Latency）：单次推理从输入到输出的时间，需区分P50（中位数）与P95/P99（尾延迟）。端侧场景中尾延迟往往由CPU调频、内存抖动引起，比平均延迟更重要。
吞吐量（Throughput）：单位时间处理的帧数或样本数（FPS/Samples/s）。对于视频流分析场景，需保证实时性（如≥30FPS）。
内存占用（Memory Footprint）：包括模型权重大小、运行时激活内存、框架本身的开销。可用/proc/self/status中的VmRSS或Android的Debug.getMemoryInfo()测量。
功耗（Power Consumption）：端侧设备对功耗极其敏感。使用perf工具或硬件功耗计测量平均功耗与峰值功耗。
初始化时间（Warm-up Time）：从引擎创建到第一次推理完成的时间，影响应用冷启动体验。

以下是一个标准的性能评估流程示例：

# 使用ONNX Runtime的C++ API进行延迟测试
#include <onnxruntime/core/session/onnxruntime_cxx_api.h>
#include <chrono>

// 创建会话
Ort::SessionOptions options;
options.SetIntraOpNumThreads(4);
options.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL);

// 预热10次
for (int i = 0; i < 10; i++) {
    session.Run(...);
}

// 正式测试100次，记录P50/P95
std::vector<double> latencies;
for (int i = 0; i < 100; i++) {
    auto start = std::chrono::high_resolution_clock::now();
    session.Run(...);
    auto end = std::chrono::high_resolution_clock::now();
    latencies.push_back(std::chrono::duration<double, std::milli>(end - start).count());
}
// 排序后取百分位值

四、常见误区与复盘

误区一：只关注平均延迟，忽略尾延迟。在端侧设备上，CPU频率的动态调谐（DVFS）会导致P95延迟比P50高出3~5倍。若仅以平均延迟作为优化目标，实际使用中会出现卡顿。正确做法是同时优化P50与P95，必要时绑定大核（通过sched_setaffinity）或锁定CPU频率。

误区二：盲目追求INT8量化。虽然INT8能带来2~4倍的加速，但某些算子（如LayerNorm、Softmax）在INT8下精度损失严重。建议先使用onnxruntime.quantization的quantize_static接口，并对比量化前后模型的输出余弦相似度。若相似度低于0.99，应改用混合量化（保留敏感层为FP16）。

复盘案例：某团队在树莓派4上部署人脸检测模型，最初选择TFLite并启用GPU Delegate，但实测FPS仅12。排查后发现，树莓派的VideoCore GPU不支持FP16运算，Delegate实际回退到CPU。改用ONNX Runtime的CPU执行，并开启ORT_ENABLE_ALL优化后，FPS提升至22。进一步使用armnnEP后达到28FPS。此案例说明：引擎的默认配置不等于最优配置，必须针对具体硬件进行基准测试。

性能评估的最终目标是建立可复现的基准测试流程。建议将测试脚本、设备状态（CPU频率、温度）、输入数据固定化，并输出包含P50/P95/内存/功耗的完整报告。只有量化评估，才能指导后续的模型压缩与引擎调优方向。