跑端侧AI的人大概率都碰到过这样一个怪现象模型没换、代码没动、开发板还是同一块刚开机的时候token刷刷往外蹦跑个十来二十分钟速度肉眼可见地往下掉等电量再低一些整个推理延迟能翻倍。我见过不少团队把这个现象当成软件bug去排查查内存泄漏、查缓存策略、查算子实现忙活半天一无所获。真相不在代码层在物理层——端侧推理消耗的是电池里的电电变成热热又反过来压制芯片的频率供电、功耗、散热三样东西串在一起才造成“越跑越慢”。这篇文章不讲模型优化只讲端侧算力背后这三条物理锁链是怎么一环扣一环的。1. 越跑越慢不是错觉先说清楚端侧算力的物理边界1.1 云侧和端侧最大的差别不在算力在“能量环境”大家习惯把端侧推理和云侧推理放在一起比性能比来比去总觉得端侧吃亏在算力弱。其实更本质的差异是能量环境完全不同。云端GPU服务器插着几千瓦的电源房间里空调常年18度机柜里风扇把热量源源不断带走。负载高了大不了多开几个实例单卡跑到降频直接换一台。端侧设备呢一块电池几百克重量没有主动散热外壳还不能烫手。拿手机来说整机持续功耗能做到4到8瓦就已经不错了开发板稍微宽松一些通常也就是10到15瓦的量级。这个能量输入上限就是墙。很多人忽略的是AI推理恰恰是所有负载里最不省油的那一类。网页浏览、视频播放都有明显的空闲窗口GPU/CPU可以间歇性歇口气。但端侧跑大语言模型是自回归生成逐token往前推每一秒都在持续大功率输出大核高负载、NPU/GPU满频连续几分钟、十几分钟不停工。这种负载形态对功耗预算和散热系统的压力比跑游戏还要极端。所以端侧推理越来越慢不是偶发故障是物理环境决定的必然走向差别只在于降频的时间点来得早还是晚。1.2 先给“慢”一个准确定义排错之前得先把现象定义清楚。这里的越跑越慢指的是同一台设备、同一个模型、同一个输入和batch配置推理吞吐量token/s随运行时间持续下降或者随电量下降且重启后冷机状态下性能能够恢复。注意两个关键词——同配置、可恢复。如果重启后依然慢那大概率是软件问题如果重启冷机马上恢复问题就出在物理约束上。还有一点容易混淆大模型生成长文本时越往后越慢有一部分是上下文长度增长导致的KV Cache变大、注意力计算量增加这是算法原因。但实际端侧场景里硬件降频往往同时发生两股效应叠加速度衰减会比纯算法预估严重得多。我自己调试时遇到过这种情况按公式算出上下文翻倍应该慢20%实测却慢了40%多出来的部分就是烫出来的。2. 功耗墙性能先撞上的是看不见的功率红线2.1 端侧芯片手里的功率预算从哪来芯片不是想跑多快就跑多快。一颗移动SoC里CPU、GPU、NPU、DSP、Modem共用同一份功率预算预算的源头是整机热设计目标和电池放电能力。手机厂商在设计时就会确定一个整机持续功耗上限比如5瓦、6瓦、8瓦所有模块在这个上限内互相掰手腕。谁占得多别人就得让路。端侧AI推理跑起来NPU/GPU和大核CPU都在抢功率调度器必须做取舍。这就能解释很多怪现象比如跑纯NPU的模型时CPU频率被压低、跑CPU混合模型时GPU被限制甚至Wi-Fi和屏幕都会在AI负载下被降优先级。做端侧AI开发不能只看某一颗芯片的频率要盯着整个SoC的功率分配。2.2 DVFS频率不是越高越好电压必须跟着涨功耗墙的技术底层是DVFS动态电压频率调整。芯片频率提高工作电压也必须相应提高而功耗和电压的平方成正比、和频率成正比简单说P约等于C乘以V的平方乘以f。这个关系非常残酷频率提高10%为了维持稳定性电压得往上抬一点实际功耗可能增加20%到30%。也就是说芯片最后那一点点性能是拿大笔功耗换来的。这也解释了为什么端侧芯片的频率表通常不是一个连续区间而是一个个离散档位。芯片不是在任何频率都能工作而是踩着台阶往上爬。每一级频率对应一个功耗点和发热量。推理负载顶到最高档时功耗瞬间逼近预算上限系统后台的功耗管理模块立刻开始权衡。所以你看任务管理器里CPU还能摸到最高频率不一定是好事可能只是短暂冲顶下一秒就被按下去。2.3 端侧推理特别容易撞墙的三种情形第一种是持续的大规模矩阵运算。LLM推理主要有两类算子显存密集型和计算密集型无论哪一类都会让NPU/GPU长时间处于高占用状态。第二种是多核协同场景调度器把任务拆给大核CPU、GPU和NPU同时干活每个模块单看功耗不高加起来整机瞬间突破预算。第三种是模型规模超配本来这个SoC功耗效率只够跑3B模型量级硬塞一个7B模型芯片只能在低频率档位勉强维持速度当然上不去。我在实际开发板测试中遇到过非常典型的情况跑同一个7B INT4模型限制整机功耗8瓦时大核CPU最高能到2.2GHz把预算放开到12瓦频率能多保持一个档位推理速度提升15%。代价是温度肉眼可见地飙升几分钟后照样被温控压回来。这就是在功耗墙上做文章预算给足了温度墙又来了。3. 散热链温度是慢慢追上来的降频也是逐级发生的3.1 从芯片节到外壳热量要过好几道关芯片工作产生的热量路径基本是固定的从硅片内部传导到芯片表面再经过导热硅脂或相变材料到屏蔽罩再从屏蔽罩到均热板、石墨片最后到外壳和空气。这一层一层每一道都有热阻。热阻大的环节就像管道里的瓶颈会把热量憋在芯片附近导致节温快速上升。端侧设备和云服务器最直观的差别就在这里服务器里有风扇直吹散热鳍片气流是主动的手机和平板只能靠外壳自然辐射加一点内部空气对流。哪怕是开发板很多也只是被动散热一块铝合金底板没有风道。芯片节温冲到85到90度太常见了。这里要区分两个温度SoC内部的节温junction temperature和外壳温度。节温是芯片命脉过热会损坏器件降频保护主要看节温。但外壳温度决定用户手感手机厂商对触感有严格约束一般控制在45度以内。这两层约束同时存在散热设计必须两头兼顾。3.2 降频不是一刀切而是多传感器各自为政移动SoC内部不止一个温度传感器。大核CPU一个温区、小核一个、GPU一个、NPU一个还有充电管理芯片、电源管理芯片各自有温度上报能力。这些传感器各看各的谁触到自己的危险温度线谁就先降频。于是你会看到一种很隐蔽的性能退化NPU触发了温控频率从最高档掉到中档但CPU还跑着正常频率系统整体吞吐量下滑20%你从上到下查软件啥问题都查不出来因为所有元器件频率看起来都“正常”。降频本身也是分档的。大多数芯片的温控逻辑是阶梯式温度低于阈值A全速超过阈值A降一档比如从最高频落到次高频继续升到阈值B再降一档。每一档停留一段时间看温度是不是回落。这个机制类似家用空调的温控不是一热就制冷而是阶梯式逼近目标温度。这一特点导致直观感受是速度“一段一段往下掉”就像人跑步时被逐渐加了负重。3.3 连续推理的热量累积是个慢变量为什么刚开机跑同一段任务飞快跑半小时后变慢因为热量在设备里累积是个慢过程。芯片的热容、外壳的热容、空气被加热的过程决定了温度不会瞬间冲到阈值而是以秒甚至分钟为单位往上爬。打个比方芯片是刚烧开的水壶外壳是大水缸壶里的水先热大缸的水慢慢升温。整个系统要达到热平衡可能需要十分钟到二十分钟。对推理任务来说这意味着前几轮请求占了大便宜——设备还是凉的芯片可以顶着高功耗跑满速。等到热量传导开、各处温度传感器显示读数上来了降频才真正开始。我测过同一台设备冷机和热机状态下的性能差冷机时跑一个生成任务能有18 token/s热平衡后只剩12左右差距高达30%。如果你只把设备放在冷态下做性能验收那到了真实业务场景被用户连续使用时性能预期会完全失准。3.4 散热悖论散热越好降频来得越晚但也越集中有意思的是“散热好”的设备并不等于不降频。散热路径好芯片热量能更高效导到外壳节温升得慢满频时间更长总吞吐量一定是更优的。但外壳温度会先到达人的触感上限于是系统被迫开始限制芯片功率以降频来保住外壳温度。散热差的设备反而因为芯片早就飙到高温阈值提前降频把功耗压下去外壳反而不那么热。做硬件选型时一定要把这个悖论想清楚。如果产品形态允许加风扇比如边缘计算盒子主动散热能显著推迟降频如果是手持设备外壳温度触感上限就是硬约束再怎么堆均热板也改变不了最终会被温控压制的结局只能尽量推迟降频的出现时间。4. 供电侧电压一抖吞吐量跟着抖4.1 电池不是稳定的电压源很多人把电池当成一个恒定电压的“大电容”实际完全不是这么回事。锂离子电池的放电曲线从满电接近4.4V一路下滑放到接近没电时大概3.6V甚至更低。电压下降意味着什么在输出功率一定的情况下电压越低电流就得越大而电流一大电池内阻上的压降就更严重形成一个恶性循环。对一个2安培左右的常规负载电池电压波动影响可能不明显但端侧推理的瞬时电流可以冲到5、6安培这时候内阻造成的压降就非常可观了。电压一旦低于电源管理芯片的最低工作门槛整机不是立刻关机而是触发保护机制把芯片频率强制往下拉。你在低电量时用手机跑模型觉得特别卡大概率就是这个原因。4.2 推理负载的瞬时功率尖峰对供电路径不友好端侧AI推理对电源的要求和视频编解码不一样它有明显的功率脉冲。生成一个token的计算密集区间功率瞬间拉高token之间的调度、访存区间功率又回落。这种高频脉冲对电源管理电路是考验电源路径要有足够的余量去应对瞬时大电流电容要能稳住电压。我见过一块设备用普通USB口供电跑LLM推理一跑就自动限频以为是固件问题后来发现是供电功率根本不够。适配器标称5V2A瞬时电流一突破就开始电流倒灌电源管理芯片检测到电压跌落就强制降频推理速度从14掉到8。换成稳压电源后同样代码性能立马上来。供电这块要是没排查纯粹在软件层调参调一个月都白搭。4.3 电池老化后的真实差距电池用上半年一年内阻变大放电能力下降。同样一个高负载推理请求新电池电压可能只跌0.15V老化电池可能跌0.3V以上。在低电量区间这个差距会被急剧放大。我做过一个简单的对比实验同一台设备同一温度环境新电池90%电量和用了一年的电池20%电量跑同一个模型的性能差距能到25%。注意这个差距不是电量本身导致的而是电压跌落深度不同。所以在用户侧你会发现一个规律设备刚买来跑AI很快用了一年之后跑同样的模型明显慢不换电池就回不到当初的性能。这跟系统更新无关就是供电能力老化。做端侧AI产品如果面向长生命周期设备必须把电池老化纳入性能规划。4.4 两条供电路线的现实差异端侧设备供电有两种典型路线。一是电池供电接受电压随SOC缓慢下降适合便携场景二是外接电源直供许多开发板、边缘盒子直接接适配器电压相对稳定但适配器的功率和纹波质量决定了能不能撑住大电流。还有一类是手机上的旁路充电——适配器直接给系统供电绕过电池既减少发热还能稳定电压。从推理性能稳定性排序旁路充电/稳压电源直供好于满电电池供电而低电量电池供电是最差的。如果你在固定场景部署端侧推理设备强烈建议优先考虑外接稳压电源别贪图“无线化”让设备用电池顶着跑。5. 一组实测曲线看看同一台设备在25分钟里都经历了什么5.1 测试环境与测试方法参数说详细的方便大家自己复现。测试设备是一块搭载中高端移动SoC的安卓式开发板被动散热一块较大金属底板无风扇室温26度左右。模型是7B参数量的对话大语言模型INT4量化推理框架自带高性能后端。测试脚本每一轮生成128个token生成完休息2秒再进入下一轮连续运行25分钟。监控链路包括整机功耗直流电源分析仪读数、SoC表面温度、最高频率档位和平均token/s。这里有几个细节被动散热开发板模拟的是“没有主动风冷”的真实端侧形态每轮之间休息2秒模拟真实对话场景但又让负载有连续性。如果完全无间隔降频会更早更狠。5.2 25分钟的温度、功耗、速度变化下面这组数据虽然来自单次试验但趋势在我测过的几乎所有端侧设备上都一致。时间点整机功耗SoC温度大核最高频率平均生成速度第0分钟7.5W38摄氏度2.6GHz18.4 token/s第5分钟8.2W61摄氏度2.6GHz17.9 token/s第10分钟7.9W78摄氏度2.4GHz15.6 token/s第15分钟6.8W86摄氏度2.0GHz13.2 token/s第20分钟6.1W84摄氏度1.8GHz11.9 token/s第25分钟5.9W83摄氏度1.8GHz11.4 token/s5.3 数据解读三个阶段非常清晰第一阶段是前5分钟满血状态。散热底板还是凉的芯片可以放开跑到最高频率功耗爬到8瓦以上速度和冷机基准值几乎一致。这个阶段最容易给测试人员造成错觉以为整机性能就是这样。第二阶段是第10到15分钟第一次降频。SoC温度越过温控阈值频率从2.6GHz退到2.4GHz再退到2.0GHz。功耗反而下降了因为频率降低让动态功耗减小但温度依然缓慢上升说明散热系统已经接近承载极限。速度降幅超过25%。第三阶段是第20分钟后热平衡稳态。功耗降到6瓦左右温度稳定在83到85摄氏度之间频率稳定在1.8GHz速度稳定在11.4到11.9 token/s。整个系统在一个更低功耗、更高温度的平衡点上运行无论再跑多久这个状态都不会有太大变化。除非环境温度变化或者设备从被动散热改成主动散热否则这个“稳态速度”就是用户真实体验到的速度。这组数据让我最有感触的一点是很多项目验收踩的坑就是只测第一阶段拿18.4这个数字写在方案里。结果用户真机上一跑稳态只有11.4差距40%。测端侧AI性能请在设备进入热平衡之后再看成绩。5.4 手机场景比开发板更残酷同样的负载放到手机上降频会来得更早因为手机的外壳面积更小、被动散热路径更受限、外壳触感温度约束更严格。我见过一台量产手机跑小模型6分钟就进入降频稳态最终稳定性能只有初始的60%。所以手机端侧AI做性能规划时最好不要参考那种“只跑三条请求”的快速测试结果要连续跑至少10分钟取稳态值。6. 工程上怎么扛把“热与电”纳入推理系统的设计变量6.1 先排查到底是软件病还是物理病遇到推理性能下降第一件事不是上模型优化而是先区分原因。我一般用这个对照表来定位特征软件问题功耗/散热/供电问题重启后冷机恢复不一定恢复基本都能恢复温度环节温度正常仍慢温度高时必慢电量相关性相关性弱低电量显著恶化运行时长相关性内存/缓存泄漏会随时间累积持续负载下持续下降有稳态任务类型相关性特定算子/模型才触发各类AI负载都会触发6.2 把温度、频率、功耗监控变成常规手段做端侧推理优化没有实时的温度/频率监控基本等于盲飞。早期我调性能时只看耗时后来发现耗时涨了原因根本看不见加监控之后数据一目了然。建议把传感器数据采集直接集成到测试脚本里每2到5秒记录一次。# 示意代码定期采样SoC温度、CPU最高频率、整机功耗 # 具体实现依赖具体平台系统接口这里只展示采集逻辑 import time import os def sample_status(): return { ts: time.time(), # 温度节点路径、频率节点路径按实际设备调整 soc_temp: read_sysfs(/sys/class/thermal/thermal_zone0/temp), cpu_max_freq: read_sysfs(/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq), power: read_power_meter(), # 外接电源分析仪或板载PMIC读数 } def run_benchmark(duration1500): logs [] while time.time() - start duration: logs.append(sample_status()) time.sleep(2) return logs # 跑完一轮后把 token/s、温度、功耗对齐看曲线这个脚本的价值不在于代码复杂度而在于让你认识到“性能下降”是一个有先兆的过程。温度爬升、频率掉档、功耗回落这些现象出现在速度变慢之前早一点看到就能早一点干预。6.3 任务编排给设备留出“喘气”的窗口如果业务形态允许不要在端侧设备上做无间断的高强度连续推理。把长会话拆成多个短轮次轮次之间插入几十毫秒到几百毫秒的空档让DVFS有时间把频率降下来喘口气。这个方法看起来不起眼但对热稳态的改善非常明显。我做过对比同样20分钟负载连续跑和无间隔跑的热稳态温度能差4到5度对应速度差10%左右。还有一个实操技巧是限制最大生成长度。很多端侧对话模型默认允许输出512或1024个token但实际上用户经常只读到一两百字。把最大生成长度限制在256甚至128既能降低单次功耗总量又能减少设备进入长时间满负载的概率。这个改动产品体验上几乎无感但对发热控制帮助巨大。6.4 供电方案固定场景优先稳压电源如果你的端侧设备是固定位置部署边缘网关、智能面板、桌面终端优先用稳压电源而非电池。注意稳压电源的功率余量建议按峰值功耗的1.5倍以上选型别看“标称3A”就以为能顶住瞬时4A电源的瞬态响应同样重要。如果必须用电池至少做好两个监控电池健康度通过充放电循环估算内阻和低电量预警。当电量低于某个阈值我习惯设为30%主动降低推理任务优先级或者切换到更小的模型、更低的精度而不是等到系统自动降频造成劣质感。手机上的旁路充电接口如果支持在跑重负载时引导用户插电也能明显改善稳速。6.5 散热辅助的性价比排序给设备加散热工程上性价比从高到低大致是加主动风扇大于加大均热板面积大于换高导热硅脂大于贴石墨片。开发板需要跑持续负载时哪怕一个低速小风扇都有奇效能把稳态速度拉回15%到20%。手持设备没有风扇选项只能在结构上增加导热路径把热量有效传导到外壳大面积区域。注意均热板的方向性热量要能纵向导到外壳而不是在芯片周围打转。还有一个容易被忽略的选项软件上限制并发度。如果设备同时跑多个推理任务强制串行化或者限制最大并发数可以减少功率尖峰重叠供电压力和热量压力都会小很多。这在边缘盒子多路请求场景里特别实用。6.6 模型侧降功耗是在源头削减热量硬件层面能做的优化终究有上限真正有效的还是让模型本身更省电。INT4/INT8量化是最直接的能把单token推理功耗砍掉一半以上剪枝、蒸馏可以减小模型规模投机采样能减少大模型实际激活的层数。我见过一个项目把7B模型从FP16切到INT4之后稳态温度降了10度速度反而快了一倍——因为降频发生得晚了很多甚至没发生。但要注意量化精度不是越高越好量化本身可能带来额外校准和精度损失。工程上的标准做法是先在云端验证精度损失在可接受范围内再上端侧测发热与速度。这几年做端侧AI的一个体会是别把芯片参数表和厂商宣传里的峰值算力太当真。端侧设备在真实环境里的性能是由功率预算、散热路径、电池状态共同决定的算力只是上限物理约束才是那个真正决定体验的下限。设计阶段就把这三条锁链纳入考量比上线后到处排查要省力得多。 
长河君 · 2026/10/25 5:00:49 · 阅读 1.2k 端侧AI越跑越慢？功耗、散热与供电三条物理锁链揭秘
跑端侧AI的人大概率都碰到过这样一个怪现象模型没换、代码没动、开发板还是同一块刚开机的时候token刷刷往外蹦跑个十来二十分钟速度肉眼可见地往下掉等电量再低一些整个推理延迟能翻倍。我见过不少团队把这个现象当成软件bug去排查查内存泄漏、查缓存策略、查算子实现忙活半天一无所获。真相不在代码层在物理层——端侧推理消耗的是电池里的电电变成热热又反过来压制芯片的频率供电、功耗、散热三样东西串在一起才造成“越跑越慢”。这篇文章不讲模型优化只讲端侧算力背后这三条物理锁链是怎么一环扣一环的。1. 越跑越慢不是错觉先说清楚端侧算力的物理边界1.1 云侧和端侧最大的差别不在算力在“能量环境”大家习惯把端侧推理和云侧推理放在一起比性能比来比去总觉得端侧吃亏在算力弱。其实更本质的差异是能量环境完全不同。云端GPU服务器插着几千瓦的电源房间里空调常年18度机柜里风扇把热量源源不断带走。负载高了大不了多开几个实例单卡跑到降频直接换一台。端侧设备呢一块电池几百克重量没有主动散热外壳还不能烫手。拿手机来说整机持续功耗能做到4到8瓦就已经不错了开发板稍微宽松一些通常也就是10到15瓦的量级。这个能量输入上限就是墙。很多人忽略的是AI推理恰恰是所有负载里最不省油的那一类。网页浏览、视频播放都有明显的空闲窗口GPU/CPU可以间歇性歇口气。但端侧跑大语言模型是自回归生成逐token往前推每一秒都在持续大功率输出大核高负载、NPU/GPU满频连续几分钟、十几分钟不停工。这种负载形态对功耗预算和散热系统的压力比跑游戏还要极端。所以端侧推理越来越慢不是偶发故障是物理环境决定的必然走向差别只在于降频的时间点来得早还是晚。1.2 先给“慢”一个准确定义排错之前得先把现象定义清楚。这里的越跑越慢指的是同一台设备、同一个模型、同一个输入和batch配置推理吞吐量token/s随运行时间持续下降或者随电量下降且重启后冷机状态下性能能够恢复。注意两个关键词——同配置、可恢复。如果重启后依然慢那大概率是软件问题如果重启冷机马上恢复问题就出在物理约束上。还有一点容易混淆大模型生成长文本时越往后越慢有一部分是上下文长度增长导致的KV Cache变大、注意力计算量增加这是算法原因。但实际端侧场景里硬件降频往往同时发生两股效应叠加速度衰减会比纯算法预估严重得多。我自己调试时遇到过这种情况按公式算出上下文翻倍应该慢20%实测却慢了40%多出来的部分就是烫出来的。2. 功耗墙性能先撞上的是看不见的功率红线2.1 端侧芯片手里的功率预算从哪来芯片不是想跑多快就跑多快。一颗移动SoC里CPU、GPU、NPU、DSP、Modem共用同一份功率预算预算的源头是整机热设计目标和电池放电能力。手机厂商在设计时就会确定一个整机持续功耗上限比如5瓦、6瓦、8瓦所有模块在这个上限内互相掰手腕。谁占得多别人就得让路。端侧AI推理跑起来NPU/GPU和大核CPU都在抢功率调度器必须做取舍。这就能解释很多怪现象比如跑纯NPU的模型时CPU频率被压低、跑CPU混合模型时GPU被限制甚至Wi-Fi和屏幕都会在AI负载下被降优先级。做端侧AI开发不能只看某一颗芯片的频率要盯着整个SoC的功率分配。2.2 DVFS频率不是越高越好电压必须跟着涨功耗墙的技术底层是DVFS动态电压频率调整。芯片频率提高工作电压也必须相应提高而功耗和电压的平方成正比、和频率成正比简单说P约等于C乘以V的平方乘以f。这个关系非常残酷频率提高10%为了维持稳定性电压得往上抬一点实际功耗可能增加20%到30%。也就是说芯片最后那一点点性能是拿大笔功耗换来的。这也解释了为什么端侧芯片的频率表通常不是一个连续区间而是一个个离散档位。芯片不是在任何频率都能工作而是踩着台阶往上爬。每一级频率对应一个功耗点和发热量。推理负载顶到最高档时功耗瞬间逼近预算上限系统后台的功耗管理模块立刻开始权衡。所以你看任务管理器里CPU还能摸到最高频率不一定是好事可能只是短暂冲顶下一秒就被按下去。2.3 端侧推理特别容易撞墙的三种情形第一种是持续的大规模矩阵运算。LLM推理主要有两类算子显存密集型和计算密集型无论哪一类都会让NPU/GPU长时间处于高占用状态。第二种是多核协同场景调度器把任务拆给大核CPU、GPU和NPU同时干活每个模块单看功耗不高加起来整机瞬间突破预算。第三种是模型规模超配本来这个SoC功耗效率只够跑3B模型量级硬塞一个7B模型芯片只能在低频率档位勉强维持速度当然上不去。我在实际开发板测试中遇到过非常典型的情况跑同一个7B INT4模型限制整机功耗8瓦时大核CPU最高能到2.2GHz把预算放开到12瓦频率能多保持一个档位推理速度提升15%。代价是温度肉眼可见地飙升几分钟后照样被温控压回来。这就是在功耗墙上做文章预算给足了温度墙又来了。3. 散热链温度是慢慢追上来的降频也是逐级发生的3.1 从芯片节到外壳热量要过好几道关芯片工作产生的热量路径基本是固定的从硅片内部传导到芯片表面再经过导热硅脂或相变材料到屏蔽罩再从屏蔽罩到均热板、石墨片最后到外壳和空气。这一层一层每一道都有热阻。热阻大的环节就像管道里的瓶颈会把热量憋在芯片附近导致节温快速上升。端侧设备和云服务器最直观的差别就在这里服务器里有风扇直吹散热鳍片气流是主动的手机和平板只能靠外壳自然辐射加一点内部空气对流。哪怕是开发板很多也只是被动散热一块铝合金底板没有风道。芯片节温冲到85到90度太常见了。这里要区分两个温度SoC内部的节温junction temperature和外壳温度。节温是芯片命脉过热会损坏器件降频保护主要看节温。但外壳温度决定用户手感手机厂商对触感有严格约束一般控制在45度以内。这两层约束同时存在散热设计必须两头兼顾。3.2 降频不是一刀切而是多传感器各自为政移动SoC内部不止一个温度传感器。大核CPU一个温区、小核一个、GPU一个、NPU一个还有充电管理芯片、电源管理芯片各自有温度上报能力。这些传感器各看各的谁触到自己的危险温度线谁就先降频。于是你会看到一种很隐蔽的性能退化NPU触发了温控频率从最高档掉到中档但CPU还跑着正常频率系统整体吞吐量下滑20%你从上到下查软件啥问题都查不出来因为所有元器件频率看起来都“正常”。降频本身也是分档的。大多数芯片的温控逻辑是阶梯式温度低于阈值A全速超过阈值A降一档比如从最高频落到次高频继续升到阈值B再降一档。每一档停留一段时间看温度是不是回落。这个机制类似家用空调的温控不是一热就制冷而是阶梯式逼近目标温度。这一特点导致直观感受是速度“一段一段往下掉”就像人跑步时被逐渐加了负重。3.3 连续推理的热量累积是个慢变量为什么刚开机跑同一段任务飞快跑半小时后变慢因为热量在设备里累积是个慢过程。芯片的热容、外壳的热容、空气被加热的过程决定了温度不会瞬间冲到阈值而是以秒甚至分钟为单位往上爬。打个比方芯片是刚烧开的水壶外壳是大水缸壶里的水先热大缸的水慢慢升温。整个系统要达到热平衡可能需要十分钟到二十分钟。对推理任务来说这意味着前几轮请求占了大便宜——设备还是凉的芯片可以顶着高功耗跑满速。等到热量传导开、各处温度传感器显示读数上来了降频才真正开始。我测过同一台设备冷机和热机状态下的性能差冷机时跑一个生成任务能有18 token/s热平衡后只剩12左右差距高达30%。如果你只把设备放在冷态下做性能验收那到了真实业务场景被用户连续使用时性能预期会完全失准。3.4 散热悖论散热越好降频来得越晚但也越集中有意思的是“散热好”的设备并不等于不降频。散热路径好芯片热量能更高效导到外壳节温升得慢满频时间更长总吞吐量一定是更优的。但外壳温度会先到达人的触感上限于是系统被迫开始限制芯片功率以降频来保住外壳温度。散热差的设备反而因为芯片早就飙到高温阈值提前降频把功耗压下去外壳反而不那么热。做硬件选型时一定要把这个悖论想清楚。如果产品形态允许加风扇比如边缘计算盒子主动散热能显著推迟降频如果是手持设备外壳温度触感上限就是硬约束再怎么堆均热板也改变不了最终会被温控压制的结局只能尽量推迟降频的出现时间。4. 供电侧电压一抖吞吐量跟着抖4.1 电池不是稳定的电压源很多人把电池当成一个恒定电压的“大电容”实际完全不是这么回事。锂离子电池的放电曲线从满电接近4.4V一路下滑放到接近没电时大概3.6V甚至更低。电压下降意味着什么在输出功率一定的情况下电压越低电流就得越大而电流一大电池内阻上的压降就更严重形成一个恶性循环。对一个2安培左右的常规负载电池电压波动影响可能不明显但端侧推理的瞬时电流可以冲到5、6安培这时候内阻造成的压降就非常可观了。电压一旦低于电源管理芯片的最低工作门槛整机不是立刻关机而是触发保护机制把芯片频率强制往下拉。你在低电量时用手机跑模型觉得特别卡大概率就是这个原因。4.2 推理负载的瞬时功率尖峰对供电路径不友好端侧AI推理对电源的要求和视频编解码不一样它有明显的功率脉冲。生成一个token的计算密集区间功率瞬间拉高token之间的调度、访存区间功率又回落。这种高频脉冲对电源管理电路是考验电源路径要有足够的余量去应对瞬时大电流电容要能稳住电压。我见过一块设备用普通USB口供电跑LLM推理一跑就自动限频以为是固件问题后来发现是供电功率根本不够。适配器标称5V2A瞬时电流一突破就开始电流倒灌电源管理芯片检测到电压跌落就强制降频推理速度从14掉到8。换成稳压电源后同样代码性能立马上来。供电这块要是没排查纯粹在软件层调参调一个月都白搭。4.3 电池老化后的真实差距电池用上半年一年内阻变大放电能力下降。同样一个高负载推理请求新电池电压可能只跌0.15V老化电池可能跌0.3V以上。在低电量区间这个差距会被急剧放大。我做过一个简单的对比实验同一台设备同一温度环境新电池90%电量和用了一年的电池20%电量跑同一个模型的性能差距能到25%。注意这个差距不是电量本身导致的而是电压跌落深度不同。所以在用户侧你会发现一个规律设备刚买来跑AI很快用了一年之后跑同样的模型明显慢不换电池就回不到当初的性能。这跟系统更新无关就是供电能力老化。做端侧AI产品如果面向长生命周期设备必须把电池老化纳入性能规划。4.4 两条供电路线的现实差异端侧设备供电有两种典型路线。一是电池供电接受电压随SOC缓慢下降适合便携场景二是外接电源直供许多开发板、边缘盒子直接接适配器电压相对稳定但适配器的功率和纹波质量决定了能不能撑住大电流。还有一类是手机上的旁路充电——适配器直接给系统供电绕过电池既减少发热还能稳定电压。从推理性能稳定性排序旁路充电/稳压电源直供好于满电电池供电而低电量电池供电是最差的。如果你在固定场景部署端侧推理设备强烈建议优先考虑外接稳压电源别贪图“无线化”让设备用电池顶着跑。5. 一组实测曲线看看同一台设备在25分钟里都经历了什么5.1 测试环境与测试方法参数说详细的方便大家自己复现。测试设备是一块搭载中高端移动SoC的安卓式开发板被动散热一块较大金属底板无风扇室温26度左右。模型是7B参数量的对话大语言模型INT4量化推理框架自带高性能后端。测试脚本每一轮生成128个token生成完休息2秒再进入下一轮连续运行25分钟。监控链路包括整机功耗直流电源分析仪读数、SoC表面温度、最高频率档位和平均token/s。这里有几个细节被动散热开发板模拟的是“没有主动风冷”的真实端侧形态每轮之间休息2秒模拟真实对话场景但又让负载有连续性。如果完全无间隔降频会更早更狠。5.2 25分钟的温度、功耗、速度变化下面这组数据虽然来自单次试验但趋势在我测过的几乎所有端侧设备上都一致。时间点整机功耗SoC温度大核最高频率平均生成速度第0分钟7.5W38摄氏度2.6GHz18.4 token/s第5分钟8.2W61摄氏度2.6GHz17.9 token/s第10分钟7.9W78摄氏度2.4GHz15.6 token/s第15分钟6.8W86摄氏度2.0GHz13.2 token/s第20分钟6.1W84摄氏度1.8GHz11.9 token/s第25分钟5.9W83摄氏度1.8GHz11.4 token/s5.3 数据解读三个阶段非常清晰第一阶段是前5分钟满血状态。散热底板还是凉的芯片可以放开跑到最高频率功耗爬到8瓦以上速度和冷机基准值几乎一致。这个阶段最容易给测试人员造成错觉以为整机性能就是这样。第二阶段是第10到15分钟第一次降频。SoC温度越过温控阈值频率从2.6GHz退到2.4GHz再退到2.0GHz。功耗反而下降了因为频率降低让动态功耗减小但温度依然缓慢上升说明散热系统已经接近承载极限。速度降幅超过25%。第三阶段是第20分钟后热平衡稳态。功耗降到6瓦左右温度稳定在83到85摄氏度之间频率稳定在1.8GHz速度稳定在11.4到11.9 token/s。整个系统在一个更低功耗、更高温度的平衡点上运行无论再跑多久这个状态都不会有太大变化。除非环境温度变化或者设备从被动散热改成主动散热否则这个“稳态速度”就是用户真实体验到的速度。这组数据让我最有感触的一点是很多项目验收踩的坑就是只测第一阶段拿18.4这个数字写在方案里。结果用户真机上一跑稳态只有11.4差距40%。测端侧AI性能请在设备进入热平衡之后再看成绩。5.4 手机场景比开发板更残酷同样的负载放到手机上降频会来得更早因为手机的外壳面积更小、被动散热路径更受限、外壳触感温度约束更严格。我见过一台量产手机跑小模型6分钟就进入降频稳态最终稳定性能只有初始的60%。所以手机端侧AI做性能规划时最好不要参考那种“只跑三条请求”的快速测试结果要连续跑至少10分钟取稳态值。6. 工程上怎么扛把“热与电”纳入推理系统的设计变量6.1 先排查到底是软件病还是物理病遇到推理性能下降第一件事不是上模型优化而是先区分原因。我一般用这个对照表来定位特征软件问题功耗/散热/供电问题重启后冷机恢复不一定恢复基本都能恢复温度环节温度正常仍慢温度高时必慢电量相关性相关性弱低电量显著恶化运行时长相关性内存/缓存泄漏会随时间累积持续负载下持续下降有稳态任务类型相关性特定算子/模型才触发各类AI负载都会触发6.2 把温度、频率、功耗监控变成常规手段做端侧推理优化没有实时的温度/频率监控基本等于盲飞。早期我调性能时只看耗时后来发现耗时涨了原因根本看不见加监控之后数据一目了然。建议把传感器数据采集直接集成到测试脚本里每2到5秒记录一次。# 示意代码定期采样SoC温度、CPU最高频率、整机功耗 # 具体实现依赖具体平台系统接口这里只展示采集逻辑 import time import os def sample_status(): return { ts: time.time(), # 温度节点路径、频率节点路径按实际设备调整 soc_temp: read_sysfs(/sys/class/thermal/thermal_zone0/temp), cpu_max_freq: read_sysfs(/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq), power: read_power_meter(), # 外接电源分析仪或板载PMIC读数 } def run_benchmark(duration1500): logs [] while time.time() - start duration: logs.append(sample_status()) time.sleep(2) return logs # 跑完一轮后把 token/s、温度、功耗对齐看曲线这个脚本的价值不在于代码复杂度而在于让你认识到“性能下降”是一个有先兆的过程。温度爬升、频率掉档、功耗回落这些现象出现在速度变慢之前早一点看到就能早一点干预。6.3 任务编排给设备留出“喘气”的窗口如果业务形态允许不要在端侧设备上做无间断的高强度连续推理。把长会话拆成多个短轮次轮次之间插入几十毫秒到几百毫秒的空档让DVFS有时间把频率降下来喘口气。这个方法看起来不起眼但对热稳态的改善非常明显。我做过对比同样20分钟负载连续跑和无间隔跑的热稳态温度能差4到5度对应速度差10%左右。还有一个实操技巧是限制最大生成长度。很多端侧对话模型默认允许输出512或1024个token但实际上用户经常只读到一两百字。把最大生成长度限制在256甚至128既能降低单次功耗总量又能减少设备进入长时间满负载的概率。这个改动产品体验上几乎无感但对发热控制帮助巨大。6.4 供电方案固定场景优先稳压电源如果你的端侧设备是固定位置部署边缘网关、智能面板、桌面终端优先用稳压电源而非电池。注意稳压电源的功率余量建议按峰值功耗的1.5倍以上选型别看“标称3A”就以为能顶住瞬时4A电源的瞬态响应同样重要。如果必须用电池至少做好两个监控电池健康度通过充放电循环估算内阻和低电量预警。当电量低于某个阈值我习惯设为30%主动降低推理任务优先级或者切换到更小的模型、更低的精度而不是等到系统自动降频造成劣质感。手机上的旁路充电接口如果支持在跑重负载时引导用户插电也能明显改善稳速。6.5 散热辅助的性价比排序给设备加散热工程上性价比从高到低大致是加主动风扇大于加大均热板面积大于换高导热硅脂大于贴石墨片。开发板需要跑持续负载时哪怕一个低速小风扇都有奇效能把稳态速度拉回15%到20%。手持设备没有风扇选项只能在结构上增加导热路径把热量有效传导到外壳大面积区域。注意均热板的方向性热量要能纵向导到外壳而不是在芯片周围打转。还有一个容易被忽略的选项软件上限制并发度。如果设备同时跑多个推理任务强制串行化或者限制最大并发数可以减少功率尖峰重叠供电压力和热量压力都会小很多。这在边缘盒子多路请求场景里特别实用。6.6 模型侧降功耗是在源头削减热量硬件层面能做的优化终究有上限真正有效的还是让模型本身更省电。INT4/INT8量化是最直接的能把单token推理功耗砍掉一半以上剪枝、蒸馏可以减小模型规模投机采样能减少大模型实际激活的层数。我见过一个项目把7B模型从FP16切到INT4之后稳态温度降了10度速度反而快了一倍——因为降频发生得晚了很多甚至没发生。但要注意量化精度不是越高越好量化本身可能带来额外校准和精度损失。工程上的标准做法是先在云端验证精度损失在可接受范围内再上端侧测发热与速度。这几年做端侧AI的一个体会是别把芯片参数表和厂商宣传里的峰值算力太当真。端侧设备在真实环境里的性能是由功率预算、散热路径、电池状态共同决定的算力只是上限物理约束才是那个真正决定体验的下限。设计阶段就把这三条锁链纳入考量比上线后到处排查要省力得多。