企业官网建设流程全解析

设备刚拿到手，跑端侧大模型速度快得飞起，每秒能吐出二十来个token，结果用了三个月、跑了上百次推理之后，同样的模型越跑越慢，延迟翻倍，帧率对半砍。很多人第一反应是“系统变卡了”，或者怀疑是推理框架有bug，甚至有人干脆重新刷机。其实问题根源根本没在软件层，而是藏在物理世界里——功耗、散热、供电这三件事，才是端侧推理性能衰减的真凶。

这篇文章不聊玄学，就直接拆开讲讲：为什么端侧推理会出现越跑越慢的现象，芯片内部在高温下干了什么，电池和供电链路又是怎么拖后腿的，以及我们能从软件侧做哪些务实的事来缓解这种情况。

1. 先看“越跑越慢”藏在哪个环节

1.1 从运行剖面看端侧推理的时间分布

端侧推理不是像一条流水线那样匀速跑完的。一次完整的推理任务，通常分成几个阶段：输入预处理、模型加载或热内存命中、计算核心执行算子、输出后处理。对端侧设备来说，真正吃功耗的是计算核心执行算子这一段，尤其是连续跑大模型或者多路并发任务的时候，时间主要耗在矩阵乘法、卷积、注意力机制这些密集计算的微内核循环里。

越跑越慢的现象，从运行剖面上看往往有两条线索：

第一条是单次推理时间本身在增加。比如最初一次推理需要80毫秒，跑了几百次任务之后逐渐拉到110毫秒、130毫秒，而且是逐步恶化，不是突然跳变。

第二条是吞吐量的下降。单位时间内能处理的帧数或请求数变少，这在视觉识别、视频分析这类持续负载场景里非常明显。

如果把这两条线索对应的功耗、芯片温度和供电电压拉出来看，就会发现一个共同规律：温度升高、频率下降、推理延迟上升，三者几乎同步发生。这说明性能衰减不是偶发状况，而是热和电联合作用的结果。

1.2 性能衰减不止是“降频”这么简单

很多人把降频理解成芯片变热之后把主频调低，然后再恢复。真实情况要复杂得多。端侧芯片内部的调频调压系统，也就是CPU/GPU/NPU的DVFS（动态电压频率调节），是按毫秒甚至微秒级做调节的。温度只是其中一个触发条件，还要看电流、功耗预算、供电电压余量、任务优先级。

所以“降频”只是表象，底下的真实逻辑是：芯片在某个工作点上，如果功耗或者温度逼近设计上限，就必须在极短时间内向下调整工作频率，甚至把多核策略从“全开”改成“部分核心运行、其余休眠”。这就导致同一个算子在冷机和热机状态下执行时间完全不同——直觉上感觉“芯片变慢了”，实际是芯片的调度策略主动退让了。

还有一个容易被忽略的点：端侧推理中的很多算子在低频率状态下会因为访存延迟占比升高而显得更慢。比如某些矩阵乘法的运算强度很高，理论上计算是瓶颈，可一旦频率降下来，单位时间能发起的访存请求变少，访存延迟又掩盖不住，计算和访存重叠的效率就直线下滑。

1.3 用一句话概括端侧“越跑越慢”的本质

端侧推理之所以越跑越慢，本质上是持续的功耗负载推高了芯片温度，芯片为了自保护开始限频限流，而供电链路在高温和重载下又出现电压跌落，进一步压缩了频率提升的空间。三者互相咬合，形成一个衰减闭环：功耗带来热量，热量压低频率，频率追不上负载之后单位任务的电流需求反而更恶化，温度继续上升。

性能衰减曲线看起来像是软件问题，实际上是一场物理博弈。

2. 功耗侧：深度学习计算为什么天生“费电”

2.1 算力与能效比的计算密度难题

我们在端侧跑推理时，经常只关注TOPS（每秒万亿次操作）这种算力指标，却很少关注达到这个算力需要消耗多少瓦。一颗宣称有10TOPS算力的芯片，如果整芯片功耗预算只有5瓦，那么真正能持续跑出的有效算力往往只有峰值的六到七成，甚至更低。

