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