重复计算问题剖析：在时序推理中哪些计算是重复的，如何识别与量化

TinyML 时序推理的核心挑战在于：模型必须在每一时间步（tick）对新的传感器窗口执行推理，但窗口之间存在大量重叠。以 3 轴加速度计、128ms 窗口、32ms 滑动步长为例，相邻窗口共享 96ms 的数据，这意味着理论上 75% 的输入特征计算被重复执行。更隐蔽的是，模型内部的状态（如 LSTM 的隐状态、卷积的中间激活）也在时间步之间被反复重新计算。本章将系统剖析重复计算的来源、识别方法、量化指标，并给出一个完整的工程案例，帮助你在实际部署中精准定位优化切入点。

3.1 核心原理：时序推理中的三类重复计算

时序推理的重复计算并非单一类型，而是分布在从原始数据到最终输出的整条链路上。根据计算发生的位置和性质，可以将其划分为三个层次：输入层重复、特征层重复和模型层重复。理解这三类重复的差异，是制定缓存策略的前提。

输入层重复是最直观的：当窗口以步长 S 滑动时，相邻窗口的重叠区域为 W-S。以 128ms 窗口、32ms 步长为例，重叠率高达 75%。如果直接对每个窗口独立执行 FFT，那么 75% 的 FFT 计算是冗余的。特征层重复则更为隐蔽——即使窗口不重叠，某些特征（如全局均值、方差）也可以通过增量公式从上一个窗口的结果推导出来，而不必重新遍历全部数据。模型层重复则取决于网络结构：对于 1D CNN，当卷积核尺寸大于步长时，相邻窗口的卷积特征图存在重叠；对于 LSTM，虽然隐状态天然传递，但若每次推理都从零初始化，则完全丧失了时序记忆能力。

3.2 判断方法：如何系统识别重复计算

识别重复计算不能靠直觉，需要一套可操作的方法论。以下是经过实践验证的四步识别流程，适用于大多数 TinyML 时序推理场景。

1. 绘制数据流图（Dataflow Graph）：将推理过程拆解为数据变换节点，标注每个节点的输入、输出和计算量（MACs 或 FLOPs）。重点关注窗口滑动方向上的数据依赖关系。
2. 计算重叠率（Overlap Ratio）：对于每个计算节点，计算相邻时间步输入数据的重叠比例。公式为：Overlap = (W - S) / W，其中 W 为窗口大小，S 为滑动步长。重叠率超过 30% 的节点应优先考虑缓存。
3. 分析状态依赖性：检查模型是否包含状态变量（如 LSTM 的 h 和 c、滑动平均的累计值）。如果存在状态变量，但代码中每次推理都重新初始化，则存在严重的重复计算。
4. 使用 Profiling 工具量化：在目标硬件（如 Cortex-M4、ESP32）上运行 profiling，记录每个函数的执行时间和调用次数。对比理论计算量与实测时间，找出“时间/计算量比”异常偏高的函数。

// 伪代码：识别重复计算的 Profiling 思路
for each time_step t:
    start = timer()
    features = extract_features(window[t])  // 可能重复
    output = model_inference(features)      // 可能重复
    elapsed = timer() - start
    log(t, elapsed, features.cache_hit, model.state_reused)
    
// 分析日志：如果 cache_hit 为 false 但窗口重叠率 > 50%，则存在优化空间

在实际工程中，最有效的方法是“差分测试”：实现一个朴素版本（每次全量计算）和一个缓存版本（增量更新），在相同输入下对比输出是否一致（允许极小误差），同时对比执行时间。如果缓存版本输出偏差在容忍范围内且速度提升显著，则说明重复计算确实存在且已被有效消除。

3.3 量化指标：如何度量重复计算的代价

识别重复计算之后，需要量化其代价，以便决定优化优先级。以下是三个核心量化指标，建议在项目初期就建立这些指标的基线。

• 冗余计算比（Redundant Compute Ratio, RCR）：RCR = 1 - (有效计算量 / 总计算量)。有效计算量指对最终输出有贡献且不可通过缓存避免的计算。RCR 越高，优化空间越大。
• 缓存命中率（Cache Hit Rate, CHR）：在实施缓存后，衡量缓存命中的计算请求占总请求的比例。CHR 应达到 80% 以上才算有效优化。
• 有效吞吐率（Effective Throughput, ET）：ET = 有效推理次数 / 总耗时。该指标直接反映优化后的实时性能，是最终用户可感知的指标。

