LAPS: A Length-Aware-Prefill LLM Serving System

作者/机构: Jianshu She 1, Zonghang Li 1, Hongchao Du 1, Shangyu Wu 1, Wenhao Zheng 2, Eric Xing 1, Zhengzhong Liu 1, Huaxiu Yao 2, Jason Xue 1, Qirong Ho 1

A1 主要贡献

现代大语言模型（LLM）服务栈，如 vLLM 和 SGLang，通常结合 prefill-decoding (PD) 分离 和 连续批处理（continuous batching） 技术以满足低延迟、高并发的服务水平目标（SLO）。其中，Prefill 阶段（计算第一个 token）主要受计算限制，而 decoding 阶段（自回归生成）主要受内存限制。PD 分离将这两个阶段解耦到不同的实例上，以避免跨阶段的资源争抢。然而，研究发现，即使进行了 PD 分离，当计算密集型的长 prefill 请求与内存密集型的短 prefill/re-prefill 请求混合在一起时，prefill 阶段内部仍然存在干扰。

核心问题与观察:
1. Re-prefill 的普遍性与特性：在多轮对话、工具使用、RAG、推测解码等场景中，re-prefill 操作非常普遍。这种操作通过结合新 token 和缓存的 KV state 来扩展现有上下文，通常是内存密集型的，其性能瓶颈在于 KV-cache 的读写而非大规模的 GEMM 运算。
2. 真实世界工作负载的异构性：通过分析真实世界的多轮对话数据集 LMsys-Chat-1M（图 2），发现大多数提示（prompt）都是短的（<256 tokens），而长上下文请求（>1K tokens）相对较少。这表明生产环境中的工作负载主要由内存密集型的短 prefill/re-prefill 构成。
3. Intra-Prefill 干扰：将内存密集型的短 prefill 与计算密集型的长 prefill 混合在统一的批处理中，会引发计算-内存干扰。短 prefill 请求需要等待耗时长的 GEMM 运算完成，导致首个 token 生成时间（TTFT）飙升；而长 prefill 请求则因短任务产生的大量 KV 缓存流量而损失有效的浮点运算性能。图 1 证实了这一问题：混合长短 prefill 会显著增加长 prefill 请求的延迟，并且随着并发度的升高，这种争用会变得更加严重。

图 1. 在不同长短请求并发水平下，长 prefill 请求的 P90 TTFT。长 prefill 请求的 token 超过 1K，而短 prefill 请求的 token 少于 64。我们在单个 H200 GPU 上并发运行它们，并使用 Qwen2.5-32B 模型提供服务。虚线表示仅处理长 prefill 请求时的延迟。

图 2. 真实 LMsys-Chat-1M 数据集中多轮对话的 token 长度分布。左图显示了第一轮的提示长度（默认包含系统提示），其中约 63% 的请求包含少于 256 个 token。在后续轮次中，短于 256 个 token 的提示比例增加到平均 81%。

研究目标与创新点 (LAPS 系统):
为解决上述挑战，本文提出了 LAPS (Length-Aware-Prefill LLM Serving system)，一个在 prefill 阶段内对长短 prefill 工作负载进行显式分离和优化的 LLM 服务系统。LAPS 引入了以下主要贡献：

经验性特征分析：分析了多轮工作负载中长短请求之间的 intra-prefill（prefill 阶段内部）干扰，揭示了当前批处理策略导致的计算-内存争用问题。
基于长度的请求分离：设计了一种请求级别的 prefill 时间/空间分离架构。该架构通过隔离长短 prefill 请求，从根本上消除了它们之间的相互干扰。
- 时间分离：在单个 prefill 实例上，按时间顺序隔离执行长短 prefill 批次。
- 空间分离：在多个 prefill 实例上，将长短 prefill 批次分配到不同的实例上执行。
自适应调度策略：
- 针对短 prefill：引入了动态等待窗口和基于输入长度的分桶（bucketizing）机制，使请求更加统一，从而实现更大的批处理大小。这结合 CUDA Graph 执行，减少了批处理启动开销，加速了处理过程。
- 针对 SLO 服务：设计了 SLO 感知的调度器，平衡等待窗口和吞吐量之间的权衡。
- 负载均衡：在多实例部署中，调度器根据实时负载动态调整每个实例处理的工作负载类型，实现跨空间分离的 prefill 实例的负载均衡。

