2、基础知识：TinyML模型部署后的数据上传需求、功耗预算与网络选型核心考量

TinyML设备的本质是“在资源受限的端侧完成感知与推理，并将最有价值的结果以低代价方式送达云端或网关”。模型部署只是第一步，真正决定系统长期可用性的，是数据上传策略与网络选型。本章围绕三个核心问题展开：端侧到底需要上传什么数据、功耗预算如何科学分配、以及BLE/Wi-Fi/LoRa三种主流无线技术的关键差异与选型逻辑。

2.1 数据上传需求：从“全量上传”到“价值上传”

TinyML设备与传统IoT传感器节点的最大区别在于：端侧已经完成了数据到信息的转化。一个振动传感器每秒产生20KB的原始波形数据，但经过TinyML模型推理后，可能只需要输出“正常”或“异常”两个字节。因此，数据上传需求的第一原则是：只上传决策结果和必要上下文，而非原始数据。

2.1.1 数据上传的三种粒度

在实际工程中，推荐采用分层上传策略：默认只上传推理结果（几字节），当检测到异常或置信度低于阈值时，再触发特征数据甚至原始数据的上传。这种“正常轻量、异常加重”的模式，可以在保持诊断能力的同时，将平均数据量降低2~3个数量级。

2.1.2 上传触发方式设计

• 周期上报：固定间隔（如每5分钟一次）发送心跳包+最新推理结果。适用于状态监控类场景，便于云端判断设备在线状态。
• 事件触发：当模型检测到特定事件（如跌倒、设备过热、异常振动）时立即上报。适用于告警类场景，要求低延迟。
• 云端查询：云端下发指令后设备才上传数据。适用于按需诊断场景，可避免无效传输。
• 自适应混合：正常时低频周期上报，异常时切换为高频事件上报。这是工业级产品的常见选择。

2.2 功耗预算：从电池容量倒推设计约束

功耗预算不是“尽量省电”的模糊概念，而是一个从电池容量和寿命目标倒推出来的硬性工程约束。假设设备使用一节2000mAh的锂电池，目标续航12个月，那么平均电流预算为：

平均电流 = 电池容量 / 目标续航时间
         = 2000mAh / (365天 × 24小时)
         ≈ 228µA

这意味着设备所有工作模式（感知、推理、传输、待机）的平均电流必须控制在228µA以内。而一颗ESP32在Wi-Fi传输时的峰值电流可达240mA，是预算的1000倍以上。因此，占空比设计成为功耗控制的核心手段。

2.2.1 功耗预算分解方法

1. 列出所有工作模式：感知（传感器采样）、推理（MCU计算）、传输（无线发包）、待机（低功耗睡眠）。
2. 测量各模式电流与持续时间：使用精密万用表或功耗分析仪实测，不要依赖数据手册估算。
3. 计算单周期能耗：能耗 = 电流 × 时间，单位为mAh或µAh。
4. 计算平均电流：平均电流 = 单周期总能耗 / 周期总时长。
5. 对比预算并迭代：若超出预算，优先优化传输环节（减少频率、压缩数据量、更换网络技术）。

2.2.2 典型功耗数据参考

2.3 网络选型核心考量：BLE、Wi-Fi与LoRa的对比与决策

三种主流无线技术各有明确的适用边界，选型错误会导致功耗失控或传输不可靠。核心考量维度包括：传输距离、数据速率、功耗特性、网络拓扑、部署成本和生态成熟度。

2.3.1 三种技术关键参数对比

2.3.2 选型决策流程

1. 确定传输距离需求：设备与网关/手机是否在10m内？→ BLE；是否在室内100m内且有Wi-Fi覆盖？→ Wi-Fi；是否在户外数公里范围？→ LoRa。
2. 评估数据量与频率：单次上传超过200B且频率高于1次/分钟？→ Wi-Fi；单次小于100B且频率低于1次/分钟？→ BLE或LoRa。
3. 计算功耗预算：用2.2节的方法估算平均电流，若Wi-Fi导致超预算，降级为BLE或LoRa。
4. 考虑网络基础设施：是否有现成的Wi-Fi AP？是否需要自建LoRa网关？手机作为BLE网关是否可接受？
5. 验证实际环境：在目标部署位置进行信号强度测试（RSSI）和丢包率测试，不要依赖理论值。

2.3.3 案例拆解：工业振动监测节点的网络选型

背景与约束：某工厂需要在200台旋转设备上部署振动监测节点，每台设备间隔约30m，厂房面积约2万m²。要求：每5分钟上报一次振动特征值（约50B），异常时立即上报告警（延迟<10s），电池供电目标续航2年。

初始方案与问题：工程师最初选择Wi-Fi方案，因为厂房已有企业Wi-Fi覆盖。实测发现：ESP32在Wi-Fi连接状态下的平均电流约80mA（含保持连接），2000mAh电池仅能支撑约25小时，远达不到2年目标。即使采用深度睡眠+定时唤醒，每次Wi-Fi重连需要2~3秒、消耗约0.2mAh，每天288次上报消耗57.6mAh，电池寿命约35天，仍不达标。

分析过程：核心矛盾在于Wi-Fi的连接维持功耗和重连开销过高。改用BLE方案后，采用广播模式（非连接）每次发送50B数据仅需约5ms、消耗0.03mAh，每天288次上报消耗8.6mAh，加上待机功耗（10µA×24h=0.24mAh/天），总日均消耗约8.84mAh，2000mAh电池理论寿命约226天，仍不足2年。进一步优化：将上报周期从5分钟延长到15分钟（工厂可接受），日均消耗降至约3.2mAh，电池寿命约625天，满足2年目标。

最终方案：采用BLE 5.0广播模式，nRF52832作为主控，上报周期15分钟，异常事件立即上报。在厂房内部署5个BLE网关（基于树莓派），通过以太网回传云端。实测6个月，电池电压从3.7V降至3.4V，估算剩余容量约65%，符合预期。

复盘经验：① Wi-Fi不适合高频小数据量的电池供电场景；② BLE广播模式比连接模式更省电（省去连接维护开销）；③ 功耗预算必须用实测数据迭代，不能只看芯片手册；④ 适当降低上报频率比更换硬件更有效。

2.4 常见误区与总结复盘

2.4.1 五个常见误区

• 误区一：认为Wi-Fi“不用白不用”。企业已有Wi-Fi覆盖不代表适合电池设备，连接维持功耗和重连开销往往被忽略。
• 误区二：只算峰值电流不算平均电流。峰值电流决定电源设计，平均电流决定电池寿命，两者必须同时评估。
• 误区三：上传原始数据“更安全”。原始数据不仅消耗带宽和电量，还增加云端存储成本。端侧推理结果+异常时补充原始数据才是最优解。
• 误区四：LoRa一定比BLE省电。LoRa的发射电流虽低于Wi-Fi，但传输速率极低，发送相同数据量所需时间更长。对于短距离场景，BLE往往更省电。
• 误区五：忽略协议开销。TCP/IP握手、TLS加密、JSON格式都会显著增加传输量。一个50B的推理结果，经过JSON封装+TCP+Wi-Fi协议后，实际空中传输可能超过500B。

2.4.2 总结：选型决策清单