# R9700 多卡企业级部署方案：TP 链路验证 + vllm-radiance + 第三张卡为什么别买

> 单卡 161 tok/s 之后的下一步：TP vs layer split 选型、卡间通信四步验证（ReBAR/ACS/showtopo）、引擎实测对比、锁功耗负面清单、双卡采购决策表

![R9700 多卡企业级部署方案](/assets/articles/lcz/r9700-multi-gpu-enterprise-solution/hero.jpg)

> 单张 R9700 的实测天花板本站已经写透（vllm-radiance MXFP4：prefill 3300 tok/s、decode 峰值 161 tok/s）。这篇解决的是下一步：怎么把 R9700 组建成企业级多卡推理服务——选 TP 还是 layer split、卡间通信链路怎么验、引擎为什么必须用 vllm-radiance、锁功耗和负面清单、以及"第二张/第三张卡什么时候值得买"的采购决策。全文数据来自本站多篇 R9700 实测文章汇总，跨卡参照数据均已标注来源卡。

## 一、为什么是 R9700 打企业级多卡

R9700 的单卡硬指标（本站实测，i5-9600KF + 32GB 双通道主机）：

| 指标 | 实测值 |
| --- | --- |
| 架构 | RDNA4（gfx1201），32GB 显存，256-bit，**576 GB/s 显存带宽** |
| 单卡 prefill（vllm-radiance MXFP4） | **2300-3300 tok/s** |
| 单卡 decode 峰值（vllm-radiance） | **161 tok/s**（思考档 40、编程档 70-80） |
| llama.cpp 基线 | decode 38-51 tok/s，代码任务最高 154 tok/s；prefill 最高 935 tok/s |
| 锁 250W 功耗 | 结温 89-90°C（离热限 20°C 余量），风扇 3340 转，算力零损失 |
| 上下文档位 | 64K/128K/262K 三档实测装得下（25.8GB 顶格） |

企业级的核心诉求有三个，R9700 逐条对应：

1. **容量**：32GB 单卡装 24GB 消费卡装不下的模型，双卡 64GB 直接进 125B 级 MoE 量化区
2. **带宽**：576 GB/s 是 decode 的硬通货——本站实测 IQ4_XS 比 Q4_K_M 少读 13% 权重、速度一点没变，decode 瓶颈在带宽不敏感于权重压缩，卡选对比调参重要
3. **成本**：无 NVLink 依赖（下文实测验证），普通 PCIe 插槽 + 可选 PCIe switch，硬件采购成本远低于同显存 N 卡方案

## 二、多卡架构选型：TP vs layer split，先想清楚再买卡

**单卡装得下就单卡跑，这是第一原则。** 多卡的真实收益场景只有两类：单卡装不下、或要并发。

| 架构 | 机制 | 适合场景 | 通信压力 |
| --- | --- | --- | --- |
| **张量并行 TP** | 每层内切矩阵，每 token 全卡 all-reduce | 单卡装不下 + 多并发服务 | **极高**（消息小、次数密、对延迟敏感） |
| **layer split** | 按层切分，层间传激活 | 容量叠加（专家缓存合起来覆盖路由） | 中（每 verify 窗口传一次，非每层两次） |
| **流水线 PP** | 按 stage 切，流水线气泡 | 超长上下文分段 | 低，但气泡伤延迟 |

layer split 的价值本质来自 Strata 社区双卡实测（来源卡：2× RTX 16GB + 47GB RAM，**非 R9700，做架构参照**）：双卡专家缓存合并后覆盖 ~98% 路由专家，decode 从 30-37 提到 54-61 tok/s 接近翻倍——**本质是把"GPU + CPU 混跑"变成"纯 GPU 跑"，价值是容量叠加不是算力叠加**。同一结论的 N 卡版本（来源卡：2× TITAN RTX）直接验证了**互连完全没用**：有 NVLink 桥接（NV2 拓扑）和没有，数字一样——Strata 类引擎刻意避免 P2P，激活数据通过 pinned RAM 每 verify 窗口传一次。**给 AMD 多卡找"NVLink 等价物"的预算可以省了**，普通 PCIe 插槽就是最优解。

