← 返回 2026-02-25

FlowPrefill：解耦抢占与预填充调度粒度以缓解 LLM 服务中的头部阻塞 FlowPrefill: Decoupling Preemption from Prefill Scheduling Granularity to Mitigate Head-of-Line Blocking in LLM Serving

Chia-chi Hsieh, Zan Zong, Xinyang Chen, Jianjiang Li, Jidong Zhai, Lijie Wen 📅 2026-02-18 👍 1 2026-07-13 08:35
SLO 优化 大语言模型 性能优化 服务架构 系统调度
arXiv HuggingFace PDF

通过算子级抢占和事件驱动调度解耦抢占粒度与调度频率，解决 LLM 服务中长请求导致的头部阻塞问题。

前置知识

Transformer 架构

Transformer 是一种基于自注意力机制的深度学习架构，主要由堆叠的多头自注意力层和前馈网络组成。在推理过程中，每一层首先通过投影矩阵将输入隐藏状态转换为 Query、Key、Value 三个矩阵，然后计算注意力权重并进行加权求和，最后经过前馈网络和残差连接产生输出。这种架构的并行化能力使其成为大语言模型的基础，但也带来了计算和内存访问的复杂性。

论文的核心优化（算子级抢占）直接依赖于 Transformer 的层次结构和算子边界，理解这些算子的执行特性是理解 FlowPrefill 如何在保证效率的同时实现细粒度抢占的基础。

自回归生成

自回归生成是 LLM 推理的标准范式，分为两个阶段：prefill 阶段和 decode 阶段。prefill 阶段并行处理整个输入序列以初始化 KV cache 并预测第一个后续 token，decode 阶段则自回归地逐个生成 token，每次将预测的 token 追加到序列中并重复迭代直到满足终止条件。这种两阶段模式导致了计算特征的显著差异：prefill 是计算密集型的矩阵-矩阵乘法操作，decode 是内存带宽密集型的矩阵-向量乘法操作。

论文针对的头部阻塞问题主要发生在 prefill 阶段，理解两个阶段的计算特征差异是理解为什么需要专门优化 prefill 调度的关键。

头部阻塞

头部阻塞是指当长上下文的 prefill 计算独占 GPU 资源时，后续到达的高优先级短请求无法立即执行，只能排队等待的现象。在生产环境中，这会导致严重的首字时间服务等级协议违约，因为短请求需要等待长 prefill 完成后才能开始处理。在 prefill-decode 分离架构中，由于所有 prefill 工作负载被集中到相同的硬件实例，这种阻塞问题被进一步放大。

这是论文要解决的核心问题。理解头部阻塞的产生机制和影响是理解 FlowPrefill 设计动机和评估指标的基础。

Prefill-Decode 分离架构

Prefill-Decode 分离是一种将 prefill 和 decode 两个阶段解耦到不同硬件实例的架构设计。由于 prefill 是计算密集型而 decode 是内存密集型，这种分离可以消除阶段间的相互干扰，提高 GPU 利用率。在典型的 1P1D 配置中，一个 prefill 实例专门处理输入的并行处理，将 KV cache 传递给 decode 实例，后者负责后续的串行 token 生成。

FlowPrefill 主要针对 PD 分离架构设计，理解这种架构的特点和挑战是理解论文系统设计的背景。

研究动机

现有方法在处理异构 SLO 工作负载时面临根本性权衡问题。真实生产环境中的 QwenTrace 包含多种任务类型，包括 Chatbot 平均长度 590 token、Web Search 平均 5976 token、Summarization 平均 6833 token，这些任务有不同的到达模式和 SLO 要求。当长 prefill 请求占用 GPU 时，短延迟敏感请求会被阻塞，导致广泛的首字时间服务等级协议违约。Chunked prefill 虽然使 prefill 可中断，但引入了响应性和吞吐率之间的固有权衡：减小 chunk 大小改善响应延迟但降低计算效率，增大 chunk 大小最大化吞吐率但加剧阻塞。论文实验数据显示，对于 32K token 输入，chunk 大小从 512 增加到 16K 时，吞吐率提升了约 3.5 倍，但延迟也从约 0.25 秒增加到约 2.5 秒。更关键的是，Layered prefill 将执行粒度与调度频率紧密耦合，如果系统在每一层执行调度检查以最大化响应性，会产生巨大的控制平面开销，但实际上高优先级请求不会持续到达，在没有真正需要抢占时触发复杂的调度逻辑会破坏执行连续性并降低整体系统效率。

