踩坑实录：多卡跑大模型 Qwen-VL，为何 vLLM 模型加载卡死而 llama.cpp 奇迹跑通还更快？
前言：部署经历
针对 Qwen3-VL-32B-Instruct 满血版模型的部署实战。手头的环境是一台配备了 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="FLASH_ATTN"
vllm serve /model/Qwen3-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 image=4,video=1 \
--api-key yourkey
结果遇到了以下现象：
- 初始化阶段：vLLM 成功加载模型权重，显存占用正常上升，甚至直接到快到 100% 就卡死了（直接超时或不动）。
- 推理阶段：发送第一条 Prompt，后台日志显示正在进行 NCCL 通信初始化。
- 死锁：GPU 使用率忽高忽低，最终降为 0，程序长时间无响应，最后抛出 NCCL 错误。
这显然不是显存不足（OOM），而是通信堵塞。
1.3 换成 Ollama 继续实验，成功。
随后，使用 Ollama 加载 GGUF 格式（自己下载的高精度的 FP16）模型，默认都是 q4 的，可以去官网找列表参数。脚本 ollama_start.sh 如下：
#!/bin/bash
echo "###########start llm by ollama...##########"
export CUDA_VISIBLE_DEVICES=0,1,2,3
export OLLAMA_NUM_PARALLEL=10
nohup ollama run qwen3-vl-32b-instruct-bf16:latest >/ollama_models/logs/qwen3vl_32.log 2>&1 &
echo "Models started in background. Check logs in /ollama_models/logs/"
- 结果：一次点亮。非常稳定，没有卡顿，每秒有 50 个 token 的样子。
为什么？难道 vLLM 的技术反而不如 llama.cpp 吗？后面仔细分析了背后的根本原因，在于两者对'并行'的方式完全不同。
第二部分：深度解析 vLLM 在弱通信环境下不好用
vLLM 之所以快，是因为它追求极致的计算密度；而它之所以挂，是因为它默认采用了 张量并行（Tensor Parallelism, TP）。
2.1 什么是张量并行（TP）？
为了讲清楚这个问题，我们把大模型想象成一个巨大的矩阵乘法工厂。假设我们要计算 Y = X × W。
在 TP 模式下，vLLM 是这样分配工作的：
- 它把巨大的权重矩阵 W，竖着切成 4 份（W1, W2, W3, W4），分别放在 4 张 A30 卡上。
- 当输入 X 进来时，4 张卡同时计算 X×W1, X×W2……
- 关键点来了：要得到最终结果 Y，必须把 4 张卡算出来的部分结果加在一起（All-Reduce）。
2.2 致命的 All-Reduce 通信风暴
大模型（Transformer 架构）通常有几十层（Qwen-32B 可能有 60-80 层）。在 vLLM 的 TP 模式下：
- 每一层计算完，都必须进行一次全员通信同步。
- 每生成一个 Token，模型就要跑完所有层。
计算公式： 通信次数 = 层数 × 生成的 Token 数量
假设模型有 80 层，你要生成 100 个字。那么显卡之间需要进行 80 × 100 = 8000 次通信！
2.3 A30 的用 vlm 跑多卡数据路径
在没有 NVLink 支持，且 PCIe 可能不支持 P2P（Peer-to-Peer）直接访问的环境下，这 8000 次通信是怎么走的？
- 路径：GPU A -> PCIe -> CPU 内存 -> PCIe -> GPU B
- 后果：
- 延迟爆炸：每次绕道 CPU 内存，延迟都会增加。在每秒几十次的高频同步下，延迟被放大成无法忍受的卡顿。
- 带宽瓶颈：PCIe Gen4 x16 的带宽（~32GB/s）远低于显卡内部显存带宽。
- NCCL 崩溃：vLLM 依赖的 NCCL 库在检测到这种恶劣的拓扑环境时，往往会因为同步超时而直接挂起（Hang）。
结论：vLLM 是一辆为高速公路（NVLink）设计的法拉利，你把它开进了泥泞的沼泽地（无 P2P 的 PCIe），它不仅跑不快，还会陷进去。
第三部分：Ollama (llama.cpp) 的玩法
Ollama 能跑通，并非因为它有什么黑科技，而是因为它默认采用了更适合低带宽环境的策略：流水线并行（Pipeline Parallelism） 或简单的 层级切分（Layer Split）。
3.1 不同的切分逻辑：切蛋糕 vs 切千层饼
如果说 vLLM 是把每一层蛋糕切成 4 块分给 4 个人吃（TP），那么 llama.cpp 就是把一个 80 层的千层饼，拆成 4 份，每人拿 20 层（PP）。
- GPU 1：负责第 1-20 层。
- GPU 2：负责第 21-40 层。
- GPU 3：负责第 41-60 层。
- GPU 4：负责第 61-80 层。
3.2 通信频率的降维打击
在这种模式下，数据是怎么流动的？
- GPU 1 算完前 20 层，把结果（仅是一个很小的 Activation Tensor）发给 GPU 2。
- GPU 1 休息（或者处理下一个请求）。
- GPU 2 接力继续算。
通信对比：
- vLLM (TP)：每生成 1 个 token，通信 80 次。
- Ollama (PP)：每生成 1 个 token，通信 3 次（1->2, 2->3, 3->4）。
这就是成功的关键：Ollama 将通信频率降低了几个数量级！即使走慢速的 PCIe 总线，这几次数据传输的耗时也是微秒级的，对整体推理速度几乎没有影响。
3.3 GGUF 格式的助攻
虽然我是为了跑满血版，但 llama.cpp 生态下的 GGUF 格式（即使是 F16）天生对这种层级切分支持得更好。llama.cpp 的 --split-mode layer 参数正是为此而生，它明确告诉程序：'不要搞复杂的张量拆分，简单粗暴地按层分就好。'
第四部分：实践中优先使用了工具 GPUStack，也印证了这点。
在这次折腾中，我也尝试了 GPUStack 这个非常好用的管理工具，但也失败了。通过分析日志，我发现了其中的生态依赖链问题。
- 默认走 vLLM：GPUStack 为了追求性能，检测到 NVIDIA 显卡时，默认首选 vLLM 后端。这直接触发了上述的
