Pipeline Parallelism in SGLang: Scaling to Million-Token Contexts and Beyond

发表时间: 2026-01 · Blog post by Shangming Cai (lmsys.org)

原文: https://lmsys.org/blog/2026-01-15-chunked-pipeline

作者：Shangming Cai | 日期：2026年1月15日

主要贡献

随着大型语言模型（LLMs）向万亿参数架构和“无限”上下文窗口扩展，底层的服务基础设施必须向更细粒度、跨节点的并行策略演进。虽然KV缓存技术有效缓解了冗余计算，但它们无法规避超长序列和极大初始输入Token长度（ITL）所固有的极高首次Token时间（TTFT）。张量并行（TP）在多节点部署时经常遇到通信瓶颈，而传统的流水线并行（PP）在处理海量提示时，又面临资源利用率不足和气泡开销的问题。处理100万Token的提示时，单次传递会导致显著的内存峰值（内存墙）和巨大的流水线气泡。

为了解决这一问题，SGLang引入了一种高度优化的流水线并行（PP）实现，专为应对超长上下文推理的挑战而设计。该设计集成了分块流水线并行（Chunked Pipeline Parallelism）、异步P2P通信（Asynchronous P2P Communication）以及简单而有效的动态分块机制（Dynamic Chunking mechanism），不仅实现了行业领先的性能，还确保了与其他并行策略、PD（Prefill-Decode）分离架构以及HiCache的无缝兼容。

在多节点部署中，当分块预填充大小设置为12K时，此实现在H20集群上将DeepSeek-V3.1扩展到PP4 TP8配置，其Prefill吞吐量达到了TP8配置的3.31倍，并且以30.5%的优势显著超越了TP32解决方案（2.54倍）。这突显了PP在针对大规模、跨节点扩展时相对于纯TP的固有架构优势。此外，该实现还实现了高达67.9%的TTFT降低（在Qwen3-235B上甚至达到81%），同时保持了82.8%的强扩展效率，为扩展万亿参数模型的超长上下文提供了一条高效的开源路径。

注：DCK 12288 (σ=0.65) 表示启用动态分块，初始分块预填充大小设置为12K，平滑因子设置为0.65。

背景知识与设计原则

长上下文Prefill中流水线并行的必要性。为了验证流水线并行（PP）在长上下文预填充（Prefill）阶段的必要性，必须将其与现有的并行范式——特别是张量并行（TP）和上下文并行（CP）——进行评估。虽然TP和CP提供了独特的优势，但对它们的通信量、气泡比例和实现复杂度进行理论和经验上的分解表明，PP在多节点扩展中占据了独特且最佳的位置。以下分析概述了每种方法固有的具体权衡。

通信量与可扩展性分析。分布式推理扩展的主要瓶颈是设备间通信。随着模型深度和序列长度的增加，设备间传输的数据量成为一个限制因素，特别是在向大规模和多节点部署扩展时。假设$B$代表批大小（在超长上下文推理中通常为1），$S$代表总序列长度，$H$代表隐藏状态维度，$L$代表总层数，$M$代表微批次大小，且激活精度为FP8（1字节）。基于此，分析了不同并行策略的通信量。

张量并行（TP）的通信开销。TP在单个层内跨多个设备拆分独立的权重张量。因此，由于在Attention块和MLP块之后都需要进行同步，TP会产生很高的通信开销。其通信量随层数呈线性扩展。这种频繁的All-Reduce同步使得TP受限于带宽，限制了其在大型集群中的可扩展性。其通信量公式为：
$\text{Commu Volume}({TP}) = 2 \cdot (TP_{Size} - 1) \cdot \left( B \cdot S \cdot \frac{H}{TP_{Size}} \right) \cdot 2 \cdot L \cdot \text{bytes} \approx 4 \cdot B \cdot S \cdot H \cdot L \cdot \text{bytes}$
（注意：在基于环的实现中，每次All-Reduce涉及$2 \times$的数据大小。每层涉及$2 \times$的All-Reduce操作，一次在Attention块之后，一次在MLP块之后。）

