3、Profiling核心概念：耗时、吞吐量、延迟、内存占用、能耗等关键指标的定义与测量单位
TinyML Profiling 的本质，是将“模型在资源受限设备上的运行表现”转化为一组可量化、可比较、可追踪的数值。没有统一的度量标准，优化就无从谈起。本章聚焦于 Profiling 中最核心的五个关键指标——耗时（Latency/Time）、吞吐量（Throughput）、延迟（Response Latency）、内存占用（Memory Footprint）和能耗（Energy Consumption），逐一厘清它们的定义边界、测量单位、采集方法以及它们之间的相互制约关系。理解这些指标，是后续进行推理链路拆分和定位瓶颈的基石。
3.1 耗时（Time）与延迟（Latency）：看似相同，实则不同
在 TinyML 性能分析中，耗时（Time） 与 延迟（Latency） 是最容易被混淆的两个概念。从工程测量角度看，它们都使用毫秒（ms）或微秒（µs）作为单位，但语义边界截然不同。耗时通常指完成一次特定计算任务（如一次卷积操作、一次量化推理）所花费的纯计算时间，它关注的是“执行过程的长短”。而延迟则是一个端到端的概念，它从输入数据被采集（例如传感器采样）开始计时，直到输出结果可用（例如分类结果写入内存或通过 UART 发出）为止，中间包含了数据预处理、排队等待、内存拷贝、推理计算、后处理等所有环节。
在 MCU 级别的 Profiling 中，我们通常使用 DWT->CYCCNT 寄存器（Cortex-M 内核）或 Timer 外设来获取精确的时钟周期数。例如，在 STM32F4 上运行一个 MobileNetV1 量化模型，如果测得推理耗时 320ms，这仅仅代表模型计算部分。而如果从 GPIO 触发传感器采集到串口打印出结果，测得 380ms，这 380ms 才是系统延迟。理解这一差异至关重要：当用户抱怨“识别太慢”时，瓶颈可能不在模型计算，而在于传感器驱动或通信接口的阻塞等待。
3.2 吞吐量（Throughput）：衡量系统的并行处理能力
吞吐量定义为单位时间内系统能够处理的推理请求数量或数据量。在 TinyML 场景下，常用 FPS（Frames Per Second，每秒处理帧数） 或 inferences/second（每秒推理次数） 作为单位。对于单次推理，吞吐量 = 1000 / 单次推理耗时（ms）。例如，若一次推理耗时 50ms，则理论最大吞吐量为 20 FPS。但在实际系统中，由于 CPU 中断、DMA 传输、RTOS 任务调度等干扰，实际吞吐量往往低于理论值。
吞吐量指标在以下场景中尤为关键：连续图像分类（如视觉 Wake Word 检测）、传感器数据流异常检测、以及多路传感器融合处理。测量吞吐量时，不能简单地用 1 除以单次延迟，而应在一个时间窗口（如 1 秒或 10 秒）内统计完成的推理总次数。例如，在 10 秒内完成了 180 次推理，则实际吞吐量为 18 FPS。这种测量方式能够反映系统在持续负载下的真实表现，包括缓存命中率下降、内存带宽争抢等稳态效应。
| 指标名称 | 核心定义 | 常用单位 | 测量工具/方法 | TinyML 典型关注点 |
|---|---|---|---|---|
| 耗时 (Time) | 单次计算任务（如单层卷积）的执行时间 | ms, µs | DWT->CYCCNT, Timer, 示波器测 GPIO 翻转 | 定位算子级瓶颈，比较不同算子实现 |
| 延迟 (Latency) | 从输入到输出的端到端时间，含 I/O 与排队 | ms, µs | GPIO 打点 + 逻辑分析仪，或记录系统 Tick | 用户体验、实时性判断 |
| 吞吐量 (Throughput) | 单位时间内完成的推理次数或数据量 | FPS, inf/s | 长时间窗口计数（如 10s 内完成次数） | 连续流处理能力、系统稳态性能 |
| 内存占用 (Memory) | 模型权重、激活值、中间缓冲区占用的 RAM/Flash | KB, MB, Bytes | 编译器 map 文件、静态分析、RTOS 堆栈统计 | MCU 资源限制、防止内存溢出 |
| 能耗 (Energy) | 完成一次推理所消耗的能量 | mJ, µJ, mAh | 功率计、电流探头 + 积分计算 | 电池寿命、热管理、能量采集设备 |
3.3 内存占用（Memory Footprint）：Flash 与 RAM 的双重约束
内存占用是 TinyML 区别于云端 AI 的最显著约束。它分为两个维度：静态内存占用 与 动态内存占用。静态内存主要指模型权重、偏置、批次归一化参数等存储在 Flash 中的常量数据，单位通常为 KB 或 MB。动态内存则指推理过程中产生的激活值（Feature Map）、中间计算结果、以及运行时栈（Stack）和堆（Heap）开销，这部分占用 RAM。例如，一个 300KB 的量化模型（INT8）在推理时，可能需要额外的 200KB RAM 来存储第一层卷积的输出特征图，因为后续层需要读取这些中间结果。
测量内存占用不能仅看编译器的 .map 文件。map 文件只给出了静态分配情况，而动态峰值内存往往出现在推理的中间阶段。常用的方法是：在推理前记录空闲 RAM 基线，推理过程中周期性检查最大堆使用量（通过 malloc 钩子或 xPortGetFreeHeapSize 等 API），或者使用静态分析工具（如 GCC 的 -fstack-usage 选项）估算栈深度。对于无操作系统的裸机环境，需要手动计算各层激活值大小的峰值。例如，一个输入为 96x96x3 的模型，第一层卷积输出 48x48x16 的特征图，占用 48*48*16 = 36,864 Bytes ≈ 36KB，这往往就是内存峰值所在。
uxTaskGetStackHighWaterMark），并预留至少 15% 的 RAM 余量。
3.4 能耗（Energy Consumption）：电池寿命的直接决定因素
能耗指标在电池供电的 TinyML 设备（如智能手表、无线传感器节点）中具有一票否决权。能耗的单位通常为 毫焦耳（mJ） 或 微焦耳（µJ），在电池容量评估时也常用 毫安时（mAh） 换算。测量能耗不能简单用“电流 × 电压”估算，因为 MCU 在不同工作模式（运行、睡眠、深度睡眠）下的电流差异巨大。例如，Cortex-M4 在 80MHz 运行时电流约 20mA，而在 STOP 模式下仅 5µA。因此，精确测量需要采用积分法：使用高精度电流探头（如 INA219）或专用功耗分析仪（如 Joulescope），以 1kHz 以上的采样率记录电流波形，再对时间积分得到总能量。
在 Profiling 中，我们通常关注单次推理能耗（Energy per Inference）。假设一次推理耗时 50ms，期间平均电流 25mA，供电电压 3.3V，则单次推理能耗 = 3.3V × 25mA × 0.05s = 4.125 mJ。如果设备使用 500mAh 的电池，在 3.3V 下总能量为 500mAh × 3.3V = 1650 mWh = 5940 J。理论上可执行推理次数 = 5940J / 4.125mJ ≈ 144 万次。但实际中还需考虑待机功耗、无线传输功耗等，因此有效次数会大幅减少。
3.5 指标间的权衡与常见误区
这五个指标并非独立，它们之间存在复杂的制约关系。最典型的是延迟与吞吐量的权衡：在单核 MCU 上，降低延迟（如使用更快的时钟）通常会提升吞吐量，但会增加能耗。而内存与耗时的权衡：使用更大的内存缓冲区可以合并内存访问、减少拷贝次数，从而降低耗时，但会挤占其他任务的 RAM 空间。例如，将输入图像从 RGB888 转换为 RGB565 可以减少 25% 的内存带宽，但需要额外的转换耗时。
常见的 Profiling 误区包括：误区一：只测单次推理耗时，忽略系统级延迟。这会导致优化了模型计算，但用户感知的提升微乎其微，因为瓶颈在传感器读取或串口打印。误区二：使用调试器（如 JTAG）进行 Profiling。调试器会引入额外的时钟周期开销，且会改变时序行为，导致测量结果失真。应使用板载硬件计数器或 GPIO 翻转法。误区三：忽略温度对能耗的影响。MCU 在高温下漏电流增大，能耗上升，因此应在目标环境温度下进行测量。
总结而言，正确的 Profiling 策略是：先明确优化目标（是降低 P99 延迟还是提升平均吞吐量），再选择合适的指标组合进行测量。对于 TinyML 设备，通常建议至少同时采集耗时（分阶段打点）、峰值内存和单次推理能耗三个指标，因为它们分别对应了时间、空间和能量三大资源约束。只有将这三个维度的数据对齐到同一份推理日志中，才能准确判断优化措施是否真正有效，避免“按下葫芦浮起瓢”的局部优化陷阱。