4、温度监控原理：理解温度传感器位置、读取方式（如sysfs、hwmon）、温度阈值设定和热管理策略

算能边缘设备（如SE5、SM5系列及基于BM1684/BM1688的板卡）在推理负载下，CPU、TPU（张量处理单元）、DDR和NVMe SSD是主要热源。温度监控不仅是防止硬件烧毁的底线，更是性能调优和寿命管理的关键依据。本章从传感器物理位置出发，深入解析Linux内核的hwmon/sysfs读取机制，并给出阈值设定与热管理策略的工程化方法。

4.1 温度传感器的物理布局与信号链路

算能边缘设备的温度监控体系是分层设计的。以典型的BM1684边缘计算盒为例，其热源分布具有明显的不对称性：TPU在运行ResNet-50批量推理时功耗可达15W-25W，而CPU（通常为ARM Cortex-A53或A72）功耗在5W-10W之间。因此，传感器布局必须覆盖以下关键位置：

• TPU芯片内部传感器：BM1684内置2-3个温度检测点（die温度），通过私有寄存器映射到内核hwmon驱动。该传感器响应最快，是判断算力负载是否过热的“第一道防线”。
• CPU热敏二极管：ARM SoC内部集成的温度传感器，通常通过Linux内核的cpufreq和thermal框架暴露。其读数反映CPU核心的实时温度，与主频和电压直接相关。
• 板载NTC热敏电阻：布置在DDR颗粒附近、NVMe SSD插槽旁以及散热器底座。NTC通过分压电路连接ADC，经i2c总线（如lm75驱动）读取。这类传感器反映的是“板级温度”，存在一定热滞后。
• 外壳/环境温度传感器：部分工业级设备在机箱进风口或出风口安装数字温度传感器（如TMP117），用于判断环境温度对散热效率的影响。

从信号链路看，温度数据流经路径为：物理传感器 → 模拟前端/数字接口（i2c/1-Wire/SPI） → 内核驱动 → hwmon子系统 → sysfs虚拟文件 → 用户态监控程序。理解这条链路对排障至关重要——当读取温度失败时，问题可能出在传感器硬件、总线通信、驱动加载或权限配置任一环节。

4.2 温度读取方式：sysfs与hwmon实战

在Linux系统中，所有温度传感器最终都通过hwmon子系统统一管理。用户态程序无需关心底层是i2c还是1-Wire，只需读取sysfs节点即可。以下是标准操作流程：

1. 枚举hwmon设备：执行ls /sys/class/hwmon/，系统会列出hwmon0、hwmon1等目录。每个目录对应一个注册的传感器驱动。
2. 识别传感器类型：查看/sys/class/hwmon/hwmonX/name文件，内容为驱动名称（如bm168x_thermal、lm75、coretemp）。
3. 读取温度值：温度文件命名规则为temp[1-9]_input，单位是毫摄氏度（m°C）。例如cat /sys/class/hwmon/hwmon1/temp1_input返回45000，表示45°C。
4. 查看阈值与告警：hwmon节点通常包含temp[1-9]_max（高温告警阈值）、temp[1-9]_crit（临界关机阈值）、temp[1-9]_alarm（告警标志）。

对于算能设备，还需关注/sys/class/thermal/thermal_zone*目录。这是内核thermal框架管理的“热区”，每个热区绑定一个或多个传感器，并关联冷却设备（cooling device）。典型读取命令如下：

# 查看所有热区及其当前温度
for zone in /sys/class/thermal/thermal_zone*/; do
    echo "$zone: $(cat $zone/type) = $(cat $zone/temp) m°C"
done

# 查看某个热区的阈值设定
cat /sys/class/thermal/thermal_zone0/trip_point_0_temp
cat /sys/class/thermal/thermal_zone0/trip_point_1_temp

需要特别注意的是，hwmon节点和thermal_zone节点可能指向同一物理传感器，但数值更新频率和滤波算法不同。hwmon通常提供原始读数，而thermal_zone可能经过内核的加权平均或去抖处理。在编写监控脚本时，建议统一使用thermal_zone作为数据源，因为其与内核热管理策略直接联动。

4.3 温度阈值设定与热管理策略

阈值设定不能“一刀切”，必须结合芯片规格、散热方案和工作环境。以BM1684为例，其芯片结温上限为105°C，但长期运行在90°C以上会显著加速电迁移效应，缩短寿命。因此，工程上推荐四级阈值体系：

