想象你是一名业余马拉松选手，第一次参加城市半马。发令枪响，你兴奋地全力冲刺，配速拉到 4 分半——三公里后大口喘气、额头滚烫、心跳爆表，五公里处不得不走路，最后拖着疲惫的身体勉强完赛。换成经验丰富的老将，他会全程瞄着心率表：上坡收力、下坡稳住、偶尔补水，体温保持在安全区，反而跑出漂亮成绩。 手机里的 LLM（大语言模型）推理，和跑马拉松如出一辙。芯片就是那位选手：模型每生成一个字，晶体管就要以每秒几十亿次的频率做“开合”运动，像肌肉做功一样消耗电能、产生热量。跑得太猛（频率太高），芯片温度飙升，手机烫手、掉电飞快；不管不顾冲下去，系统就会强制“降频”——相当于身体强制让你停下来走路。 聪明的端侧工程师，做的就是“教练”：帮芯片制定配速策略——什么时候全速冲、什么时候收着跑、体温到多少度必须减速、散热结构怎么排布，最终在不烫手、不掉链子的前提下，把模型又快又稳地跑完。本文用这个马拉松视角，带你一次性看懂移动 LLM 功耗优化与热管理的全貌。

岗位关联

一句话价值：掌握功耗与热管理，是端侧 LLM 从“能跑”到“跑得好”的分水岭——这决定了你的模型是手机里流畅的助手，还是烫手的演示品。

目录
  1. 可视化演示
  2. 功耗发热成因：热量从哪来
  3. 计算调度降耗：教练的配速计划
  4. 热管理机制：身体的体温警戒线
  5. 降频性能影响：减速的代价与真相
  6. 功耗性能平衡：寻找最优工作点
  7. 端侧落地实践：从训练场到赛场
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示FCFS与RR两种CPU调度算法的进程执行时序，通过甘特图直观对比调度策略对等待时间和响应时间的影响。

本节配有交互动效（进入视口后自动加载，约 3KB）。

FCFS调度 先来先服务，按到达顺序依次执行进程 等待时间 = 开始时间 - 到达时间 简单公平但平均等待时间较长

功耗发热成因：热量从哪来

马拉松选手起跑后，大腿肌肉每一次收缩都在做功——做功就要“烧”能量，于是体温迅速爬升。你摸到的滚烫大腿，正是肌肉做功的副产物。手机芯片里的情况一模一样：LLM 每生成一个 token，成千上万个晶体管像微型马达一样高频开合，电能被消耗，热量在指甲盖大的硅片上堆积。

芯片功耗分成两大类，对应“做功”和“漏气”两个来源。第一类是动态功耗，即晶体管开合瞬间消耗的能量，占总功耗的六到八成；第二类是静态功耗，指晶体管即使躺着不动也会漏掉的一点点电流，如同轮胎慢撒气。两者相加，就是芯片从电池里“吃掉”的总功率。

动态功耗和电压、频率直接相关。其中 V 是驱动电压，f 是运行频率，C 是负载电容（可理解为“开合一次要搬运的电荷量”），α 是活动因子（同一时刻真正在翻转的晶体管比例）：

回到马拉松：要降温，要么少做功（降低 α，别让所有肌肉同时发力），要么放慢步频（降低 f），要么减小每一步的幅度（降低 V）。其中最立竿见影的是“放慢步频”和“减小步幅”——这正是下一节计算调度的核心思路。

