TinyML基础与推理调度概述
TinyML（微型机器学习）是机器学习与嵌入式物联网系统交叉融合的前沿领域，其核心目标是在毫瓦级甚至微瓦级功耗预算下，于MCU（微控制器）、DSP（数字信号处理器）或极低功耗NPU上部署和运行机器学习模型。与云端AI依赖高性能GPU和庞大算力不同，TinyML强调在资源极度受限的边缘设备上完成数据采集、特征提取、推理决策的全链路闭环。推理调度（Inference Scheduling）则是这一闭环中的“神经中枢”，它决定了模型推理任务何时执行、以何种顺序执行、占用多少计算与存储资源，以及如何在实时性、功耗和准确率三个相互制约的维度之间做出动态权衡。本章将系统阐述TinyML的定义边界、典型应用场景，并深入剖析推理调度在资源受限设备上的核心价值与实现逻辑。
上图展示了TinyML推理调度的核心框架。左侧为TinyML定义中的硬性资源约束，右侧为典型应用场景，中间是推理调度需要解决的核心问题，底部则揭示了实时性、功耗与准确率三者之间的动态平衡关系。这张图贯穿本章始终，后续所有讨论都将围绕这一框架展开。
一、TinyML定义与核心特征
TinyML并非简单的“小模型”或“轻量级AI”，而是一套完整的工程方法论。从技术栈角度看，它涵盖了模型设计（如深度可分离卷积、模型剪枝、量化感知训练）、编译器优化（如TFLite Micro、CMSIS-NN）、运行时环境（如TensorFlow Lite for MCU、Edge Impulse）以及硬件适配（ARM Cortex-M系列、RISC-V MCU、低功耗NPU）等多个层面。其核心特征可以归纳为以下四点：
- 极致的资源约束：典型的TinyML设备仅有几十KB到几百KB的RAM，Flash存储通常在1MB以内，CPU主频在几十MHz到两百MHz之间。这意味着模型参数量必须控制在百万级以下，推理过程中的中间张量必须精打细算。
- 严格的功耗预算：大多数TinyML设备依赖纽扣电池或能量采集（如太阳能、振动能）供电，平均功耗需控制在毫瓦级。一次推理的能耗往往只有几十到几百微焦耳，这要求调度策略必须精细到“每次推理消耗多少能量”的粒度。
- 软硬件协同设计：TinyML不是纯软件问题，指令集架构（如ARM Cortex-M4的DSP指令、Cortex-M7的SIMD）、内存层次结构（SRAM vs Flash）、外设接口（DMA、定时器、ADC）都会直接影响推理效率。调度器必须感知这些硬件特性。
- 端云协同的定位：TinyML设备通常不是孤立工作的，它们与云端形成“端侧实时响应+云端深度训练”的协作模式。调度策略需要考虑何时本地推理、何时上传数据、何时接收模型更新。
二、推理调度的概念与核心机制
推理调度（Inference Scheduling）在TinyML语境下，是指对设备上多个可能的推理任务（可能来自不同传感器、不同模型、不同优先级）进行时间、计算、存储和功耗资源的动态分配过程。它不同于传统操作系统的进程调度，因为推理任务具有以下特殊性：
- 周期性任务与事件驱动任务混合：例如，一个可穿戴设备可能需要每100ms执行一次加速度计的姿态识别（周期任务），同时需要立即响应按键事件进行语音关键词检测（事件驱动任务）。调度器必须同时满足两类任务的时序要求。
- 模型可变性：同一设备可能部署多个模型（如轻量级模型用于日常监测，重量级模型用于异常确认），调度器需要根据当前场景动态选择加载哪个模型，并管理模型在Flash和RAM之间的切换开销。
- 计算深度与功耗的耦合：推理任务的执行深度（如卷积层数、循环次数）直接影响功耗。调度器可以通过调整推理精度（如跳过某些层、降低输入分辨率）来换取功耗降低，但这会牺牲准确率。
推理调度的核心机制包括：任务优先级管理（基于截止时间和重要度）、动态电压频率调节（DVFS）（在任务空闲期降低主频）、模型切换策略（根据输入复杂度选择不同规模的模型）、批处理与流水线（在多个传感器数据流之间共享计算单元）。这些机制共同构成了一个多目标优化问题。
三、推理调度在资源受限设备上的重要性
在云端，推理调度主要关注吞吐量和成本；在TinyML设备上，推理调度直接决定了设备能否在电池寿命、响应速度和任务有效性之间维持基本可用性。其重要性体现在以下三个层面：
| 维度 | 无调度策略的后果 | 有调度策略的收益 |
|---|---|---|
| 实时性 | 高优先级事件被低优先级任务阻塞，响应延迟不可控 | 关键任务截止时间可预测，最坏情况执行时间（WCET）可分析 |
| 功耗 | 设备持续全速运行，电池寿命缩短至数小时 | 空闲时进入深度睡眠，平均功耗降低10~50倍 |
| 准确率 | 固定使用高精度模型，导致内存溢出或推理超时 | 根据场景动态切换模型，在资源允许时使用高精度模型 |
以一个具体的工业振动监测场景为例：设备需要每200ms采集一次振动数据并执行FFT+CNN推理，用于检测轴承故障。如果调度器不做任何优化，设备将始终以最高主频运行，功耗约为50mW，一块200mAh的纽扣电池只能维持约4小时。而引入调度策略后：在正常工况下，调度器将主频降至48MHz，推理频率降为每500ms一次，功耗降至8mW；当检测到振动幅值异常时，调度器立即提升主频至120MHz，并将推理频率提高到每100ms一次，同时切换到更高精度的故障分类模型。这种动态调度使平均功耗降至12mW，电池寿命延长至16小时以上，同时保证了异常检测的实时性和准确性。
四、典型应用场景中的调度特征
不同应用场景对推理调度的需求差异显著，理解这些差异是设计调度策略的前提。下表对比了三个典型场景的调度特征：
| 场景 | 任务类型 | 实时性要求 | 功耗预算 | 调度重点 |
|---|---|---|---|---|
| 智能手表活动识别 | 周期性（每50ms） | 中等（100ms内响应） | 极低（<1mW平均） | 低功耗模式切换、传感器数据融合调度 |
| 工业电机故障检测 | 周期+事件驱动 | 高（异常需10ms内报警） | 中等（可接有线电源） | 优先级抢占、模型动态切换 |
| 智能音箱关键词唤醒 | 事件驱动（持续监听） | 极高（<50ms响应） | 低（待机时<0.5mW） | 两级唤醒（轻量级检测+重量级确认） |
在智能音箱场景中，调度策略通常采用“两级流水线”：第一级使用一个参数量仅10KB的微型模型持续监听音频流，该模型每20ms运行一次，功耗仅0.3mW；当第一级模型检测到可能的唤醒词时，才触发第二级——一个参数量200KB的完整模型进行精确确认。这种调度设计将平均功耗控制在0.5mW以下，同时保证了唤醒准确率。如果直接使用完整模型持续监听，功耗将高达15mW，电池供电设备将无法接受。
五、推理调度的实现路径与挑战
在实际工程中，推理调度的实现通常遵循以下步骤：
- 任务建模：明确所有推理任务的周期、截止时间、最坏执行时间（WCET）、功耗特征。这一步需要结合静态分析（如对模型计算图进行FLOPs估算）和实测数据。
- 调度策略选择：根据任务特征选择调度算法。对于固定周期任务，可采用速率单调调度（RMS）；对于混合任务，可采用最早截止时间优先（EDF）或固定优先级抢占调度。
- 功耗管理集成：将DVFS、睡眠状态机与调度器耦合。例如，在任务间隙插入WFI（Wait For Interrupt）指令，或根据当前任务队列长度动态调整CPU频率。
- 运行时监控与自适应：通过硬件计数器（如DWT->CYCCNT）监控实际执行时间和功耗，当发现任务实际执行时间偏离WCET时，动态调整调度参数。
然而，这一实现路径面临诸多挑战：WCET分析困难（缓存行为、分支预测导致执行时间不确定）、多目标冲突（降低功耗往往意味着降低频率，从而增加执行时间）、模型切换开销（从Flash加载模型到RAM需要时间，可能影响实时性）。这些挑战使得推理调度成为一个需要深度结合硬件特性和应用语义的定制化工程，而非简单的算法套用。
六、总结与复盘
本章从TinyML的定义出发，明确了其资源受限的本质特征，进而引出推理调度这一核心概念。推理调度不是孤立的算法，而是连接硬件能力、模型特性与应用需求的桥梁。在资源受限设备上，没有调度策略的TinyML系统就像没有交通信号灯的城市——虽然车辆（推理任务）都能跑，但拥堵（资源竞争）、事故（超时）和能源浪费（功耗失控）将不可避免。
回顾本章内容，需要重点掌握以下要点：
- TinyML的“三大约束”（内存、算力、功耗）决定了推理调度必须采用轻量级实现，调度器本身的代码和数据结构也要精打细算。
- 推理调度的核心是“动态平衡”——实时性、功耗、准确率三者不可兼得，但可以通过调度策略在不同时间尺度上（毫秒级、秒级、分钟级）进行权衡。
- 典型应用场景的调度需求差异巨大，不存在“万能调度器”，必须针对具体场景定制。
- 实现推理调度需要软硬件协同：硬件提供的定时器、DMA、低功耗模式是调度策略得以实施的基础。