AlignedServe: Orchestrating Prefix-Aware Batching to Build a High-Throughput and Computing-Efficient LLM Serving System

发表时间: 2026-06 · arXiv:2605.23389 (SIGMOD 2026)

原文: https://arxiv.org/abs/2605.23389

作者/机构：Fengyao Bai, Hongbin Zhang, Zhitao Chen, Jiangsu Du, Zhiguang Chen, Yutong Lu / 中山大学 (Sun Yat-Sen University, China)

速读

一句话结论 本文提出了 AlignedServe 推理系统，通过将前缀长度相近的请求打包并结合 CPU 内存缓冲与 GPU 间 NVLink 预取技术，消除了大模型解码阶段的迭代内等待气泡，在主流基准测试中实现了最高 1.98 倍的吞吐量提升和 7.4 倍的延迟降低。

要解决什么问题 现有的大模型推理系统在解码（Decode）阶段存在严重的“迭代内气泡”问题。在自回归生成中，生成一个新 token 的计算开销由多层感知机（MLP）和注意力机制（MHA）组成。其中 MLP 的开销对所有 token 是一致的，但 MHA 的开销与该 token 依赖的前缀（即历史 KVCache）长度成正比。现有的连续批处理策略（如 Orca）只关注在请求完成时填补空位以维持批次大小，却忽略了同一批次内各个请求的前缀长度差异。当一个批次中同时包含短前缀和长前缀请求时，短前缀 token 会迅速计算完毕，随后必须在原地等待长前缀 token 计算完成，才能共同进入下一次迭代。这种木桶效应导致了极大的算力浪费，实验表明，在一个大小为 64 的批次中仅混入 4 个长请求，就会让单次迭代的延迟飙升 61%。尽管业界已经通过分离预填充与解码阶段来优化整体架构，但在最细粒度的单次迭代层面，因前缀长度不一导致的算力闲置依然是制约吞吐量的核心卡点。

怎么做的 核心思路是将前缀（即已积累的 KVCache）长度相近的请求划分到同一个批次中，确保同一迭代内所有 token 的生成开销基本一致，从而绕开迭代内气泡这一卡点。生成单个 token 的核心计算量由注意力机制决定：

$$Attention(q, K, V) = softmax \left( \frac { q K ^ { T } } { \sqrt { d _ { k } } } \right) V$$

其计算和访存复杂度约为 $2sh$（$s$ 为前缀长度，$h$ 为隐藏层维度），而后续 MLP 层的复杂度为固定的 $8h^2$。当 $s$ 极大时，注意力机制的开销将占据主导。为了实现这一思路，系统设计了三个关键部件。首先是基于大容量 CPU 内存的 KV 池，由于前缀长度分布极广，必须维持海量的运行中请求才能凑出长度相近的批次，因此系统将预填充阶段生成的 KVCache 卸载到最高可达数 TB 的 CPU 内存中作为候选。其次是前缀感知批处理策略，系统在内存中维护了一棵四叉树，叶子节点存储请求，内部节点记录该区间内的请求数和显存占用量。通过密度优先搜索算法，自顶向下寻找既能装入 GPU 显存、又满足最小批次大小限制的请求集合；若当前子树请求太少，则向上回溯并向兄弟节点借用请求，确保前缀长度分布最集中。最后是 GPU 间预取架构与批次级调度，为了掩盖从 CPU 内存向解码 GPU 传输 KVCache 的 PCIe 带宽瓶颈，系统创新性地让预填充 GPU 充当缓冲，提前将组装好的批次预取到预填充 GPU 的显存中。在解码 GPU 显存耗尽需要驱逐最长请求，或有请求完成需要补充新请求时，直接通过高带宽的 NVLink 将 KVCache 注入解码 GPU，极大地降低了调度延迟。

