关键词：SGLang、流水线并行、超长上下文推理、动态分块、分布式推理

本文聚焦大语言模型（LLM）向万亿参数与超长上下文演进时的推理基础设施瓶颈，提出 SGLang 优化版流水线并行（PP）方案。

Pipeline Parallelism in SGLang: Scaling to Million-Token Contexts and Beyond
https://lmsys.org/blog/2026-01-15-chunked-pipeline/

通过集成分块流水线并行（Chunked Pipeline Parallelism）、异步点对点通信（Asynchronous P2P Communication）以及一种简单而有效的动态分块（Dynamic Chunking）机制，这种 PP 设计实现了 行业领先的性能，同时确保与其他并行策略、PD 解耦（PD Disaggregation）和 HiCache 的无缝兼容性。

在多节点部署中，在 H20 集群上使用此实现将 DeepSeek-V3.1 扩展至 PP4 TP8（即 4 路流水线并行，8 路张量并行），当分块预填充（prefill）大小设置为 12K 时，其预填充吞吐量相比 TP8 提升了 3.31 倍，相比 TP32 解决方案（2.54 倍）显著高出 30.5% 的幅度。

这凸显了 PP 在大规模跨节点扩展方面相比纯 TP 固有的架构优势。此外，我们的实现还将首字延迟（TTFT）降低了 67.9%， 同时保持了 82.8% 的强扩展效率（Strong Scaling Efficiency），为扩展用于超长上下文的万亿参数模型提供了一条高效的开源路径。

作为开源方案，其配置简单灵活， 未来还将兼容上下文并行、优化解码侧 PP 等 ，为万亿参数模型的超长上下文推理提供高效、可扩展的解决方案。

DeepSeek-V3.1 在 H20 上的预填充吞吐量（Batch Size = 1）（越高越好）注：DCK 12288 (σ=0.65) 表示启用动态分块，初始分块预填充大小设置为 12K，平滑因子设置为 0.65

关键问题

问题一：动态分块机制的理论普适性是否受限？

动态分块算法基于二次函数建模预测最优分块大小，但其核心假设是注意力机制的复杂度随序列长度呈近似二次增长。然而，不同模型架构（如 MQA、GQA、不同 FFN 结构）的实际延迟曲线可能存在显著差异。该算法是否对特定模型（如 Qwen、DeepSeek）或注意力变体存在过拟合风险？ 在未进行针对性性能拟合的模型上，其动态调整效果是否会大打折扣，甚至劣于静态分块策略？

动态分块机制的核心思想是通过建模“序列长度-处理时间”的二次关系来预测最优分块大小， 其有效性确实依赖于一个关键假设：注意力机制的计算/通信复杂度随序列长度近似呈二次增长。

从理论上讲，这一假设对于标准的全注意力（Full Attention）机制是成立的。然而，文中也明确指出，由于不同硬件、模型内核性能以及注意力变体（如 GQA、MHA）的差异，静态配置很难在所有场景下达到最优。

因此，该机制通过引入平滑因子（Smooth Factor） 这一超参数来适应这种不确定性。用户可以通过调整该因子（推荐范围 0.6-0.85）来 平衡预测的激进程度与硬件执行的稳定性，这本身就是为了应对不同模型和硬件的性能差异。

文中实验也验证了该策略在DeepSeek-V3.1 和Qwen3-235B-A22B-FP8 这两种不同架构模型上的有效性，均带来了显著的性能提升。这表明，虽然具体的最优参数（初始分块大小、平滑因子）需要根据目标模型进行微调，但动态调整以均衡各阶段计算时间 这一核心原则具有广泛的适用性。对于未经验证的新模型，该机制仍能通过动态减少分块大小来缓解因注意力计算增长导致的阶段错位，其效果至少不会差于一个选择不当的静态分块大小。

因此，该机制并非过拟合于特定模型，而是提供了一种可调的、适应非线性计算增长的通用优化框架。

问题二：流水线并行与量化优化的根本矛盾如何调和？

大尺度张量并行（如 TP32）通常因 MoE FFN 权重的量化块划分限制而无法实施。流水线并行虽缓解了此问题，但本质上仍依赖模型层的纵向切分。当模型层数有限或结构不均匀时，高 PP 度数可能导致各阶段计算负载严重失衡，加剧流水线气泡。这是否意味着在追求极致长上下文扩展时，PP 的扩展潜力仍受限于模型自身的层数规模和结构均匀性？ 是否有根本性方案能同时突破量化约束与层级划分瓶颈？

流水线并行（PP）确实通过沿模型层维度进行划分，巧妙地规避了张量并行（TP）中因 MoE FFN 权重量化块（Quantization Block） 不可分而导致的扩展限制。然而，PP 的扩展潜力并非不受限，其面临的主要瓶颈是流水线气泡 和模型层数与结构的均匀性。

