我意外地用一条隐藏的PCIe 2.0 x4插槽削弱了4x RTX 3090 LLM设备的性能，修复后使Mistral 128B的性能翻倍。

我发布这篇文章作为警告，提醒所有使用老旧工作站/HEDT主板搭建多GPU本地LLM机器的人。我的配置（Node #04）： * Gigabyte X399 Designare EX * Threadripper 1950X * 128GB DDR4 * 4x RTX 3090 * 10GbE TP-Link/Aquantia 网卡 * NCCL版 llama.cpp * 用于 safetensors 模型的 vLLM 之前我的多GPU结果出奇地令人失望。机器能工作，所有4块GPU都能检测到，显存可用，模型也能加载，但某些工作负载表现平平。例如：Mistral Medium 3.5 128B Q4_K GGUF 只有约11 tok/s，且GPU利用率很低，只有30%左右。我以为是后端/模型/拆分/NCCL的问题。结果发现，有一块3090插在物理x16插槽上，但该插槽电气上仅是PCIe 2.0 x4。更糟的是，在修复BIOS/设置/位置之前，Linux显示那块GPU协商速率低至Gen2 x1 / Gen1 x4。关键证据： ```bash nvidia-smi --query-gpu=index,name,pci.bus_id,pcie.link.gen.current,pcie.link.width.current,pcie.link.gen.max,pcie.link.width.max --format=csv ``` 错误布局导致一块GPU实际上被严重拖累。重新插拔显卡后，GPU现在显示为： ```text GPU0: Gen3 max, x8 GPU1: Gen3 max, x16 GPU2: Gen3 max, x8 GPU3: Gen3 max, x16 ``` 隐藏的错误在于，这块主板有多个物理x16长度的插槽，但并非所有插槽电气上都相同。那个PCIe 2.0 x4插槽原本是给网卡用的，不是给3090的。修正插槽布局后，结果大幅改善。 Qwen3.6 27B BF16 配合 vLLM TP=4 + MTP，上下文长度260K： ```text ~78-80 tok/s 生成速度 ~80% 草稿接受率 ``` Qwen3.6 27B BF16 GGUF 配合 NCCL版 llama.cpp，`--split-mode tensor`，启用MTP： ```text ~66.5 tok/s ~85% 草稿接受率 ``` Mistral Medium 3.5 128B Q4_K GGUF 配合 llama.cpp： 之前，使用 `--split-mode layer`： ```text ~11 tok/s GPU利用率低 ``` 修正PCIe布局后，改用： ```bash --split-mode tensor --tensor-split 25,25,25,25 ``` 结果： ```text ~24.7 tok/s ``` 所以得出的教训： 1. 不要相信物理插槽长度。查看主板手册中的电气通道布局。 2. 始终在Linux下验证实际的协商PCIe宽度/速度。 3. `nvidia-smi` 和 `lspci -vv` 是你的好朋友。 4. 在llama.cpp中，`--split-mode layer` 对于某些大型GGUF模型可能严重浪费GPU。 5. 对于我的Mistral 128B GGUF测试，`--split-mode tensor` 带来了巨大改善。 6. 如果某块GPU意外插在错误的PCIe路径上，整个多GPU推理系统可能看起来像是后端问题，但实际上只是插槽布局问题。 有用的命令： ```bash nvidia-smi topo -m ``` ```bash nvidia-smi --query-gpu=index,name,pci.bus_id,pcie.link.gen.current,pcie.link.width.current,pcie.link.gen.max,pcie.link.width.max --format=csv ``` ```bash for B in 09:00.0 0a:00.0 41:00.0 42:00.0; do echo "===== $B ====="; sudo lspci -vv -s "$B" | grep -E "LnkCap|LnkSta"; done ``` 如果你正在用二手3090搭建“廉价显存怪兽”，请先检查这一点，不要急着指责NCCL、llama.cpp、vLLM、量化或模型本身。在我的案例中，修正PCIe插槽位置将这台机器从“为什么这么弱？”变成了“好吧，这玩意确实是怪兽”。