LAPS 与现有的 PD 分离架构兼容，并在此基础上引入了 prefill 批次的时间/空间分离模式，从而进一步优化了异构 LLM 服务工作负载。

A3 背景知识与动机

2.1 (Re-)Prefill 的计算-内存边界

统一延迟模型。prefill 和 re-prefill 阶段具有不同的延迟特性。re-prefill 在处理新 prompt token 的同时还需关注历史 token，这增加了计算和内存开销，并改变了（re-）prefill 从计算密集型转变为内存密集型的 token 长度边界点 $L_m$。我们构建一个统一的延迟模型来确定 prefill 和 re-prefill 的边界 $L_{prefill_m}$ 和 $L_{re-prefill_m}$。总延迟 $T(L, H) = T_{comp}(L, H) + T_{mem}(L, H)$，其中 $L$ 是新 token 数，$H$ 是历史 token 数。计算延迟项 $T_{comp}$ 反映了增量因果注意力和 FFN 的计算：

$$T_{\mathrm{comp}}(L, H) \approx \alpha L(L+2 H)+\beta L,$$

其中 $\alpha$ 和 $\beta$ 分别是 attention 和 FFN 计算的每 token 成本。内存延迟项 $T_{mem}$ 模拟了 KV 读/写 I/O 的时间：

$$T_{\text{mem}}(L, H) \approx \gamma_{w} L + \gamma_{r} H,$$

其中 $\gamma_w$ 和 $\gamma_r$ 分别是每 token KV 写/读的时间。

Prefill 阶段的边界。在首轮 prefill 中，历史 $H=0$，因此 $T_{comp}(L, 0) \approx \alpha L^2 + \beta L$ 且 $T_{mem}(L, 0) \approx \gamma_w L$。通过令这两个部分相等，可以得到边界点：

如果 $\gamma_w \le \beta$，prefill 总是计算密集型的；否则，当 $L < L_{prefill_m}$ 时，内存访问占主导。

Re-prefill 阶段的边界。对于 re-prefill，当 $H > 0$ 时，计算和内存延迟项为：

$$T_{\text{comp}}(L, H) \approx \alpha L^{2}+(2 \alpha H+\beta) L,$$

$$T_{\text{mem}}(L, H) \approx \gamma_{w} L+\gamma_{r} H,$$

因此边界由以下公式给出：

$$L_m^{\text{re-prefill}} = \max\left(0, \frac{-(2\alpha H + \beta - \gamma_w) + \sqrt{(2\alpha H + \beta - \gamma_w)^2 + 4\alpha\gamma_r H}}{2\alpha}\right).$$

对于固定的 $H > 0$，当 $L < L_{re-prefill_m}$ 时，re-prefill 是内存密集型的，因为当 $L \to 0$ 时，$T_{mem}(L, H) \to \gamma_r H > 0$ 而 $T_{comp}(L, H) \to 0$。随着 $H$ 的增加，边界 $L_{re-prefill_m}$ 会增长直到一个饱和点，即当 $H \gg |\beta - \gamma_w|/(2\alpha)$ 时，$L_{re-prefill_m} \to \gamma_r / (2\alpha)$。因此，在有长历史记录的情况下，re-prefill 在一定数量的新 token 内保持内存密集型。

运行时拟合与 Roofline 模型。计算和内存延迟可以分别建模为 $(L, H)$ 的二次和线性函数。通过收集运行时样本 $(T_{comp}, T_{mem}, L, H)$ 来拟合曲线，得到 $\alpha, \beta, \gamma_w, \gamma_r$，从而计算出边界 $L_{prefill_m}$ 和 $L_{re-prefill_m}$。另外，根据 Roofline 模型，prefill 的计算强度随 prompt 长度 $L$ 线性增加。当计算强度 $AI(L)$ 达到硬件的 roofline 斜率 $AI^* = P_{peak}/B_{mem}$ 时，即为计算-内存边界。在 A100、H100 和 H200 等硬件上进行的实证分析表明【索引35, Llm inference unveiled: Survey and roofline model insights, 2024, https://arxiv.org/abs/2402.16363】【索引39, Distserve: Disaggregating prefill and decoding for goodput-optimized large language model serving, 2024, https://arxiv.org/abs/2401.09670】，这个转变通常发生在 150 到 512 个 token 之间。

