前言
vLLM Omni 是面向图文 / 语音 / 多模态大一统模型（Qwen3-Omni、MiniCPM-Omni、LLaVA-Omni 等）的分布式推理引擎，相比原生 vLLM，它天然拆分编码器、LLM 解码器、语音 Vocoder 多阶段计算。
--pipeline-parallel-size（简写 -pp，流水线并行度）是突破单节点显存瓶颈、支撑超大多模态模型、跨多机部署的核心参数。很多同学部署超大 Omni 模型时出现 OOM、多卡负载不均、跨节点推理失败，根源都是 PP 参数配置错误。
本文结合 Omni 多模态架构，讲清 PP 原理、与 TP 张量并行区别、搭配方案、生产启动命令、调优避坑与落地实践。
一、参数基础定义
1. 基础参数信息
bash
运行
# 命令行参数
--pipeline-parallel-size PIPELINE_PARALLEL_SIZE
# 简写
-pp
# 默认值
1
官方释义：模型流水线并行的阶段数量，将模型垂直分层切分到多 GPU / 多节点，每个 Stage 负责连续一层网络计算vLLM。
在 vLLM Omni 多模态场景下，PP 有两层含义：
- 传统 LLM 流水线并行：把文本大模型 Transformer 层切分为 N 段，分配给 N 个 GPU；
- Omni 特有跨模态流水线：图像编码器、LLM 主干、音频解码器可拆分为独立 Pipeline Stage，PP 控制多模态模块分布式部署规模arXiv。
2. PP 核心运行原理（工厂流水线模型）
张量并行 TP 是横向切单层权重，所有 GPU 同步处理同一个请求；
流水线并行 PP 是纵向切模型完整层级，GPU 各司其职，多请求微批次流水执行：
- 将完整模型按层数均分，PP=N 则拆成 N 个连续 Stage；
- 输入请求拆分为多个 micro-batch 微批次；
- Stage0 处理微批次 1 → 输出特征传给 Stage1；同时 Stage0 立刻处理微批次 2；
- 所有 GPU 同时处理不同批次的不同网络层，重叠计算抵消等待气泡时间，提升整体吞吐火山引擎 …。
关键优势：
- 单卡显存占用线性下降，单节点放不下的百亿 / 千亿多模态模型，靠 PP 跨节点拆分；
- 通信量远低于 TP：仅 Stage 之间传递一次中间特征，无需每层 AllReduce；
- Omni 多模态场景适配极强：视觉 / 音频编码器可独立分配流水线 Stage，避免图像编码抢占 LLM 显存。
固有短板：
- 单 Token 原生延迟高于 TP：请求必须串行走完所有 Stage；
- 低并发、小批量下会产生流水线气泡（部分 GPU 空闲），利用率下滑；
- 跨节点部署依赖 NCCL/RDMA 高速网络，千兆网卡会严重拖慢速度。
二、PP vs TP：vLLM Omni 场景核心区别
表格
| 维度 | Pipeline Parallel (PP, 流水线并行) | Tensor Parallel (TP, 张量并行) | Omni 适用场景 |
|---|---|---|---|
| 切分方式 | 垂直分层，每卡持有完整多层权重 | 横向切单层权重，每层多卡均分 | PP：超大模型、跨节点、多模态分模块；TP：单机低延迟 |
| 通信频率 | 仅 Stage 边界传特征，通信少 | 每层都做 AllReduce，通信密集 | 多模态编码器推荐 PP；LLM 主干单机推荐 TP |
| 显存收益 | 线性降低，跨节点扩容 | 单机显存分摊，不支持跨机拆分 | Qwen3-Omni-30B/70B 优先 PP+TP 混合 |
| 延迟表现 | 单 Token 延迟更高，高并发吞吐强 | 低延迟、首包 TTFT 更快 | 直播实时对话选 TP；批量图文生成选 PP |
| 硬件依赖 | 跨节点需 IB/RDMA，单机 PCIe 即可 | 必须 NVLink 高速互联 | 多机集群用 PP；单机 8 卡 NVLink 只用 TP |
| 典型配置 | pp=2 tp=4（2 节点每节点 4 卡 TP） | pp=1 tp=8（单机 8 卡张量并行） | Omni 语音 + 图像混合推理推荐混合并行 |
三、vLLM Omni 下 PP 的两种使用场景
场景 1：纯 LLM 主干流水线并行（传统用法）
适用于纯文本超大 Omni 底座（如 Qwen3-Omni-70B），单节点 8 卡仍放不下完整权重，设置 PP 拆分 Transformer 层。
示例：单机 4 卡，pp=4 tp=1，4 张卡均分 LLM 全部网络层，每张卡只加载 1/4 模型权重。
场景 2：Omni 多模态分 Stage 流水线（特有能力）
vLLM Omni 把模型拆分为三大独立计算阶段：
- Stage0：图像 / 音频编码器（多模态特征提取）
- Stage1：LLM 大语言主干 Transformer
- Stage2：语音 Vocoder 音频生成
通过pipeline-parallel-size配合--stage-overrides，可给每个模态阶段分配独立流水线并行资源，实现视觉、文本、音频模块硬件隔离，互不抢占显存，这是纯 vLLM 不具备的能力vLLM。
四、PP+TP 混合并行标准搭配公式（生产必看）
总 GPU 数量 = pipeline-parallel-size (pp) × tensor-parallel-size (tp)
通用部署规范：
- 单机多 GPU（≤8 卡，NVLink）：优先
pp=1，仅用 TP，保证最低推理延迟； - 多节点集群（每节点 8 卡）：
tp=单节点GPU数，pp=节点数量，跨节点靠 PP 分层，节点内部 TP 加速； 例：2 台 8 卡服务器，tp=8 pp=2，总 16 卡； - 中小单机 4 卡，模型显存紧张：混合
pp=2 tp=2，均衡显存与延迟，兼顾吞吐； - 多模态图文语音混合任务：pp 设置为模态阶段数量，搭配小 TP，分离编码器与 LLM 资源。
五、vLLM Omni 完整启动示例命令
示例 1：单机 4 卡混合并行 pp=2 tp=2（Qwen3-Omni-30B）
bash
运行
vllm serve Qwen/Qwen3-Omni-30B-A3B-Instruct \
--omni \
--port 8000 \
--tensor-parallel-size 2 \
--pipeline-parallel-size 2 \
--gpu-memory-utilization 0.88 \
--max-model-len 8192 \
--trust-remote-code \
--enforce-eager
示例 2：双节点 16 卡超大模型（每台 8 卡，tp=8 pp=2，Ray 分布式）
主节点（master，192.168.1.100）：
bash
运行
vllm serve Qwen/Qwen3-Omni-70B-A3B-Instruct \
--omni \
--tensor-parallel-size 8 \
--pipeline-parallel-size 2 \
--distributed-executor-backend ray \
--ray-address auto \
--node-rank 0 \
--num-nodes 2 \
--master-addr 192.168.1.100 \
--master-port 29500 \
--gpu-memory-utilization 0.85
从节点：
bash
运行
vllm serve Qwen/Qwen3-Omni-70B-A3B-Instruct \
--omni \
--tensor-parallel-size 8 \
--pipeline-parallel-size 2 \
--distributed-executor-backend ray \
--node-rank 1 \
--num-nodes 2 \
--master-addr 192.168.1.100 \
--master-port 29500
示例 3：Omni 多模态分 Stage 流水线（编码器独立 GPU）
通过--stage-overrides配合 pp，图像编码单独占用两张 GPU 流水线并行：
bash
运行
vllm serve Qwen/Qwen3-Omni-30B-A3B-Instruct --omni \
--port 8090 \
--pipeline-parallel-size 2 \
--tensor-parallel-size 1 \
--stage-overrides '{
"0": {"num_replicas": 1, "devices": "0,1"},
"1": {"num_replicas": 1, "devices": "2,3"}
}'
六、PP 参数调优黄金实践（Omni 多模态专属）
1. PP 数值选择规则
- PP 尽量为 2 的幂次（1/2/4/8），NCCL 通信效率最优；
- 模型层数 ÷ pp 尽量整除，避免 Stage 之间计算量不均衡（负载倾斜会大幅降低吞吐）；
- 多模态模型优先把图像编码器单独作为一个 PP Stage，图像特征不占用 LLM 显存；
- 批量图文生成、短视频语音合成高吞吐场景：pp 适度放大（pp=4）；实时对话低并发场景：pp=1。
2. 显存优化技巧
- pp 增大，单卡模型权重显存同步降低，可提升
--gpu-memory-utilization至 0.85~0.9； - Omni 图像编码会产生大量中间特征缓存，拆分 PP Stage 隔离编码器，可减少 30% 左右峰值显存占用；
- AWQ/GPTQ 量化模型同样支持 PP 并行，显存压力进一步释放。
3. 网络通信优化（跨节点 PP 必做）
- 集群启用 IB/RDMA，NCCL_IB_DISABLE=0；
- 设置环境变量加速跨 Stage 通信：
bash
运行
export NCCL_DEBUG=INFO
export NCCL_P2P_DISABLE=0
export CUDA_VISIBLE_DEVICES=0,1,2,3
- 跨节点 PP 必须使用 Ray 分布式后端
--distributed-executor-backend ray，多进程 mp 不支持多机 PP。
七、高频踩坑与解决方案
坑 1：设置 pp 后模型加载 OOM
原因：TP 与 PP 乘积超过服务器可用 GPU 总数；Stage 负载不均，某一分段层过多显存溢出。
解决：
- 核对总卡数 = tp × pp；
- 降低
gpu-memory-utilization至 0.8； - 拆分多模态 Stage，图像编码器独立分配 GPU。
坑 2：pp>1 时推理延迟暴涨
原因 1：并发量太低，流水线气泡时间占比过高；
解决：提高服务并发，增大--max-num-batched-tokens；低并发业务改为 pp=1 纯 TP。
原因 2：跨节点千兆网卡，Stage 间特征传输缓慢；
解决：单机部署放弃跨节点 PP，更换 IB 高速网络。
坑 3：Omni 音频 / 图像生成卡死、无输出
原因：PP 分层时多模态 Stage 通信未走零拷贝，特征传递丢失；
解决：启用 vLLM-Omni 内置零拷贝通信，添加--async-chunk参数，降低跨 Stage 数据拷贝开销。
坑 4：多节点 pp 启动报 NCCL 连接失败
原因：master 端口不通、节点 rank 配置错误、防火墙拦截 29500 端口；
解决：统一 master 地址与端口，关闭防火墙，所有节点 tp/pp 参数完全一致。
八、适用与不适用场景总结
推荐使用 pp>1（流水线并行）
- 70B/405B 超大 Omni 多模态底座，单机显存无法容纳；
- 多机集群分布式部署，单节点 GPU 上限 8 卡；
- 图文、语音批量离线生成，追求高吞吐，延迟容忍度高；
- 需要硬件隔离图像编码器、LLM、语音解码器，避免显存争抢。
建议 pp=1（关闭流水线并行）
- 单机 NVLink 高速互联（A100/H100 8 卡），低延迟实时对话业务；
- 在线客服、实时语音聊天，QPS 低、对 TTFT 首包延迟敏感；
- 小参数量 Omni 模型（7B/14B），单卡完全放下，无需分层拆分。
结语
--pipeline-parallel-size是 vLLM Omni 突破硬件上限、支撑大一统多模态大模型分布式推理的核心开关。区别于传统 LLM 推理，Omni 可以把图像、文本、语音三大模态拆分为独立流水线 Stage，合理搭配 PP+TP 混合并行，既能解决超大模型显存不足问题，又能隔离多模态计算资源、平衡吞吐与延迟。
落地时记住核心准则：单机低延迟用 TP (pp=1)，多机超大规模用 PP 分层，图文批量生成混合 PP+TP，实时对话尽量关闭流水线并行。
