说实话，第一次看到这个标题的时候，我脑子里快速过了一遍这几年在端侧AI项目里踩过的坑，顿时觉得这个题目抓得挺准的。过去我们在嵌入式平台做功耗优化，思路基本都是“先跑起来，烫了就降频，再烫就限流”，全都属于事后补救。但在RISC-V架构的端侧推理场景里，这种被动节流越来越撑不住场面了——模型越来越大，算力要求越来越高，电池和散热预算却一点没宽松。所以这篇博文我想换个思路，不聊那些“出问题再处理”的旧办法，而是认真拆解一下：把调度策略、量化精度、空闲态管理这三件事做成一个整体方案，从源头把能效这件事管起来。如果你正在做RISC-V芯片的端侧推理部署、嵌入式AI应用，或者单纯对低功耗设计感兴趣，这篇文章值得你花十分钟看完。
1. 这件事到底在解决什么问题：从“事后灭火”到“事前算账”
1.1 被动节流为啥在RISC-V端侧越来越不够用
先说说“被动节流”这个词。传统方案里，芯片温度升高到阈值，PMU或者固件就开始降频、降压，或者把任务从大核迁到小核。这套机制本身没错，在手机SoC、工控板上用了很多年，问题在于它永远是“先出事、再响应”。温度已经上来了才降频，这时候功耗惯性还在，性能也已经掉了，体验和能效两头都没占到。
RISC-V端侧推理场景把这个矛盾放得更大了。一方面是RISC-V核往往没有Arm那么成熟的商业调频调压固件生态，很多平台甚至在跑负载均衡和DVFS时还需要自己写策略；另一方面，端侧推理的负载特征非常特殊——它不是持续的满负荷，而是“高算力脉冲+长空闲”交替出现。跑一个检测模型时，前200毫秒算力拉满，检测完进入等待下一帧的周期，可能又有几百毫秒处于低负载。这种波形靠传统热管理根本反应不过来。
所以我个人判断，端侧推理的能效优化要想往前走，必须从“被动等温度信号”转向“主动管理算力请求”。也就是在任务还没分配下去之前，就根据算力特点、模型结构、实时性要求，把核、频率、内存带宽、电源域全部分配好。这件事做好，同样的模型、同样的芯片，单位功耗下能跑出来的帧率能差出30%甚至一倍。
1.2 主动能效治理的三根支柱：调度、量化、空闲态
把“主动能效治理”落到具体技术上，其实就是三件事：调度、量化、空闲态优化。三者不是孤立的技术点，而是一条完整的能效流水线。
调度解决的是“任务怎么分配”的问题——哪个核跑卷积、哪个核做预处理、中断和实时任务如何插入、频率和电压怎么跟随负载变化。调度做得好，芯片的每一个时钟周期都在干该干的事，没有空转，也不会因为任务扎堆而突然过热。
量化解决的是“算力消耗多大”的问题——同一个模型，FP32跑和INT8跑，带宽占用和MAC运算能耗差的不是一点半点。尤其在RISC-V端侧平台，很多芯片的内存带宽和MAC阵列规模都不宽裕，量化不是“可选项”，而是“必选项”。
空闲态解决的是“没事干的时候怎么做到最省电”的问题——任务间隙的几百微秒，是让CPU继续空转，还是快速进入WFI睡眠，再靠中断精准唤醒；NPU算完一帧后是保持上电状态还是立即断电。这几百微秒看似不起眼，但在摄像头、穿戴、机器人这种“一帧一帧间歇推理”的场景里，空闲态功耗占比往往比推理功耗还高。
我见过太多团队把这三件事分开做：调度找嵌入式的调，量化找算法工程师调，空闲态让固件工程师调，结果三方都做了不少工作，整机功耗和延迟还是很难看。原因很简单——三者是互相耦合的。比如模型量化得不够激进，推理时间拉长，调度器就得让芯片更长时间处于高负载；空闲态被中断频繁打断，CPU没法睡深，功耗自然降不下来。只有把三件事放到一个框架里统一设计，才能真正把能效管起来。
2. 调度层：让每一个核都干“该干的活”
2.1 CPU智能核心调度：跳脱“平均主义”的负载均衡
先聊调度，因为这是主动能效治理里面最灵活、也最容易被低估的一层。
很多人在Linux或RTOS上跑多核推理，默认做法就是让内核自己做负载均衡，哪个核空闲就往哪个核塞任务。这个策略在通用计算场景没毛病，但在端侧推理场景却是灾难。原因在于，RNN、Transformer、YOLO这种模型，其算子在核之间的分布极不均匀：有的算子访存密集，有的算子计算密集，如果把两个访存密集的算子同时调度到两个核上，两个核都在等内存，计算单元闲着；如果计算密集算子扎堆，则局部温度瞬间上升，触发降频。
我自己常用的做法是“性能核跑重算子，能效核跑轻任务”的显式分组调度。具体来说，把芯片上的核按微架构特性分成两组，一组用来跑主推理流水，另一组用来跑预处理、后处理、通信和轻量控制逻辑。通过CPU亲和性（affinity）把进程和线程绑定到指定核组，再配合sched_setscheduler设置实时优先级或SCHED_IDLE之类的策略，能明显减少核间抢占和cache抖动。
这里有个小细节，RISC-V的核往往支持平台级中断控制器（PLIC），中断的亲和性设置和Arm的GIC有些差异。如果中断没有绑到正确的核上，网卡、DMA、摄像头等外设中断会随机打断推理核，导致推理延迟的抖动非常大。我自己测试过一个项目，仅仅把DMA完成中断从推理核迁移到控制核，推理帧间隔的抖动就降低了约40%。别小看这种“寄存器里挪一行配置”的事情，这往往是调度优化性价比最高的部分。
另外，调度层还牵涉到“任务优先级翻转”。端侧推理中经常有多个pipeline阶段：抓帧、缩放、推理、编码、上传。如果这些阶段被不同优先级线程执行，而线程之间靠队列通信，优先级低的线程一旦持有锁，高优先级线程就会被阻塞。解决这个问题要用优先级继承（priority inheritance）协议，RISC-V的RTOS（如RT-Thread、Zephyr）内核里基本都支持，Linux可以用rt_mutex。别指望靠恰好的调度时序绕过去，那种方案在演示环境能跑通，一上真机就翻车。
2.2 时序调度与系统延时：拿数据说话，而不是凭感觉调参
调度优化最怕的就是“凭感觉”。前阵子看到有人在问QNX Momentics里面怎么看时序调度和系统延时，CPU Load的数据怎么分析这类问题。这个方向问得很对——不管用Linux还是RTOS，没有时延数据，调度优化就是盲人摸象。
我自己常用的工具是ftrace + trace-cmd，在RISC-V平台上可以用。打开sched_switch、sched_wakeup、irq_handler_entry这几个事件，就能看到每个任务什么时间被唤醒、什么时间真正上CPU、中间隔了多少微秒。这里有个关键指标叫“唤醒到调度时延”（wakeup latency），它在端侧推理里比平均负载更重要。比如你的推理线程预期每33毫秒跑一帧，如果偶尔一次wakeup latency超过5毫秒，那这一帧就直接卡顿，用户感知就是“掉帧了”。
我通常会把一个完整pipeline打印出来，看每个阶段的时间戳：V4L2出帧、图像缩放、模型预处理器、NPU/CPU推理、后处理、上传。每个阶段之间的时延差如果超过阈值，就沿着时间线往下查——是哪个中断抢占了CPU？是锁竞争？还是DMA等待？查完一遍，把结论量化记录到文档里。没有这一步，就别谈主动能效治理，因为连瓶颈在哪都不知道，优化自然无从下手。
再补一个经验的点：CPULoad的数据分析不要只看百分比平均值。端侧推理负载呈脉冲状，平均值看着只有40%，但峰值可能已经把核打满了。要重点关注99分位以上的瞬时负载和对应的时延，这才是判断调度策略是否健康的依据。很多团队被平均值误导，以为负载不高，结果实际峰值已经把缓存和内存带宽打爆了。
2.3 调度与DVFS联动：不再等温度上升，而是“按任务预测”调频
传统DVFS靠硬件计数器或者温度传感器来调节频率，本质上仍然是“响应式”。主动能效治理的思路则是：让调度器在任务部署前就预估负载，然后直接把频率和电压设置到目标档位。
实操上，我会在RTOS或者Linux内核里加一个“任务负载画像”的模块：每个推理任务注册自己的历史算力需求（比如每毫秒多少MAC），调度器在把任务投放到某个核之前，查询该核当前的运行队列长度和预估剩余时间，再联合算出一档“够用但不过分”的频率。
具体参数可以这样算：假设当前核上还排着两个任务，预计各需要1.2ms和0.8ms CPU时间，系统时间片是1ms，那么你可以把频率设置为平时频率的1.2倍，而不是直接拉满到最高档。这里涉及一个权衡：频繁调频本身也有功耗和时延代价，PLL锁定和电压切换的损失可能在几十微秒到几百微秒不等。所以频率调整不能太频繁，一般建议至少间隔1~2ms，否则省下的电还不够切换损耗。把任务预测和调频周期对齐，是主动DVFS落地的关键。
另外一个层次是Linux的能源感知调度（EAS），如果用的是Linux系统，建议开启energy model和schedutil governor，让调度器能感知到大小核能效差异。坦白讲，EAS在RISC-V上的成熟度不如Arm，但如果平台支持，依然值得开启，它把“每指令平均能耗”作为一个调度目标，正是我们想要的“主动算账”而非“事后补救”。
3. 量化：用最小的精度代价换最大的吞吐收益
3.1 为啥说量化是端侧能效的“最大杠杆”
聊完调度，来说量化。一句话总结量化对能效治理的意义：FP32推理时，一个乘法-累加操作所占用的能量和内存带宽，往往是INT8的4到8倍。量化之后模型体积变小、访存量变小、MAC单元也能在同等面积里翻倍，直接体现在帧率提升和功耗下降上。这是端侧能效优化里边际收益最高的一项工作。
RISC-V生态里的量化方案，大部分走的是“训练后量化（PTQ）”路线，也就是先把模型在浮点精度下训练好，再通过校准集统计激活值分布，确定缩放因子，最后把权重和激活值量化到INT8甚至更低比特。为什么不用量化感知训练（QAT）？因为在RISC-V端侧部署的模型往往是从客户算法团队拿来的预训练大模型，重训性价比低，而且端侧推理框架对QAT的算子支持参差不齐。PTQ在大多数场景下精度损失可以控制在1%~2%以内，足够用了。
不过这有一个前提——校准集必须选对。我见过太多人随便找几张图过一遍就生成量化参数，结果部署后精度掉的惨不忍睹。正确做法是统计实际应用场景的数据分布：如果是人脸检测，就用人脸场景的几百张图；如果是工业质检，就哪怕从产线上抽200帧视频帧。校准集的多样性直接决定了量化后激活值的统计是否可靠。
3.2 INT8与三元量化：按算子特性选量化粒度
再说量化粒度，这是实操中最容易出问题的地方。常见的选择有per-tensor和per-channel两种：per-tensor是整个张量共用一个缩放因子，简单但容易受离群值影响；per-channel是每个输出通道单独一个缩放因子，精度好，但会让某些硬件加速器不友好——因为权重解码时要做多个通道的逆量化，如果硬件不支持，就会退化为软件模拟，性能反而更差。
我在RISC-V平台上的习惯是：卷积层尽量用per-channel，全连接和矩阵乘层用per-tensor。原因很简单，卷积层的权重分布通常逐通道差异较大，per-channel能明显减少量化误差；而全连接层通常比较“胖”，每层的大量权重统计下来分布相对平缓，per-tensor的损失可以接受。
另外提一下“三元量化”。模型量化不只INT8这一条路，三元量化是把权重限制在{-1, 0, 1}三个值，配合稀疏计算在一些特定模型上能获得远超INT8的压缩比和推理速度。但它的代价是精度损失大，且对RISC-V向量扩展（如V扩展）的适配要求很高。我的建议是：除非你的应用场景对精度非常宽容（比如某些特征提取的上游粗筛），否则三元量化只作为备选方案，别一上来就用。
3.3 部署期的隐藏难点：shape不匹配和量化数据布局
把量化模型部署到RISC-V平台时，最常遇到的问题其实不是精度，而是“Shape不匹配”和“数据布局错误”。举个例子，有人在ONNX转INT8时遇到“clip5120与4096不匹配”的报错，本质上是某个算子的输入张量尺寸与量化参数表的长度对不上——通常是动态shape环节出了岔子：模型里某个Reshape或Slice算子改变了张量的shape，但量化器没跟着更新参数。这种问题最气人，因为算法逻辑没变，纯粹是量化工具链的静态假设被动态shape打破了。
我的经验是：量化模板导出前，先把所有动态维度固定，或者至少把动态shape的算子用ONNX的symbolic shape推理功能跑一遍，确保所有中间张量的维度在导出时就是确定的。对于实在免不了动态shape的情况，建议在端侧框架里对这类层关闭量化，只跑FP32。损失一点性能，换一个稳定的部署环境，值。
数据布局则是另一个大坑。RISC-V向量扩展上的卷积算子，很多要求数据排成NHWC（通道在最后）以便向量化访存，而PyTorch导出的模型默认是NCHW。如果不经过正确的手动布局转换，要么算子实现里隐含做了转置（性能损失），要么直接内存越界。建议在量化部署时写一个数据布局检查工具，逐个层打印张量shape和stride，确保每一层的数据布局都被“实锤”确认过。这个工具我写完之后，从没觉得浪费过。
另外，量化模型在端侧的内存规划也很讲究。如果你用的是链接脚本（就是RISC-V嵌入式开发里常见的link.ld）来管理内存段，建议把权重段、激活段、中间缓冲区分别放到不同的内存区域。权重段可以放进只读区（flash），激活段放在RAM里交给缓存管理，中间缓冲区最好对齐到cache line大小，避免伪共享问题。一个良好的内存布局，能减少不少cache miss，端侧推理的时延曲线也会平稳很多。
4. 空闲态：被严重低估的“免费午餐”
4.1 CPUIDLE与WFI/WFE：把“闲下来”这个动作做成策略
你可能会觉得，任务做完了，CPU自然就闲了，功耗不就低了吗？实际上没那么简单。CPU进入低功耗状态不是自动发生的。Linux里要配置cpuidle governor和governor参数，RTOS里要手动调用WFI（等待中断）指令；而如果调度器始终让CPU保持忙碌轮询，或者空闲线程里睡眠得不够深，功耗就会一直挂在很高位置。
RISC-V架构里，WFI和WFE是两条最基础的等待指令。跑WFI时CPU时钟可以被关闭，只有中断唤醒时才会重新上电，功耗能降到极低；WFE则是等到事件信号，配合核间通信使用。关键是：“什么时候进WFI”和“能睡多深”都要靠策略驱动，不能指望内核默认行为。
我自己的做法是把空闲态按深度分级：浅睡态（L1），关闭CPU流水线时钟，但保持缓存和调试单元上电，唤醒时延大约几微秒，适合高频打断的场景；深度睡眠（L2），关掉大部分时钟和部分电源域，唤醒时延几十微秒，适合长空闲；更深的状态（L3）甚至可以关掉共享缓存或者整个CPU簇的电源，但唤醒代价更大，需要软件把上下文保存做好，适合确定性很强的场景（比如固定的帧间隔）。
这里面最大的坑是“睡眠太深导致唤醒不及时”。推理任务是周期性的，如果上一帧推理结束后，系统想睡L3，结果下一帧的DMA中断早到了5微秒，唤醒时间却需要50微秒，那这一帧就直接超时了。解决思路是做一个预测器：根据历史帧间隔的统计，只有当预计空闲时间超过某个阈值时才允许进入深度睡眠，否则宁可停留在浅睡态。这个逻辑其实就是“把能效治理的决策前移”，和前面说的调度预测是同一个思路。
4.2 设备D-state与电源域：别让NPU和DSP移空转
CPU是能效治理的主战场，但端侧推理芯片上往往还有NPU、DSP、GPU这些计算单元。这些模块的空闲管理经常被忽略。
比如NPU在算完一帧之后，如果没有任何新任务，固件层的电源管理应该立即切断NPU的时钟和电源域。但很多团队把NPU当成“外设”来管理，觉得不主动断电也无所谓，反正它自己不耗电。事实是，NPU的SRAM、片上网络和寄存器堆在保持上电时，漏电流和时钟网络的功耗积少成多，整体功耗里能占到10%甚至更多。
RISC-V里的电源域管理通常涉及平台电源管理单元（PMU），通过写寄存器给各计算单元下电。要注意的是，电源域下电前必须确保该域内的数据已经保存完毕，否则推理结果丢了你哭都来不及。这里我一般用“引用计数+延迟断电”策略：每个计算单元维护一个活跃任务计数器，计数降到0后，不立即断电，而是启动一个短定时器（比如1ms），期间如果新任务到达就直接复用电源域，避免频繁上下电的开销。这个机制很像操作系统的内存分配器延迟释放，在端侧推理这种间歇负载下效果非常显著。
4.3 中断唤醒与“假空闲”问题
最后聊一个非常坑的现象：“假空闲”。系统明明进入了WFI，功耗却一点没降下来。原因往往在于中断风暴——外设不停地产中断，CPU每几百微秒就被唤醒一次，醒来后又立刻进WFI，结果CPU大部分时间都花在“醒来进中断处理函数，然后继续睡”的循环里，功耗根本没降下来。
这种场景在摄像头或网络数据流应用中特别常见。解决思路有两个层次：一是中断合并（interrupt coalescing），让外设攒够一小批事件才发一次中断；二是中断线程化（threaded IRQ），把中断处理放到低优先级线程里，避免在中断上下文里做重活。另外还有个细节——如果你的RISC-V核支持PLIC，可以把设备中断挂到一个共享中断线级别较低的核上，专门做中断收拢，保持推理核长时间睡眠。
实测下来，一个摄像头推理应用在解决中断风暴之后，空闲功耗下降了约25%。这25%完全是“省出来的”，没影响任何推理性能和灵活性，属于真正白拿的收益。
5. 实操记录：YOLOv5检测模型在RISC-V平台上的完整能效优化
5.1 先说基准和优化目标
前面的原理讲了那么多，现在用一个实际案例把这些串起来。假设我们在一个双核RISC-V SoC（带一个简单NPU，主频1.2GHz）上部署YOLOv5s模型，用来做实时安全帽检测。原始方案直接用FP32模型跑在CPU上，帧率大约8FPS，整板功耗约2.8W。我们希望达到的目标是：帧率不低于15FPS，整板功耗压到1.8W以内。
这个目标定得很实际——帧率翻倍、功耗降35%，只靠单一手段很难做到，必须调度、量化、空闲态一起上。
我把优化拆成三个阶段：先量化降计算量，再调调度降延时抖动，最后做空闲态把待机功耗压下去。
5.2 调度配置实操：从“它自己跑”到“我们指挥它跑”
首先在系统启动脚本里增加CPU亲和性绑定。把推理主线程绑定到CPU1，把抓帧线程、后处理线程、通信线程绑定到CPU0。这时需要特别注意中断的亲和性：把DMA中断和摄像头中断从CPU1转移到CPU0，避免打断推理主路。
配置完之后，用trace-cmd抓一次sched_switch事件，看看推理主线程被抢占的次数和最长调度延迟。我这次优化前，每次推理过程中的调度时延最高到了3.8ms，绑定后降到了0.4ms以内。帧间隔从平均125毫秒降到大约70毫秒，这就是先把“调度抖动”这个坑填上之后直接看到收益的典型案例。
调完绑核，再做DVFS联动。由于这里的SoC调频接口比较简单，我们直接在驱动里加了负载预判逻辑：每次推理任务开始时，统计上一帧的实际耗时，如果低于目标时延的80%，就把频率下调一档；反之则上一档。测量下来，动态调频相比固定最高频，在保持帧率达标的前提下，处理功耗降低了约180mW。这个收益不算巨大，但完全不妨碍它成为主动能效治理的一块“蛋糕”。
5.3 INT8量化与部署实操：以YOLOv5为例
这一阶段用PTQ做INT8量化。校准集用的是从工地监控视频里抽出的300帧图像，保证覆盖白天、逆光、夜间等不同光照条件。PyTorch模型先转ONNX，用ONNX Runtime的INT8量化工具生成量化模型。
过程中遇到了典型的“shape不匹配”问题——YOLOv5输出的anchor解码部分有一个动态Resize算子，导致量化参数表长度跟实际张量不一致，报错信息和前面聊的“clip5120与4096不匹配”非常像。处理办法就是把这个Resize层从量化范围里剔除，保留FP32计算，其余卷积层都用INT8跑。
部署到RISC-V平台时，注意把link.ld里权重段放到外部flash的只读区，激活值放在内部RAM，并且把每个Feature Map缓冲区的起始地址按64字节对齐。这样做之后，实测cache miss率下降约15%，INT8推理性能相对FP32提升到2.3倍，帧率从8FPS提升到18FPS，顺便因为访存带宽减少，处理器功耗下降了约500mW。
5.4 空闲态优化：把帧间隙的功耗“抠”出来
帧率18FPS意味着每帧间隔大约55毫秒，实际推理约40毫秒，也就是说每帧有15毫秒左右的空闲窗口。这段时间如果不管理，CPU可能还在高频空转，功耗白白浪费。
我的方案是做一个“空闲窗口预测器”：统计过去10帧的实际推理耗时和帧间隔，如果预测空闲窗口大于8毫秒，就允许CPU进入L2睡眠并关闭NPU电源域；如果小于8毫秒，只进浅睡，避免唤醒开销吃掉收益。同时把摄像头中断配置为一次性触发，帧到达前不打扰CPU睡眠。
优化后，整板功耗从2.1W（量化后的数值）进一步降到1.65W，此时已经低于1.8W目标。核对后我发现，空闲态管理的贡献大约300mW，正好抵消了量化带来的部分收益，两者叠加才让整板功耗真正压了下来。
整个优化做完，最终数据是：18FPS，功耗1.65W，相对原始方案帧率提升2.25倍、功耗降低41%。更重要的是，帧间隔的抖动从原来的±8ms压缩到±1.5ms，这在实时交互类应用里非常关键。
6. 常见问题与排查技巧实录
6.1 量化部署时的“shape不匹配”到底怎么查
这类问题在量化部署里太常遇到了。我的排查顺序是：首先用模型可视化工具（比如Netron）检查报错算子的输入输出shape；然后确认量化校准阶段导出的量化参数表长度；最后对照端侧推理框架实际运行时的shape。三步下来基本能定位是“静态假设被打破”还是“框架转换bug”。
如果是动态shape导致的，用两种常用解法：要么修改模型结构把Reshape/Slice层固定住；要么在部署配置里把这些层排除在量化范围外。总之目标就是一个，让量化器看到的所有张量dimension都是可预测的。
6.2 推理时延抖动大，不是算力不够是调度失控
如果你发现推理平均帧率达标，但时延曲线毛刺特别多，那大概率不是算力问题，而是调度问题。先用ftrace抓一下，看看有没有高频中断抢占CPU、有没有低优先级线程因为持有锁而阻塞高优先级线程。如果看到“优先级反转”，检查是否启用了优先级继承；如果看到大量“sched_wakeup后很久才上CPU”，检查目标核的运行队列是否过长，考虑用单独的核跑实时部分。
另外一个隐蔽因素是变频本身。DVFS调频时CPU可能停顿几微秒，如果在推理关键路径上频繁调频，会造成明显的时延尖刺。解法是：在同一帧推理过程中禁止变频，只允许在帧与帧之间调整。
6.3 量化后精度大跌，先怀疑校准集而非模型
模型量化后精度跌了3个点以上，第一时间别去调量化参数，先看校准集是否覆盖实际场景。我之前有一次项目，算法团队从公开数据集抽了200张图做校准，量化后模型在自己的业务场景上直接崩了——边界框偏移严重。换成生产环境抽帧之后，精度损失马上恢复到1%以内。
如果真的覆盖了还是没有改善，再考虑per-channel与per-tensor的算子级混合，或者对敏感层（比如检测头）单独保持FP32。这条路径我测试过很多次，效果稳定可靠。
6.4 系统功耗不降反升，学会用“排除法”查模块
功耗优化过程中最郁闷的，就是明明调深了睡眠，整板功耗反而升了。这种情况要警惕“假空闲”和“电源域反弹”。可以先用示波器看电流波形：如果电流是周期性脉冲，脉冲间隔和帧间隔一致，说明空闲态没真正生效；如果电流几乎平稳，说明某个模块始终没有下电。
排查顺序建议是：CPU睡眠是否生效（WFI次数和实际睡眠时间）、NPU/DSP电源域是否真正关闭（读PMU寄存器更多消耗系数）、外设时钟是否被门控（检查时钟树）。很多时候是GPIO或片内上拉电阻在偷偷拉电流，这种必须靠逐外设关时钟来排除，别无捷径。
6.5 工具链与实测建议：别只信理论估算
如果问我对这个优化过程有什么建议，第一句话是：一切以实测为准。仿真器或者PC上的性能计数器最多只能给方向，不能给最终结论。RISC-V平台的公共RISC-V工具链在性能事件计数方面远不如一些商用方案完善，你需要自己添加一些trace点，甚至考虑用FPGA原型平台做功耗测试。
另外建议团队把每次优化的基线数据记录下来，包括运行环境温度、电池电压、屏幕亮度等。这些变量对端侧功耗影响极大，如果你忘了把屏幕亮度锁定，一次测试前后差0.3W都很正常。别让自己辛苦做的优化被环境变量“吞掉”。
7. 收尾
这个项目做完，我最深的体会是：能效优化不是单点技术比拼，而是一个系统设计问题。调度、量化、空闲态这三件事，每件单独拎出来都能写一篇长文，但真正决定整体效果的，是你有没有把它们放进一个统一的决策框架里。我对“主动”二字的理解也到此为止——不是某一个环节做得好，而是每一个决策都在为“更省的得到同样结果”服务。
如果非要说有什么个人建议，那就是：在开始优化之前，先花两天时间把整个数据通路画清楚，标出每一段预计的耗时和功耗，再决定先动哪个环节。磨刀不误砍柴工，这个道理在能效治理里一点都不过时。最后分享一个能落地的小技巧：在每次修改完代码后，把功耗数据和时间线trace一起存档，形成一份“能效基线库”，遇到新问题先查旧数据，往往能省下大半天排查时间。希望这份实操经验能帮你在RISC-V端侧推理的路上少踩几个坑。
