2、推理能耗模型：能耗的组成、测量与建模基础
各位同学，咱们今天聊聊推理能耗模型。说实话，这章是整个课程里最“硬核”的部分之一。你想想看，如果你连能耗从哪来、怎么测、怎么建模都不清楚，那后面谈优化就是空中楼阁。
我个人习惯是，拿到一个新板子，先跑一遍能耗基线。不是跑什么复杂模型，就一个简单的矩阵乘法。为什么？因为能耗的三大块——计算、内存、通信——在这个操作里全都能暴露出来。
2.1 能耗的三大组成部分
推理能耗，说白了就是三件事在吃电：
- 计算能耗：CPU/GPU/NPU 做乘加运算时消耗的能量
- 内存能耗：数据在 SRAM、DRAM 之间搬来搬去消耗的能量
- 通信能耗：芯片之间、板卡之间、甚至设备到云端传输数据消耗的能量
我刚开始做边缘推理时，一直以为计算是最耗电的。直到有一次在 Jetson Nano 上跑 MobileNet，用功率计一测，发现内存访问占了将近 60%。嗯，当时我就意识到，直觉靠不住，数据才靠谱。
关键认知： 在边缘设备上，内存访问能耗往往远高于计算能耗。一次 DRAM 访问的能耗，大约是一次乘加运算的 100-200 倍。
2.1.1 计算能耗
计算能耗主要来自算术逻辑单元（ALU）和乘法器。对于神经网络来说，主要是卷积和全连接层的乘加运算。
我一般用这个公式估算：
E_compute = N_mac × E_mac其中 N_mac 是乘加操作次数，E_mac 是单次乘加能耗。不同硬件差异很大，比如：
| 硬件平台 | 单次乘加能耗 (pJ) | 备注 |
|---|---|---|
| ARM Cortex-A72 | ~20 pJ | 通用CPU，效率一般 |
| NVIDIA Jetson GPU | ~5 pJ | 并行度高，但功耗大 |
| Edge TPU | ~2 pJ | 专用加速器，效率高 |
| 定制ASIC | <1 pJ | 极致优化，但灵活性差 |
我的经验： 别太迷信芯片手册上的理论值。实际跑起来，因为内存带宽瓶颈、散热降频等因素，真实能耗往往是理论值的 1.5-2 倍。我习惯在手册值基础上加 30% 的余量。
2.1.2 内存能耗
内存能耗是边缘设备上最大的“隐形杀手”。为什么？因为数据搬移比计算本身更耗电。
我举个例子：在 STM32F4 上跑一个 3×3 卷积，计算本身可能只花 0.1 mJ，但为了把输入特征图和权重从 Flash 搬到 SRAM，再搬回去，内存访问能耗可能高达 0.5 mJ。
内存能耗的组成：
- 片上内存（SRAM）：速度快，能耗低，但容量小（通常几十 KB 到几 MB）
- 片外内存（DRAM/Flash）：容量大，但每次访问能耗高一个数量级
我常用的估算公式：
E_memory = N_read × E_read + N_write × E_write其中 E_read 和 E_write 取决于内存层级。比如：
| 内存层级 | 读取能耗 (pJ/bit) | 延迟 (ns) |
|---|---|---|
| L1 SRAM | ~0.5 | ~1 |
| L2 SRAM | ~2 | ~5 |
| LPDDR4 | ~20 | ~50 |
| NAND Flash | ~100 | ~1000 |
避坑指南： 我曾经在一个项目里，为了省成本选了低端 MCU，结果模型跑起来发热严重。一查才发现，Flash 读取能耗占了 70%。后来换了带更大 SRAM 的芯片，能耗直接降了一半。所以，选型时别只看算力，内存子系统同样关键。
2.1.3 通信能耗
通信能耗在单芯片推理中占比不大，但在分布式推理或端云协同场景下，就成了大头。
我做过一个实验：在 ESP32 上跑一个语音唤醒模型，本地推理只耗 50 mJ，但把音频数据传到云端推理，Wi-Fi 传输就耗了 200 mJ。你想想看，这多不划算。
通信能耗主要来自：
- 无线传输：Wi-Fi、蓝牙、4G/5G 的射频功耗
- 有线传输：SPI、I2C、USB 等接口的驱动功耗
- 协议开销：数据打包、解包、重传等
粗略估算：
E_comm = Data_size × E_per_bit + E_overhead不同无线协议的每比特能耗差异巨大：
| 通信方式 | 每比特能耗 (nJ/bit) | 典型场景 |
|---|---|---|
| BLE 5.0 | ~0.5 | 传感器数据上传 |
| Wi-Fi 802.11n | ~5 | 视频流传输 |
| 4G LTE | ~50 | 远程监控 |
| LoRa | ~0.1 | 低速率远距离 |
我的建议： 如果通信能耗占比超过 20%，就该考虑做数据压缩或本地预处理了。我习惯在模型输出端加一个“变化检测”，只有数据变化超过阈值才传输，能省 80% 的通信能耗。
2.2 能耗测量方法
理论说得再好，不如实际测一测。我见过太多人拿着芯片手册算能耗，结果实际跑起来差好几倍。所以，测量是必须的。
2.2.1 硬件测量方法
最直接的方法，就是在电源路径上串一个采样电阻，用 ADC 采集电压和电流。
我常用的工具：
- INA219/INA226：I2C 接口的电流/功率监测芯片，精度 1% 左右，适合嵌入式场景
- Joulescope：专业功耗分析仪，采样率 2 MHz，能捕捉微秒级的功耗波动
- 示波器 + 电流探头：最灵活，但设置麻烦，适合调试阶段
硬件测量的基本电路：
电源 → 采样电阻 (0.1Ω) → 目标设备
↓
ADC 采集电压差 → 计算电流 → 积分得能耗注意： 采样电阻不能太大，否则压降会影响设备正常工作。我一般选 0.01-0.1Ω，功耗损失控制在 1% 以内。
2.2.2 软件测量方法
如果手头没有硬件工具，也可以用软件方法估算。虽然精度差一些，但胜在方便。
我常用的软件方法：
- Linux 的 powercap 接口：读取 CPU/GPU 的能耗计数器，精度约 10%
- MCU 的 DWT 计数器：通过统计指令执行周期，结合手册功耗数据估算
- 性能计数器 + 能耗模型：统计内存访问次数、MAC 操作次数，代入能耗模型计算
举个例子，在 Linux 系统上：
# 读取 CPU 能耗
cat /sys/class/powercap/intel-rapl/intel-rapl:0/energy_uj
# 读取 GPU 能耗（NVIDIA）
nvidia-smi --query-gpu=power.draw --format=csv我的经验： 软件测量适合做相对比较，比如对比不同优化策略的能耗差异。但绝对数值别太当真，我测过几次，软件读数比实际功耗低 15-20%。所以，关键决策还是要靠硬件测量。
2.3 能耗建模基础
有了测量数据，下一步就是建模。为什么要建模？因为测量只能得到“是什么”，建模才能回答“为什么”和“如果...会怎样”。
2.3.1 经验模型
最简单的建模方法，就是基于测量数据拟合一个公式。比如：
E_total = a × N_mac + b × N_mem + c × N_comm其中 a、b、c 是通过实验数据拟合出来的系数。我一般用最小二乘法，跑 10-20 个不同配置的测试用例，就能得到不错的拟合结果。
优点：简单、直观、容易实现。
缺点：泛化能力差，换一个硬件或模型就得重新拟合。
2.3.2 分析模型
分析模型基于硬件架构的物理特性来建模。比如，对于计算能耗：
E_compute = V^2 × f × C_eff × N_cycle其中 V 是电压，f 是频率，C_eff 是有效电容，N_cycle 是执行周期数。
这种模型更精确，但需要深入了解硬件细节。我一般在做芯片选型或架构设计时用分析模型，日常优化还是用经验模型多。
2.3.3 机器学习模型
最近几年，也有人用机器学习来预测能耗。输入是模型结构、硬件配置、输入数据特征，输出是能耗预测值。
我试过用随机森林做能耗预测，在 5 种不同硬件上训练，预测误差在 5% 以内。但问题是，训练数据收集很麻烦，而且模型本身也有能耗开销。
我的建议： 对于大多数边缘推理场景，经验模型就够用了。别为了追求精度把问题搞复杂。先跑起来，再优化，这是我一贯的原则。
2.4 小结
这一章我们聊了能耗的三大组成——计算、内存、通信。记住了，内存是最大的“电老虎”。测量方法上，硬件测量最准，软件测量最方便。建模方面，从经验模型开始，够用就好。
下一章，我们会把这些知识用起来，开始做实际的能耗优化。到时候，我会拿一个具体的模型，一步步演示怎么分析、怎么优化。嗯，敬请期待。