开头
最近在调试一个端侧视觉推理项目时，遇到一个让我印象深刻的现象：刚部署完模型，冷机状态下跑一次目标检测只要20多毫秒，整个板子性能表现非常亮眼。可是连续运行半小时之后再测，单次推理的耗时居然涨到了60毫秒以上，吞吐量几乎掉了一半。更诡异的是，程序没有改过一行代码，CPU占用率没有异常，内存也没有泄漏——它就是纯纯粹粹地变慢了。
这种"端侧推理越跑越慢"的问题，我相信不少做嵌入式AI、边缘计算或者手机端部署的开发者都遇到过。很多人第一反应是去查代码、查内存、查后台任务，折腾半天无功而返。但如果你把视角从软件切换到硬件物理层面，就会发现真正的元凶藏在三个关键词里：功耗、散热、供电。这三者不是独立运行的，它们像一组连锁齿轮，互相咬合、互相拖累，最终表现为推理性能的逐步衰减。
这篇文章我想完整拆解一下这个"越跑越慢"背后的物理机制——功耗墙怎么卡住芯片、热量怎么一步步扼杀频率、供电侧又怎么在关键时刻"掉链子"，最后再分享我实测过的监控方法和优化路径。不管你是正在做端侧项目部署，还是只是好奇手机跑大模型为什么会发热降频，这篇文章应该都能给你一个比较完整的答案。
1. 现场还原：从"冷机满血"到"热机半血"的完整过程
1.1 一段典型的时间-性能衰减曲线
先把现象说得更具体一点。我在一块无风扇的端侧开发板上跑一个轻量级检测模型，环境温度大约25摄氏度，板子刚上电时SoC温度在35度左右。这个状态下单次推理延时稳定在22ms，帧率能跑到45 FPS上下，性能表现让人满意。
但我让任务持续跑起来，每隔5分钟记录一次数据，得到了一条非常典型的衰减曲线：
| 运行时间 | SoC温度（约） | CPU/NPU频率状态 | 单次推理延时 | 综合吞吐量 |
|---|---|---|---|---|
| 0 min | 35°C | 满频运行 | 22 ms | 45 FPS |
| 5 min | 65°C | 满频运行 | 23 ms | 43 FPS |
| 10 min | 78°C | 开始降频 | 28 ms | 35 FPS |
| 15 min | 85°C | 明显降频 | 36 ms | 27 FPS |
| 20 min | 88°C | 深度降频 | 48 ms | 20 FPS |
| 30 min | 90°C | 接近最低频率 | 62 ms | 16 FPS |
注意看第0分钟和第30分钟的差别——推理延时翻了将近3倍，吞吐量掉了接近65%。这不只是"稍微变慢"，而是整个系统的处理能力被大幅削弱。如果你在做实时视频流处理或交互式应用，这种衰减意味着产品体验从"流畅"直接跌到"卡顿"。
1.2 为什么说这不是软件问题
遇到性能衰减，标准的排查思路是先怀疑软件层：是不是有内存泄漏？是不是后台进程抢占了CPU？是不是模型推理线程优先级被降低了？
我当时的排查过程也很常规：
- 用监控工具看内存占用，稳定在合理范围，没有持续爬升；
- 检查后台线程，除了推理主线程和必要的中枢线程外，没有额外的CPU密集任务；
- 确认推理代码路径没有变化，每次推理的任务量完全相同；
- 尝试杀掉非必要系统服务，性能衰减照旧。
软件层面全部正常，但温度监控显示了一个不能忽视的事实：芯片温度在持续上升，而CPU/GPU/NPU的核心频率同步在往下掉。这就把矛头指向了硬件物理层——是功耗与热管理机制在主动地、逐步地限制芯片性能。
这里要引入一个重要的认知：现代端侧SoC（片上系统）内部都有多层保护机制，它们会在芯片接近功耗、温度或供电极限时主动降频，目的不是让你变慢，而是防止芯片过热损坏或者系统崩溃。所以我们在软件层看到的一切"变慢"，其实都是硬件保护机制在发挥作用。弄清楚这层关系，问题就不再神秘了。
1.3 "越跑越慢"的本质：三个变量的连锁博弈
端侧推理性能衰减的完整链路是这样一个循环：
首先，推理任务是高负载持续计算，芯片功耗需求远高于日常应用；功耗需求转化为热量，在芯片内部迅速累积；芯片温度升高，逼近散热系统的极限；温度传感器触发动态电压频率调整（DVFS）策略；核心频率被一步步压低；频率降低导致推理性能下降。而性能下降后，任务执行时间变长，单位时间内的热量并没有同步减少多少，温度继续维持在较高水平，降频状态也就持续下去。
在这个循环里，功耗是起因，散热是放大器，供电则是又一个隐藏的约束条件。三个变量连在一起，形成了"越跑越慢"的完整解释。后面几节我会把它们逐一拆开来讲。
2. 功耗墙：芯片手里那张看不见的"预算卡"
2.1 先搞清楚芯片的功耗预算从哪里来
每一颗端侧SoC都有一个设计功耗上限，业界通常叫TDP（热设计功耗）或TBP（典型功耗上限）。这个数字不是随便定的，它由三方面决定：封装能承受多大热量、配套散热方案能带走多少热量、供电系统能提供多大电流。
拿常见的无风扇端侧设备举例：一块紧凑型开发板，整机功耗预算可能只有7W到15W，其中SoC分到的往往是5W到10W。相比之下，一台桌面电脑的CPU功耗预算可能是65W甚至125W，还有大型散热塔或水冷在后面兜底。端侧设备既没有风扇，也没有大面积散热鳍片，还要兼顾便携或嵌入场景的体积限制，所以功耗预算是极其吝啬的。
推理任务恰恰是那个最"贪吃"的负载。一个中等规模的卷积神经网络在GPU/NPU上跑一次推理，会同时压满：CPU核心（负责调度和数据预处理）、GPU/NPU（负责大规模并行矩阵运算）、内存控制器（负责持续高带宽的数据搬运），以及相关的缓存和总线。这意味着一瞬间的功耗需求就可能顶到芯片的峰值上限，远超它在日常轻负载下的功耗水平。
2.2 推理任务的功耗特征：持续咬满，不留喘息
要理解为什么推理任务容易触发功耗墙，得先看它的功耗波形。
手机刷网页、看视频这类日常任务，功耗是脉冲式的——突然有个渲染任务，功耗冲到峰值两三秒，然后又掉回低位。这种负载对散热和供电来说相对友好，因为热量有时间散掉，供电单元也有时间"回血"。
端侧推理则完全不同。特别像视频流检测、连续语音识别、长时间传感器数据推理这类应用，模型推理以每秒若干次的频率持续运行，每一帧的计算量都差不多，功耗曲线近乎是一条直线，始终咬在最高位附近。热量来不及消散，供电系统长期处于高负荷输出状态，芯片内部的温度会单调上升，直到接近热平衡点。
所以做端侧AI部署的人经常说：模型推理的真实功耗测试，一定要用"持续负载"方式跑，不能只测单次推理的峰值功耗。单次推理时芯片还能靠热容短暂扛住性能，看起来数据很漂亮，但长跑之后就会露馅。
2.3 内存功耗：容易被忽略的"隐形大户"
说到功耗，很多人的注意力全在SoC上，但内存（RAM）在推理任务中的耗电同样不可小觑。为什么？因为推理模型需要不断把权重、中间特征图从内存搬进搬出，内存带宽被压得很高。
近两年大家开始关注"家用DDR5内存功耗"这类话题，其实背后就是这个逻辑：内存的高频运行和持续访问会产生可观的热量和功耗。虽然单颗内存颗粒功耗不高，但在高带宽推理场景下，LPDDR5这类内存芯片也可能贡献1W到3W的功耗，对一台总预算只有10W的端侧设备来说，这已经是不可忽略的占比了。
更麻烦的是，内存芯片和SoC通常紧邻布置，内存控制器、走线、颗粒本身的热量还会互相叠加，进一步推高整个模块的温度。在一些紧凑型端侧设备上，我甚至见过内存区域温度比SoC还高的情况——这种情况下，哪怕SoC本身没到降频温度，内存持续过热也会导致系统性能波动，甚至出现频繁的内存训练降速（Dynamic Refresh Rate调整）。所以排查功耗问题时，别光盯着CPU/GPU，内存功耗和内存温度也要纳入监控范围。
2.4 功耗墙是怎么"按住"芯片不放的
当芯片功耗需求持续超过预算时，芯片内部有两种手段来限制：第一种是软件层的DVFS调频，第二种是硬件层的电流限制。
DVFS很好理解，就是动态调整核心电压和主频。功耗与电压的平方成正比、与频率成正比，降低一点电压和频率，功耗就能显著降下来。这是最常用、最平滑的功耗控制手段。
硬件电流限制则更直接。芯片内部有PMU（电源管理单元）或PMIC（电源管理集成电路），实时监测各路供电电流。如果瞬时电流超过设定阈值，哪怕只是超过几毫秒，也会触发保护动作，禁止核心继续往上冲频，或者强制拉低频率上限。这个机制对推理场景特别重要——当你每次开始跑一个新batch时，电流都会瞬间冲高，如果供电余量不足，频繁的电流尖峰就可能反复触发限制，让性能很难回到最高档。
我印象很深的一次排查：某块板子在推理启动的一瞬间，功耗表跳到了标称值1.5倍以上，但持续不到几百毫秒就回落。这种尖峰对平均功耗影响不大，却会让硬件保护机制频繁收紧。峰值功耗和持续功耗是两码事，但在限制性能这件事上，峰值功耗往往更致命。
3. 散热的连锁反应：温度升高是这样扼杀性能的
3.1 从功耗到热量：芯片为什么"烧"得这么快
如果你学过芯片功耗的基础知识，一定见过这个公式：动态功耗 = 电容 × 电压² × 频率。芯片翻转内部电路时，要对寄生电容充放电，这个过程消耗的能量最终全部变成热量。电压越高、频率越快，产生的热量就越惊人。
推理任务恰恰把电压和频率都推到了高位。GPU/NPU里的计算单元（MAC阵列）以极高速率翻转，加上SRAM缓存和数据总线的活跃，芯片单位面积内的发热密度甚至比普通CPU负载高出好几倍。你可以把它想象成一块小面积电阻通了大电流——热量在米粒大小的地方快速积累。
这个热量要排出去，必须经过一条完整的热路径：芯片内部的晶体管沟道 → 硅片基板 → 封装外壳 → 导热材料（硅脂/石墨片）→ 散热片或外壳 → 外部空气。每一层都有热阻，热阻越小、导热越快。端侧设备受成本和体积限制，散热设计往往捉襟见肘——没有风扇，散热片面积也小，有些甚至靠外壳本身被动散热。
3.2 温度传感器与降频触发：从"全速"到"刹车"的那一秒
芯片内部密密麻麻分布着温度传感器，有的在CPU核心旁边，有的在GPU附近。这些传感器实时上报温度给电源管理控制器，控制器里有一套降频策略（Thermal Throttling Policy）。
这套策略通常分好几级。举个简化的例子：
| 温度区间 | 策略动作 |
|---|---|
| 低于70°C | 允许最高频率 |
| 70°C-80°C | 频率上限降为最高档的90% |
| 80°C-90°C | 频率上限降为最高档的75% |
| 90°C以上 | 深度降频，留一点维持性频率防止死机 |
每一级降频之间通常有回滞（hysteresis），避免温度在临界点上下抖动导致频率反复横跳。但也因为这种回滞设计，一旦芯片进入深度降频状态，想要恢复高性能，必须把温度降到远低于触发点的水平才行——这就解释了为什么有时候你跑完任务，板子"冷静"了，再次推理依然要等上好一阵才能恢复全速。
我在开发板上就见过这样的现象：表面温度已经摸起来只有微温了，但SoC内部依然保持着降频状态。原因就是芯片内部的热容大，外壳凉得快，核心处的热点温度还在较高位。所以说，外壳温度只能作为粗略参考，真实的降频状态要看芯片内置传感器或核心频率。
3.3 "越跑越慢"的正反馈循环是怎么形成的
有了前面的铺垫，现在可以完整还原那个循环了：
持续推理 → 高功耗 → 芯片温度上升 → 触发降频 → 核心频率降低 → 推理能力下降 → 但任务依然以固定周期持续提交 → 高负载继续维持 → 温度维持在高温平台 → 降频无法解除 → 性能继续被压制。
这个循环一旦建立，就是一个稳定的"低性能高温度"平衡态，不会自动恢复。更麻烦的是，不少推理框架在性能下降后会试图通过增加并行线程或启用更多核心来"补救"，结果反而是让功耗变得更高、温度更进一步上升，形成恶性循环。
我看过一些端侧设备的实测数据：在被动散热条件下，持续推理的稳定性能往往只有峰值性能的50%到70%。也就是说，如果你的产品要求24小时不间断推理，你实际能获得的有效算力可能只有账面上的一半。这个数据在项目规划和模型选型时一定要提前算进去。
3.4 散热方案差异：为什么同样的SoC性能可以差一倍
很多开发者都有这样的经验：同样的芯片，放进手机里和放进带小风扇的开发板上，推理性能表现天差地别。这恰恰说明了散热设计的决定性作用。
散热的核心是降低热路径的总热阻。有效的措施包括：增大散热片面积；使用高导热系数的界面材料（石墨片、相变材料、硅脂）；增加均热板或热管；如果可以接受噪音，加一个小风扇是性价比最高的方案。
我自己实测过一个对比：同一块板子，不加任何辅助散热，满载推理稳定在80°C以上，推理延时40ms；在芯片背面贴一块高质量石墨片并让外壳充分接触，温度降了约10°C，延时降到33ms；再叠加一个静音小风扇对准散热片吹，温度直接压到55°C左右，延时回到28ms附近的水平。三种方案性能差异接近45%。这就是散热对端侧推理性能最直观、最生动的证明。
4. 供电侧的"隐形极限"：电压跌落与电流预算
4.1 电从哪来：一条完整的端侧供电链路
很多人想不通：明明写着"适配器供电5V/3A"，额定功率15W，而芯片功耗才10W，怎么会供电不足？问题恰恰在于，供电能力不是只看总额，还要看每一级转换和分配环节能不能把功率及时有效地送到位。
端侧设备的供电链路大体是：电源适配器或电池 → 输入稳压/充电管理 → 系统总线上的PMIC → 多路输出电压（核心电压Vcore、内存电压、IO电压等）→ 芯片内部的各种供电域。
每一级都有各自的输出能力和响应速度。PMIC的某个降压转换器可能标称能输出3A，但当SoC瞬时需要5A电流时，这个转换器可能就会进入限流保护，输出电压随之跌落。电压跌到SoC最低工作电压以下，芯片要么出现计算错误，要么触发掉电保护重新启动，要么被内部的Fuse/EDPL机制检测到而强制降频。
4.2 瞬时功耗与电压跌落：推理场景的"致命一击"
推理任务有一类特殊的供电杀手——电流尖峰。当一批计算任务开始时，大量晶体管同时翻转，电流需求会在极短时间内（微秒级）冲到峰值。这个尖峰如果超过了供电链路的响应极限，就会导致电压出现瞬间跌落（Voltage Droop）。
电压跌落对芯片有什么影响？简单说，芯片DSP/NPU计算单元在某个时钟周期需要足够的电压才能完成逻辑翻转。电压一旦跌落到某个阈值以下，该时钟周期就可能出现延迟或者逻辑未完全翻转，导致计算结果错误。为了防止这种事发生，芯片会设置一个电压保护下限，一旦检测到电压有跌穿风险，就立即降低工作频率或工作电压——也就是降频。
我做过一个实验：同一块板子，用稳压性能好的适配器供电时，推理稳定在高频；换用内阻较大的劣质电源适配器后，同样负载下核心频率明显下降，推理延时增加约20%。而两者的标称输出电压竟然是一样的。问题不在电压的"名义值"，而在供电通路在瞬态电流冲击下的保持能力。
4.3 电池供电：为什么用电池跑推理比插电更慢
如果你在手机或带电池的开发板上做过推理测试，大概率会发现：满电状态用电池跑，性能比插着充电器要差一些；电量越低，差距越大。
这里有三个层面的原因。第一，电池本身有内阻，电流流经内阻会产生压降。放电电流越大，电池端电压被拉得越低。第二，电池在低电量时内阻会进一步增大，电压跌落更明显，系统为了保护稳定性会主动下调功耗上限。第三，很多设备在电池供电模式下会切换到更保守的电源管理策略，直接限制SoC的最高频率或最大电流。
这就引出一个很关键的实操经验：在性能测试和产品验收阶段，一定要明确供电状态。用电池跑和用适配器跑，性能基准完全不同。如果产品最终是电池供电的，就应该以电池供电下的长期稳定性能为设计基准，而不是以插电时的峰值性能为基准。
4.4 供电余量与"独立供电"思维：从硬盘盒说起
聊到这里，我想起最近大家讨论得比较多的"2.5寸和3.5寸硬盘盒，必须独立供电"这个话题。为什么大硬盘盒要强调独立供电？因为USB接口的标准供电能力（通常5V/0.9A）远不够3.5寸机械硬盘启动和持续运行的峰值需求——硬盘马达启动瞬间的电流可能高达1.5A到2A。如果强行用USB口供电，轻则掉盘，重则损伤硬盘。所以大硬盘盒必须外接独立电源，为的就是给峰值负载预留足够的余量。
这个原理放在端侧推理上是完全相通的。有些供电能力吃紧的端侧设备，推理性能上不去，原因不是芯片不行，而是供电链路在持续高负载下没有余量。甚至有些集成度高的设备，同一路电源要同时给SoC、内存和USB外设供电，推理任务一启动，外接的摄像头、屏幕、硬盘等外设全部叠加抢电，电压就更稳不住了。
我之前排查过一个奇怪问题：同样的推理程序，不接摄像头时延时30ms，接上USB摄像头后变成45ms，一开始以为是摄像头驱动占用了CPU，后来用功率计一测，发现USB摄像头的加入让系统总电流大幅上升，SoC核心电压的跌落幅度明显增大，系统自动降频了。把摄像头改到独立供电的USB Hub之后，问题立刻缓解。这就是"独立供电"思维在端侧设备上的又一次验证。
还有一些专业设备直接采用双电源供电设计——主系统和外设传感器分别由两路独立电源供电，互不干扰。这种设计不是堆料，而是从系统层面把"敏感的数字核心"和"嘈杂的外围负载"隔离开来，有效避免了外设电流波动对核心供电稳定性的冲击。如果你的产品有类似需求，这种思路很值得参考。
5. 实测与归因：如何找到性能瓶颈的真正归属
5.1 需要监控的四类关键数据
如果你正在被"端侧推理越跑越慢"折磨，先别急着改代码，先把观测数据补齐。我在实践中发现，至少需要四类数据才能准确定位问题。
第一类是芯片温度，包括SoC各个核心的实时温度，甚至内存温度，记录温度的上升曲线和峰值；第二类是核心频率，关注CPU大核、GPU/NPU的实际运行频率，对比额定最高频率，看有没有被压低；第三类是功耗，如果板子有功率计或外接功耗仪，记录整机功耗和瞬时峰值；第四类是推理性能指标，即每次推理的延时或吞吐量，最好精确到单次耗时。
把这些数据放到同一时间轴上，就能形成一张"透视表"。性能衰减伴随温度上升、频率下降，那就是散热/降频问题；性能衰减伴随电压跌落明显、频率被硬件限制，那就是供电问题；性能衰减但温度和频率都正常，就要回到软件层面排查。
5.2 三个对照实验：快速定位真凶
只看监控数据还不够，我建议做三个对照实验来锁定症结。
实验一叫固定频率对照法。在系统层面把CPU/GPU频率锁在一个中等偏低的值，跑同样的推理负载。如果锁频后性能稳定、不再衰减，说明之前的性能下降是由DVFS降频引起；如果不锁频时能跑到更高帧率但衰减严重，而锁低频后帧率虽然低一些但稳定，那基本可以确认是散热或功耗限制在起作用。
实验二叫协助降温对照法。给设备增加外部强制散热（比如一个普通风扇直吹散热片，或者把设备移到空调出风口附近），再次跑持续推理。如果增加散热后性能明显恢复，说明散热能力是目前的主要瓶颈。这个实验我每次做都有新的体会——散热改善带来的性能提升往往立竿见影。
实验三叫供电方式对照法。分别在电池供电、普通适配器供电、高品质稳压电源供电三种状态下跑同一负载，对比频率和延时差异。如果供电质量改善后性能下降不再出现，说明供电余量不足或电压跌落是主因。
5.3 一条完整的归因排查清单
结合多次实战排查，我整理了一份可以直接套用的排查清单：
- 先测冷机30秒内的峰值性能，作为基准线；
- 持续高负载运行30分钟以上，每2分钟记录一次温度、频率、功耗、推理延时；
- 画出各参数的时间曲线，确认性能衰减模式；
- 锁频实验，判断DVFS是否为主要苛扣性能的因素；
- 加散热实验，判断散热瓶颈；
- 换供电实验，判断供电瓶颈；
- 全部实验交叉对比，确认主因与次因；
- 根据主因选择优化方案。
这套流程我第一次完整跑下来，用了大约半天时间，但换来的是一个非常清晰的结论——之前纠结了好几天的问题，其实在实验数据面前一目了然。排查端侧性能问题，最忌讳的就是凭感觉猜，用数据说话才能避免在错误的方向上白费力气。
6. 稳住性能的实战优化路径
6.1 被动散热设备上的实用改造方案
假如你的产品不能加风扇，或者客户对噪音和功耗有严格限制，那散热侧的优化重点应该是降低热阻和扩大热容。
- 更换导热材料：原厂硅脂渣到不行的案例太多了，换一张高品质石墨片或铜箔，能显著降低SoC到外壳之间的热阻。石墨片要注意别搭到不相干的地线或走线，避免短路风险。
- 利用外壳散热：让SoC的导热区域尽可能大面积地接触金属外壳，必要时在接触面加导热垫。外壳是端侧设备天然的巨大散热器，很多人忽略了这一点。
- 降低环境热累积：设备和墙壁、桌面之间留出空气流通空间；如果设备在密闭柜体里，哪怕增加一个无动力通风口都能明显改善热平衡。
- 软件配合：在推理间隙插入适当的低功耗等待期，允许芯片温度回落。比如视频检测场景，可以检测画面无变化时降低推理频率。
6.2 从软件层面主动"分时降载"
持续高负载是性能衰减的直接诱因。如果业务场景允许，可以在软件层把负载"脉冲化"，给散热和供电留出喘息时间。
举个例子：一个实时检测任务如果要求每秒10帧，与其每100ms固定跑一次推理，不如在检测到场景变化时才跑推理，场景不变时只做轻量级的帧差判断。后者能大幅降低平均功耗，让芯片温度稳定在较低区间，避免触发深度降频。这样虽然峰值推理次数变少了，但有效输出性能反而更高、更稳定。
另一个思路是分批推理。把多个推理请求合并成一个批次（batch），集中算完之后休息一会儿，而不是一小份一小份地持续提交。集中式的计算功耗尖峰虽然大，但间隔期的温度回落更彻底，总体来说散热压力更小。
还有一点容易被忽略：推理框架的算子实现选择会影响功耗。同样的卷积，有的实现内存带宽占用大、功耗高，有的实现更省电。我自己对比过不同推理后端跑同一个模型的情况，功耗相差接近30%。所以性能调优时，不要只看延时，也要关注每帧的功耗指标，优先选择能效比更高的算子实现和量化方案。
6.3 模型与算法侧的"减负"思路
除了系统层面，模型本身也有优化空间。
- 量化：从FP16降到INT8，不仅模型体积缩小，推理时的内存带宽占用和计算功耗也显著降低。对端侧来说，INT8几乎是标配。
- 剪枝与蒸馏：减少模型的冗余通道或层数，在精度损失可接受的情况下，把每帧计算量降下来，芯片自然不需要跑那么高的频率。
- 动态分辨率：在不同场景下调整输入图像的分辨率，场景复杂时用高分辨率，简单场景用低分辨率。这样平均功耗会明显低于固定最高分辨率。
- 跳帧：在保证业务要求的前提下，允许偶尔跳帧，把算力集中在关键帧上。
这些策略的核心目标都是同一个：把芯片从"持续高功耗"的状态中解放出来，让温度和功耗都回到不需要触发降频的区间。
6.4 供电侧的"升级"与"余量设计"
供电优化经常被忽视，但改善空间往往非常可观。
一个很实际的操作是把电源适配器换成电流余量更大的型号。比如原来用5V/2A适配器，换成功率更大、纹波更小的5V/3A适配器，供电链路的电压跌落就会明显改善。注意适配器的质量也很重要——杂牌适配器纹波很大，即便标称电流足够，瞬态响应能力依然差，推理任务一启动电压就会掉。
如果产品是电池供电，可以考虑在电池和负载之间增加储能电容，用来对冲瞬间电流尖峰。这个做法在硬盘盒、电机驱动等领域已经非常成熟，端侧推理设备同样适用。这种"供电冗余"的设计理念，本质上是给系统增加了一个蓄水池，不让脉冲式的电流需求直接打到电池和PMIC上。
对于有条件的项目，直接采用双电源供电设计是更稳妥的选择：数字核心一路独立电源，外设和传感器另一路电源，两路相互隔离。这样既能避免外设电流波动对核心的干扰，也方便针对核心电源做更高品质的滤波和稳压。我个人在几个项目中试过这个方案，推理稳定性提升非常明显。
6.5 把"热平衡性能"写进项目指标
说了这么多，最后想提醒一个研发管理层面的问题。很多端侧项目在立项时，拿到的算力指标是SoC厂商的峰值算力，比如"8 TOPS NPU"。但真实产品在持续推理场景下能稳定维持的算力，往往只有峰值的50%到70%。如果产品经理或客户拿峰值指标做产品定义，等到原型机出来性能不达标，再回来改散热和供电设计，成本就高了。
我个人建议，从项目一开始就把"热平衡性能"作为关键指标来考核。也就是让设备在持续满载状态下运行足够长的时间，测稳定后的性能值，用这个值来做产品设计、竞品对比和验收标准。我在习惯这个做法之后，踩的坑就少了很多——因为峰值性能很好看但留不住，热平衡性能才是用户实际用到的性能。
结尾
做了这么多年端侧项目，我最大的感受是：决定端侧推理性能天花板的，往往不是芯片算力本身，而是功耗、散热和供电这三根"隐形绳索"。芯片厂商给的峰值参数是一场在理想环境里表演的短跑成绩，而你的产品需要的是一个在炎热夏天、密闭机箱里、电池快没电的情况下还能稳定输出的马拉松成绩。
最后再分享一个小技巧：测性能的时候，一定不要只测冷机数据。把设备预热到正常工作温度后再测，得到的才是真实可用性能。我后来每次做端侧推理评测，都会先满载跑20分钟以上，让温度和降频都稳定下来再记数据。这个习惯帮我避掉了不少"好看但没用"的测试结果，也希望你们能派上用场。
