直接检查内核日志中热节流痕迹，结合温度读数与频率变化交叉验证：运行dmesg命令筛查throttle、thermal等关键词，用sensors和turbostat观察实时温度及therm/prochot状态，区分硬件热节流与软件限频，并通过时间线对齐日志与硬件行为确认因果关系。

直接看内核日志里有没有热节流（thermal throttling）的明确痕迹，再结合温度读数和频率变化交叉验证。

查 dmesg 里的热节流关键词

降频发生时，内核通常会记录警告或错误。运行以下命令快速筛查：

• dmesg | grep -i "throttle\|thermal\|prochot\|tjmax" —— 查找热节流、PROCHOT信号、温度阈值（Tjmax）相关日志
• dmesg | grep -E "(CPU|core).*[0-9]+\.?[0-9]*C" —— 匹配含温度数值的日志行（部分驱动会直接打印）
• dmesg -T | grep -A2 -B2 "throttled" —— 带时间戳，上下文更完整，便于定位触发时刻

确认是否真有温度墙触发

仅靠日志还不够，得看实时温度和节流状态是否同步：

Linux Ai Server

Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。

下载

• 先装传感器工具：sudo apt install lm-sensors && sudo sensors-detect（按提示完成初始化）
• 运行 sensors 查当前各核心温度，重点关注是否接近 Tjmax（通常 95–105℃）
• 用 turbostat --debug 观察 THERM 和 PROCHOT 字段：若频繁显示 “YES”，说明硬件层已发出节流信号
• 对比 cat /proc/cpuinfo | grep "cpu MHz" 或 cpupower frequency-info，看实际运行频率是否明显低于标称最大值

区分软件限频与硬件热节流

有些降频是系统策略导致的，不是温度问题：

• 检查当前 governor：cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor，若为 powersave 或 ondemand，可能主动降频
• 查节能 BIOS 设置：重启进 BIOS，确认 “Intel SpeedStep” / “AMD Cool’n’Quiet” 是否启用；某些主板在 “EC Firmware” 或 “Fan Profile” 中强制开启温控策略
• 排除 NMI watchdog 干扰：cat /proc/sys/kernel/nmi_watchdog，值为 1 时可能误报高 CPU 占用，临时关闭测试：echo 0 > /proc/sys/kernel/nmi_watchdog

关联日志与硬件行为的时间线

把几个关键信号对齐，才能确认因果关系：

• 用 dmesg -T 获取带本地时间的日志，记下疑似节流发生的时刻
• 同一时间点运行 sensors 和 turbostat -l 1 -n 5（每秒采样5次），看温度和 THERM/PROCHOT 是否同步跳变
• 如果 dmesg 出现 “acpi_thermal_rel: thermal zone is hot” 或 “acpi processor: throttling enabled” 类似条目，基本可锁定是 ACPI 层热策略生效