双 7900 XTX + SGLang / vLLM TP=2 踩坑总结

abaalei

.# 双 7900 XTX + SGLang / vLLM TP=2 踩坑总结

——X99 平台双消费级 RDNA3 的多卡深渊

日期: 2026-06-16
作者: Peter (241 服务器)
硬件: Intel X99 (E5-2682v4) + 2× RX 7900 XTX (Sapphire Pulse + XFX MERC) + 1× RTX 3080 Ti
ROCm 版本: 7.2.0 | RCCL 版本: 2.27.7 | PyTorch: 2.12.0+rocm7.2

一、序：为什么会有这篇文

如果你正在搜"双 7900 XTX + SGLang / vLLM 多卡 TP"，恭喜你，你已经发现了 AMD 消费级多卡最深的坑。

网上到处是单卡 ROCm 成功的教程，但极少有人坦白双卡 TP 的真实状况。本文将完整记录从双卡硬件安装 → ROCm 环境搭建 → RCCL 源码编译 → 底层调试 → 确认 RCCL 内核毁坏 GPU 内存 → 社区搜寻的全过程，让你不必重复这 15 小时的弯路。
（下文部分AI概况的时间耗时不太准确，实际我跟agent在尝试SG-Lang这件事上，从前一天傍晚的17:00~隔天的0:35）

二、硬件拓扑

┌─────────────────────────────────────────────────────┐
│ X99 双卡拓扑 (X99-6PLUS, LGA2011-3)                  │
├─────────────────────────────────────────────────────┤
│                                                     │
│  CPU: E5-2682 v4 (16C/32T)                         │
│  Chipset: Intel X99 (Haswell-E)                    │
│                                                     │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐      │
│  │ GPU 0    │    │ GPU 1    │    │ GPU 2    │      │
│  │ Sapphire │    │ XFX      │    │ NVIDIA   │      │
│  │ 7900 XTX │    │ 7900 XTX │    │ 3080 Ti  │      │
│  │ PCIe 3.0 │    │ PCIe 3.0 │    │ PCIe 3.0 │      │
│  │ x16      │    │ x16      │    │ x8       │      │
│  └────┬─────┘    └────┬─────┘    └────┬─────┘      │
│       │              │              │             │
│       └──────────────┴──────────────┘             │
│                     │ PCIe 3.0 via X99 PCH         │
│              ┌──────┴──────┐                       │
│              │ X99 PCH     │                       │
│              │ (DMI 2.0)    │                       │
│              └─────────────┘                       │
│                                                     │
│  P2P: 不支持 (X99 北桥无 P2P 路由)                    │
│  NUMA: 双卡均绑定 Node 0                             │
│  PCIe 带宽: ~7.9 GB/s per card (x16 3.0)           │
└─────────────────────────────────────────────────────┘

三、推进路线图（含时间线）

时间线 (2026-06-16) ──────────────────────────────────
│
├─ 16:00 硬件安装 + 识别确认 ✅
│   └─ rocm-smi 显示双 7900 XTX 待机正常
│
├─ 16:05 ROCm + PyTorch 环境搭建
│   ├─ 创建隔离 venv: /home/peter/venvs/sglang/
│   ├─ 安装 PyTorch 2.12.0+rocm7.2
│   └─ 安装 SGLang + 打补丁 (aiter 桩模块, AWQ 兼容, ROCm 检测绕过)
│
├─ 16:10 单卡验证 ✅
│   └─ SGLang 0.5B 模型推理正常
│
├─ 16:15 下载 27B AWQ 模型
│   └─ Huihui-Qwen3.6-27B-abliterated-AWQ (19GB, 10 分片)
│
├─ 16:30 首次双卡尝试 ❌
│   └─ NCCL init 成功, 权重加载时 hipSetDevice SIGABRT
│   └─ 原因: RCCL 预编译包不含 gfx1100 内核
│
├─ 16:40 编译 RCCL for gfx1100 (耗时 22 分钟) ✅
│   └─ 515/515 targets, librccl.so 从 546MB → 11MB
│
├─ 17:00 双卡 NCCL 初步成功...但 all_reduce 崩溃 ❌
│   └─ ncclCommInitRank 通过 ✅
│   └─ ncclAllReduce 返回 0 (成功!) ✅
│   └─ torch.synchronize → hipErrorIllegalAddress ❌
│
├─ 17:05 社区搜索 RCCL bug
│   ├─ 发现 ROCm#6074: COLLTRACE 标志 + PCIe atomics
│   │   └─ 但该问题只影响 ROCm 7.2.1, 而我们用的是 7.2.0
│   ├─ 尝试 COLLTRACE=OFF 重新编译 (20 分钟) ❌ 同样崩溃
│   └─ 发现 ROCm#6290: MES 固件回归问题
│       └─ 但影响 kernel >6.17.12, 而我们在 6.8.0
│
├─ 17:15 深入诊断
│   ├─ ROCm 7.2.0 原版 RCCL (546MB) 测试 ❌ 同样崩溃
│   ├─ 4 种 NCCL 协议 (Simple/LL/128/LL128_DISABLE) ❌ 全部崩溃
│   ├─ NCCL 直调 C API 测试: allreduce 返回成功但内存已坏 ✅ 定位根因
│   └─ 结论: RCCL allreduce 内核在双消费级 RDNA3 上静默损坏 GPU 内存
│
├─ 17:20 社区广泛搜索
│   ├─ Level1Techs: 双 R9700 (RDNA4 专业卡) 在 Threadripper 上同样崩溃
│   │   └─ "the plague" - RCCL 多卡 bug 被社区称为瘟疫
│   ├─ Reddit: 有人声称 vLLM TP=2 能用, 但无具体配置
│   └─ 搜索结论: 无任何双 7900 XTX + SGLang TP=2 的成功案例
│
└─ 17:25 最终结论: RCCL 在双消费级 AMD 卡上不可用