首先，PP 的扩展效率受公式制约。当模型总层数固定时，增加 PP 度数意味着每个阶段分配的层数减少。如果层数过少或模型各层计算负载差异巨大（如前馈层与注意力层），即使采用动态分块，也难以完全消除阶段间等待时间，导致扩展效率下降。后文的实验也显示，随着 PP 度数增加，强扩展效率呈单调衰减趋势。

其次，对于层数有限的模型，高 PP 度数可能导致单阶段层数过少，无法充分利用 GPU 计算资源，同时增加通信开销的比重。

根本性的解决方案在于混合并行策略与系统级协同优化：

PP × CP 融合：未来路线规划（PP × CP）目标是结合流水线并行和上下文并行的优点。CP 可以无气泡地处理序列维度，在节点内与 PP 结合，有望在突破量化限制的同时，减少对模型层数均匀性的依赖，并进一步降低 TTFT。
PD 解耦架构：SGLang 原生支持的预填充-解码解耦（PD Disaggregation）允许为超长上下文预填充阶段配置高 PP 度数，而为解码阶段配置高 TP 度数或其他策略。这种异构分工让不同阶段采用最适合其计算特性的并行方式，从系统层面化解了单一并行策略的局限性。
智能划分与负载均衡：后文提到的优化技巧（如将更多层分配给较高 PP 等级）即是针对非均匀层划分的实践。更先进的划分算法可以基于模型各层的实际计算 profile 进行动态负载分配，最大化硬件利用率。

因此，虽然 PP 单独使用存在扩展限制，但通过将其作为异构混合并行架构中的一个核心组件，并与上下文并行、张量并行以及解耦 serving 架构协同设计，可以有效突破量化约束与模型结构限制，为万亿参数、百万 token 上下文的推理提供可行的扩展路径。

一、引言

随着大语言模型（LLMs）向万亿参数架构和“无限”上下文窗口扩展，底层的服务基础设施必须向更细粒度的跨节点并行化策略演进。虽然 KV 缓存技术有效地缓解了冗余计算，但它们无法规避超长序列在极长初始输入 Token 长度（Input Token Length, ITL）下固有的高昂首字延迟（Time to First Token, TTFT）。

尽管张量并行（Tensor Parallelism, TP）仍然是节点内扩展的传统方法，但它在多节点部署期间经常遇到通信瓶颈。
另一方面，尽管传统的流水线并行（Pipeline Parallelism, PP）通过减少通信量解决了这一瓶颈，但在处理如此巨大的提示词（Prompts）时，它面临着资源利用率不足和气泡（Bubble）开销的问题。

借鉴开源创新和学术研究的灵感，SGLang 引入了高度优化的流水线并行实现，具有异步通信和动态分块预填充功能，有效减少了流水线气泡。通过集成这些技术，SGLang 探索并重构了超长提示词的处理方式——有效地消除了长序列预填充的高昂延迟，并将其转化为高吞吐量、计算可扩展的流式工作流。

实证基准测试表明，SGLang 的 PP 实现达到了行业领先的性能。在大规模部署中，当扩展至 PP4 时，它对各种模型架构保持了 80% 以上的扩展效率，并且在 H20 上使用 PP8 部署 Qwen3-235B-A22B-FP8 时，对于超长提示词的首字延迟（TTFT）降低了 81%。

二、研究背景：为什么选择流水线并行？

为了验证流水线并行（PP）对于长上下文预填充的必要性，必须将其与现有的范式——特别是张量并行（TP）和上下文并行（Context Parallelism, CP）进行评估。

虽然 TP 和 CP 提供了独特的优势，但对它们的通信量、气泡率和实现复杂性进行理论和实证分解后发现，PP 在多节点扩展方面占据了独特的最佳位置。以下分析概述了每种方法固有的具体权衡。

2.1 通信量与可扩展性分析

分布式推理扩展的主要瓶颈是设备间通信。随着模型深度和序列长度的增加，设备之间传输的数据量成为限制因素，尤其是在扩展到大规模和多节点部署时。

假设代表批量大小（Batch Size，在超长上下文推理中通常为 1），代表总序列长度，代表隐藏状态（Hidden State）维度，代表总层数，代表微批量（Micro-batches）大小，激活精度为 FP8（1 字节）。基于此，我们分析了不同并行策略的通信量。

