设备端跑大模型的朋友应该都有过这种体验同一个模型冷机状态下第一轮推理飞快跑上十分钟之后同样的请求延迟肉眼可见地涨了上去有时候甚至直接卡顿。很多人第一反应是“模型被什么后台任务抢占了”查了一圈进程发现CPU占用并不高问题不在软件层。真正的原因往往藏在那句老生常谈里端侧推理的瓶颈从来不是算力而是功耗、散热和供电。这篇文章就把这三件事拆开讲清楚它们是如何一步步让你的推理任务“越跑越慢”的。这个现象背后不是单一因素在起作用而是三个物理环节互相耦合的结果功耗决定了芯片能跑多快散热决定了芯片敢跑多快供电则决定了芯片能不能稳定跑。任何一个环节出问题最终都会体现在同一个结果上——频率下降、性能劣化、推理延迟升高。这篇文章适合正在做端侧模型部署、边缘计算方案选型、或者自己组装本地推理设备的开发者参考看完之后你能学会如何定位推理变慢的物理根因而不是在软件层瞎折腾。1. 内容整体设计与思路拆解1.1 “越跑越慢”意味着什么在聊原理之前先把“越跑越慢”这个表述界定清楚。端侧推理的性能退化通常分两种形态短期退化从设备冷启动开始跑前几分钟性能正常之后逐渐劣化大概半小时后趋于稳定但性能已经比初始状态掉了一大截。这种退化通常可以在关闭设备、冷却一段时间后恢复原因基本锁定在散热降频上。长期退化设备运行数小时甚至数天之后持续变慢即使单次任务间隔很久也一样。这种往往是供电电路老化、电池内阻升高、或者散热材料导热硅脂、散热垫劣化导致的属于物理层面的性能衰减。我见过很多开发者把“越跑越慢”理解成“缓存被占满”或者“内存泄漏”但在端侧推理场景里绝大多数短期性能退化是温度墙和功耗墙共同作用的结果。理解了这一点整个排查方向就对了。1.2 端侧推理的特殊压力特征端侧推理与云端推理最大的不同在于工作负载的瞬时爆发性。云端GPU有专业机房环境温度恒定供电充裕算力可以持续拉满。而端侧设备手机、平板、边缘盒子、迷你主机的设计目标从来不是“持续高负载”而是“大多数时间低负载、短时间性能爆发”。这个设计取向直接决定了端侧设备的散热和供电余量都非常有限。一台15W TDP的迷你主机瞬时功耗冲到28W是可以的但不能持续一块手机SoC单核算力可以跑到3GHz以上但全核满速几分钟就会触发降频。端侧推理恰好是那种“长时间高占用”的典型负载——一个注意力层的矩阵乘法还没算完下一个已经在排队了芯片长期处于高功耗区间于是温度快速爬升功耗墙和温度墙接连触发。我之前帮一个朋友排查他的本地大模型推理设备那个设备跑7B量化模型开局能达到每秒15个token十分钟之后掉到每秒6个token。拆开设备一看散热模组上积了厚厚一层灰风扇转速虽然会跟着温度变化但风道已经被灰尘堵死了大半。清灰之后性能立刻恢复到初始水平。这件事给了我一个很重要的经验端侧推理设备大多数情况下不是性能不够而是“物理环境”撑不住性能释放。1.3 三个环节如何串联成一条退化链功耗、散热、供电不是三个独立的问题它们是一条完整的因果链芯片执行推理任务需要消耗电能 → 电能大部分转化为热量 → 热量堆积导致芯片温度升高 → 芯片为避免过热烧毁自动降频 → 降频后推理变慢供电在这个链条里的角色更加隐蔽。当芯片频率升高时瞬时电流随之增大。如果供电电路无法提供足够的电流或者电压在负载突变时跌落到阈值以下芯片会直接进入保护状态触发频率回退甚至系统重启。更麻烦的是供电不足本身也会加剧发热电源转换效率下降多余的功率转化为热量进一步推高芯片温度。这就形成了一个恶性循环功耗产生热量热量触发降频降频又让任务执行时间变长、总耗电量增加虽然瞬时功耗降低了但功耗墙的“墙”并没有消失供电系统长时间处于高负载状态效率下降热量积累更多。理解了这个循环你就知道为什么单纯优化软件算法解决不了“越跑越慢”——物理层的瓶颈不解除软件层怎么优化都只是缓解症状。2. 核心细节解析与实操要点2.1 功耗是源头芯片功耗模型大致由三个部分组成动态功耗、静态功耗和短路功耗。动态功耗是主要部分由开关频率和负载电容决定P α × C × V² × f其中α是翻转率C是负载电容V是工作电压f是频率。这个公式里最值得关注的是V平方项——电压下降一点点功耗降低非常显著反之电压上调一点点功耗也急剧上升。端侧推理芯片为了保证续航和散热通常采用动态电压频率调整DVFS策略芯片根据实时负载需求动态调整电压和频率组合。低负载时压低电压频率省电降热高负载时提高电压频率满足性能要求。看起来很美实际运行中却有几个坑DVFS调频需要时间。负载切换时反馈回路需要检测负载变化、计算目标频率、调整电压这个过程通常要几百微秒到几毫秒。推理任务对延迟敏感前一毫秒频率还没拉上去任务已经在低频率下执行了表现为单次推理延迟偏高。调频策略偏向保守。多数端侧芯片的DVFS算法优先保障稳定性和温度不会一股脑把频率拉到最高。即使温度距离上限还有不小余量频率也可能仅达到峰值的70%80%这就是“功耗墙”的实际形态。频率调整粒度不够精细。推理任务的负载并非始终均衡——注意力计算阶段算力密集非线性激活阶段反而很轻。如果调频跟不上任务节奏就会出现“重计算时频率不够高、轻计算时频率白白拉高”的低效状态。我实测过某款端侧平台的解码速度曲线能明显看到在上下文长度较长时token生成速度会出现周期性波动。对照芯片频率日志才发现每次长上下文触发内存高带宽占用时芯片会主动压低CPU/NPU频率因为内存控制器本身也是发热大户。这提醒我们不要只盯着“芯片算力”内存子系统的功耗和发热同样会反噬推理性能。2.2 散热决定了性能天花板半导体器件的性能和温度强相关。高温影响主要体现在两个层面一是漏电流增加。温度升高后半导体PN结的漏电流呈指数级上升静态功耗跟着上涨芯片整体功耗进一步升高发热更多。二是载流子迁移率下降。迁移率下降意味着晶体管的开关速度变慢相同电压下能够达到的最高频率降低芯片就要用更高电压才能维持原本的频率功耗又不必要地增加。为了应对这两重影响硬件设计者引入了温度墙Thermal Throttling芯片温度达到设定阈值时逐步下调频率和电压将温度控制在安全范围。这个机制是好事情——它防止芯片在过热状态下发生永久性损坏。但代价也显而易见你的推理任务被强制减速。散热设计的核心指标是热阻。一颗芯片要正常工作热量必须从芯片表面传递到外部环境路径包括芯片封装内部 → 导热材料 → 散热片 → 风扇/被动散热表面 → 空气。每一层都有热阻总热阻等于各层之和。散热效率越差芯片达到温度墙的速度越快。对端侧设备来说提升散热效率有几个务实的选择改善导热材料把普通硅脂换成高性能导热硅脂或相变材料能显著降低芯片与散热片之间的热阻。我实测某款边缘盒子更换导热垫之后同样负载下芯片温度低了8℃左右推理速度恢复到初始状态的90%以上。优化风道布局很多设备为了外观紧凑进风口被遮挡出风口紧贴墙面。整理一下摆放位置留出510厘米的通风空间比换风扇效果更明显。加装主动散热如果设备原本是被动散热加装一个小风扇哪怕是低速静音款散热效率都能提升一个量级。限制功耗上限这是治标不治本但有时候是最有效的。通过软件把芯片功耗限制在某个低于峰值的水平让芯片长期稳定运行在“次高频率”上总吞吐可能比“峰值频率频繁降频”更高。2.3 供电是那个容易被忽略的瓶颈供热问题聊完了接下来看供电。这一块在端侧推理里被低估得很严重。现代芯片运行在高频率时需要很大的瞬时电流。以一款旗舰级移动SoC为例CPU全核满频时电流可能超过10ANPU推理时另有额外电流需求。如果供电电路跟不上电压会瞬间跌落芯片为了保护数据完整性会立刻降频甚至暂停执行。供电系统对推理性能的影响主要有三种表现电源适配器功率不足。很多端侧设备标称15W功耗配18W适配器看起来有裕量但适配器在实际输出时存在损耗和波动加上设备里还有其他部件屏幕、硬盘、USB外围设备抢电流留给芯片的功率余量其实很紧。推理任务瞬间拉高功耗时适配器电压跌落芯片频率被压制。电池供电时的内阻问题。使用电池的设备更明显。锂电池在大电流放电时电池内阻会产生压降内阻越大压降越大。电池老化后内阻上升高功耗场景下电压维持不住系统只能降频保护。这就是为什么同一台设备插着电源跑得快、用电池跑得慢电池老化后差异更明显。供电转换效率随负载变化。电源转换电路在特定负载区间效率最高负载过低或过高效率都会下降。推理任务在中等偏高负载区工作时如果电源管理策略没有匹配好供电电路多消耗的功率会转化为热量进一步恶化散热环境。3. 实操过程与核心环节实现3.1 如何量化“越跑越慢”要解决性能退化先把现象量化。我建议准备一套简单的测试脚本固定模型、固定输入长度、固定推理参数在冷机状态下开始跑每隔一段时间记录一次延迟或token吞吐。跑至少30分钟最好跑满1小时拿到完整曲线后观察下降趋势。实测过程中有几个细节需要注意每轮之间要留间隔。不要连续发满负载请求否则测出的是峰值吞吐而不是延迟曲线。建议每跑完一轮停12秒再发下一轮让设备有一个喘息的窗口模拟真实交互场景。记录环境温度。夏天室内30℃和冬天室内18℃的推理性能曲线差异巨大。我做过对比环境温度每升高5℃芯片最高频率大约下降8%12%。如果你在空调房里测出来正常、在没空调的房间里性能暴跌那个差异不是设备坏了而是热容被环境顶爆了。同时采集芯片频率和温度。光记录延迟不够还得把硬件数据一起抓下来。用系统工具读CPU/GPU/NPU频率采样、芯片结温采样把三者画在同一张图上根因一目了然——如果延迟爬升和芯片温度爬升同步出现就是温度墙在作祟如果温度还很健康但延迟就降了考虑功耗墙或功耗限制策略。我当时排查设备本来以为问题在NPU调度画完图之后发现NPU频率曲线跟温度曲线几乎完美重合温度每涨10℃NPU频率往下掉一档。问题的指向就非常明确了根本不用浪费时间在软件层翻找。3.2 自定义一个简易的持续推理测试脚本下面给一个简单的Python模拟脚本。它不做真实的AI推理而是模拟推理任务的高计算负载用来快速判断设备的散热和供电健康状况import time import threading import statistics def burn_cpu(duration_s600): 持续进行密集整数运算模拟推理负载 end_time time.time() duration_s result 0 while time.time() end_time: for i in range(10000): result i * i result % 1000000007 time.sleep(0.001) # 避免纯粹占满内核留出采样时间 return result def measure_performance_window(seconds10): 在当前状态下执行一段固定强度计算用耗时评估性能 start time.time() burn_cpu(seconds) elapsed time.time() - start return elapsed if __name__ __main__: print(冷机基线) baseline measure_performance_window(5) print(f {baseline - 5:.2f}s 额外耗时) # 持续高负载运行5分钟 print(开始持续负载 300 秒...) t threading.Thread(targetburn_cpu, args(300,)) t.start() samples [] while t.is_alive(): time.sleep(30) samples.append(statistics.fmean([measure_performance_window(3) for _ in range(3)])) print(f 第 {len(samples)*30}s 附近: 耗时波动 {min(samples):.2f}s ~ {max(samples):.2f}s) t.join() print(测试完成)这段代码的原理是用纯CPU密集任务模拟推理的持续高功耗特性通过重复测量固定时长的计算耗时来评估当前处理性能。如果后半程耗时明显高于前半程说明设备在持续负载下发生了性能退化接下来就可以配合硬件温度监控工具进一步确认原因。这里的逻辑是不依赖具体AI框架任何电脑都能跑方便对照。真实推理任务的波动会更复杂但这个脚本足够帮你快速筛出问题设备。3.3 供电不足的现场排查法供电问题在软件日志里往往不显眼我总结了一套现场排查的思路切换供电模式做个对照实验。同一台设备用电池跑一轮插着电源再跑一轮对比推理速度。如果性能差异超过10%基本可以断定电池供电模式下存在功耗限制或电压降级。更换电源适配器试试。用功率余量更大的适配器替代原装适配器注意电压必须一致电流可以更大再跑一轮对比。如果性能提升明显原适配器的供电余量确实不足。尝试同时给USB外设独立供电。端侧设备上挂着移动硬盘、USB采集卡等外设时外设的瞬态电流会拉低系统供电电压间接影响芯片性能。给外设加独立供电之后主机的推理速度常常有明显恢复。观察重启后的短时性能。设备刚插电或刚重启时电池处于充电状态系统会优先满足充电需求此时压降可能更明显。先把设备用到电量较低时再充电测试排除充电和推理抢功率的干扰。有一个比较反直觉的现象我遇到过设备插着电跑推理时比用电池还慢。这种情况看起来不可思议但原因并不复杂——某些设备的充电管理策略很激进插着电时系统会同时给电池充电电池充电电流和推理电流叠加总电流逼近适配器上限电压跌落幅度反而比纯电池供电更大。解决办法也简单在系统设置里关闭或限制充电电流或者等电池基本充满后再跑推理。3.4 散热与功耗的协同调优顺序刚拿到一台端侧推理设备我建议按下面的顺序做一轮系统调优每一步都切切实实能带来性能收益第一步清灰换硅脂。别嫌老土这一步性价比极高。灰尘堵塞风道导致的散热恶化通常比预想严重得多。如果设备已经用了两三年把散热模组拆下来清灰、重涂硅脂大概率能看到性能恢复10%20%。第二步调整供电配置。检查电源适配器规格是否满足峰值功率需求用至少高出一个档位的适配器替换测试。如果是电池设备检查电池健康度。电池健康度低于80%的旧机器换电池比任何软件调优都有效。第三步设置合理的性能模式。很多端侧设备提供“性能模式/均衡模式/省电模式”的选项。做推理时务必选择性能模式但这个选择也有代价——性能模式下芯片功耗上限更高发热更快如果没有良好散热支撑过一会儿还是会降频。这时候可以在系统层面微微限制功耗比如设置功耗上限为峰值的90%让芯片保持一个稍低但稳定的频率总吞吐反而更高。第四步监控温度并设置预警。用硬件监控工具读取芯片温度设定一个温度阈值超过阈值时主动降低负载或暂停推理任务让芯片有机会散热。提前主动降温比被温度墙强制降频体验上更好——前者只是任务变慢一点后者往往伴随着卡顿甚至掉帧。4. 常见问题与排查技巧实录4.1 温度不算高但推理还是慢检查功耗墙温度墙和功耗墙是两套机制。温度墙看结温功耗墙看芯片累计功耗。有些芯片为了控制整体发热会监测一段周期内的平均功耗如果平均功耗超过设定值即使当前温度不高也会限制频率。如果你观察到芯片温度在70℃上下、离温度墙还很远但推理性能下降了重点排查功耗墙策略。大多数端侧平台的功耗墙参数是隐藏的未必开放给开发者调节。你能做的是调整负载模式把连续推理任务改成间歇性任务给芯片留出“功耗预算恢复”的时间窗口。举个例子连续跑大模型对话会让功耗墙迅速触发但如果把用户请求处理改成“处理1秒、暂停0.5秒”的节奏功耗墙就不会那么容易被触发整体体验可能更跟手。4.2 同一台设备为什么外部环境变化影响这么大这是一种很常见的“薛定谔的性能”现象在空调房里跑得挺快的设备搬到没空调的房间就慢得离谱。原因就是散热系统中的热容和热阻在临界点附近工作。热容决定了设备能吸收多少热量而不升温热阻决定了热量从芯片传递到环境的效率。环境温度升高后热量的散发动力变小温差变小芯片温度更容易触及温度墙。这不仅仅是“夏天芯片更容易变热”这么简单而是环境温度变化让设备从“勉强支撑”滑向了“温度墙频繁触发”的区间。实操建议不要只看设备标称功耗来选型。如果设备TDP为15W但实际推理负载会冲到25W就在25W的基础上预留至少30%的散热余量来做选型不然大概率会遇到性能波动。边缘设备放的位置也很重要别塞进密闭弱电箱或者抽屉里让设备周边有空气流通温度表现会好非常多。4.3 双电源供电能解决端侧推理的供电瓶颈吗这个说法最近讨论度不低主要来自硬件DIY圈子给端侧设备配双电源一路供给主板一路单独供给外设避免外设的瞬态电流干扰主板供电。从原理上说是成立的外设单独供电确实能隔离一部分电气干扰。但用在端侧推理上要注意区分场景。如果你用的是一体化迷你主机内部供电方案是厂商设计好的你没有机会在中间插入双电源。外置双电源最多是把外部适配器分成两路一路给主机、一路给USB设备集线器或硬盘盒。这种情况下确实能稳定USB外设的供电减轻主适配器的电流负担。但如果瓶颈在主机内部供电电路的转换能力双电源帮不上忙。另一种情况是DIY的AIO设备比如用ITX主板加独立NPU加速卡组成的推理盒子两条独立的电源轨就很有价值——加速卡瞬时电流需求大和主板共用一路电源容易互相干扰拆成双路供电之后加速卡的电压稳定性明显提升推理性能波动也小一些。4.4 硬盘盒“独立供电”和推理变慢有什么关系这里把热搜里的硬盘盒话题顺带解释清楚。2.5寸和3.5寸硬盘盒对供电的要求差异巨大2.5寸机械硬盘和绝大多数2.5寸SSD功耗很低USB接口供电就够了3.5寸机械硬盘启动时瞬时电流很大轻松超过1A如果硬盘盒不带独立供电硬盘一启动就会把USB口电压拉低导致整个USB控制器电压不稳。对推理设备来说如果模型文件、数据缓存放在USB外接硬盘上硬盘每次读写都会造成USB控制器电压波动进而影响整个系统的电压稳定性推理任务就会出现间歇性卡顿甚至掉盘。这种情况下给硬盘盒加独立供电尤其3.5寸硬盘盒表面上是在修硬盘供电实际是在保护整机的供电稳定性也间接保护了推理性能的连贯性。我踩过一个具体的坑某台设备跑模型时总是每隔几分钟卡一次查了很久都没找到原因。最后发现根因是模型权重文件放在一个USB 3.0移动硬盘盒里硬盘盒没有独立供电每次读权重文件大块数据时USB电压就掉一截系统USB控制器报错重试推理线程就被卡一下。换成带独立供电的硬盘盒再也没出现过间歇卡顿。这类问题不看实测数据很难定位因为软件层往往没有明显报错信息。4.5 端侧推理中“轮流降频”是不是普遍现象很多多核SoC在设计时有一个不太被注意的机制当所有核心同时高负载运行时总功率超过设计值调度器会让核心轮流降频——不是所有核心一起降到同一个低频而是让一部分核心保持高频、另一部分核心降到低频过一段时间再交换角色。这样做的好处是单核心依然能维持峰值性能坏处是当多线程推理任务跑在多个核心上时每个核心的算力都受到限制。这对推理任务的影响很微妙。稠密的矩阵乘法算子受益于单线程高频率如果某个核心频繁被降频算子执行时间就拉长了。而多线程推理如果调度粒度太大线程分配到“正在降频”的核心上延迟就会出现跳跃性增长。调试这类问题的思路是用系统工具观察每个核心的实时频率如果存在明显的“轮流降频”尝试限制推理任务使用的核心数——比如8核芯片只绑定4个核心跑推理让这4个核心分配到更高的功耗预算剩余4个核心空载。实测下来限制核心数有时能让总吞吐更高因为避免了降频震荡带来的调度开销。4.6 快速排查速查表下面这个表格是我做端侧推理性能退化排查时经常对照的分享出来直接抄作业即可。现象优先怀疑项排查方法解决方向运行数分钟后逐渐变慢温度墙触发监控芯片结温观察降频是否与温度同步清灰、换硅脂、改善通风、加风扇刚插电跑得慢、电池跑得快充电与推理抢功率对比插电/电池两轮测试尝试关闭充电更换高功率适配器或限制充电电流80%电量以下明显变慢电池内阻升高检查电池健康度放大电流放电测试更换电池优先插电使用接入USB外设后间歇卡顿供电电压跌落拔掉外设对比测试观察USB控制器报错外设独立供电换优质线材多线程推理时延迟跳变核心轮流降频观察各核心实时频率曲线限定推理核心数调节线程池大小环境温度升高后性能剧烈下滑散热余量不足对比不同环境温度下的性能曲线加强散热降低功耗上限调整摆放位置任务负载不高也慢慢变慢供电转换效率劣化测量长期运行时的系统功耗和温度更换适配器检查电源管理固件5. 从根因出发的调优思路这些年做端侧推理优化的一个核心体会是大部分“越跑越慢”的问题根因不是软件写错了而是硬件物理层的瓶颈没有处理好。软件层能做的优化天花板很低——算子融合、量化、缓存命中率优化边际收益越来越小但物理层的调优空间往往很大——散热改善10℃、供电稳定几个百分点、功耗墙策略调整一下推理性能就能恢复一大截。如果你现在手头恰好有一台端侧推理设备性能表现不稳建议按这个流程走一遍先用固定负载脚本量化退化曲线同时采集温度和频率数据画出时间轴对照图然后从最简单的散热维护开始清灰、换硅脂、改善通风接着排查供电适配器规格、电池健康度、外设干扰最后再回到软件层调整功耗策略和线程调度。这轮走完大概率能找到问题所在并且比盲目优化模型代码要高效得多。端侧推理的物理瓶颈不会消失但理解了功耗、散热、供电之间的联动关系你至少能判断出问题出在哪一环节不再需要瞎猜。