Ptotal=Pdynamic+Pstatic=αCV2f+IleakV\displaystyle P_{\text{total}} = P_{\text{dynamic}} + P_{\text{static}} = \alpha C V^{2} f + I_{\text{leak}} V
这个公式告诉我们：动态功耗和电压的平方成正比，电压一降，功耗就“唰”地掉一块；频率只起一次方作用，是第二敏感的旋钮。
  1. 总功耗构成芯片总功耗等于动态功耗与静态功耗之和，前者是发热主力，后者是待机也躲不掉的基础消耗。
    Ptotal=Pdynamic+PstaticP_{\text{total}} = P_{\text{dynamic}} + P_{\text{static}}
  2. 动态功耗三项动态功耗等于活动因子、负载电容、电压平方、频率四者相乘，四个因子各有物理含义。
    Pdynamic=αCV2fP_{\text{dynamic}} = \alpha C V^{2} f
  3. 活动因子 α表示同一时刻真正在翻转的晶体管比例，反映“有多少肌肉在同时发力”，取值在 0 到 1 之间。
    0≤α≤10 \le \alpha \le 1
  4. 电压平方项电压一旦降下来，功耗会以平方速度缩水——这是整个功耗优化里最值钱的一个旋钮。
    V2=V×VV^{2} = V \times V
  5. 频率项f 是每秒开关次数，频率越高发热越猛，但它是线性的，性价比不如电压。
    Pdynamic∝fP_{\text{dynamic}} \propto f
  6. 静态泄漏静态功耗等于漏电流乘以电压，温度越高漏电流越大，形成“越热越漏、越漏越热”的正反馈。
    Pstatic=IleakVP_{\text{static}} = I_{\text{leak}} V

计算调度降耗：教练的配速计划

老练的马拉松跑者绝不会全程一个配速：起跑热身、上坡收力、下坡顺势、最后两公里才放开。手机芯片同样拥有“配速计划”，学名 DVFS（动态电压与频率调节）——根据任务轻重实时调整工作电压和频率。比如 LLM 输出“的、了、吗”这类高频常用词时计算量小，芯片自动“慢跑”；遇到复杂上下文生成时才短暂“冲刺”。

除了 DVFS，端侧还常用“大小核”异构调度：大核像冲刺型选手，爆发力强但费电发热；小核像续航型选手，省电但慢。LLM 推理的很多环节（如注意力矩阵乘法）适合大核，而 tokenizer、填充等轻任务丢给小核。更进一步的算子融合，则像改进跑姿——把多个小动作合并成连贯动作，减少内存反复搬运的“无效功”。

为什么降电压收益这么大？看下面这个公式。N 是一次推理总的开关次数（可理解为“总步数”），任务固定时 N 基本不变；而 V 是平方项，电压降到 80%，动态能耗立刻降到原来的 64%：

调度优化的第一性原理是：在总步数不变的前提下，尽可能压低每一步的“做功单价”——优先降电压，其次降频率，再配合小核和算子融合减少 N 本身。教练的配速表，就是这么一栏一栏填出来的。

Edynamic=CV2N\displaystyle E_{\text{dynamic}} = C V^{2} N
公式把“总步数”和“每步单价”分开：任务量（N）由模型决定，但每步的能耗单价（CV²）可以由工程师控制。
  1. 总开关次数 N完成一次 LLM 推理需要开关大量晶体管，N 近似固定，是能耗公式里的“总步数”。
    Edynamic=CV2NE_{\text{dynamic}} = C V^{2} N
  2. 电压平方项电压下降到原来的 80% 时，动态能耗变为原来的 0.64 倍——这就是降电压的高杠杆。
    (0.8)2=0.64(0.8)^{2} = 0.64
  3. 总步数压缩通过算子融合、减少内存搬运可以减小 N，等于优化跑姿少走弯路。
    N=∑翻转次数N = \sum \text{翻转次数}
  4. 能耗结论调度优化的优先级是——先降电压、再降频率、最后压缩 N。
    Edynamic∝V2E_{\text{dynamic}} \propto V^{2}

热管理机制：身体的体温警戒线

跑者身体里有一套自带的热管理系统：体温超过 38.5°C，大脑就发信号让你出汗、放慢速度；超过 40°C 就可能中暑。芯片内部同样有个“体温中枢”——热管理单元，通过分布在芯片各处的温度传感器实时感知硅片温度，一旦越线立刻执行降温动作。