TP（张量并行）：TP 将单个权重张量在单层内的多个设备间拆分。因此，由于需要在注意力模块（Attention Block）和 MLP 模块之后进行同步，TP 产生了高昂的通信开销。因此，通信量随层数线性扩展。这种频繁的 All-Reduce（全归约）同步使 TP 受限于带宽，限制了其在大型集群上的可扩展性。注：在基于环的实现中，每个 All-Reduce 涉及数据大小。每层涉及 All-Reduce 操作，一个在注意力模块之后，一个在 MLP 模块之后。
CP（上下文并行）：类似地，CP 需要大量的同步通信来聚合跨设备的键值（KV）状态。通常，CP 在每一层利用 All-Gather（全收集），导致在带宽受限的环境中产生显著的延迟惩罚。注：假设 CP 利用基于 Ring-Attention 的解决方案。对于利用 GQA 的模型，小于，这减少了 CP 的通信量。
PP（流水线并行）：相比之下，PP 表现出显著降低的通信足迹。数据仅在流水线阶段的边界传输，使用点对点（Point-to-Point, P2P）原语而不是集合操作（Collective operations）。由于一个阶段通常包含多个层，通信频率由阶段数（）决定，而不是总层数（）。关键的是，对于一个固定的模型，当我们增加每个阶段的层数时，边界处的通信量保持不变。 注：在的多节点部署中，与 TP 相比，PP 实现了近一个数量级的总通信量减少。

2.2 气泡率（Bubble Ratio）的权衡

虽然 PP 优化了通信，但它引入了流水线气泡——即设备等待数据依赖的空闲时间。这在通信效率和设备利用率之间提出了权衡。

TP 和 CP：理论上，这两种方法都实现了零气泡率，因为所有设备同时对同一张量或序列的不同部分进行计算。假设通信不会暂停计算，这最大化了计算强度。
PP：PP 不可避免地会产生气泡率，由 PP 大小（）和微批量数量（）之间的相互作用量化：。然而，对于工作负载巨大（）的长上下文预填充场景，该比率显著降低，使得与通信收益相比，效率损失可以忽略不计。在后文性能影响部分，我们将评估我们 PP 实现的强扩展效率（即增加处理器数量，同时保持问题规模不变）。

值得注意的是，虽然 PP 在跨节点扩展方面具有明显优势（通信带宽通常成为主要瓶颈），但通常不建议使用纯高度 PP 配置。这是因为，对于固定的工作负载，流水线气泡率随 PP 大小成比例增加。

相反，更好的策略是利用无气泡并行方法（如 TP 或 CP）进行节点内扩展。由于节点内通信通常利用像 NVLink 这样的高带宽互连，这些集合操作远不像跨节点传输那样容易成为性能瓶颈，从而允许系统最大化计算利用率而不会产生额外的流水线开销。

2.3 实现复杂性与架构通用性

新功能的实现复杂性和架构通用性是现代推理系统的关键因素，特别是对于开源项目。

张量并行 (TP)：TP易于实现且支持广泛。然而，大规模TP配置在多节点扩展场景中通常不适用，因为量化所需的粒度有时无法与MoE FFN权重的分区约束对齐。因此，即使不考虑通信开销，由于与量化这一关键优化技术的不兼容性，较大的TP通常被排除在外。
上下文并行 (CP)：CP实现复杂，需要对注意力机制进行特定且通常是侵入性的修改（例如Ring Attention）。这些修改必须针对每种注意力变体和特定模型进行定制，通用性较低。
流水线并行 (PP)：PP的实现复杂度中等。它需要对模型进行分区，但对层的内部机制保持不可知。这使得PP成为适用于所有模型架构的通用解决方案，无需针对特定注意力变体进行内核级重写。在某种程度上，消除PP气泡比实现PP本身更具挑战性。

| 指标 | 张量并行 (TP) | 上下文并行 (CP) | 流水线并行 (PP) |
| :— | :— | :— | :— |
| 拆分维度 | 隐藏状态 (H) | 序列 (S) | 层 (L) |
| 通信模式 | AllReduce (每层) | AllGather (每层) | P2P (发送/接收) |
| 通信量 | 高 | 中 | 低 |
| 气泡率 | 0 | 0 | – |
| 实现复杂度 | 低 | 高 (特定于注意力变体) | 中 |
| 架构通用性 | 中 | 低 | 高 |

总之，通用性和扩展效率的平衡使得PP不仅仅是一种替代方案，而是将长上下文预填充扩展到TP和CP遇到带宽上限的大规模多节点集群的必要组件。同时，CP有潜力补充TP，用于节点内无气泡扩展和加速。PP × CP 的组合方案已在开发中。

四、挑战：“气泡”与“墙”