效果如何 实验在配备 8 张 H100 GPU（支持 NVLink）的服务器上进行，评估了 OPT 系列模型（2.7B 到 30B 规模）。对比基线包括三个代表性系统：vLLM（代表主流的连续批处理与先到先得调度路线）、DistServe（代表预填充与解码分离架构路线）以及 FastGen（代表高吞吐文本生成路线）。在包含真实生产环境请求长度分布的 AzurePublicDataset 数据集上，AlignedServe 展现了最强的性能，其解码吞吐量最高达到了基线方法的 1.98 倍，同时将 P99 每次输出 token 延迟最多降低了 7.4 倍。在合成负载测试中，当短请求占比达到 95% 时，吞吐量依然比 FastGen 高出 1.85 倍。消融实验证明，若关闭 GPU 预取机制，吞吐量会下降 14.73%。代价方面，由于请求需要先在 CPU 内存池中等待匹配相近长度的同伴，首个 token 延迟（TTFT）会有所增加，在 ShareGPT 和 LongBench 上的平均 TTFT 分别为 1.49 秒和 2.54 秒；在极端情况下若关闭防饥饿机制，最大等待时间可能达到 30 秒。此外，该架构需要占用 20GB 到 250GB 的额外 CPU 内存来维持 KV 池，且在两个批次交替切换的短暂过渡期内，仍会不可避免地出现少量长度不一致的混合迭代。

主要贡献

大型语言模型（LLMs）的推理分为预填充（Prefill）和解码（Decode）两个阶段。预填充阶段计算密集且对GPU友好，而解码阶段由于需要大量KVCache来计算注意力机制，通常受限于内存带宽。现有的最先进推理框架（如Orca、Sarathi-Serve等）主要通过将多个请求打包成批次（Batch）并在GPU间调度来提高计算效率。然而，这些研究大多集中在粗粒度的请求级或批次级优化，忽略了每次解码迭代（Iteration）内部存在的细粒度气泡（Bubbles）。

由于同一迭代中生成的Token所依赖的KVCache（即前缀，Prefix）长度不同，计算注意力机制的成本也不同。依赖极长KVCache的Token往往会成为该迭代的性能瓶颈，导致其他生成较快（前缀较短）的Token必须长时间等待，从而产生迭代级气泡，严重降低系统吞吐量。

本文的主要贡献如下：
1. 深入剖析迭代级气泡：通过理论分析和基于真实Trace的实验，首次指出同一迭代中生成的Token因前缀长度不同而具有不同的计算成本，这种差异引入的迭代级气泡会显著降低整体性能。
2. 提出前缀感知批处理策略：设计了一种新颖的批处理策略，旨在将依赖相似长度KVCache的推理请求分组到同一个批次中，确保每次迭代中生成的所有Token具有相同的计算成本，从而消除迭代内的气泡。
3. 设计AlignedServe推理框架与批次级调度策略：为高效支持前缀感知批处理，解耦了预填充和解码阶段，利用大容量CPU内存来容纳海量运行中（in-flight）的请求以备批处理。在CPU内存中生成的批次由精心设计的批次级调度策略调度，显著减少批次级气泡。进一步提出“GPU为GPU预取（GPU-Prefetch-For-GPU）”架构，利用预填充GPU提前通过高带宽NVLink将KVCache预取并传输给解码GPU，大幅降低PCIe传输延迟。
4. 显著的性能提升：在合成工作负载和实际应用工作负载上的广泛实验表明，与最先进的系统（如vLLM、DistServe、DeepSpeed-FastGen）相比，AlignedServe最大可将解码吞吐量提高 $1.98\times$，并将延迟降低高达 $7.4\times$。

背景知识与设计动机

