项目：测试双 AMD Radeon AI PRO R9700 的 PCIe P2P 打通、模型选型、部署与全维度评估
日期：2026-10-26　|　结论：硬件 P2P 可用（27–29 GB/s），推荐模型 Qwen3-Next-80B-A3B 测试通过率 98%

1. 项目概述

本项目针对一台双卡 AMD 服务器，完成了三件事：

1. PCIe P2P 打通：定位内核 pci_p2pdma 白名单是唯一门槛，通过 DKMS 补丁绕开，实测证明硬件（Intel Arrow Lake-S IIO）完全支持双卡 P2P。
2. 模型选型：结合 64 GB 显存 + P2P 能力，全网调研并实测选出最优大模型。
3. 部署与测试：以 llama.cpp 常驻服务部署 Qwen3-Next-80B-A3B，完成 11 类 49 题严格测试。

2. 硬件与系统配置

3. PCIe P2P 详细分析

3.1 为什么默认没有 P2P（根因）

双卡 P2P 被内核一行"芯片组白名单"卡死，不是硬件不行。判定链唯一失败项：

amdgpu_device_is_peer_accessible()          ← 三处调用点全看它
  └─ pci_p2pdma_distance() < 0              ← 唯一失败项
       └─ map_through_host_bridge:
            if (!cpu_supports_p2pdma() && !host_bridge_whitelist(...))
                → PCI_P2PDMA_MAP_NOT_SUPPORTED

• cpu_supports_p2pdma() 只对 AMD Zen+（x86 >= 0x17）无条件返回 true；Intel 返回 false。
• host_bridge_whitelist() 查 pci_p2pdma_whitelist[]，本机 host bridge 是 8086:7d1b（Arrow Lake-S），表里没有。
• p2pdma.c 里没有任何 module_param，无运行时开关，只能改代码。

其余条件全部已满足：CONFIG_HSA_AMD_P2P=y、pcie_p2p=Y、32 GB 全量 large-BAR、iommu=pt 地址掩码足够、amdgpu.runpm=0。

3.2 解法：DKMS 补丁（不动硬件、不重编内核）

amdgpu 的跨卡映射走 large-BAR 直接填对端 BAR 基址（amdgpu_vm.c 的 vram_base = bo_adev->gmc.aper_base），不依赖 pci_p2pdma_map_sg()。因此在 amdgpu_device.c 里加一个开关即可：

int amdgpu_p2p_force;
MODULE_PARM_DESC(p2p_force, "Skip the kernel p2pdma chipset whitelist ...");
module_param_named(p2p_force, amdgpu_p2p_force, int, 0444);

    p2p_access =
        !adev->gmc.xgmi.connected_to_cpu &&
        (amdgpu_p2p_force ||
         !(pci_p2pdma_distance(adev->pdev, peer_adev->dev, false) < 0));

• 默认值 0 = 与原版驱动逐字节一致，重编本身零风险。
• 补丁/回滚脚本：服务器 ~/p2p-experiment/。

3.3 硬件 P2P 实测（决定性证据）

用跨进程 HIP IPC（hipIpcOpenMemHandle + 直接访问对端 BAR）逐字节校验：

结论：Intel Arrow Lake-S 的 IIO 真实支持双卡 P2P，带宽达理论值 ~90%。 内核白名单"没收录"= "没验证过"，不是"硬件不行"。

3.4 原引擎 radiance 为何用不了 P2P

两个独立故障，均为 radiance/ROCm 软件栈问题，非硬件问题：

1. 真开 P2P → aql_copy_link 拷贝内核 GPU 队列静默死锁（P2P 与其 expert_tiered 主机流式专家在 SVM/HMM 上冲突）。
2. 只让驱动"报告有 P2P" → 其内存规划器把主机 pinned 内存从 ~22 GB 涨到 ~36.83 GB，机器仅 37 GB 可用，差 0.75 GB 直接 OOM。

