想象你开了一家小餐馆,后厨不大,人手有限,但每天电费账单高得吓人。账单上的钱主要砸在三个地方:灶台火力(CPU/GPU计算)、冰箱储物(内存读写)、外卖跑腿(网络通信)。手机里的 AI 应用就是这位掌勺大厨——识别一张图片、唤醒一次语音助手,都是在后厨里“开火炒菜”。而电池,就是你的电费预算。 精打细算的老板不会让厨师一直开大火,也不会在打烊后还灯明火旺。他有三招:根据菜谱调节火力(动态精度调节)、把硬菜外包给中央厨房(计算卸载)、没人点餐就关灯省电(休眠调度),再加上集中上菜(批量推理)、给每台电器装电表(功耗测量)、总结一本“电费预算菜谱”(功耗建模)。本文就用这家小餐馆的日常,带你彻底搞懂移动端 AI 的能耗优化。

岗位关联

对 AI 从业者而言,掌握移动端能耗优化意味着你交付的模型不再是“实验室里的玩具”,而是能在真实手机上流畅运行、续航持久的可用产品——这是边缘 AI 工程师与算法工程师拉开差距的核心能力。

目录
  1. 可视化演示
  2. 能耗三维度:看懂你的“后厨电费账单”
  3. 动态精度调节:大火与小火的艺术
  4. 计算卸载:外包给中央厨房
  5. 休眠调度:打烊后的省电哲学
  6. 批量推理:聚餐时的集中上菜
  7. 功耗测量:给厨房装上电表
  8. 功耗建模:预算电费的菜谱
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态展示动态精度调节、计算卸载策略、休眠调度与能耗对比四个视角,直观理解移动端AI部署的功耗优化方法。

本节配有交互动效(进入视口后自动加载,约 3KB)。

能耗三维度:看懂你的“后厨电费账单”

小餐馆老板每天打烊后都要看一眼电费账单。账单上的钱花在三个地方:灶台火力、冰箱储物、外卖跑腿。手机里的 AI 应用也一样——每一次推理、每一次唤醒,耗电都逃不出这三个维度。

在移动端,AI 任务执行时,CPU/GPU 在做矩阵乘法和卷积运算,这是“计算”维度的能耗;模型参数和中间特征图要在内存里读写,这是“存储”维度的能耗;如果任务需要联网,Wi-Fi 或蜂窝模块收发数据,则是“通信”维度的能耗。三个维度各有各的功率和持续时间,合起来就是一次 AI 任务的总能耗。

把这三个分项展开写,就得到移动端能耗的基础公式。这个公式是整个能耗优化的“总账本”,后面所有策略都是为了压低某些分项。

老板看懂账单后,才能判断省电的主战场在哪里:如果灶台占了六成电,优化就该锁定计算;如果外卖跑腿占大头,就该考虑少联网。账单是决策的起点,而不是看到哪省就省哪。

E=∑iPi×ti=Pcalctcalc+Pmemtmem+Pcommtcomm\displaystyle E = \sum_i P_i \times t_i = P_{calc}t_{calc} + P_{mem}t_{mem} + P_{comm}t_{comm}
  1. 能耗符号E(Energy)表示一次 AI 任务消耗的总能量,单位是焦耳(J),可以理解为“电费总额”。
    E\displaystyle E
  2. 求和运算Σ 把所有部件的能耗分项累加起来,总能耗不是某一个部件单独决定的。
    ∑iPi×ti\displaystyle \sum_i P_i \times t_i
  3. 计算能耗项P_calc 是 CPU/GPU 的平均功率,t_calc 是计算持续的时间,两者相乘就是“灶台火力”的电费。
    Pcalctcalc\displaystyle P_{calc}t_{calc}
  4. 存储与通信项P_mem × t_mem 对应内存读写的能耗,P_comm × t_comm 对应网络传输的能耗。
    Pmemtmem+Pcommtcomm\displaystyle P_{mem}t_{mem} + P_{comm}t_{comm}

