@abaalei 感觉x99还是太老了，epyc应该下一个娱乐场

@terry 现在问hermes 直接入给我说是我硬件不支持了。大概的意思就是我硬件层pci-e 直接到cpu 。cpu或芯片组不带路由功能。如果想实现，就要在显卡到cpu之间，加一个路由层，比较plx交换，这也是猜测可行。现在这种折腾不值得了，内存下来了，可能就直接换epyc的平台了。

看着视频，学着大神的贴子对于“魔改SGLANG支持7900XTX 双卡TP”的坎坷学习路，还是总结了一下，指点。活都是ai做的，我就是跟在ai操作下学习一下方法。哈。下面是正文

【踩坑实录】双 7900XTX 跑 SGLang TP=2 —— 从物理挪卡到裸机 LXC 验证，X99 平台 TP 死局全记录

2026-09-07 ~ 2026-09-09 · 三天折腾，结论：平台死，不是软件锅
硬件：X99-T8D 双路 E5-2696v3 + 2× RX 7900 XTX + PVE 9.2
目标：双卡张量并行（TP=2）跑 SGLang 魔改 fork（gfx1100 分支）

---

一、结果先讲

TP=2 方向关闭。死因：Intel X99 root complex 不支持 GPU 间 P2P 路由。

软件栈全装通了（ROCm 7.14 + torch 2.11 + fork 编译 + 模型加载都过了），死在最后一关：双卡通信实测 hipDeviceCanAccessPeer = NO。

不是 VFIO 的问题（LXC 验证了），不是虚拟化层的问题（LXC 等价裸机也验证了），是 Intel 平台硬件本身就没有这个能力。

---

二、踩坑顺序（重点：我走的路径全是错的顺序）

阶段 0（错）：先装软件，后查硬件

这是最大的坑。我花了一天时间装 ROCm 7.14、torch 2.11、SGLang fork 编译，结果最后 5 分钟就能查出来的问题，让我先走了几天弯路。

正确的顺序应该是：先查硬件 P2P 能力，再决定要不要装软件。

5 分钟硬件预检命令：

# 1. 两卡是否在同一个 CPU socket 下？
lspci -D | grep -iE "vga|3d controller"
# 看 bus 号：0x:xx = CPU0 域，8x:xx = CPU1 域
# 如果一张 04:00 一张 86:00 → 跨 CPU socket，TP 直接判死

# 2. IOMMU group 是否独立？
for d in <gpu1_bdf> <gpu2_bdf>; do
  echo "$d -> group $(basename $(readlink /sys/bus/pci/devices/$d/iommu_group))"
done
# 如果两张卡在不同的 IOMMU group → 没有 peer DMA 路径

这两个检查如果一开始就做了，三天变三小时。

---

阶段 1：初始报错 —— 双卡不在同一 CPU

VM104 里装好了 ROCm 7.14 + fork，启动 SGLang TP=2，直接报错：

RCCL error: communication failure between GPUs

当时的误判：以为是软件配置问题，开始查 RCCL 环境变量、torch 版本匹配、编译参数。

实际原因：两张卡分别在 CPU0（bus 04）和 CPU1（bus 86）下，跨 socket 通信走 QPI/UPI，PVE 直通下没有 peer DMA 路径。

---

阶段 2：物理挪卡 —— 同一 CPU 下还不行

操作：把原来挂在 CPU1 侧的卡拔下来，插到 CPU0 侧空着的 x16 槽里。

验证（重启后）：

• 卡1：04:00.0 → CPU0-Port2（Gen3 x16）
• 卡2：07:00.0 → CPU0-Port3（Gen3 x16）

两张卡都挂在 CPU0 下了。但 TP=2 还是不通。

为什么同 CPU 还不够？

两张卡虽然在同一 CPU，但：

1. 各挂一个独立的 root port（00:02.0 和 00:03.0）
2. 各属一个独立的 IOMMU group（54 和 58）
3. 每张卡还经过板载 Navi10 PCIe 交换芯片（板上的 retimer）