本文的目标是本文的目标是设计一个首字时间 goodput 优化的 LLM serving 系统，能够通过解耦抢占粒度与调度频率来有效处理具有异构 SLO 要求的推理请求，同时避免细粒度、持续触发调度所带来的开销。具体而言，系统需要支持自适应的 prefill 调度，使抢占能够在最合适的执行边界处被按需触发，从而消除冗余的调度开销，同时最大化 goodput 并满足多样化的 SLO 要求。

与已有工作不同的是，本文的独特切入角度在于揭示了现有系统中的结构性限制：将执行粒度与调度频率耦合迫使系统在吞吐率和 SLO 达成之间做出妥协。不同于现有方法依赖固定粒度的划分如 chunk-level 或 layer-level，FlowPrefill 提出将这两者完全解耦，通过在算子边界实现细粒度执行中断而不损失固定小分块关联的效率，以及仅当请求到达或完成事件发生时触发调度决策的机制，从而支持高效的抢占响应性同时最小化控制平面开销。这种设计自然适用于 Prefill-Decode 分离系统，有效地缓解了 prefill 诱导的头部阻塞。

核心方法

FlowPrefill 的整体思路是通过两个核心创新来解决响应性和吞吐率之间的权衡问题。首先，算子级抢占利用 Transformer 层中核心算子的自然边界作为抢占检查点，在不分割请求的情况下实现细粒度执行中断。这种方法利用了保留内核语义的最细实践执行边界，实现了高响应性而不牺牲吞吐率。其次，事件驱动调度将调度决策与执行粒度分离，仅在两种类型的事件发生时触发调度：请求到达和完成。这种设计使得系统能够及时响应高优先级请求，同时避免频繁调度检查的开销。结合这两个创新，FlowPrefill 实现了响应的服务等级感知调度，同时避免了细粒度、持续触发调度的开销。

核心创新点是将抢占粒度与调度频率解耦。在现有方法中，抢占只能发生在固定的执行边界，这迫使系统在粒度和效率之间权衡。FlowPrefill 通过算子级抢占在算子边界插入轻量级抢占检查，实现了比层级调度更细的粒度，同时避免了分块级别的分割开销。更重要的是，事件驱动调度将调度决策从执行粒度中解耦出来，仅在真正需要时才触发调度，避免了在没有抢占需求时执行不必要的调度逻辑。这种设计允许系统在保持高吞吐率的同时，为高优先级请求提供近乎非阻塞的响应。

方法步骤详情

方法步骤的完整描述如下。第一步是请求入队，当代理收到新请求时，将其解析并按顺序派发到 prefill 和 decode 实例。每个 prefill 实例维护一个专用的请求队列，跟踪系统中所有请求的逻辑状态。第二步是事件触发调度，事件监控器监控事件队列，当请求到达或完成时触发调度轮次。每个事件只触发一次调度，避免了连续轮询的开销。第三步是优先级计算，使用 Slack-aware EDF 策略计算每个请求的优先级，具有最早截止时间和非负 slack 的请求获得最高优先级。第四步是服务等级感知批处理，选择最高优先级请求，然后从候选请求中选择可以与其批处理且不会违反其服务等级协议的请求。批处理受 token 预算限制，确保批处理的好处被正确捕获。第五步是抢占决策，如果当前执行任务不是最高优先级请求，则发送抢占信号。执行池收到信号后，在当前算子完成后执行抢占检查，如果信号已设置，则取消信号、发送确认、暂停当前任务并移动到抢占任务队列。第六步是执行恢复，收到抢占确认后，调度器提交高优先级请求的执行任务。当高优先级请求完成后，其完成事件触发新的调度轮次，调度器恢复之前被抢占的任务继续执行。第七步是算子级抢占实现，在核心算子边界插入轻量级抢占检查，每次检查只涉及简单的并发原语操作，开销可忽略不计。对于张量并行部署，使用同步迭代计数器确保所有并行进程到达相同计数器时才暂停，避免死锁。

技术新颖性

技术新颖性体现在三个方面。首先，算子级抢占是首次将抢占粒度推进到 Transformer 核心算子边界的工作，比现有的层级调度提供更细的粒度，同时避免了分块级别的分割开销。这种设计利用了 LLM 架构的自然边界，具有通用性和鲁棒性。其次，事件驱动调度首次将调度决策与执行粒度完全解耦，仅在真正需要时触发调度，避免了在没有抢占需求时执行不必要的调度逻辑。这种设计结合 Slack-aware EDF 和服务等级感知批处理算法，实现了智能的资源分配和 preemptive scheduling。第三，Slack-aware EDF 策略通过将 slack 纳入优先级计算，主动降低无法满足截止时间的请求的优先级，提高了服务等级协议达成的稳定性。这与传统的 EDF 和 deadline-aware EDF 不同，具有前瞻性和鲁棒性。这些创新的结合使得 FlowPrefill 能够在高负载下保持高服务等级协议达成率，同时最大化系统吞吐率。