LLM推理过程概述：当前主流的LLM（如GPT、Llama、OPT等）大多采用仅解码器（Decoder-only）的Transformer架构，并使用自回归方法生成Token。推理过程分为预填充和解码两个阶段。对于给定的推理请求，预填充阶段接收完整的输入提示词并并行计算所有Token以生成第一个输出Token，该阶段具有内在并行性，计算效率高且开销相对较低（在小批次下仅为解码开销的 $1/200$）。预填充后进入解码阶段，逐个生成后续Token直至推理完成。根据自回归模型，生成给定Token依赖于之前生成的所有Token。为了避免重复计算，系统会将表征Token的键（Key）和值（Value）向量保留在内存中，即KVCache。与预填充相比，解码阶段并行度差（逐个生成）且受限于内存带宽，难以使GPU计算力饱和，因此解码阶段构成了LLM推理的主要开销。

解码过程的深入分析：典型的Transformer模型包含多个相同的层，每层分为多头注意力（MHA）块和多层感知机（MLP）块。定义参数 $b$ 为批次大小， $s$ 为推理序列长度， $h$ 为隐藏层维度。对于要生成的新Token $x_{n+1}$，假设其前缀为 $X = x_1, ..., x_n$。系统不保存 $X$，而是将 $K = k_1, ..., k_n$ 和 $V = v_1, ..., v_n$ 保留在内存中，其中 $k_i$ 和 $v_i$ 通过公式1计算：

$$q_i = W_q x_i, \ k_i = W_k x_i, \ v_i = W_v x_i$$


生成 $x_{n+1}$ 需要根据公式2计算注意力，其核心是 $h \times [h, s]$ 和 $s \times [s, h]$ 的向量-矩阵乘法，计算操作数和内存访问量均约为 $2sh$。

$$Attention(q, K, V) = softmax\left(\frac{qK^T}{\sqrt{d_k}}\right)V$$
计算注意力后，向量输入到由两个全连接层组成的MLP中（如公式3所示）， $W_1$ 和 $W_2$ 的形状分别为 $[h, 4h]$ 和 $[4h, h]$，计算操作数和内存访问量均约为 $8h^2$。
$$x = f_{GeLU}(x_{out}W_1)W_2 + x_{out}$$

表1总结了生成单个Token的计算和内存开销。

Component Computational Overhead Memory Overhead
MHA $2sh$ $2sh$
MLP $8h^2$ $8h^2$

MLP的开销在计算和内存上远高于MHA，但在大批次下，由于权重矩阵 $W_1$ 和 $W_2$ 被所有Token共享，从HBM加载的开销被分摊，MLP性能显著提升。相反，MHA由于主要受KVCache影响，其开销随批次大小线性增加，且随着序列变长，MHA开销逐渐增加而MLP保持不变。因此，当生成的Token依赖长前缀时，MHA占据了总开销的很大一部分。如果依赖长前缀和短前缀的两个Token在同一批次的同一迭代中生成，高开销的长前缀Token将成为瓶颈，显著降低整体性能。

长前缀Token的瓶颈效应：为了证明长前缀Token会成为每次迭代的瓶颈，设计了将不同长度的提示词分组到一个批次中并评估每次迭代延迟的实验。以批次大小64为例，基线是包含64个短提示词（每个32个Token）的批次；对比组分别为63短+1长、62短+2长、60短+4长（长提示词包含4096个Token）。实验在部署于H100 GPU上的vLLM运行Llama-7b模型。随着解码生成的Token越来越多，每次迭代的延迟逐渐增加，这证明长前缀确实对解码延迟产生重大影响。此外，即使批次中仅包含极少数长提示词，整体性能也会显著下降。例如在生成Token长度为600时，基线延迟为 $13.49ms$，而混合4个长提示词的批次延迟达到 $21.73ms$，仅4个长提示词就使迭代延迟增加了约 $61\%$。由于输入提示词长度不同以及每个请求生成的Token数量不同，同一迭代中生成的Token依赖不同长度的前缀是普遍现象。分析AzurePublicDataset、Openchat_ShareGPT4和Summarization数据集发现，长前缀占比极高（如代码生成中超4000个Token的前缀占 $15.06\%$，GPT4和摘要任务中甚至高达 $40\%$）。