原因很简单：TOPS是峰值算力，是在理想工作电压和温度下、用特定精度和特定算子形态跑出来的。真实推理任务里，算子形状多样，数据搬运频繁，很多算力消耗在等待数据而不是计算上。而功耗呢？功耗大体上正比于频率乘以电压的平方，再乘以负载电容。只要芯片试图冲高频率，电压就得往上抬，功耗就会呈现非线性上涨。

这个非线性非常致命。频率从1.2GHz提升到1.5GHz，看起来只提了25%，但如果电压需要从0.8V提高到0.92V，功耗增长可能远超25%，接近50%。换句话说，越往峰值算力去靠，单位性能提升付出的功耗代价就越大。

端侧设备整机功耗预算就那么多，所以芯片根本不可能长期跑在最高频点上。推理引擎面对这种局面，只能选择“短时高频、长时中低频”的折中策略，而这恰恰为后续发热和衰减埋下了伏笔。

2.2 连续推理任务等于“持续峰值功耗烤机”

拿典型的视频流检测场景来说，每一帧进来都要求尽快完成推理，下一帧已经在队列里等着了。这种负载形态没有明显的空闲间隙，芯片的利用率很可能长时间保持在80%以上，功耗曲线几乎是平直的，一直顶在高位。

这不同于浏览网页或者看视频那种突发负载。日常应用的功耗峰值来得快、去得也快，芯片有大量的空闲时间散热。而连续推理是持续高功耗，等于把芯片当作一个小型加热棒连续通电。热量积累的速度远大于自然散热的速度，芯片外壳温度、内部结温都会稳步上升。

我自己在实测中遇到过这样一个场景：某开发板跑一个实时姿态识别模型，启动后前两分钟帧率可以稳定在30FPS，五分钟后开始波动，十分钟后掉到22FPS左右，二十分钟后只剩18FPS。看温度日志才知道，SoC表面温度从45℃一路爬到了78℃，且还在缓慢上涨。这就是典型的连续负载把散热余量耗尽了。

2.3 功耗管理策略应对“越跑越慢”的关键

对端侧推理来说，软件侧能做的第一件实事，就是主动管理功耗，而不是把功耗管理完全交给系统默认策略。比如在推理引擎的调度参数里，可以设置最高允许功耗预算，或者周期性检查当前温度，在温度接近阈值之前主动降低推理精度或帧率，避免被动触发深度降频。

另一个思路是调整任务的执行批次。小批次意味着单次计算时间短、功耗脉冲高但间歇大；大批次则单次计算时间长、平均功耗平稳但持续热量大。对于长时间运行的推理任务，适度使用大批次反而比小批次更容易控制住芯片温度，因为频率可以稳定在稍低的档位，减少因频繁冲高频带来的热量尖峰。

我在实际项目里试过这么一组对比：同一个目标检测模型，batch size从1调到4之后，稳定帧率降低了一些，但持续运行三十分钟后的温度比batch size=1时低了近12℃，且几乎没有性能衰减。原因就是大批次让计算单元持续满负荷工作，但频率档位不需要频繁动态拉升，功耗曲线更平滑。

3. 散热侧：热节流如何一步步吃掉性能

3.1 导热路径与芯片温度组成部分

芯片内部产生的热量，要经过封装、导热界面材料、散热片、外壳，最后才算真正散到环境里。任何一层换热效率不高，都会让热量堆在芯片内部，表现为结温升高。

很多端侧设备为了轻薄，没有主动风扇，全靠被动散热，热阻很大。这样一来，芯片内部温度对外界环境温度的变化极其敏感。夏天室外35℃和空调房25℃的对比下，同样的推理任务，芯片结温可能相差10到15℃。就这十几度，足以让DVFS系统从“高频运行”退到“中频运行”，推理延迟直接上升30%以上。

这里要引入一个概念，叫热设计功耗，也就是TDP。芯片在设计时就定好了一个参考功耗，在这个功耗以下持续运行，散热系统能把温度控制在安全范围以内。但端侧推理任务尤其是多线程或多核并行时，瞬时功耗经常超过TDP。芯片内部的温度管理单元没那么宽容，一旦检测到超过阈值，会以极短的响应周期介入，直接限制功耗和频率。

3.2 热节流机制的工作过程以及失效模式

