核心概念：资源预算（内存、Flash、算力、功耗）与业务指标（准确率、延迟、吞吐量）的定义及分类

TinyML 项目的验收之所以困难，根源在于它同时受到物理世界资源约束与业务世界效果要求的双重拉扯。一个模型在服务器上跑出 99% 的准确率毫无意义，如果它需要 2MB 的 RAM 而目标微控制器只有 256KB；同样，一个推理延迟仅 5ms 的模型也没有价值，如果它的准确率只有 60% 无法满足业务底线。因此，我们必须首先建立一套统一的语言体系，将资源预算与业务指标放在同一张验收表上进行度量和权衡。本章将系统定义这两大类指标的内涵、分类方式、度量单位以及它们之间的耦合关系，为后续章节的验收表设计打下概念基础。

资源预算：物理世界的硬性天花板

资源预算描述的是目标硬件平台能够提供的物理资源上限。在 TinyML 场景中，这些资源不是"越多越好"的软性指标，而是决定方案是否可行的硬性约束。如果模型超出内存预算，系统直接无法启动；如果 Flash 超限，固件无法烧录；如果功耗超标，电池寿命不满足产品规格。因此，资源预算在验收表中通常扮演"一票否决"的角色。

内存（RAM）预算

内存是 TinyML 中最稀缺的资源。微控制器的 RAM 通常在 16KB 到 512KB 之间，而一个简单的 CNN 模型在推理过程中，每一层的激活值（activation）都需要暂存在 RAM 中。内存预算需要区分两类占用：静态占用（模型权重、代码段、全局变量）和动态占用（推理时的中间激活值、输入输出缓冲区、运行时堆栈）。实际工程中，我们通常用以下公式估算峰值内存需求：

峰值RAM = 模型权重驻留 + 最大激活层输出 + 输入/输出缓冲区 + 运行时堆栈 + 系统保留

例如，在 STM32F4 系列（192KB RAM）上部署关键词唤醒模型时，若模型权重为 80KB，最大激活层为 30KB，输入缓冲区 16KB，堆栈预留 8KB，则总占用约 134KB，剩余约 58KB 供系统其他任务使用。验收时，需要明确内存余量比例（建议至少保留 15%-20% 余量），以应对极端输入尺寸或系统升级。

Flash（存储）预算

Flash 用于持久化存储模型权重、推理代码、运行时库以及启动代码。与 RAM 不同，Flash 的占用是相对静态的，但同样存在"超限即失败"的特性。Flash 预算需要覆盖：模型权重文件（通常以 C 数组或二进制形式嵌入）、推理引擎代码（如 TensorFlow Lite Micro 内核）、应用业务代码以及启动引导程序。一个常见的误区是只计算模型权重而忽略推理引擎本身的大小——TFLite Micro 的基础运行时约 10-20KB，加上算子库后可能膨胀到 50-100KB。在验收表中，Flash 预算应明确列出各项子占用，并给出总容量上限。

算力（Compute）预算

算力描述处理器执行推理所需的运算量，常用单位包括 MACs（乘加运算次数）、MOPS（百万次运算/秒）或 DMIPs（Dhrystone 百万指令/秒）。算力预算的核心意义在于判断"在目标帧率下，处理器是否来得及完成推理"。例如，一个 8MHz 的 Cortex-M0+ 内核，其峰值算力约为 8M MACs/s，而一个 300KB 的 MobileNetV1 模型需要约 569M MACs——显然无法实时运行。算力预算需要结合目标帧率计算：

所需算力 = 单次推理MACs × 目标帧率（FPS）

如果所需算力超过硬件峰值算力的 70%，就需要考虑模型压缩或降低帧率。算力预算还直接影响功耗——算得越快，越早进入休眠，平均功耗越低。

功耗（Power）预算

功耗是 TinyML 区别于其他嵌入式 AI 场景的核心指标。对于电池供电设备，功耗直接决定产品续航。功耗预算需要区分三种状态：峰值功耗（推理瞬间）、平均功耗（一个完整工作周期内）和待机功耗（休眠状态）。验收时通常以"电池寿命"作为最终业务指标，而功耗预算则是实现该指标的技术约束。例如，一个 300mAh 的纽扣电池，若平均工作电流为 5mA，则理论续航为 60 小时；若通过降低推理频率将平均电流降至 0.5mA，续航可延长至 600 小时。功耗预算与算力、内存访问模式、外设使用频率密切相关，需要综合考量。

