大模型推理流水线并行优化深度调研报告

调研主题：大模型推理流水线并行优化 所属域：大模型框架 调研日期：2026-03-14 报告版本：v1.0

目录

1. 维度一：概念剖析
2. 维度二：行业情报
3. 维度三：方案对比
4. 维度四：精华整合
5. 参考资料

维度一：概念剖析

1. 定义澄清

通行定义

大模型推理流水线并行优化（Pipeline Parallelism Optimization for LLM Inference）是指在大规模语言模型推理阶段，将模型的不同层（或层组）分配到多个计算设备（GPU/TPU）上，通过流水线方式并行执行计算，从而突破单设备显存限制并提升推理吞吐量的技术体系。

流水线并行的核心思想源自深度学习训练的 GPipe（2018）和 PipeDream（2018），但在推理场景下有其独特性：推理是自回归的、请求驱动的、延迟敏感的，这要求流水线设计必须考虑 KV 缓存管理、动态批处理、以及 token 级调度等新问题。

常见误解

边界辨析

2. 核心架构

┌─────────────────────────────────────────────────────────────────────┐
│                    大模型推理流水线并行系统架构                       │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   请求入口                                                           │
│      │                                                              │
│      ▼                                                              │
│   ┌──────────────┐                                                  │
│   │  请求调度器   │ ←─── 动态批处理 / 优先级队列 / 公平性调度          │
│   │  Scheduler   │                                                  │
│   └──────┬───────┘                                                  │
│          │                                                          │
│          ▼                                                          │
│   ┌──────────────────────────────────────────────────────────────┐ │
│   │                    流水线执行引擎                              │ │
│   │  ┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐   │ │
│   │  │ Stage 0 │ →  │ Stage 1 │ →  │ Stage 2 │ →  │ Stage N │   │ │
│   │  │ GPU 0   │    │ GPU 1   │    │ GPU 2   │    │ GPU N   │   │ │
│   │  │Layers1-8│    │Layers9-16│   │Layers17-24│  │Layers25-32│ │ │
│   │  └────┬────┘    └────┬────┘    └────┬────┘    └────┬────┘   │ │
│   │       │              │              │              │         │ │
│   │       ▼              ▼              ▼              ▼         │ │
│   │  ┌──────────────────────────────────────────────────────┐   │ │
│   │  │              KV Cache 管理层（跨 Stage 共享）           │   │ │
│   │  │         PagedAttention / Prefix Cache / Swap          │   │ │
│   │  └──────────────────────────────────────────────────────┘   │ │
│   └──────────────────────────────────────────────────────────────┘ │
│          │                                                          │
│          ▼                                                          │
│   ┌──────────────┐                                                  │
│   │  通信优化层   │ ←─── NVLink / RDMA / NCCL / 1B1S 聚合           │
│   │  Communication│                                                  │
│   └──────────────┘                                                  │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

组件职责说明：

3. 数学形式化

公式 1：流水线效率模型

$\eta_{pipeline} = \frac{T_{compute}}{T_{compute} + T_{bubble} + T_{comm}} = \frac{N \cdot t_{layer}}{N \cdot t_{layer} + (P-1) \cdot t_{layer} + (P-1) \cdot t_{comm}}$

解释：流水线效率取决于计算时间、气泡时间和通信时间的比例。其中 $N$ 是总层数，$P$ 是 Stage 数量，$t_{layer}$ 是单层计算时间，$t_{comm}$ 是 Stage 间通信时间。

公式 2：最优微批次大小

$B_{opt} = \arg\min_{B} \left( \frac{T_{total}(B)}{B} \right) = \arg\min_{B} \left( \frac{P \cdot t_{fwd}(B) + (P-1) \cdot t_{comm}(B)}{B} \right)$

解释：最优微批次大小需要在减少气泡（大批次）和降低延迟/显存占用（小批次）之间找到平衡点。

公式 3：吞吐量增益模型

$\text{Throughput}_{gain} = \frac{\text{Throughput}_{PP}}{\text{Throughput}_{single}} \approx \frac{P \cdot \eta_{pipeline}}{1 + \alpha \cdot (P-1)}$

解释：流水线并行的吞吐量增益与 Stage 数量 $P$ 和流水线效率 $\eta_{pipeline}$ 成正比，但受通信开销系数 $\alpha$ 制约。

公式 4：KV 缓存内存模型

$M_{KV} = L \cdot H \cdot D_{head} \cdot B \cdot S \cdot 2 \cdot \text{precision}$

解释：KV 缓存内存占用与层数 $L$、注意力头数 $H$、头维度 $D_{head}$、批大小 $B$、序列长度 $S$ 成正比，因子 2 表示 Key 和 Value 各一份。

公式 5：端到端延迟分解

