从峰值算力到持续算力——端侧推理设备的功耗与热约束管理

端侧 AI 推理的规格表通常以峰值算力示人：TOPS、GHz、MFU（模型算力利用率）。但端侧设备的真实工况是"贴在用户的桌面上、塞在摄像头外壳里、锁在无风扇的塑料盒中"——散热能力以瓦计，环境温度以季节计。在这种工况下，决定用户体验的不是设备开机后第一帧的延迟，而是运行到第十分钟、第一小时之后，推理时延是否仍然稳定。

这就引出峰值算力与持续算力（sustained performance）的分野：峰值算力由电路频率与算子并行度决定，持续算力则由散热系统的稳态功耗预算决定。两者之间隔着两条物理机制——动态电压频率调节（DVFS）的时延响应，与热节流（thermal throttling）的性能衰减。本文围绕这两条机制展开：调频如何影响推理时延、节流触发后性能沿什么曲线衰减、以及持续负载下的能效应如何测量与评估。

一个值得先声明的框架：功耗与热行为是强平台属性。频率-电压表、温度阈值、衰减策略都是 SoC 厂商的私有实现数据，本文讨论的是跨平台成立的机制框架与 Linux 上的通用观测手段，涉及具体数值的表述均标注其属性（规范要求、平台实现或示例量级），不可外推。

一、约束从哪里来：三条物理边界

1.1 功耗墙：DVFS 的立方律

CMOS 动态功耗的经典近似是 P ≈ C·V²·f，频率与电压近似线性联动（更高频率需要更高电压），于是动态功耗随频率近似立方增长：频率提升 20%，功耗可能上升 70% 以上。这条立方律决定了端侧设备几乎不可能长期运行在最高频点——不是"不想"，而是功耗预算不允许。

对推理时延的直接含义是：设备的"出厂频率"往往只能在温度受限的短时间内维持；长时运行的稳态频率由散热决定，典型为峰值频点的六到八成（示例量级，随散热形态差异极大：无风扇金属外壳与主动风扇方案可差出数瓦预算）。

1.2 热墙：结温的不可逾越性

SoC 的结温（junction temperature）存在硬上限（典型为 100–125°C 区间，具体值见厂商数据手册，属实现数据）。温度传感器（RISC-V 平台常见为靠近 CPU 核与 NPU 热源的 ADC 通道，经设备树 thermal zones 描述）持续上报温度，内核 thermal 框架按预设的 trip point 分级响应：

• passive trip（被动阈值）：先降频降压，用性能换温度；
• hot trip：进一步压制频率，可能连带降外设总线频率；
• critical trip（紧急阈值）：内核关机保护，这是最后的手段而非工程选项。

热节流不是异常状态，而是散热设计内的正常稳态——问题从来不是"会不会节流"，而是节流后时延曲线是否可预期。

1.3 能效墙：每焦耳推理数的最大化

端侧设备的第三个约束是电池与能耗预算（移动/便携场景）或电费与散热噪音（固定场景）。能效比把三者统一成单一优化目标：每秒推理数 ÷ 功耗 = 每焦耳推理数（inferences per Joule）。DVFS 立方律的另一面是能效的甜点区间：频率低于某阈值时静态功耗与软件开销占比上升，频率高于某阈值时电压立方惩罚 dominates——端侧推理的最优工作点几乎从不在最高频点，而在中间的"能效甜点频点"（典型为峰值频率的 50–70%，示例量级）。

二、DVFS 与推理时延：调频比想象的更贵

2.1 调频间隙：推理时延里的"隐形停顿"

频率切换不是免费的：锁相环（PLL）重锁定、电压轨爬升（调压器压摆率限制）期间，CPU 通常需要停顿。一次调频间隙的典型量级在微秒到毫秒级（具体值取决于调压器与时钟树设计，属实现数据），看似不大，但问题在于触发频率：

推理负载天然是间歇性的——一帧到来，前处理、推理、后处理，然后空闲。若 governor 在"忙时升频、闲时降频"间振荡，每次帧处理都可能撞上调频间隙，且最坏情况恰好落在推理的临界路径上。时延抖动因此成为 DVFS 的第一副作用：平均时延可能只恶化几个百分点，但 p99 时延可能因调频间隙与推理关键段的叠加而显著膨胀。

2.2 Linux 上的落地：governor 选择与锁频

推理服务的调频策略在 Linux cpufreq 框架下落地：

bash

复制

 

 

# 查看当前 governor 与可用频点
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

# 推理服务推荐：performance governor——常驻高频，杜绝调频间隙
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# 能效优先场景：手动钉在能效甜点频点
echo 1200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 1200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

三种典型策略的取舍：