动态精度调节:大火与小火的艺术

有经验的厨师不会永远开大火——炖汤要小火慢煲,爆炒要大火快攻。AI 推理也是如此,并非所有计算都需要最高精度。

神经网络推理默认常用 FP32(32 位浮点数)表示权重和激活值。如果换成 FP16(16 位)甚至 INT8(8 位整数),单个数值的位宽减半甚至变为四分之一,硬件的计算能耗也近似同比例下降。代价是数值精度有所损失,但在很多任务中,模型本身有足够的鲁棒性,精度损失往往不到 1%。

动态精度调节的“动态”二字是关键:系统根据当前任务对精度损失的敏感程度,实时切换位宽。比如人脸解锁这种安全敏感任务保持高精度,而场景分类这种容错较高的任务就用低精度。

老板看菜下碟、厨师看火调速:该用大火时绝不省火,能用小火时绝不浪费。动态精度调节就是在保证菜品(模型性能)质量的前提下,把火候调到刚刚好。

Ecalc′=b′b×Ecalc,ΔE=(1−b′b)×Ecalc\displaystyle E_{calc}' = \frac{b'}{b} \times E_{calc}, \quad \Delta E = \left(1 - \frac{b'}{b}\right) \times E_{calc}
  1. 位宽比例b' 和 b 分别表示优化后与优化前的数值位宽,比如从 32 位降到 16 位,比例就是 0.5。
    b′b\displaystyle \frac{b'}{b}
  2. 新计算能耗计算能耗按位宽比例近似线性缩放,位宽减半,计算能耗约减半。
    Ecalc′=b′b×Ecalc\displaystyle E_{calc}' = \frac{b'}{b} \times E_{calc}
  3. 节省的能耗ΔE 表示从 FP32 切到低位宽后省下的能耗,1 减去位宽比就是节省比例。
    ΔE=(1−b′b)×Ecalc\displaystyle \Delta E = \left(1 - \frac{b'}{b}\right) \times E_{calc}

计算卸载:外包给中央厨房

小店人手不够时,老板会把招牌菜外包给中央厨房做。但外包不是免费的——外卖跑腿要花油费,等餐也要花时间。划不划算,得算完账才知道。

计算卸载(Computation Offloading)就是这个逻辑:把本地要跑的重型 AI 任务通过 Wi-Fi 或 5G 发送到云端,云端算完把结果传回来。本地计算能耗几乎归零,但两笔新开销出现了:一是收发数据的通信能耗,二是等待期间手机处于低功耗监听状态的待机能耗。

卸载是否划算,取决于一个简单的不等式:卸载后的总能耗是否小于本地执行能耗。在信号满格的 Wi-Fi 下,通信高效,卸载往往很划算;但在信号差的电梯里,数据反复重传,通信能耗可能飙升,还不如本地硬算。

老板不会在暴雨天让外卖小哥骑车跨越半个城市——那油费比自己做菜还贵。计算卸载也要看“路况”:网络好就外包,网络差就自己炒。

Eoffload=Ecomm+Pidle×twait,决策:Eoffload<Elocal\displaystyle E_{offload} = E_{comm} + P_{idle} \times t_{wait}, \quad \text{决策:} E_{offload} < E_{local}
  1. 通信能耗E_comm 包含上传请求和下载结果的全部数据收发能耗,网络越差,这一项越大。
    Ecomm\displaystyle E_{comm}
  2. 等待待机能耗等待云端返回时,手机进入低功耗监听,P_idle 是待机功率,t_wait 是等待时长。
    Pidle×twait\displaystyle P_{idle} \times t_{wait}
  3. 卸载判定条件只有当卸载后的总能耗小于本地执行能耗时才卸载,否则继续本地计算。
    Eoffload<Elocal\displaystyle E_{offload} < E_{local}

休眠调度:打烊后的省电哲学

小店打烊后,老板不会让所有灯和灶火继续烧着,只会留一盏门灯,有人敲门才把灯全打开。手机 AI 也一样——不在推理时,就应该“打烊”。

休眠调度(Sleep Scheduling)让芯片在空闲期进入深度睡眠(Deep Sleep),功率从数百毫瓦骤降到几十微瓦。但睡眠不是免费的:从深度睡眠唤醒到可运行状态,需要一次性消耗一笔能量,还要花时间。如果空闲时间太短,频繁唤醒反而会吃掉省下的电。

调度策略的核心是预测空闲时长:空闲很短就不睡,空闲中等用轻度睡眠,空闲长才进深度睡眠。语音助手的“低功耗唤醒”就是典型应用——平时只有微型监听模块在运行,听到唤醒词再唤醒完整的识别模型。

门灯(低功耗监听)是合理的省电状态——既不会耗太多电,又能响应客人敲门。休眠调度不是“一睡了之”,而是算好“醒一次花多少钱”,再决定要不要睡。

Ecycle=Pactivetactive+Psleeptsleep+Ewakeup\displaystyle E_{cycle} = P_{active}t_{active} + P_{sleep}t_{sleep} + E_{wakeup}
  1. 活跃期能耗P_active 是工作状态的功率,t_active 是活跃运行时长,这是正常干活时的电费。
    Pactivetactive\displaystyle P_{active}t_{active}
  2. 睡眠期能耗P_sleep 是深度睡眠功率,通常比 P_active 小几个数量级,t_sleep 是睡眠时长。
    Psleeptsleep\displaystyle P_{sleep}t_{sleep}
  3. 唤醒开销E_wakeup 是硬件从睡眠恢复到可运行状态消耗的一次性能量,每次进入和退出的“起床费”。
    Ewakeup\displaystyle E_{wakeup}

批量推理:聚餐时的集中上菜

客人零散来,厨师炒一个菜洗一次锅,又费火又费水;聚餐时一桌点八个菜,厨师可以一次备料、一次开火,把备料时间摊到每道菜上。批量推理省电的原理,就是把这笔“洗锅费”摊薄。

每次 AI 推理都有固定开销:加载模型、初始化缓存、启动计算核心。如果每个请求都单独走一遍这些流程,固定开销就被重复支付。把多个样本凑成一个批次(batch)统一推理,固定开销只付一次。

设一次批量推理的固定开销为 E_fixed,每多处理一个样本的边际能耗为 E_per,批量大小为 n。那么每个样本的平均能耗是固定开销除以 n,再加上边际能耗。n 越大,固定开销被摊得越薄,平均能耗越接近边际能耗。

但批量不能无限大——客人等不起,老板也不会为了凑一桌牺牲翻台率。批大小的上限,由业务能容忍的延迟决定,这是批量推理与用户体验之间的平衡木。

Eˉ=Efixedn+Eper\displaystyle \bar{E} = \frac{E_{fixed}}{n} + E_{per}
  1. 固定开销E_fixed 是启动推理引擎的固定能量消耗,与样本数量无关,就像洗锅这件“一次性准备”。
    Efixed\displaystyle E_{fixed}
  2. 边际能耗E_per 是每多处理一个样本新增的能耗,与批量大小基本无关。
    Eper\displaystyle E_{per}
  3. 平均摊薄把固定开销除以样本数 n,得到每个样本分摊到的固定成本,n 越大这项越小。
    Efixedn\displaystyle \frac{E_{fixed}}{n}

功耗测量:给厨房装上电表

想省钱,先得知道每台电器到底吃了多少电。老板买了个电表,挨个设备测。移动端优化也必须先测量——没有准确的数据,一切优化都是盲人摸象。

功耗测量的基础是电学规律:瞬时功率 P 等于电压 V 乘电流 I。工程上常用外接功率监视器(如 Monsoon Power Monitor)或者手机内核的电池电量接口,以固定的采样率记录功率轨迹。由于功率随时间连续变化,能耗需要对功率做时间积分;在离散采样条件下,积分退化为求和。

采样率的选择是个权衡:采样越密集,统计越准确,但采样本身也会消耗设备和工具的资源。通常会在 1Hz 到 1000Hz 之间根据任务时长选择合适的采样率,再通过多次重复实验取平均值来消除噪声。

电表要装对位置——测灶台就只给灶台供电,测冰箱就只给冰箱供电。如果所有电器共用一块电表,数据混在一起,老板就永远不知道谁在偷电。

P=V×I,E=∫0TP(t) dt≈∑i=1NPiΔt\displaystyle P = V \times I, \quad E = \int_{0}^{T} P(t)\,dt \approx \sum_{i=1}^{N} P_i \Delta t
  1. 瞬时功率P 等于 V 乘以 I,电压乘电流得到当前时刻的功率,这是“此刻的电表读数”。
    P=V×I\displaystyle P = V \times I
  2. 积分定义能耗是功率对时间的定积分,从 0 到 T 时刻的功率曲线下面积。
    E=∫0TP(t) dt\displaystyle E = \int_{0}^{T} P(t)\,dt
  3. 离散近似用 N 个采样点 P_i 乘以采样间隔 Δt 求和,逼近真实的积分值。
    ∑i=1NPiΔt\displaystyle \sum_{i=1}^{N} P_i \Delta t

功耗建模:预算电费的菜谱

有了电表数据,老板还想在开店前就预估这个月电费。他总结出一个规律:电费大致等于灶台火力乘以使用时间,加上冰箱容积乘以开门次数,再加一个基础损耗。这就是功耗建模。

功耗建模把设备整体功耗拆解为多个可测量因子(CPU 使用率、内存占用、网络吞吐量)的线性组合。基于采集的真实功耗数据,用线性回归拟合出每个因子的权重系数,就可以在不接电表的情况下预测任意负载下的功耗。

这个线性模型的形式很简洁:预测功耗等于各因子与权重的乘积之和,再加上一个常数项。α、β、γ 分别表示 CPU、内存、网络对功耗的敏感度,δ 是设备空载时的基础功耗。系数拟合完成后,模型就可以用于优化决策:比如判断当前网络条件下该不该卸载。

有了这份“电费菜谱”,老板换新菜(新模型)之前就能估算成本,决定是自己炒(本地推理)还是外包(云端卸载)。建模的价值,是把“拍脑袋省电”变成“算得清账再省电”。

P^=αUcpu+βMused+γBnet+δ\displaystyle \hat{P} = \alpha U_{cpu} + \beta M_{used} + \gamma B_{net} + \delta
  1. 特征变量U_cpu 是 CPU 使用率,M_used 是内存占用比例,B_net 是网络吞吐量,这三个都是可实时读取的指标。
    Ucpu, Mused, Bnet\displaystyle U_{cpu},\ M_{used},\ B_{net}
  2. 回归权重α、β、γ 分别表示三个因子对功耗的敏感程度,数值越大说明该因子越“费电”。
    α, β, γ\displaystyle \alpha,\ \beta,\ \gamma
  3. 基础功耗δ 是设备空载时的基础功耗常量,相当于店门开着但什么都没干时的底耗。
    δ\displaystyle \delta
  4. 预测值把实时采集的特征代入公式,得到当前功率的预测估值。
    P^\displaystyle \hat{P}

AI 应用场景

场景1:手机语音助手的“管家模式”

阶段:移动端推理部署阶段

解决的问题:语音助手需要 24 小时待命监听唤醒词,如果一直用全精度模型常驻后台,一小时能吃掉 10% 以上的电量。传统方案是高性能后台常驻,识别灵敏但续航崩溃。让休眠调度与低功耗唤醒上场:平时只有微型唤醒模块在听,听到唤醒词才启动完整识别模型。

具体案例:某手机厂商在语音助手中实测,采用休眠调度 + 唤醒后动态切换到 FP16 推理,唤醒词识别准确率仅下降 0.3%,24 小时待机能耗从 2400mW 降到 80mW,相当于让手机多撑了半天。

场景2:外卖 App 的“菜品识别”卸载决策

阶段:推理任务执行阶段

解决的问题:用户拍照识别菜品,在 Wi-Fi 环境下把图片上传到云端识别,本地计算能耗几乎为零;但在 4G 弱网环境下,上传图片反复重传,通信能耗反而更高。传统方案固定走云端,遇到弱网就变成“电老虎”。用功耗建模实时估算当前网络条件下的卸载成本,自动决定本地跑还是云端跑。

具体案例:某外卖 App 实测,5G 网络下卸载比本地省电 35%,而弱 4G 信号下卸载比本地费电 20%。接入动态卸载决策后,全网络环境下整体平均功耗下降 18%。

场景3:智能门禁的“批量认证”调度

阶段:推理调度阶段

解决的问题:小区门禁的人脸识别在早晚高峰集中爆发,如果每个用户都单独启动一次推理,固定开销重复消耗。传统方案逐次处理,平均单次推理能耗高。方案:把短时间内到达的人脸凑成 batch 统一推理,摊薄固定开销。

具体案例:某智慧社区门禁高峰期约每秒 3 次识别请求,采用动态批量推理后,单次人脸识别平均能耗降低 42%,延迟仅增加 80ms,用户完全无感知。

Python 演示

python59 行
import numpy as np  class PowerModel:    """线性功耗模型:P = a*cpu + b*mem + g*net + d"""     def __init__(self, lr=0.1, epochs=800):        self.lr = lr        self.epochs = epochs        self.w = None     def fit(self, X, y):        n, m = X.shape        Xb = np.hstack([X, np.ones((n, 1))])        self.w = np.zeros(m + 1)        for _ in range(self.epochs):            pred = Xb @ self.w            grad = 2 * Xb.T @ (pred - y) / n            self.w -= self.lr * grad        return self     def predict(self, X):        Xb = np.hstack([X, np.ones((X.shape[0], 1))])        return Xb @ self.w  def evaluate(power, name):    baseline = 1.2 * 0.9 + 0.6 * 0.7 + 0.8 * 0.4 + 0.3    print(f"{name}: 预估功耗 {power:.2f} mW, 相对能耗 {power / baseline * 100:.1f}%")  def main():    rng = np.random.default_rng(42)    n = 2000    cpu = rng.uniform(0, 1, n)    mem = rng.uniform(0, 0.9, n)    net = rng.uniform(0, 1, n)    power = 1.2 * cpu + 0.6 * mem + 0.8 * net + 0.3 + rng.normal(0, 0.05, n)     X = np.column_stack([cpu, mem, net])    model = PowerModel()    model.fit(X, power)     print("拟合系数: alpha=%.2f beta=%.2f gamma=%.2f delta=%.2f" % (        model.w[0], model.w[1], model.w[2], model.w[3]))     s1 = np.array([[0.35, 0.72, 0.40]])    s2 = np.array([[0.12, 0.50, 0.85]])    s3 = np.array([[0.25, 0.40, 0.22]])    for s in s1:        evaluate(model.predict(s), "动态精度")    for s in s2:        evaluate(model.predict(s), "计算卸载")    for s in s3:        evaluate(model.predict(s), "批量推理")  if __name__ == "__main__":    main()
目的:用模拟采集的手机功耗数据(CPU 使用率、内存占用、网络吞吐量)训练一个线性功耗模型,再借模型评估三种能耗优化策略的预估功耗。
  1. self.w = np.zeros(m + 1)初始化回归系数向量,比特征数多一个位置存放基础功耗 δ。
  2. Xb = np.hstack([X, np.ones((n, 1))])给特征矩阵拼接一列全 1,对应常数项 δ。
  3. grad = 2 * Xb.T @ (pred - y) / n计算均方误差对系数的梯度,这是梯度下降的“方向盘”。
  4. self.w -= self.lr * grad沿负梯度方向更新系数,逐步逼近最优拟合。
  5. power = 1.2 * cpu + 0.6 * mem + 0.8 * net + 0.3 + rng.normal(0, 0.05, n)用已知的真实系数加上高斯噪声,模拟真实世界的功耗采集数据。
  6. model.fit(X, power)训练模型,让线性回归自己“学”出每个因子的敏感度。
  7. evaluate(model.predict(s), "动态精度")用训练好的模型“算一算”,不装电表就能预估该策略下的功耗。

常见误区

误区既然 FP16 比 FP32 省一半电,那 INT8、INT4 不是更香吗?干脆把所有模型都切成最低位宽,省到极致。

正解位宽下降带来的精度损失是非线性的——FP32 到 FP16 损失很小,FP16 到 INT8 损失尚可接受,但 INT8 到 INT4 往往模型直接“糊了”。动态精度调节的精髓是“该高时高、该低时低”,就像厨师炖汤用小火、爆炒必须大火,全程小火做不出脆嫩的口感。要结合任务对精度的敏感度来选择位宽,而不是一味求低。

为何常见:直观上“位宽减半、能耗减半”给了人线性错觉,忽略了精度损失随位宽下降而急剧加速的非线性特性。

误区本地算又热又费电,不如全部上传云端,手机当个遥控器,肯定最省电。

正解卸载省了计算能耗,但通信能耗可能是无底洞。弱网下数据反复重传,等待期间手机还不能深度休眠,E_comm + P_idle × t_wait 完全可能超过本地计算能耗。卸载是一道不等式选择题,必须把两边的账都算了再决定。网络好、数据量小、任务重时才值得卸载。

为何常见:看到“云端省电”的成功案例就以为全局适用,忽略了网络条件这个最大的变量。

误区深度睡眠功率最低,那让芯片能睡多久睡多久,空闲就立刻深睡,反正唤醒也很快。

正解每次休眠-唤醒都有转换开销 E_wakeup,频繁唤醒等于反复交“起床费”。如果空闲时间比唤醒加入睡的开销还短,深睡反而更费电。成熟的调度策略会预测空闲时长:短空闲保持轻度睡眠,长空闲才进深度睡眠,就像门灯常亮但大灯绝不多开。

为何常见:只盯着 P_sleep 远小于 P_active 这个事实,忽略了“入睡”和“醒来”本身也有能量代价。

误区平均能耗 E_fixed/n 随 n 单调下降,那把所有请求都攒成一大把再统一推理,肯定最省电。

正解n 增大意味着延迟线性上升,用户可能早就走了;而且攒批期间设备一直处于活跃等待状态,P_active × t_active 可能把省下的固定开销又吃回去。批大小不是越大越好,而是在业务延迟预算约束下的最优解。

为何常见:把能耗公式当成了纯数学问题,忽略了真实场景中延迟和用户体验的硬约束。

面试题

Q1. 移动端 AI 任务的总能耗主要由哪三个维度构成?

单选题 · easy

  • A.计算、存储、通信三个维度← 正确答案
  • B.仅 CPU 单核计算
  • C.仅屏幕显示耗电
  • D.仅网络传输耗电

答案:A。总能耗包括计算(CPU/GPU)、存储(内存读写)和通信(网络收发)三部分。B、C、D 都只看到了单一方面,而优化必须先看全整个“电费账单”。

Q2. 动态精度调节为什么能降低计算能耗?

单选题 · easy

  • A.降低数值位宽从而减少计算量← 正确答案
  • B.降低屏幕亮度来省电
  • C.关闭网络模块减少耗电
  • D.压缩内存容量来省电

答案:A。降低数值位宽(如 FP32→FP16)让每个数值占用的位变少,硬件计算能耗近似按比例下降。屏幕、网络、内存都与计算的精度调节无关。

Q3. 计算卸载的决策条件是什么?

单选题 · mid

  • A.云端模型必须本地更大
  • B.卸载后能耗小于本地能耗← 正确答案
  • C.本地 CPU 核心一定空闲
  • D.网络信号必定满格接入

答案:B。卸载是否合算,取决于 E_offload = E_comm + P_idle × t_wait 是否小于 E_local。云端模型大小、CPU 状态、信号满格都不是决策的核心条件。

Q4. 哪些情况会导致计算卸载反而更费电?

多选题 · mid

  • A.弱网下反复重传数据包← 正确答案
  • B.等待期间无法进入休眠← 正确答案
  • C.云端推理速度非常快
  • D.上传数据量过大过多← 正确答案

答案:ABD。弱网重传会使 E_comm 飙升;等待期间无法休眠会拉长高功耗待机时间;数据量大直接抬高通信能耗。云端推理快是卸载的有利因素,不会导致更费电。

Q5. 休眠调度中“唤醒开销”指的是什么?

单选题 · mid

  • A.从睡眠恢复运行的一次性能耗← 正确答案
  • B.手机开机动画的耗电
  • C.网络重连的流量费用
  • D.屏幕点亮消耗的电量

答案:A。唤醒开销 E_wakeup 是硬件从深度睡眠恢复到可运行状态时的一次性固定能耗。它与开机动画、网络流量、屏幕点亮的成本无关,是调度决策中必须计入的“起床费”。

Q6. 批量推理能够省电的原因是什么?

多选题 · hard

  • A.摊薄每次推理固定启动开销← 正确答案
  • B.提升核心利用率减少空转← 正确答案
  • C.完全不增加服务延迟
  • D.降低每个样本边际能耗

答案:AB。批量推理把 E_fixed 摊到 n 个样本上,同时提高计算核心利用率、减少重复启动的空转。它并不降低边际能耗 E_per,而且必然引入一定延迟,C 和 D 都是误解。

Q7. 功耗测量中瞬时功率 P 的计算公式是?

单选题 · easy

  • A.P = V × I← 正确答案
  • B.P = V / I
  • C.P = I / V
  • D.P = V + I

答案:A。电学基本定律,功率等于电压乘电流。其余三个都是错误组合。

Q8. 功耗模型中线性回归的 δ 项代表什么?

单选题 · mid

  • A.设备空闲时的基础功耗← 正确答案
  • B.CPU 使用率的权重系数
  • C.网络吞吐量的权重系数
  • D.内存占用的权重系数

答案:A。δ 是常数项,对应设备空载时的基础功耗,好比店里什么菜都没做时也要付的基本电费。α、β、γ 才是各因子的权重。

Q9. 关于能耗公式 E = Σ P_i × t_i,下列说法正确的有?

多选题 · hard

  • A.功率越大总能耗一定越高
  • B.能耗是功率对时间的总计← 正确答案
  • C.各维度能耗分类统计再汇总← 正确答案
  • D.运行时间短能耗就一定低

答案:BC。能耗取决于功率和持续时间两者的乘积。功率大但时间极短,能耗未必高;时间短但功率巨大,能耗也可能很高。因此 A、D 的“一定”说法都过于绝对。

Q10. 本地执行某 AI 任务能耗为 950mJ,卸载后通信能耗 300mJ,等待期间待机功率 80mW、等待 5 秒。正确的判断是?

单选题 · hard

  • A.卸载成本 700mJ,应当卸载← 正确答案
  • B.卸载成本 400mJ,应当本地
  • C.卸载成本 700mJ,不应卸载
  • D.卸载成本 1000mJ,不应卸载

答案:A。E_offload = E_comm + P_idle × t_wait = 300 + 80 × 5 = 700mJ。700mJ < 950mJ,满足卸载条件 E_offload < E_local,所以应当卸载。