移动端的温控不是“一刀切”，而是多级递进：第一级，温和地降频降压，掐掉发热源头；第二级，温度还在涨就限制功率预算（给芯片定一个“功率配额”，超额就强制削减任务）；第三级，极端情况下暂停部分计算，甚至整机降载，优先保护硬件不被烧毁。

散热结构决定了“热量能不能及时送出去”，用热阻 θ 衡量——这跟“跑者穿什么衣服散热”同理。硅片到空气的温升满足下面这个公式：

热管理 = 源头节流（降功耗）+ 末端疏导（散热）。前者是教练叫选手放慢，后者是给选手换上透气跑服。两者配合，才能让芯片在安全温度内持续输出不掉链子。

TJ=TA+P×θJA\displaystyle T_{J} = T_{A} + P \times \theta_{JA}
公式说人话：芯片内部温度 = 环境温度 + 功耗 × 散热阻力。功耗和热阻越大，内部温度就越高。
  1. 结温 T_J芯片硅片内部的真实温度，是热管理系统的终极监测对象，规格书里给的 85°C、105°C 指的都是它。
    TJ=TA+P×θJAT_{J} = T_{A} + P \times \theta_{JA}
  2. 环境温度 T_A手机壳外的空气温度，属于“出场设定”——夏天暴晒的车内会让基线整体抬高。
    TA=25∘C (典型室温)T_{A} = 25^{\circ}C \ (\text{典型室温})
  3. 功耗 P芯片当前功率，是公式里唯一可以由调度控制的可变项。
    P=Pdynamic+PstaticP = P_{\text{dynamic}} + P_{\text{static}}
  4. 热阻 θ_JA热量从硅片传导到空气的阻力，散热材料越好 θ 越小，相当于散热通道越宽敞。
    θJA=TJ−TAP\theta_{JA} = \frac{T_{J} - T_{A}}{P}

降频性能影响：减速的代价与真相

降频当然不是免费的午餐。想象马拉松选手被迫从 4 分配速降到 6 分配速，完赛时间自然大幅拉长。LLM 推理也一样：芯片降频后，每生成一个字都要花更长时间，用户感受到的“打字速度”变慢。

延迟和频率近似成反比：频率降为 60%，单 token 生成延迟约变为原来的 1.67 倍；每秒能生成的 token 数（吞吐量）也同步下降。但请注意一个常被误解的事实——降频只改变速度，不改变计算内容，模型输出的文字完全相同，只是慢一点，不会变笨。

所以降频的代价是“慢”，收益是“不烫手、能续命”。教练的功力，在于让选手在用户几乎察觉不到的降速范围内压住体温——比如把单 token 延迟从 50ms 抬到 60ms，人眼完全无感，功耗却能下降 30%。

TnewTold≈foldfnew\displaystyle \frac{T_{\text{new}}}{T_{\text{old}}} \approx \frac{f_{\text{old}}}{f_{\text{new}}}
频率和延迟是“跷跷板”：频率砍掉四成，延迟就多出六成多。代价是体感变慢，收益是温度受控、续航保住。
  1. 延迟比例任务执行时间与频率近似成反比，这是数字电路的基本节拍关系。
    TnewTold≈foldfnew\frac{T_{\text{new}}}{T_{\text{old}}} \approx \frac{f_{\text{old}}}{f_{\text{new}}}
  2. 数值代入频率从满频降到 60% 时，延迟倍数约为 1.67。
    10.6≈1.67\frac{1}{0.6} \approx 1.67
  3. 吞吐量变化每秒生成的 token 数等于“单位时间除以单 token 延迟”，同样成反比下降。
    Throughput∝1T\text{Throughput} \propto \frac{1}{T}
  4. 精度不受影响只要电压仍在正常工作范围内，频率改变不改变数字逻辑的结果。
    Outputnew=Outputold\text{Output}_{\text{new}} = \text{Output}_{\text{old}}

功耗性能平衡：寻找最优工作点

