vLLM多卡张量并行配置指南：TP设多少与5步排查

先给结论：vLLM多卡张量并行配置指南的参数决定顺序

很多人以为把 --tensor-parallel-size 调得越大，多卡推理就一定越快，但实际上 TP 设多少要由显存分账和模型注意力头数共同决定，不是越大越好。正确的思路是：先按四笔显存账算出 TP 下限，再按注意力头数整除约束和卡间互联确定上限，然后依次调整 --gpu-memory-utilization、--max-model-len 和 KV Cache 精度，最后做同请求分布的对照验证。vLLM 官方文档明确，单机多卡优先用张量并行，跨节点才叠加流水线并行，以避免低速网络拖累高频通信官方并行文档。本文就以这套顺序，给你一份可直接照做的 vLLM多卡张量并行配置指南。

第一步：四笔显存账算出 TP 下限

启动 vLLM 时，显存分配遵循固定顺序：先加载模型权重，再执行一次 dummy forward 探测中间激活，最后按 --gpu-memory-utilization（默认约 0.90-0.92）把剩余显存划给 PagedAttention 的 KV Cache 池。因此，你至少要几张卡，取决于四笔账：权重、KV Cache、中间激活、引擎常驻开销。

估算方法很简单：先拿单卡总显存乘以 --gpu-memory-utilization，得到可用显存；然后用模型权重大小加上预期 KV Cache 占用（与最大上下文长度和并发数相关）除以单卡可用显存，向上取整就是 TP 的下限。中间激活与引擎常驻开销的实际占用需以本机 Profiling 结果为准，建议先按保守估计预留余量、再用实际启动日志中的 KV Cache 块数回填修正。若可用显存与需求接近，应在同一模型上分别试跑相邻两档 TP，以启动日志与压测结果决定取哪一档。具体模型的权重与 KV Cache 量级可参考 Qwen部署显存需求 。

第二步：注意力头数整除约束与卡间互联，决定 TP 上限

TP 不是想设几就设几。vLLM 要求模型的总 Query 头数以及 GQA 架构下的 KV 头数都必须能被 --tensor-parallel-size 整除，否则初始化阶段会直接抛维度切分断言异常，服务起不来。例如一个 Query 头数为 32 的模型可以被 2、4、8 整除，但不能被 3、5、6 整除，所以 TP=3/5/6 这类取值在多数主流架构上不可用；上线前请以自己模型 config 中的 num_attention_heads 与 num_key_value_heads 逐一验算。

另一个上限是卡间互联带宽。张量并行依赖高速总线（如 NVLink）做算子级切分和 All-Reduce 通信，如果你用的是 PCIe 互联的卡，跨卡通信开销会显著拉低性能，此时 TP 不宜设得过高。因此，TP 上限 = min(满足头数整除的最大值, 互联带宽允许的切分数)。关于跨卡通信与切分收益的更多实测思路，可参考 多卡推理优化。

第三步：TP 与 PP 怎么分工，什么时候才动用跨节点流水线

--tensor-parallel-size 和 --pipeline-parallel-size 的分工很清晰：单机内优先把 TP 拉满（TP=单机卡数），因为 NVLink 带宽高；当模型超过单机总显存时，再叠加跨节点的 PP，通常 PP=节点数。这样组合可以避免跨节点低速网络承载高频张量通信。

一个常见的误配是单机内滥用 PP——明明卡间有高速互联，却切成 PP，导致流水线气泡降低利用率。另一个误配是跨节点强行切 TP，让 All-Reduce 走慢速网络，吞吐直接崩掉。所以跨节点时，正确做法是每台机器内部满切 TP，再跨节点切 PP。

需要说明的是，千亿级 MoE 模型在跨节点部署下的 Expert Parallelism 与 TP/PP 三维混合切分比例，目前各硬件平台仍在动态演进，本文的 TP/PP 组合结论只覆盖稠密模型的单机与多机常规拓扑，不对 MoE 最优切分给定论。

启动命令示例：

# 单机 4 卡，TP=4
vllm serve your-model --tensor-parallel-size 4

# 跨 2 节点，每节点 4 卡，TP=4，PP=2
vllm serve your-model --tensor-parallel-size 4 --pipeline-parallel-size 2

第四步：gpu-memory-utilization 与 max-model-len 的调整次序