上下文并行（CP）的通信开销。类似地，CP需要大量的同步通信来跨设备聚合键值（KV）状态。通常，CP在每一层都利用All-Gather操作，在带宽受限的环境中会导致显著的延迟惩罚。其通信量公式为：
$\text{Commu Volume}({CP}) = (CP_{Size} - 1) \cdot \left( B \cdot \frac{S}{CP_{Size}} \cdot 2 \cdot H_{KV} \right) \cdot L \cdot \text{bytes} \approx 2 \cdot B \cdot S \cdot H_{KV} \cdot L \cdot \text{bytes}$
（注意：假设CP采用基于Ring-Attention的解决方案。对于使用GQA的模型，$H_{KV}$小于$H$，这降低了CP的通信量。）

流水线并行（PP）的通信优势。相比之下，PP展现出显著减少的通信占用。数据仅在流水线阶段的边界进行传输，使用点对点（P2P）原语而非集合操作。由于一个阶段通常包含多个层，通信频率由阶段数（$P$）决定，而非总层数（$L$）。关键在于，对于一个固定的模型，随着我们增加每个阶段的层数，边界处的通信量保持不变。其通信量公式为：
$\text{Commu Volume}({PP}) = M \cdot \left( \frac{B}{M} \cdot S \cdot H \right) \cdot (P-1) \cdot \text{bytes} = B \cdot S \cdot H \cdot (P-1) \cdot \text{bytes}$
（注意：在$P \ll L$的多节点部署中，与TP相比，PP的总通信量实现了近乎数量级的减少。）

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

TP与CP的零气泡特性。这两种方法在理论上均实现了零气泡比例，因为所有设备同时在同一张量或序列的不同部分上进行计算。假设通信不阻塞计算，这最大化了计算强度。

PP的气泡比例量化。PP不可避免地会产生气泡比例，该比例由PP大小（$P$）和微批次数量（$M$）之间的相互作用来量化：
$\text{Bubble Ratio} = \frac{P - 1}{P - 1 + M}$
然而，对于工作负载巨大的长上下文预填充场景（$M \gg P$），这个比例显著下降，使得与通信增益相比，效率损失变得微不足道。在性能影响部分，评估了PP实现的强扩展效率（即在问题规模保持不变的情况下增加处理器数量）。

跨节点与节点内扩展策略。值得注意的是，虽然PP在跨节点扩展（此时通信带宽通常成为主要瓶颈）中提供了明显的优势，但通常不建议使用纯高阶PP配置。这是因为，对于固定的工作负载$M$，流水线气泡比例与PP大小$P$成正比增加。相反，更好的策略是利用无气泡的并行方法（如TP或CP）进行节点内扩展。由于节点内通信通常利用如NVLink等高带宽互连，与跨节点传输相比，这些集合操作极不可能成为性能瓶颈，从而允许系统在不产生额外流水线开销的情况下最大化计算利用率。

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

TP的局限性。TP易于实现且被广泛支持。然而，大规模TP配置本质上是不适用的，因为量化块所需的粒度有时无法与MoE FFN权重施加的分区约束对齐。因此，即使不考虑通信量和开销，由于与量化（这是一项关键且不可或缺的优化技术）不兼容，通常在多节点扩展场景中也会排除更大的TP。

CP的复杂性。CP很复杂，需要对注意力机制进行特定的、通常是侵入性的修改（例如Ring Attention）。这些修改必须针对每种注意力变体和特定模型进行定制，从而降低了通用性。

PP的通用性。PP代表了中等程度的复杂度。它需要对模型进行分区，但对层的内部机制保持不可知。这使得PP成为适用于所有模型架构的通用解决方案，无需针对特定注意力变体进行内核级别的重写。在某种程度上，消除PP气泡比实现PP本身更加困难。

并行策略指标对比。