既然快会烫、慢会卡，那是不是直接锁最低频率最省事？恰恰相反。跑者一味慢走看似省力，但比赛时间拖得太长，身体的基础代谢消耗反而让总消耗更高。芯片同理：频率过低时任务执行时间被拉长，静态功耗和内存、屏幕等基础功耗一直在烧，总能耗可能不降反升。

于是工程师引入“最优工作点”的概念：存在一个中间频率，让“总能耗最低”且“延迟可接受”。评估这种平衡，常用综合指标 EDP（能耗延迟积）——把“费电”和“慢”放在同一个天平上称重：

更聪明的做法是场景感知调度：用户看视频时后台跑 LLM 任务可以明显降频；用户正快速打字等回复时则优先保性能、容忍短暂发热。真正的高手，不是把每个场景都调到同一个“最优频率”，而是像经验丰富的跑者一样，懂得看路况调整配速。

EDP=E×T=P×T2\displaystyle \text{EDP} = E \times T = P \times T^{2}
EDP 同时惩罚“费电”和“慢”：延迟稍微拉长，就被平方项放大，所以一味省电拖时间会输得很惨。
  1. EDP 定义能耗延迟积 = 总能耗 × 总延迟，两者相乘，同时惩罚费电和慢。
    EDP=E×T\text{EDP} = E \times T
  2. 展开形式总能耗 = 平均功率 × 时间，代入得到 P × T²。
    EDP=P×T2\text{EDP} = P \times T^{2}
  3. 时间平方的杀伤力延迟翻倍，EDP 恶化 4 倍——这就是“不能无脑锁低频”的数学原因。
    (2T)2=4T2(2T)^{2} = 4T^{2}
  4. 最优工作点在不同频率下分别测 EDP，取曲线最低点对应的频率作为工作点。
    f∗=arg⁡min⁡ EDP(f)f^{*} = \arg\min \ \text{EDP}(f)

端侧落地实践：从训练场到赛场

光懂理论上不了赛场。真正的端侧工程师做功耗优化，有一套标准训练流程：先“测心率”——用功耗仪或系统电源管理接口（如 Android batterystats）测出 LLM 推理各阶段的电流曲线；再“找瓶颈”——定位是哪个算子、哪段访存在疯狂耗电；然后“练动作”——结合 DVFS、算子融合、量化等手段针对性优化；最后“复测”——对比优化前后的功耗与延迟，看是否达标。

评估能效有个直观指标 PPW（性能功耗比）：每瓦特功耗能换来多少次运算。换算成马拉松语言，就是“每一口补给能跑多远”。高通、联发科的官方工具链和 Perfetto 等剖析工具，都能帮助端侧工程师精确拿到这些数字。

从测量到优化再到验证，跑完这个闭环，你的 LLM 才算真正“适应了赛场”：不烫手、不掉电、不卡顿。记住教练那句话——比赛的胜利不在一公里，而在全程的配速管理。

PPW=OPSP\displaystyle \text{PPW} = \frac{\text{OPS}}{P}
PPW 越高，说明每毫安时电量产出的算力越多。它是端侧模型“能不能长期跑”的硬指标。
  1. PPW 定义性能功耗比 = 每秒操作数 ÷ 平均功耗，衡量“单位电费的算力产出”。
    PPW=OPSP\text{PPW} = \frac{\text{OPS}}{P}
  2. OPS 含义芯片每秒完成的浮点或整型运算次数，可写成“总操作数 ÷ 执行时间”。
    OPS=总操作数T\text{OPS} = \frac{\text{总操作数}}{T}
  3. 能效对比在相同 OPS 下，P 越小 PPW 越高；在相同 P 下，OPS 越大 PPW 越高。
    PPW∝1P\text{PPW} \propto \frac{1}{P}

AI 应用场景

手机端本地 AI 助手

阶段：推理部署与运行时优化

解决的问题：手机端跑 LLM 时发热烫手、电池飞速消耗，传统云侧方案没有功耗顾虑，端侧则必须精打细算。通过动态调频调压配合热管理，让模型“温顺”地跑在手机上。