2.2 探索长短 Prefill/Re-prefill 间的干扰

排队论模型分析。我们使用标准的 M/G/1（马尔可夫/通用/单服务器）先进先出（FCFS）排队模型【索引23, Solving m/g/l type markov chains: recent advances and applications, 1998, Stochastic Models】来分析长短 prefill 请求之间的干扰。短 prefill 和 re-prefill 作业通常是内存密集型的，而长 prefill 作业是计算密集型的。我们将请求处理过程建模为经过计算站和内存站两个服务站。

表 1. 按 prefill 和 decode 特征进行任务分类。SPSD: 短 prefill, 短 decode; SPLD: 短 prefill, 长 decode; LPSD: 长 prefill, 短 decode; LPLD: 长 prefill, 长 decode。

图 3. 在不同长短请求并发水平下，短 prefill 请求的 P90 TTFT。虚线表示仅处理短 prefill 请求时的延迟。其他设置与图 1 相同。

队头阻塞（HoL Blocking）惩罚。根据 Pollaczek-Khinchine (P-K) 结果【索引24, Generalizations of the pollaczek-khinchin integral equation in the theory of queues, 1986, Advances in applied probability】，M/G/1 队列的平均等待时间为：

$$W = \frac{\lambda \mathbb{E}[S^2]}{2(1 - \rho)}$$

当不同长度的作业被批处理在一起时，服务时间的方差会增加所有请求的等待时间，引入队头阻塞（HoL）惩罚：

$$\Delta W_{\text{HoL}} = \frac{\lambda p(1-p)}{2(1-\rho)}(S_{\ell} - S_{s})^2 > 0.$$

这个惩罚项随着并发度和服务异构性的增加而增长，解释了在混合长短 prefill 工作负载中观察到的延迟增加现象（如图 1 和图 3 所示）。

护航效应（Convoy Effect）。长 prefill 对短（re-）prefill 的影响更大。由于所有类别的请求都面临相同的排队时间 $W$，其归一化延迟为 $R_i / S_i = 1 + W / S_i$。考虑到短作业的服务时间 $S_s$ 小于长作业的服务时间 $S_l$，短作业的相对延迟增加（$W/S_s$）会比长作业（$W/S_l$）更大。这种护航效应解释了为什么随着长 prefill 并发度的增加，短 prefill 的延迟增长得更快，这是带宽争用的明显症状。

2.3 揭示长短 Prefill 混合的来源

任务多样性导致混合。通用 LLM 服务必须处理多种任务，如表 1 所示，日常聊天和创意生成是典型的短 prompt 任务，而推测解码和 token 路由则产生高频的短 re-prefill。相比之下，长文档问答和自主代理工作流则对应长上下文 prefill。在实践中，这些不同类型的请求流会随时间交错出现，导致 prefill 工作负载中出现长短请求混合。

现有调度系统的局限性。大多数现有系统（如 vLLM 【索引18, Efficient memory management for large language model serving with pagedattention, 2023, https://arxiv.org/abs/2309.06180 】, TGI 【索引12, Text generation inference documentation, 2024, https://huggingface.co/docs/text-generation-inference/en/index】）采用 FCFS 方式调度请求，并将它们打包到统一的批次中。即使是采用多队列设计的系统（如 Sarathi-Serve 【索引1, Sarathi: Efficient llm inference by piggybacking decodes with chunked prefills, 2023, https://arxiv.org/abs/2308.16369】、TensorRT-LLM 【索引4, NVIDIA/TensorRT-LLM, 2023, https://github.com/NVIDIA/TensorRT-LLM】），其队列也大多是面向阶段（prefill vs. decode）或基于 SLA 的。因此，长短（re-）prefill 请求仍然会被共同批处理。

与长度分桶的区别。最相关的工作是长度分桶（length bucketing）【索引8, Multi-bin batching for increasing llm inference throughput, 2024, arXiv:2412.04504】【索引38, Bucketserve: Bucket-based dynamic batching for smart and efficient llm inference serving, 2025, arXiv:2507.17120】，它将请求按预测的序列长度分组到大小均匀的桶中，以减少填充（padding）并提高吞吐量。然而，这些方法只优化了批次内的长度方差，并未分离 prefill 与 re-prefill，也没有解决我们所识别的计算-内存干扰问题。

A2 方法细节