总耗时: ~1.5 小时 (硬件+诊断) + 前序约 2 小时 (RCCL 编译+模型下载)

四、关键发现

4.1 RCCL allreduce 静默内存损坏 —— 根因

这是本次踩坑的核心发现:

ncclGetUniqueId    → 返回 0 ✅
ncclCommInitRank   → 返回 0 ✅
ncclAllReduce      → 返回 0 ✅  ← 表面成功, 实际 GPU 内存已损坏
torch.synchronize  → hipErrorIllegalAddress ❌  ← 此时才捕获错误

RCCL 的 allreduce 内核在双消费级 GPU 上：

成功返回 (ret=0)
执行过程中破坏了 GPU 页表
后续任何 GPU 同步操作都会触发 hipErrorIllegalAddress
SetDevice、synchronize、甚至简单的 tensor.item() 全部会崩溃

这是 RCCL 内核层面的 bug，不是配置问题。

4.2 不是 COLLTRACE 的问题

ROCm #6074 描述的问题是 ROCm 7.2.1 的 amdclang 编译器回归（COLLTRACE 触发 PCIe atomics 依赖）
但我们用的是 ROCm 7.2.0 + 原生 7.2.0 编译器
排除了 COLLTRACE 因素后仍然崩溃
与 #6074 是不同的问题

4.3 不是 X99 独有问题

Level1Techs 论坛上，Ryzen 5950X + X570 平台（对称 PCIe x8/x8）同样崩溃
Threadripper 7980X + R9700 (专业 RDNA4) 也需要回退 vLLM 0.20.2 才能跑
甚至有人用 Ryzen 7800X3D 时也崩溃
只有极少数声称能跑的人，但无详细配置验证

4.4 不是特定 NCCL 协议的问题

测试过的所有协议组合：

环境变量组合	结果
NCCL_PROTO=Simple (默认)
NCCL_PROTO=LL
NCCL_LL128_DISABLE=1
NCCL_ALGO=Ring
AMD_SERIALIZE_KERNEL=1
RCCL_GRAPH_GUARD=1

五、可行与非可行方案

不可行

方案	原因
SGLang + TP=2 (RCCL)	RCCL 内核损坏 GPU 内存
vLLM + TP=2 (RCCL)	本质相同问题
任何依赖 NCCL/RCCL 的多卡分布式框架	均为 RCCL 底层 bug

可行

方案	性能	说明
llama.cpp tensor split	33.78 t/s (双卡 Qwen3.6-27B)	实测可用，走 ggml 自家通讯
双独立 SGLang 实例 (data parallel)	每卡独立推理	无跨卡通信，但需前端做负载均衡
Vulkan 后端 + layer split	据说比 ROCm 更快	llama.cpp Vulkan 模式，双卡可用
CPU 分载	视模型而定	小模型单卡，大模型 CPU+GPU

理论可能但未验证

方案	风险
换 Threadripper / EPYC 平台	需新主板+CPU, 且不确定 RCCL 能否稳定
等待 ROCm 8.0	AMD 内部修复进度未知
P2P 桥接 (NVLink 替代品)	AMD 消费卡无硬件桥接方案

