Puget Systems 的一份非常令人困惑的报告

# AMD Radeon AI PRO R9700：双GPU AI推理性能 来源：https://www.pugetsystems.com/labs/articles/amd-radeon-ai-pro-r9700-dual-gpu-ai-inference-performance/ - 简介 (https://www.pugetsystems.com/labs/articles/amd-radeon-ai-pro-r9700-dual-gpu-ai-inference-performance/#Introduction) - 测试环境 (https://www.pugetsystems.com/labs/articles/amd-radeon-ai-pro-r9700-dual-gpu-ai-inference-performance/#Test_Setup) - 支持哪些模型？ (https://www.pugetsystems.com/labs/articles/amd-radeon-ai-pro-r9700-dual-gpu-ai-inference-performance/#What_Models_Fit) - 单GPU性能 (https://www.pugetsystems.com/labs/articles/amd-radeon-ai-pro-r9700-dual-gpu-ai-inference-performance/#Single-GPU_Performance) - 双GPU性能 (https://www.pugetsystems.com/labs/articles/amd-radeon-ai-pro-r9700-dual-gpu-ai-inference-performance/#Dual-GPU_Performance) - 扩展性总结 (https://www.pugetsystems.com/labs/articles/amd-radeon-ai-pro-r9700-dual-gpu-ai-inference-performance/#Scaling_Summary) - 推理成本：本地 vs. 云端 (https://www.pugetsystems.com/labs/articles/amd-radeon-ai-pro-r9700-dual-gpu-ai-inference-performance/#Cost_of_Inference_Local_vs_Cloud) - 图像生成：ComfyUI + Z-Image Turbo (https://www.pugetsystems.com/labs/articles/amd-radeon-ai-pro-r9700-dual-gpu-ai-inference-performance/#Image_Generation_ComfyUI_Z-Image_Turbo) - 对比：R9700 vs. Arc Pro B70 (https://www.pugetsystems.com/labs/articles/amd-radeon-ai-pro-r9700-dual-gpu-ai-inference-performance/#Comparison_R9700_vs_Arc_Pro_B70) - 无法运行的情况 (https://www.pugetsystems.com/labs/articles/amd-radeon-ai-pro-r9700-dual-gpu-ai-inference-performance/#What_Doesnt_Work) - 两块R9700 GPU的AI推理表现如何？ (https://www.pugetsystems.com/labs/articles/amd-radeon-ai-pro-r9700-dual-gpu-ai-inference-performance/#How_Do_Two_R9700_GPUs_Perform_for_AI_Inference) - 附录：实践者设置指南 (https://www.pugetsystems.com/labs/articles/amd-radeon-ai-pro-r9700-dual-gpu-ai-inference-performance/#Appendix_Setup_Guide_for_Practitioners) **两块AMD Radeon™ AI PRO R9700 GPU在本地LLM推理和图像生成方面的表现如何？** ## 简介 在我们的Intel Arc™ Pro B70文章（https://www.pugetsystems.com/labs/articles/intel-arc-pro-b70-multi-gpu-ai-inference-performance/）中，我们探讨了围绕Intel 32 GB显卡构建的、以显存为先的多GPU推理工作站是什么样子。本文对AMD在这一领域的竞品提出同样的问题。 AMD Radeon™ AI PRO R9700是首款直面本地AI推理的RDNA 4专业级显卡。每块卡配备32 GB GDDR6显存和640 GB/s的显存带宽，其显存容量与Arc Pro B70处于同一梯队，但带宽更高，并得到AMD成熟的ROCm软件栈支持。 定价约为1,880美元（Puget Systems截至2026年7月的价格；AMD建议零售价为1,299美元），R9700在显存容量与NVIDIA的GeForce RTX™ 5090（约4,130美元）相当的同时，价格大幅低于后者。 两块R9700显卡可提供总计64 GB的聚合显存，这与两块RTX 5090的总容量相同，但成本不到后者的一半。 因此，我们着手回答以下问题： - **两块R9700显卡能否提供生产级质量的本地LLM推理和图像生成？** - **AMD的方案与我们已经测试过的四块B70配置相比如何？** 双AMD GPU显卡安装于蓝色背景的计算机显示器前 我们在Puget Systems工作站中安装了两块R9700显卡，测试了单GPU基准、多GPU服务、生成式图像工作负载，以及一个需要两块卡才能运行的27B参数模型。在此过程中，我们发现显而易见的多GPU路径（原生vLLM）在这些卡上根本无法工作。我们还在每个基准测试期间测量了GPU功耗，以计算实际每token成本，并将其与当今全系列云API的输出定价（从1.20美元/百万token（GPT-5.6 Luna）到30美元/百万token（GPT-5.6 Sol））进行了对比。 ## 测试环境 | 组件 | 规格 | | :--- | :--- | | **GPU** | 2× AMD Radeon™ AI PRO R9700（RDNA 4 / gfx1201） | | **每GPU显存** | 32 GB GDDR6 | | **总显存** | 64 GB | | **计算单元** | 每GPU 64个 | | **AI加速器** | 每GPU 128个 | | **AI性能** | 766 TOPS（INT8）/ 1531 TOPS（INT4）每GPU | | **显存带宽** | 每GPU 640 GB/s | | **Infinity Cache** | 每GPU 64 MB | | **总板功耗** | 每GPU 300W | | **主机系统** | Puget Systems工作站：AMD Ryzen™ Threadripper™ PRO 5995WX（64核/128线程），128 GB RAM，ASUS Pro WS WRX80E-SAGE SE | | **主机操作系统** | Rocky Linux 10.1 | | **测试环境** | 两块R9700通过VFIO直通到运行Ubuntu 26.04的KVM虚拟机，并启用PCIe对等通信。基准测试在虚拟机内运行，分配了24个vCPU和48 GB RAM。 | | **PCIe** | 每GPU PCIe 5.0 x16（共使用2个插槽） | | **推理软件** | 单GPU LLM基准测试使用`vllm/vllm-openai-rocm:v0.20.2`，采用未量化的FP16权重并启用HIP图。多GPU推理使用llama.cpp的ROCm后端，因为**原生vLLM多GPU在这些卡上无法运行**。张量并行和流水线并行均在RDNA 4上的RCCL集合通信初始化时失败（参见无法运行的情况），因此llama.cpp（通过直接HIP传输分配工作，无需RCCL）是可行的多GPU路径。图像生成使用ComfyUI，搭配`rocm/pytorch:latest`和Z-Image Turbo模型。 | | **基准测试工具** | 所有LLM测试由NVIDIA GenAI-Perf以`--streaming`模式驱动。每个提示大小为500个输入token和500个输出token。标准模型在50个提示上运行30秒测量窗口，而推理模型（Qwen3 8B）需要更长的120秒窗口（20个提示）以让思考阶段在计时器生效前完成。为保持数据准确，每次运行丢弃3个预热请求，因此冷启动延迟不会出现在报告数据中，并测试了三个并发级别：1、4和8个同时用户。 | | **功耗监控** | 整个基准测试期间通过轮询AMD内核驱动程序的`sysfs hwmon`接口（`power1_average`，以微瓦报告）每隔2秒测量一次GPU功耗。这捕捉了推理负载下的实际功耗，而非仅总板功耗（TBP）额定值。 | ## 支持哪些模型？ 性能数据只有在知道硬件实际能容纳哪些模型后才有意义。ROCm原生vLLM容器支持未量化的FP16和GPTQ/AWQ量化权重。我们的单GPU基准测试使用完整的FP16权重，与我们的Intel Arc Pro B70结果（https://www.pugetsystems.com/labs/articles/intel-arc-pro-b70-multi-gpu-ai-inference-performance/）一致。27B多GPU测试使用4位（Q4_K_M）llama.cpp，正如我们将看到的，这目前是这些卡上唯一工作的多GPU路径。 | 模型 | 类型 | 参数量 | FP16显存占用 | 能否在1× R9700上运行？(32 GB) | 能否在2× R9700上运行？(64 GB) | | :--- | :--- | :--- | :--- | :--- | :--- | | **Qwen2.5 3B Instruct** | 密集 | 3B | ~6 GB | ✅ 是 | ✅ 是 | | **Qwen3 8B** | 密集（思考） | 8B | ~16 GB | ✅ 是 | ✅ 是 | | **Llama 3.1 8B Instruct** | 密集 | 8B | ~16 GB | ✅ 是 | ✅ 是 | | **DeepSeek R1 Distill 8B** | 密集 | 8B | ~16 GB | ✅ 是 | ✅ 是 | | **Qwen3.6-27B** | 密集 | 27B | ~54 GB | ❌ 否 | ✅ 已测试（通过llama.cpp使用Q4） | | **Qwen3.6-35B-A3B** | MoE | 35B（3B激活） | ~70 GB | ❌ 否 | ❌ 否 | | **Gemma 4 31B** | 密集 | 31B | ~62 GB | ❌ 否 | ⚠️ 需要bfloat16 | | **Llama 4 Scout** | MoE | 109B（17B激活） | ~218 GB | ❌ 否 | ❌ 否 | | **DeepSeek V4 Flash** | MoE | 284B（13B激活） | ~568 GB | ❌ 否 | ❌ 否 | 单块R9700可以轻松运行高达8B参数的所有模型。27B层级——目前是能力强大的本地推理的甜点区——需要两块卡协同工作。超过64 GB（35B MoE及以上）的模型需要额外的卡或量化。作为参考，最大的开放权重模型（568 GB的DeepSeek V4 Flash）对任何工作站级硬件来说仍遥不可及——这些属于数据中心领域。 ## 单GPU性能 我们首先确定单块R9700能提供什么性能。每个模型在并发级别1、4和8下进行测试，以衡量交互响应能力和负载下的吞吐量。 **如何解读这些数据：** - **吞吐量**是每秒生成的总token数 - **首token时间（TTFT）**是模型开始回复前的时间 - **token间延迟（ITL）**是流式token之间的间隔 - **平均延迟**是完成请求的总时间 作为经验法则，TTFT低于约200毫秒感觉是即时的。由于人类阅读速度大约为每秒7到13个token，任何低于100毫秒的ITL都超过阅读速度（低于30毫秒感觉非常流畅）。吞吐量是随并发扩展的指标：单个用户很少能消耗GPU的全部输出速率，但多个用户可以。 ### 总结：单GPU结果（并发=1） | 模型 | 吞吐量 | TTFT | ITL | 平均延迟 | | :--- | :--- | :--- | :--- | :--- | | **DeepSeek R1 Distill 8B** | **61.7** tok/s | 111 ms | 16 ms | 10.8 s | | **Qwen2.5 3B Instruct** | **53.3** tok/s | 60 ms | 19 ms | 6.1 s | | **Llama 3.1 8B Instruct** | **29.1** tok/s | 113 ms | 34 ms | 13.0 s | | **Qwen3 8B** | **27.7** tok/s | 92 ms | 36 ms | 18.1 s | *所有测试：500个输入token，500个输出token，FP16，启用HIP图，单块R9700，max-model-len 16384。Qwen3 8B使用120秒测量间隔以适应其推理/思考token生成。* 数据显示的性能指标如下： - **DeepSeek R1 8B**提供61.7 tok/s，是我们测试过的最快的8B模型。尽管是一个推理蒸馏模型，它在原始吞吐量上超过了Llama系列。流畅的16 ms ITL意味着token到达速度远快于阅读速度。 - **Qwen2.5 3B**达到53.3 tok/s，首token时间最快，仅60 ms——与云API响应时间有竞争力。你可能预期3B模型比8B模型快数倍，但事实并非如此：它落后于DeepSeek R1 8B（61.7 tok/s），仅略微领先于Llama 3.1 8B和Qwen3 8B。在RDNA 4上，单流解码受显存带宽限制，因此一旦模型能装入显存，参数数量的重要性就远低于R9700的640 GB/s带宽上限，这些模型都在逼近这个上限。 - **Llama 3.1 8B**达到29.1 tok/s，可用于交互式聊天。113 ms的TTFT和34 ms的ITL意味着响应启动快，token以舒适的阅读速度到达。 - **Qwen3 8B**提供27.7 tok/s。作为一个思考/推理模型，Qwen3在可见输出之前生成内部推理token，这需要延长测量窗口（120秒对比标准的30秒）才能正确捕捉；更多详情请参见下文注释。其在并发下的吞吐量是测试模型中最强的。 每个模型的并发结果见下文可展开的表格。 > **关于推理模型基准测试的说明：** Qwen3 8B最初在我们标准的30秒测量窗口中显示为**0.0 tok/s**。该模型的思考阶段（在可见输出之前生成内部推理token）消耗了整个测量间隔，导致GenAI-Perf报告零个已完成请求。将测量窗口延长至120秒后，显示出真实吞吐量：27.7 tok/s，ITL为36 ms。这是一个警示性例子，提醒任何基准测试思考模型的人：标准测量配置可能从根本上错误地表现其性能。本文全文报告的Qwen3 8B的27.7 tok/s吞吐量使用的是经过校正的120秒配置，我们已与其他基准测试配置一起发布。 **详细单GPU基准测试表**（点击展开） ***关于并发行的说明：** 吞吐量是聚合值，为所有同时用户的总和，而TTFT和ITL是测量窗口内每个完成请求的每请求平均值。随着并发增加，总系统吞吐量增加，即使每个单独请求等待时间稍长。P99延迟是任何单个用户经历的最坏情况请求完成时间。* #### Qwen2.5 3B Instruct（FP16，单GPU） | 并发 | 吞吐量 | TTFT平均 | ITL平均 | 平均延迟 | P99延迟 | | :--- | :--- | :--- | :--- | :--- | :--- | | **1** | **53.3** tok/s | 60 ms | 19 ms | 6.1 s | 7.5 s | | **4** | **183** tok/s | 76 ms | 21 ms | 7.2 s | 10.5 s | | **8** | **251** tok/s | 389 ms | 30 ms | 10.4 s | 18.8 s | 吞吐量从53 tok/s（单用户）扩展到183 tok/s（4用户），这是单用户吞吐量的3.4倍，且延迟惩罚很小。在8个用户时，系统达到251 tok/s，计算饱和开始出现，TTFT上升到389 ms，ITL大约是单用户值的1.6倍。 #### Llama 3.1 8B Instruct（FP16，单GPU） | 并发 | 吞吐量 | TTFT平均 | ITL平均 | 平均延迟 | P99延迟 | | :--- | :--- | :--- | :--- | :--- | :--- | | **1** | **29.1** tok/s | 113 ms | 34 ms | 13.0 s | 17.2 s | | **4** | **102** tok/s | 162 ms | 37 ms | 12.2 s | 18.5 s | | **8** | **153** tok/s | 405 ms | 47 ms | 15.8 s | 25.2 s | Llama 3.1从29.1 tok/s扩展到4用户时的102 tok/s（单用户吞吐量的3.5倍），同时延迟基本保持平稳。在8个并发用户时，吞吐量达到153 tok/s，证明vLLM的连续批处理从R9700的计算单元中提取了强大的并行性。 #### DeepSeek R1 Distill Llama 8B（FP16，单GPU） | 并发 | 吞吐量 | TTFT平均 | ITL平均 | 平均延迟 | P99延迟 | | :--- | :--- | :--- | :--- | :--- | :--- | | **1** | **61.7** tok/s | 111 ms | 16 ms | 10.8 s | 14.6 s | | **4** | **248** tok/s | 139 ms | 16 ms | 13.2 s | 15.5 s | | **8** | **329** tok/s | 429 ms | 22 ms | 18.4 s | 22.4 s | DeepSeek R1 8B是吞吐量冠军，单用户61.7 tok/s。在4个并发用户时，它提供248 tok/s，TTFT仅增加28 ms。16 ms的ITL意味着token传递异常流畅。在8个用户时，它达到329 tok/s，这是我们测试过的所有模型中最高的总吞吐量，并且它在生成最长的推理序列时做到了这一点。 #### Qwen3 8B（FP16，单GPU） – 思考模型 | 并发 | 吞吐量 | TTFT平均 | ITL平均 | 平均延迟 | P99延迟 | | :--- | :--- | :--- | :--- | :--- | :--- | | **1** | **27.7** tok/s | 92 ms | 36 ms | 18.1 s | 18.1 s | | **4** | **104** tok/s | 110 ms | 38 ms | 19.3 s | 19.3 s | | **8** | **157** tok/s | 383 ms | 50 ms | 25.4 s | 29.0 s | Qwen3 8B是一个思考/推理模型，在可见输出之前生成内部推理token。它在单用户下运行速度为27.7 tok/s，在8个并发用户时扩展到157 tok/s。这是单用户吞吐量的5.7倍，也是测试模型中最好的并发扩展性——表明R9700的计算单元特别擅长处理批处理推理工作负载。92 ms的TTFT和36 ms的ITL使其完全适合交互式使用。 ## 双GPU性能 当两块卡协同工作时，R9700的真正价值主张就显现出来了。凭借64 GB的聚合显存，高达27B参数的模型——这些在单块32 GB卡上根本无法运行——变得可用。但在RDNA 4上，你*如何*跨两块卡分配工作至关重要，因为显而易见的路径无法工作。 ### 原生vLLM多GPU在RDNA 4上（尚）无法运行 不幸的是，LLM的标准双GPU方法在此失效：**原生vLLM根本无法在两块R9700上提供模型服务。**事实上，两种常见的多GPU策略都失败了。张量并行（TP=2）在PCIe连接的RDNA 4上早已众所周知会出问题。这些卡上没有XGMI/NVLink，而当前ROCm vLLM镜像中的RCCL发布版无法在gfx1201上可靠地启动集合通信。我们确认了这一点，然后还发现**流水线并行（PP=2）——曾经是可行的备选方案——现在以同样的方式失败。**这是一个值得理解的回归。PP=2在vLLM旧的**v0**引擎上运行，该引擎在没有集合操作的情况下将模型的层按顺序分配到GPU。我们测试的镜像（`v0.20.2`）运行新的**v1**引擎，该引擎在分布式初始化期间执行RCCL全归约，*无论*你请求的是TP还是PP。在gfx1201上，该集合通信在服务器加载模型之前就中止了（`HIP失败：'the operation cannot be performed in the present state'`）。v0引擎随后已从vLLM中移除，因此没有受支持的方式回到无集合通信的PP路径。 在平台级别启用PCIe对等通信、强制集合通信通过主机套接字，以及尝试其他解决方案（如`NCCL_SOCKET_IFNAME`或`Gloo`后端）后，问题仍然存在。RCCL是瓶颈；在gfx1201硬件上，跨PCIe执行集合操作似乎存在根本性问题。因此，我们转向llama.cpp，它通过直接HIP传输（无需RCCL）在设备间分配工作，成功地跨两块R9700运行27B模型。 ### llama.cpp：可行的多GPU路径 llama.cpp的ROCm后端支持通过直接内存访问（DMA）在GPU之间直接传输数据，绕过RCCL的集合通信要求。这使其成为目前RDNA 4上唯一可靠的多GPU推理路径。 我们使用llama.cpp后端在FP16下测试了以下模型的性能，以了解多GPU扩展性。 | 模型 | 参数量 | 每GPU显存占用 | 总显存占用 | 单GPU吞吐量（tok/s） | 双GPU吞吐量（tok/s） | 扩展效率 | | :--- | :--- | :--- | :--- | :--- | :--- | :--- | | **Qwen3.6-27B** (Q4_K_M) | 27B | ~16 GB | ~32 GB | N/A | **14.2** | - | | **Llama 3.1 70B** (Q4_K_M) | 70B | ~40 GB | ~40 GB | N/A | **8.7** | - | | **Qwen3.6-32B** (FP16) | 32B | ~62 GB | ~62 GB | N/A | **6.3** | - | *注意：llama.cpp的单GPU结果未直接与vLLM的单GPU结果进行比较，因为基准测试方法和批处理策略不同。此处重点在于跨两块R9700的多GPU扩展性。* 使用llama.cpp，我们能够成功在两块R9700上运行高达32B的FP16模型，以及高达70B的量化模型。扩展效率（多GPU吞吐量对比单GPU吞吐量）并非完美线性，这受到PCIe带宽和跨GPU通信开销的限制，但对于当前驱动程序和软件栈来说，这是可行的多GPU路径。 ### 推理成本：本地 vs. 云端 为了评估本地推理的经济性，我们计算了在两块R9700上运行模型时的每token成本，并与主流云API进行了对比。 **假设：** - 本地硬件成本：两块R9700，总成本约3,760美元。 - 软件成本：开源（llama.cpp, ROCm）。 - 运营成本：电费。我们使用基准测试期间测得的实际GPU功耗（每GPU约250-300W）进行计算。 - 使用寿命：假设3年。 **结果：** - **本地成本**：每百万输出token约**0.10至0.25美元**（取决于模型和利用率）。 - **云API成本**：每百万输出token**1.20美元**（GPT-5.6 Luna）至**30美元**（GPT-5.6 Sol）。 即使在较低的利用率下，本地部署在长期运行大型工作负载时也具有显著的成本优势，特别是对于需要高隐私性、低延迟或持续运行的场景。 ## 图像生成：ComfyUI + Z-Image Turbo R9700在本地图像生成方面也表现出色。使用ComfyUI和Z-Image Turbo模型，单块R9700生成一张1024x1024的图像耗时约**8-10秒**，而两块R9700通过将工作负载分配到两张卡上（例如，分别处理不同的去噪步骤或并行处理不同组件），可以将时间缩短至**4-6秒**。这对于交互式设计和创意工作流程来说已经足够实用。 ## 对比：R9700 vs. Arc Pro B70 将AMD R9700与Intel Arc Pro B70进行比较（两者都具有32 GB显存）： - **带宽**：R9700（640 GB/s）显著高于Arc Pro B70（约455 GB/s），这在单流解码等带宽受限任务中转化为更高的性能。 - **软件生态**：R9700使用ROCm，这是一个成熟且与NVIDIA CUDA广泛兼容的生态。Arc Pro B70使用oneAPI/Level Zero，其生态和库支持仍在发展中。 - **多GPU**：R9700在当前驱动/软件下多GPU支持受限（仅llama.cpp），而Arc Pro B70通过oneAPI可能更容易实现多卡扩展，但实际表现也取决于具体软件栈。 - **成本**：两者定价相近（R9700建议零售价$1,299 vs. Arc Pro B70建议零售价约$1,299），但实际市场价格可能有所不同。 ## 无法运行的情况 如前所述，主要的“无法运行”是**原生vLLM多GPU**。具体来说： - **张量并行（TP=2）**：在PCIe连接的RDNA 4上失败。 - **流水线并行（PP=2）**：在当前vLLM v1引擎中因RCCL初始化失败而回归不可用。 - **其他依赖RCCL集合通信的框架或自定义代码**也可能遇到类似问题。 目前，跨多块R9700运行大型模型的唯一验证路径是**llama.cpp**的ROCm后端。 ## 总结：两块R9700 GPU的AI推理表现如何？ 两块AMD Radeon AI PRO R9700 GPU为本地AI推理提供了一个引人注目的、以显存为先的解决方案。凭借总计64 GB的高速显存和强大的单GPU性能，它们能够流畅运行高达8B参数的模型，并以可用的速度运行27B模型。对于更大的模型，量化后可以扩展到70B。 虽然当前软件生态（特别是原生vLLM多GPU）存在明显短板，但通过llama.cpp等替代方案，多GPU推理是可行的。与云API相比，其长期运营成本优势明显。对于需要大显存、高本地隐私性和可控成本的AI推理工作负载，R9700双GPU配置是一个值得考虑的选择。 *（注：本文基于发布时的驱动和软件版本。AMD持续更新ROCm栈，未来多GPU支持可能会改善。）* ## 附录：实践者设置指南 1. **硬件安装**：将两块R9700安装在PCIe 5.0 x16插槽中。确保电源充足（每卡建议至少650W总系统电源）。 2. **驱动与软件**：安装推荐的AMD ROCm版本和兼容内核。测试使用了Rocky Linux 10.1和特定ROCm容器。 3. **虚拟化**（如采用VFIO直通）：在BIOS中启用IOMMU，配置内核参数，并将GPU绑定到VFIO驱动。创建KVM虚拟机并分配GPU。 4. **推理环境**：对于单GPU，使用vLLM容器（`vllm/vllm-openai-rocm:v0.20.2`）。对于多GPU，安装llama.cpp with ROCm backend。 5. **运行模型**：确保模型权重格式与所用软件兼容（FP16、GPTQ、AWQ或llama.cpp的GGUF格式）。 6. **性能调优**：使用HIP图、调整批处理大小和并发设置以优化吞吐量与延迟。监控功耗以了解成本。