• 拆分维度：TP为隐藏状态（$H$），CP为序列（$S$），PP为层（$L$）。
• 通信模式：TP为每层AllReduce，CP为每层AllGather，PP为P2P（发送/接收）。
• 通信量：TP高，CP中等，PP低。
• 气泡比例：TP为0，CP为0，PP为$\frac{P - 1}{P - 1 + M}$。
• 实现复杂度：TP低，CP高（特定于注意力变体），PP中等。
• 架构通用性：TP高，CP低，PP高。

PP的必要性与未来CP结合。通用性和扩展效率的平衡使得PP不仅仅是一种替代方案，而是将长上下文预填充扩展到TP和CP遇到带宽天花板的海量多节点集群的必要组件。同时，CP具有补充TP以实现节点内无气泡扩展和加速的潜力。PP × CP的开发已经在进行中，这将包含在后续路线图中。

方法细节

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

分块流水线并行（CPP）的引入。在单次前向传播中处理100万Token的提示会导致巨大的气泡，因为后续阶段需等待第一阶段完成。受Mooncake【1，Qin, Ruoyu, et al. "Mooncake: A kvcache-centric disaggregated architecture for llm serving." ACM Transactions on Storage (2024).】、BladeLLM【2，Yang, An, et al. "Qwen2. 5-1m technical report." arXiv preprint arXiv:2501.15383 (2025).】和TeraPipe【3，Li, Zhuohan, et al. "Terapipe: Token-level pipeline parallelism for training large-scale language models." International Conference on Machine Learning. PMLR, 2021.】等架构的启发，SGLang支持了分块流水线并行（Chunked Pipeline Parallelism）。

分块预填充的工作机制。SGLang不将完整的提示输入流水线，而是将提示划分为较小的“块”（例如4K或6K Tokens）。这些块像微批次一样流经流水线阶段。通过将长提示分解为小块，系统可以对预填充阶段进行“流水线化”。一旦第一阶段完成块1的隐藏状态计算并启动PP通信，它会立即转为处理块2，而阶段2同时开始处理块1。这使得流水线启动延迟从与总序列长度成正比，降低为仅与第一个块的大小成正比。

CPP的工程意义。这种方法标志着从工程角度应对超长上下文挑战的关键第一步。值得注意的是，SGLang在六个多月前就率先支持了此功能（#5724，#8846），突显了其对优化现实世界长上下文推理的长期承诺。

微批次处理与异步P2P通信的重叠优化。尽管结合流水线并行和分块预填充可以显著减少通信量，但它经常受到流水线气泡的影响，即GPU在等待CPU元数据处理或网络传输时发生阻塞。为了消除这种性能隐患，SGLang实现了一个带有非阻塞异步点对点（P2P）通信的微批次事件循环，使GPU计算与CPU元数据处理和PP通信重叠。这确保了当一个微批次在GPU上计算时，下一个微批次已经准备好并有效地移动到位，从而确保流水线尽可能保持饱和。

事件循环中同步/异步逻辑的解耦。调度器在_pp_send_pyobj_to_next_stage中使用async_send。它不等待传输完成，而是返回一个P2PWork句柄。实际的同步（P2PWork.work.wait()）被推迟到调用_pp_commit_comm_work时，允许CPU在数据传输过程中执行其他工作——如调度下一个批次或处理元数据。

多流执行机制。除了作为同步流的主default_stream外，SGLang还利用专用的forward_stream和copy_stream分别执行前向传播GPU计算和设备到主机（D2H）的内存传输，以实现更好的重叠。当_pp_launch_batch在GPU上为当前阶段执行当前微批次时，CPU使用_pp_process_batch_result处理上一个微批次的结果。

固定分块大小导致的流水线气泡问题。借助分块流水线并行和异步P2P通信，SGLang在PP大小增加到4时已能实现超过80%的强扩展效率。然而，固定大小的分块预填充仍会导致流水线中的气泡，且随着PP深度的增加，这种低效变得更加明显。其主要原因是，由于自注意力的增量特性，模型在相同大小的块上表现出不均匀的执行延迟。随着前缀序列长度的增长，每个块的处理时间呈非线性增加。这些时间不匹配在流水线中传播，在更高的PP秩上加剧了效率损失。