在传统的流水线并行设置中，模型层被分区到多个GPU（第1阶段到第N阶段）。当处理标准请求（例如 < 4K tokens）时，它通常工作良好。然而，当处理超过 128K甚至1M tokens 的提示词时，会出现两个关键问题：
1. 流水线气泡（The Pipeline Bubble）：将提示词作为整体批次处理会迫使下游GPU进入长时间的空闲状态，产生巨大的“流水线气泡”，严重降低吞吐量。
2. 内存墙（The Memory Wall）：在单次前向传递中处理100万个token的提示词需要存储和通信整个序列的中间隐藏状态，导致显著的开销和峰值内存占用。

五、SGLang 流水线并行架构

SGLang的流水线实现超越了标准的“顺序”方法，引入了多项高级功能以最小化“气泡”（即GPU空闲时间）并最大化硬件利用率。

5.1 分块流水线并行（Chunked Pipeline Parallelism, CPP）

在单次前向传递中处理100万个token的提示词会导致巨大的气泡，因为后期阶段需要等待第一阶段完成整个序列的计算。

受Mooncake[1]、BladeLLM[2]和TeraPipe[3]等架构的启发，SGLang支持分块流水线并行（CPP）。

SGLang并非将完整的提示词一次性输入流水线，而是将其划分为更小的“块”（例如4K或6K tokens）。这些块像微批量一样流过流水线阶段。通过将长提示词分解为较小的块，系统可以对预填充阶段进行“流水线化”。

一旦第一阶段完成了块1的隐藏状态计算并启动PP通信，它立即开始处理块2，而阶段2同时开始处理块1。这将流水线启动延迟从与总序列长度成正比降低到仅与第一个块的大小成正比。

从工程角度看，此方法是解决超长上下文挑战的关键第一步。值得注意的是，SGLang早在六个月前就率先支持了此功能（#5724[4], #8846[5]），体现了其长期致力于优化现实世界长上下文推理的承诺。

5.2 更好的重叠：微批量与异步P2P通信

虽然结合流水线并行和分块预填充可以比张量并行显著减少通信量，但它通常会受到流水线气泡的影响，即GPU在等待CPU元数据处理或网络传输时被阻塞。

为了消除这种性能瓶颈，SGLang实现了带有非阻塞异步点对点（P2P）通信的微批量事件循环，以将GPU计算与CPU元数据处理和PP通信重叠。这确保了当一个微批量在GPU上计算时，下一个微批量已经准备就绪并高效地移动到位，从而尽可能保持流水线饱和。 相关代码见 python/sglang/srt/managers/scheduler_pp_mixin.py[6]。

该实现的关键机制包括：
* 事件循环中的解耦同步/异步逻辑：调度程序在 _pp_send_pyobj_to_next_stage 中使用 async_send。它不等待传输完成，而是返回一个 P2PWork 句柄。实际的同步 P2PWork.work.wait() 被推迟到调用 _pp_commit_comm_work 时，允许CPU在数据传输过程中执行其他工作——例如调度下一个批次或处理元数据。
* 多流执行（Multi-Stream Execution）：除了作为同步流的主 default_stream 之外，SGLang利用专用的 forward_stream 和 copy_stream 分别执行前向传递GPU计算和主机到设备（H2D）内存传输，以实现更好的计算与通信重叠。当 _pp_launch_batch 在GPU上为当前阶段执行当前微批量时，CPU使用 _pp_process_batch_result 准备下一个微批量的结果。

5.3 高级选项：动态分块（Dynamic Chunking）

借助分块流水线并行和异步P2P通信，随着PP大小增加到4，SGLang已经实现了超过80%的强扩展效率。

然而，固定大小的分块预填充仍然会在流水线中引起气泡，并且随着PP度数的增加，这种低效变得更加明显。这种现象背后的主要原因是 模型在相同大小的块上表现出不均匀的执行延迟，这主要源于自注意力（Self-Attention）的增量性质。随着前缀序列长度的增长，每个块的处理时间呈非线性增加。这些时序不匹配在流水线中传播，加剧了更高PP等级（Rank）下的效率损失。

图1：固定分块预填充大小的流水线图

我们使用较大的PP大小测试了不同模型，发现它们都符合这一结论。下面是一个典型案例的分析结果。

图2：固定分块预填充大小下PP rank 7的分析结果

因此，如果SGLang在CPP中仍然采用固定的分块预填充大小，流水线气泡率将大于理论预期（即 1 – 1/PP_SIZE）。

为了解决这个问题，SGLang引入了一种动态分块机制来预测下一个块的最佳大小，使其满足以下条件：
下一个块的处理时间 ≈ 流水线阶段对齐的理想时间
其中 prefix_len 表示前缀序列长度，chunk_size 表示下一个块大小。通过对具有不同输入序列长度（ITL）的一系列请求进行分析，我们将累积运行时间建模为序列长度的二次函数。使用此模型，我们可以求解任何给定前缀长度 prefix_len 的最佳下一个块大小 chunk_size。由于注意力机制的计算/通信复杂度随 O(n^2) 扩展，随着 prefix_len 的增长，下一个块大小将逐渐减小，以保持流水线阶段之间对齐的块执行时间。

