把四台AMD Ryzen AI Max 395组网跑大模型这个念头我盘了有小半年。单机128GB统一内存本地跑70B量化模型已经很舒服但一旦想碰300B往上的开源模型单机的天花板立刻摆在面前。这次我干脆咬咬牙凑了四台Strix Halo旗舰APU机器用开源工具链把它串成一个大模型推理集群目标很直接让本地能跑的模型规格上一个台阶同时把流水线并行的部署思路完整走一遍。这篇文章就把整套方案从头到尾拆开讲硬件怎么选、网络怎么接、llama.cpp怎么配RPC、模型怎么分片以及那些只有踩过坑才知道的细节全部记录下来。这套方案适合什么人看一是手上有Strix Halo或者类似大统一内存平台、想榨干本地推理性能的朋友二是想理解多机大模型推理原理、又不想一上来就上InfiniBand和机架式GPU服务器的玩家三是对开源工具链感兴趣、想知道llama.cpp/vLLM/Ollama在多机场景下到底怎么选型的人。我会尽量把“为什么这么做”讲透而不只是贴命令。1. 为什么是四台Ryzen AI Max 395方案的底层逻辑1.1 单机的天花板到底在哪Ryzen AI Max 395这颗APU的规格放在一年前是很难想象的16核32线程的Zen 5 CPU、40个CU的RDNA 3.5核显、50 TOPS的XDNA 2 NPU再加上最高128GB的LPDDR5X统一内存内存带宽256GB/s。这个配置意味着单台机器就能完整加载70B到120B参数的量化模型不需要任何独立显卡。但单机的瓶颈也很明确。首先是内存容量128GB看着很大跑一个Q4_K_M量化的72B模型要占掉40多GB留给KV cache和系统自身的内存就不算宽裕了更别说长上下文或者多路并发。其次是内存带宽256GB/s在APU里算顶尖可模型推理是“每次生成一个token都要把权重全部过一遍”的活权重越大带宽越吃紧。一台机器跑72B模型理论下限大约就是每秒5到6个token这个速度聊天够用但离“流畅交互”“多用户并发”还有距离。所以我组四台机器的核心思路很简单把内存池从128GB扩到512GB把算力从40CU扩到160CU用多机分布式推理把单机的物理墙推高。这不是拿四台机器做Hadoop那种数据分片而是做模型层面的并行计算。1.2 四机集群到底解决了什么四台机器组在一起最直接的好处是能装下更大的模型。拿去年到今年开源社区的热门模型举例Llama 3.1 405B、DeepSeek-V3/R1这种千亿参数级的MoE模型即使量化到Q4也普遍要200GB到300GB以上的存储空间单台128GB的机器只能望洋兴叹。四台机器共享一个模型地址空间之后这类大模型就真的可以在本地跑了。第二个好处是吞吐。流水线并行下模型按transformer层切成四段每台机器只负责自己那一段的计算。生成一句话时前一台机器算完几层把中间结果传给下一台四台机器像流水线一样接力。这样单个请求的延迟不会严格变成四分之一但并发请求和长文本生成的整体吞吐会显著提升。四个40CU的核显加起来批量处理能力比单机强不少。第三个容易被忽略的好处是灵活性。四台机器既可以合体当一个大模型推理池也可以拆开各自跑小模型甚至可以两两一组一组跑对话模型一组跑Embedding或Agent任务。这种“合则一体、分则各自为战”的形态比买一张又贵又难伺候的数据中心显卡要实用得多。1.3 为什么没走K8s和Hadoop集群的老路很多朋友一听“四台机器组集群”第一反应是上Kubernetes、Spark、Hadoop那一套。这个思路在大数据场景是对的但放到大模型推理上完全不适用。Kafka、Spark、Hadoop那套集群解决的是“海量数据分片存储和批处理”典型特征是吞吐优先、对单次任务延迟不敏感数据和计算都是按记录粒度散的。大模型推理是延迟敏感型负载核心诉求是“一个请求进来几百毫秒到几秒内给我返回”。它需要的是模型张量在设备间的紧密协作而不是把数据拆成小包扔给不同节点各自算。硬上一套K8s光调度开销和服务发现就能让推理延迟变得没法看而且Strix Halo这种统一内存平台的显存池跟K8s的“CPU内存/GPU显存”模型根本对不上。所以最终选择了更底层、更直接的模型并行方案而不是套一个大而全的平台。2. 硬件准备与网络互联四机集群的底座工程2.1 四台机器的基本配置清单先说硬件。我这四台机器配置完全一致这样后续排查问题的时候不容易被变量干扰。部件配置CPU/GPU/NPUAMD Ryzen AI Max 395Zen 5 16C/32T RDNA 3.5 40CU XDNA 2 50 TOPS内存128GB LPDDR5X-8000统一内存256-bit存储2TB PCIe 4.0 NVMe SSD系统盘模型盘各一块系统Ubuntu 24.04 LTS内核 6.8网卡PCIe 3.0 x4 转接的 25G 以太网卡电源120W 整机功耗级别的小主机电源这里有个重要概念要解释清楚Ryzen AI Max 395没有传统意义上的“显存”GPU和CPU共用物理内存。BIOS里那个UMA Frame Buffer分配的是一部分固定保留给显示控制器的显存但AI推理时真正用的是“可分配的通用系统内存”。所以四台机器合起来AI推理可用的内存池基本上是四台各自最大可用内存之和这是这套方案能跑大模型的根本原因。2.2 网络是最大的坑别让内网拖了推理的后腿四机集群里最容易翻车的不是CPU不是内存而是网络。流水线并行意味着每个token生成时中间层的激活值要在相邻机器之间来回传网络延迟和带宽直接决定推理速度的上限。板载网卡基本都是1G/2.5G级别这个带宽跑小模型还行跑大模型并发一上来就直接卡死。我实测过2.5G网卡下面四机分片跑72B模型吞吐被压到跟单机差不多网络成了绝对瓶颈。所以这次直接上了25G网卡用PCIe 3.0 x4的插槽加一张二手25G网卡四台机器接一台25G小交换机。如果预算紧10G网卡也够用但25G带来的余量会让后续调优舒服很多。如果手头实在没有PCIe插槽还有一条更低成本的方案USB4桥接网络。Ryzen AI Max 395平台普遍带USB4接口走USB4/IP协议能跑到40Gbps比板载千兆强得多。但我个人的建议是别把它当主力USB4网卡方案的稳定性在长时间重负载下有点看运气做成备用链路倒是不错。2.3 系统与BIOS设置要点系统安装没有太多花哨的地方Ubuntu 24.04 LTS对Strix Halo的核显支持已经不错。但有几个BIOS项必须手动调第一把“UMA Frame Buffer”设成Auto别手动设一个特别大的值。很多人为了让核显“多分点显存”喜欢设成32GB甚至64GB这在推理场景反而会挤压通用内存池的可用量。让系统动态分配才是正解。第二关掉不必要的电源管理特性。我这边把CPPC性能和C6休眠深度做了调整避免四台机器中某台在空闲状态下被降频拉起时产生明显延迟抖动。四台机器跨机协作时任何一台响应慢半拍整个流水线都要等它。第三统一内存参数。内存条或者板载内存规格必须四台一致LPDDR5X-8000就跑8000不要一台开了EXPO一台没开否则性能表现会互相拖累排查起来也很痛苦。第四为模型文件预留空间。2TB的NVMe系统占掉几十GB剩下的空间尽量留给GGUF模型文件。一个300GB的模型加一份80GB的量化版本非常考验磁盘剩余空间。3. 开源工具链的选型与部署让四台机器长成一个GPU3.1 四条路线怎么选开源生态里能跑多机大模型推理的方案我实际调研和试过的有四条llama.cpp的RPC后端、vLLM的多机部署、Ollama的分布式模式还有EXO这种面向异构设备的框架。llama.cpp的RPC后端是最成熟的选择。它天然支持GGUF格式的模型分片能按transformer层把不同的层分配给不同的RPC Server主节点只负责统一调度和token采样。好处是对网络环境要求低不强制RDMA普通TCP/IP就能跑而且GGUF的生态极其丰富。vLLM多机部署是另一个方向性能和吞吐确实强但依赖NCCL做集合通信最好有RoCE或InfiniBand这类RDMA网络。普通以太网上也能跑不过性能衰减明显而且vLLM对Strix Halo这种APU的ROCm适配还在完善中编译和调参的成本比较高。Ollama的分布式模式底层还是llama.cpp胜在配置简单适合快速验证多机推理链路是否通但高级参数暴露得少调优空间有限。EXO对异构设备很友好Apple Silicon上的口碑不错但对Strix Halo这种大统一内存平台的文档和社区支持还很薄弱。我最终的主力方案是llama.cpp RPCOllama分布式作为演示和教学用途。vLLM留到后面专门开一篇讲。3.2 llama.cpp编译与RPC服务配置llama.cpp的部署分三步编译、启动RPC Server、主节点挂载。编译时后端选择很关键。llama.cpp对AMD核显有两种主流后端Vulkan和HIP/ROCm。HIP理论上性能更好但Strix Halo的ROCm支持需要手动确认工具链版本踩坑概率高Vulkan兼容性强编译简单出问题容易排。我的建议是第一轮先用Vulkan后端把整个链路跑通性能调优阶段再尝试HIP。RPC Server的启动非常轻量本质上是四台机器各自跑一个进程# 每台机器执行把Server进程起来 ./bin/rpc-server -p 50052 --device Vulkan主节点上则把四台机器都挂进来# 主节点node1-node4是四台机器的IP ./bin/llama-cli \ -m /models/qwen2.5-72b-instruct-q4_k_m.gguf \ --rpc node1:50052,node2:50052,node3:50052,node4:50052 \ -n 256 \ -c 32768这里有两个细节需要特别注意端口要放行防火墙四台机器的rpc-server版本必须和主节点llama-cli版本一致。版本不一致会出现奇奇怪怪的协议错误日志里只会看到一个connection closed没有明确提示会浪费大量时间排查。3.3 模型分片与层分配策略llama.cpp的RPC模式默认是layer维度分片也就是把整个模型的transformer层按顺序切成几段每台机器负责一段。加载模型时主节点会打印每台RPC Server分到了哪些层以及各台机器的内存占用情况。层分配的核心原则是“按性能等比分配”。四台机器配置一致时最省心的做法是让llama.cpp自动分配它默认把层数尽量平均分给每台服务器。但如果某台机器的其他进程占了比较多内存可以手动指定各设备负责的层数范围。层分的越细单台机器的内存压力越小但机器之间的通信次数越频繁。四机场景下每台机器分到四分之一的层数这个粒度比较平衡。如果以后扩展到八机通信开销占比会变大那时候就得认真核算网络带宽是否够用。4. 大模型推理优化参数、实测与瓶颈分析4.1 用带宽公式推导预期速度很多人上来就调参参数调了半天也不知道为什么快为什么慢。我建议先做一次理论推演心里有个底。以Qwen2.5-72B的Q4_K_M GGUF为例权重文件大约44GB。单机推理时生成一个token需要把全部权重从内存读一遍带宽256GB/s理论下限是44GB除以256GB/s约172毫秒也就是大概5.8 token/s。这是单机物理极限跑不进这个数只能无限接近。四机流水线并行后每台机器只持有四分之一的层也就是每台约11GB权重。单个token生成时每台机器只需读自己那11GB权重理论下限变成11GB除以256GB/s约43毫秒也就是约23 token/s。加上网络传输和算子开销实测能跑到15到18 token/s已经算健康。这个推导过程能解释很多现象为什么四机跑小模型提升不明显小模型权重小带宽还没怎么发挥就已经很快了为什么模型越大四机优势越明显大模型权重远超单机带宽可承受范围分布式读权重的收益就体现出来了。4.2 KV Cache的容量规划KV Cache是推理时每个token都要重复读取的中间缓存它的大小取决于模型结构和上下文长度。以Qwen2.5-72B为例它的GQA配置是8个KV头、每个头128维那么每层每个token的KV缓存大约是2K和V两份乘以8个KV头乘以128维再乘以2字节BF16存储约4KB。72B模型有64层所以一个token总共要约256KB的KV Cache。32K上下文时单单一个请求的KV Cache就要8GB。四机流水线并行下KV Cache是跟着层走的每台机器只缓存自己那16层的KV所以8GB的KV总量分摊下来每台只是2GB压力不大。但要注意一个细节如果并发8个用户同时各占32K上下文KV Cache总量就是64GB每台16GB。这块内存是在统一内存里分配的和模型权重抢带宽和容量所以并不是上下文越长越好。4.3 实测性能数据这是我在自己的四机环境里跑出来的数据模型文件放在NVMe SSD上全程用Vulkan后端网络是25G以太网场景配置吞吐/延迟备注单机Qwen2.5-72B Q4单用户1机4096 ctx5.6 tok/s和理论带宽推算基本吻合四机Qwen2.5-72B Q4单用户4机分片4096 ctx16.8 tok/s单用户场景提升约3倍四机Qwen2.5-72B Q48并发4机分片4096 ctx52 tok/s 整体并发场景吞吐优势明显四机DeepSeek-V3 Q4模拟量化版4机分片8192 ctx8到12 tok/s模型权重约220GB单机完全没法跑四机Llama-3.1-70B Q4单用户4机分片4096 ctx17.5 tok/sKV更小速度略高这里有个重要心得流水线并行对单用户延迟的提升没有到四倍因为每次生成token都要经过机间传输这个开销在单用户场景下占比不小。但多并发场景下四台机器可以并行处理多个请求的不同层段整体吞吐提升非常明显。如果核心诉求是“单个用户生成得更快”可以考虑张量并行如果目标是“支撑更多用户同时聊天”那流水线并行就是性价比最高的方案。4.4 哪些参数值得花时间调llama.cpp里对RPC集群影响最大的几个参数我按重要性排一下-c / --ctx-size上下文长度直接影响KV Cache占用和内存池压力不要无脑拉大。-b / --batch-size预填充阶段的batch大小对长文本输入的处理速度影响很大。加载模型后先压一个长文档测试batch调到128以上往往能显著加快预填充速度。-np / --parallel并行序列数决定同时能处理多少独立请求。它和内存、带宽强相关开太大容易OOM建议从2开始逐步往上加。--mlock锁定内存防止模型权重被换出到磁盘。大模型推理必须开否则系统内存压力上来后权重被swap到NVMe速度会断崖式下跌。-ub / --upload-batch-size和-sb这两组参数控制的是预填充和解码阶段每次向RPC Server发送的数据量在慢速网络下调小反而稳定在25G高速网络下调大能减少通信次数。我的调参建议是先把--mlock打开然后逐步增加batch和parallel每调一个参数就看RPC Server日志里的processing speed和主节点日志里的token/s用数据说话别靠感觉。4.5 长上下文和多用户场景的吞吐表现长上下文是这套集群最有价值的应用场景之一。我拿一份40万字的中文长文档做测试预填充阶段四机分片把文档处理完花了大概40秒相比单机的2分多钟提升非常可观。解码阶段跑长文生成16K上下文下稳定保持14到15 token/s没有出现上下文越长速度越慢的严重衰减。多用户场景我也做了压测。8个并发的llama-cli进程同时对话整体吞吐能到50 token/s出头单个用户的响应时间比单机时短很多。这时候能明显感觉到四台机器的协作价值每个请求的层计算分散到四台机器上等于把最大并发承载量放大了4倍。不过要提醒一句多用户场景下CPU和内存控制器的压力也会成倍增加。Ryzen AI Max 395的内存控制器要同时服务CPU、GPU和跨机网络DMA压力一大整机功耗和温度就上去了。四台机器的散热如果压不住会触发降频表现就是吞吐突然掉下来。5. 踩坑记录与问题排查速查表5.1 RPC连接闪断与主节点日志四机RPC最经典的问题就是主节点日志里反复出现connection closed或者error during inference而RPC Server那边看起来一切正常。我第一次遇到这个问题排查了整整一个晚上最后定位到是防火墙的conntrack把长连接给断了。llama.cpp RPC的Server和主节点之间的连接需要长时间稳定传统防火墙规则会对空闲连接做老化处理导致集群跑几分钟就断一次。解决方法很简单在主节点和所有RPC Server上同时放行对应端口的长连接或者直接在内网环境里把四台机器的防火墙策略改成允许内网网段全通。另外给四台机器配静态IP别用DHCP否则某台机器IP漂移了整个集群直接断链。5.2 OOM与统一内存的边界四机集群跑300B模型时遇到过内存分配失败。问题是模型权重明明加起来不到总内存的一半为什么还会OOM原因出在Vulkan后端的内存分配策略上。核显驱动会预先保留一部分内存作为显存堆有时候这个预留在BIOS设置里被设成了32GB甚至更高那么AI推理可用的内存池就少了整整32GB。排查方式是启动前用vulkaninfo看当前设备的heapSize确认每台机器对llama.cpp暴露的可用显存是多少。如果发现可用内存远小于128GB回BIOS把UMA Frame Buffer改回Auto。另一个坑是系统内存和“显存”抢空间。Ubuntu桌面环境本身占用不小再加上浏览器多开内存很容易被挤占。我的经验是推理用机器就别装图形桌面跑Ubuntu Server版SSH进去管理内存干净很多。5.3 速度不达预期时先定位瓶颈当实际token/s明显低于理论推算时不要盲目调参先定位瓶颈在三处中的哪一处一是每台机器内部的内存带宽二是跨机网络的传输带宽三是单机的算子效率。定位方法很简单先看RPC Server日志里每台机器处理层的时间如果四台机器处理时间不均衡说明层分配不均匀或者某台机器被其他进程拖累了如果每台机器处理时间都正常但主节点整体token/s上不去那基本是网络延迟和传输开销的问题如果网络也正常还是慢那就考虑换个后端试试比如从Vulkan切到HIP。我遇到过一次特别典型的案例某一台机器因为散热风道被堵温度冲到90度以上触发降频RPC日志里那台机器的处理时间比其他机器长了近一倍整个集群的速度被拖到和单机差不多。清理灰尘、重新摆位后恢复。5.4 多机时间同步与长期稳定性多机推理对时间同步的要求不像数据库集群那么苛刻但并不代表完全不用管。四台机器的系统时间如果偏差过大排查日志时会非常痛苦因为各台机器的日志时间戳对不上很难看出调用链的先后顺序。我统一配了chrony做NTP同步偏差控制在几毫秒以内后续排查问题轻松很多。长期稳定性方面我最长的一次压测是连续跑12小时的对话服务期间没有断连但出现过一次某台机器温度过高导致的性能波动。建议给四台机器都做温度监控超过85度就报警不要等到触发降频才发现问题。6. 实测结果汇总与拓展方向到这里这套四机集群的完整交付形态已经很清晰了。硬件就是四台128GB的Ryzen AI Max 395机器网络从2.5G升级到25G软件栈是Ubuntu Server加llama.cpp的RPC后端模型管理用GGUF格式。最终跑70B模型的单用户速度从5.6 token/s提升到16.8 token/s8并发场景整体吞吐到50 token/s以上至于单机完全装不下的300B级别模型也能稳定跑出8到12 token/s的可用速度。这套方案的上限还能继续推。下一步我计划做三件事一是把网络换成100G进一步压缩跨机传输时间看单用户速度能不能逼近理论值二是尝试HIP/ROCm后端同网络条件下应该还能再带来一些性能增益三是接入vLLM的多机模式用真实的RDMA网络重新测一轮把两条技术路线的差异量化出来。开源工具链的迭代速度很快几个月前这些事还都很麻烦现在已经到了“花点心思就能本地跑大模型集群”的阶段。如果你也想在自己的设备上复刻这套方案我给三个最实在的建议第一先别急着上大模型用一个小模型把四机RPC链路跑通确认网络和版本没问题第二理论推演的带宽计算一定要做它能告诉你瓶颈在哪、预期多少避免瞎调参第三日志和监控从一开始就做好四台机器跨机协作没有日志寸步难行。这套折腾下来我最大的体会是本地大模型的上限从来不是单机算力而是能不能把多机的内存带宽和算力真正协同起来。四台Ryzen AI Max 395的组合等于用远低于一张旗舰数据中心卡的预算换来了一台能跑300B模型的本地推理服务器。它不适合追求极致单用户延迟的场合但如果你想在本地自由地试验大模型、跑多用户服务、把模型权重和数据牢牢握在自己手里这套开源工具链加持的集群方案是这个节点上性价比最离谱的玩法之一。 
长河君 · 2026/9/19 5:10:33 · 阅读 1.2k 四台Ryzen AI Max+ 395组网：llama.cpp RPC分布式推理集群实战
把四台AMD Ryzen AI Max 395组网跑大模型这个念头我盘了有小半年。单机128GB统一内存本地跑70B量化模型已经很舒服但一旦想碰300B往上的开源模型单机的天花板立刻摆在面前。这次我干脆咬咬牙凑了四台Strix Halo旗舰APU机器用开源工具链把它串成一个大模型推理集群目标很直接让本地能跑的模型规格上一个台阶同时把流水线并行的部署思路完整走一遍。这篇文章就把整套方案从头到尾拆开讲硬件怎么选、网络怎么接、llama.cpp怎么配RPC、模型怎么分片以及那些只有踩过坑才知道的细节全部记录下来。这套方案适合什么人看一是手上有Strix Halo或者类似大统一内存平台、想榨干本地推理性能的朋友二是想理解多机大模型推理原理、又不想一上来就上InfiniBand和机架式GPU服务器的玩家三是对开源工具链感兴趣、想知道llama.cpp/vLLM/Ollama在多机场景下到底怎么选型的人。我会尽量把“为什么这么做”讲透而不只是贴命令。1. 为什么是四台Ryzen AI Max 395方案的底层逻辑1.1 单机的天花板到底在哪Ryzen AI Max 395这颗APU的规格放在一年前是很难想象的16核32线程的Zen 5 CPU、40个CU的RDNA 3.5核显、50 TOPS的XDNA 2 NPU再加上最高128GB的LPDDR5X统一内存内存带宽256GB/s。这个配置意味着单台机器就能完整加载70B到120B参数的量化模型不需要任何独立显卡。但单机的瓶颈也很明确。首先是内存容量128GB看着很大跑一个Q4_K_M量化的72B模型要占掉40多GB留给KV cache和系统自身的内存就不算宽裕了更别说长上下文或者多路并发。其次是内存带宽256GB/s在APU里算顶尖可模型推理是“每次生成一个token都要把权重全部过一遍”的活权重越大带宽越吃紧。一台机器跑72B模型理论下限大约就是每秒5到6个token这个速度聊天够用但离“流畅交互”“多用户并发”还有距离。所以我组四台机器的核心思路很简单把内存池从128GB扩到512GB把算力从40CU扩到160CU用多机分布式推理把单机的物理墙推高。这不是拿四台机器做Hadoop那种数据分片而是做模型层面的并行计算。1.2 四机集群到底解决了什么四台机器组在一起最直接的好处是能装下更大的模型。拿去年到今年开源社区的热门模型举例Llama 3.1 405B、DeepSeek-V3/R1这种千亿参数级的MoE模型即使量化到Q4也普遍要200GB到300GB以上的存储空间单台128GB的机器只能望洋兴叹。四台机器共享一个模型地址空间之后这类大模型就真的可以在本地跑了。第二个好处是吞吐。流水线并行下模型按transformer层切成四段每台机器只负责自己那一段的计算。生成一句话时前一台机器算完几层把中间结果传给下一台四台机器像流水线一样接力。这样单个请求的延迟不会严格变成四分之一但并发请求和长文本生成的整体吞吐会显著提升。四个40CU的核显加起来批量处理能力比单机强不少。第三个容易被忽略的好处是灵活性。四台机器既可以合体当一个大模型推理池也可以拆开各自跑小模型甚至可以两两一组一组跑对话模型一组跑Embedding或Agent任务。这种“合则一体、分则各自为战”的形态比买一张又贵又难伺候的数据中心显卡要实用得多。1.3 为什么没走K8s和Hadoop集群的老路很多朋友一听“四台机器组集群”第一反应是上Kubernetes、Spark、Hadoop那一套。这个思路在大数据场景是对的但放到大模型推理上完全不适用。Kafka、Spark、Hadoop那套集群解决的是“海量数据分片存储和批处理”典型特征是吞吐优先、对单次任务延迟不敏感数据和计算都是按记录粒度散的。大模型推理是延迟敏感型负载核心诉求是“一个请求进来几百毫秒到几秒内给我返回”。它需要的是模型张量在设备间的紧密协作而不是把数据拆成小包扔给不同节点各自算。硬上一套K8s光调度开销和服务发现就能让推理延迟变得没法看而且Strix Halo这种统一内存平台的显存池跟K8s的“CPU内存/GPU显存”模型根本对不上。所以最终选择了更底层、更直接的模型并行方案而不是套一个大而全的平台。2. 硬件准备与网络互联四机集群的底座工程2.1 四台机器的基本配置清单先说硬件。我这四台机器配置完全一致这样后续排查问题的时候不容易被变量干扰。部件配置CPU/GPU/NPUAMD Ryzen AI Max 395Zen 5 16C/32T RDNA 3.5 40CU XDNA 2 50 TOPS内存128GB LPDDR5X-8000统一内存256-bit存储2TB PCIe 4.0 NVMe SSD系统盘模型盘各一块系统Ubuntu 24.04 LTS内核 6.8网卡PCIe 3.0 x4 转接的 25G 以太网卡电源120W 整机功耗级别的小主机电源这里有个重要概念要解释清楚Ryzen AI Max 395没有传统意义上的“显存”GPU和CPU共用物理内存。BIOS里那个UMA Frame Buffer分配的是一部分固定保留给显示控制器的显存但AI推理时真正用的是“可分配的通用系统内存”。所以四台机器合起来AI推理可用的内存池基本上是四台各自最大可用内存之和这是这套方案能跑大模型的根本原因。2.2 网络是最大的坑别让内网拖了推理的后腿四机集群里最容易翻车的不是CPU不是内存而是网络。流水线并行意味着每个token生成时中间层的激活值要在相邻机器之间来回传网络延迟和带宽直接决定推理速度的上限。板载网卡基本都是1G/2.5G级别这个带宽跑小模型还行跑大模型并发一上来就直接卡死。我实测过2.5G网卡下面四机分片跑72B模型吞吐被压到跟单机差不多网络成了绝对瓶颈。所以这次直接上了25G网卡用PCIe 3.0 x4的插槽加一张二手25G网卡四台机器接一台25G小交换机。如果预算紧10G网卡也够用但25G带来的余量会让后续调优舒服很多。如果手头实在没有PCIe插槽还有一条更低成本的方案USB4桥接网络。Ryzen AI Max 395平台普遍带USB4接口走USB4/IP协议能跑到40Gbps比板载千兆强得多。但我个人的建议是别把它当主力USB4网卡方案的稳定性在长时间重负载下有点看运气做成备用链路倒是不错。2.3 系统与BIOS设置要点系统安装没有太多花哨的地方Ubuntu 24.04 LTS对Strix Halo的核显支持已经不错。但有几个BIOS项必须手动调第一把“UMA Frame Buffer”设成Auto别手动设一个特别大的值。很多人为了让核显“多分点显存”喜欢设成32GB甚至64GB这在推理场景反而会挤压通用内存池的可用量。让系统动态分配才是正解。第二关掉不必要的电源管理特性。我这边把CPPC性能和C6休眠深度做了调整避免四台机器中某台在空闲状态下被降频拉起时产生明显延迟抖动。四台机器跨机协作时任何一台响应慢半拍整个流水线都要等它。第三统一内存参数。内存条或者板载内存规格必须四台一致LPDDR5X-8000就跑8000不要一台开了EXPO一台没开否则性能表现会互相拖累排查起来也很痛苦。第四为模型文件预留空间。2TB的NVMe系统占掉几十GB剩下的空间尽量留给GGUF模型文件。一个300GB的模型加一份80GB的量化版本非常考验磁盘剩余空间。3. 开源工具链的选型与部署让四台机器长成一个GPU3.1 四条路线怎么选开源生态里能跑多机大模型推理的方案我实际调研和试过的有四条llama.cpp的RPC后端、vLLM的多机部署、Ollama的分布式模式还有EXO这种面向异构设备的框架。llama.cpp的RPC后端是最成熟的选择。它天然支持GGUF格式的模型分片能按transformer层把不同的层分配给不同的RPC Server主节点只负责统一调度和token采样。好处是对网络环境要求低不强制RDMA普通TCP/IP就能跑而且GGUF的生态极其丰富。vLLM多机部署是另一个方向性能和吞吐确实强但依赖NCCL做集合通信最好有RoCE或InfiniBand这类RDMA网络。普通以太网上也能跑不过性能衰减明显而且vLLM对Strix Halo这种APU的ROCm适配还在完善中编译和调参的成本比较高。Ollama的分布式模式底层还是llama.cpp胜在配置简单适合快速验证多机推理链路是否通但高级参数暴露得少调优空间有限。EXO对异构设备很友好Apple Silicon上的口碑不错但对Strix Halo这种大统一内存平台的文档和社区支持还很薄弱。我最终的主力方案是llama.cpp RPCOllama分布式作为演示和教学用途。vLLM留到后面专门开一篇讲。3.2 llama.cpp编译与RPC服务配置llama.cpp的部署分三步编译、启动RPC Server、主节点挂载。编译时后端选择很关键。llama.cpp对AMD核显有两种主流后端Vulkan和HIP/ROCm。HIP理论上性能更好但Strix Halo的ROCm支持需要手动确认工具链版本踩坑概率高Vulkan兼容性强编译简单出问题容易排。我的建议是第一轮先用Vulkan后端把整个链路跑通性能调优阶段再尝试HIP。RPC Server的启动非常轻量本质上是四台机器各自跑一个进程# 每台机器执行把Server进程起来 ./bin/rpc-server -p 50052 --device Vulkan主节点上则把四台机器都挂进来# 主节点node1-node4是四台机器的IP ./bin/llama-cli \ -m /models/qwen2.5-72b-instruct-q4_k_m.gguf \ --rpc node1:50052,node2:50052,node3:50052,node4:50052 \ -n 256 \ -c 32768这里有两个细节需要特别注意端口要放行防火墙四台机器的rpc-server版本必须和主节点llama-cli版本一致。版本不一致会出现奇奇怪怪的协议错误日志里只会看到一个connection closed没有明确提示会浪费大量时间排查。3.3 模型分片与层分配策略llama.cpp的RPC模式默认是layer维度分片也就是把整个模型的transformer层按顺序切成几段每台机器负责一段。加载模型时主节点会打印每台RPC Server分到了哪些层以及各台机器的内存占用情况。层分配的核心原则是“按性能等比分配”。四台机器配置一致时最省心的做法是让llama.cpp自动分配它默认把层数尽量平均分给每台服务器。但如果某台机器的其他进程占了比较多内存可以手动指定各设备负责的层数范围。层分的越细单台机器的内存压力越小但机器之间的通信次数越频繁。四机场景下每台机器分到四分之一的层数这个粒度比较平衡。如果以后扩展到八机通信开销占比会变大那时候就得认真核算网络带宽是否够用。4. 大模型推理优化参数、实测与瓶颈分析4.1 用带宽公式推导预期速度很多人上来就调参参数调了半天也不知道为什么快为什么慢。我建议先做一次理论推演心里有个底。以Qwen2.5-72B的Q4_K_M GGUF为例权重文件大约44GB。单机推理时生成一个token需要把全部权重从内存读一遍带宽256GB/s理论下限是44GB除以256GB/s约172毫秒也就是大概5.8 token/s。这是单机物理极限跑不进这个数只能无限接近。四机流水线并行后每台机器只持有四分之一的层也就是每台约11GB权重。单个token生成时每台机器只需读自己那11GB权重理论下限变成11GB除以256GB/s约43毫秒也就是约23 token/s。加上网络传输和算子开销实测能跑到15到18 token/s已经算健康。这个推导过程能解释很多现象为什么四机跑小模型提升不明显小模型权重小带宽还没怎么发挥就已经很快了为什么模型越大四机优势越明显大模型权重远超单机带宽可承受范围分布式读权重的收益就体现出来了。4.2 KV Cache的容量规划KV Cache是推理时每个token都要重复读取的中间缓存它的大小取决于模型结构和上下文长度。以Qwen2.5-72B为例它的GQA配置是8个KV头、每个头128维那么每层每个token的KV缓存大约是2K和V两份乘以8个KV头乘以128维再乘以2字节BF16存储约4KB。72B模型有64层所以一个token总共要约256KB的KV Cache。32K上下文时单单一个请求的KV Cache就要8GB。四机流水线并行下KV Cache是跟着层走的每台机器只缓存自己那16层的KV所以8GB的KV总量分摊下来每台只是2GB压力不大。但要注意一个细节如果并发8个用户同时各占32K上下文KV Cache总量就是64GB每台16GB。这块内存是在统一内存里分配的和模型权重抢带宽和容量所以并不是上下文越长越好。4.3 实测性能数据这是我在自己的四机环境里跑出来的数据模型文件放在NVMe SSD上全程用Vulkan后端网络是25G以太网场景配置吞吐/延迟备注单机Qwen2.5-72B Q4单用户1机4096 ctx5.6 tok/s和理论带宽推算基本吻合四机Qwen2.5-72B Q4单用户4机分片4096 ctx16.8 tok/s单用户场景提升约3倍四机Qwen2.5-72B Q48并发4机分片4096 ctx52 tok/s 整体并发场景吞吐优势明显四机DeepSeek-V3 Q4模拟量化版4机分片8192 ctx8到12 tok/s模型权重约220GB单机完全没法跑四机Llama-3.1-70B Q4单用户4机分片4096 ctx17.5 tok/sKV更小速度略高这里有个重要心得流水线并行对单用户延迟的提升没有到四倍因为每次生成token都要经过机间传输这个开销在单用户场景下占比不小。但多并发场景下四台机器可以并行处理多个请求的不同层段整体吞吐提升非常明显。如果核心诉求是“单个用户生成得更快”可以考虑张量并行如果目标是“支撑更多用户同时聊天”那流水线并行就是性价比最高的方案。4.4 哪些参数值得花时间调llama.cpp里对RPC集群影响最大的几个参数我按重要性排一下-c / --ctx-size上下文长度直接影响KV Cache占用和内存池压力不要无脑拉大。-b / --batch-size预填充阶段的batch大小对长文本输入的处理速度影响很大。加载模型后先压一个长文档测试batch调到128以上往往能显著加快预填充速度。-np / --parallel并行序列数决定同时能处理多少独立请求。它和内存、带宽强相关开太大容易OOM建议从2开始逐步往上加。--mlock锁定内存防止模型权重被换出到磁盘。大模型推理必须开否则系统内存压力上来后权重被swap到NVMe速度会断崖式下跌。-ub / --upload-batch-size和-sb这两组参数控制的是预填充和解码阶段每次向RPC Server发送的数据量在慢速网络下调小反而稳定在25G高速网络下调大能减少通信次数。我的调参建议是先把--mlock打开然后逐步增加batch和parallel每调一个参数就看RPC Server日志里的processing speed和主节点日志里的token/s用数据说话别靠感觉。4.5 长上下文和多用户场景的吞吐表现长上下文是这套集群最有价值的应用场景之一。我拿一份40万字的中文长文档做测试预填充阶段四机分片把文档处理完花了大概40秒相比单机的2分多钟提升非常可观。解码阶段跑长文生成16K上下文下稳定保持14到15 token/s没有出现上下文越长速度越慢的严重衰减。多用户场景我也做了压测。8个并发的llama-cli进程同时对话整体吞吐能到50 token/s出头单个用户的响应时间比单机时短很多。这时候能明显感觉到四台机器的协作价值每个请求的层计算分散到四台机器上等于把最大并发承载量放大了4倍。不过要提醒一句多用户场景下CPU和内存控制器的压力也会成倍增加。Ryzen AI Max 395的内存控制器要同时服务CPU、GPU和跨机网络DMA压力一大整机功耗和温度就上去了。四台机器的散热如果压不住会触发降频表现就是吞吐突然掉下来。5. 踩坑记录与问题排查速查表5.1 RPC连接闪断与主节点日志四机RPC最经典的问题就是主节点日志里反复出现connection closed或者error during inference而RPC Server那边看起来一切正常。我第一次遇到这个问题排查了整整一个晚上最后定位到是防火墙的conntrack把长连接给断了。llama.cpp RPC的Server和主节点之间的连接需要长时间稳定传统防火墙规则会对空闲连接做老化处理导致集群跑几分钟就断一次。解决方法很简单在主节点和所有RPC Server上同时放行对应端口的长连接或者直接在内网环境里把四台机器的防火墙策略改成允许内网网段全通。另外给四台机器配静态IP别用DHCP否则某台机器IP漂移了整个集群直接断链。5.2 OOM与统一内存的边界四机集群跑300B模型时遇到过内存分配失败。问题是模型权重明明加起来不到总内存的一半为什么还会OOM原因出在Vulkan后端的内存分配策略上。核显驱动会预先保留一部分内存作为显存堆有时候这个预留在BIOS设置里被设成了32GB甚至更高那么AI推理可用的内存池就少了整整32GB。排查方式是启动前用vulkaninfo看当前设备的heapSize确认每台机器对llama.cpp暴露的可用显存是多少。如果发现可用内存远小于128GB回BIOS把UMA Frame Buffer改回Auto。另一个坑是系统内存和“显存”抢空间。Ubuntu桌面环境本身占用不小再加上浏览器多开内存很容易被挤占。我的经验是推理用机器就别装图形桌面跑Ubuntu Server版SSH进去管理内存干净很多。5.3 速度不达预期时先定位瓶颈当实际token/s明显低于理论推算时不要盲目调参先定位瓶颈在三处中的哪一处一是每台机器内部的内存带宽二是跨机网络的传输带宽三是单机的算子效率。定位方法很简单先看RPC Server日志里每台机器处理层的时间如果四台机器处理时间不均衡说明层分配不均匀或者某台机器被其他进程拖累了如果每台机器处理时间都正常但主节点整体token/s上不去那基本是网络延迟和传输开销的问题如果网络也正常还是慢那就考虑换个后端试试比如从Vulkan切到HIP。我遇到过一次特别典型的案例某一台机器因为散热风道被堵温度冲到90度以上触发降频RPC日志里那台机器的处理时间比其他机器长了近一倍整个集群的速度被拖到和单机差不多。清理灰尘、重新摆位后恢复。5.4 多机时间同步与长期稳定性多机推理对时间同步的要求不像数据库集群那么苛刻但并不代表完全不用管。四台机器的系统时间如果偏差过大排查日志时会非常痛苦因为各台机器的日志时间戳对不上很难看出调用链的先后顺序。我统一配了chrony做NTP同步偏差控制在几毫秒以内后续排查问题轻松很多。长期稳定性方面我最长的一次压测是连续跑12小时的对话服务期间没有断连但出现过一次某台机器温度过高导致的性能波动。建议给四台机器都做温度监控超过85度就报警不要等到触发降频才发现问题。6. 实测结果汇总与拓展方向到这里这套四机集群的完整交付形态已经很清晰了。硬件就是四台128GB的Ryzen AI Max 395机器网络从2.5G升级到25G软件栈是Ubuntu Server加llama.cpp的RPC后端模型管理用GGUF格式。最终跑70B模型的单用户速度从5.6 token/s提升到16.8 token/s8并发场景整体吞吐到50 token/s以上至于单机完全装不下的300B级别模型也能稳定跑出8到12 token/s的可用速度。这套方案的上限还能继续推。下一步我计划做三件事一是把网络换成100G进一步压缩跨机传输时间看单用户速度能不能逼近理论值二是尝试HIP/ROCm后端同网络条件下应该还能再带来一些性能增益三是接入vLLM的多机模式用真实的RDMA网络重新测一轮把两条技术路线的差异量化出来。开源工具链的迭代速度很快几个月前这些事还都很麻烦现在已经到了“花点心思就能本地跑大模型集群”的阶段。如果你也想在自己的设备上复刻这套方案我给三个最实在的建议第一先别急着上大模型用一个小模型把四机RPC链路跑通确认网络和版本没问题第二理论推演的带宽计算一定要做它能告诉你瓶颈在哪、预期多少避免瞎调参第三日志和监控从一开始就做好四台机器跨机协作没有日志寸步难行。这套折腾下来我最大的体会是本地大模型的上限从来不是单机算力而是能不能把多机的内存带宽和算力真正协同起来。四台Ryzen AI Max 395的组合等于用远低于一张旗舰数据中心卡的预算换来了一台能跑300B模型的本地推理服务器。它不适合追求极致单用户延迟的场合但如果你想在本地自由地试验大模型、跑多用户服务、把模型权重和数据牢牢握在自己手里这套开源工具链加持的集群方案是这个节点上性价比最离谱的玩法之一。