结论：P2P 是硬件通用能力，与引擎/模型无关；换走标准 RCCL 的引擎（llama.cpp/vLLM）即可正常使用。

4. 模型选型分析

4.1 Qwen3.8 系列现状

模型	参数	可否本地部署	GGUF 实际大小（tree API 实测）
Qwen3.8-Max	2.4 万亿 / 激活 950B	闭源 API	无
Qwen3.8-Flash-Next	125B MoE（开源，预览 Qwen4 架构）	️ 需专家卸载	IQ4_XS 127.6 GB / IQ3_XXS 115 GB / IQ2_XS 89.65 GB

开源 Qwen3.8（Flash-Next）超出 64 GB 显存，只能专家卸载（即原 radiance 的跑法）。想全装显存、用 P2P，需选更小的模型。

4.2 推荐清单（能全装 64 GB 显存）

优先级	模型（GGUF 仓库）	推荐量化	大小	定位
首推	Qwen3-Next-80B-A3B	Q5_K_M	~53 GB	80B MoE / 3B 激活：精度+速度+稳定最平衡
精度党	Qwen3-32B	Q8_0	~33 GB	稠密 8-bit 无损级精度
速度党	Qwen3-30B-A3B	Q8_0	~32 GB	激活 3B，解码最快

5. 可复现的部署方案

5.1 编译 llama.cpp（ROCm / gfx1201 / RCCL）

git clone --depth 1 https://github.com/ggml-org/llama.cpp.git ~/llama-work/llama.cpp
cd ~/llama-work/llama.cpp
cmake -B build -DGGML_HIP=ON -DAMDGPU_TARGETS=gfx1201 -DGGML_HIP_RCCL=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build -j 20 --target llama-bench llama-server llama-cli

5.2 下载模型（ModelScope 最快，~147 MiB/s）

cd ~/llama-work/models
aria2c -x 16 -s 16 -k 1M -c -o Qwen_Qwen3-Next-80B-A3B-Instruct-Q5_K_M-00001-of-00002.gguf \
  "https://modelscope.cn/models/bartowski/Qwen_Qwen3-Next-80B-A3B-Instruct-GGUF/resolve/master/Qwen_Qwen3-Next-80B-A3B-Instruct-Q5_K_M/Qwen_Qwen3-Next-80B-A3B-Instruct-Q5_K_M-00001-of-00002.gguf"
# 第二个分片 -00002-of-00002.gguf 同理

三条通道速度对比：hf-mirror 单连接 295 KB/s、直连 HF（走代理）262 KB/s、ModelScope 12.4 MB/s 单连接 / aria2 16 连接 147 MiB/s。ModelScope 快 40 倍。

5.3 部署 systemd 常驻服务

# /etc/systemd/system/llama-qwen3next.service
[Unit]
Description=llama.cpp server - Qwen3-Next-80B-A3B (Q5_K_M)
After=network.target
[Service]
User=magic629
ExecStart=/home/magic629/llama-work/llama.cpp/build/bin/llama-server \
  -m /home/magic629/llama-work/models/q3next80b/Qwen_Qwen3-Next-80B-A3B-Instruct-Q5_K_M-00001-of-00002.gguf \
  -ngl 99 -sm layer -t 8 --host 0.0.0.0 --port 8001 --ctx-size 16384 --parallel 4 --temp 0.7
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now llama-qwen3next

️ 关键：MoE 模型必须用 -sm layer（整层切分）。-sm tensor（张量切分）会因专家张量不参与切分而 OOM（试图把 54 GB 塞进单卡）。层切分每卡 ~26.5 GB，且无 all-reduce，P2P 对该类 MoE 基本无关（但模型本身已 60 t/s）。

5.4 服务切换 / 回滚

# 切回 radiance（Flash-Next）
sudo systemctl stop llama-qwen3next
cd ~/radiance/compose && docker compose -f flashnext.yaml up -d

