在上一篇关于Mac Mini (M4 Pro)的文章里，我从几个方面较为全面地测试了M4 Pro运行LLM的现状。虽然大容量高位宽LPDDR统一内存的组合确实可以满足一些LLM场景的需求，但Apple GPU的一些弱点导致其相比市面上相同价位的方案较为尴尬。
本文我们的探讨对象是AMD的Strix Halo平台。它的参数与M4 Pro相似，那么它是否能避免Apple GPU的那些问题呢？正文开始之前先剧透结论：比M4 Pro少尴尬一些，但依然有点尴尬。
几个月前，我曾有机会测试Intel专为超轻薄笔记本打造的Lunar Lake处理器。尽管其独特的设计让它脱颖而出，但在绝对性能方面的弱势意味着它可能并不适合大多数用户的主流PC需求。
对于主流笔记本产品线来说，Intel推出了Arrow Lake H45作为Meteor Lake的继承者。本次，我将对Arrow Lake H45中的酷睿Ultra 7型号（255H）进行测试。
声明：本文仅为个人测试，测试使用的一切设备、工具等资产与本人所在公司/职位无关，也没有接受任何赞助。
简单举例讲一下Linux的调度器是如何顾此失彼，以及一些硬件厂商的贡献者和维护者不在乎feature是否真的工作，造成用户困扰的。
前阵子在测试Strix Point与Lunar Lake等平台的CPU时，我偶然发现本代处理器在核间延迟这一指标上的一些变化。众所周知同步与互斥是现代复杂多线程软件高度依赖的原语之一，对其进行性能优化也是多线程编程的一大难点。多核处理器在硬件层面高效率地设计并实现同步，在工程上也是一个不小的挑战。
事实上，同步延迟这一概念不仅是对于CPU，其对于GPU也是一个重要的指标。在理想世界里，GPU可以以极高的吞吐并行处理大量毫不相关的数据。但现实是随着GPU规模的不断扩大，在一部分例如Gaming的领域的GPU应用已经出现了非常严重的并行度瓶颈，小规模数据的计算之间互相依赖导致不同层级的交互延迟成为瓶颈。
与CPU核心相对应，在GPU上处于类似层级的结构是SM (NVIDIA) / CU (OpenCL | AMD GCN)等等，一些厂商如Intel和Apple也将其直接称为GPU核心。而家用GPU的SM/CU核心数量远远超过普通家用CPU (144/96 vs 24)，数据中心GPU更是如此(160/304 vs 32-128)，这意味着为这些处理器核心的缓存一致性互联设计也会更加具有挑战性。
本文以我手边可用的一些硬件，搭配ROCm/HIP编程环境讲解如何使用类似测试CPU的手段来测量GPU的跨核心同步延迟，并提供一些大致的数据参考。
继续阅读