边缘计算热失速常从热阻开始

很多端侧设备实验室里跑得很顺，装进机柜或路侧箱体后却开始忽快忽慢。边缘计算一旦遇到热失速，根因往往不是标称算力不够，而是散热路径里的热阻被低估了。

热降频通常不是突然发生，而是被峰值负载一点点推出来。模型推理、视频编码、加密传输和本地压缩若在同一窗口叠加，芯片结温会在几秒内抬高；控制器为了保保护件会先降频，再限制加速器占空比。平均吞吐看似还能接受，尾延迟却先被拉长，因为最热时刻恰好也是业务最忙的时刻。实验室里只跑单模型，往往测不到这种叠加负载。

散热路径上的每一级热阻都会把结温推高。芯片到封装、封装到导热垫、导热垫到散热片、散热片到空气，只要其中一环接触不平、材料老化或装配压力不足，热量就出不去。更麻烦的是，很多节点温度传感器并不贴近最热单元，显示出来的板温还算温和，结温却已经逼近阈值。于是系统看上去只是偶发变慢，实际上热保护早已介入。

外壳和风道会把这种误判放大。路侧箱、工业机柜或无风扇封闭壳体常把热量困在局部腔体里，进风口虽有凉气，热点附近却形成回流短路。若风扇位置只照顾整机平均温度，不照顾加速器和 PMIC 热源，温控策略会一直根据错误位置调速。最后不是所有元件都热，而是某个关键芯片先达到保护点。

导热界面材料的老化也不能忽略。导热垫压缩永久变形后，初期装机合格并不代表半年后仍保持同样热阻；硅脂泵出现象、灰尘覆盖鳍片、机柜滤网堵塞，都会让散热曲线慢慢变差。现场最棘手的是这种退化不一定触发硬故障，只会让节点在夏季高温或连续高负载时开始间歇性掉速。

温控算法本身也可能加剧抖动。若风扇调速阈值设得太窄，系统会在两个温度点之间频繁来回，导致风扇噪声和功耗上升，结温却没有真正稳定。更稳的办法，是结合负载预测和温升斜率提前拉风，而不是等温度探头越线再急刹。对无风扇设备，则应把任务错峰和峰值占空控制纳入热设计，而不是只看外壳摸上去是否烫手。

热问题排查要做空间化观测。单个 CPU 温度或板卡平均温度解释不了局部热点，至少要把结温、板边温度、进出风温差和降频次数关联起来看。若吞吐下降总和某一温区同时出现，说明真正的限制不在软件调度，而在热通路。把降频事件和业务延迟对齐，团队才能把“系统慢”翻译成“热阻大在哪”。

还要把 PMIC、存储颗粒和加速器周边供电级一并纳入热图，因为真正先限流的有时并不是主芯片，而是被热点带偏的供电环节。

扩算力之前，先确认机柜、供电和风道是否支撑得住。很多项目上更大芯片后，单节点峰值性能确实上去，却因为散热不足导致长期可持续性能更低。热设计的目标不是让设备短时跑分高，而是让最坏环境下仍能维持可预测吞吐。

只要热阻链条没被测清，性能上限就只是纸面参数。把热点位置、导热界面和降频门限一起管住，边缘计算的实时输出才不会被温度悄悄改写。