IOMMU 的 peer DMA 隔离是按 group 切的，跨 group 默认拒绝。要两卡同 group，必须挂在同一个 PCIe switch 的下游（x8+x8 拆分），X99-T8D 的布局做不到。

教训：同 CPU 是 P2P 的必要条件，不是充分条件。还需要同 IOMMU group（同 PCIe switch 下游）。

---

阶段 3：怀疑虚拟化层（VFIO）

当时的逻辑（后来被 hermes 验证是对的推理方向）：

• vfio-pci 直通本身不做跨设备 peer DMA
• guest 内核看到的 PCIe 拓扑是 QEMU 伪造的（BDF 重编成 01:00/02:00，不是物理 BDF）
• 所以 VM 里测试 NO 不能证明物理机也 NO

验证方案：不重装系统（代价太大），用 LXC 容器代替。

为什么 LXC 能模拟裸机？

• LXC 容器共享宿主内核，没有自己的内核
• GPU 不需要 vfio 直通，宿主直接用 amdgpu 驱动
• 容器里的 ROCm 用户态通过 /dev/kfd + /dev/dri 访问 GPU
• KFD 看到的是宿主真实的 PCIe 拓扑
• 等价于裸机的硬件条件

操作步骤：

1. 改宿主 modprobe 配置：GPU 从 vfio-pci 切回 amdgpu
2. 重启宿主（冷启动，不能热切！）
3. 建 LXC 200（Ubuntu 24.04），放行 /dev/kfd + /dev/dri
4. 容器内装 ROCm 7.14 用户态
5. 跑 HIP 测试程序

LXC 实测结果：

hipDeviceCanAccessPeer(0→1) = NO
hipDeviceCanAccessPeer(1→0) = NO
KFD p2p_links 目录为空
跨卡 memcpy = 3.1 GB/s（纯主机内存中转）

结论：虚拟化不是原因。Intel X99 root complex 本身就不提供 GPU 间 P2P/原子路由。

BIOS 能救吗？ 不能。

• Above 4G Decoding（大 BAR）已开（唯一的前提条件）
• Intel X99 平台没有 "enable P2P" 选项（这类选项不存在于 Intel 平台）
• root port 的 AtomicOpsCap = Routing-（实测），这是芯片能力，BIOS 改不了

---

三、最终根因

Intel Haswell-EP 的 root complex 没有 GPU 间 peer DMA 路由能力。

• AMD 平台的 GMI/infinity fabric 北桥原生支持 peer 路由
• Intel 平台的 RC 不支持（或支持极弱）
• 两张卡的数据路径必须穿过 root complex
• Intel RC 不提供 GPU 间直连路由

对照成功案例：所有 GPU P2P 跑通的案例都是：

• AMD 单路平台（AM4/AM5/TRX40/TRX50），GMI 原生 peer 路由
• 或加 PLX 交换卡，两卡挂到同一 switch 下游（绕开 RC）

Intel X99/Z270 等消费/工作站平台：无成功先例。

---

四、必须避的坑（按重要性排序）

坑 1：先装软件再查硬件（最大坑）

错误：装了一天的 ROCm + fork，才去查硬件
正确：5 分钟跑完硬件预检，再决定要不要装软件

# 5 分钟预检脚本
echo "=== GPU BDF 和 CPU socket 归属 ==="
lspci -D | grep -iE "vga|3d"
for d in $(lspci -D | grep -iE "vga|3d" | awk '{print $1}'); do
  bus=${d%%:*}
  if [[ $bus < 0x80 ]]; then
    echo "$d → CPU0 域"
  else
    echo "$d → CPU1 域"
  fi
done

echo "=== IOMMU group ==="
for d in $(lspci -D | grep -iE "vga|3d" | awk '{print $1}'); do
  grp=$(basename $(readlink /sys/bus/pci/devices/$d/iommu_group) 2>/dev/null)
  echo "$d → group $grp"
done