Overview of FlowPrefill
Figure 5: Overview of FlowPrefill
Execution logic is hierarchical, and preemption checks can be placed at different execution boundaries
Figure 6: Execution logic is hierarchical, and preemption checks can be placed at different execution boundaries
Cooperative preemption process
Figure 7: Cooperative preemption process
Example of serving two requests with different priorities in FlowPrefill
Figure 8: Example of serving two requests with different priorities in FlowPrefill

实验结果

核心发现包括多个方面的验证结果。在端到端性能提升方面，在 QwenTrace 上，FlowPrefill 在所有三个模型上都显著优于基线系统。论文实验结果显示，FlowPrefill 相比 DistServe 在 90% 服务等级协议达成率下可维持 4.7 到 5.6 倍更高的请求率，相比 DistServe-CP2K 和 DistServe-CP8K 分别提高了最多 2.0 倍和 4.5 倍。这些提升主要源于 FlowPrefill 能够在异构服务等级协议下及时抢占低优先级请求。在更严格的服务等级协议支持方面，在固定请求率下，FlowPrefill 支持 1.5 到 2.3 倍比 DistServe-CP2K 更严格的服务等级协议，以及 2.1 到 3.1 倍比 DistServe-CP8K 更严格的服务等级协议。在调度策略有效性方面，论文实验显示，Slack-aware EDF 在最大 goodput 和最小服务等级协议目标上都显著优于 naive EDF 和 deadline-aware EDF。这是因为 Slack-aware EDF 主动降低在高负载下不太可能满足其服务等级协议的请求的优先级，防止了累积队列延迟导致的达成崩溃。在算子级抢占的低开销方面，论文实验显示，算子级抢占将平均阻塞时间减少了 3.5 到 4.2 倍，从层级的 10 到 20 毫秒降低到小于 4.5 毫秒，且开销可忽略不计。在单服务等级协议场景下，FlowPrefill 保持高服务等级协议达成率，同时实现与基线相当的吞吐率。在系统兼容性方面，FlowPrefill 适用于 Prefill-Decode 分离和同部署架构，也适用于混合专家模型。在批处理策略方面，论文实验显示，适度大小的批处理 token 预算在提高吞吐率的同时保持较低的服务等级协议违约风险。

Prompt length across diverse tasks in the evaluation trace
Table 1: Prompt length across diverse tasks in the evaluation trace
Settings of different TTFT SLO requirements
Table 2: Settings of different TTFT SLO requirements
End-to-end performance of three models under varying request rates and SLO requirements on QwenTrace
Figure 9: End-to-end performance of three models under varying request rates and SLO requirements on QwenTrace
Performance comparison under three scheduling policies
Figure 10: Performance comparison under three scheduling policies
Performance comparison under varying batch token budgets and no batching
Figure 11: Performance comparison under varying batch token budgets and no batching
Average preemption blocking time under operator- and layer-level preemption boundaries
Figure 12: Average preemption blocking time under operator- and layer-level preemption boundaries
Real and predicted TTFT for three models serving a trace segment from QwenTrace at a given request rate
Figure 13: Real and predicted TTFT for three models serving a trace segment from QwenTrace at a given request rate
Performance comparison under a single-SLO workload
Figure 14: Performance comparison under a single-SLO workload
Performance of FlowPrefill with chunked prefill under different chunk sizes
Figure 15: Performance of FlowPrefill with chunked prefill under different chunk sizes
Performance comparison under the PD-colocation setting
Figure 16: Performance comparison under the PD-colocation setting
Performance comparison for serving Qwen3-30B-A3B
Figure 17: Performance comparison for serving Qwen3-30B-A3B
查看结构化数据
任务指标本文基线提升
Multi-SLO LLM Serving on QwenTrace Maximum Goodput at 90% SLO attainment 4.7 to 5.6 times higher request rate than DistServe baseline DistServe with First-Come-First-Served policy 4.7 to 5.6 times higher sustainable request rate
Multi-SLO LLM Serving on QwenTrace Minimum SLO scale supported Supports 1.5 to 2.3 times tighter SLOs than DistServe-CP2K and 2.1 to 3.1 times tighter than DistServe-CP8K DistServe-CP2K and DistServe-CP8K baselines Significantly tighter SLO requirements supported
Preemption blocking time analysis Average preemption blocking time Less than 4.5 milliseconds with operator-level preemption 10 to 20 milliseconds with layer-level preemption 3.5 to 4.2 times reduction in blocking time
Mixture-of-Experts model serving with Qwen3-30B-A3B Maximum Goodput Up to 1.6 times higher than DistServe-CP2K baseline DistServe-CP2K with 2048 token chunk size 1.6 times higher goodput and 2.4 times tighter SLO attainment