LAPS 旨在缓解多轮 LLM 服务中长短 prefill 请求之间的干扰。这种干扰源于两个主要因素：（1）它们异构的计算特性，以及（2）统一批处理导致的队头阻塞。LAPS 建立在 PD 分离架构的 prefill 实例之上，并在 prefill 阶段内增加了更细粒度的分离设计。

3.1 短 Prefill 优化

动机。在自回归服务中，大部分端到端延迟通常来自 decode 阶段，因此现有优化多集中于 decode 阶段。然而，随着 LLM 工作负载的多样化，prefill 阶段已成为日益重要的瓶颈，但其优化潜力，特别是对短 prefill 和多轮 prefill 的优化，很大程度上被忽视了。

在 Prefill 阶段应用 CUDA Graph 的可行性。传统上，由于输入长度和批次组成变化很大，导致张量形状不稳定，prefill 阶段不使用 CUDA Graph。然而，在多轮对话中，re-prefill 步骤处理的是新的用户输入，不包含系统提示，因此序列更短且更均匀。这种稳定的形状模式符合 CUDA Graph 的固定结构要求，使得通过填充或分桶（例如，长度为 8, 16, 32, 64）实现高图重用率成为可能。

图捕获与分桶。LAPS 借鉴了 EAGLE-2 的推测解码优化思路【索引21, Eagle2: Faster inference of language models with dynamic draft trees, 2024, https://arxiv.org/abs/2406.16858】【索引22, Eagle-3: Scaling up inference acceleration of large language models via training-time test, 2025, https://arxiv.org/abs/2503.01840】，预定义了一个由 prompt 长度和批处理大小组成的 2 的幂次方网格（例如，$L \in \{8, 16, ..., 256\}$ 和 $B \in \{1, 2, ..., 64\}$）。在系统初始化时，为每个桶捕获一个 CUDA Graph。在推理过程中，每个短 prefill 请求被填充到最接近的桶，并与共享相同 $(L, B)$ 配置的其他请求组合，从而以可忽略的内存开销最大化图的重用。

图感知内存批处理。为了最大化 CUDA Graph 对短 prefill 工作负载的益处，LAPS 的批处理策略旨在：（i）减少图启动频率，（ii）提高大批量图的重用率。这通过适度延长等待窗口和图融合来实现。在高并发下，稍微延迟批处理的形成可以让更多的短 prefill 请求累积起来，当节省的启动开销超过等待成本时，整体效率得以提高。图 5 展示了不同等待窗口设置下的延迟-吞吐量权衡。

自适应等待深度（AWD）调度器。如算法 1 所示，AWD 调度器维护两个自适应阈值：等待窗口 $W$（调度前等待的最大时间）和目标深度 $D$（与捕获的 CUDA Graph 形状对齐的期望批大小）。

在每个调度轮次中，AWD 累积短 prefill 请求，直到等待窗口 $W$ 到期或达到目标深度 $D$。
请求按输入长度贪婪地分组以最小化填充，如果任何请求接近其截止日期，则提前调度。
在调度前，批次会与最接近的已捕获 CUDA Graph 配置进行匹配以最大化图重用；否则，使用标准的 prefill 内核。
每次调度后，根据观察到的填充时间和实际批处理大小，动态更新 $W$ 和 $D$ 用于下一轮调度。

图 5. 不同等待窗口下的平均延迟和吞吐量曲线。等待窗口越大，批处理的短 prefill 请求就越多。该服务系统在 H200 GPU 和一个 14B 模型上运行，短 prefill 请求（提示长度小于 256 token）的并发度为 64。

算法 1 AWD: 自适应等待深度批处理 (短 Prefill)
输入: 捕获的形状 H(深度, 内存), 预算 M, 松弛阈值 σ, 边界 [W_min, W_max], 服务时间估计 S
1 W ← clip(min_i(DDL_i - t - S), [W_min, W_max])
  D ← max_{G∈H: mem(G)≤M} depth(G)
2 while 服务器运行 do
3   启动计时器; B ← ∅
    while 已用时间 < W and depth(B) < D do
4     if min_{i∈B∪{next}}(DDL_i - (t + S_b)) ≤ σ then
5       break ▷ 满足SLA
6     添加下一个短请求 (桶优先; 适应内存)
7   G⋆ ← NEARESTGRAPH(B, H, M) ▷ 最近的捕获形状
8   if G⋆ 存在 then
9     将 B 填充至 G⋆
10  else
11    使用标准 prefill 内核
12  调度 B; d ← depth(B); τ ← 达到 d 的时间
    if d ≥ D then