具体案例：某旗舰手机内置 7B 端侧模型，连续对话 3 分钟后芯片温度到达 55°C，系统触发 DVFS 把频率降到 80%，温度稳定在 62°C 以内；单次回复延迟从 300ms 升到 380ms（用户无感），整机功耗下降约 40%，不再烫手，续航明显改善。

智能座舱车载语音助手

阶段：边缘设备部署调优

解决的问题：车内中控屏幕后方空间密闭，高温天暴晒后座舱已接近 50°C，LLM 推理容易触发硬性降频导致语音助手卡顿。需要“预判式”热管理，而非被动响应。

具体案例：工程师把热管理策略改为“预降频 + 功率预算”：车辆进入隧道或地下车库（凉爽环境）时提前降低温度基线；在高温强日照路段提前限制屏幕帧率和后台任务，保证语音助手响应时间的抖动控制在 20% 以内。

智能手表端侧健康助手

阶段：端侧推理功耗设计

解决的问题：手表电池仅 300mAh，跑一次 LLM 推理可能吃掉 2% 电量，热管理空间极小。需要把“马拉松”变成“百米赛”来规划：任务拆分、闲时执行、低功耗核调度。

具体案例：可穿戴团队将健康问答模型的推理任务拆成多个小段，利用用户抬腕间隙在低功耗小核上闲时执行，配合关闭屏幕常亮和网络预取，把单次推理能耗从 6mAh 压到 2mAh，温度始终低于 40°C。

Python 演示

python52 行
class ThermalAwareRunner:    """Simulate mobile LLM thermal-aware scheduling."""     def __init__(self, alpha=2.2, threshold=55.0, low_freq=0.4):        self.temp = 36.0        self.freq = 1.0        self.threshold = threshold        self.alpha = alpha        self.low_freq = low_freq        self.times = []        self.temps = []        self.freqs = []     def step(self, t):        if self.temp >= self.threshold:            self.freq = max(self.freq * 0.8, self.low_freq)        else:            self.freq = min(self.freq + 0.05, 1.0)        self.temp += self.alpha * self.freq - 0.6 * (self.temp - 36.0)        self.times.append(t)        self.temps.append(self.temp)        self.freqs.append(self.freq)     def run(self, steps=120):        for t in range(steps):            self.step(t)        return self.times, self.temps, self.freqs  def unmanaged(alpha=2.2, steps=120):    temp = 36.0    temps = []    for t in range(steps):        temp += alpha * 1.0 - 0.3 * (temp - 36.0)        temps.append(temp)        if temp >= 70.0:            break    return temps  def main():    manager = ThermalAwareRunner()    times, temps, freqs = manager.run()    no_temps = unmanaged()    print("managed peak temp: %.1f C" % max(temps))    print("unmanaged peak temp: %.1f C" % max(no_temps))    print("managed min freq: %.2f" % min(freqs))    print("managed avg temp: %.1f C" % (sum(temps) / len(temps)))  if __name__ == "__main__":    main()
目的：模拟一个带热管理的 LLM 推理调度器，对比“有调度”和“无管理”两种场景下的峰值温度与频率变化，验证降频抑制温升的效果。
  1. if self.temp >= self.threshold:体温越过 55°C 警戒线，就触发热管理。
  2. self.freq = max(self.freq * 0.8, self.low_freq)频率每步降到原来的 80%，但用 max 兜底不低于 0.4。
  3. self.freq = min(self.freq + 0.05, 1.0)温度安全时每步回升 0.05，缓慢恢复避免震荡。
  4. self.temp += self.alpha * self.freq - 0.6 * (self.temp - 36.0)温度变化 = 发热项 − 散热项，对应公式中的 P 和 θ。
  5. if temp >= 70.0: break无管理模型一路狂奔到 70°C 才被硬件强制刹车。
  6. times, temps, freqs = manager.run()完整跑一遍推理，记录温度与频率轨迹。
  7. print("managed peak temp: %.1f C" % max(temps))输出管理前后峰值温度对比，直观看到差异。