不同长度前缀在每次迭代中引入的负面影响
前缀长度的累积分布函数(CDF)

前缀感知批处理的探索：为验证将前缀长度相似的推理请求分组到一个批次中的有效性，设计了考虑与不考虑前缀长度的批处理策略对比实验。准备了64组推理提示词，每组内部长度相同，组间长度从10到3790递增。第一种策略（前缀感知）将每组作为一个批次依次运行，其所有批次的平均TPOT（每个输出Token时间）约为 $200ms$。第二种策略（无前缀感知）从每组抽取一个提示词组成64个长度完全不同的批次，其平均TPOT约为 $233.43ms$。前缀感知批处理保证了给定迭代中生成的所有Token具有相同的成本，它们同时生成并一起进入下一次迭代；而对应策略中，依赖长前缀的Token成为瓶颈，阻碍了已生成完毕的短前缀Token进入下一次迭代，导致GPU资源利用率不足。

考虑与不考虑前缀长度的批处理策略对比
考虑与不考虑前缀长度的批处理策略对比

方法细节

设计理念与面临的挑战：将具有相同前缀长度的推理请求分组到一个批次中并非易事。首先，服务系统必须维护大量的运行中请求，以确保能够选择出足够多前缀长度相似的请求。由于前缀长度分布范围极广（从几十到上万），除非有海量请求等待调度，否则很难凑齐一个理想的批次，这给GPU有限的HBM带来了极高的内存开销挑战。其次，前缀感知批处理策略必须动态适应工作负载，不能像传统策略那样简单地凑够固定数量就生成批次。策略需要动态调整滑动窗口，并在请求完成离开时仔细选择合适的候选请求加入。最后，系统必须配备精心设计的调度器，在吞吐量、延迟、资源利用率和公平性之间取得平衡，避免等待匹配的请求经历过长延迟甚至被饿死。

系统整体架构：为了克服内存容量挑战，提出了一种可扩展的架构，该架构由KV池（KV pool）、预填充实例（Prefill instances）和解码实例（Decoding instances）三个组件构成。KV池驻留在主机内存（CPU内存）中，用于保存从GPU卸载的KVCache，其数TB的容量足以容纳数百万个Token，确保有充足的请求等待批处理。解码实例负责接收调度的批次并生成新Token，可采用数据并行、张量并行等任意并行策略。预填充实例除了处理输入提示词外，还作为解码实例与主机内存之间KVCache交换的中间缓冲区。当批次被调度时，系统并非通过带宽有限的PCIe直接将KVCache传输给解码实例，而是先将批次从主机内存预取到预填充实例的HBM中，然后通过高带宽的NVLink转发给解码实例。当请求到达时，首先由预填充实例处理（步骤1），生成的KVCache被传送到KV池（步骤2）。批次生成器从KV池中选择合适的请求生成批次（步骤3）。计划运行的批次被异步预取到预填充实例的候选批次缓冲区中（步骤4），等待通过NVLink转发给解码实例（步骤5）。调度器在运行时监控解码实例，当HBM耗尽时，会将请求驱逐到预填充实例的候选请求缓冲区（步骤6）；当运行批次过小无法饱和GPU时，会将请求从缓冲区传递给解码实例（步骤5）。

AlignedServe整体架构图
AlignedServe整体架构图

前缀感知批处理策略：传统批次生成器通常根据先到先得（FCFS）原则生成批次。为了确保同一批次中的请求具有相似的前缀长度，系统维护了一个四叉树（Quad-tree）来容纳所有运行中的请求，并提出了一种基于该树的密度优先搜索（Density First Search）策略。四叉树包含内部节点和叶节点，内部节点负责一个前缀长度范围并将其等分为四个子范围给子节点，每个内部节点维护一个元组（请求计数器，块计数器）来表征其子树。为了生成批次，密度优先搜索策略从根节点开始自顶向下搜索，遇到内部节点时考虑三种情况：情况1（成功生成批次），如果子树中请求占据的内存块总数不超过给定阈值（例如小于GPU HBM容量），则将这些请求成功分组为一个批次；情况2（进一步自顶向下搜索），如果内存块总数超过阈值，说明HBM无法容纳，此时选择请求计数器最大的子节点（请求密度最高）继续向下搜索，以缩小搜索范围；情况3（进一步自底向上搜索），如果内存块未超阈值但请求总数太少（如小于128），不足以饱和GPU计算力，则返回父节点，通过搜索左兄弟或右兄弟节点来扩大搜索范围。该算法通过$L$-Search和$R$-Search函数控制扫描方向，确保生成的批次请求落在尽可能小的范围内。

