AMD Ryzen AI Max+ 395四机并联：大语言模型集群推理深度测试

本文是介绍使用四块Framework主板构建AI推理集群的完整过程，并对其在大语言模型推理任务中的性能表现进行了系统性评估。该集群基于AMD Ryzen AI Max+ 395处理器，采用mini ITX规格设计，可部署在10英寸标准机架中。

Jeff Geerling大佬还开发了名为Beowulf AI Cluster的自动化部署工具集，该工具集基于Ansible平台，可实现在beowulf集群架构上快速部署多种开源AI集群工具，支持CPU、GPU以及混合推理配置。

因为我只关心Max+ 395的性能测试部分（尤其是并行测试部分），所以本篇文章有删改，想看原文的请看最后的Jeff Geerling大佬博客

系统硬件配置

本次评估的硬件配置采用了Framework提供的完整解决方案。每个计算节点包含Framework主板、专用电源模块、Noctua CPU散热器以及1TB WD NVMe固态硬盘。

Framework主板在设计上更接近于单板计算机（SBC）架构，而非传统的插槽式CPU和内存桌面主板设计。该主板采用焊接式APU设计，集成了CPU、NPU（神经处理单元）和iGPU（集成图形处理器）以及系统内存。根据Framework的技术说明，采用焊接式设计而非可更换内存模块（如CAMM标准）的主要原因是为了确保内存时序的精确控制，从而在AI工作负载中实现最优性能表现。

集群基础性能测试

系统组装完成后，进行了全面的性能评估测试。完整的测试数据已在GitHub相关仓库中详细记录，包括Framework Desktop的sbc-reviews完整数据、top500 HPL基准测试结果以及Ollama和LLM基准测试结果。

在环境特性方面，该集群系统表现出优异的静音性能。配备Noctua CPU散热套件的情况下，系统噪音控制在46dBa以下。主板预装的散热器采用相变热界面材料技术，确保从APU裸芯到散热器的高效热传导。散热风扇支持智能调速，在系统空闲时可完全停转。

在功耗特性方面，单个计算节点的功耗表现如下：睡眠状态约2W，空闲状态约11W，满负荷运行时约150W。系统在高负载初期会短暂进入更高的turbo boost频率状态，但在持续满负荷基准测试中会稳定在145-155W功耗范围内。所有功耗测量均在交流电源端进行，测试环境运行Fedora 42操作系统（部分测试使用Fedora Rawhide开发版本）。

网络连接性能测试显示，虽然系统配备Thunderbolt/USB4端口，但实际测试中仅能达到10 Gbps的传输速率。内置以太网控制器支持5 Gbps传输速率，在实际测试中能够稳定达到标称速度。未来通过驱动程序优化或Linux系统调整，有望将Thunderbolt节点间连接速度提升至15-20 Gbps。

在通用计算性能方面，单个计算节点表现出色。运行pts/build-linux-kernel基准测试，单节点能够在不到一分钟的时间内完成Linux内核编译任务。

四节点集群配置下，即使未进行针对Ryzen AI Max+芯片特性的专门优化，运行top500-benchmark测试仍能实现超过1 TFLOP的FP64浮点计算性能。

在能效比方面，虽然CPU效率表现良好，但与Apple M系列芯片仍存在显著差距。在FP64计算能效比方面，其表现与Raspberry Pi 5相当。

GPU加速AI推理性能评估

这是我比较关心的问题，因为毕竟我们买这个都是为了做本地的LLM推理，之所以翻译这篇文章的主要原因是大佬已经调通了并行推理，也就是说我们可以用几台主机横向扩展，这样可以加载更大的模型。

测试过程中发现，部分硬件功能（如内置NPU）仍无法正常工作。虽然AMD在评测期间发布了一些NPU测试示例，但由于时间限制，未能完成完整的验证测试。基于这一现状，建议用户在选购时应基于当前已验证可用的功能进行评估，而非基于未来承诺或规格说明中的潜在功能。

在软件兼容性方面，初期在Fedora 42系统上配置ROCm与Ollama的集成遇到了一些技术障碍。最终通过升级至Fedora Rawhide版本解决了ROCm的兼容性问题，使得Ollama能够正常运行，但其性能表现仍不如直接使用llama.cpp。

单节点配置下，系统能够很好地支持CPU或iGPU推理模式，可选择Vulkan或ROCm作为底层加速框架。性能测试结果显示：

对于集成显卡而言（在完全未使用NPU的情况下），测试获得了令人满意的性能数据。在能效比方面，虽然未能达到Apple芯片的水平，但在AMD消费级芯片中表现最佳。