基于此方法，调度程序可以在运行时预测并动态调整块大小，以最小化由阶段未对齐引起的气泡。需要注意的是，调度程序不使用原始预测值。为了促进高效的KVCache内存管理并确保与硬件执行效率的亲和力，该值会向下对齐到最大（--page-size，64）的最近倍数。

图3：完美动态分块的流水线图

然而，由于硬件、模型和目标工作负载的变化，静态配置很少能在所有场景中都达到最优。因此，在切换到动态分块模式时，需要一定程度的超参数调优才能达到峰值性能。

此外，我们发现由于不同形状的内核性能变化，很难完美拟合二次函数。因此，我们引入了一个环境变量 SGLANG_DYNAMIC_CHUNKING_SMOOTH_FACTOR 来平滑动态分块算法的缩减，其默认值为 0.75。该因子决定了在预填充阶段块大小可以改变的程度。较大的值会导致更激进的块大小缩减，可能提升性能，但会增加块的总数（末尾的块可能变得非常小，反而可能导致性能下降）。

动态分块预填充的调优指南

步骤 1 – 迭代确定目标 PP 大小下的最佳固定分块预填充大小：不同的 PP 大小可能对应不同的最佳固定分块预填充大小。用户应根据可用资源进行迭代，以建立扩展基线。
步骤 2 – 动态分块的初始块大小选择：将初始块大小设置为最佳固定分块预填充大小的 2 倍或 3 倍。这有助于减少块的总数，并防止“尾部块”未充分利用硬件。为了维持极长输入 Token 长度（ITL）的效率，动态预测器会自动确保后续块的大小至少为此初始大小的 1/4。对于此类情况，也建议使用较大的初始块大小（例如最佳固定分块预填充大小的 4 倍）。
步骤 3 – 平滑因子调整：此因子控制块大小调整对二次性能拟合模型预测的遵循严格程度。
- 1.0：严格遵循模型预测。
- 0.6 – 0.85（推荐）：动态缩放与硬件稳定性之间达到最佳平衡的典型范围。实验表明，0.6 到 0.85 之间的值通常能为动态分块带来最佳性能，如图 4 和图 5 所示。
- 0：禁用动态调整，恢复为传统的固定大小分块。

图 4：DeepSeek-V3.1 平滑因子调优示例（越低越好）
图 5：Qwen3-235B-A22B-FP8 平滑因子调优示例（越低越好）

另一个小的优化技巧：当模型层无法在各流水线并行（PP）等级（Ranks）间均匀分割时，将较大的分区分配给较高的 PP 等级。这可以在较高 PP 等级等待前一阶段结果时提高 GPU 利用率，从而减少较高 PP 等级上的流水线气泡。以 DeepSeek-V3.1 为例，SGLANG_PP_LAYER_PARTITION=15,15,15,16 通常比 16,15,15,15 表现更好。

为了验证这些组合策略的有效性，我们使用动态分块分析了 DeepSeek-V3.1 的执行。如下方 PP rank 3 的分析结果所示，与静态分块方法相比，流水线气泡被显著最小化，从而实现了更饱和的执行。

图 6：动态分块下 PP rank 3 的分析结果（DeepSeek-V3.1）

5.4 生产就绪：与 PD 解耦和 HiCache 的兼容性

SGLang 的独特优势在于其原生支持流水线并行设置中的预填充-解码（Prefill-Decode, PD）解耦。

在解耦集群中，预填充节点可以利用高流水线并行度（PP）来处理极长的上下文提示词，而解码节点则可以采用不同的并行策略（如高张量并行度 TP）来最大化 Token 生成速度。

逐块 KVCache 传输：启用 PD 解耦后，SGLang 支持像 Mooncake 这样的传输引擎后端，无需等待所有块处理完成，即可立即将一个块的 KVCache 从预填充节点传输到解码节点。此功能大大降低了 KVCache 传输开销。
灵活的混合策略：SGLang 允许用户混合并利用 PD 解耦中的多种并行性。例如，可以在一组节点上运行 PP8 TP8 以处理繁重的预填充任务，同时应用其他组合（如 PP1 TP8、PP8 TP1 或 PP1 DP16 EP16）进行高吞吐量解码，从而优化推理生命周期的不同阶段。这使用户能够以高度可定制的方式满足生产环境中预期的首字延迟（TTFT）和每 Token 输出时间（TPOT）目标。
内存效率：通过跨设备分布模型权重，PP 减少了每个 GPU 的内存占用，从而允许更大的 KV 缓存和更高的并发。因此，在某些情况下，它可用于扩展最大上下文长度。