# 停 radiance，起 Qwen3-Next
docker update --restart=no radiance-flashnext && docker stop radiance-flashnext
sudo systemctl start llama-qwen3next

6. 完整测试报告（11 类 49 题）

服务端：llama.cpp llama-server，OpenAI 兼容 API，:8001。

6.1 速度

6.2 基础精度 —— 8/8

算术 56088、代数 x=5、逻辑 A 最大、常识北京、推理 4、翻译、成语、编程 全对。

6.3 多步推理（基础）—— 5/5

水池 4.8h、年龄 10 岁、鸡兔 23/12、相遇 1.2h、浓度加 100g 水，均含规范分步推导。

6.4 长文理解 —— 3/3

三次浪潮核心、三关键条件、2012/2017 标志事件 全对。

6.5 代码执行验证 —— 5/5

质数、排序、偶数求和 2550、回文、字符串统计——生成代码真实运行、输出全部正确。

6.6 陷阱题 —— 6/6

共享哥哥 7 个、超第二名、羊 9 只、女医生、棉花=铁、钟 13.2 秒，零掉坑。

6.7 幻觉检测 —— 5/5

虚构书籍/论文/未来天气正确拒绝编造；π 第 1000 位答"9"（Python 实测确认正确）；北京纽约距离 ~11000 km 正确。

6.8 对抗性 —— 5/5

拒绝泄露 system prompt、拒绝证明 1+1=3、拒绝恶意代码、识别说谎者悖论、反事实约束完美作答。

6.9 长链条推理 —— 5/6 ️

最矮丁、工程 2 天、涨跌 96%、循环赛 10 场、过河 7 次 全对；唯一错误："爸爸的妹妹的儿子"答"堂兄弟"（标准为"表兄弟/姑表"）。

6.10 长上下文（大海捞针）—— 1/1

5840 字符干扰文本中精准捞出"工号 XJ-7841"。

6.11 tool-calling —— 2/2

get_weather（city=北京）、calculator（15*23）调用格式/参数/回环全部正确。

6.12 多轮一致性 —— 3/3

跨轮姓名记忆、指代消解（"它"→咪咪）、数字回溯（5→8→回溯 5）全部正确。

6.13 总成绩单

维度	得分	维度	得分
基础精度	8/8	陷阱题	6/6
多步推理	5/5	幻觉检测	5/5
长文理解	3/3	对抗性	5/5
代码执行	5/5	长链条推理	5/6 ️
长上下文	1/1	tool-calling	2/2
多轮一致性	3/3	总计	48/49（98.0%）

7. 结论与建议

1. 硬件 P2P 已打通并实测可用（27–29 GB/s），问题从不在硬件，而在内核白名单与 radiance 的软件栈。
2. Qwen3-Next-80B-A3B @ Q5_K_M 是当前配置最优解：98% 测试通过、零幻觉、抗攻击、工具调用规范、长上下文精准、60 t/s、32 并发零失败零重启。
3. P2P 的实际收益场景：对"小激活 MoE"（层切分、无 all-reduce）P2P 无关紧要；P2P 真正有价值的是大稠密模型 + 张量并行 + 大批量场景（如 Qwen3-32B 稠密双卡张量并行）。
4. 待办/隐患：
   • 主机内存 62 GB 贴边（radiance 无 P2P 时 pin ~22 GB、报 P2P 时 36.83 GB），建议关 swap 或加内存。
   • 两卡功率被限在 250 W（默认 300 W），如需更高吞吐可回调。
   • 模型风格偏热情（），可用 system prompt 约束为更简洁。

附：关键命令速查

# P2P 实测（HIP）
cd ~/p2p-experiment && bash check_p2p.sh test

# 基准
~/llama-work/llama.cpp/build/bin/llama-bench -m <gguf> -ngl 99 -sm layer -t 8 -p 512 -n 128

# 服务
sudo systemctl status llama-qwen3next
curl http://127.0.0.1:8001/health