策略	平均时延	时延抖动	能效	适用场景
performance（常驻高频）	最优	最优	最差	市电供电、散热充足
schedutil（按负载调频）	中	差（调频间隙）	中	交互式混合负载
固定甜点频点	中偏优	优	最优	电池供电的持续推理

对延迟敏感型推理服务，务实的选择通常是二元的：要么 performance 常驻，要么直接钉频点——让 governor 在推理负载下自主决策，几乎必然引入可观的时延长尾。

2.3 RVV 的影响：每周期工作量决定频率需求

RISC-V Vector 扩展（RVV）改变了时延与频率的换算关系。同样的推理算子，标量实现与 RVV 实现的每周期数据吞吐可相差数倍（向量宽度 vlen 与实现相关，属平台属性）；这意味着相同时延目标下，RVV 优化良好的工作负载可以运行在显著更低的频点，功耗按立方律获益。这是"算法优化换功耗预算"的典型路径：把算子库从标量迁移到 RVV（如利用开源 RISC-V NN 库的向量化实现），往往等效于给设备白送了一截散热余量。玄铁处理器全线支持 RVV，配套的软件栈与算子库见生态板块。

三、热节流：性能衰减曲线的三个阶段

3.1 衰减曲线的形态

持续满负载下，SoC 频率与温度的时间演化呈现三阶段特征：

频率
峰值频点 ────╮
              ╲  ① 预热段：功耗满载，温度爬升
               ╲    （数秒到数分钟，取决于热容）
               ╲
稳态频点 ──────╲＿＿＿＿＿＿＿＿ ③ 稳态段：散热平衡
                ╱  ② 节流段：触发 passive trip，
               ╱     阶梯式降频直到温度回落
              ╱
温度          传感器结温沿同曲线爬升至稳态

预热段（pre-warming）：设备以峰值频点运行，结温从环境温度向稳态爬升。此段时长由热容决定——金属外壳、散热片、均热板都在为这一段"充值"。冷启动跑 benchmark 的成绩即取自此段，这也是峰值算力宣传数字的来源。

节流段（throttling transition）：结温触及 passive trip point，thermal 框架开始压制频率。多数实现的降频是阶梯式而非线性连续的（cooling device 的离散状态，实现细节），每降一级观察温度响应，可能伴随小幅回升-再降的锯齿。

稳态段（sustained equilibrium）：产热与散热平衡，频率锁定在稳态工作点。这一段的频率才是端侧推理设备的设计输入——预热段的性能只是营销数字。

3.2 Linux thermal 框架的观测

bash

复制

 

 

# 温度与 trip points
cat /sys/class/thermal/thermal_zone0/temp
cat /sys/class/thermal/thermal_zone0/trip_point_*_temp

# cooling device 的当前状态（频率压制等级）
cat /sys/class/thermal/cooling_device0/cur_state

# 频率的实时演化（配合推理负载）
cpupower monitor
# 或直接记录
while true; do
    date +%s.%N $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq) \
        >> freq-trace.log
    sleep 0.1
done

把 freq-trace.log 与推理时延记录按时间对齐，即可绘制该设备自己的衰减曲线——第三节的方法论即以此为基础。

3.3 衰减曲线对推理服务的工程含义

冷启动测量不可信：任何短时 benchmark（跑几分钟的 mlperf 类测试若未做预热）测得的是预热段性能，对长时服务不具代表性。可信的时延评估必须覆盖稳态段。

节流段是时延抖动的重灾区：降频阶梯映射为时延台阶，若推理服务恰在此段处理请求，p99 会阶段性恶化。对硬实时性要求高的场景，主动把工作点钉在稳态频点（跳过预热段的"虚假繁荣"），反而换来全时段的时延一致性——这是用平均性能换确定性的又一次实例。

稳态频点是散热设计的函数：同一 SoC 在不同外壳里的持续算力可以差出一倍。SoC 选型时只看峰值 TOPS，等于把散热设计的失误延迟到产品阶段暴露。

四、能效比评估：每焦耳推理数的测量方法

4.1 定义先行：三个层次的能效指标

指标	定义	用途
瞬时能效	1/（当前功耗 × 当前时延）	频点扫描，找甜点
稳态能效	稳态吞吐 ÷ 稳态功耗	系统级设计评估
任务能效	总推理数 ÷ 总耗能（J）	电池场景，含空闲态功耗

第三项常被忽视：间歇性推理设备（如每秒一帧的监控推理）的能耗大头可能在空闲态而非推理态——此时 cpuidle 深睡态的支持质量（RISC-V 平台取决于 SBI 的 suspend 实现深度，实现属性）比推理能效更影响续航。

4.2 功耗测量：两条路径