资源类型	典型单位	常见范围（MCU）	超限后果	验收优先级
RAM	KB / MB	16KB - 512KB	系统崩溃 / 无法启动	一票否决
Flash	KB / MB	64KB - 2MB	固件无法烧录	一票否决
算力	MACs / MOPS	1M - 100M MACs/s	帧率不达标 / 卡顿	高
功耗	mA / mW	0.1mA - 100mA	续航不满足规格	高

业务指标：需求侧的效果标尺

业务指标描述的是模型在真实场景中达成业务目标的程度。与资源预算的"硬约束"属性不同，业务指标通常是"软目标"——它们存在可接受的阈值范围，且不同指标之间可能存在冲突。业务指标的核心挑战在于：实验室指标与真实场景指标往往存在显著差异，因此验收表中的业务指标必须定义在"真实部署条件"下。

准确率（Accuracy）及其衍生指标

准确率是最直观的业务指标，但在 TinyML 场景中需要进一步细分。对于分类任务，常用 Top-1 准确率（预测概率最高的类别是否正确）和 Top-5 准确率（前五个预测中是否包含正确类别）。对于检测任务，则使用 mAP（平均精度均值）或 F1 Score（精确率与召回率的调和平均）。在工业异常检测场景中，误报率（False Positive Rate）和漏报率（False Negative Rate）往往比整体准确率更重要——一个将正常振动误判为故障的模型，会导致产线频繁停机，损失远大于漏报一次故障。验收时，需要根据业务场景明确"哪个错误代价更高"，并据此设定准确率指标的权重。

延迟（Latency）指标

延迟指从输入数据到达处理器到输出结果可用的时间间隔，单位通常为毫秒（ms）。延迟指标需要区分单次推理延迟和端到端延迟——后者还包括传感器采样、数据预处理、通信传输等环节。在交互式应用（如语音唤醒）中，延迟直接决定用户体验；在工业控制中，延迟可能影响安全响应时间。延迟的统计分布同样重要：P50 延迟（中位数）反映典型性能，P95/P99 延迟反映极端情况下的表现。由于 TinyML 设备可能受到中断、内存竞争、温度变化等因素影响，延迟波动往往比服务器端更大，验收时应同时设定平均延迟上限和尾延迟上限。

吞吐量（Throughput）指标

吞吐量描述系统在单位时间内处理的样本数量，常用单位是 FPS（帧/秒）或 次/秒。吞吐量与延迟密切相关但不等同：延迟是单次处理的耗时，吞吐量是系统整体的处理能力。在连续运行的数据流场景（如振动监测、心率检测）中，吞吐量必须大于数据到达速率，否则数据会积压丢失。吞吐量还受批处理能力影响——某些硬件支持多输入并行推理，但 TinyML 设备通常为单输入流，因此吞吐量往往受限于单次推理延迟和系统调度开销。验收时，需要明确吞吐量的持续运行时间——设备连续工作 1 小时、24 小时还是 7×24 小时，其平均吞吐量可能因热降频或内存碎片而不同。

业务 KPI 指标

除了上述技术性业务指标外，TinyML 项目还需要关注更高层的业务 KPI，例如电池续航时间、设备成本、覆盖率（如语音助手在嘈杂环境下的唤醒成功率）、误触发次数/天等。这些指标往往由资源预算和业务指标共同决定。例如，电池续航 = 电池容量 ÷ 平均功耗，而平均功耗又取决于推理频率（由业务需求决定）和单次推理功耗（由算力和硬件决定）。因此，验收表必须建立"资源预算 → 业务指标 → 业务 KPI"的因果链，确保每一项 KPI 都能追溯到具体的资源或算法决策。

资源预算与业务指标的耦合关系

资源预算与业务指标并非独立存在，它们之间存在复杂的耦合关系。理解这些关系是设计验收表的前提。最核心的耦合体现在以下三个维度：

• 模型大小 vs 准确率：更大的模型通常准确率更高，但占用更多 Flash 和 RAM。量化（从 FP32 到 INT8）可以减少 4 倍存储和内存，但可能带来 1%-3% 的准确率损失。剪枝可以移除冗余权重，但过度剪枝会导致准确率急剧下降。
• 算力 vs 延迟/吞吐量：在硬件算力固定的情况下，单次推理的 MACs 直接决定延迟下限。降低 MACs（如使用深度可分离卷积）可以降低延迟，但可能影响准确率。反之，提高时钟频率可以降低延迟，但会增加功耗。
• 功耗 vs 业务连续性：推理频率越高，平均功耗越大，电池寿命越短。业务需要"实时响应"还是"周期性检测"直接决定了功耗预算的分配。例如，一个智能门锁的人脸识别，可以只在有人靠近时唤醒，而不是持续运行。