如果两卡跨 CPU 或跨 IOMMU group，直接停止，TP 方向关闭。

坑 2：同 CPU ≠ 有 P2P

错误：以为把两张卡挪到同一 CPU 就能通
正确：同 CPU 是必要条件，还需要同 IOMMU group

X99-T8D 的两个独立 root port（00:02.0 和 00:03.0）分属两个 IOMMU group，
即使物理位置都挂在 CPU0 侧，照样没有 peer DMA。

坑 3：VFIO 直通天然不支持 peer DMA

错误：以为 VM 里 P2P 不通是虚拟化层的锅，去折腾 VFIO 配置
正确：VFIO 直通设计上就不支持跨设备 peer DMA，这不是配置问题

即使物理机能通，VM 直通也通不了（除非用 vIOMMU + 特殊内核支持，PVE 不支持）。

坑 4：LXC 能模拟裸机，但不救平台

LXC 验证的意义是排除虚拟化层的干扰，确认"裸机也不行"。
但如果平台本身不支持 P2P（如 Intel X99），LXC 也救不了。

坑 5：驱动热切换会锁卡

错误：vfio → amdgpu 热切换（echo "..." > /sys/bus/pci/drivers/vfio-pci/unbind）
正确：必须冷启动（改 modprobe 配置后重启）

热切换可能导致 GPU 进入 D3hot 状态无法唤醒，PCI reset 都救不了，只能重启宿主。

坑 6：PCIe 速率看错位置

错误：看 GPU 端点的 lspci 输出（显示 16GT/s x16）
正确：看 root port 侧（真实槽速）

GPU 端点显示的速率是"卡内 switch → 卡"那一段，不是端到端速率。
真实瓶颈在 root port 侧（8GT/s Gen3），以 root port 的 LnkSta 为准。

坑 7：ROCm 版本和源（装软件阶段）

如果决定装软件，注意：

• ROCm 7.14 的源在 repo.amd.com/rocm/packages-multi-arch/ubuntu2404
• 包名带版本后缀：amdrocm-core-dev7.14-gfx1100
• torch wheel 要 curl 直接下（flat 目录不是 pip 索引），不能 pip install --index-url

坑 8：PVE 双卡直通 romfile 冲突

错误：两张卡共用同一个 romfile
正确：必须复制一份异名的 rom（如 7900XTX_dump.rom 和 7900XTX_dump2.rom）

---

五、排查正确顺序（建议存为 checklist）

双卡 TP 可行性排查（5 分钟版）：

1. CPU socket 检查
   lspci -D | grep -iE "vga|3d"
   → 两卡 bus 号一个 0x:xx 一个 8x:xx？
   → YES = 跨 CPU，TP 判死，停止

2. IOMMU group 检查
   for d in <gpu1> <gpu2>; do
     basename $(readlink /sys/bus/pci/devices/$d/iommu_group)
   done
   → 不同 group？
   → YES = 无 peer DMA 路径，TP 判死，停止

3. 平台检查
   主板是 Intel X99/Z270/X299 等？
   → YES = 无 P2P 成功先例，TP 判死，停止

4. （以上全通过才继续）
   装软件 → 实测 hipDeviceCanAccessPeer

走完前三步，能省掉 90% 的无谓折腾。

---

六、那这两张卡还能干嘛？

TP 死局，但两张卡不是废铁：

1. 双实例并行（推荐）
   每张卡各跑一个独立的单卡推理服务，互不通信

   • VM102 跑模型 A
   • VM103 跑模型 B
   • 两卡各自满载，总吞吐 = 2× 单卡吞吐
   • 这是当前拓扑下性价比最高的用法

2. llama.cpp 分层并行（--split-mode layer）
   各卡独立计算不同层，卡间只传激活值（走 CPU 内存中转）

   • 不要求 P2P，3.1 GB/s 够用
   • 社区有 5×7900XTX 长期稳定运行的先例
   • 双卡 48GB 显存可跑 ~48GB 权重模型