密度优先搜索(Density First Search)图示
密度优先搜索(Density First Search)图示
def recursive_dfs(node, Bmax, Kmin):
    B = collect_requests(node)
    Bused = sum(r.blocks for r in B)
    if Bused <= Bmax and len(B) >= Kmin:
        return B
    elif Bused > Bmax:
        cmax = find_max_density_child(node)
        return recursive_dfs(cmax, Bmax, Kmin)
    else:
        Bleft = Bmax - Bused
        Kleft = Kmin - len(B)
        if node.left_sibling != 0:
            addition = r_search(node.left_siblings, Bleft, Kleft)
        else:
            addition = l_search(node.right_siblings, Bleft, Kleft)
        Bfinal = B + addition[0 : min(Kleft, len(addition))]
        return Bfinal

def r_search(siblings, Bleft, Kleft):
    selected = []
    for s in reversed(siblings): # from right to left
        requests = collect_requests(s)
        for r in requests:
            if r.blocks + sum(req.blocks for req in selected) <= Bleft:
                selected.append(r)
            else:
                return selected
    return selected

def l_search(siblings, Bleft, Kleft):
    selected = []
    for s in siblings: # from left to right
        requests = collect_requests(s)
        for r in requests:
            if r.blocks + sum(req.blocks for req in selected) <= Bleft:
                selected.append(r)
            else:
                return selected
    return selected

批次级调度策略：与传统连续批处理（Continuous Batching）在请求完成后立即加入任意新请求的请求级调度不同，本文提出了批次级调度策略，逐批次调度到达的请求。为了支持该策略，在预填充实例准备了候选批次缓冲区（Candidate Batch Buffer，保存下一个待调度的批次）和候选请求缓冲区（Candidate Requests Buffer，保存属于当前运行批次但未调度的请求）。未调度的请求来源于两处：一是运行批次前缀逐渐变长时，KV池中偶然出现前缀长度相似的请求被动态预取进来；二是因HBM耗尽而被驱逐出解码实例的请求。当运行批次完成一次迭代时触发调度，需考虑三种情况：情况1（从候选请求缓冲区调度），当有请求完成释放了HBM空间，优先从候选请求缓冲区选择请求加入运行批次，这符合服务相似前缀长度请求的核心理念；情况2（从候选批次缓冲区调度），当候选请求缓冲区为空时，从候选批次缓冲区选择请求加入，此时运行批次包含来自两个不同原始批次的请求，系统行为退化为传统的连续批处理，这是批次切换的时刻；情况3（将请求驱逐到候选请求缓冲区），当HBM空间不足以进行下一次迭代时，如果在情况1下（请求前缀相似），则选择最长的请求作为受害者驱逐，如果在情况2下（批次切换中），则选择旧批次中最长的请求驱逐，以加速批次切换。所有调度引起的KVCache传输均通过NVLink在GPU间直接进行，显著降低了调度延迟。

批次级调度策略图示：(a)从候选请求缓冲区调度 (b)从候选批次缓冲区调度
批次级调度策略图示：(a)从候选请求缓冲区调度 (b)从候选批次缓冲区调度
completed_reqs = get_completed_requests(Brun)
release_hbm(completed_reqs)
remove_from_batch(Brun, completed_reqs)

