端侧推理做过一段时间之后大家基本都会撞见同一个怪现象同一个模型同一台设备刚烧录好、电也满着的时候推理速度明明很能打连续跑上几分钟延迟肉眼可见地变长跑上十几二十分钟吞吐可能直接掉到峰值的一半以下。第一反应往往是怀疑模型被人改过或者系统里有什么后台任务在抢算力可排查一圈下来CPU占用正常、内存没泄漏、网络也没抖动速度就是回不去。其实这不是程序出了问题而是设备在功耗、散热与供电这三条硬约束下主动给自己踩了刹车。这篇文章想把这个现象彻底讲透。我会沿着“功耗预算决定性能上限散热决定能撑多久供电决定能不能发挥出来”这条主线把端侧推理越跑越慢的底层逻辑拆开给你看。适合正在做手机端、开发板、边缘盒子推理部署的工程师也适合想搞懂“为什么设备用一会儿就变卡”的硬件爱好者。读完之后你至少能回答三个问题掉速的根因在哪怎么快速定位以及从模型侧、系统侧、硬件侧分别能怎么缓解。1. 先看一个熟悉的场景端侧推理为什么速度守不住如果你手里有一台带NPU的开发板或者一台旗舰手机可以自己复现一遍跑一个连续目标检测或者大模型生成的任务每轮记录延迟和帧率。我拿到过的绝大多数设备画出来的曲线都不是平的而是前半段平缓、后半段下滑最后稳定在一个明显低于初值的位置。这个形态不是个例而是端侧推理的常态。1.1 从标称性能到持续性能芯片厂商标注的算力比如几十TOPS、上百TOPS本质上是一个“峰值性能”代表的是在理想供电、理想散热的实验室条件下算力单元能短时间顶到的极限。但在真实设备里这个极限是守不住的因为芯片一旦开始高负载计算功耗立刻上去热量在狭小的机身里迅速堆积。工程上经常用两个词区分这件事峰值性能peak performance和持续性能sustained performance。端侧推理给你最直观的感觉——越跑越慢其实就是从峰值性能往持续性能滑落的过程。滑落多快、最终停在哪个位置取决于整机的热设计能力而不取决于芯片型号本身有多强。我习惯把这种行为理解成“性能预算曲线”。设备读到的不是单一性能数字而是一条随时间变化的能力包络线。前面跑得快是系统允许你透支后面稳住的速度才是这台设备在这个工况下真正能长期提供的能力。1.2 端侧推理特有的压力特征云端的推理压力其实相对友好服务器有大功率电源、机房空调、暴力风扇芯片可以长时间贴着功耗墙跑。端侧就不一样了手机也好开发板也好都要在非常紧的功耗预算内工作。手机类设备整机持续功耗往往控制在个位数到十几瓦开发板稍好一些但十几瓦到二十几瓦也已经逼近极限。更麻烦的是端侧推理的任务特性。视频流检测、大模型对话、连续语音识别这些实际应用都不是“算一下歇一下”的偶发负载而是长时间高负载的持续计算。NPU/GPU全速运行把设备内部的功耗密度一下子拉满。这种“低压高密”的工作模式对散热和供电的考验是全面性的也是端侧推理比一般的轻度应用更容易触发掉速的原因。还有一个容易被忽略的点端侧推理往往是 NPU、CPU、内存三者同时高负载。比如现在端侧大语言模型推理光在内存里反复搬运权重就占据大量带宽CPU还要负责前后处理和调度NPU本身又要做矩阵乘加。多个发热源挤在一个板级空间里热量叠加得非常快。1.3 三个约束变量其实是同一条链条说到这可以把整个逻辑串起来了。端侧推理越跑越慢不是某一个环节决定而是功耗、散热、供电三个变量互相锁定。功耗是源头芯片要高速计算就必须消耗功率功耗越高发热越大散热决定热量能不能及时排走排不走就变成结温升高芯片只能降频自保供电决定芯片能不能拿到足够多、足够稳的能量供不上或者供不稳系统同样会降级运行。任何一个环节出现短板性能都会被拉回来。所以后面三节我会分别拆功耗、散热、供电这三根链条并在最后一节给出诊断和应对的具体做法。2. 功耗预算性能的天花板是“瓦特”而不是“TOPS”讨论端侧推理很多人第一眼只看TOPS也就是算力数字。但从工程角度看真正决定这算力能不能发挥出来的是功耗预算。芯片设计再好功耗预算不够算力就是空转。2.1 端侧芯片的功耗账本一块典型端侧推理设备功耗由几块组成算力单元NPU/GPU/CPU、内存子系统、各类控制器和射频模块等。其中算力单元和内存往往是大头。先看算力单元。拿常见的开发板或者手机SoC来说NPU在大规模矩阵运算时功耗可能占到整机功耗的三到五成CPU多核全开时候也不遑多让。简单估算一下一块提供几十TOPS算力的主流端侧SoCNPU满负荷跑起来功耗经常到五瓦、八瓦甚至更高再加上CPU和内存整板高负载功耗到十五瓦以上非常常见。对手机这种电池供电的设备来说这个功率已经非常“烫手”了。再内存子系统这里很多人会有一个误区。比如家用场景里大家讨论DDR5内存功耗常常觉得它的工作电压从DDR4的1.2V降到1.1V肯定更省电。实际不是这样DDR5的工作电压确实降了但频率和带宽大幅提升之后内存模组整体功耗并不低而且对电源纹波更敏感。用在端侧开发板上的LPDDR系列同理——电压低并不等于总功耗低更不等于你可以忽略它在整机功耗预算里的位置。所以做功耗预算的时候不要只看芯片TDP或者内存单颗粒功耗一定要把算力负载、内存带宽占用、外设功耗全部叠加估算并留出至少20%-30%的余量。提示端侧设备的标称功耗和实际持续功耗可能差很多。文档里写的是典型场景平均功耗而AI推理往往是持续满载场景要用满载功耗做热设计和电源设计否则掉速是必然的。2.2 DVFS性能是“发”出来的不是“拉”出来的为什么功耗不够就直接影响速度因为现代芯片几乎都用了DVFS也就是动态电压频率调节。系统有一个电源管理单元它会根据芯片当前的功耗、电流、温度等状态动态决定芯片运行在哪个电压和频率点。这个机制很像一个“额度管理员”。你在系统里看到的“频率”不是绝对的而是管理员根据当前功耗余量“发放”的。频率越高动态功耗越高频率和功耗大致呈线性关系电压和功耗大致是平方关系芯片发热之余还考验供电能力。如果整机功耗预算已经接近上限管控单元就会逐级下调频率把芯片限制在一个功耗更低的状态。对连续推理来说DVFS有几个直接影响第一推理延迟不是“固定值”而是随每轮频率波动。你看到的第一次调用快是因为芯片刚开始跑在最高档跑久了频率被逐档压低延迟自然变大。第二频率降档是分级的。芯片通常有十几个频率档位管理单元一次未必会直接砍一大截而是每次下调一档隔一段时间温度继续逼近阈值再降一档。所以你会感觉速度是“慢慢变慢”的而不是陡然卡住。第三DVFS的决策还会参考供电能力。如果检测到输入电压跌落厉害也就是供电跟不上哪怕温度不高系统也会提前锁频。这一点第4节会详细讲。2.3 功耗互锁后的实际表现再深入一点功耗和性能之间还有一个动态耦合过程工程上常称为“功耗性能互锁”。简单解释就是性能提升→功耗增加→发热增加→温度升高→性能被限制→功耗略降→温度回落→性能又小幅恢复。如此循环形成一段周期性的“锯齿”性能曲线。我用一些典型的端侧设备测过假设前两分钟能跑到初始帧率的100%五分钟时往往已经掉到80%左右到十分钟左右稳定在60%到80%之间具体停在哪取决于设备散热和供电余量。主动散热的设备能稳住更高的点位被动散热的设备则会更靠下。需要说明的是以上是常见现象的区间描述不同设备差异很大。但它给了一个重要启示评测一个端侧推理方案不能只看第一秒的延迟和第一分钟的平均帧率必须看“持续稳定性能”不然上线后一定会被用户反馈“越用越卡”。3. 散热热如何一步一步把性能吃回去功耗说完第二根链条是散热。功耗产生之后热量如果在设备内部堆积会直接抬升芯片结温而结温是触发降频的核心信号。可以说散热设计的好坏直接决定“越跑越慢”这条曲线的斜率。3.1 从芯片结温到设备表面一条完整的传热路径要理解散热怎么影响性能得先看热量的行走路径。芯片内部的发热点最高温度叫结温Tj热量穿过封装材料和导热材料到达外壳外壳温度记为Tc再往外是环境空气温度记为Ta。热量传递遵循热阻模型大致可以写成 Tj Ta 功耗 × 总热阻。这个公式看起来简单但信息量很大。如果环境温度不变、功耗不变降低总热阻——比如用更好的导热垫、更大的散热片、加风扇——就能直接压低结温。反过来如果热阻固定环境温度升高结温也会线性抬高。夏天设备比冬天更容易降频就是这个原因。散热路径上每一环都很关键。芯片封装内的热阻到散热器和芯片中间的界面热阻再到散热器向空气辐射对流的换热热阻任何一环拉了胯热量就会堵在中间。实际项目中我见过很多因为导热垫没压实、散热器接触面不平、风道被遮挡而整体性能掉一截的板子它们并不是芯片选的差纯粹是热量没送出去。3.2 热节流是分级的不是“一刀切”很多人以为芯片降频是温度到某个阈值就关门其实不是。现代SoC的热管理非常精细芯片里会有多个温度传感器分布在CPU、GPU、NPU、内存控制器附近。系统并不傻等一个全局温度报警而是持续监测每个局部热点。以我在开发板上看到的策略为例温度低于一个安全值时频率可以自由浮动超过第一个阈值先锁最高频率不再允许进入最高档继续走高开始逐档下压并且优先压CPU还是优先压NPU有不同策略逼近绝对上限则可能直接做任务暂停或调度节流。这里有个很实用的经验轻微掉速时往往是“锁最高频”生效了继续掉速才是真正“降频运行”。所以用户感知的“越跑越慢”其实是多个阶段叠加的结果。锁定最高频可能只损失个位数的性能但当你跑到降频阶段性能损失就是百分之二三十甚至更大了。另一个常见的现象是“设备上盖热不热”和“掉不掉速”不一定对应。有些设备外壳做得隔热很好表面摸起来甚至不烫但内部芯片已经快顶到节流阈值了反过来有些设备用金属机身主动导热表面很烫反而说明热量有效地传出来了。所以判断散热问题不能光靠手感。3.3 环境温度与散热设计的“互相凑合”散热设计和环境条件是强耦合的。一个开发板在室温28℃的环境里能稳定跑8W的负载到了室温35℃的环境里可能连6W都稳定不住。整机散热方案基本上是按一定的环境温度上限来设计的比如消费类设备可能按35℃或40℃环温设计工业盒子可能要按50℃甚至更高。超出设计工况性能下滑是正常现象。我自己调试的一块被动散热开发板就很典型。室温下用连续目标检测场景测前五分钟延迟曲线还算平五分钟之后帧率开始周期性抖动。用热像仪一看NPU区域温度确确实实已经到了节流阈值。后来在芯片上方加了一块小型散热片并优化了风道同场景持续帧率提升了两成左右而且掉速斜率明显变缓。这块散热片值多少钱物料成本很低但带来的持续性能改善非常可观。很多端侧项目恰恰是在这一步省了不该省的钱。3.4 为什么说“散热设计是端侧性能设计的一部分”最后说一个观点在端侧推理项目里不要等设备做出来之后再去补散热而是应该提前进入性能预算的评估。规划阶段就要算清楚这个模型在目标芯片上的满载功耗是多少设备的散热能力能持续带走多少瓦环境温度范围是多少允许结温波动到多少度。这几个数字一出其实已经能预判最终持续性能了和后面实测的差别不会太大。有一个我反复使用的估算逻辑如果散热方案只能持续带走6W热量而NPU满负载需要8W才能跑到目标帧率那这个目标帧率在稳态下就永远实现不了。别指望系统会“奇迹般地顶住”——系统顶不住的时候只会降频而且会自动启动一切保护机制。把散热余量留够了性能才是可控的。4. 供电被低估的隐形瓶颈功耗是需求散热是排热那供电就是供给端。很多端侧推理项目的性能问题排查到散热就停了但往往供电才是更深一层的瓶颈。尤其当你发现“设备刚开机时性能还行用几分钟就掉速”而且“温度并不算高”的时候一定要往供电方向去想。4.1 从电池/电源到NPU供电域的完整路径端侧设备的供电链路其实相当长。以手机为例电池输出3.7V到4.4V左右经过板级PMIC电源管理集成电路和多路DC-DC转换器变成CPU、NPU、内存、IO各供电域需要的电压例如0.7V到1.0V不等的核心电压。每一个供电域都有独立的电流预算和电压监控。开发板类设备相对简单一些通常是外部电源输入再通过板级DC-DC转换给不同模块供电。但不管哪种形态供电链路的末端都是芯片内部大量的晶体管。当NPU进入一个密集计算阶段功率需求会在极短时间内快速上升这个上升速度可能达到每微秒几安的级别。对应地DC-DC转换器必须具备足够的瞬态响应能力否则输出电压就会瞬间跌落。4.2 IR drop、线损以及一次“看不见”的电压跌落供电设计里IR drop是最容易被低估的敌人。所谓IR drop就是电流I流过电阻R时产生的压降。芯片功耗越高供电路径上的电流越大即便一条铜走线电阻只有十几毫欧在几安培的大电流下也会产生几十到上百毫伏的压降。CPU/NPU核心电压本身才零点几伏几十毫伏就是几个百分点的降幅足以让电路不稳定。系统怎么应对这种不稳不会直接宕机而是更保守地选择低一档的工作电压和频率来确保右侧的电压余量足够。于是你就看到了掉速。另外一个常见问题是电源适配器或输入线的线损。一些开发板用USB口供电而USB口输出能力本来就有上限。拿大家熟悉的场景举例一个3.5英寸硬盘盒为什么必须独立供电因为3.5英寸机械硬盘启动瞬间电流就很大电机持续运转功率也很高如果只靠USB口那点电力供根本喂不饱结果就是硬盘反复掉盘、读写速度波动、甚至损坏数据。2.5英寸硬盘功率小很多USB口勉强够用但设计糟糕的USB口也可能出现供电不足。这不是“插根线”的问题而是峰值功率、电流余量和电压稳定性的问题。端侧推理设备也一样。我曾遇到一块开发板用某款电源适配器跑大模型推理性能总是不稳定换成一个输出电流余量更大的稳压电源之后问题立刻缓解。原适配器标称电压没错但电流输出能力不足高负载时输出电压被拉低板子只能降频保护。这就是供电成为隐形瓶颈的真实案例。4.3 双电源供电的正确理解再延伸一下“双电源供电”这个常见概念。很多人觉得双电源就是两根线一起插多一个电源就多点功率其实没那么简单。真正的双电源设计至少要考虑几个问题两路电源的地电势是否一致是否做了防倒灌设计负载是否做了合理的功率分配以及各路电源的开关时序如何协调。如果只是简单地把两个USB电源并在一起给设备供电轻则有一路被反充、发热重则导致系统复位。这和“硬盘盒必须独立供电”是同一个逻辑——供电设计归根结底看的是电流路径是否清晰每一路负载是否都有足够预算而不是供电接口数量。所以在端侧推理板卡上看到“支持双路供电”时不要想当然地认为性能会翻倍。真正有价值的是每一路供电都满足对应负载的峰值需求并且切换时不会造成电压塌陷。4.4 电池老化带来的“慢性掉速”还有一个容易被忽略的场景就是电池老化带来的长期性能下滑。锂电池内阻会随着使用次数增加而变大内阻变大之后在高电流输出时电池端电压跌落更明显。同一台手机新机时NPU满载能稳定跑住某档频率用了两年之后同样负载下电池电压更容易触发保护性降压于是系统会更早降频体感就是“手机变卡了”。这种情况下换一块新电池往往比任何软件优化都管用。我在实际项目里就见过一台设备明明温度不高性能却一直上不去排查到最后发现是电池健康度只剩六成。换上稳压电源直接供电之后性能立刻恢复到了设计值。这件事说明供电健康度本身就是一个需要纳入日常运维监控的指标。5. 定位问题先分清是热还是电再谈优化面对“越跑越慢”大部分人上来就调模型或者压算子这是比较低效的路径。正确做法是先做诊断弄清瓶颈到底在功耗预算、散热能力还是供电能力上。下面分享一套我在实际项目中常用的诊断流程。5.1 先收集三类数据按照性价比排序我建议优先做好以下三件事第一读系统日志。Linux开发板通常可以读取CPU和GPU的频率、温度、负载有些SoC还开放NPU的负载和频率读取接口。先把频率日志跑起来观察推理过程中频率是否在逐档下调如果下调了是跟着温度走还是跟着电压走。第二量测功耗。用可编程电子负载或者高精度功耗计给设备供电时记录整机功耗曲线。启动推理后如果功耗迅速爬升并持续顶在某个“功耗墙”上那就是功耗预算卡住了如果功耗曲线本身波谷很深可能是任务负载波动或者供电能力不足。第三拍温度和红外。热像仪能看到板上的热点区域热电偶可以贴在芯片封装表面和散热片上记录温度梯度。重点观察NPU区域的温度是否在节流阈值附近震荡还是持续走高后回落。这三类数据出来之后大部分问题都能判断归属。5.2 一张表快速定位“越跑越慢”的主因现象特征优先怀疑方向验证思路前2分钟正常之后稳定掉速散热瓶颈/热节流对比温度曲线和频率降档是否同步性能波动呈周期性锯齿功耗墙与温度反复互锁看功耗曲线是否反复触碰上限刚开机性能就不高温度却很低供电能力不足换电流余量更大的电源再测插上某些USB外设后性能骤降供电域被外设挤占断开外设对比测试电池设备越用越卡电池内阻升高检测电池健康度尝试直供电源环境温度高才掉速环温设计上限不够在不同室温下做同一场景对比这张表不能替代详细波形分析但能给排查指一个大致方向。5.3 从模型侧、系统侧、硬件侧分别下手定位到主因之后优化可以从三个层面推进。模型侧的优化思路是降低功耗峰值。量化是最便宜的手段INT8量化通常能在精度损失很小的情况下把算力单元的能耗降下来一截。此外算子融合能减少内存反复搬运直接降低内存子系统的持续功耗。对于大模型可以调整batch size避免瞬间功耗尖峰过高。系统侧的优化思路是平滑负载和调整调度策略。如果整机供电散热底子一般可以设置更保守的CPU/NPU频率上限让设备一开始就跑在更可持续的状态而不是冲高后断崖式下跌。这个思路听起来有点“反直觉”但稳态吞吐往往更好。另外合理设置DVFS调参策略、给任务绑定CPU核心、控制后台进程都能减少不需要的功耗。硬件侧的优化最直接但也最需要前置规划增加散热面积、加主动散热风扇、优化导热材料、选用更低导通电阻的电感、加宽供电走线、增强DC-DC的瞬态响应。这些改动需要在设计阶段就做后期补救成本很高。5.4 常规工作中容易踩的坑这里集中说几个真实的坑。第一个坑只看“平均功耗”不看“峰值功耗”。推理任务的特点是瞬时功耗尖峰很高平均功耗看着不大但峰值可能高出平均30%-50%。散热和供电都必须按峰值设计按平均值设计掉速是迟早的事。第二个坑把散热测试放在低温环境做。在空调房调试得好好的设备一进没有空调的现场就掉速这不是玄学散热设计的环温余量很低。测试环境必须覆盖产品最恶劣的工况。第三个坑忽视供电路径上的连接器电阻。接插件、线缆、转接板的接触电阻在大电流下会带来可观的压降而且接触电阻还常常不稳定。我做电源测试时最怕的就是劣质Type-C线和劣质转接板它们能把性能偷走一成还不留痕迹。第四个坑只看温度不看频率日志。有些时候外壳温度并不高但芯片内部局部热点已经触发节流了不读频率日志根本发现不了。调试时必须同时看“行为”和“状态”温度只是状态的一部分。6. 一次端侧推理项目的复盘与几条实践铁律最后用一个我实际经历过的验证项目做总结性复盘。这个项目需要在一块带NPU的开发板上连续跑视频结构化推理目标帧率要求不算苛刻但要求24小时不重启、性能不劣化。首次联调时帧率前两分钟达标十分钟之后掉到目标值的70%。当时第一个怀疑是模型推理代码效率问题排查了两天发现CPU、内存都正常模型也已经是量化版本。后来接上功耗计一看整机功耗稳定顶在12W左右而这个开发板被动散热设计方案只能持续带走8W出头——果然是功耗和散热顶不住了。当时的调整分两步先把系统最高CPU频率压低一档降低整机功耗峰值再在NPU区域增加一块小型散热片并调整设备摆放方式。改完之后持续帧率提升了约15%并且24小时测试性能曲线基本平稳。后面进一步优化了模型中的算子融合把内存搬运减少了一部分峰值功耗又降了一截系统余量更大了。这个案例里没有高深的理论但验证了我这几条实践铁律第一所有性能测试必须以长期稳定性能为准不能拿前两分钟的数据当宣传数据第二功耗、散热、供电三条约束必须统一规划只优化任何一条都无法根本解决问题第三测量数据永远是排查的第一步没有频率、温度、功耗的日志性能问题就只是“玄学”。端侧推理这件事本质上是一场在有限功耗、有限散热、有限供电条件下争取最大持续算力的平衡术。芯片给了你峰值能力但真正决定产品体验的是这些能力能不能在整机约束下持续释放。我自己的体会是做端侧部署时把功耗预算、散热冗余、供电余量这三件事想清楚了一大半的性能问题其实都可以在画板子之前就避免掉。希望这篇梳理能帮你少走几次弯路。