踩坑实录：多卡跑大模型 Qwen-VL，为何 vLLM 模型加载卡死而 llama.cpp 奇迹跑通还更快？
前言：部署经历
针对 Qwen-VL-32B 满血版模型的部署实战。手头的环境是一台配备了 4 张 NVIDIA A30（24GB 显存） 的服务器。按理说，96GB 的总显存足以吞下 FP16 精度的 32B 模型（约 65GB 权重）。然而，在使用业界标杆 vLLM 进行部署时，系统却陷入了诡异的'死锁'——显存占满，但推理毫无反应，最终超时报错。
尝试切换到 Ollama（底层基于 llama.cpp），奇迹发生了：不仅部署成功，而且运行流畅。这引发了我深深的思考：同样的硬件，同样模型，为何两个主流框架的表现天差地别？
本文将围绕PCIe 通信瓶颈、Tensor Parallelism（张量并行） 与 Pipeline Parallelism（流水线并行） 进行分析。
第一部分：硬件环境
1.1 NVIDIA A30
在 NVIDIA 的产品谱系中，A30 是一款基于 Ampere 架构的中端推理卡，拥有 24GB HBM2 显存，带宽 933 GB/s。属性如下：
- NVLink 的缺失：虽然 A30 规格书支持 NVLink，但在很多通用服务器或云实例中，并没有物理配置 NVLink Bridge，就比如我的服务器上。
- PCIe 的独木桥：当卡与卡之间没有 NVLink 这种'高速私家路'时，所有通信都必须走 PCIe 总线。
实际环境补充：本文服务器显卡连 4 卡 PCIe 都没联通，最多只有两卡。采用 VLLM 时，如果两卡部署也必须选择 SYS 链接的形式。下面是卡联通情况：
nvidia-smi topo -m
| 缩写 | 含义 | 典型场景 |
|---|---|---|
| X | 自身（Self） | GPU 内部环路 |
| PXB | PCIe x16 桥接（Direct PCIe Bridge） | 同一 PCIe 树下的 GPU 直接互联 |
| SYS | 系统总线（System Bus） | 通过 CPU/主板 南桥间接连接 |
| PIX | PCIe 交换机（PCIe Switch） | 多 GPU 通过 PCIe 交换机互联 |
1.2 故障复现：vLLM 加载模型'卡死'
在使用 vLLM 尝试拉起 4 卡推理时，部署脚本如下：
#!/bin/bash
echo "###########start vl by vllm...##########"
export GLOO_SOCKET_IFNAME="enp210s0f0" # 多网卡需要指明
export CUDA_VISIBLE_DEVICES="1,2,3,4"
export VLLM_LOGGING_LEVEL="DEBUG"
export VLLM_ATTENTION_BACKEND=
vllm serve /model/Qwen-VL-32B-Instruct \
--gpu-memory-utilization 0.8\
--dtype auto \
--host 0.0.0.0 \
--port 7860\
--tensor-parallel-size 2\
--kv-cache-dtype fp8 \
--max-model-len 10000\
--limit-mm-per-prompt mage=4,video=1\
--api-key yourkey