热节流不是一次性动作，而是一个持续调节过程。芯片温度逼近trip point时，它不会直接把频率砍掉一半，而是先小幅降频，观察温度走势；如果温度还在涨，再进一步降频。这种渐进式调节看起来很合理，但对实时推理任务很不友好——因为推理时间不稳定，帧率忽高忽低，整个系统体验就变得非常“肉”。

更麻烦的是，散热侧还有一个隐性失效模式叫热循环老化。芯片在反复经历高温-低温、高功耗-低功耗的循环时，封装内部的焊接点、导热材料都会产生微小的机械应力。时间长了以后，芯片封装到PCB之间的散热路径热阻会略微变大。哪怕只是热阻增加10到20%，芯片稳定工作温度就会明显上移。这也就是为什么一台设备用久了之后，跑同样的任务感觉比新的时候更烫、更容易卡的原因之一。

我接触过一批运行一年多的设备，同样跑一个图像分类模型，推理时CPU频率比刚部署时平均低了约200MHz，测试温度却反而高出了8℃。散热路径老化是绕不过去的物理损耗。

3.3 散热的实际干预方式与温控参考点

散热干预的优先级很明确：先保证空气流道通畅，再提升导热介质效率，最后才考虑加主动散热。对普通开发者来说，最容易被忽视的是导热介质老化。很多端侧设备的SoC和散热片之间靠导热硅脂或导热垫片连接，长时间高温运行后硅脂会干裂或垫片会变硬，导致热阻变大。

如果你发现一台设备用了一段时间后，推理性能明显退化，但系统负载和电源都没问题，第一件值得做的事是重新涂抹导热硅脂或者更换导热垫片。我做过一次这样的维护，某台设备换掉干裂的导热垫片后，同样推理任务下的SoC温度直接降了10℃以上，性能基本恢复到初始状态。

另外一个温控参考点：不要把温控阈值设得太保守，也不要设得太激进。设得太保守，芯片稍微热一点就开始限频，损失性能；设得太激进，芯片长期工作在高温区间，加速散热路径老化。一般来说，端侧SoC的结温上限在85℃到105℃之间，长期稳定运行建议控制在70℃到80℃之间比较合适。实测发现，结温长期控制在75℃以下的设备，性能衰减速度远小于长期超过85℃的设备。

4. 供电侧：电源链路是性能衰减的隐形天花板

4.1 端侧供电链路的构成与损耗

端侧设备从电池或适配器取电，到芯片核心电压域真正供上电，中间要经过线缆、主板走线、电感、MOS管、电源管理芯片、电容网络，最后才到CPU/GPU/NPU核心。这条链路里面每经过一级就会有损耗，损耗的表现形式就是压降和发热。

电源管理芯片的效率通常在85%到95%之间，看起来挺高，但如果整机功耗是10瓦，那么电源链路里损失掉的就有0.5到1.5瓦。这部分能量不会凭空消失，而是变成热量，又把设备内部的温度推高一点。温度升高又让电源芯片的效率降低，进一步增加损耗——这是供电侧的热正反馈。

更关键的是动态压降，也就是transient drop。当推理任务突然从一个空闲状态切换到一个计算密集状态，电流需求会在微秒级突然拉高，比如从0.5A跳到4A。这么大的电流阶跃会导致供电电压瞬间跌落，尤其当电池老化或者线路阻抗偏大的时候，电压跌落幅度可能超过100mV。

芯片的核心电压一旦出现明显跌落，稳定性就成了问题。为了保住不出计算错误，芯片有两种选择：一是等待电压恢复再继续算，这等于白白增加延迟；二是直接降低工作频率，让电流需求降下来，稳住电压。无论哪种选择，推理都会变慢。

4.2 电池老化与放电曲线对推理性能的影响

移动端设备还有一个很特别的变量——电池。锂电池在使用过程中，内阻会逐渐变大。内阻变大后，当推理任务索取大电流时，电池本身的压降就会很严重，最终到芯片那里的电压就偏低。

这就出现一个恶性循环：芯片想高频运行->电流变大->电池内阻压降增大->芯片电压不足->频率被限制。换了一块健康的新电池后，同一台设备跑同样模型，性能提升往往立竿见影，根本原因之一就是供电能力恢复了。