13    W ← clip(τ, [W_min, W_max])
14  else
15    D ← d

3.2 长短 Prefill 分离

设计理念。为了从根本上消除长短 prefill 请求之间的干扰，我们采用了一种类似于 PD 分离的设计理念，进一步分离长 prefill (LP) 和短 prefill (SP) 请求。与 PD 分离不同，LP/SP 分离中的两类任务是互斥的，调度目标的约束更少，为适应物理计算资源和工作负载特性的调度策略提供了更大的设计空间。LAPS 实现了两种互补的调度器：用于单实例 prefill 执行的时间分离调度器，以及用于多实例 prefill 协调的空间分离调度器。系统概览如图 4 所示。

图 4. 多轮 LLM 推理期间的资源利用率。长上下文请求在 prefill 期间使张量核心饱和（计算密集型），而短而频繁的请求和 re-prefill 阶段则是内存密集型的，HBM 使用率高——这说明了共享服务系统中计算密集型和内存密集型工作负载之间的干扰。

层级调度与对 CUDA Graph 的增益。LAPS 引入了一个层级调度层：在每个 prefill 实例内部使用时间分离调度器管理实例内优先级，同时一个空间分离调度器跨多个 prefill 实例协调实例间的资源分配。这种分离设计进一步放大了 CUDA Graph 对短 prefill 工作负载的益处。通过为长短请求维护独立的队列，LAPS 可以在请求到达时就确定是否应用 CUDA Graph 执行，从而减少批处理延迟和形状异构性，提高图的重用率和吞吐量。

互斥执行。Prefill 执行在实例级别按长度进行分离：每个实例专门执行一种类型的 prefill 任务，要么是短 prefill（内存密集型），要么是长 prefill（计算密集型）。所有请求首先根据 prompt 长度 $L_p$ 和边界点 $L_m$ 进行分类，并分别进入独立的短请求队列 $Q_s$ 和长请求队列 $Q_l$。

两种调度模式。
(a) SLA 约束模式: 每个请求 $i$ 都有一个绝对的截止日期 $DDL_i$。调度器在每个决策时刻 $t$ 计算两个候选等待窗口并选择更严格的一个：

$$W(t)=\operatorname{clip}\left(\min \left\{W_{\mathrm{SLA}}(t), W_{\mathrm{GR}}(t)\right\},\left[W_{\min }, W_{\max }\right]\right).$$

其中，SLA 窗口 $W_{SLA}(t)$ 是在任何待处理的短 prefill 请求违约前的最后安全等待时间：

$$W_{\mathrm{SLA}}(t)=\max \left\{0, \min _{i \in \mathcal{Q}_{s}(t)}\left(\mathrm{DDL}_{i}-t-\widehat{S}\right)-\delta\right\}$$

而 Graph 窗口 $W_{GR}(t)$ 是在估计的短请求到达速率 $\hat{r}_s$ 下，达到与最近捕获的 CUDA Graph 形状对齐的目标批处理深度 $D$ 的预期时间：

$$W_{\mathrm{GR}}(t) \approx \frac{\max \{0, D-\operatorname{depth}(B)\}}{\max \left\{\hat{r}_s, \varepsilon\right\}}$$

当 SLA 压力较大时，等待窗口会缩短；压力较小时，调度器可能等待更长时间以聚合更大的批次。

(b) 无截止日期模式: 对于如数据集蒸馏等离线任务，策略简化为在可行性约束下的 token 最大化。调度器形成大的、形状相似的短 prefill 批次以填充最近的 CUDA Graph 桶，而长 prefill 则以大的固定大小块 $C_l$ 调度单个请求，以保持高计算强度和最大化吞吐量。

单实例的时间分离模式。LAPS 采用时间分离模式，每个 GPU 实例专门用于短 prefill 或长 prefill 执行。系统维护两个全局队列 $Q_s$ 和 $Q_l$，每个实例只从自己的队列中拉取任务。这种按类别独占执行的方式避免了长短请求干扰，并确保了两种模式下 prefill 延迟的稳定性。