• 正常区（<75°C）：全性能运行，无需干预。此区间风扇转速可维持在30%-50%以降低噪音。
• 预警区（75°C-85°C）：触发告警日志，风扇转速提升至70%，监控系统开始记录高频采样数据。
• 降频区（85°C-95°C）：内核thermal框架自动触发DVFS（动态电压频率调整），TPU频率从1.5GHz降至1.0GHz，CPU governor切换为powersave。此时推理延迟会增加约20%-30%。
• 临界区（>95°C）：触发紧急降频至最低档，同时向管理平台发送SNMP Trap或Webhook告警。若温度继续上升至100°C，硬件看门狗强制关机。

热管理策略的实现依赖内核的thermal框架配置。在设备树（device tree）或BIOS设置中，可以定义trip_point与cooling_device的映射关系。对于运行容器化推理服务的边缘设备，建议在应用层额外实现“软降级”策略：当检测到温度超过85°C时，主动将部分非关键任务迁移到CPU执行，或降低批处理大小（batch size），从而减少TPU热密度。

4.4 案例拆解：一次因温度误判导致的推理性能抖动

背景与约束：某智慧园区项目部署了20台SE5边缘盒子，运行24小时视频结构化分析。现场环境温度约35°C，设备安装在半封闭弱电井内。上线一周后，运维反馈部分设备出现周期性推理延迟飙升，从平均35ms波动至80ms。

初始现象与数据采集：通过Prometheus监控发现，延迟飙升与TPU温度曲线高度相关。当温度达到82°C时，延迟开始恶化。进一步检查/sys/class/thermal/thermal_zone0/trip_point_1_temp，发现其值为80000（即80°C）。这意味着内核在80°C时就触发了降频，而芯片规格允许105°C。

分析判断：问题根源在于默认阈值过于保守。设备出厂时设定的降频阈值80°C，是为通用场景设计的，未考虑该现场环境温度较高导致的基础温度偏高。实际上，TPU在85°C以下运行完全安全，且性能无衰减。过低的降频阈值导致设备在负载高峰时“过早”降频，引发性能抖动。

操作步骤：

1. 将降频阈值从80°C调整至88°C：echo 88000 > /sys/class/thermal/thermal_zone0/trip_point_1_temp。
2. 将临界关机阈值从95°C调整至100°C（确认散热器余量足够）。
3. 修改systemd服务/etc/systemd/system/thermal-threshold.service，在开机时自动应用上述设置。
4. 增加风扇转速曲线：在40°C时即启动风扇，60°C时转速提升至80%，避免温度快速爬升。

结果对比：调整后，TPU温度稳定在86°C-89°C区间，推理延迟恢复至35ms±5ms，且未出现硬件告警。设备在连续运行30天后，无热关机事件。

风险与复盘：该操作的风险在于，如果散热系统存在积灰或风扇故障，88°C的降频阈值可能不足以保护芯片。因此，必须同时部署“温度变化率”监控——若每分钟温升超过8°C，立即触发告警并强制降频。复盘结论：阈值设定必须结合现场环境温度、散热冗余度和负载特征进行“一站点一策略”调优，不能盲目套用出厂默认值。

4.5 总结与最佳实践

温度监控的本质是“感知-决策-执行”的闭环。感知层要确保传感器数据准确、无漂移；决策层要合理设定多级阈值，避免过于保守或激进；执行层要联动风扇、DVFS和任务调度。以下为关键复盘清单：

• 传感器校准：每半年对比一次hwmon读数与红外测温枪实测值，偏差超过±3°C时需检查导热硅脂或传感器焊接。
• 日志关联：将温度日志与推理延迟、功耗日志关联存储，便于事后分析性能抖动是否由热管理触发。
• 冗余设计：对于关键节点，建议同时监控TPU温度和进风口温度，两者温差超过15°C时提示散热风道堵塞。
• 自动化响应：编写脚本监听temp*_alarm文件变化，触发告警时自动抓取dmesg和sensors输出，形成排障快照。

最后，务必在运维手册中记录每台设备的阈值修改历史。温度监控不是“设置一次就永久生效”的静态配置，而是需要随季节变化、负载演进和硬件老化持续调优的动态工程。