案例拆解：智能振动监测节点的指标定义

我们以一个工业设备振动监测节点为例，完整演示资源预算与业务指标的定义过程。该节点部署在工厂电机上，通过加速度传感器采集振动数据，使用 TinyML 模型判断设备是否处于异常状态。

背景与约束：设备采用 CR2032 纽扣电池供电（容量 220mAh），要求续航至少 6 个月（约 4380 小时）。主控为 Nordic nRF52840（Cortex-M4F，64MHz，256KB RAM，1MB Flash）。传感器采样率 1kHz，每次采集 256 个样本（256ms 窗口），要求每 5 秒完成一次推理。

初始目标与现象：初始模型为一个 3 层卷积网络，FP32 权重，大小 180KB，单次推理 MACs 为 2.3M。实测单次推理延迟 45ms，峰值电流 12mA，平均电流（含传感器采样和无线传输）约 0.8mA。计算电池寿命：220mAh ÷ 0.8mA ≈ 275 小时，远低于 4380 小时目标。

分析判断过程：首先检查资源预算——Flash 占用 180KB（模型）+ 60KB（代码）= 240KB，在 1MB 预算内；RAM 峰值占用 85KB，在 256KB 预算内。算力方面，2.3M MACs ÷ 45ms ≈ 51M MACs/s，远低于 M4F 的峰值（约 80M MACs/s），算力不是瓶颈。核心问题在功耗——平均电流 0.8mA 中，推理部分约占 0.3mA（12mA × 45ms ÷ 5000ms），传感器采样约占 0.2mA，无线传输约占 0.2mA，待机约占 0.1mA。要满足 4380 小时续航，平均电流需降至 220mAh ÷ 4380h ≈ 0.05mA，即需要降低 16 倍。

实际操作步骤：第一步，将模型从 FP32 量化为 INT8，Flash 降至 45KB，RAM 峰值降至 32KB，单次推理 MACs 降至 2.1M（量化后算子略有变化），延迟降至 38ms。第二步，将推理频率从每 5 秒一次改为每 30 秒一次（业务上可接受，因为设备故障发展通常需要数分钟）。第三步，优化传感器采样策略——仅在推理前 300ms 内开启传感器，其余时间关闭。第四步，将无线传输改为仅在检测到异常时发送数据，正常时每 10 分钟发送一次心跳包。

结果对比：优化后，平均电流降至 0.045mA，电池寿命约 4889 小时，满足 6 个月目标。准确率从 FP32 的 94.2% 降至 INT8 的 92.8%，仍在业务可接受范围（≥90%）。延迟 38ms 满足实时性要求。资源预算全部达标，业务指标全部满足。

风险与代价：量化后模型对低幅值振动信号的敏感度有所下降，误报率从 1.2% 升至 1.8%，但仍在可接受范围。推理频率降低意味着故障发现时间从最长 5 秒延长至 30 秒，对于快速发展的故障（如轴承碎裂）可能不够及时。复盘经验：功耗优化应优先于模型压缩——在本案例中，降低推理频率和优化采样策略带来的功耗节省远大于量化本身。

总结复盘：指标定义的核心要点

在 TinyML 验收表中，资源预算与业务指标的定义需要遵循以下要点：第一，资源预算必须量化到具体数值，不能使用"尽量小""够用就行"等模糊表述；第二，业务指标必须定义在真实部署条件下，包括温度范围、输入分布、并发场景等；第三，必须建立指标间的因果关系，明确哪些资源约束影响哪些业务指标，以便在验收不达标时快速定位问题；第四，预留合理的余量——资源预算建议保留 15%-20% 余量，业务指标建议设定"目标值"和"最低可接受值"两档，避免因环境波动导致验收失败。

最终，验收表的核心价值在于将"这个模型好不好"转化为"这个模型在指定硬件上、以指定功耗预算、达到指定业务效果"的可验证命题。只有资源预算与业务指标在同一张表上并列呈现、相互约束，TinyML 项目的验收才能从主观判断走向客观决策。