固定分块的图表验证。测试了使用大PP大小的不同模型，发现它们均符合此结论。以下是典型情况的性能分析结果。

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

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

因此，如果SGLang仍对CPP使用固定的分块预填充大小，流水线气泡比例将大于理论预期（即$\frac{P - 1}{P - 1 + M}$）。

动态分块机制的引入与数学建模。为解决此问题，SGLang引入了动态分块机制来预测下一个块的最佳大小，使其满足以下条件：
$\text{Runtime}(L + \Delta L) - \text{Runtime}(L) = \text{Runtime}(\text{Initial Chunk Size})$
其中$L$表示前缀序列长度，$\Delta L$表示下一个块的大小。通过分析一系列具有不同ITL的请求，将累积运行时间建模为序列长度的二次函数。使用该模型，为任何给定的前缀长度$L$求解最佳的下一个块大小$\Delta L$。由于注意力机制的计算/通信复杂度随$L$扩展，下一个块的大小将随着$L$的增长逐渐减小，以保持跨流水线阶段对齐的块执行时间。

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

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

平滑因子的引入与调优需求。然而，由于硬件、模型和目标工作负载的差异，静态配置很少能在所有场景中达到最优。因此，实现峰值性能需要在切换到动态分块模式时进行一定程度的超参数调优。此外，发现由于不同形状的内核性能差异，很难完美拟合二次函数。因此，引入了一个环境变量（SGLANG_DYNAMIC_CHUNKING_SMOOTH_FACTOR）来平滑动态分块算法的缩减，默认值为0.75，该变量决定了预填充阶段块大小变化的程度。较大的值会导致更激进的块大小缩减，可能提高性能，但会增加总块数（末尾的块大小可能变得非常小，从而导致性能下降）。

动态分块预填充的调优指南-步骤1。迭代以找到目标PP大小的最佳固定分块预填充大小：目标ITL的不同PP大小可能具有不同的最佳分块预填充大小。因此，用户应根据可用的扩展资源进行迭代以获得基准。

动态分块预填充的调优指南-步骤2。动态分块的初始块大小选择：将初始大小设置为最佳固定分块预填充大小的$2 \times$或$3 \times$。这减少了总块数，并防止“尾部块”未充分利用硬件。为了在极大的输入Token长度（ITL）下保持效率，动态预测器会自动确保后续块至少为该初始大小的1/4。此外，在此类情况下，建议使用更大的初始块大小（例如，最佳固定分块预填充大小的$4 \times$）。

动态分块预填充的调优指南-步骤3。平滑因子调整：该因子控制块大小调整对二次性能拟合模型预测的遵循程度。

• 1.0：严格遵循模型。
• 0.6 – 0.85（推荐）：动态扩展和硬件稳定性之间最佳平衡的典型范围。通过实验发现，0.6到0.85之间的范围通常产生动态分块的最佳性能，如图4和图5所示。
• 0：禁用动态调整，恢复为传统的固定大小分块。

图4：调整DeepSeek-V3.1平滑因子的示例（越低越好）

图5：调整Qwen3-235B-A22B-FP8平滑因子的示例（越低越好）

层分区优化技巧。当层数无法被秩均匀整除时，将较大的分区放在较高的PP秩中。这可以在较大的PP秩等待前一阶段结果时提高GPU利用率，从而减少较高PP秩上的气泡。以DeepSeek-V3.1为例，SGLANG_PP_LAYER_PARTITION=15,15,15,16通常比16,15,15,15表现更好。

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

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

与PD分离架构的生产级兼容性。SGLang的一个独特优势是在流水线设置内原生支持预填充-解码（PD）分离。在分离集群中，预填充节点可以使用高阶PP处理极长上下文提示，而解码节点可以使用不同的并行策略（如高阶TP）最大化Token生成速度。