多实例的空间分离模式。在多实例设置中，LAPS 使用一个控制器（见算法 2）来动态平衡 $N$ 个 GPU 实例间的短 prefill 和长 prefill 工作负载。系统维护两个独立的实例池：$n_s$ 个短 prefill 实例和 $n_l = N - n_s$ 个长 prefill 实例。控制器在每个控制间隔监控每个实例的队列积压、SLA 偏差和 GPU 利用率来估计其负载压力，然后比较两个池的总体压力，并在不平衡超过阈值时迁移实例。这种简单的反馈控制稳定了 P99 延迟，防止了振荡，并保持了高 GPU 利用率。

算法 2 轻量级实例压力控制器
输入: 总数 N; 当前 (n_s, n_l); 控制周期 ∆t; 冷却时间 T_cool; 滞后 τ; 最小分配 n_min; 权重 (α, β, γ); 鲁棒聚合器 A(·)
16 t_last ← -∞
   while 服务器运行 do
17   sleep ∆t ▷ 收集两个池中每个实例的信号
18   foreach 实例 k in SHORT 池 do
19     测量 q_k, e_k, u_k; ψ_k ← α q_k + β e_k - γ u_k;
20   foreach 实例 k in LONG 池 do
21     测量 q_k, e_k, u_k; ψ_k ← α q_k + β e_k - γ u_k; ▷ 鲁棒的池压力 (P90)
22   P_s ← A({ψ_k : k ∈ SHORT})
     P_l ← A({ψ_k : k ∈ LONG})
     if now - t_last < T_cool then
23     continue
24   ▷ 带滞后和保障措施的单步爬山
25   if P_s > (1 + τ) P_l and n_l > n_min then
26     迁移一个实例: n_s ← n_s + 1; n_l ← n_l - 1; t_last ← now;
27   else if P_l > (1 + τ) P_s and n_s > n_min then
28     迁移一个实例: n_l ← n_l + 1; n_s ← n_s - 1; t_last ← now;

A4 实验环境

硬件配置：实验在单台 NVIDIA H200 GPU 以及一个包含 8 台 H200 的多 GPU 集群上进行。
软件配置：LAPS 基于 SGLang 实现，扩展了约 2000 行代码。
工作负载：
1. 在线任务：高并发、长短 prompt 混合的多轮对话。
2. 离线任务：对单个请求没有截止日期约束的完整数据集蒸馏。
数据集：使用 LMsys-Chat-1M【索引36, Lmsys-chat-1m: A large-scale real-world llm conversation dataset, 2024, https://arxiv.org/abs/2309.11998 】和 ShareGPT【索引35, Judging llm-as-a-judge with mt-bench and chatbot arena, 2023】数据集，它们包含大规模、真实世界的人机对话。
模型：评估中使用了 Qwen2.5-7B/14B/32B 模型。
评估指标：收集了 prefill 阶段的关键指标，包括首个 token 生成时间（TTFT）、P90 延迟、平均每秒请求数（RPS）和服务水平目标（SLO）违规率。
基线系统：将 LAPS 与 SGLang 和 vLLM 进行比较。这两个系统都是当前最先进的 LLM 服务系统，但它们在 prefill 阶段不支持 CUDA Graph，且其批处理策略仅依赖于可用内存容量。

A4 实验结果

性能对比（图 6）：
- 实验内容：在 ShareGPT-4 数据集上，比较 LAPS 与 SGLang（带 PD 分离）及其两个部分变体（仅启用 CUDA Graph 的 LAPS 和仅启用分离的 LAPS）的性能。测试了不同并发级别（1到64）和三种模型（Qwen2.5-7/14/32B），涵盖单实例（时间分离）和 8 实例（空间分离）设置。
- 实验结果：LAPS 在所有关键指标（RPS、平均延迟、P90 延迟）上均优于 SGLang 及其变体。在高并发下，LAPS 的优势更加明显。具体而言，在单 prefill 实例和 8 prefill 实例设置中，LAPS 的 RPS 分别比基线高出最多 20% 和 33%，同时平均延迟降低了 20%。
- 分析结论：单独启用 CUDA Graph 改进有限，甚至可能因开销导致性能下降。而分离机制能够动态调整等待窗口，形成更大的批次，从而放大了 CUDA Graph 的性能增益，使其调度和启动开销变得可以忽略不计。