外部仪表法（推荐用于校准）：直流电源分析仪或功率计串联在设备供电回路，直接记录功率时间序列。精度高、平台无关，是所有内部计数器法的校准基准。缺点是设备侵入性，且难以拆分 CPU/NPU/外设的分项功耗。

内部计数器法（推荐用于日常调优）：Linux powercap 框架暴露的能量计数器：

bash

复制

 

 

# 能量计数器（若平台驱动支持）
ls /sys/class/powercap/
cat /sys/class/powercap/intel-rapl:0/energy_uj   # 示例：类比重构到具体平台

RISC-V 平台上该能力取决于 SoC 厂商是否提供能耗计数器驱动（规范层面无强制要求，属实现选项）；不支持的平台上，可用 PMU 事件近似——利用"动态功耗与指令数/周期数强相关"的特性，以 perf stat 的 instructions、cycles、stalled-cycles 事件构建功耗代理指标，再用外部仪表一次性校准代理系数。这套"事件代理 + 仪表校准"的流程是社区在缺少 RAPL 类标准接口时的通行做法。

4.3 评估流程：频点扫描 × 持续负载

一套完整的能效评估可执行流程：

bash

复制

 

 

# 1. 频点扫描：每个频点跑固定推理负载，记录吞吐与功率
for freq in 408000 600000 800000 1200000 1600000; do
    echo $freq > .../scaling_min_freq
    echo $freq > .../scaling_max_freq
    # 预热至稳态（持续运行至温度曲线平坦）
    run_inference_bench --duration 10min --log throughput-$freq.log
    # 同步记录外部功率计或能量计数器
done

# 2. 计算每个频点的 inferences/J，绘制能效曲线，定位甜点频点
# 3. 在甜点频点做长时（≥1h）验证：确认稳态温度、确认无节流台阶

两个易犯的测量错误：未预热即测（混入预热段数据，能效被高估）；功率计采样率过低（低于推理负载的占空比频率时，间歇负载的平均功率被错误平滑）。

4.4 一份示例对照（量级说明用）

工作点配置	平均时延	稳态温度	能效（相对值）
performance governor，峰值频点	1.0×	触发节流，锯齿	1.0×
钉峰值频点（锁死不节流）	—	超临界关机	—
钉稳态频点（80% 峰值）	1.25×	平稳	1.4×
钉能效甜点（60% 峰值）	1.6×	平稳，余量大	1.9×

（示例数据仅用于说明趋势：峰值频点在无风扇端侧设备上不可持续；甜点频点以约六成时延代价换取近两倍能效。具体数字随 SoC、散热形态、模型负载差异极大，不可外推为普遍规律。）

五、排查与验证清单

部署后若出现"跑着跑着变慢"，按序排查：

确认是否节流：cat /sys/class/thermal/cooling_device*/cur_state 非零即处于压制状态；配合温度日志确认触发时刻与频率台阶的对应关系。

确认 governor 未漂移：某些发行版的 tuned/thermal daemon 会回写 governor，scaling_governor 需纳入部署后的配置审计。

确认 NPU/加速器的独立热域：异构推理（CPU 预处理 + NPU 推理）平台的热源是 NPU 而非 CPU 时，CPU 侧的 governor 调优无法解除瓶颈——需检查 thermal zones 中 NPU 域的 trip 与 cooling 绑定。

确认空闲态功耗：间歇负载场景用功率计测整机待机功耗，与推理态功耗对比；若待机占比过高，优先投入 cpuidle 深睡态而非推理优化。

确认测量方法本身：外部功率计的采样率、内部计数器的校准时效（供电电压随电量漂移会改变计数器-功率映射），都是能效数据可信度的隐性前提。

六、结语：把散热当第一公民

端侧推理设备的设计逻辑可以压缩为一句话：峰值算力是营销数字，稳态频点是设计输入，能效甜点是优化目标。

三条机制的工程转译分别是：DVFS 立方律意味着 RVV 等每周期吞吐优化直接兑换功耗预算；热节流的三阶段曲线意味着一切性能评估必须以稳态段为准、冷启动数据不可外推；能效评估意味着 inferences per Joule 应取代 TOPS 成为跨方案的统一比较轴。Linux 侧的 cpufreq/thermal/powercap 框架提供了全部观测与控制接口，而 RISC-V 生态在能耗计数器等接口的标准化上仍有空间——现阶段的做法是机制框架按通用知识理解，具体频点表、trip 阈值与计数器支持逐平台向厂商文档（如玄铁开放的技术资料）核对。把散热从"最后一厘米的结构问题"提升为性能设计的第一公民，是端侧推理从 demo 走向产品的分水岭。