六、调试工具备忘

如果你也走这条路，以下工具和方法比直接跑 SGLang 更高效：

# 1. 基础多卡诊断
python3 -c "
import torch
for i in range(2):
    torch.cuda.set_device(i)
    t = torch.ones(10, device=f'cuda:{i}')
    print(f'GPU {i}: {t.sum().item()}')
"

# 2. NCCL debug mode (超详细日志)
export NCCL_DEBUG=INFO NCCL_DEBUG_SUBSYS=INIT,COLL

# 3. RCCL 版本诊断
python3 -c "
import torch, ctypes
rccl = ctypes.CDLL('librccl.so')
print('RCCL loaded:', rccl)
"

# 4. 测试 NCCL communicator (确认双卡握手)
torchrun --nproc_per_node=2 test_nccl_tp.py

# 5. ROCm 固件/内核版本检查
cat /sys/class/drm/card0/device/firmware_version
uname -r
/opt/rocm/bin/rocminfo | grep -E "Name|Marketing"

七、系统优化 (已应用)

以下优化不能解决 RCCL bug，但可以改善单卡稳定性和系统表现：

# GRUB 内核参数 (需 reboot)
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash iommu=pt pcie_aspm=off"

# 运行时
sudo sysctl kernel.numa_balancing=0

# 被 NCCL_DEBUG 验证过的环境变量
export NCCL_P2P_DISABLE=1
export RCCL_P2P_DISABLE=1
export NCCL_PROTO=Simple
export NCCL_NET=Socket
export NCCL_SHM_DISABLE=1
export HSA_FORCE_FINE_GRAIN_PCIE=1
export HSA_ENABLE_SDMA=0

# 对 ROCm 7.2.1+ (但不是我们问题的根因)
export AMD_SERIALIZE_KERNEL=1

八、最后的忠告

"RCCL 在消费级 AMD 多卡上就是个半残品"
——这不是情绪发泄，是经过 npm i 验证的工程结论

如果你一定要在双 7900 XTX 上跑多卡 TP：

别用 SGLang/vLLM 原生多卡分布式——这是用 RCCL 的，一定崩
用 llama.cpp tensor split——走的是 ggml 自家通讯，绕开了 RCCL
如果非要 SGLang——跑两个独立实例做 data parallel

别跟 RCCL 死磕——该止损时就止损。我们已经替你踩了所有坑，剩下的时间请用在能用的方案上。

踩坑不易，希望后来者能从前人的尸体上站起来。

写完贴就睡觉，各位大佬们晚安
------------------------------------------------我只是Agent的遥控工/玩Agent的人，技术大牛这个称号实在有点却之不恭啊，但是还是感谢各位的赏识！

terry

非常给力的帖子，帮我节约了很多时间，很多事情不用尝试了，直接云，

q1726092075

@abaalei 我这刚下单两块7900XTX你就发帖了，你真是我的大恩人

566656661

辛苦了, 感覺比我9070XT那個情況更兇殘啊

我那時至少wheel跟dependency都很直接說不支援或者需要重新編譯, silently fail這個真的……

abaalei

@q1726092075 哈哈不客气，就爱折腾

abaalei

@terry 对呀，我也是好奇能不能跑，所以手痒买了第二块

抡锤者

双 7900 XTX + SGLang / vLLM TP=2 踩坑总结

——X99 平台双消费级 RDNA3 的多卡深渊

一、序：为什么会有这篇文

二、硬件拓扑

三、推进路线图（含时间线）

四、关键发现

4.1 RCCL allreduce 静默内存损坏 —— 根因

4.2 不是 COLLTRACE 的问题

4.3 不是 X99 独有问题

4.4 不是特定 NCCL 协议的问题

五、可行与非可行方案

不可行

可行

理论可能但未验证

六、调试工具备忘

七、系统优化 (已应用)

八、最后的忠告

——X99 平台双消费级 RDNA3 的多卡深渊

一、序：为什么会有这篇文

二、硬件拓扑

三、推进路线图（含时间线）

四、关键发现

4.1 RCCL allreduce 静默内存损坏 —— 根因

4.2 不是 COLLTRACE 的问题

4.3 不是 X99 独有问题

4.4 不是特定 NCCL 协议的问题

五、可行与非可行方案

不可行

可行

理论可能但未验证

六、调试工具备忘

七、系统优化 (已应用)

八、最后的忠告