$T_{end2end} = T_{queue} + T_{prefill} + T_{decode} + T_{comm}^{total}$

$T_{decode} = \sum_{t=1}^{T_{gen}} \max_{p \in [1,P]} \left( t_{fwd}^{(p)} + t_{comm}^{(p)} \right)$

解释：端到端延迟包含排队时间、预填充时间、解码时间和总通信时间。解码阶段每 token 的延迟由关键路径（最慢 Stage）决定。

4. 实现逻辑

class PipelineParallelInference:
    """
    大模型推理流水线并行核心系统

    关键抽象：
    - Stage: 模型层的逻辑分组，每个 Stage 运行在独立 GPU 上
    - MicroBatch: 请求被切分的最小执行单元
    - Schedule: 定义 MicroBatch 在 Stage 间的执行顺序
    """

    def __init__(self, config: PipelineConfig):
        # Stage 配置：定义每层到 GPU 的映射
        self.stage_ids = config.stage_ids  # List[int]
        self.layers_per_stage = config.layers_per_stage  # Dict[stage_id, List[layer_idx]]
        self.num_stages = config.num_stages

        # 通信后端：NCCL / GLOO / 自定义
        self.comm_backend = self._init_comm_backend(config)

        # KV 缓存管理器：跨 Stage 共享
        self.kv_cache_manager = KVCacheManager(
            max_seq_len=config.max_seq_len,
            block_size=config.block_size,
            dtype=config.dtype
        )

        # 请求调度器：动态批处理
        self.scheduler = RequestScheduler(
            max_batch_size=config.max_batch_size,
            scheduling_policy=config.scheduling_policy
        )

        # 本地模型层（当前 Stage 持有的层）
        self.local_layers = self._load_local_layers(config.model, config.local_stage_id)

    def _init_comm_backend(self, config):
        """初始化通信后端，支持点对点和集合通信"""
        if config.comm_backend == "nccl":
            return NCCLBackend(config.world_size, config.rank)
        elif config.comm_backend == "custom":
            return CustomP2PBackend(config.stage_topology)
        else:
            raise ValueError(f"Unsupported comm backend: {config.comm_backend}")

    def core_operation(self, requests: List[Request]) -> List[Response]:
        """
        核心操作：执行流水线并行推理

        流程：
        1. 请求调度和微批次切分
        2. 执行流水线调度（1F1B / GPipe / Interleaved）
        3. KV 缓存管理和跨 Stage 通信
        4. 结果聚合和返回
        """
        # Step 1: 调度请求，生成微批次序列
        micro_batches = self.scheduler.schedule(requests)

        # Step 2: 执行流水线（以 1F1B 调度为例）
        outputs = self._execute_1f1b_schedule(micro_batches)

        # Step 3: 聚合结果
        responses = self._aggregate_outputs(outputs, requests)

        return responses

    def _execute_1f1b_schedule(self, micro_batches: List[MicroBatch]) -> Dict:
        """
        执行 1F1B（One-Forward-One-Backward 变体）调度

        推理场景下的 1F1B 简化为：
        - 每个 MicroBatch 依次流经所有 Stage
        - 通过交错执行减少 bubble
        """
        num_micro_batches = len(micro_batches)
        outputs = {}

        for mb_idx, micro_batch in enumerate(micro_batches):
            # 当前 Stage 的前向计算
            hidden_states = self._forward_local(micro_batch)

            # 如果不是最后一个 Stage，发送到下一个 Stage
            if self.stage_id < self.num_stages - 1:
                hidden_states = self.comm_backend.send_recv(
                    hidden_states,
                    dst=self.stage_id + 1
                )
            else:
                # 最后一个 Stage，保存输出
                outputs[micro_batch.id] = hidden_states

            # 如果是第一个 Stage，接收新输入
            if self.stage_id == 0 and mb_idx < num_micro_batches - 1:
                next_input = self._prepare_next_input(micro_batches[mb_idx + 1])

        return outputs

    def _forward_local(self, micro_batch: MicroBatch) -> Tensor:
        """
        执行本地层的前向计算

        关键优化：
        - FlashAttention 加速注意力计算
        - Kernel Fusion 减少内存访问
        - KV Cache 复用避免重复计算
        """
        hidden_states = micro_batch.input

        for layer_idx, layer in enumerate(self.local_layers):
            # 注意力层：需要 KV Cache
            if layer.is_attention:
                kv_cache = self.kv_cache_manager.get(
                    micro_batch.request_id,
                    layer_idx
                )
                hidden_states, new_kv = layer(
                    hidden_states,
                    kv_cache=kv_cache,
                    is_prefill=micro_batch.is_prefill
                )
                self.kv_cache_manager.update(
                    micro_batch.request_id,
                    layer_idx,
                    new_kv
                )
            else:
                # MLP 层：纯计算
                hidden_states = layer(hidden_states)

        return hidden_states