这两个参数都在改同一个 KV Cache 池，所以必须按顺序调，一次只动一个。--gpu-memory-utilization 决定池子多大（默认 0.90-0.92），--max-model-len 决定单请求预留多长的逻辑上下文。如果你直接把 --max-model-len 设成模型的理论极大值，单个请求会吃掉过多 KV block，系统最大并发会被剧烈压缩NVIDIA 博客。

正确的次序是：先固定 --gpu-memory-utilization，再根据实际请求长度压 --max-model-len，观察吞吐和并发变化。同时改两个参数，出了问题你无法判断是谁引起的。一般建议 --max-model-len 设为略大于你最长的真实请求，而不是模型极限。

第五步：vllm fp8 kv cache 怎么开启，以及腾出的余量给谁

当 KV Cache 成为瓶颈时，可以开启 FP8 量化：--kv-cache-dtype fp8（硬件支持时也可用 fp8_e4m3 或 fp8_e5m2）。这不会量化模型权重，只把每 Token 的 KV Cache 占用降低约 50%，相当于可用 Token 容量翻倍FP8 KV Cache 文档。

腾出的余量怎么分配？分场景判断：如果你的业务是长文档、长上下文，优先提高 --max-model-len；如果是聊天或高并发 API，优先提升并发。注意，FP8 会带来精度损失，上线前务必做质量回归测试。如果对显存分账理解不深，可参考 GPU集群规划 做整体规划。

引擎版本为什么必须写进配置基线

同样一份启动参数，vLLM 引擎版本变了，结果未必能复现——因为算子实现、默认值、显存 Profiling 行为都可能变化。所以配置基线里必须记录四项：引擎版本、模型版本、完整启动命令、硬件拓扑。升级前后，重跑同一组对照，确保性能变化不是版本漂移造成的。

配完怎么验证：同请求分布下 TP=1/2/4 对照

照本文这份 vLLM多卡张量并行配置指南配完后，验证时固定模型、请求分布和并发梯度，分别记录 TTFT（首字延迟）、单 Token 时延、总吞吐、最大并发和显存占用。注意：TP 的主要收益是摊薄单卡显存和降低 TTFT，但跨卡 All-Reduce 开销可能让总吞吐不升反降，尤其在 Decode 密集的高并发场景。所以必须实测，不要默认线性加速。

用 NexGPU 的按量多卡实例，可以快速拉起 TP=1/2/4 三组环境，配合预制模板保证引擎版本一致，避免漂移。

把 vLLM多卡张量并行配置指南的五步倒过来，就是下面这张排查顺序表。

排查顺序表

常见问题

TP 设多少合适？

TP 取决于模型头数整除约束和显存需求。先算显存账确定下限，再查头数整除确定上限，取满足两者的最大值。例如 32 头模型可支持 2、4、8，但不能是 3、5、6。

TP 和 PP 有什么区别？

TP 将单层切分到多卡并行计算，适合单机高速互联；PP 按层分段，适合跨节点。单机优先 TP，跨节点才用 PP，避免低速网络拖累。

双卡吞吐上不去是什么原因？

最常见的原因不是参数，而是互联：TP 的收益主要在摊薄单卡显存与降低 TTFT，若两卡走 PCIe 而非 NVLink，或场景是 Decode 密集的高并发，跨卡 All-Reduce 的通信开销可能吃掉并行收益，总吞吐不升反降。此外，未开 --gpu-memory-utilization 调优导致 KV Cache 不足，或 TP 设置不当引入通信开销，也可能 --max-model-len 设置过大压缩了并发。按排查表逐项检查。

gpu-memory-utilization 设多少？

默认 0.90-0.92 即可，但如果出现 OOM，可以逐步降低到 0.8 或 0.85，同时观察吞吐变化。不要设太低，否则 KV Cache 过小影响并发。

FP8 KV Cache 怎么开启？

启动命令加 --kv-cache-dtype fp8，硬件支持时可用 fp8_e4m3 或 fp8_e5m2。开启后 KV Cache 占用降约 50%，但需做质量回归测试。

启动报 CUDA out of memory 怎么办？

先降 --gpu-memory-utilization 至 0.8，再降 --max-model-len，如果仍不够，考虑开启 FP8 KV Cache 或提高 TP 以摊薄显存。

建议先按上述五步在自己的模型与真实请求分布上跑一次 TP=1/2/4 对照，把引擎版本、启动命令、硬件拓扑与实测指标一起存成配置基线，升级引擎后重跑同一组对照。需要临时多卡环境做这组对照时，可用 NexGPU 的按量多卡实例与预制模板拉起同一引擎版本，避免版本漂移让参数不可复现。