从放电曲线上看，电池电量高的时候，内阻相对较低，电压平台稳定；电量低的时候，内阻升高，电压下降明显。所以很多端侧推理设备在电池电量低于20%之后，跑模型的性能会肉眼可见地变差，哪怕整机温度和之前一样。我在测评平板设备时就发现，电量从100%降到20%，同一个姿态检测模型的推理延迟增加了约25%，而功耗和散热并没有发生变化——问题就出在电池的放电能力上。

4.3 供电设计的优化与软硬件协同策略

针对供电侧的性能衰减，软硬件协同能做几件实事。

第一件是合理的电源预算规划。在推理引擎启动时，不要一股脑地为整个任务把功耗拉满，而是预留裕量。否则一旦瞬间电流叠加，电压跌落到不稳定边缘，系统会触发更严厉的降频保护，得不偿失。按整机功耗预算的80%作为推理任务的设计上限，往往比顶着100%跑更稳。

第二件是关注低频电流纹波。端侧推理任务中的算子切换会产生电流脉冲序列，这些脉冲如果在特定频率上和电源链路中的电容谐振点重合，就会形成纹波放大。表现上就是虽然平均功耗不高，但芯片的电压余量不足，稳定性下降。处理方案是在电源管理固件中增加动态负载感知，或者调整推理任务的算子发射节奏，避免在敏感频段上连续冲击。

第三件是定期校准电源管理芯片的电压调节参数。很多高端设备在出厂后，电源管理芯片的参数是固定的，但电池内阻会随着循环次数增加而变大。定期根据电池的实际健康状态调整供电参数，让电压补偿曲线跟着电池状态走，能明显改善设备在生命周期后期的推理性能稳定性。

5. 软件侧做一些务实的事情来缓解性能衰减

5.1 推理引擎的功耗-性能协同调参

既然硬件侧的物理限制无法彻底消除，软件侧能做的就是把有限的功耗和热预算花在刀刃上。推理引擎的很多参数，普通开发者其实是可以调优的。

比如算子融合。将多个相邻算子融合成一个更大的算子，可以减少中间结果的写回和读取，降低内存带宽压力，从而降低同等计算量下的功耗。这种优化对慢吞吞的端侧推理来说效果很明显，因为它削减了最耗电的数据搬运。

再比如选择合适的数值精度。很多端侧推理引擎默认跑FP16，但实际用INT8量化后的模型，在一些支持相应指令集的芯片上，功耗能降低接近一半，而精度损失控制在可接受范围内。对于长时间运行的推理服务，量化带来的发热降低，某种意义上比精度收益更有价值。

还有线程亲和性设置。把密集计算的线程绑在大核上，把调度和预处理线程放在小核上，避免线程在大小核之间频繁迁移。线程迁移不仅耗时，还会造成功耗脉冲，干扰DVFS系统的频率决策。固定亲和的线程组，实测能让温度波动幅度降低好几个百分点，性能输出的抖动也明显改善。

5.2 温控感知的推理调度策略

把温度当作调度的一个维度，而不是等系统被动降频了再去处理。我建议在推理框架中加一个“温度感知调度器”，每秒钟采样一次芯片温度，预测温度变化趋势，并提前调整后续任务的执行参数。

比如，温度处于低位时，用高帧率模式跑；温度接近阈值时，把帧率上限往下调一点，或者把并发路数减少一路，而不是等热节流强制介入。这种方式叫软降级，目的是用轻微的性能让步，换取系统性能的长期稳定，而不是让性能像过山车一样忽高忽低。

在实际项目中，用这种策略做视频结构化分析设备时，连续运行一周后推理吞吐量只下降了不到5%，对比旧方案动辄20%以上的衰减，应该说差距相当明显。核心逻辑就一句话：与其让芯片在系统保护机制下被动降频，不如提前主动规划资源。

5.3 长期运行场景下的实用建议

如果你负责的端侧设备需要7x24小时跑推理任务，这些经验你可以直接拿去用：

• 定期监控芯片结温和电池健康度，不要把温度监控日志只看成“排查问题时才用”的冷数据，定期分析温度趋势，能在性能明显劣化之前提前干预。
• 规划好推理任务的休眠策略。连续跑推理不等于每时每刻都要满负荷，每调度一个批次的推理任务之间，刻意插入几十毫秒的低功耗等待，能让芯片温度有时间回落，换取后续更高频率的执行效率。这种策略叫间歇式推理，看起来利用率降低了，实际吞吐量反而更稳。
• 对电池供电的设备，建议严格控制放电深度，尽量让电量维持在30%以上运行推理任务，避免电池内阻增大带来的供电瓶颈。