局限与改进

局限性包括多个方面的分析。作者承认算子级抢占的最小阻塞时间仍然受限于单个算子的最大运行时间。对于超长输入，单个算子可能仍然引入数百毫秒的延迟。虽然这在大多数场景下是可接受的，但对延迟极其敏感的应用可能需要更细的粒度。对于混合专家模型，虽然扩展到门控和专家算子边界，但专家级抢占粒度可能仍然较粗，特别是在专家负载不均衡的情况下。作者没有提供对混合专家模型中专家级抢占粒度的详细分析。首字时间预测模型的准确性依赖于离线预填充配置文件的多项式拟合。虽然论文显示预测足够准确，但在更复杂的工作负载或动态环境下，模型的泛化能力可能成为瓶颈。作者没有讨论如何处理预测误差或动态更新预测模型。虽然事件驱动调度减少了调度开销，但在极高并发场景下，事件队列和调度逻辑本身可能成为瓶颈。作者没有提供系统可扩展性到更大规模部署的分析。论文主要关注 prefill 阶段的优化，对 decode 阶段的调度策略讨论较少。虽然 decode 阶段不是本文的主要目标，但在某些工作负载下，decode 阶段的优化仍然重要。

独立分析的弱点

独立分析的弱点包括多个方面。算子级抢占虽然提供了细粒度的抢占能力，但对于某些模型架构，单个算子的运行时间可能仍然较长，特别是在 GPU 利用率高的情况下。改进方向可以考虑在算子内部进一步细分抢占边界，或引入预测性的 preemptive scheduling，在算子执行前预测高优先级请求的到来并提前准备抢占。首字时间预测模型依赖于离线预填充配置文件，这要求模型在部署前进行广泛的性能分析。在生产环境中，模型参数、硬件配置或工作负载特征可能动态变化，静态预测模型可能无法准确预测。改进方向可以考虑在线学习和自适应预测，根据实际运行时数据动态调整预测模型，或引入更轻量级的预测机制。事件驱动调度虽然减少了调度开销，但在某些场景下可能过于保守。例如，当系统负载很高且有很多请求在队列中等待时，仅依赖事件触发可能导致调度决策不及时。改进方向可以考虑引入混合调度策略，在事件驱动的基础上定期触发调度轮次，或在检测到高负载时增加调度频率。论文主要关注单节点或小规模集群的部署，对于大规模分布式部署，调度决策需要跨多个节点协调，这带来了额外的复杂性和开销。改进方向可以考虑分布式调度算法，结合全局资源管理和本地自适应调度，以实现更好的可扩展性。

未来方向

未来研究方向包括作者提出的扩展和基于本文成果的可延伸方向。作者提出的扩展包括将算子级抢占扩展到更多模型架构，如更多类型的混合专家架构、多模态模型，以及在更大规模部署中的性能验证。基于本文成果的可延伸方向包括动态抢占边界调整，根据输入长度、模型深度和系统负载动态调整抢占边界，在响应性和效率之间自适应权衡；多优先级队列，为不同服务等级协议级别维护多个队列，实现更精细的资源分配和优先级管理；并行调度，将调度逻辑并行化，以处理极高并发场景下的调度需求；与 decode 阶段调度的协同，虽然论文主要关注 prefill 阶段，但与 decode 阶段调度的协同可以进一步优化整体系统性能；能耗优化，结合能耗感知的调度，在满足服务等级协议的同时优化能耗效率。跨领域应用方面，算子级抢占和事件驱动调度的思想可以应用到其他具有类似执行模式的系统，如深度学习推理的其他阶段、其他类型的机器学习模型，甚至非 AI 领域的计算系统。

复现评估