class KVCacheManager:
    """
    KV 缓存管理器

    核心功能：
    - PagedAttention：页式内存分配，减少碎片
    - Prefix Cache：共享公共前缀的 KV，优化多轮对话
    - Swap：显存不足时与 CPU 内存交换
    """

    def __init__(self, max_seq_len: int, block_size: int, dtype: torch.dtype):
        self.block_size = block_size  # 每 block 的 token 数
        self.num_blocks = max_seq_len // block_size
        self.block_table = {}  # request_id -> List[block_idx]
        self.physical_blocks = torch.zeros(
            (self.num_blocks, 2, H, D, dtype),  # 2 for K and V
            device=device
        )

    def get(self, request_id: str, layer_idx: int) -> Tensor:
        """获取指定请求和层的 KV Cache"""
        block_indices = self.block_table.get(request_id, [])
        if not block_indices:
            return None
        return self.physical_blocks[block_indices]

    def update(self, request_id: str, layer_idx: int, new_kv: Tensor):
        """更新 KV Cache（解码阶段追加新 token）"""
        if request_id not in self.block_table:
            self.block_table[request_id] = self._allocate_blocks()
        # 追加新 block 或更新现有 block
        # ... 实现细节

5. 性能指标

6. 扩展性与安全性

水平扩展

流水线并行的水平扩展通过增加 Stage 数量实现：

扩展性最佳实践：

• 对于 70B 以下模型：优先使用张量并行（2-4 路），减少通信
• 对于 70B+ 模型：采用 TP+PP 混合，如 TP=4 × PP=4
• 对于千卡集群：引入 Expert Parallelism（MoE 专属）

垂直扩展

单节点内的优化上限：

安全考量

维度二：行业情报

1. GitHub 热门项目（15+ 个）

数据来源：GitHub 公开数据，检索日期 2026-03-14

活跃度筛选标准：

• 最近 6 个月有提交
• Stars > 1000（或补充项目 > 500）
• 官方维护或知名团队

2. 关键论文（12 篇）

经典高影响力论文（40%）

最新 SOTA 论文（60%）

数据来源：arXiv/ACL/NeurIPS/ICLR 等，检索日期 2026-03-14

3. 系统化技术博客（10 篇）

数据来源：官方博客/技术社区，检索日期 2026-03-14

4. 技术演进时间线

维度三：方案对比

1. 历史发展时间线

2018 ─┬─ GPipe (Google) → 提出流水线并行训练范式，引入微批次和重计算
      │
2018 ─┼─ PipeDream (Microsoft) → 1F1B 调度，显著减少流水线气泡
      │
2020 ─┼─ DeepSpeed (Microsoft) → 支持 ZeRO + 流水线并行，推动大模型训练
      │
2023 ─┼─ vLLM (Berkeley) → PagedAttention + 连续批处理，推理吞吐量革命
      │
2023 ─┼─ TensorRT-LLM (NVIDIA) → GPU 原生优化，FP8/INT4 量化支持
      │
2024 ─┼─ DistServe (Tsinghua) → 预填充/解码解耦，异构资源调度
      │
2024 ─┼─ Mooncake (Kuaishou) → KVCache 池化，多机共享缓存架构
      │
2025 ─┼─ SGLang (LMSYS) → RadixAttention + 结构化生成优化
      │
2025 ─┼─ PipeInfer (Microsoft) → 流水线推理 + 投机采样融合
      │
2026 ─┴─ 当前状态：混合并行 (TP+PP+DP) + 量化 (FP8/INT4) + 智能调度 综合优化

2. 六种方案横向对比

3. 技术细节对比

4. 选型建议

选型决策树：

                    ┌─────────────────┐
                    │  需要多 GPU 吗？  │
                    └────────┬────────┘
                             │
              ┌──────────────┴──────────────┐
              │ NO                          │ YES
              ▼                             ▼
    ┌─────────────────┐          ┌─────────────────────┐
    │ 需要量化/CPU 吗？│          │  需要混合并行吗？    │
    └────────┬────────┘          └──────────┬──────────┘
             │                              │
    ┌────────┴────────┐           ┌────────┴────────┐
    │ YES             │ NO        │ YES             │ NO
    ▼                 ▼           ▼                 ▼
llama.cpp        vLLM/        DeepSpeed        vLLM/TensorRT
Ollama          SGLang                        (单机多卡)

维度四：精华整合

1. The One 公式

用一个"悖论式等式"概括大模型推理流水线并行的核心本质：