逐块KVCache传输。SGLang支持mooncake等传输引擎后端，当启用PD分离时，它可以立即将一个块的KVCache从预填充节点传输到解码节点，而无需等待所有块完成。此功能极大地减少了KVCache传输开销。

灵活的混合策略。SGLang允许用户在PD分离中混合利用多种并行机制。可以在一组节点上运行PP8 TP8进行繁重的预填充任务，并应用其他组合，如PP1 TP8、PP8 TP1和PP1 DP16 EP16进行高吞吐量解码，针对推理生命周期的不同阶段进行优化。这允许用户以高度可定制的方式满足生产中预期的TTFT和TPOT目标。

内存效率。通过跨设备分配模型权重，PP降低了单GPU的内存占用，允许更大的KV缓存和更高的并发性。因此，在某些情况下可用于扩展最大上下文长度。

与HiCache的兼容性。处理超过128K Token的上下文时，SGLang还支持结合HiCache（一种分布式分层KV缓存系统）的分块流水线并行，以进一步减少超长初始ITL的多轮QA和智能体应用的TTFT。

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

实验环境

• 硬件配置：主要实验在一个包含6个H20节点（每个节点配备8张96GB VRAM GPU）的小型集群上进行。由于资源限制，未进行DeepSeek-V3.1的PP度为8的实验。对于DeepSeek-V3.1的PP大小=1配置，使用了一台独立的H20节点（8张141GB VRAM GPU）以获取128K输入长度的基线性能（在96GB VRAM版本上会发生OOM）。
• 模型配置：测试了DeepSeek-V3.1和Qwen3-235B-A22B-FP8模型。为了进行极长上下文实验，手动将上述模型的上下文长度覆盖为100万，仅用于性能分析。
• 软件与测试配置：为了彻底比较多节点扩展场景中TP和PP的差异，修改了DeepSeek-V3.1的模型实现文件（跳过了load_weights中的部分权重加载）和config.json，成功使TP32运行仅用于性能验证。在吞吐量测试期间，记录了16个连续请求的平均值以验证流水线饱和时的吞吐性能。

实验结果

输入Token吞吐量与强扩展效率实验。

• 实验内容：分析了不同分块策略和PP大小下的吞吐量表现，并对比了PP与纯TP策略的性能。
• 实验结果与分析：
  • PP对比TP：将张量并行（TP）扩展到16时观察到性能下降。相比之下，混合并行方法（PP2 TP8）在吞吐量和延迟指标上始终优于PP1 TP16。此外，对于所有分块大小配置，PP4 TP8也始终优于PP1 TP32。值得注意的是，在固定分块大小12288下，该设置在PP4 TP8的所有分块策略中表现最差。然而，PP4 TP8的最差性能仍以18.4%的显著优势超越了PP1 TP32（同样使用12288的固定分块大小），尽管后者已代表了所测试的纯TP配置的最佳性能。启用动态分块后，这一优势增加到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吞吐量分析）。

图7：DeepSeek-V3.1的吞吐量分析（越高越好）

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

• 强扩展效率分析：强扩展效率曲线说明了系统扩展时硬件利用率的衰减（在分析中，ITL保持128K不变而$P$增加，根据公式，气泡比例下限必然更高）。所有配置在PP大小（GPU数量）增加时均表现出单调的效率衰减。然而，Qwen DCK 18K在PP8规模下仍保持了76.9%的优异效率，而静态6K配置则降至69.6%。这证实了动态管理的较大分块对由流水线气泡引起的性能下降具有更强的弹性。DeepSeek-V3.1在评估至PP大小=4时，保持了82.8%的效率。
• 图表引用：图9（强扩展效率与PP大小分析）。

图9：强扩展效率与PP大小分析（越高越好）

TTFT降低与百万Token扩展实验。

