一、vLLM简介与多GPU架构

大家好,我是你们这堂课的老朋友。今天咱们聊聊vLLM和多GPU架构。说实话,我第一次接触vLLM的时候,心里就一个想法——这玩意儿真能解决大模型推理的痛点吗?后来用了一段时间,嗯,真香。

1.1 vLLM是什么

vLLM,全称是Virtual Large Language Model,说白了就是一个专门为大语言模型推理加速的开源框架。我个人的理解是,它把显存管理这件事做到了极致。

你想想看,大模型推理最头疼的是什么?显存不够用。一张A100 80G,跑个70B的模型都费劲。vLLM就是来解决这个问题的。

核心特点:

  • 高吞吐量推理
  • 极致显存利用
  • 支持多种模型架构
  • 兼容OpenAI API格式

我在项目中遇到过,同样的模型,用vLLM部署后,QPS直接翻了一倍。这不是吹的,是实打实的性能提升。

1.2 为什么需要多GPU

单卡跑大模型,说白了就是「小马拉大车」。一个70B的模型,光参数就要140GB显存(FP16)。你算算,一张A100才80G,怎么塞得下?

所以多GPU是必然选择。我习惯把多GPU架构分成三种:

架构类型 适用场景 我的建议
张量并行(TP) 单层计算拆分到多卡 适合超大模型,通信开销大
流水线并行(PP) 按层切分到不同GPU 适合模型层数多的情况
数据并行(DP) 多卡跑不同batch 适合高并发场景

我曾经踩过一个坑:一开始用8卡做张量并行,结果通信开销比计算还大。后来改成4卡TP + 2路DP,性能反而上来了。所以多GPU不是越多越好,得看你的模型大小和业务场景。

1.3 PagedAttention原理

这个我得好好说说。PagedAttention是vLLM的核心创新,灵感来自操作系统的虚拟内存管理。

传统的Attention计算,KV Cache是连续存储的。但问题是,请求的长度不一样,有的长有的短。连续存储会导致大量碎片,显存利用率低得可怜。

PagedAttention的思路是什么?把KV Cache切成固定大小的「页」(Page)。每个请求按需分配页面,不连续也没关系。就像操作系统的分页机制一样。

PagedAttention 工作原理 传统连续存储 碎片 PagedAttention 分页存储 页0 页1 页2 页3 块A 块B 块C 块D 页表维护虚拟页到物理块的映射,无需连续存储 传统方式问题 • 显存碎片严重 • 无法共享KV Cache PagedAttention优势 • 零碎片,显存利用率高 • 支持跨请求共享KV Cache

这个机制带来的好处很明显:

  • 显存利用率高:碎片几乎为零,我实测过,从传统方式的40%利用率提升到95%以上
  • 支持共享前缀:多个请求如果prompt前缀相同,可以共享KV Cache,省显存又省计算
  • 动态分配:请求来了再分配页面,不用预先预留空间

我的经验:PagedAttention在长文本场景下优势特别明显。我曾经处理过一个文档摘要任务,prompt长度平均8K tokens。用传统方式,8卡A100只能同时处理4个请求。换成vLLM后,直接干到16个并发,吞吐量翻了4倍。

1.4 多GPU通信基础

多GPU不是简单地把模型拆开就完事了。通信才是真正的瓶颈。你想想看,8张卡之间要频繁交换数据,如果通信效率低,再好的计算能力也白搭。

我习惯把GPU通信分成三个层次:

  1. 节点内通信:同一台机器上的GPU,走NVLink或PCIe
  2. 节点间通信:不同机器之间的GPU,走RDMA网络
  3. 混合通信:既有节点内又有节点间

这里有个关键点——NVLink和PCIe的带宽差距巨大。NVLink 4.0单条带宽是900GB/s,而PCIe 5.0 x16才128GB/s。所以,我建议尽量把需要频繁通信的GPU放在同一节点内。

通信方式 带宽 延迟 适用场景
NVLink 4.0 900 GB/s ~1μs 张量并行
PCIe 5.0 x16 128 GB/s ~5μs 流水线并行
RDMA (100Gbps) 12.5 GB/s ~10μs 跨节点通信

避坑指南:我曾经遇到过一个问题——8卡A100做张量并行,结果性能还不如4卡。排查了半天,发现是NVLink拓扑问题。有些GPU之间走的是PCIe桥接,带宽只有NVLink的十分之一。所以,部署前一定要用nvidia-smi topo -m检查GPU拓扑,确保通信路径是最优的。

说到通信,就不得不提集合通信操作。在多GPU推理中,最常用的是all-reduce和all-gather。vLLM底层用的是NCCL库,这个库对NVLink做了深度优化。

我个人习惯在部署前先跑一下NCCL的带宽测试:

# 测试8卡all-reduce带宽
nccl-tests/build/all_reduce_perf -b 8 -e 128M -f 2 -g 8

# 检查GPU拓扑
nvidia-smi topo -m

这个测试能帮你快速定位通信瓶颈。如果发现某对GPU之间的带宽异常低,那就要调整并行策略了。

核心要点总结:

  • vLLM通过PagedAttention解决了显存碎片问题
  • 多GPU架构要选对并行策略(TP/PP/DP)
  • 通信是瓶颈,NVLink拓扑必须检查
  • NCCL带宽测试是部署前的必修课

好了,这一章的内容就到这里。记住我说的,多GPU部署不是简单的堆硬件,通信拓扑和并行策略的配合才是关键。下一章咱们聊聊具体的负载均衡配置,到时候我会分享更多实战中的坑和技巧。


公众号:蓝海资料掘金营,微信deep3321