算法能耗模型：为什么更快的算法反而更耗电？

我最近在做一块低功耗嵌入式平台的算法移植，被一个现象搞得很困惑：把一个排序模块从快排换成堆排序，理论上比较次数更稳定，跑下来的时间确实快了15%，可是整板功耗反而涨了一截。这让我重新审视算法分析中一个长期被忽略的维度——能耗模型。我们在课程和面试里反复比较时间复杂度和空间复杂度，但很少有人把能耗当成一等的评估标准。可在移动设备、边缘计算、数据中心这些场景里，能耗模型和计算效率的平衡，往往比单纯看耗时更关键。这篇内容我把自己踩过的坑、实测数据和沉淀下来的方法论整理出来，希望对做算法选型和能耗优化的朋友有实际帮助。这也是我这个系列里围绕能耗问题做的第四次系统整理，前几篇偏硬件和体系结构，这篇会把重点放到算法分析本身。

1. 算法分析多了个能耗维度之后，很多“最优解”要重写了

1.1 传统复杂度分析没回答的问题

传统算法分析回答的是：输入规模 n 趋近无穷时，操作次数随 n 怎么增长。这个框架非常优雅，但它隐含地假设所有操作代价一样。实际硬件上，一次乘法指令和一次缓存未命中的代价不同，一次浮点运算和一次内存访问的能耗也不同。当我们把能耗这个维度加进来，“最优算法”的定义就要重新讨论。

以排序为例，快速排序平均情况 O(n log n)，在教科书和工程里都被认为是不错的选择。但快排的递归深度、分支预测失败率、缓存局部性在不同数据分布下波动很大。堆排序呢？它的比较次数稳定，但访问模式是跳跃式的，缓存命中率很差。在特定输入规模下，堆排序的能耗可能比快速排序低，也可能高得多。这些差异只有在能耗模型下才看得出来。

我这么说不是要否定复杂度分析，它仍然是算法设计的骨架。问题在于：很多工程决策完全依赖渐进复杂度排序，把这个排序当成唯一真理，忽略了常数因子、访存模式、运行时功耗行为这些在能耗视角下同样关键的因素。做与传统复杂度分析互补的能耗评估，往往能发现“标准答案”外的更优解。

1.2 能耗为什么进入算法评估视野

原因很现实：算法跑在哪，功耗就在哪被看见。移动端 App 里一个低效算法不仅仅是让用户等，还会缩短续航；数据中心的节能调度中，同一个大数据任务用不同算法执行，耗电差异可以到两位数百分比；在电池供电的 IoT 设备上，算法能耗直接决定电池能用几个月而不是几周。

超算领域早就有了 Green500 这类能耗榜单，说明在性能之外，能耗已经成为一个独立且可量化的评估维度。算法分析作为一切计算系统的基础，自然也需要把能耗模型纳入分析框架，而不是把它当成编译器或硬件的“锅”。尤其在三五年内，边缘设备、可穿戴设备、嵌入式传感器只会越来越多，跑在上面的算法到底“吃多少电”，会成为系统设计能否成立的前置条件，而不是上线后才发现的问题。

1.3 为什么谈算法能耗要落在“能耗模型”上

直接看设备功耗行不行？理论上可以，实际上问题很大。设备功耗包含的东西太多：屏幕、无线模块、风扇、其他进程、温度变化。这些和算法本身没有因果关系。一段排序算法运行期间，屏幕功耗可能占了 80%，算法自身的贡献被完全淹没。

所以我们真正关心的是“由算法执行直接贡献的动态能耗”加上“算法调度对系统状态的影响”。这两部分必须通过一套模型来抽象和分解，才能在不同硬件、不同系统环境下比较不同算法。这套模型的核心思想就是分清楚哪些功耗是算法引起的，哪些是系统本来就有的，哪些是环境噪声。层次化拆解是做这件事的基础，也是我接下来要展开的内容。

2. 能耗模型的层次拆解：别把系统功耗当算法功耗

2.1 硬件层的物理基础

数字电路里的动态功耗大概可以用一个公式概括：

code复制P_dynamic = α * C * V² * f

α 是翻转率（switching activity），表示电路节点在单位时间内发生 0→1 或 1→0 翻转的比例；C 是等效电容；V 是工作电压；f 是时钟频率。

从这个公式能看出两个算法相关的问题。

第一个是 α。算法不同，执行的指令序列不同，电路翻转率不同。搜索引擎里更密集的运算会让总线和 ALU 翻转更多，能耗自然更高。这个微观层面的差异最终会表现为指令级别的能耗差异，不同指令类别之间的能耗差距可达数倍甚至一个数量级。

第二个是 f。频率是硬件状态，不是算法直接决定的，但是算法的并行度和计算密度会影响系统选择多高的频率运行（DVFS，即动态电压频率调节），这是一个间接影响的通道。算法负载越重，系统越倾向于拉高频率，电压也随之升高，而功耗公式里 V 是平方项，影响会被急剧放大。这也是后面要重点讲的一个矛盾点。

除了动态功耗，还有静态功耗（漏电流），在先进制程里占比越来越大，不过它和算法执行的关系较