**第三张卡是负优化**（来源卡：RTX PRO 4500 三卡测试，社区结论 #417）：对 decode 零增益，反而拖慢长 prompt prefill——layer split 要跨两个卡边界搬数据，最慢的卡排在最后。**双卡是甜蜜点，三卡以上边际收益为负。**

## 三、TP 的命门：卡间通信链路验证（企业部署八成卡死在这）

TP 的瓶颈不是单卡算力，是卡间 all-reduce 带宽。本站引用的论坛实测数字：

| 链路状态 | 带宽 |
| --- | --- |
| 无 P2P，RCCL 退回 SHM（经主机内存中转） | **约 6.9 GB/s** |
| PCIe switch 直接 P2P | **约 10.3 GB/s**（双向聚合约 19.7 GB/s） |
| 两卡对主机的上行（共享 Gen3 x16） | 约 15.75 GB/s（switch 不会加宽这条） |

**switch 治的是通信，不是算力**——买到的是卡间直连不经主机、延迟更低，顺带绕开老平台 P2P 不通的问题。单请求单卡跑的话，买 switch 基本白花钱。

装完先验证再谈调优，四步：

1. `rocm-smi --showtopo`：两卡 weight/hops，同 root complex 应为 1 跳
2. 跑 `hipDeviceCanAccessPeer`，或 `RCCL_DEBUG=INFO` 看 all-reduce 走的是 P2P 还是 SHM
3. `lspci -vvv` 看路径上 bridge 的 ACSCap/ACSCtl——**ACS 没关是 ReBAR 开着仍不走 P2P 的高频原因**（默认拦不经根复合体的对等访问）
4. 关 ACS 方法：BIOS 有选项就关；没有就 `pci=acs_override` 或 setpci 改 ACS Control 位。注意：两卡各自直连 CPU root port、中间无桥时 ACS 不参与，别白折腾

BIOS 三件套（硬条件）：**Above 4G Decoding = ON、ReBAR = ON、CSM = OFF**。两条插槽都直连 CPU（能拆 x8/x8 的 PCIe 4.0/5.0 即可，不必硬上 x16）——第二个长插槽若实际接芯片组，不行。

**关 ACS = 拿设备间隔离换 P2P 性能，企业多租户环境别关，本机自用/可信环境再关。**

## 四、引擎选型：为什么必须 vllm-radiance

RDNA4 上没有原生 MXFP4 运算单元——原生 ROCm vLLM 跑 MXFP4 会退回 BF16"模拟反量化"，每次 GEMM 先反量化再算，慢 3-5 倍。本站实测的引擎对比（R9700 单卡，Qwen3.8-27B MXFP4）：

| 引擎版本 | prefill | decode |
| --- | --- | --- |
| 某原生 ROCm vLLM | ~1200 tok/s | 最低 15 tok/s |
| llama.cpp（MTP n2） | 最高 935 tok/s | 38-51（代码 154） |
| **vllm-radiance 1.0.15** | **2300-3300 tok/s** | **思考 40 / 编程 70-80（峰值 161）** |

启动后必须确认这三行日志（R4D attention + W4A8 GEMM 全部生效）：

```
Using RadianceMxfp4W4A8LinearKernel for MXFP4 GEMM
[radiance] R4D kernel selection: libr4d 全部 query 解析成功
[radiance.gdn] all-R4D prefill / decode(fused) / prefill+spec path live
```

**假警报提醒**：启动日志会出现一行 `The current platform does not support native MXFP4/MXFP6 computation`——这是 quark 模块另一支 supports_mx() 调用的误报，上游文档已注明，不代表 MXFP4 kernel 没启用。判断真实状态只看上面三行。

最省事的打包镜像（paiton，27B NVFP4 + DFlash2 投机解码全配好，实测 prefill ~3.3k、decode 100-110、260W）：