if not has_sufficient_hbm_for_next_iteration():
    if is_batch_switching(Brun):
        victim = select_victim_from_old_batch(Brun)
    else:
        victim = select_victim_longest(Brun)
    evict_to_buffer(Brun, victim, Rcand)
else:
    if Rcand:
        new_reqs = select_requests_from(Rcand)
        add_to_batch(Brun, new_reqs)
    elif Bcand:
        new_reqs = select_requests_from(Bcand)
        add_to_batch(Brun, new_reqs)

实现细节：在实现中需要考虑以下关键细节。首先是饥饿问题，如果四叉树某子树中请求不足，可能长时间无法生成批次导致饿死。系统为每个内部节点设置时间戳，超过阈值则提升优先级，该阈值可根据服务级别目标（SLOs）动态调整。其次是动态调度，静态生成的批次在运行时，如果KV池中出现与运行批次前缀长度相似的请求，调度器会将其动态预取到候选请求缓冲区等待加入，这也有助于避免饥饿。最后是原型实现，AlignedServe基于最先进的解耦架构DistServe开发，改进了其FCFS调度策略。预填充后的请求不直接进入解码，而是存入KV池进行前缀感知批处理。虽然这引入了额外的批处理延迟，但显著提高了吞吐量，且由于前缀长度分布极广，在预填充实例有限的HBM中直接匹配是不现实的。

实验环境

  • 硬件配置：服务器配备2颗Intel(R) Xeon(R) Platinum 8462Y+ CPU，8张通过NVLink连接的NVIDIA H100 GPU，800GB DRAM。CPU与GPU通过PCIe 5.0连接。
  • 模型架构：采用OPT系列模型，包括OPT-2.7B、OPT-6.7B、OPT-13B和OPT-30B，所有实验均使用FP16精度。

  • 数据集：

    • 合成工作负载：构建了包含不同长短请求比例的数据集（短请求<1000 Tokens，长请求1000-8000 Tokens）。
    • 应用工作负载：ShareGPT（多轮对话交互）、LongBench（长上下文理解）、AzurePublicDataset（真实生产环境推理Trace）。

  • 对比基线（软件配置）：vLLM（集成SarathiServe和Orca技术）、DistServe（预填充/解码解耦架构）、DeepSpeed-FastGen（高吞吐量系统）。

实验结果

解码吞吐量：在合成工作负载（短请求比例分别为 $70\%$ 到 $95\%$）下，AlignedServe在所有负载下均持续优于其他系统。特别是在短请求占 $95\%$（长请求占 $5\%$）时，AlignedServe在OPT-2.7b模型上分别超越vLLM、DistServe和FastGen $1.32\times$、 $1.35\times$ 和 $1.85\times$（详见Fig 7）。在应用工作负载下，AlignedServe在LongBench、ShareGPT和AzurePublicDataset上分别比其他系统最大提升了 $1.98\times$、 $1.35\times$ 和 $1.98\times$ 的吞吐量（详见Fig 8）。对于AzurePublicDataset这种前缀长度跨度极大（3到7437）的场景，AlignedServe能有效处理长请求带来的负面影响。

合成工作负载下的解码吞吐量(tokens/s)
实际应用工作负载下的解码吞吐量

解码延迟：通过评估P99 TPOT（每个输出Token时间）来衡量每次解码迭代的延迟。在合成工作负载下，AlignedServe一致实现了比基线系统低 $1.74\times - 3.05\times$ 的延迟（详见Fig 9）。在应用工作负载下，AlignedServe在LongBench、ShareGPT和AzurePublicDataset上分别最大降低了 $2.1\times$、 $1.65\times$ 和 $7.4\times$ 的P99 TPOT延迟（详见Fig 10）。单次迭代延迟的降低直接解释了吞吐量的提升。

合成工作负载下的P99 TPOT延迟
实际应用工作负载下的P99 TPOT延迟

