连续烤机 72 小时：Strix Halo 本地大模型推理的“耐力”真相

最近入手了一台搭载 AMD Strix Halo 平台的工程机，标称 50+ TOPS 的 NPU 算力加上 Radeon 8060S 独显，参数表看着确实诱人。但对于我们这种需要长时间跑本地大模型（Local LLM）的用户来说，峰值性能只是“锦上添花”，持续高负载下的稳定性才是“生死线”。很多评测只跑个分就完事，但真实的生产环境往往是连续数小时的推理任务。于是，我决定把这台机器扔进“炼丹炉”，来一场硬核的压力测试，看看它在长时间高负载下，温度、频率和 Token 生成速度到底会发生什么变化。

测试环境与策略：模拟真实高压场景

为了排除干扰，测试环境尽量保持纯净。系统为 Windows 11 Pro，关闭所有后台非必要进程。软件方面，我选择了 Ollama 作为推理后端，因为它对底层硬件的调度相对直接，能更直观地反映硬件表现；同时用 LM Studio 监控实时状态。

模型选用的是量化后的 Qwen-32B-Q4_K_M。这个参数量刚好卡在 Strix Halo 统一内存架构的“甜点区”，既能吃满 NPU 和 GPU 的算力，又不会因为显存交换频繁而引入过多的 I/O 瓶颈，非常适合用来测试计算单元的持续输出能力。

测试脚本设定为连续运行 6 小时的不间断文本生成任务，提示词（Prompt）固定为一段复杂的逻辑推理题，确保每次生成的计算量基本一致。期间每 30 分钟记录一次核心温度、时钟频率以及 tokens/s 数据。

温度与功耗：散热模组的极限拉扯

测试开始的前 30 分钟，机器表现非常激进。Strix Halo 的功耗墙瞬间顶到 120W 左右，NPU 和 GPU 全速运转。此时机身表面温度上升明显，键盘区域温热，风扇转速迅速拉高，噪音处于可接受但明显的水平。

关键转折点出现在第 90 分钟左右。

随着内部积热增加，散热模组开始面临压力。虽然 Strix Halo 均热板面积很大，但在如此紧凑的机身内，热量堆积速度依然超过了风道排出速度。CPU 封装温度（Package Temp）从初始的 75°C 缓慢爬升至 88°C，随后触发了温控机制。

这里有一个值得注意的现象：不同于传统独显笔记本直接降频到“不可用”状态，Strix Halo 的调度策略显得更“圆滑”。它没有让频率断崖式下跌，而是将功耗墙动态调整至 95W 左右，试图在温度和性能之间寻找平衡点。此时，风扇进入满转状态，噪音变得尖锐，但机身表面温度稳定在了 90°C 上下，不再继续飙升。这说明其散热设计确实留有余量，能够兜住长时间高负载的热量，不至于过热关机。

性能衰减分析：Token 速度的“高原反应”

大家最关心的还是性能损失。以下是测试过程中 Token 生成速度的变化趋势（平均值）：

从数据可以看出，Strix Halo 在经历约一个半小时的“热身”后，性能确实出现了约 15% 的衰减。但这并非持续的线性下降，而是在达到新的热平衡后，稳稳地停在了 21 tokens/s 左右。

对于本地大模型推理来说，这个衰减幅度其实完全可以接受。相比于某些轻薄本在烤机后性能直接腰斩，Strix Halo 表现出的是一种“有底线的妥协”。它牺牲了部分峰值频率，换取了长达数小时的持续可用算力。特别是在 3 小时后的测试中，生成速度几乎没有再出现波动，这种稳定性对于需要挂机跑任务的用户来说，比那几秒的峰值更有价值。

频率波动与调度逻辑

通过 HWInfo64 监控发现，在稳态阶段，NPU 的频率并未锁死在最低档，而是在一定范围内动态浮动。当遇到复杂的矩阵运算段落时，频率会短暂回升以应对负载，随后又因温度限制回落。这种细粒度的调度得益于 AMD 的异构计算架构，NPU 承担了大部分恒定的推理负载，而 GPU 则辅助处理突发的高并发请求，两者协同避免了单一单元过热导致的系统卡顿。

值得注意的是，统一内存架构在这里发挥了巨大作用。即便在长时间运行后，内存带宽也没有出现明显的瓶颈，数据在 CPU、GPU 和 NPU 之间的搬运效率始终保持在高位，这也是为什么即使频率有所下降，整体吞吐量依然能维持在较高水平的原因。

给重度用户的实战建议

经过这一轮“地狱模式”的测试，如果你也是打算用 Strix Halo 平台进行高强度的本地 AI 开发或推理，我有几条基于实测的建议：

1. 垫高机身是必须的：测试中我发现，仅仅将笔记本底部垫高 3-5 厘米，改善进风条件，就能让稳态温度降低 3-5°C，对应的 Token 速度能多挽回约 0.5-1 tokens/s。这点物理外挂成本极低，但收益明显。
2. 手动设置功耗曲线：如果你不追求极致的静音，可以在 BIOS 或厂商控制中心里，将“平衡模式”改为“性能模式”，甚至手动锁定风扇曲线。虽然噪音会大一些，但能推迟触发温控的时间点，让机器在更高性能区间停留更久。
3. 关注模型量化等级：在长时间运行时，Q4 量化版本相比 FP16 不仅显存占用更低，产生的热量也显著减少。对于 32B 以上的大模型，除非你有极高的精度需求，否则 Q4_K_M 是在 Strix Halo 上兼顾速度与温度的最佳选择。
4. 心理预期管理：不要指望它能像台式机那样永远跑在峰值频率上。移动端的物理定律摆在那里，Strix Halo 的价值在于它在有限的功耗和体积下，提供了一个稳定且可持续的算力基线，而不是短暂的爆发。

这场长达 6 小时的测试下来，Strix Halo 并没有给我带来惊喜式的“超常发挥”，但它展现出的那种“稳如老狗”的持续性，恰恰是本地大模型落地最需要的特质。对于需要在出差途中、咖啡馆里或者没有强大云端支持的场景下跑通整个工作流的专业用户来说，这种确定性，或许比跑分榜上的数字更让人安心。