3. 换平台（如果有 TP 刚需）

   • AMD AM5 单路（X670E 等），双卡 x8+x8，GMI 原生 peer 路由
   • 或加 PLX PEX 交换卡（成本高，X99 槽位/散热不友好）

---

七、总结

阶段	操作	结果	教训
1	装 ROCm + fork	编译过，import 过	顺序错了，应先查硬件
2	VM104 启动 SGLang	RCCL 通信崩	跨 CPU socket，无 P2P
3	物理挪卡到同 CPU	还是不通	同 CPU 不够，还要同 IOMMU group
4	怀疑 VFIO 层	LXC 验证	虚拟化不是原因
5	LXC 原生 amdgpu	还是 NO	平台本身不支持
6	查 root port 能力	AtomicOpsCap = Routing-	Intel RC 无 peer 路由

核心教训：

1. 先硬件后软件，5 分钟预检省三天弯路
2. 双路主板跨 socket 无 P2P，结构性死局
3. 同 CPU 同 IOMMU group 是 P2P 的两个必要条件，缺一不可
4. Intel 消费/工作站平台无成功先例
5. 换平台（AMD 单路）是最实际的解法

---

本文已脱敏（无 IP、无具体用户名、无内部系统标识），可直接发技术社区。 现在ai真是贴心。

现在唯一有可能的就是把一条pci-e的x16拆分为8*8 用8654转接卡，去连接2张显卡，我感觉 能跑通，但是没有意义，本来pci-e 3(x99)中x16带宽就是瓶颈。所以，这样操作下来，一点意义都没有。

今天 SGLang 双卡部署的总结（已去掉 IP 等敏感信息，去掉原帖内容）：
═══════════════════════════════════════════
一、最后结果
═══════════════════════════════════════════

1. SGLang 双卡 TP=2 在本平台不可行，方向正式关闭。
   卡点不是软件：ROCm 7.14 + torch 2.11 + SGLang 魔改 fork（gfx1100-support）全部装通，编译过、import 过、模型加载过，死在最后一关——双卡通信（hipDeviceCanAccessPeer = NO）。
2. 根因是平台硬伤，不是配置问题：
   Intel X99 双路主板的 root complex 没有 GPU 间 P2P 路由能力，两卡分属两个独立 root port、两个 IOMMU group，数据只能经 CPU 内存中转，实测跨卡 3.1~6.9 GB/s（正常 TP 平台是 32~900 GB/s，差 10~300 倍）。
3. 环境已全部还原并验证（实测确认）：
   • 两台推理 VM（GPU0/GPU1）恢复单卡直通，均 running
   • 两台 llama-server 的 /v1/models 均正常返回 qwen3.8-27b
   • 双卡回到 vfio-pci，双卡测试 VM 的直通配置已清空
   • 双卡均设 onboot=1，宿主重启后自动恢复
   • 配置备份保留在宿主 /root/gpu_restore_102103_20260909_2054
     ═══════════════════════════════════════════
     二、硬件平台
     ═══════════════════════════════════════════

• 宿主：pve001，华南 X99-T8D 双路主板，2× E5-2696v3（Haswell-EP，PCIe 3.0），PVE 9.2.6
• GPU：2× RX 7900 XTX（gfx1100/RDNA3，24GB），每卡经板载 Navi10 交换芯片挂到独立 root port
• 测试载体：
  • VM104：Ubuntu 24.04.4，双卡 vfio 直通
  • LXC 200：宿主原生 amdgpu 驱动（模拟裸机条件）
  • VM102/103：还原后各持一卡，llama.cpp Vulkan
    ═══════════════════════════════════════════
    三、问题链（踩坑顺序，后人照这个避）
    ═══════════════════════════════════════════
    阶段 0：装环境（9/7~9/8）