当处理超过 128K Token 的上下文时，SGLang 还支持结合 HiCache 的分块流水线并行。HiCache 是一个分布式分层 KV 缓存系统，可进一步降低超长初始 ITL 在多轮问答和智能体（Agentic）应用中的 TTFT：

语义前缀匹配：SGLang 的 HiCache 使用基于基数树的层次结构在块级别匹配前缀。当长上下文请求到达时，SGLang 可以执行分层缓存查找。如果前缀 Token（在先前块中处理过）已缓存在 HiCache 的“存储”层（例如主机内存或本地磁盘）中，PP 流水线可以完全跳过这些块的处理，从而大幅降低 TTFT。

六、性能影响

本节对 DeepSeek-V3.1 和 Qwen3-235B-A22B-FP8 模型的流水线并行（PP）性能特征进行了严格的定量评估。分析重点关注 PP 大小、动态分块（DCK）和硬件可扩展性之间的相互作用。

我们的实验测试台是一个由 6 个 H20 节点（每个节点配备 8 个 96GB VRAM GPU）组成的小型集群。由于测试资源有限，未进行 DeepSeek-V3.1 的 PP 度数为 8 的实验。此外，对于 DeepSeek-V3.1 的 PP size = 1 配置，我们使用了一个独立的 H20 节点（配备 8 个 141GB VRAM GPU）来获得输入 Token 长度为 128K 的基线性能（96GB VRAM 版本会发生 OOM）。为了更好地验证流水线饱和时的吞吐量性能，我们在吞吐量测试期间对 16 个连续请求的平均值进行了基准测试和测量。

注意：我们使用符号 DCK 来表示启用动态分块时的分块预填充大小设置，σ 代表动态分块的平滑因子。

为了进行极长上下文的实验，我们将上述模型的上下文长度重写为 100 万，仅用于性能分析。
此外，我们尝试对 DeepSeek-V3.1 使用 TP32 和对 Qwen3-235B-A22B-FP8 使用 TP8 进行实验。然而，由于权重量化块无法被 FFN（MoE）层的权重整除，大型 TP 配置本质上不受支持（参考问题[7]）。为了在多节点扩展场景中彻底比较 TP 和 PP 的差异，我们修改了 DeepSeek-V3.1 的模型实现文件（在 load_weights 中跳过部分权重加载）和 config.json（解决方法问题[8]），并设法让 TP32 仅用于性能验证。

6.1 输入 Token 吞吐量和强扩展效率

对吞吐量与 PP 大小的分析表明，两种模型系列都具有强大的水平可扩展性，尽管扩展效率的程度因配置而异。

PP 与 TP 对比：实验数据揭示了一个关键现象：当张量并行（TP）扩展至 16 路时，其性能落后于混合并行方案（PP2 TP8）。尽管两者使用的 GPU 总数相同，但 PP2 TP8 在吞吐量和延迟指标上均持续优于 PP1 TP16。类似地，在所有分块大小配置下，PP4 TP8 的表现也始终优于 PP1 TP32。值得注意的是，在固定块大小为 12288 的设置下，PP4 TP8 在其所有分块策略中表现最差。然而，即使如此，其最差性能仍比 PP1 TP32（同样采用 12288 的固定块大小，这也是纯 TP 配置中的最佳表现）高出 18.4%。若启用动态分块，这一优势将进一步扩大至 30.5%。这些结果凸显了流水线并行（PP）方法的固有优势。
DCK 的卓越可扩展性：Qwen DCK 18K 配置展现了最高的可扩展性，PP8（32 个 GPU）相比 PP1（4 个 GPU）实现了 6.14 倍 的加速比。这一性能表明，动态调整块大小优化了计算强度与节点间通信延迟之间的平衡。
架构比较：DeepSeek 模型在 PP4 规模之前，其扩展轨迹与 Qwen 模型相当。值得关注的是，DeepSeek DCK 12K (3.31×) 的性能略优于其静态 4K 变体 (3.20×)，这验证了动态分块策略在提升吞吐量方面具有跨架构的稳健性。

图 7：DeepSeek-V3.1 的吞吐量分析（越高越好）图 8：Qwen3-235B-A22B-FP8 的吞吐量分析（越高越好）

强扩展效率曲线揭示了随着系统规模扩大，硬件利用率下降的趋势（在强扩展效率分析中，输入长度保持 128K，GPU 数量增加，根据公式，流水线气泡率的下限必然升高）。随着流水线并行规模（GPU 数量）的增加，所有配置的效率均呈现单调衰减。然而，Qwen DCK 18K 在 PP8 规模下仍保持了 76.9% 的卓越效率，而静态 6K 配置的效率则下降至 69.6%，这证实了更大且动态管理的块对流水线气泡引起的性能下降更具弹性。由于资源限制，DeepSeek-V3.1 仅被评估至 PP size = 4，其效率保持在 82.8%。根据当前趋势推断，DeepSeek 模型可能会遵循与 Qwen 类似的效率轨迹，其中 DCK 预计将优于固定分块策略。

