本文介绍使用四块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集群工具的成熟度仍有待提升。