图 6. LAPS 和 SGLang 在一个 H200 节点上的性能比较。上两行图对应时间分离设置（1个 prefill 实例），下两行图对应空间分离设置（8个 prefill 实例）。我们报告了四种配置下的 RPS、平均延迟和 P90 延迟：原生 SGLang PD 分离（蓝线）、LAPS（仅启用 CUDA Graphs，橙线）、LAPS（仅启用分离，绿线）和完整 LAPS（红线）。

SLO 违规率（图 7）：
- 实验内容：使用 LMsys-Chat-1M 数据集，假设请求到达遵循泊松过程，TTFT SLO 设为 0.4s。比较 LAPS、SGLang（PD 分离）、带路由器的 SGLang（PD 分离）和 vLLM（PD 分离）在不同客户端并发水平下的 SLO 违规率。
- 实验结果：
* 在单实例设置中，LAPS 的 SLO 违规率比带路由器的 SGLang 降低了约 10%，比原生 DP 的 SGLang 降低了约 30%。
* 在 8 实例空间分离设置下，LAPS 实现了零 SLO 违规，而带路由器的 SGLang 仍有 4.7% 的违规率。

分析结论：LAPS 的调度策略能更好地满足严格的延迟要求。

图 7. 在 LMsys-Chat-1M 数据集上，不同客户端并发水平下的 SLO 违规率。结果展示了 LAPS、SGLang（PD 分离）、SGLang（带路由器的 PD 分离）和 vLLM（PD 分离）在两种设置下的表现：（上）单实例（时间分离）和（下）8 实例（空间分离）。

离线蒸馏任务（表 2）：
- 实验内容：在每个请求没有严格截止日期的蒸馏任务中进行评估，此时等待窗口可以设置得相对较大。配置为 4 个 prefill 实例和 4 个 decode 实例，解码长度为 1K tokens。
- 实验结果：与 SGLang（原生 PD 分离）相比，LAPS 在处理两个对话数据集时，端到端耗时分别减少了 7.3% 和 8.3%。
- 分析结论：在吞吐量优先的离线任务中，LAPS 同样有效。

表 2. 采用 4 个 prefill 和 4 个 decode 实例的 PD 分离服务，在两个对话数据集上进行蒸馏的端到端时间。

与非 PD 分离设置的兼容性（图 8）：
- 实验内容：通过在不同并发级别下混合 prefill 和 decode 请求，评估 LAPS 在非 PD 分离设置下的兼容性。
- 实验结果：在混合解码条件下，prefill 请求的 RPS 下降。
- 分析结论：LAPS 只有在 PD 分离架构下才能充分利用 CUDA Graph 为短 prefill 请求带来的吞吐量优势。当与 decode 工作负载混合时，缺乏连续批处理会引入额外的批次间延迟，导致整体性能下降。

图 8. 在单实例和双实例设置下，不同并发级别中 PD 分离和混合解码模式的 prefill 吞吐量对比。

A7 补充细节

成本分析。在 LAPS 部署中，CUDA Graph 在初始化期间被捕获到内存中。每个图都绑定到固定的内核配置，无法适应动态的内核大小，因此必须捕获多个图以覆盖不同的 token 长度和批处理大小。每个 prefill 步骤都会引入查找和选择开销，因此图的数量必须受限，以平衡内存使用和性能。
* 内存成本：测量显示，对于 7B、14B 和 32B 模型，单个图的大小分别为 228MB、240MB 和 277MB，表明图的大小对模型规模不敏感。
* 启动开销：系统首次初始化时，需要逐层捕获内核和 KV-cache 操作，这会引入一定的启动开销。实验表明，捕获单个 prefill 图会产生大约 8-12 秒的初始化开销。

A5 结论

本文提出了 LAPS，一个基于 PD 分离范式、针对异构多轮对话工作负载进行优化的、感知 prefill 长度的 LLM 服务系统。通过分离长短 prefill 请求，LAPS 消除了 prefill 阶段的计算-内存干扰。其自适应调度器（AWD）和基于 CUDA Graph 的执行提高了批处理效率并降低了短 prefill 延迟。LAPS 支持时间和空间两种分离模式，可扩展到单 prefill 实例和多 prefill 实例部署。在真实世界数据集上的实验表明，与 SGLang 和 vLLM 等最先进的框架相比，LAPS 在高并发下实现了更高的吞吐量和更低的延迟，证明了其有效性。