图 9：强扩展效率与流水线并行规模分析（越高越好）

6.2 百万级输入长度下的首 Token 延迟降低与横向扩展

从图 10 和图 11 可以观察到，将流水线并行规模从 PP1 增加到 PP4，能够在固定分块和动态分块设置下显著降低首 Token 延迟。其中，动态分块在不同 PP 设置下表现更优。

图 10：DeepSeek-V3.1 的首 Token 延迟分析（越低越好）图 11：Qwen3-235B-A22B-FP8 的首 Token 延迟分析（越低越好）

对于 Qwen3-235B-A22B-FP8 模型，基线首 Token 延迟约为 55.5 秒（PP1 TP4），在 PP8 TP4 配置下降低至 约 10.5 秒，延迟改善约 81.1%。
对于 DeepSeek-V3.1 模型，基线首 Token 延迟约为 48.5 秒（PP1 TP8），在 PP4 TP8 配置下降低至 约 15.5 秒，延迟改善约 67.9%。

这些结果表明，分块流水线并行在降低首 Token 延迟方面非常有效。

为了展示 SGLang 利用优化的分块流水线并行进行扩展的能力，我们在 H20 平台上使用 PP8（32 个 NVIDIA H20 GPU）对 Qwen3-235B-A22B-FP8 模型在不同输入长度下的首 Token 延迟进行了基准测试。

表 1：H20 平台上 PP8 TP4 配置下，Qwen3-235B-A22B-FP8 的首 Token 延迟与输入长度对比

如上表所示，系统能够有效扩展以处理海量上下文。即使在 100 万 Token 的极端情况下，SGLang 在 NVIDIA H20 上仍能保持高稳定性和可接受的延迟，展示了其应对最严苛长上下文应用的能力。

利用比 H20 计算能力更强、带宽更高的硬件，或跨更多节点扩展到更大的流水线并行规模（例如为 DeepSeek-V3.1 模型使用 PP8 TP16），可以进一步降低百万 Token 上下文的首 Token 延迟。

七、如何快速使用

要使用这些功能，只需配置 --pp-size 和 --chunked-prefill-size 参数。若要采用动态分块方案，请使用 --enable-dynamic-chunking 并设置环境变量 SGLANG_DYNAMIC_CHUNKING_SMOOTH_FACTOR。

注意：需要 SGLang 发布版本 >= v0.5.7

示例：服务 DeepSeek-V3.1，输入 Token 长度为 128K（共 32 个 GPU）

使用 8 路张量并行和 4 路流水线并行

预填充节点 0（固定分块预填充大小）

python3 -m sglang.launch_server
–model-path deepseek-ai/DeepSeek-V3.1 –trust-remote-code
–nnodes 4 –node-rank 0 –tp 8 –pp-size 4
–port 30000 –dist-init-addr
–mem-fraction-static 0.8 –attention-backend fa3
–host 0.0.0.0 –watchdog-timeout 3600
–max-running-requests 128 –chunked-prefill-size 4096

预填充节点 0（带动态分块）

export SGLANG_DYNAMIC_CHUNKING_SMOOTH_FACTOR=0.65
python3 -m sglang.launch_server
–model-path deepseek-ai/DeepSeek-V3.1 –trust-remote-code
–nnodes 4 –node-rank 0 –tp 8 –pp-size 4
–port 30000 –dist-init-addr
–mem-fraction-static 0.8 –attention-backend fa3
–host 0.0.0.0 –watchdog-timeout 3600
–max-running-requests 128 –chunked-prefill-size 12288 –enable-dynamic-chunking

示例：服务 Qwen3-235B-A22B-FP8，输入 Token 长度为 128K（共 32 个 GPU）

使用 4 路张量并行和 8 路流水线并行

预填充节点 0（固定分块预填充大小）

python3 -m sglang.launch_server
–model-path Qwen/Qwen3-235B-A22B-FP8 –trust-remote-code
–nnodes 4 –node-rank 0 –tp 4 –pp-size 8
–port 30000 –dist-init-addr
–mem-fraction-static 0.8 –attention-backend fa3
–host 0.0.0.0 –watchdog-timeout 3600
–max-running-requests 128 –chunked-prefill-size 6144

预填充节点 0（带动态分块）