• 实验内容：测试不同PP配置下的首次Token时间（TTFT），并在Qwen3模型上测试了高达100万Token的极端输入长度。
• 实验结果与分析：
  • 从图10和图11可以观察到，将PP大小从PP1增加到PP4，无论是固定分块设置还是动态分块设置，都能大幅度降低TTFT。且动态分块在不同PP设置下表现更好。对于Qwen3-235B-A22B-FP8，基线TTFT约为55.5秒（PP1 TP4），在PP8 TP4配置下减少到约10.5秒，延迟改善约81.1%。对于DeepSeek-V3.1，基线TTFT约为48.5秒（PP1 TP8），在PP4 TP8配置下减少到约15.5秒，延迟改善约67.9%。这些结果表明分块流水线并行在降低TTFT方面非常有效。
  • 为了展示SGLang在优化后的CPP下的可扩展性，在H20 GPU上针对PP8配置的Qwen3基准测试了不同输入Token长度下的TTFT。即使在100万Token的极端边缘，SGLang在NVIDIA H20上也保持了高稳定性和可接受的延迟（420.91秒）。
  • 图表/表格引用：图10（DeepSeek-V3.1 TTFT分析），图11（Qwen3 TTFT分析），表1（Qwen3 1M Tokens TTFT）。

图10：DeepSeek-V3.1的TTFT分析（越低越好）

图11：Qwen3-235B-A22B-FP8的TTFT分析（越低越好）

表1：Qwen3-235B-A22B-FP8在H20上使用PP8 TP4的TTFT与输入Token长度对比

补充细节

入门使用指南与参数配置。要利用这些功能，用户只需配置--pp-size和--chunked-prefill-size。要进一步采用动态分块解决方案，需使用--enable-dynamic-chunking并设置环境变量SGLANG_DYNAMIC_CHUNKING_SMOOTH_FACTOR。注意：要求SGLang发布版本 >= v0.5.7。

DeepSeek-V3.1服务配置示例。以下是处理128K输入Token长度（共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 <MASTER_NODE_IP> \
  --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 <MASTER_NODE_IP> \
  --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服务配置示例。以下是处理128K输入Token长度（共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 <MASTER_NODE_IP> \
  --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 <MASTER_NODE_IP> \
  --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

结论

SGLang对流水线并行的实现不仅仅是模型权重的拆分；它是对长上下文时代推理生命周期的彻底重新设计。通过将分块预填充与异步通信和动态分块相结合，SGLang为服务和加速万亿参数模型的长上下文提供了一条最有效且开源的路径。未来的路线图（2026年上半年）将包括与上下文并行（CP）兼容以进一步降低TTFT、解码端的流水线并行（性能优化和最佳实践调优），以及为动态分块提供更好的拟合和分块策略。

附录

致谢与社区贡献。感谢SGLang团队和社区提供的实现和慷慨支持，特别是Shangming Cai、Xuchun Shang、Yanbo Yang、Leon Gao、Ying Sheng、Zhiqiang Xie、Lianmin Zheng及其他许多人。感谢来自蚂蚁集团SCT网络团队的Jianhao Fu、TikTok的Kevin Li、阿里云计算的Siyu Liu和Teng Ma、字节跳动的Xiaolei Zhang、美团的Chao Wang以及NVIDIA的Xiaowei Wang在代码改进和测试方面做出的突出贡献。

系统设计启发与参考文献。从SGLang、Mooncake【1，Qin, Ruoyu, et al. "Mooncake: A kvcache-centric disaggregated architecture for llm serving." ACM Transactions on Storage (2024).】和TeraPipe【3，Li, Zhuohan, et al. "Terapipe: Token-level pipeline parallelism for training large-scale language models." International Conference on Machine Learning. PMLR, 2021.】的系统设计中学到了很多，这些共同帮助改进了此流水线并行的实现。此外参考了Qwen2.5-1M的技术报告【2，Yang, An, et al. "Qwen2. 5-1m technical report." arXiv preprint arXiv:2501.15383 (2025).】。