```bash
docker run -d --name qwen38 --network host --ipc host \
  --device /dev/kfd --device /dev/dri --group-add video \
  -e PAITON_NGRAM_CODRAFT=1 -e RADIANCE_GDN_LAZY=0 \
  -v /data/models/qwen38-nvfp4:/models/target:ro \
  -v /data/models/qwen38-dflash2:/models/draft:ro \
  --restart unless-stopped \
  ghcr.io/eliovp/paiton-vllm-plugin:qwen38-rocm10-vllm029-65k-20260924-r3 \
  serve /models/target --tokenizer /models/target \
  --served-model-name Qwen3.8 --host 0.0.0.0 --port 8080 \
  --tensor-parallel-size 1 --max-model-len 65536 --kv-cache-dtype fp8 \
  --gpu-memory-utilization 0.98 --attention-backend R4D \
  --enable-prefix-caching --enable-chunked-prefill
```

## 五、企业级运维：锁功耗 + 负面清单

**锁 250W 是全文最值的一个调整**（R9700 实测 300W vs 250W 对照）：

| | 300W（默认） | 250W（建议） |
| --- | --- | --- |
| 结温 | 96-97°C | **89-90°C** |
| 显卡风扇 | 3926 转 | 3340 转 |
| FP16 算力 | 127-148 TFLOPS | 113-154（无实质差异） |

降 8°C、风扇少 600 转、算力零损失——AI 推理瓶颈是访存不是算力，多给 50W 只换来更吵。**必须用 systemd 服务写功耗上限，udev 规则会被驱动覆盖**（amdgpu 加载时自己启用 runtime PM 的时序在 udev 事件之后）。

**负面清单（全部实测过，列出来省时间）**：

| 试过的 | 结果 |
| --- | --- |
| `--setperflevel high` | **更差 -23%**，功耗还从 20W 涨到 50W——默认 auto 就是最优 |
| 升级 ROCm 版本 | 无实测收益 + 真实翻车先例（gfx1201 静默回退 CPU，70 → 10 tok/s） |
| 换 Vulkan 后端 | prefill **-30%**（Mesa 25.2.8 已知 RADV 回退） |
| 更小量化（IQ4_XS）换速度 | **零变化**（少读 13% 权重、速度不变） |
| vLLM/SGLang 原生版/TensorRT/ExLlamaV3/LMDeploy/Ollama 等 | gfx1201 上**全线硬阻塞**，别浪费时间试 |
| 第三张卡 | **负优化**（decode 零增益 + 拖慢长 prefill） |

一句话：**ROCm 7.2.4 + 默认 auto + 250W 锁功耗 + vllm-radiance，就是 R9700 的甜点位。**

## 六、采购决策：什么时候买第二张卡

| 场景 | 决策 |
| --- | --- |
| 27B 级单流服务 | 单卡足够（decode 161 峰值）。**不为单流速度买第二张**——层切分不加速单流（本站 profile 实测确认），RDNA4 张量并行不保证收益 |
| 要 125B 级 MoE 容量 | 买第二张。64GB 双卡进量化区，layer split 走容量叠加（架构参照：双卡 decode 接近翻倍） |
| 主脑 + 码农双模型常驻 | 第二张的真实需求点——两模型同时在线互不抢显存 |
| 已有双卡想加第三张 | **别买**，负优化 |
| 要并发服务（多路 agent 调用） | 双卡 TP + PCIe switch（若验证走 SHM 才上 switch），配合 RadixAttention 类缓存树引擎（agent 场景长上下文为主，命中红利大） |

## 结论

R9700 企业级多卡的正确姿势一句话：**单卡装得下就单卡跑；装不下上双卡 layer split 走容量叠加；TP 之前先验 P2P 链路（ReBAR/ACS/showtopo 四步）；引擎必须 vllm-radiance；250W 锁功耗；第三张卡别买。** 全部数字可复核：单卡基线见本站《R9700 单卡真实基线》与《MXFP4 配置实战》，多卡链路见《双卡/多卡 TP 跑通 P2P 完整实战》，layer split 架构参照见《Strata 双卡 layer split》。

*数据出处：本站 R9700 系列实测（2026-09 至 10 月）+ 抡锤者论坛机主实测帖 + Strata 官方仓库社区 benchmark（#384/#389/#392/#417）*


---
来源：https://laobanclaw.top/articles/r9700-multi-gpu-enterprise-solution/（AI 军火库）