5.4 性能越跑越慢的排查路径参考

如果你现在正好遇到设备推理变慢的问题，可以按下面的顺序做一次排查：

1. 先记录当前室温与设备外壳温度。如果外壳烫手，问题大概率出在散热侧。
2. 查看芯片温度和频率日志，确认是否有热节流触发记录，哪些核心被降频了。
3. 检查电源管理日志中的电压记录，看是否有明显的瞬态电压跌落。
4. 有电池的设备，检查电池健康度和内阻数值，如果内阻异常，优先考虑更换电池。
5. 如果以上都正常，尝试用默认低频状态跑同一模型，对比推理时间差异。如果低频状态下推理时间反而更稳定，说明高频状态下的供电和散热都不健康。

这套排查顺序是针对端侧推理性能衰减的通用方法，不依赖具体平台，基本能定位出80%以上的“越跑越慢”问题。

6. 整个系统层面的思考：性能衰减是物理规律的回归

把一个端侧AI设备看成一个小型系统，功耗、散热、供电三者从来不是独立变量，而是互相耦合的。功耗决定发热，发热决定温度和散热需求，温度反馈到功耗管理策略，供电电压又决定芯片能否稳定高频运行。这三者组成的循环，在长时间运行中总会找到一个新的平衡点，而这个平衡点的位置决定了设备的持续推理性能。

“越跑越慢”不是软件或者某个单一硬件的bug，而是这个系统在长时间重载之后重新寻找平衡的结果。理解了这一点，你会明白为什么只靠换一个推理框架或者调几个参数收效有限，因为你在软件层做的事情再多，也绕不开芯片温度和供电电压的物理边界。

反过来说，如果你能站在系统的高度去管理功耗、干预散热、稳定供电，你会突然发现，端侧推理性能其实比很多人想象的更有韧性。我经历过的最直观的例子，就是同一款设备，一组只关注算法部署，另一组做了完整的功耗温控调度和供电参数校准，运行半年后前者的推理延迟已经涨了40%，而后者只涨了不到8%。差距不是算法拉开的，而是系统物理层管理拉开的。

6.1 把性能管理当成长期的系统性工作

很多人把性能优化当成一个一次性工程，调完参数就完事了。但端侧推理的真实情况是，性能是时间的函数——第一天跑得好不代表三个月后跑得好，冬天跑得好不代表夏天跑得好。设备散热路径会老化，电池内阻会增大，外壳积灰会影响散热，这些因素全部会随时间变化。

比较合理的做法是把性能管理当成一个持续性的维护任务：

• 建立温度基线档案，记录新设备在不同负载下的正常温度曲线；
• 定期对比当前温度数据和基线数据，偏差超过阈值就排查散热或供电；
• 根据季节调整功耗策略，夏天适当降低推理帧率上限，给散热留足余量；
• 让推理引擎加入自校准逻辑，根据当前温度和历史性能数据动态调整执行参数。

这一套做下来，不需要昂贵硬件，也不需要改算法模型，就能让设备在整个生命周期内维持比较稳定的推理性能。

6.2 结尾想说的

功耗、散热与供电，这三个词听起来很像硬件工程师的领域，但做端侧AI部署的人如果只盯着算子优化和模型压缩，迟早会被物理规律上一课。我第一次踩到“越跑越慢”这个坑的时候，以为推理框架有bug，花了两天检查算子实现，最后才发现芯片结温已经接近90℃，DVFS早就把频率锁低了。从那以后我养成了习惯，凡是跑端侧推理任务的设备，第一步一定先建立功耗和温度监控，再看算法和框架。

如果你正在做端侧推理相关的项目，建议现在就打开设备的温度日志，跑一段持续负载，看看你的芯片是如何一步步降频的。亲眼见到那条温度上升曲线和性能下降曲线同步变化之后，你对端侧AI的理解会有一个实质性的升级。这篇文章如果能帮你少走一点弯路，我也算没白写。