清华等团队最新研究：PipeSwift重新定义流水线并行，大模型智能体服务提速最高2.33倍

当前代码生成、网页搜索、科研辅助类的大语言模型智能体已经进入落地阶段，这类应用的运行逻辑和传统聊天机器人存在明显差异：智能体需要执行多轮交互，每轮模型的输出会触发后续的工具调用、环境交互等动作，用户不会感知到逐词生成的过程，只关心整个任务从提交到完成的总耗时。这种需求的转变，也对大语言模型服务系统的优化方向提出了新的要求。

来自清华大学、上海交通大学和北极熊科技的研究团队，近期推出了一款面向智能体场景的大语言模型服务系统PipeSwift，针对性解决了上述问题。

论文标题：PipeSwift: Revisiting Pipeline Parallelism for Large-Scale Completion-Oriented Agentic LLM Serving

论文链接：https://arxiv.org/pdf/2609.16491

研究背景

过去主流的大语言模型服务系统都是针对聊天场景设计，核心优化目标是在满足首词元延迟、词元生成间隔等服务等级目标（SLO）的前提下，最大化解码吞吐量，因此普遍采用prefill优先的调度策略：新请求到达后立刻启动prefill阶段，尽快输出第一个词元，同时尽可能聚合解码请求提升批量效率。

但这类策略放到智能体场景下会出现明显的适配问题：智能体任务的核心性能指标是作业完成时间（JCT），不需要严格的逐词元SLO约束。如果依然沿用prefill优先的策略，会导致prefill请求频繁打断解码流程，碎片化的prefill执行也无法充分利用硬件算力，最终反而拉长了整体任务的完成时间。

从实际测试的统计数据来看，智能体任务的连续多轮交互会复用大量上下文前缀，前缀缓存命中率普遍超过95%，每轮prefill只需要处理少量新增词元，这也为prefill的批量聚合提供了空间。

核心发现

为了找到智能体场景下的最优服务策略，研究团队首先对调度空间和并行策略做了系统性的探索，得到了两个关键的核心洞察。

第一个核心洞察是，prefill效率和解码效率的平衡直接决定了JCT表现，单独优化其中任意一个指标都无法得到最低的JCT。研究团队设置了一个可调节的编排间隔参数：调度器每执行I步解码后，才会聚合所有就绪的prefill请求统一处理。当I=1时就是传统的prefill优先策略，测试结果显示这种策略确实能得到最低的解码耗时，但整体JCT却比最优值高22%，原因是碎片化的prefill频繁打断解码，导致所有在途请求的解码停滞时间大幅增加。当编排间隔调整到128时，prefill的总耗时从1093.7s降到304.6s，虽然解码耗时有所上升，但整体JCT达到了最优值。

第二个核心洞察是，过去被忽视的流水线并行（PP）在JCT目标下比当前主流的宽专家并行（EP）更有优势。宽EP是当前大规模MoE模型部署的主流方案，优势是解码延迟低，但prefill阶段每层都需要跨节点通信，在节点带宽有限的情况下prefill效率偏低。而PP只需要在相邻流水线阶段之间传递激活值，不需要每层都做跨节点通信，prefill效率更高。虽然PP的解码延迟没有优势，但在prefill和解码效率的平衡下，整体JCT表现反而更好。

PipeSwift的设计创新

基于上述两个核心洞察，研究团队开发了开源的面向智能体场景的流水线并行运行时PipeSwift，主要包含三方面的设计创新。

首先是JCT感知的分层调度策略，分别针对prefill和解码阶段做了适配。在prefill阶段，由于不同请求的缓存前缀长度、新增词元长度差异较大，PipeSwift会通过离线拟合的成本模型估算每个请求的prefill开销，再用贪心的装箱算法将请求划分到多个微批次，保证各个微批次的负载均衡，同时计算最优的微批次数量，最小化流水线气泡的影响。在解码阶段，PipeSwift会在每轮prefill完成后或者有请求结束时，触发流水线冲刷，按照KV缓存的总长度重新划分微批次，避免运行过程中出现负载不平衡的问题。

其次是实现了流水线并行与多词元预测（MTP）的深度集成，这也是现有开源推理系统都不具备的能力。MTP是当前大规模MoE模型常用的推理加速技术，通过draft-verify-extend的流程一次生成多个词元，大幅提升解码效率。

但要把MTP集成到PP架构中需要解决不少问题：最后一个流水线阶段除了执行常规的层计算，还要完成验证、KV缓存更新、draft生成等额外工作，直接均分层会导致最后一个阶段成为瓶颈。PipeSwift会通过离线 profiling 调整各阶段的层分配，给最后一个阶段预留足够的开销空间，保证整个流水线的负载均衡。

最后是采用了SPMD分布式调度架构，替代了传统的中心化调度器，各个工作节点会独立生成一致的调度决策，不需要频繁在节点之间传递调度信息，大幅降低了分布式调度的 overhead，也让动态的流水线调度更容易实现。

性能表现

研究团队在64张H800 GPU的集群上对PipeSwift做了全面的性能验证，测试使用了GLM-4.7-360B和Qwen3.5-397B两个参数量超过360B的MoE模型，覆盖了代码智能体数据集SWE-Bench和网页搜索智能体数据集BrowseComp两个典型场景。

测试结果显示，在固定64GPU的资源预算下，PipeSwift的整体JCT比SGLang的宽EP部署方案低1.21-1.45倍，比vLLM的PP2部署方案低1.60-2.33倍。甚至对比使用了两倍GPU资源（128张）的SOTA PD分离部署方案，PipeSwift的JCT依然低1.14-1.54倍。

从扩展性测试来看，随着并发数和上下文长度的提升，PipeSwift的优势会进一步扩大：当单实例并发从12提升到28时，PipeSwift对比没有prefill延迟的SGLang EP方案的加速比从1.59倍提升到1.86倍；当上下文长度从64K提升到192K时，加速比也保持在1.59倍以上，最高达到1.72倍。

消融实验的结果显示，PipeSwift的调度优化可以带来1.31倍的性能提升，加上流水线集成的MTP后，整体性能提升可以达到2.29倍，验证了两个核心设计的价值。

总结与展望

PipeSwift的出现，为面向智能体场景的大语言模型服务系统提供了新的优化思路：过去针对聊天场景设计的SLO导向的优化策略，并不适配智能体场景的JCT导向需求，重新审视prefill和解码的平衡关系、重新评估不同并行策略的适用性，可以带来显著的性能提升。

研究团队也提到，当前PipeSwift使用的是固定的编排间隔，未来可以探索自适应的调度策略，根据实时的workload特征动态调整间隔值，进一步提升不同场景下的适配性。对于正在部署大语言模型智能体应用的开发者而言，PipeSwift的优化思路和落地成果也有很高的参考价值，可以帮助企业在现有硬件资源下大幅提升智能体服务的运行效率。