★ FEATURED ARTICLE 做端侧推理的朋友应该都有同感RISC-V这几年的势头足够猛从MCU到跑Linux的AIoT SoC到处都能看到它的影子。我从x86平台的推理优化切换过来之后最大的不适应是功耗这件事变得极其敏感。x86上多烧两瓦可能无所谓端侧设备比如智能摄像头、工业传感器、便携AI盒子每一瓦都跟续航、发热、产品形态直接挂钩。早期我做能效优化方法特别土——模型跑不动就降频任务跑完就让核心睡觉发热高了就强制节流。这些手段有一个共同特点它们都是问题出现之后的被动反应。直到我把调度、量化、空闲态三件事放在一起整体设计才真正体会到什么是主动能效治理。这篇文章围绕RISC-V端侧推理展开核心是调度、量化、空闲态优化的联动方法适合正在做RISC-V边缘设备部署、手里有嵌入式Linux板子、或者做AIoT产品功耗优化的工程师参考。我会把量化模型选型、算子调度绑定、CPU idle配置到实测数据的完整过程都列出来方便直接照着调。1. 为什么端侧能效要从“被动节流”转向“主动治理”1.1 被动节流三板斧的问题我之前在智能摄像机端侧目标检测场景上踩过一轮典型的被动节流手段有三个分头看似乎都有道理组合在一起就出问题。第一是DVFS降频。温度高了就把频率从1.0GHz降到400MHz表面上是省电了但推理延迟直接翻倍。为了补偿延迟又不得不提高任务的并发度并发起来之后核心温度继续升高又触发下一轮降频形成恶性循环。这个路数在笔记本上还能接受落在端侧产品上用户感知是“画面突然变卡”体验非常差。第二是WFI等待。推理线程跑完之后调用等待指令让核心休息但调度器里还有大量tick在周期性唤醒CPU浅睡一两毫秒就被拉起来功耗不降反升。我实测过一个板子线程加入WFI之后功耗只少了不到5%因为唤醒源太多空闲时间被打得稀碎。第三是低精度算子不考虑硬件的实际支持。比如fp16在很多RISC-V核上没有半精度向量指令软件模拟出来的效率非常低跑起来反而比fp32更慢、更耗电。量化并不是越低比特就越好硬件的向量宽度、指令支持情况、内存带宽约束都必须一起看。这些被动手段本质都是在“等系统出问题再介入”没有一个环节在主动规划“任务该去哪里执行”“每个算子该多短小”“空闲窗口该睡多深”。1.2 主动治理的三维联动模型主动能效治理我习惯拆成三个正交的杠杆调度解决的是工作负载分布在哪、何时执行、并发到什么程度。量化解决的是每个算子的计算强度和访存体积。空闲态解决的是无负载时硬件有多快进入低功耗状态、唤醒延迟多大。这三个维度不能独立调。量化的粒度变了调度图的关键路径就变了调度决策直接决定CPU空闲窗口的长度idle状态的选择又反过来约束调度器的抢占时机。用一个小餐馆打比方被动节流是客人走了才关灯、人一多就手忙脚乱主动治理是排好班、提高出菜效率、闲时让师傅休息养精神接客节奏和人力分配是提前算好的。后端侧推理的能效治理也一样得先建立“负载画像”哪个算子吃算力、哪个算子吃带宽、哪个环节有等待窗口、等待窗口能容忍多深的睡眠。把这三条线串起来统一调才有意义。2. 调度层让算力资源跟推理任务精准匹配2.1 异构多核调度向量核、标量核、加速器怎么分配现代RISC-V SoC很少只有一个同构大核常见的组合是通用标量核加向量核加DSP/NPU。向量扩展一般对标量程序也能跑但跑向量算子最划算DSP/NPU则对某些固定算子友好。调度要做的第一件事就是把算子跟最合适的执行单元匹配起来。我手头一款带玄铁C906/C908这类RVV扩展核的SoC跑YOLO这类检测模型典型分配方法是Conv、Matmul、GEMM这些计算密集而且有数据并行度的算子交给向量核心LayerNorm、Softmax、Residual Add这些访存频繁、算术密度低的算子留在标量核心上。如果反过来全塞到同一个核上跑向量单元忙不过来标量单元闲着功耗浪费肉眼可见。同时要从系统层为每个核心设置CPU affinity避免线程在各核间漂移。线程漂移的代价是缓存和TLB全丢下一次访存全部重新加载。我见过一个项目多核推理不绑核结果每次线程迁移之后都会有一百多毫秒的卡顿一查cache miss率翻了三倍。绑核之后这个问题立刻消失。还有一种常见情况是DSP/NPU空闲但CPU在忙。对于固定流水线的推理框架比较管用的做法是先把帧搬运和预处理放到DSP上把CPU的时间完全留给推理主循环中断和DMA由专用核处理。整体吞吐会提高CPU的功耗尖峰也平滑很多。2.2 从链接脚本到运行时调度编译期也是调度的一部分“调度”不只有操作系统的线程调度编译器和链接器其实也在做调度。对RISC-V来说link.ld决定代码段、只读数据段、堆栈等装载位置。如果热函数所在的.text段跨了页面边界或者i-cache集合冲突严重指令预取效率会明显下降。我遇到过一个问题把中断处理函数和主循环代码放在同一个cache区域的相邻位置中断频繁时主循环性能损失接近两成。原因是中断代码把主循环的指令行从cache里挤出去了每次中断后的恢复都要重新取指令时间全耗在预取上。建议用编译器的函数段选项配合链接脚本把热函数单独安排section让关键路径对齐到cache line频繁使用的常量表放在只读段避免跟栈混用。这些看起来是静态层面的功夫实际上对运行时调度影响很大——缓存命中率一旦低了调度器看到的每个任务执行时间都有巨大抖动负载均衡就无从谈起指令级的空泡直接变成功耗浪费。2.3 嵌入式Linux和RTOS下的实时调度配置在嵌入式Linux上比较经典的做法是用内核参数把某个核隔离出来跑实时推理任务。命令行可以这样加isolcpus2 nohz_full2 rcu_nocbs2isolcpus把core2从普通调度器的平衡范围内拿掉nohz_full关闭core2上的周期性tickrcu_nocbs减少RCU回调干扰。然后把推理线程绑到core2cpu_set_t cpuset; CPU_ZERO(cpuset); CPU_SET(2, cpuset); pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), cpuset);调试阶段直接用taskset更省事taskset -c 2 ./infer_app同时把推理线程设成SCHED_FIFO实时优先级避免被普通进程抢占。这里有个坑如果用了isolcpus而且core2上只跑这个RT线程当推理线程阻塞等待数据时core2会空转因为没有其他可运行任务也不会有普通调度器来给它找事干。解决方式是把等待逻辑改成WFI指令让core2在等待时进入低功耗态这正好跟后面的空闲态优化接上。RTOS场景更直接。FreeRTOS里的IDLE任务默认就是WFI但要注意任务优先级和tick设置。推理任务如果长时间占用CPU后台任务饿死外设数据丢失优先级设低了中断响应不及时。实践上建议把采集、预处理、推理、后处理拆成独立任务用信号量同步采集任务优先级最高推理任务中间后处理最低这样帧率稳定且CPU不会满负荷跑空转。3. 量化层精度与功耗的天平怎么摆3.1 量化为什么是端侧能效第一杠杆量化就是神经网络定点化把fp32权重和激活变成int8甚至更低比特。带来的收益非常直接int8相比fp32存储带宽减少到四分之一整数乘加单元面积小、功耗低在相同向量寄存器宽度下一次能多塞4倍的数据计算密度提升。我在RISC-V向量核上做过对比规则卷积层在int8 GEMM下比fp32 GEMM等效吞吐高约2.5倍功耗低大约55%。注意这里说的量化只谈神经网络模型定点化不要跟其他领域的“量化”混在一起。端侧设备通常内存带宽比算力更稀缺量化直接砍掉访存压力省下的功耗立竿见影。量化还有一层隐性收益模型文件变小后从flash加载到DDR的时间缩短整机启动和模型热切换的时间都更短。对端侧产品来说这不仅是能效收益还是用户体验收益。3.2 PTQ实操从PyTorch到端侧int8的完整链路训练后量化PTQ是端侧最常用的路径因为它不需要重新训练模型成本低、流程短。基本流程是先搞到fp32模型准备一个覆盖真实场景的校准数据集然后用校准集跑一遍前向统计每层激活值的分布范围根据分布确定量化参数最后把模型转换和打包成端侧runtime可以跑的格式。具体到不同的部署路径RISC-V端侧我推荐这样选MCU级别用TFLite Micro的int8量化内存占用小runtime固定支持。Linux级别用ONNX Runtime加int8适合传统视觉模型和检测模型。LLM类模型用GGUF格式选Q4_K_M、Q5_K_M这类档位配合llama.cpp类runtime部署。定标细节非常关键。权重用per-channel对称量化比较稳因为不同输出通道的权重分布差异大激活由于经过ReLU之类激活函数后通常非负用per-tensor非对称量化更合理。校准数据至少准备200到1000张太少统计不准太多耗时也长。我用KL散度校准法比较多它对激活分布尾部的处理比min/max更稳不容易被个别极端值带偏。有个坑必须提醒量化时如果只是简单地把权重的min/max映射到-128到127经常会把精度干崩。正确的做法是先做BN折叠把batch norm参数吸收进卷积层再统计激活范围这样量化误差能明显变小。我在一个检测模型上做过对比做了BN折叠再量化mAP只掉了0.02直接硬量化掉了0.1还多。3.3 量化档位选择与实测数据开源社区里GGUF量化档的排布已经相对成熟我按经验整理成表格档位特点相对速度内存占用Q8_0精度接近无损但仍偏重略慢较大Q6_K质量与速度折中偏质量中中Q5_K_M主流选择质量可接受中偏快中偏小Q4_K_M省内存优先质量能接受最快小端侧LLM部署我一般是先试Q5_K_M如果内存吃紧再降到Q4_K_M。Q8_0虽然精度最好但在带宽受限的RISC-V板子上跑不出速度优势因为访存体积摆在那里。Q4_K_M对注意力层或某些敏感层可能掉点偏多具体要看任务。实测过一个7B级别模型Q5_K_M比Q8_0快约18%内存少约20%输出质量差距在端侧场景完全可以接受。3.4 量化后的调度图要重新测绘很多做量化的同学忽略了这个量化之后算子执行时间变了任务图的关键路径也变了。fp32时瓶颈是Conv层计算量化之后Conv快了一倍多瓶颈往往变成数据搬运或者Dequantize/Quantize这类转换算子。此时调度策略必须跟着调整。我通常的做法是先用量化后的模型跑一遍全链路profiling找出新的关键路径。如果新瓶颈是数据搬运就把DMA通道优先级调高、把搬运跟计算重叠如果新瓶颈是反量化算子就把它放到向量的ALU单元上而不是标量核心上。否则量化省下的时间又被新的瓶颈吃回去了功耗虽然降了延迟却没降产品体验上不去。4. 空闲态优化零功耗需要精确到每一毫秒4.1 RISC-V平台上的低功耗状态层级绝大多数RISC-V核提供WFI指令执行之后核心进入等待中断状态但电压域没有关漏电还在。这只能算浅睡。要往深了走可以关掉时钟域进一步唤醒时重新锁相环和恢复寄存器。真正关机级别需要PMU控制供电把整个核心掉电功耗接近零但唤醒延迟会到毫秒甚至更高级别。嵌入式Linux中cpuidle框架管理这些状态。menu governor会根据预测的空闲时长选择唤醒延迟可接受的最深状态。这里有两个关键参数target residency表示进入该状态的收益点如果预测空闲时间比这个短进入深睡眠反而亏exit_latency表示退出该状态需要的唤醒时间直接影响延迟需求敏感的任务。看这两项参数的命令cat /sys/devices/system/cpu/cpuidle/state0/name cat /sys/devices/system/cpu/cpuidle/state0/latency cat /sys/devices/system/cpu/cpuidle/state0/residency有些板子的cpuidle没有正确描述深睡眠的exit_latency导致governor盲目进入深睡唤醒延迟激增。这种问题的特征是推理任务偶尔出现几十毫秒的卡顿但平均功耗没降多少。排查方法就是关掉深睡状态对比一下。4.2 推理负载的呼吸节奏与idle偏好一次典型的端侧目标检测循环是这样的视频帧到DMA内存预处理推理后处理等待下一帧如果目标是30帧间隔就是33毫秒。其中“等待下一帧”是最宝贵的空闲窗口。如果governor预测next timer event在3毫秒后它就会选择浅睡状态因为深睡的唤醒成本划不来。如果预测在30毫秒后就应该进入深睡眠把功耗降到最低。问题出在预测上嵌入式系统的timer事件来源很多网络phy、rtc、热管理、RCU都可能周期性唤醒把空闲时间切碎governor就永远选不到深睡。实操建议是先用powertop这类工具查看系统wakeup源。我调试过一台设备低负载时平均功耗2.2W降不下来用trace一抓发现大量wakeup来自hrtimer和网络phy网络接口其实不在用但phy芯片的脉冲还在不停唤醒CPU。把phy电源关掉功耗直接降了0.5W。对于已知固定间隔的端侧管线可以用pm_qos接口限制最低idle层级保证唤醒延迟不会突破约束。比如推理任务要求唤醒延迟不超过500微秒那就把power state限制在浅睡级别。这个操作会牺牲一点空闲功耗但换来回稳定性对产品体验很值。RTOS场景下FreeRTOS的IDLE任务可以执行WFI但要注意tickless模式。默认tick是1毫秒一次即使所有任务都阻塞tick也会周期性唤醒CPU。打开tickless idle模式之后系统根据最近一次定时器到期时间决定是否跳过中间tick空闲功耗明显下降。我实测一块MCU级别板子开tickless后待机电流从2.8mA降到1.1mA。4.3 空闲态与调度联动的经典坑一个非常经典的功耗bug推理任务在idle深睡眠边缘频繁被唤醒每次只睡几毫秒就起来干活然后又睡下去。看起来CPU利用率不高但因为频繁进出深睡唤醒功耗和恢复损耗全部叠加最终功耗比一直浅睡还高。这种问题被称为“thrashing”。排查思路很简单跑一帧推理打点记录空闲时间的分布再看cpuidle每层状态的进入次数。如果state2这个深睡眠层进出次数特别多但平均停留时间远低于target residency基本就是thrashing。修复方法要么调高该状态的target residency让governor更保守要么用pm_qos强制浅睡要么修改驱动的中断触发频率对齐到帧节奏。另一个坑是调度器的CPU tick。Linux默认每个CPU周期性产生tick中断即使任务很少也要醒来处理。isolcpus加nohz_full可以缓解但要注意如果core2上的RT线程阻塞等待nohz_full模式下core2会进入idle并可能睡得很深。此时从core0来的跨核唤醒信号延迟对RT任务来说可能不可接受需要评估唤醒延迟预算。5. 实操实录一块RISC-V板子的能效改造全过程5.1 硬件基线与环境准备我用的是一块带双核RISC-V加向量扩展的AIoT SoC跑嵌入式Linux 5.10内存是LPDDR4板上有NAS加速器。部署的是YOLOv5n目标检测模型输入640x640输出检测框。功耗数据用电流探针接在整板供电回路上记录。先做基线测试模型用fp32线程不绑定系统默认调度默认cpuidle。整板平均功耗2.15W端到端延迟365毫秒CPU温度开机15分钟后到75度。这块板子的向量扩展对int8支持很好但fp32的矩阵计算能力一般。所以量化收益预期很高。线程绑定前先确认内核版本和smp配置确认CONFIG_CPUSET和CONFIG_SCHED_SMT都有。环境准备特别提醒一点跑功耗测量时必须关闭屏幕背光、关闭usb外设、把调试串口波特率降低或者直接断开串口长时间连接否则串口活跃本身会拉高少量功耗。5.2 调度配置从单核单线程到多核联动的每一步第一步先量化模型到int8重新编译runtime确认推理结果可用。这一步后延迟从365毫秒降到212毫秒平均功耗从2.15W降到1.62W。第二步做核隔离和线程绑定。我加了isolcpus2 nohz_full2 rcu_nocbs2然后把推理主线程绑到core2把视频采集和DMA处理留在core0和core1。这一步延迟降到186毫秒功耗降到1.48W。性能提升主要来自线程不再迁移、缓存命中率回升。第三步设置实时优先级。把推理线程设为SCHED_FIFO优先级80后处理线程优先级50采集线程优先级60。同时关掉系统里不必要的服务这步之后延迟稳定在186毫秒不再抖动之前偶尔出现的50毫秒尖峰消失。第四步针对空闲态优化。我的管线固定等待下一帧约33毫秒间隔但实际上governor没选最深idle态因为系统还有其他timer。我用了pm_qos限制浅睡级别保证唤醒延迟再关掉无用的phy电源后平均功耗从1.48W降到1.15W。延迟轻微升到190毫秒原因是某些空闲窗口进入了较深睡眠唤醒损失了约4毫秒可以接受。5.3 量化模型的部署路径与细节量化部署用ONNX Runtime的int8动态量化加TFLite的结构化剪枝做对比。最后选了TFLite路线因为它的int8 kernel在RISC-V向量指令上优化得更好内存分配也更简单。校准集用了500张涵盖白天、夜晚、逆光的真实摄像头截图把动态范围的极端情况都覆盖到了。转换时关键参数是每个op的min/max。我在转换工具里对权重使用per-channel对称量化激活使用per-tensor非对称量化。导出后的tflite模型大约只有fp32版本的27%加载时间缩短一大截。实测mAP从0.62掉到0.60精度损失可以接受。有一个细节容易漏量化模型的后处理输出仍然可能是fp32的box坐标。如果为了省电把后处理也强行用整数计算坐标精度会丢失检测框偏移明显。所以后处理保持fp32没有问题它的计算量占比非常小不用为了量化而量化。5.4 常见问题与排查技巧实录我用一个速查表总结这段时间踩过的坑现象可能原因排查与解决路径量化后精度掉得离谱校准集不覆盖真实场景重新采集校准数据改用KL散度校准多核推理速率反而下降线程漂移、缓存抖动绑核查perf的cache miss率平均功耗怎么调都降不下来外设保持唤醒、定时器过密用powertop和trace找wakeup源偶发几十毫秒卡顿idle太深、唤醒延迟超预算用pm_qos限制idle层级单核满载但系统闲着RT优先级反转检查mutex是否设了协议继承量化和调度都调完延迟还是高新瓶颈变成数据搬运拉升DMA优先级搬运和计算重叠有一个案例值得展开说量化完成后模型mAP从0.62跌到0.53一开始怀疑是量化参数选错折腾很久才发现问题在校准集。原校准集全是从测试环境抓的干净图片没有逆光和运动模糊导致激活统计范围跟真实场景明显偏差。把校准集补齐之后mAP直接回到0.60。这告诉我们量化校准不是走过场数据质量比量化方法的差异大得多。另一个案例是偶发卡顿。我用trace抓wakeup source发现一个SPI外设在轮询模式下每帧产生几十次短中断每次打断推理主循环还阻止系统进入深睡眠。改成DMA模式并把传输节奏对齐到帧间隔后卡顿和功耗问题同时消失。还是那个原则找到真正让CPU频繁醒来的源头远比调idle参数有效。5.5 还得说一句架构级优化没有银弹调度、量化、空闲态这三个维度是我目前觉得ROI最高的切入路径但不代表只有这三件事。后端侧推理真正做深了还有算子融合、访存布局、轻量化backbone、知识蒸馏、低比特混合精度等一系列手段。我个人实际操作的体会是先把量化做了这是最稳的低垂果实然后绑核和设置优先级这一步收益直观且风险低最后才是空闲态治理因为它最容易引入偶发延迟必须对负载节奏足够熟悉之后再做。顺序反过来的话往往会在功耗和延迟两端反复纠结调试效率很低。这个方案后续很容易扩展如果产品形态允许可以在推理帧率下降时主动降低模型分辨率走通动态分辨率调度也可以把调度、量化参数暴露成运行时接口根据电池剩余电量自动切换“高性能档”“均衡档”“长续航档”。我目前正在做的就是把这三条线的参数做成配置表用一套简单脚本根据场景自动下发量产阶段调参效率能再上一个台阶。
阅读完成 · 觉得有帮助？