复现评估方面，论文提供了一定的开源信息。实现在 vLLM-0.11.2 上进行，执行池使用线程池执行器管理每请求执行任务，每个任务在自己的线程中运行，具有专用的 CUDA stream 和 vLLM runner，通过并发原语同步。硬件环境是配备八块 NVIDIA A800-SXM4-80GB GPU 的服务器，通过每秒 200 GB 的 NVLink 互连，两颗 52 核 Intel Xeon Platinum 8470 CPU，1 TB 主机内存。评估使用三个不同规模的模型，包括 Llama3-8B 单路张量并行、Qwen2.5-14B 两路张量并行、Llama3-70B 四路张量并行。工作负载使用真实生产环境追踪数据 QwenTrace，包含四种任务类型，具有不同的 prompt 长度分布和时间戳请求到达。论文提供了一些实现细节，但没有明确发布完整的源代码或配置文件。复现难度中等，需要相同的硬件环境、vLLM 版本和 QwenTrace 数据集，但算法描述相对详细，可以在 vLLM 上重新实现。作者没有提供 Docker 镜像或详细的环境配置脚本，这可能增加复现难度。

论文图表

Request length distributions and arrival patterns for different task types in QwenTrace
Figure 1: Request length distributions and arrival patterns for different task types in QwenTrace

该图展示了 QwenTrace 生产环境追踪数据中不同任务类型的请求长度分布和到达模式。图表包含三个子图，分别显示了不同任务类型在时间轴上的请求到达情况。从图中可以观察到不同任务具有显著不同的输入长度分布和对数尺度范围，这反映了异构工作负载的特征。聊天机器人和图像理解任务通常有较短的输入但严格的服务等级协议，而网络搜索和摘要任务涉及长输入但有较宽松的服务等级协议。

这张图对理解论文很重要，因为它直观地展示了真实生产环境中的工作负载异构性，这是导致头部阻塞问题的根本原因。不同任务类型的不同长度分布和到达模式解释了为什么需要支持异构服务等级协议的调度策略，以及为什么长 prefill 请求会阻塞短延迟敏感请求。

Using different prefill granularities to meet the SLO of time-to-first-token
Figure 2: Using different prefill granularities to meet the SLO of time-to-first-token

该图对比了三种不同的 prefill 调度策略，包括分块预填充、分层预填充和本文提出的方法。图中显示了在时间轴上两个请求的执行情况，包括它们的 prefill 阶段和不同的服务等级协议约束。在分块预填充中，固定的 chunk 边界进行调度，可能导致高优先级请求的服务等级协议违约。在分层预填充中，每一层边界进行调度，虽然粒度更细但仍然可能产生阻塞。在本文方法中，通过算子级抢占和事件驱动调度实现了接近非阻塞的执行，能够满足请求的服务等级协议而不违反其他请求的服务等级协议。

这张图对理解论文很重要，因为它直观地对比了现有方法与 FlowPrefill 的区别，展示了 FlowPrefill 如何通过解耦抢占粒度与调度频率来实现更好的服务等级协议达成。图中的时间线清晰地显示了不同策略下的调度决策点和服务等级协议的影响。

Throughput and latency of chunked prefill for a 32K-token input under different chunk sizes when serving an Llama3-8B
Figure 3: Throughput and latency of chunked prefill for a 32K-token input under different chunk sizes when serving an Llama3-8B

该图展示了在不同 chunk 大小下，分块预填充的吞吐率和延迟性能。上图显示了吞吐率与 chunk 大小的关系，下图显示了 chunk 延迟与 chunk 大小的关系。图中使用了交替的颜色来标记不同的 chunks。结果显示，随着 chunk 大小的增加，吞吐率显著提升，但延迟也随之增加。这清楚地展示了分块预填充中响应性和吞吐率之间的权衡。

这张图对理解论文很重要，因为它量化地展示了现有方法面临的核心权衡：更小的 chunk 提高响应性但降低效率，更大的 chunk 提高效率但加剧阻塞。这是 FlowPrefill 要解决的关键问题。

Throughput and normalized TTFT during the prefill phase for different input lengths when serving an Llama3-8B
Figure 4: Throughput and normalized TTFT during the prefill phase for different input lengths when serving an Llama3-8B

该图展示了在 prefill 阶段，对于不同输入长度，批处理大小对吞吐率和归一化首字时间的影响。左图显示吞吐率与批处理大小的关系，右图显示归一化首字时间与批处理大小的关系。结果显示，对于短请求，批处理显著提高吞吐率，同时延迟增长适中。对于长请求，批处理提供的吞吐率增益很小，但延迟线性增长。这揭示了工作负载不对称性。

这张图对理解论文很重要，因为它揭示了不同长度请求对批处理的不同响应，这解释了为什么 FlowPrefill 采用服务等级协议感知批处理策略，只批处理可以在不违反服务等级协议的情况下一起执行的请求。