export SGLANG_DYNAMIC_CHUNKING_SMOOTH_FACTOR=0.8
python3 -m sglang.launch_server
–model-path Qwen/Qwen3-235B-A22B-FP8 –trust-remote-code
–nnodes 4 –node-rank 0 –tp 4 –pp-size 8
–port 30000 –dist-init-addr
–mem-fraction-static 0.8 –attention-backend fa3
–host 0.0.0.0 –watchdog-timeout 3600
–max-running-requests 128 –chunked-prefill-size 18432 –enable-dynamic-chunking

八、未来路线图

我们正在不断完善 PP 堆栈，2026 年上半年 PP 路线图包括这些重要任务有：

与上下文并行（Context Parallelism）的兼容性，以进一步降低 TTFT
解码端的流水线并行
性能优化和最佳实践调优
动态分块的更好拟合和分块策略

SGLang Pipeline Parallelism 路线图状态表

状态说明：
* ✅ 已完成：关联的 Pull Request 已被合并，或在讨论中明确提及已完成。
* ⏳ 进行中/规划：列为路线图任务，但未提供已合并的 PR 链接，或明确标注为待办事项。

总结

SGLang 推出的优化版流水线并行方案，是面向大语言模型超长上下文推理的基础设施革新。该方案通过创新整合分块流水线并行、异步 P2P 通信与动态分块机制，成功破解了传统 PP 的“流水线气泡”和“内存墙”核心痛点，同时实现了与 PD 解耦、HiCache 及其他并行策略的无缝兼容。

相较于张量并行和上下文并行，该 PP 方案凭借低通信量、高架构通用性的优势，在多节点大规模部署中展现出显著性能优势：
* DeepSeek-V3.1 在 PP4 TP8 配置下比 TP32 吞吐量提升 30.5%。
* Qwen3-235B-A22B-FP8 的首次令牌生成时间最高降低 67.9%，且强扩展效率保持在 82.8% 以上，可稳定支撑百万 token 级上下文推理。

其灵活的混合并行策略、逐块 KV 缓存传输及分层缓存匹配等设计，进一步提升了生产环境适用性，为万亿参数模型的高效部署提供了实用路径。

未来随着与上下文并行的兼容及解码侧 PP 优化，该方案将持续强化超长上下文推理的效率与稳定性，为开源社区提供更具扩展性的技术支撑。

[9] Pipeline parallelism roadmap: https://github.com/sgl-project/sglang/issues/11857

关注“鲸栖”小程序，掌握最新AI资讯

本文来自网络搜集，不代表鲸林向海立场，如有侵权，联系删除。转载请注明出处：http://www.itsolotime.com/archives/18223

SGLang流水线并行：突破百万Token上下文推理瓶颈，实现3.31倍吞吐量提升

关键问题

问题一：动态分块机制的理论普适性是否受限？

问题二：流水线并行与量化优化的根本矛盾如何调和？

一、引言

二、研究背景：为什么选择流水线并行？

2.1 通信量与可扩展性分析

2.2 气泡率（Bubble Ratio）的权衡

2.3 实现复杂性与架构通用性

四、挑战：“气泡”与“墙”

五、SGLang 流水线并行架构

5.1 分块流水线并行（Chunked Pipeline Parallelism, CPP）

5.2 更好的重叠：微批量与异步P2P通信

5.3 高级选项：动态分块（Dynamic Chunking）

动态分块预填充的调优指南

5.4 生产就绪：与 PD 解耦和 HiCache 的兼容性

六、性能影响

6.1 输入 Token 吞吐量和强扩展效率

6.2 百万级输入长度下的首 Token 延迟降低与横向扩展

七、如何快速使用

示例：服务 DeepSeek-V3.1，输入 Token 长度为 128K（共 32 个 GPU）

使用 8 路张量并行和 4 路流水线并行

预填充节点 0（固定分块预填充大小）

预填充节点 0（带动态分块）

示例：服务 Qwen3-235B-A22B-FP8，输入 Token 长度为 128K（共 32 个 GPU）

使用 4 路张量并行和 8 路流水线并行

预填充节点 0（固定分块预填充大小）

预填充节点 0（带动态分块）

八、未来路线图

SGLang Pipeline Parallelism 路线图状态表

总结

相关推荐

阿里VLCache革新视觉语言模型推理：仅计算2%视觉token实现16倍加速，精度近无损

美团LongCat技术突破：LoZA稀疏注意力机制实现10倍解码加速，轻松驾驭百万级长文本

驯服GPU集群中的“吵闹邻居”：MIT等高校提出轻量级控制器，实现可预测LLM服务，TTFT p99降低10-15%

GPU上LLM推理性能瓶颈深度解析：从两阶段特性到MoE/RAG优化策略

T-MAN：NPU大模型推理的革命性方案，解码速度提升3.1倍，能效比领先84%