@张光璞 说:

@laobenxiong 说:

今天还发现那张闲鱼卡, 当功耗超过300w时有一点高频噪音, 不知道什么原理.

pcie 交换机发热巨大，你这样倒扣能行？？

嗯, switch 发热量大, 所以把它移到机架上了. 小主机里面的是换了一张单独的转接卡.

@kos-or 说:

這個太厲害了 , 還沒用過這種PCIe 轉接卡
這看起來像是三個不同型號的轉接卡 請問會有效能差異嗎？ 有沒有推薦的型號 以後說不定會用到

长一点的卡: 一个电源需要一个, 它接着24+4的线, 可以控制电源的开关;
其它两个短的就不再需控制电源了, 直接从PSU取电就行. 品牌无所谓, 哪个便宜买哪个.

@番茄胡萝卜 说:

那些球是干什么用的？我和AI都陷入四十分钟的思考。而且没有结果

杂耍球, 有乒乓球, 匹克球, 等. 相当于沙包. 预防老年痴呆.

@fcys 说:

刚看过油管视频，过来分享一下我的双卡硬件思路。要同时解决体积和散热还是得改液冷，广东室温30度，两张A卡跑满，结温不高于80度。冷排风扇和侧板风扇都是160的，恒定700转，距离1米以上听不到任何声音。当然改液冷对咱们普通消费者来说往往意味着丧失质保，这一点需要取舍，但是使用感受真的是比风冷好太多了。顺带提醒一个坑，冷板一定要全铜焊接的，不要用其他材质，也不要用密封圈锁固的密封方式，现在配件价格这么高，一旦漏液就不值当了。

还是限制功率比较好，70% ~100% 的功率变化 ，实际性能提升可能只有10%

@laobenxiong 说:

今天还发现那张闲鱼卡, 当功耗超过300w时有一点高频噪音, 不知道什么原理.

pcie 交换机发热巨大，你这样倒扣能行？？

@番茄胡萝卜 说:

那些球是干什么用的？我和AI都陷入四十分钟的思考。而且没有结果

口球

@laobenxiong 说:

搞了个开放式机架, 折腾了好一阵, 勉强装好了.

pci switch 卡由于散热片太高, 小主机盖不上. 所以又弄了个转接卡, 好在都是便宜货, 值不了多少钱, 就是瞎折腾

今天还发现那张闲鱼卡, 当功耗超过300w时有一点高频噪音, 不知道什么原理.

以我在外网高强度冲浪得知： 线材对卡间通讯速度至关重要。

pci switch 卡由于散热片太高, 小主机盖不上. 所以又弄了个转接卡, 好在都是便宜货, 值不了多少钱, 就是瞎折腾

今天还发现那张闲鱼卡, 当功耗超过300w时有一点高频噪音, 不知道什么原理.

实际性能怎么样, 正确性咋滴, 由于还没怎么用, 所以没啥感觉.
我还是要先把硬件搞一搞.

btw, 我为此搞了一个 fork; 都是 AI 干的, 我自己云里雾里的....

一、TP=2 时两卡都 ~100%，推不出「带宽不是瓶颈」。
rocm-smi / nvidia-smi 的 GPU use% 只统计「有没有 kernel 在跑」，不区分 kernel 在算还是在等。TP 的 all-reduce 本身就是个常驻 kernel，通信时 SM 照样被占着，读数自然 100%。要判通信是不是瓶颈，看三样：

1. 扩展比：TP=2 相对单卡的 decode 吞吐。dense 27B 跑在 x8 链路上，1.5–1.7x 属正常，低于 ~1.4x 才说明通信拖后腿。
2. 实链路带宽/延迟：rccl-tests 的 bus BW，和协商速率对一下（gen3 x8 单向约 7–8GB/s）。再用 RCCL_DEBUG=INFO 确认走的是 P2P 还是退化成 host-staged/SHM。
3. 通信暴露占比：nsys/rocprof 看每步 all-reduce 耗时 / 总步时。batch=1 时消息小，占比重但主要是延迟（kernel 启动 + RCCL 同步），不是带宽；batch 大了才轮到带宽说话。所以「带宽」和「延迟」要分开测。