$\text{Pipeline Inference} = \underbrace{\text{Layer Partitioning}}_{\text{容量扩展}} + \underbrace{\text{MicroBatch Scheduling}}_{\text{效率优化}} - \underbrace{\text{Bubble} + \text{Communication}}_{\text{效率损耗}}$

解读：流水线并行的收益来自模型切分带来的容量扩展和微批次调度带来的效率优化，但必须减去流水线气泡和通信开销带来的损耗。最优设计就是最大化前两项、最小化后两项。

2. 一句话解释

流水线并行就像工厂流水线：把大模型切成多段，每段在不同 GPU 上同时工作，前一段算完立刻传给下一段，这样既能装下超大模型，又能让多个请求"重叠执行"提升吞吐——代价是段间要"传话"（通信），而且偶尔要"等下家"（气泡）。

3. 核心架构图

┌─────────────────────────────────────────────────────────────┐
│              流水线并行推理核心架构                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  请求 → [调度器] → [Stage0] → [Stage1] → [Stage2] → 输出    │
│              │          │          │          │             │
│              ▼          ▼          ▼          ▼             │
│           排队时间   计算+通信   计算+通信   计算          │
│              │          │          │          │             │
│              ▼          ▼          ▼          ▼             │
│           TTFT      Bubble1    Bubble2    完成            │
│                                                             │
│  关键指标：吞吐量 = 请求数 / (TTFT + 生成时间 + 气泡)        │
│  优化目标：最大化流水线效率 = 计算时间 / (计算 + 气泡 + 通信) │
│                                                             │
└─────────────────────────────────────────────────────────────┘

4. STAR 总结

5. 理解确认问题

问题：为什么流水线并行主要提升吞吐量而非降低延迟？在什么场景下流水线并行反而会增加单请求延迟？

参考答案：

流水线并行的核心机制是让多个请求的 MicroBatch 在流水线上"重叠执行"——当请求 A 的 MicroBatch 在 Stage1 计算时，请求 B 的 MicroBatch 可以在 Stage0 同时计算。这种重叠提高了设备利用率，从而提升整体吞吐量。

但单请求的端到端延迟包含：

1. 等待 MicroBatch 填满的排队时间
2. 流经所有 Stage 的计算时间
3. Stage 间通信时间
4. 流水线气泡等待时间

与单卡推理相比，流水线并行增加了通信时间和气泡时间，因此单请求延迟可能反而增加。

延迟增加的场景：

• 小批量/单请求场景：无法充分利用重叠执行的优势，通信和气泡开销占比高
• 高通信开销环境：跨节点/低带宽网络，Stage 间传输成为瓶颈
• 不平衡的 Stage 切分：某 Stage 计算时间远大于其他，成为关键路径瓶颈

结论：流水线并行适合高并发、批量处理的场景，不适合低延迟、单请求的场景。生产环境通常配合 Continuous Batching 和动态调度来平衡吞吐和延迟。

参考资料

GitHub 项目

1. vLLM: https://github.com/vllm-project/vllm
2. TensorRT-LLM: https://github.com/NVIDIA/TensorRT-LLM
3. SGLang: https://github.com/sgl-project/sglang
4. DeepSpeed: https://github.com/microsoft/DeepSpeed
5. llama.cpp: https://github.com/ggerganov/llama.cpp
6. TGI: https://github.com/huggingface/text-generation-inference
7. MLC LLM: https://github.com/mlc-ai/mlc-llm
8. Ollama: https://github.com/ollama/ollama
9. Mooncake: https://github.com/kvcache-ai/Mooncake
10. DistServe: https://github.com/DistServe/DistServe

学术论文

1. GPipe (NeurIPS 2019): https://arxiv.org/abs/1811.06965
2. PipeDream (SOSP 2021): https://dl.acm.org/doi/10.1145/3477132.3483539
3. vLLM (OSDI 2023): https://www.usenix.org/conference/osdi23/presentation/kwon
4. Alpa (OSDI 2022): https://www.usenix.org/conference/osdi22/presentation/zheng
5. DistServe (OSDI 2024): https://arxiv.org/abs/2401.09670
6. Mooncake (arXiv 2024): https://arxiv.org/abs/2407.00079
7. SGLang (arXiv 2023): https://arxiv.org/abs/2312.07104
8. PipeInfer (arXiv 2023): https://arxiv.org/abs/2311.15562

技术博客

1. vLLM Blog: https://blog.vllm.ai
2. NVIDIA TensorRT-LLM Docs: https://nvidia.github.io/TensorRT-LLM
3. DeepSpeed Blog: https://www.deepspeed.ai
4. LMSYS Blog: https://lmsys.org/blog
5. Hugging Face Blog: https://huggingface.co/blog
6. Eugene Yan: https://eugeneyan.com

报告完成日期：2026-03-14 总字数：约 7500 字