消融实验与开销分析：
- 迭代调度开销：比较AlignedServe和DistServe调度迭代的时间。AlignedServe中超过 $95\%$ 的迭代在 $5ms$ 内完成调度，而DistServe有 $80\%$ 的迭代耗时超过 $10ms$（详见Fig 11）。新批次生成时间由于采用了流水线机制（在解码当前批次时生成并预取下一批次）被有效隐藏。
- 前向计算延迟：在长请求占比 $95\%$ 且长请求长度从2000递增到10000的合成负载下，基线系统（尤其是DistServe）的延迟显著增加，而AlignedServe仅轻微增加，证明其有效消除了迭代级气泡（详见Fig 12）。将框架内的前缀感知策略替换为FCFS后，前缀感知策略有超 $90\%$ 的迭代在 $30ms$ 内完成前向计算，而FCFS策略低于 $10\%$（详见Fig 13）。
- GPU预取与批处理消融：在AzureDataset上，禁用GPU预取会导致吞吐量下降 $14.73\%$，同时禁用预取和前缀感知批处理则下降 $28.51\%$（详见Fig 14）。
- 批次切换与KV池开销：批次切换时违反设计理念的迭代比例在ShareGPT和LongBench上分别不超过 $8.61\%$ 和 $12.37\%$。800GB的KV池在LongBench实际消耗仅在20GB到250GB之间。
- TTFT（首个Token生成时间）：禁用饥饿处理机制时，ShareGPT和LongBench的平均TTFT分别为1.49秒和2.54秒，在生产环境中可接受。恢复饥饿处理机制后可按需调整TTFT（详见Fig 15）。

迭代调度的开销对比
合成工作负载下每次迭代前向计算延迟的对比
前缀感知批处理与FCFS在前向计算延迟方面的对比
GPU预取和前缀感知批处理的消融实验
首个Token生成时间(TTFT)的CDF

补充细节

相关工作：
- 解耦架构：许多推理框架采用了将预填充（计算密集型）和解码（内存密集型）阶段解耦的架构，如Splitwise 【25，Splitwise: Efficient generative llm inference using phase splitting + 2024 + ISCA】、DistServe 【40，DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving + 2024】和Mooncake 【26，Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM Chatbot + 2025 + FAST】。这允许独立优化硬件分配，避免阶段干扰。
- 批处理和调度优化：Orca 【37，Orca: A Distributed Serving System for Transformer-Based Generative Models + 2022 + OSDI】首次明确考虑了输入输出长度的变化，将调度从请求级细化到迭代级（连续批处理）。Sarathi-Serve 【2，Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve + 2024 + OSDI】将输入提示词划分为固定大小的块并与解码混合。这些现有系统均与AlignedServe的优化方向正交。
- KVCache管理：PagedAttention 【17，Efficient memory management for large language model serving with pagedattention + 2023 + SOSP】引入了操作系统中的分页概念来非连续分配KVCache。FlexGen 【28，FlexGen: high-throughput generative inference of large language models with a single GPU + 2023 + ICML】等探索了将冷KV卸载到DRAM或SSD。长上下文推理促使了对共享前缀的KVCache管理研究，这些工作生成的不同长度前缀可以进一步输入到AlignedServe中以实现高吞吐量。

结论

传统的LLM服务系统大多忽略了推理请求长度不同的事实，将不同长度的请求分组到一个批次中会导致严重的迭代级气泡。本文提出了一种名为AlignedServe的新型LLM服务框架，它采用了前缀感知批处理策略，将前缀长度相似的请求分组到同一个批次中，从而显著消除了迭代级气泡。为了高效支持该策略，进一步设计了新颖的解耦架构以及相应的批次级调度策略，以减少调度开销。由各种工作负载驱动的实验证明，与最先进的系统相比，AlignedServe实现了更高的性能（高吞吐量）和更低的调度开销（计算高效）。未来的工作可以结合共享前缀的KVCache管理，进一步提升长上下文场景下的推理效率。