常见误区

误区一听到“降频”就觉得是巨大的性能牺牲，认为模型会胡言乱语、错别字变多，好像芯片被“打了半折”。

正解降频/降压只改变计算的“节奏”，不改变计算的“内容”。数字电路在额定电压和频率范围内，计算结果逐比特一致，模型输出的 token 完全相同，只是生成更慢。真正让输出变差的是量化、剪枝等模型压缩手段，那是另一回事。就像跑者减速不会改变跑姿的正确性，只是到终点更晚。

为何常见：把“性能”理解成“质量”，混淆了计算速度与模型能力两个维度。

误区手机没法装风扇，那就买外接散热器，以为把外壳温度压下去，发热问题就万事大吉。

正解散热只是“尾气处理”，热量真正的源头是功耗。如果计算调度不做优化，即使表面温度被压住，电池仍在高速放电，续航照样崩。散热设计降低的是热阻 θ，让热量更快导走，但总产热没变；只有“减负”（降频、降载）才能从源头减少产热。这就像给跑者扇扇子不如让他放慢脚步。

为何常见：手摸到的是外壳温度，容易忽略内部芯片和电池的持续产热。

误区既然降频省电，干脆把频率锁到最低，一劳永逸，反正省电第一。

正解频率过低会让任务执行时间大幅拉长，芯片长时间处于“带病坚持”状态，静态功耗和内存、屏幕等基础功耗一直在烧，总能耗可能不降反升；延迟也长到用户无法接受。所以存在最优工作点：既不热到降频，也不慢到耗电。用 EDP 的平方项理解就是——时间拖长会让综合效率急剧恶化。

为何常见：只看了“频率-瞬时功耗”的正相关，忽略了“时间-总能耗”的乘积关系。

误区热管理就应该把温度打压到三十几度，越低越安全，仿佛芯片怕冷怕热。

正解手机是被动散热，没有外部制冷资源，强压温度意味着严重牺牲性能。芯片在规格书允许的结温内（如 85°C）都算安全。热管理目标是“把温度控制在阈值内、尽量少牺牲性能”，而不是“追求最低温度”。就像跑者的目标不是把体温降到 35°C，而是别突破 38.5°C 警戒线。

为何常见：把“降温”本身当成目的，忘了降温只是保证稳定运行的手段。

面试题

Q1. 移动 LLM 推理时芯片温度急剧上升的最主要热量来源是什么？

单选题 · easy

  • A.屏幕背光发出的热量
  • B.芯片动态功耗转化的热← 正确答案
  • C.电池充电产生的热量
  • D.网络信号辐射的热量

答案：B。芯片发热主要来自动态功耗：晶体管高频开合把电能变成热能，如同肌肉做功产生体温。屏幕背光、充电和网络辐射也会产热，但 LLM 推理时芯片动态功耗的产热量远高于其他几项，是烫手的第一元凶。

Q2. 热管理触发“降频”的直接目的是什么？

单选题 · easy

  • A.让手机外观保持好看
  • B.降低功耗并遏制温升← 正确答案
  • C.提升设备的下载速度
  • D.减少系统后台任务数

答案：B。降频的直接目的就是减少芯片每秒的开关次数，从而降低动态功耗、压住温升，相当于教练让选手放慢步频以免中暑。外观、下载速度和后台任务都不是降频的目标。

Q3. 动态功耗公式中，哪个因素对功耗影响最显著？

单选题 · mid

  • A.驱动电压的平方项← 正确答案
  • B.负载电容的平方项
  • C.时钟频率的平方项
  • D.活动因子的平方项

答案：A。动态功耗 P = αCV²f，只有电压是平方项。电压从 1.0V 降到 0.8V，功耗直接变 64%；频率和电容都是一次方，活动因子也不是平方关系。所以“降压”永远是功耗优化里杠杆最大的旋钮。

Q4. 芯片频率降为原来 60% 时，同一推理任务的延迟约如何变化？

