企业官网建设流程全解析

把四台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 四台机器的基本配置清单

先说硬件。我这四台机器配置完全一致，这样后续排查问题的时候不容易被变量干扰。

这里有个重要概念要解释清楚：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. 开源工具链的选型与部署：让四台机器长成一个GPU

3.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 RPC，Ollama分布式作为演示和教学用途。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缓存大约是2（K和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以太网：

这里有个重要心得：流水线并行对单用户延迟的提升没有到四倍，因为每次生成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/s，8并发场景整体吞吐到50 token/s以上，至于单机完全装不下的300B级别模型，也能稳定跑出8到12 token/s的可用速度。

这套方案的上限还能继续推。下一步我计划做三件事：一是把网络换成100G，进一步压缩跨机传输时间，看单用户速度能不能逼近理论值；二是尝试HIP/ROCm后端，同网络条件下应该还能再带来一些性能增益；三是接入vLLM的多机模式，用真实的RDMA网络重新测一轮，把两条技术路线的差异量化出来。开源工具链的迭代速度很快，几个月前这些事还都很麻烦，现在已经到了“花点心思就能本地跑大模型集群”的阶段。

如果你也想在自己的设备上复刻这套方案，我给三个最实在的建议：第一，先别急着上大模型，用一个小模型把四机RPC链路跑通，确认网络和版本没问题；第二，理论推演的带宽计算一定要做，它能告诉你瓶颈在哪、预期多少，避免瞎调参；第三，日志和监控从一开始就做好，四台机器跨机协作，没有日志寸步难行。

这套折腾下来，我最大的体会是：本地大模型的上限从来不是单机算力，而是能不能把多机的内存带宽和算力真正协同起来。四台Ryzen AI Max+ 395的组合，等于用远低于一张旗舰数据中心卡的预算，换来了一台能跑300B+模型的本地推理服务器。它不适合追求极致单用户延迟的场合，但如果你想在本地自由地试验大模型、跑多用户服务、把模型权重和数据牢牢握在自己手里，这套开源工具链加持的集群方案，是这个节点上性价比最离谱的玩法之一。