# vLLM 推理原理（三）：GPU 怎样真正干活，多张卡又怎样协作？

> **摘要：** 调度计划确定之后，vLLM 如何把计算高效地交给 GPU？本文解释 Attention 后端、FlashAttention、编译优化和 CUDA Graph 的分工，通过矩阵拆分与部署示意讲清 DP、TP、PP、EP 四种并行方式，分析多卡通信的成本，并介绍量化、推测解码与 Prefill/Decode 分离，最后给出从性能现象定位瓶颈的验证思路。

![vLLM 推理原理（三）封面：GPU 执行优化与多卡协作]![cover-03.png](https://developer.qcloudimg.com/http-save/yehe-12628201/07cb3cb2faf165d2c37d2b4fbeb2229f.png)

前两篇已经把请求拆成了一轮轮 token 计算，也解释了 KV Cache 如何在显存里安家。

现在假设调度器已经选出本轮的输入。仍然有许多工作没有完成：输入需要整理成合适的张量，模型的算子要高效执行；如果一份模型横跨多张 GPU，各张卡还需要在正确的时间交换中间结果。

本篇把这两件事连起来：**单卡上减少计算和数据搬运的浪费，多卡上切分工作并承担通信代价。**

> 以 vLLM v0.32.0、V1 引擎为参照，资料核对日期为 2026-10-22。常规文本生成是主线，MoE、推测解码与 P/D 分离在对应小节单独说明。所有配图均为机制示意，不是实测性能图。

## 1. 一份调度计划，还需要被翻译成设备输入

调度器的输出，可以理解为“哪些请求，本轮各计算多少 token，并使用哪些 KV 块”。GPU Model Runner 随后准备 token IDs、位置、请求边界、块表和 KV 写入位置等信息。

设备侧不仅要知道当前计算哪些 token，还要知道它们属于哪条序列、能读取多少历史内容，以及新的 K、V 应写入哪里。

模型实现再把这些输入连接到具体算子。Attention、矩阵乘法、归一化、激活等操作，可能采用不同内核与库；后端选择与 GPU 架构、数据类型、head 维度、模型特征和配置有关。

因此，vLLM 不是始终执行同一个“神奇 Attention kernel”。它集成并选择多种执行路径，支持范围可查阅官方的 [Attention Backend Feature Support](https://docs.vllm.ai/en/v0.32.0/design/attention_backends/)。

## 2. Prefill 与 Decode，为什么常常需要不同优化？

prefill 一次处理许多已知 token，线性层可以组织较大的矩阵乘法，常有较高的计算密度。普通 decode 中，每条序列每轮通常只有一个新输入位置，但依然要经过模型，并访问历史 KV。

当 batch 较小时，decode 很可能花大量时间从显存读取权重与缓存。把多个请求的 token 组织成一个批次，可以让线性层的一次执行服务更多输入，提高权重数据的利用程度。

可以做一个非常粗糙的下界估算：假设一轮必须从显存读取 14 GB 权重，设备有效带宽为 1 TB/s，单看这一项就约需：

```text
14 GB / (1000 GB/s) ≈ 0.014 s = 14 ms
```

这不是某张 GPU 或某个模型的实测速度，也没有计入 KV、算术、缓存命中、通信和其他开销。它只是说明：即使算力很高，数据搬运仍可能成为执行时间的约束。

“prefill 偏计算、decode 偏访存”是一种常见工作负载判断，不能当作无条件定律。批大小、上下文长度、模型结构和硬件都会改变瓶颈，最后仍需要测量。

## 3. FlashAttention 与 PagedAttention，分别改了什么？

第二篇讲的分页 KV，解决的是缓存如何组织，以及 Attention 怎样访问分散的物理块。

FlashAttention 关注另一个问题：计算 Attention 时，如何减少 GPU 高带宽显存 HBM 与片上存储之间的数据搬运。

![图 11：直接物化分数矩阵与分块计算的差异]![11-flash-attention.png](https://developer.qcloudimg.com/http-save/yehe-12628201/a0ed0218de1da27ded3a52546c5b0a48.png)

*图 11：HBM 是 GPU 的大容量显存；片上存储容量较小，但更靠近计算单元。图中只强调中间数据的处理方式。*

在朴素的长序列 Attention 实现中，`QKᵀ` 会产生一个大型分数矩阵；softmax 等步骤还可能带来额外读写。FlashAttention 使用分块计算与在线 softmax，在处理小块数据时累计必要统计量和输出，避免把完整分数矩阵写入 HBM 后再反复读回。[参考：FlashAttention 论文](https://arxiv.org/abs/2205.14135)

它保持标准精确 Attention 的数学目标，不靠简单删掉若干注意力连接来换速度；浮点运算顺序变化仍可能造成数值差异。对于密集全注意力，也不能把它理解为把算术复杂度从平方直接变成了线性。

可以把两者的分工写成：

| 机制 | 主要回答的问题 |
| --- | --- |
| 分页 KV / PagedAttention | 历史 K、V 放在哪些块中，计算时如何定位？ |
| FlashAttention 类计算方法 | 读到这些数据后，怎样更高效地完成 Attention？ |

支持分页 KV 的 Attention 后端可以结合这些思路。因此，不能把它们简单看成只能二选一的两个开关。

## 4. torch.compile 与 CUDA Graph：少做调度上的重复劳动

GPU 执行也有主机侧开销。若一次前向包含很多小算子，CPU 需要反复提交内核；当设备计算本身很快时，这些提交与间隙可能变得明显。

这里有两类相关但不同的优化：

- **编译优化**：对计算图进行分析、生成或选择更合适的执行代码，必要时融合操作、减少中间读写。
- **CUDA Graph**：捕获兼容的一段设备执行流程，后续通过 replay 复用，减少反复逐项提交的开销。

![图 12：逐项提交与图重放]![12-cuda-graphs.png](https://developer.qcloudimg.com/http-save/yehe-12628201/61dbdd5b44ead3d7f050bd4eaf2f7835.png)

*图 12：CUDA Graph 是设备执行图的捕获与重放，不是训练时用于求梯度的自动微分图。*

vLLM V1 集成了 `torch.compile`；具体编译行为与缓存设计见 [torch.compile integration](https://docs.vllm.ai/en/v0.32.0/design/torch_compile/)。它仍可能依赖外部高效算子，并不意味着所有算子都由同一个编译器从头生成。

图重放也有约束：输入形状、缓冲区地址和算子后端等需要满足兼容条件。请求数量与本轮 token 数不断变化时，引擎可能使用不同捕获尺寸、padding、完整图或分段图，并在必要时走非图执行路径。vLLM 提供运行时图分派机制，见 [CUDA Graphs](https://docs.vllm.ai/en/v0.32.0/design/cuda_graphs/)。

这些优化并非没有成本：编译、预热和捕获会影响启动时间，并占用额外内存。比较方案时，应把冷启动和稳态执行分开统计。

## 5. 多 GPU 之前，先问：切分的是哪一种工作？

“把请求分配到多张卡上”，至少可能指四件不同的事情。

![图 13：DP、TP、PP 与 EP 的区别]![13-parallelism.png](https://developer.qcloudimg.com/http-save/yehe-12628201/4ef2fd71ceb88019a44c74f63d342389.png)

*图 13：这些是概念视图，实际部署可以组合多种并行策略。*

### DP：多份模型副本，接不同的请求

对稠密模型，可以部署多份完整的逻辑模型副本，让不同副本处理独立请求。副本内部仍可以使用 TP 或 PP，因此“一份副本”不一定只占一张卡。

DP 的主要作用是增加服务容量与吞吐，通常不会自动让单个请求的一步计算变成原来的几分之一。各副本也需要自己的执行状态和缓存容量。[参考：Data Parallel Deployment](https://docs.vllm.ai/en/v0.32.0/serving/data_parallel_deployment/)

### TP：把同一层中的张量切开

当一份模型单卡装不下，或者希望分担每张卡的计算与存储时，可以采用 Tensor Parallelism。

为了看清它的工作方式，使用一个简化的两层 MLP：

```text
X 的形状：[m, h]
W1：[h, f]       W2：[f, h]
Y = φ(XW1)W2
```

将 W1 按输出列切成两份，W2 按对应的输入行切成两份：

```text
GPU 0：Y0 = φ(XW1_0)W2_0
GPU 1：Y1 = φ(XW1_1)W2_1

最终 Y = Y0 + Y1
```

这样，两个设备各算一部分中间维度，最后通过求和得到完整结果。若后续各 rank 都需要结果，就可以使用 All-Reduce 等集合通信操作。

![图 14：一个 MLP 的张量并行示例]![14-tensor-parallel.png](https://developer.qcloudimg.com/http-save/yehe-12628201/b0df7ce93ea1201af1e692ca3e374439.png)

*图 14：真实 Llama 类 MLP 还包含门控等结构，这里只保留“分列—本地计算—分行—汇总”的主线。*

Attention 也可以按 head 等维度组织并行。实际实现需要兼顾 Q heads、KV heads 与 TP 大小，有些情况下 KV 会被复制，不能一律假设所有内存都恰好除以卡数。可以结合 [Llama 模型实现](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/model_executor/models/llama.py) 与[并行线性层实现](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/model_executor/layers/linear.py) 阅读。

### PP：把不同层放到不同设备

Pipeline Parallelism 可以让一组设备处理前面的层，另一组处理后面的层，阶段之间传递中间激活。

对单条序列的一次前向，后面的阶段仍依赖前面的结果。通过多个批次在不同阶段交错推进，才有机会形成流水线；依赖等待和负载不均则会产生“气泡”。

PP 能减少每卡保存的模型层数，但不承诺单请求延迟按卡数缩短。vLLM 支持 TP 与 PP 的组合，具体模型支持及部署方式见 [Parallelism and Scaling](https://docs.vllm.ai/en/v0.32.0/serving/parallelism_scaling/)。

### EP：把 MoE 的专家放到不同设备

MoE 模型会根据路由，为 token 选择需要执行的专家网络。Expert Parallelism 将不同专家放在不同 rank，把 token 对应的激活分发给专家，再合并结果。

这类通信常涉及 dispatch、combine，以及相应的 all-to-all 类数据交换。它还需要处理专家负载不均和通信计算重叠。[参考：Expert Parallel Deployment](https://docs.vllm.ai/en/v0.32.0/serving/expert_parallel_deployment/)

MoE 的并行组合还有一个重要边界：当 DP attention 与跨 rank 的专家层协作时，各 DP rank 不再是完全互不相干的模型副本，前向步骤可能需要对齐。不能把稠密模型的 DP 图直接套到所有 MoE 部署。

## 6. vLLM 到底怎样“调度多个 GPU”？

可以把问题拆成三个层次。

**第一层，在启动时建立拓扑。** 决定 TP、PP、DP 大小，建立 rank 与进程组，加载各设备需要的权重，准备设备内存、缓存布局并执行必要的预热。vLLM 通常采用一个 GPU Worker 进程管理一个设备。它不会在每个 token 产生后，再从全世界空闲 GPU 中随意挑一张来继续执行。

**第二层，运行时选择副本。** 在采用 DP 的服务中，入口或协调机制将请求送到适当的副本。这里解决的是请求路由与负载分配问题；外部负载均衡和引擎内部路由的职责取决于部署方式。

**第三层，副本内调度并执行。** Engine Core 为本轮请求选择 token 并管理 KV，执行器将计划交给对应 Worker，各 rank 按已建立的模型切分协作计算。

![图 15：DP=2、TP=2 的四卡示例]![15-replica-routing.png](https://developer.qcloudimg.com/http-save/yehe-12628201/64d40e2b26a0e95beb773864eb7df7f5.png)

*图 15：对于这个稠密模型示例，两个副本各有调度和 KV 状态；每份副本内部的两张卡共同执行一份模型。*

进程、Executor 与 Worker 的连接可对照 [MultiprocExecutor 源码](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/v1/executor/multiproc_executor.py) 阅读。

单机多卡常用原生多进程执行，多节点部署还可以使用 Ray 等运行时。进程如何部署，与张量如何通信是两个层次：Ray 不会代替 Attention 计算，也不代替 NCCL 或 vLLM 对应的通信后端完成所有 GPU 数据交换。

TP 通常存在较频繁的层内通信，所以 PCIe、NVLink、跨机网络的拓扑和带宽都会影响收益。一个粗略的时间模型是：

```text
每轮时间 ≈ 本地计算 + 访存 + 未被重叠掩盖的通信与等待 + 其他开销
```

增加 GPU 可以减少单卡的部分工作，同时也会增加通信与同步。不能只用总显存和总算力判断最终性能。

## 7. 另外三项常见能力，分别省掉什么？

| 能力 | 主要改变什么 | 不能默认保证什么 |
| --- | --- | --- |
| 量化 | 降低某些权重、激活或 KV 的表示精度与存储开销 | 所有 GPU 都更快、质量完全不变 |
| 推测解码 | 提出多个候选，再由目标模型验证，减少部分串行生成开销 | 一次验证必定接受全部候选 |
| Prefill / Decode 分离 | 让不同实例承担不同阶段，传输相应 KV 状态 | 不计传输成本就自动提高吞吐 |

**量化**要分清压缩的对象。只做权重量化，不等于 KV Cache 也使用了低精度。格式和后端的硬件支持同样关键，参见 [Quantization](https://docs.vllm.ai/en/v0.32.0/features/quantization/)。

**推测解码**可以由小模型或其他提议方法先给出候选序列，目标模型再验证。正确的接受、拒绝与采样过程是保持目标分布的关键；浮点与配置差异也意味着不能承诺逐 token 复现某一次普通采样。其收益受接受率、额外工作和负载影响，参见 [Speculative Decoding](https://docs.vllm.ai/en/v0.32.0/features/speculative_decoding/)。

**P/D 分离**给了 prefill 和 decode 独立分配资源与调节延迟的空间，但两边必须传递或取得相应 KV 状态。它增加了传输、路由和容量协调问题。本文参照版本的文档仍标为实验特性，并明确提醒不能把它当成吞吐必然提升的方案，见 [Disaggregated Prefilling](https://docs.vllm.ai/en/v0.32.0/features/disagg_prefill/)。

这些机制可以组合，但每一项解决的问题不同。优化前需要先确认实际瓶颈。

## 8. 用一组小实验，把机制和观测结果对上

下面是验证方案与启动示例，未在本文环境中执行 GPU 基准测试。运行前需要准备与所选版本匹配的受支持 GPU、驱动、依赖和模型文件；命令采用 Linux shell 写法。

```bash
# 假设已安装 vLLM 0.32.0；首次启动可能需要下载模型。
# 这些参数用于理解各项约束，不是生产环境推荐值。
vllm serve Qwen/Qwen3-0.6B \
  --max-model-len 4096 \
  --max-num-seqs 16 \
  --max-num-batched-tokens 2048
```

可以先用一个流式请求确认基本链路：

```bash
curl -N http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "Qwen/Qwen3-0.6B",
    "messages": [{"role": "user", "content": "请用三句话解释缓存的作用。"}],
    "max_tokens": 128,
    "stream": true
  }'
```

这只是连通性检查。要理解连续批处理，应进一步产生受控的并发负载；要观察前缀缓存，应固定完全相同的前缀，并区分冷缓存和热缓存。

建议按四组变量逐项改变：

1. **并发数**：从低并发逐步增加，检查吞吐提升是否伴随更长排队。
2. **输入长度**：保持输出条件相近，比较短输入和长输入的 TTFT。
3. **共享前缀比例**：比较冷缓存、热缓存与开头发生变化的请求。
4. **并行配置**：有多卡时，在模型装得下的前提下比较 TP 与多副本；保持模型、精度与负载一致。

每次记录版本、模型 revision、GPU 型号与互联、精度、输入输出长度分布、请求到达方式、预热与缓存状态，再比较请求完成率、输出吞吐、TTFT、ITL 及其 P95 / P99。若结束条件导致实际输出长度不同，也应一并记录。

服务端可通过 `/metrics` 暴露队列、缓存和请求等观测信息，具体字段按当前版本实际输出核对。[参考：Production Metrics](https://docs.vllm.ai/en/v0.32.0/usage/metrics/)

例如 `num_requests_waiting` 可帮助观察排队，`kv_cache_usage_perc` 反映块池使用程度。延迟口径则需再细分：参照版本的 `inter_token_latency_seconds` 按流式输出事件采样，`request_time_per_output_token_seconds` 按完成请求统计平均 TPOT。一个事件包含多个 token 时，二者不能直接互换。[参考：Metrics 设计与口径](https://docs.vllm.ai/en/v0.32.0/design/metrics/)

![图 16：由现象定位需要检查的系统层次]![16-performance-map.png](https://developer.qcloudimg.com/http-save/yehe-12628201/ccb81a26f703404b3c9108c66950e063.png)

*图 16：这些是候选原因；判断瓶颈仍需结合时间线、负载和设备指标。*

当首 token 慢时，先拆分排队与 prefill；输出忽快忽慢时，检查混合批次和 KV 压力；加卡收益差时，检查通信与每卡工作量；GPU 没吃满时，也要看 CPU 分词、进程调度和网络。

沿着这三篇的请求链路，现在可以从应用现象一路追到执行位置：输入怎样编码，哪些 token 被选中，历史状态放在哪些块里，算子怎样读取这些状态，多张卡又在哪里汇合结果。掌握这些连接后，vLLM 的参数和监控指标，才有了可解释的含义。

上一篇：[vLLM 推理原理（二）：请求怎么排队，KV Cache 怎么住进显存？](https://cloud.tencent.com/developer/article/2767041)

## 参考资料与源码入口

1. [Attention Backend Feature Support](https://docs.vllm.ai/en/v0.32.0/design/attention_backends/)
2. [FlashAttention 论文](https://arxiv.org/abs/2205.14135)
3. [torch.compile integration](https://docs.vllm.ai/en/v0.32.0/design/torch_compile/)
4. [CUDA Graphs](https://docs.vllm.ai/en/v0.32.0/design/cuda_graphs/)
5. [Data Parallel Deployment](https://docs.vllm.ai/en/v0.32.0/serving/data_parallel_deployment/)
6. [v0.32.0：Llama 模型实现](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/model_executor/models/llama.py)
7. [v0.32.0：并行线性层](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/model_executor/layers/linear.py)
8. [Parallelism and Scaling](https://docs.vllm.ai/en/v0.32.0/serving/parallelism_scaling/)
9. [Expert Parallel Deployment](https://docs.vllm.ai/en/v0.32.0/serving/expert_parallel_deployment/)
10. [v0.32.0：MultiprocExecutor](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/v1/executor/multiproc_executor.py)
11. [Quantization](https://docs.vllm.ai/en/v0.32.0/features/quantization/)
12. [Speculative Decoding](https://docs.vllm.ai/en/v0.32.0/features/speculative_decoding/)
13. [Disaggregated Prefilling](https://docs.vllm.ai/en/v0.32.0/features/disagg_prefill/)
14. [Production Metrics](https://docs.vllm.ai/en/v0.32.0/usage/metrics/)
15. [Metrics 设计与口径](https://docs.vllm.ai/en/v0.32.0/design/metrics/)


摘要： 调度计划确定之后，vLLM 如何把计算高效地交给 GPU？本文解释 Attention 后端、FlashAttention、编译优化和 CUDA Graph 的分工，通过矩阵拆分与部署示意讲清 DP、TP、PP、EP 四种并行方式，分析多卡通信的成本，并介绍量化、推测解码与 Prefill/Decode 分离，最后给出从性能现象定位瓶颈的验证思路。

vLLM 推理原理（三）：GPU 怎样真正干活，多张卡又怎样协作？

云平台负责人

人工智能

vLLM推理原理详解GPU高效执行与多卡协作机制，深入解析Attention后端、FlashAttention及CUDAGraph优化分工，阐述DP、TP、PP、EP四种并行策略的切分方式与通信成本，涵盖量化、推测解码等性能优化方案，提供从现象定位瓶颈的系统验证思路。

负载均衡

代码解释

编译器

路由

JSON

2026上云采购 | AI焕新·智启新局

tione

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

vLLM 推理原理（三）：GPU 怎样真正干活，多张卡又怎样协作？-腾讯云开发者社区-腾讯云

vLLM 推理原理（三）：GPU 怎样真正干活，多张卡又怎样协作？

vLLM 推理原理（三）：GPU 怎样真正干活，多张卡又怎样协作？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