单选题 · mid

  • A.缩短为原来的三分之一
  • B.保持原来延迟完全不变
  • C.延长为原来的约 1.7 倍← 正确答案
  • D.缩短为原来的约 0.6 倍

答案：C。延迟与频率近似成反比，1 ÷ 0.6 ≈ 1.67，所以延迟约变为 1.7 倍。这是跑者配速从 4 分降到 6 分的直接代价——速度慢了，到达终点的时间必然拉长。

Q5. 以下关于 DVFS（动态电压频率调节）的说法，正确的有哪些？

多选题 · mid

  • A.可以实时调节电压和频率← 正确答案
  • B.降低电压能显著降低功耗← 正确答案
  • C.频率与功耗成一次方正比← 正确答案
  • D.调频只能整体关闭芯片电源

答案：ABC。DVFS 就是实时调节电压和频率的“配速计划”；电压平方项决定降压收益巨大；频率在公式中是一次方。调频是连续调节档位，绝不是“整体关闭电源”这种粗暴手段。

Q6. 电压从 1.0V 降到 0.75V、频率从 1.8GHz 降到 1.2GHz 时，动态功耗约为原来的多少？

单选题 · hard

  • A.约等于原来的四分之一
  • B.约等于原来的八分之三← 正确答案
  • C.约等于原来的一半左右
  • D.约等于原来的百分之百

答案：B。动态功耗 ∝ V²f。电压比 0.75² = 0.5625，频率比 1.2/1.8 ≈ 0.667，两者相乘 ≈ 0.375 = 八分之三。可见即使频率只降一点，配合降压也能带来明显收益，这就是 DVFS 的高杠杆所在。

Q7. 某任务动态功耗占 70%、静态功耗占 30%，电压降到原来的 80%、频率降到原来的 60%（静态功耗与电压近似成正比），总功耗约变为原来的多少？

单选题 · extreme

  • A.约变为原来的百分之二十五
  • B.约变为原来的百分之五十四← 正确答案
  • C.约变为原来的百分之七十五
  • D.约变为原来的百分之百左右

答案：B。动态部分：0.7 × (0.8)² × 0.6 ≈ 0.30；静态部分：0.3 × 0.8 = 0.24；合计 ≈ 0.54。这个题提醒我们：静态功耗不可忽视，它正是“频率降太多反而费电”的原因之一——因为任务时间拉长，静态项一直在烧。

Q8. 端侧 LLM 推理在哪个频率状态下通常总能耗最低？

单选题 · easy

  • A.始终最高的频率状态
  • B.始终最低的频率状态
  • C.任务相关的最优频率点← 正确答案
  • D.完全随机选取的频率

答案：C。频率太高发热触发降频，太低任务时间拉长、静态功耗拖累总能耗，所以存在最优工作点。这好比跑步配速：太快会中暑退赛，太慢则基础代谢白白消耗，只有合适配速最经济。

Q9. 以下哪些属于移动端芯片热管理的手段？

多选题 · mid

  • A.温度传感器实时监控← 正确答案
  • B.功率预算动态限制← 正确答案
  • C.被动散热材料设计← 正确答案
  • D.屏幕分辨率任意调低

答案：ABC。温度传感器是热管理的“眼睛”，功率预算限制是第二道闸门，石墨片、均温板等被动散热负责疏导热量，三者共同构成热管理机制。调节屏幕分辨率属于显示优化，与芯片热管理无直接关系。

Q10. 以下哪些调度策略能有效降低 LLM 推理的峰值功耗？

多选题 · hard

  • A.把轻任务调度到小核← 正确答案
  • B.算子融合减少访存开销← 正确答案
  • C.动态下调电压与频率← 正确答案
  • D.无限提高芯片运行频率

答案：ABC。小核调度让轻任务用“慢跑模式”，算子融合减少内存搬运的无效功，DVFS 动态降压降频——三者都从源头削减功耗。无限提高频率只会让功耗爆炸式上升并立刻触发强制降频，与目标背道而驰。