集群测试阶段为避免网络配置问题的干扰，选择使用内置网络控制器，并配备了NICGIGA 5 Gbps 8端口交换机。这是目前市场上为数不多能够在单一设备中提供多个5 Gbps RJ45端口的网络交换解决方案。

使用Beowulf AI Cluster项目框架，对Exo、llama.cpp RPC和dllama等多种集群工具进行了系统性测试。测试结果显示，Exo项目似乎缺乏持续维护，在Strix Halo支持方面存在长期未解决的问题，最终放弃了该工具的深入测试。llama.cpp RPC在处理小型模型时表现良好，但在大型模型上会采用轮询调度模式，而在处理超大型模型（如DeepSeek R1 Q4_K_M）时会出现段错误异常（相关问题已在GitHub issue中报告）。distributed-llama在支持的模型范围内（包括Llama 3.1 405B）能够在集群环境中稳定运行，但Vulkan支持存在不稳定性，推理过程可能出现异常（如单词无限循环重复），且目前支持的模型种类较为有限。

综合测试结果表明，目前尚无完美的开源AI集群解决方案。

llama.cpp的RPC模式被认为是最具发展潜力的方案。在超大型LLM的轮询调度问题演示中，通过nvtop工具监控GPU使用情况，可以观察到主节点依次将计算任务分配给各个从节点的过程：

理想情况下，llama.cpp应能实现类似HPL在FP64数学计算中的并行化工作负载分配，但这涉及复杂的技术实现挑战。正是由于这些技术难题，RPC功能目前仍被标记为实验性质。

虽然技术社区经常讨论通过组合多台迷你PC构建AI集群的可行性，但实际实施过程远比理论分析复杂。除了网络带宽相对于内存访问速度的巨大劣势外，现有AI集群工具的成熟度仍有待提升。

成本效益分析

从经济角度分析，不包括DeskPi机架、托盘、网络交换机和布线成本，本次测试的集群配置总成本约为8,004美元。

与其他大语言模型推理解决方案的性能成本比较如下：

此前测试的AmpereOne服务器仅使用CPU即可达到4 tokens/s的推理速度，该服务器的采购成本约为12,000美元。

配备512GB内存的M3 Ultra Mac Studio售价接近10,000美元，但其性能表现显著优于测试集群，可达到16 tokens/s的推理速度。

需要说明的是，上述性能比较中Framework集群的0.7 t/s数据基于Llama 3.1 405B模型测试，而其他系统的数据基于DeepSeek R1 671B模型（均采用Q4量化），因此这一比较并非完全等价。

在DeepSeek R1 Q2_K_M模型的集群测试中，使用Vulkan加速框架获得了以下性能数据：

针对ChatGPT新发布的开源模型，在单节点配置下的测试结果如下：

gpt-oss-20b模型测试结果：

gpt-oss-120b模型测试结果：

在集群模式下运行相同模型时，tg128推理性能下降至24 tokens/s

测试结果表明，采用当前最先进的开源AI集群工具进行多机推理时，其性能表现始终不如单机大内存配置。在构建AI推理系统时，应优先考虑垂直扩展策略。集群化部署虽然理论上具有吸引力，但在AI应用场景中面临额外的技术挑战。

虽然开源AI集群工具未来可能达到与其他高性能计算工具相当的成熟度，但在当前技术水平下，要获得更优的集群性能，仍需要专用硬件、高速互连以及大量的系统优化工作。

总结

AI集群技术虽然具有技术价值，但距离主流应用仍有相当距离。Deepseek的671B能抛出26t/s的速度如果自用的话是可以达到忍受的最低限度的。但是我个人感觉395最大问题还是价格，rdna3的魔改rdna3.5，对于游戏向肯定没人买，作为AI产品，内存给的带宽又太少了，而且抠搜的只有96G的显存。这导致大模型推理还是需要并行，但是目前来看AMD的生态还是太弱了，并行智能靠RPC,并且Jeff 大佬的测试中还会出现错误一点都不稳定，这也导致395算是一个鸡肋。不过归根到底还是价格问题，现在价格是13999也就是1万4，其实有这时间折腾RPC并行，我不如买8个V100，虽然硬件麻烦一些，但是只要硬件没毛病，软件直接上手就用了。所以等等党们不要着急，如果这玩意能降到10999，没准那时候并行的方案就稳定了，那就是真香，哈。

我只截取了我感兴趣的部分，大佬原文：

https://avoid.overfit.cn/post/6e2057cb902b4033b3d6cd712f2a8c62