1. ROCm 版本坑：fork 要求 ROCm 7.14，但官方常用源的 ubuntu2404 目录里只有 10.0，7.14 的正确源是 repo.amd.com 的 multi-arch 目录，包名带版本后缀。
2. torch wheel 下载坑：pytorch.org 断流；AMD manylinux 源是 flat 目录不是 pip 索引，pip --index-url 会报 No matching distribution，必须 curl 直接下 wheel 再本地装。
3. fork 源码 bug：moe_q_gemm_rdna3.cu 里 half2 z_h[4] 在 ROCm 7.14 clang 下编译失败，须改成 z_h[4][2]；且必须改 .cu 源文件（.hip 是 hipify 产物会被覆盖）；不能把该文件从构建里剔除（链接期 undefined symbol）。
4. CUDA 污染坑：pip editable install 会顺手拉 CUDA 版 torch 覆盖 ROCm 版，装完必须 force-reinstall 回 rocm wheel 并卸载 nvidia 相关包。
5. PVE 双卡直通坑：两卡共用同名 romfile 会报 duplicate fw_cfg file name，必须复制一份异名 rom。
   阶段 1：P2P 验证（9/9 上午）
6. VM 内实测：hipDeviceCanAccessPeer 双向 NO，rocm-smi topo 矩阵 False/False → VM 直通路径判死。
7. 怀疑是虚拟化层问题（vfio 不做 peer DMA、guest 看到的是伪造拓扑），决定验证"裸机能不能通"。
   阶段 2：裸机/LXC 路径（9/9 中午）
8. 新问题——卡锁死：vfio→amdgpu 热切换测试中，卡 2 进入 D3hot 无法唤醒，PCI reset 都阻塞，内核多进程卡在 SMU 通信上，只能重启宿主恢复。（教训：换驱动要冷启动，别热切）
9. 建 LXC 走宿主原生 amdgpu（最接近裸机）：实测 hipDeviceCanAccessPeer 依然 NO，KFD 的 p2p_links 目录为空，跨卡 memcpy 3.1 GB/s（纯主机中转）。
10. 结论钉死：虚拟化不是原因，Intel X99 root complex 不给 GPU 间 P2P/原子路由。BIOS 也无开关可解（Above 4G 已开，唯一前提已满足，剩下是硬件能力问题）。
    阶段 3：收尾（9/9 下午~晚上）
11. 还原：双卡回 vfio，VM102/103 恢复单卡直通 + onboot=1，VM104 清 hostpci，重启宿主，验证 API 恢复。
    ═══════════════════════════════════════════
    四、给后来人的五条血泪教训
    ═══════════════════════════════════════════
12. 双卡 TP 先查硬件再装软件：5 分钟命令（hipDeviceCanAccessPeer + lspci IOMMU group）能救几十小时的装环境时间。这次是反着来的，白折腾。
13. 双路主板（X99/EPYC 双路）跨 CPU socket 的双卡没有 P2P，结构性不可行。
14. 即便两卡挪到同一 CPU 下，只要挂在两个独立 root port、不同 IOMMU group，照样没有 P2P。今天特意做了这个验证——白费。
15. Intel 消费/工作站平台（X99/Z270 等）无 GPU P2P 成功先例；成功案例全是 AMD 单路平台（原生 peer 路由）或 PLX 交换卡拓扑。
16. 看 PCIe 速率以 root port 侧为准：GPU 端点 lspci 显示 16GT/s x16 是卡内 switch 那段，真实槽速是 root port 的 Gen3（8GT/s），两头看结论完全不同。

@Rex 我理解的意思是，他2张显卡，一个用于27b的模型，一个用于跑图（comfyui）

不知道双路的x99会不会在pic通道上会好一些呢。

贴子真是全全的干货。学习中

如果除了comfyui只能单卡外，纯跑模型，有必要双卡或是三卡7900xtx嘛

我也是初学者，7900xtx 尝试过llama.cpp 最简单，也最有效率，vllm这个就比较绕，有很多环境要单独下rocm的版本。模型对gguf的好像支持不是太好。主要是现在gguf的量化比较好，能把模型控制在24G以内。最后还是停留在了llama.cpp上。有时间了继续学习vllm毕竟如果想多并发。还得是用它。