量化过程需要注意：计算量不等于能耗。在 TinyML 设备上，内存访问的能耗往往高于计算能耗。因此，即使 RCR 很高，如果缓存需要消耗大量额外内存，也可能得不偿失。建议在量化时同时考虑 内存带宽占用 和 Flash/RAM 容量 的约束。

3.4 案例拆解：智能手环活动识别中的重复计算优化

下面通过一个完整的工程案例，展示如何识别、量化并消除时序推理中的重复计算。该案例基于一颗 Cortex-M4 内核（主频 80MHz，RAM 64KB）的智能手环，运行一个 1D CNN 活动识别模型（识别走路、跑步、静止三种状态）。

初始状态与约束：传感器以 50Hz 采样 3 轴加速度计数据。窗口大小 W=64 个采样点（1.28 秒），滑动步长 S=16 个采样点（0.32 秒）。模型输入为 3×64 的特征矩阵，首先计算每个轴的 FFT（64 点），然后输入两层 1D CNN（卷积核大小 5，步长 1）。设备要求推理延迟 < 50ms，平均功耗 < 5mA。

初始现象：实测推理延迟为 85ms，功耗 8mA，均超出规格。Profiling 显示 FFT 计算占 40% 时间，CNN 第一层卷积占 35% 时间。

分析判断过程：

1. 计算窗口重叠率：(64-16)/64 = 75%。这意味着每 4 次 FFT 中有 3 次是重复的。
2. 分析 CNN 感受野：卷积核大小 5，步长 1，输入长度 64。相邻窗口的输入重叠 48 个采样点，因此第一层卷积的特征图也有 75% 重叠。
3. 检查代码：发现每次推理都从原始传感器数据重新计算 FFT，且 CNN 的中间激活未缓存。

实际操作步骤：

// 优化方案 1：FFT 增量缓存
// 维护一个 64 点的环形缓冲区，每次滑动 16 点
// 只对新进入的 16 点做 FFT，旧 48 点的 FFT 结果从缓存读取
// 使用 FFT 的线性性质：FFT(新窗口) = FFT(旧窗口) - FFT(移出部分) + FFT(移入部分)

// 优化方案 2：CNN 特征图缓存
// 第一层卷积的输入重叠 48 点，因此输出特征图也重叠
// 缓存上一时间步的卷积输出，只计算新滑入 16 点对应的卷积结果
// 注意：由于卷积核跨步为 1，需要处理边界效应

// 优化方案 3：状态复用
// 确认模型无 LSTM 层，但第二层 CNN 的池化操作可以复用部分结果

结果对比：

风险与代价：缓存策略引入了额外的 RAM 开销（13KB），在 64KB RAM 的平台上仍可接受。但需要注意：FFT 增量计算引入了浮点误差累积，经过 1000 次迭代后误差可能达到 1e-4 量级，对于分类任务无影响，但对于回归任务需要定期重置缓存。此外，CNN 特征图缓存增加了代码复杂度，需要仔细处理边界条件。

复盘经验：本次优化的核心成功因素在于：先量化（RCR=0.72），再定位（FFT 和第一层 CNN 占 75% 重复），最后针对性设计缓存。如果一开始盲目优化所有层，不仅工作量巨大，还可能引入难以调试的 bug。建议在项目启动时就将 RCR 和 CHR 作为持续跟踪的指标，纳入 CI/CD 流程。

3.5 常见误区与总结

在识别和消除重复计算的过程中，开发者常陷入以下误区，需要特别警惕。

• 误区一：认为缓存总是有益的。缓存需要消耗 RAM，增加代码复杂度，并可能引入误差累积。对于计算量本身很小的节点（如简单的加法），缓存反而得不偿失。
• 误区二：忽略数据对齐问题。滑动窗口的步长可能不是缓存粒度的整数倍。例如，FFT 缓存要求窗口大小是步长的整数倍，否则需要额外的插值或填充，反而增加计算量。
• 误区三：只关注计算时间，忽略内存访问时间。在 Cortex-M 系列等低功耗 MCU 上，从 Flash 读取权重和从 RAM 读取缓存数据的时间可能超过计算时间。优化时应使用 __attribute__((section(".ramfunc"))) 将关键函数放入 RAM 执行。
• 误区四：认为重复计算只存在于窗口滑动场景。即使是非滑动窗口（如事件触发推理），模型内部的状态变量（如 BatchNorm 的 running_mean）也可能被重复计算。每次推理时重新计算 BatchNorm 统计量是常见的隐藏浪费。