芯片满载为何一会就降频？热点怎么别乱跑？

芯片满载后很快降频，未必说明散热器不够大，很多时候是热点位置和控制回路都在变。热从哪里冒出来、控制又按哪里判断，二者一错位，降频就会来得又早又乱。

热点迁移是多核SoC里最容易被低估的热问题。工作负载一旦在CPU、大缓存、NPU和媒体模块之间来回切换，最高功率密度点不会固定停在单个传感器附近，而会沿着供电岛、互连和局部热点相互牵引。某个时刻温度最高的是执行单元，几毫秒后可能变成共享缓存边缘或片上网络路由器。若热模型还是按静态功耗图估算，控制器看到的只是一个被平均过的温度面，真正最危险的局部峰值已经从传感器旁边滑走。先进封装里情况更复杂，堆叠存储、底部逻辑和封装散热路径不对称，导致垂直方向的热点迁移比平面方向更快。很多团队发现同样的总功耗下，不同业务组合触发降频的时刻差很多，根因不是软件调度玄学，而是热源分布改变了局部热阻，某些区域的结温爬升速度远快于平均结温。所以温度传感器布点不能只贴平均功耗最大的模块，应该覆盖最可能在任务迁移后成为新峰值的交界区和纵向热堆叠位置。少看这一层，控制器就会一直盯错地方。

DVFS回授迟滞会把本来可控的热波动放大成反复拉锯。温度传感器本身有量化和采样周期，固件决策也有滤波与迟滞带，等到控制器确认“该降频”时，热点往往已经冲过阈值；等它再决定升回去，热量却还留在硅里没散完。结果就是频率在几个档位之间来回摆，性能和功耗都不好看。若控制算法只盯单点温度，而不考虑功耗变化斜率和热扩散时间常数，门限调得再细也只能治表。更稳妥的做法是把DVFS分成预测和纠偏两层：前一层根据负载类型和功率上升速度预判热点将在哪一块形成，提前减小电压爬升；后一层再用真实温度闭环修正长期偏差。还要把任务迁移、功率门控和封装散热条件写进同一个控制模型，否则软件一迁核，热控算法就像换了地图继续开车。芯片不是因为温度高才降频得难看，而是因为热点在动、控制却还按静态位置和滞后节奏做决定。若算法没有把封装热惯性和风扇、均热板响应一起算进去，控制环看到的永远是过去几毫秒的温度，而不是下一毫秒的风险。热控越依赖慢信号，降频就越容易追着热点尾巴跑。热控参数如果只在单一跑分场景下整定，换一类业务后就会重新追错热点。会追热点的控制，才配谈性能释放；只追阈值的控制迟早会抖。

热管理真正要管的是热点的轨迹，而不是一条平均温度曲线。让传感器位置、功率分布和DVFS节奏彼此对上，降频才不会在满载时失去章法。