二、单卡 gen1x8 利用率上不去、gen2x8 就 ~100%，这反而说明 PCIe 在卡它。
单卡正常推理权重全在 VRAM，每 token 的计算不经过 PCIe，链路速率本来不该影响 util。你观察到 gen 直接决定 util，基本只有一个解释：有数据在过 PCIe——要么有层 offload 到 CPU（--n-gpu-layers 没拉满或显存不够），要么 KV / 部分 buffer 落在 GTT（ROCm 下 RDNA3 常见），每个 token 都要 Host-GPU 搬。gen1x8 约 2GB/s 喂不饱，GPU 大量时间在等传输，util 就低；gen2x8 翻倍喂得上，util 回 100%。这跟 TP 时 util 100% 不矛盾，是两种不同的「在等」。

三、你这台的链路本身。
两卡挂在同一个 gen3 switch 的两个下游口（--showtopo 里 hop=2、weight=40 就是过 switch 的代价），上游再共享一条 x8 到 host。互传能在 switch 内转发、不用上根桥，但仍受 switch fabric 和当前协商速率（现在每卡只到 gen2 x8）限制。先按你说的换短 8654 线把 gen3 x8 谈起来，然后单卡基线 → rccl-tests → SGLang TP=2 的 pp/tg 三份数据贴上来再定。TP 能不能到 1.6x，取决于模型是 dense 还是 MoE、batch 和 ctx 多长，实测比猜准。

现在TP 能有1.6x 吗？

还没测呢. 等有了结果再汇报哈.

回头换短一点的 8654 8i线看看能不能救回 gen3x8. 另外我还有一个疑问@xiaote 如果跑TP=2的时候两张卡的gpu利用率都是~100%, 是不是说明它们之间的带宽不是瓶颈? 另外, 我单张卡测试的时候(llama.cpp), 发现如果 gen1x8, gpu的利用率上不去, 到了gen2x8就可以~100%了.

现在TP 能有1.6x 吗？

bruin@m920x ~ $ rocm-smi --showtopo


============================ ROCm System Management Interface ============================
================================ Weight between two GPUs =================================
       GPU0         GPU1
GPU0   0            40
GPU1   40           0

================================= Hops between two GPUs ==================================
       GPU0         GPU1
GPU0   0            2
GPU1   2            0

=============================== Link Type between two GPUs ===============================
       GPU0         GPU1
GPU0   0            PCIE
GPU1   PCIE         0

======================================= Numa Nodes =======================================
GPU[0]          : (Topology) Numa Node: 0
GPU[0]          : (Topology) Numa Affinity: -1
GPU[1]          : (Topology) Numa Node: 0
GPU[1]          : (Topology) Numa Affinity: -1
================================== End of ROCm SMI Log ===================================
bruin@m920x ~ $ rocm-smi --showtopoaccess


============================ ROCm System Management Interface ============================
========================== Link accessibility between two GPUs ===========================
       GPU0         GPU1
GPU0   True         True
GPU1   True         True
================================== End of ROCm SMI Log ===================================

回头换短一点的 8654 8i线看看能不能救回 gen3x8. 另外我还有一个疑问@xiaote 如果跑TP=2的时候两张卡的gpu利用率都是~100%, 是不是说明它们之间的带宽不是瓶颈? 另外, 我单张卡测试的时候(llama.cpp), 发现如果 gen1x8, gpu的利用率上不去, 到了gen2x8就可以~100%了.

[00] 00.0 CoffeeLake Host Bridge (Root)
└── 01.0 ← Root Port
└── [01] 00.0 ← ★ PCIe Switch 上游口（6 口 switch）
├─ [02] 08.0 (下游口) → 04.0 → [04] 00.0 → [05] 00.0 Navi31 卡1
├─ [02] 09.0 (下游口) → 07.0 → [07] 00.0 → [08] 00.0 Navi31 卡2
├─ [02] 10.0
├─ [02] 11.0
├─ [02] 12.0
└─ [02] 13.0
判定依据：00.0-[02-0c]（bus 01 上的 00.0）有 6 个下游端口（08/09/10/11/12/13 都在 bus 02）——这是典型的 6 口 PCIe switch。两块卡（bus 05、bus 08）都从同一个 switch 的两个不同下游口下来。

结论：两卡之间的 P2P 流量可以在 switch 内部转发，不用上到 Host Bridge/RC。

对比 T7910：那台是两卡各挂独立 root port（过 host bridge），内核 pci_p2pdma 白名单里没有根桥 → P2P 彻底没戏。你这台 m920x 因为有 switch 做汇聚，架构上就支持 P2P，这是质的差别。