1. 论文基本信息

1.1. 标题

EcoServe: Enabling Cost-effective LLM Serving with Proactive Intra- and Inter-Instance Orchestration （EcoServe：通过主动的实例内和实例间编排实现经济高效的LLM服务）

1.2. 作者

• Jiangsu Du (杜江苏), Hongbin Zhang (张宏彬), Taosheng Wei (韦涛盛), Zhenyi Zheng (郑真毅), Kaiyi Wu (吴开义), Zhiguang Chen (陈志光), Yutong Lu (卢宇彤)
• 所属机构: 中山大学 (Sun Yat-sen University), 广州, 中国。

1.3. 发表期刊/会议

该论文尚未在正式期刊或会议上发表。目前以预印本 (preprint) 形式发布在 arXiv 上。arXiv 是一个开放获取的预印本数据库，在计算机科学（尤其是机器学习和系统领域）具有广泛的影响力，许多重要研究成果在此发布以供早期审阅和传播。

1.4. 发表年份

2025年

1.5. 摘要

当前的大型语言模型 (LLM) 服务策略主要分为非解耦 (NoDG) 和完全解耦 (FuDG) 两种，取决于预填充 (prefill) 和解码 (decode) 阶段是否分离。然而，NoDG 策略导致严重的预填充-解码干扰，而 FuDG 策略则高度依赖高性能互连（例如 InfiniBand），这使得它们在成本效益方面表现不佳。

本文介绍了 EcoServe，一个旨在通过商品化互连 (commodity interconnects) 在集群上实现经济高效的 LLM 服务的系统。EcoServe 建立在部分解耦 (PaDG) 策略之上，该策略应用时间解耦 (temporal disaggregation) 和滚动激活 (rolling activation) 进行主动的实例内和实例间调度。它首先在单个实例内沿时间维度解耦预填充和解码阶段，以减轻阶段间干扰并提高吞吐量 (throughput)。其次，它协调多个实例并周期性地激活它们，以确保预填充处理的持续可用性，从而改善延迟 (latency)。因此，EcoServe 的基本服务单元是一个宏实例 (macro instance)，其中多个实例协同工作。它进一步集成了自适应调度算法 (adaptive scheduling algorithm) 用于在宏实例中路由请求，以及分裂扩容方法 (mitosis scaling approach) 以实现细粒度容量扩展。与现有解决方案相比，EcoServe 除了提供高吞吐量 (goodput) 外，还在负载均衡 (load balancing)、硬件成本、并行兼容性甚至工程复杂度方面表现出色。

在配备32块 NVIDIA L20 GPU 和商品化以太网 (commodity Ethernet) 的生产级集群上服务 30B 和 70B 规模模型时，EcoServe 相较于四种代表性的 NoDG 和 FuDG 系统，平均吞吐量分别提高了 82.49%、86.17%、122.76% 和 126.96%。

1.6. 原文链接

• 原文链接: https://arxiv.org/abs/2504.18154v1
• PDF 链接: https://arxiv.org/pdf/2504.18154v1.pdf
• 发布状态: 预印本 (preprint)

2. 整体概括

2.1. 研究背景与动机

随着大型语言模型 (LLM) 在各种任务中的广泛应用，如何以最低的成本提供 LLM 服务并同时满足服务水平目标 (SLO) 成为一个核心挑战。LLM 推理过程包含两个截然不同的阶段：预填充 (prefill) 阶段和解码 (decode) 阶段。这两个阶段各有其性能指标：预填充阶段关注首令牌时间 (Time to First Token, TTFT)，解码阶段关注每输出令牌时间 (Time Per Output Token, TPOT)。TTFT、TPOT 和吞吐量 (throughput) 之间存在固有的性能权衡：提升其中一个往往会牺牲其他。

现有集群级 LLM 服务方案主要分为两大类：

1. 非解耦策略 (Non-Disaggregated, NoDG)：预填充和解码阶段在同一个实例中执行。

2. 完全解耦策略 (Fully Disaggregated, FuDG)：预填充和解码阶段分配给不同的实例。

   然而，这两种现有策略都存在显著局限性，阻碍了 LLM 服务的成本效益：

• NoDG 策略的局限性：由于预填充和解码阶段在同一实例中，它们之间会产生严重的干扰。例如，过度优先处理预填充会延长解码延迟，影响 TPOT；反之亦然。这种干扰还会导致 GPU 资源利用率不足，因为解码阶段难以积累足够大的批次规模来饱和 GPU，从而降低吞吐量。此外，NoDG 策略难以有效利用流水线并行 (pipeline parallelism)，因为微批次工作负载的不平衡和数据依赖性会导致严重的流水线气泡 (pipeline bubbles)。

• FuDG 策略的局限性：虽然 FuDG 策略通过将预填充和解码分离到不同实例来完全消除阶段间干扰，但它需要频繁地在预填充和解码实例之间传输大量的 KV 缓存 (KV cache) 数据。这要求使用高性能互连（如 NVLink 或 InfiniBand），而这些互连不仅成本高昂，而且能耗巨大。同时，FuDG 策略还面临负载不平衡的挑战，尤其是在调整预填充和解码实例的比例时，以及在节点内存利用率上的不平衡（解码实例存储大量 KV 缓存而预填充实例存储较少）。

  本文的切入点或创新思路：作者观察到，为了提升性能权衡的上限并充分利用资源，必须协调实例内调度（决定何时执行预填充和解码）与实例间调度（决定何时何地路由请求）。为此，EcoServe 提出了部分解耦策略 (Partially Disaggregated, PaDG)，通过时间解耦和滚动激活实现主动的实例内和实例间调度，从而在商品化互连集群上实现经济高效的 LLM 服务。

2.2. 核心贡献/主要发现

EcoServe 的核心贡献和主要发现包括：

1. 提出了 EcoServe 系统：一个旨在通过商品化互连实现经济高效的 LLM 服务的系统。
2. 引入了部分解耦 (PaDG) 策略：这是 EcoServe 的基石，通过时间解耦 (temporal disaggregation) 在单个实例内沿时间维度分离预填充和解码阶段，以及通过滚动激活 (rolling activation) 在多个实例间协调预填充处理的持续可用性。该策略结合了 NoDG 的局部性优点和 FuDG 的阶段隔离优点，同时避免了两者的高昂成本。
3. 设计了自适应调度算法 (adaptive scheduling algorithm)：用于在宏实例 (macro instance) 内路由请求，能够在满足 TTFT 和 TPOT SLO 的前提下，优化预填充令牌的插入数量。
4. 开发了分裂扩容方法 (mitosis scaling approach)：受生物细胞有丝分裂启发，该方法允许系统进行细粒度、弹性地容量调整，通过增减宏实例内的实例数量，并在达到阈值时进行宏实例的拆分或合并，以适应工作负载变化。为此，还引入了可序列化代理对象 (serializable proxy object) 实现灵活的实例迁移，避免服务中断。
5. 实现了分层架构：系统包含总体调度器 (overall scheduler)、宏实例调度器 (macro-instance scheduler) 和实例调度器 (instance scheduler) 三个层次，协同工作。
6. 全面的性能评估：在生产级集群上，使用 30B 和 70B 规模模型以及商品化以太网，EcoServe 在 P90 吞吐量方面相较于四种代表性的 NoDG 和 FuDG 系统，平均取得了显著的性能提升（82.49% 到 126.96% 不等）。
7. 多维度优势：EcoServe 在高吞吐量 (goodput) 的同时，还在负载均衡、硬件成本、并行兼容性（特别是流水线并行）和工程复杂度方面优于现有解决方案。

3. 预备知识与相关工作

3.1. 基础概念

为了理解 EcoServe 的设计和其所解决的问题，需要先了解大型语言模型 (LLM) 推理的一些基本概念和挑战。

3.1.1. LLM 推理阶段：预填充 (Prefill) 与解码 (Decode)

LLM 的推理过程，尤其是生成式任务，通常分为两个主要阶段，如图 2 所示：

• 预填充阶段 (Prefill Phase)：也称为编码阶段 (encoding phase) 或上下文处理阶段 (context processing phase)。在这个阶段，模型一次性处理用户的整个输入序列（或称为提示，prompt），生成所有输入令牌对应的 KV 缓存 (KV cache) 和第一个输出令牌。这个阶段通常涉及大量的矩阵乘法运算，计算量与输入序列长度的平方成正比，因此是计算密集型 (compute-bound) 的。

• 解码阶段 (Decode Phase)：也称为生成阶段 (generation phase)。在这个阶段，模型逐个生成输出令牌。每生成一个新令牌，都需要将当前已生成的所有令牌及其对应的 KV 缓存作为输入，然后预测下一个令牌。由于每次只生成一个令牌，计算量相对较小，但需要频繁访问和更新 KV 缓存，因此是内存带宽密集型 (memory-bound) 的。

  下图（原文 Figure 2）展示了 LLM 自回归解码过程：

  该图像是论文中的示意图，展示了LLM自回归解码过程，区分了预填充(prefill)和解码(decode)阶段，体现时间维度上的输入输出动态及关键缓存机制。

Figure 2. LLM autoregressive decoding process.

3.1.2. KV 缓存 (KV Cache)

在 Transformer 架构中，self-attention 机制需要计算查询 (Query, Q)、键 (Key, K) 和值 (Value, V) 矩阵。在自回归生成过程中，为了避免重复计算已经处理过的令牌的 K 和 V，这些矩阵会被存储在内存中，这就是 KV 缓存。KV 缓存的大小随着序列长度的增加而线性增长，成为 LLM 推理过程中一个主要的内存消耗因素。

3.1.3. 算术强度 (Arithmetic Intensity, AI)

算术强度是衡量计算效率的一个指标，定义为浮点运算次数 (FLOPS) 与内存访问量之比。 $$\text{Arithmetic Intensity (AI)} = \frac{\text{Floating-Point Operations (FLOPS)}}{\text{Memory Access (Bytes)}}$$

• 符号解释:

  • $\text{FLOPS}$: 每秒浮点运算次数，衡量计算吞吐量。

  • $\text{Memory Access}$: 内存读取和写入的数据总量，衡量内存带宽需求。

    高算术强度意味着计算可以在数据加载后进行大量处理，通常表示为计算密集型；低算术强度意味着需要频繁访问内存，通常表示为内存密集型。如论文表 2 所示，预填充阶段通常具有更高的算术强度（因为它依赖于序列长度 $S$ 和批次大小 $B$），而解码阶段的算术强度较低（主要依赖批次大小 $B$，并且需要加载 KV 缓存）。

3.1.4. 内存-计算权衡 (Memory-Compute Trade-off)

在 LLM 推理中，有限的内存容量会严重限制计算并行性。KV 缓存是除了模型权重之外主要的内存消耗来源。解码阶段通常受限于内存带宽，需要同时处理数百个请求才能饱和 GPU，这导致了大量的内存使用。例如，Llama-30B 模型单个令牌的 KV 缓存需要 1.52 MB，这意味着 128 个请求平均输出长度为 300 令牌，将需要大约 58.4 GB 的内存，这与模型权重的内存占用量相当。此外，LLM 生成任务涉及变长序列，输出长度不确定，这要求预留大量内存以防止内存溢出 (OOM)，进一步复杂了资源分配。

3.1.5. 批处理技术 (Batching Techniques)

为了充分利用现代 GPU 的并行计算能力，批处理 (batching) 是处理深度学习工作负载的常用技术。

• 连续批处理 (Continuous Batching)：动态地在每个迭代中允许请求进入或退出批次，以适应输入和输出长度的变化。这已成为 LLM 服务系统的标准技术。
• 独立批处理 (Separate Batching)：仅在预填充阶段或解码阶段分别对请求进行批处理。由于这两个阶段性能特征不同（预填充计算密集，解码内存密集），这种方式可以为每个阶段选择最优的批次大小。
• 混合批处理 (Hybrid Batching)：将预填充和解码阶段的请求合并到同一个批次中进行处理。

3.1.6. LLM 并行推理 (Parallel LLM Inference)

为了提升单个推理实例的计算和内存容量，采用了多种并行策略：

• 张量并行 (Tensor Parallelism, TP)：将每个层的计算分布在多个设备上，模型权重和 KV 缓存均匀分布。这需要频繁的设备间通信（例如，每个 Transformer 层涉及两次 all-reduce 操作）。论文中提到 Llama-30B 在 4 个 NVIDIA L20 GPU 上进行分布式 TP 推理时，通信开销占据了近一半的执行时间。

• 流水线并行 (Pipeline Parallelism, PP)：层级划分模型，每个设备负责模型的一部分层。它只需要较少的数据量（每个几层一次点对点通信）进行通信，因此在商品化硬件上很有前景。

• 专家并行 (Expert Parallelism, EP) 和 序列并行 (Sequence Parallelism, SP)：EP 将 MoE (Mixture of Experts) 模型中的不同专家分布到不同设备上。SP 则在序列维度上进行划分。

  下图（原文 Figure 3）展示了张量并行和流水线并行：

  该图像是论文中图5的架构示意图，展示了EcoServe系统的部分解耦策略及调度流程。包含时间维度的预填充与解码阶段的划分（Temporal Disaggregation）、滚动激活（Rolling Activation）、自适应调度算法及分裂扩容（Mitosis Scaling Approach）等关键模块。

Figure 3. Tensor parallelism and pipeline parallelism.

• (a) 张量并行 (Tensor Parallelism)：将一个 Transformer 层的计算（例如 QKV 投影和 FFN）分布到多个 GPU 上。每个 GPU 只计算一部分张量，然后通过 all-reduce 操作同步结果。这种方式需要频繁且高带宽的通信。

• (b) 流水线并行 (Pipeline Parallelism)：将模型的不同层分配给不同的 GPU。例如，GPU 0 处理第 0-L/2 层，GPU 1 处理第 L/2+1 到 L 层。数据在层之间通过点对点通信传递。这种方式减少了通信量，但可能因阶段不平衡导致“流水线气泡”。

  下图（原文 Figure 4）展示了流水线气泡：

  该图像是图表，展示了论文中关于流水线气泡（Pipeline bubbles）的示意，具体表现为多GPU在不同批次之间及预填充（Prefill）与解码（Decode）阶段的时间不均衡情况。

Figure 4. Pipeline bubbles.

• 流水线气泡 (Pipeline Bubbles)：在流水线并行中，由于不同阶段或不同微批次的工作负载不均衡，会导致某些 GPU 处于空闲等待状态，这些空闲时间就被称为“气泡”。例如，图 4 中，GPU 0 完成了微批次 MB0 的处理后，在 MB1 到来之前可能会空闲，而 GPU 1 在等待 MB0 的输出时也可能空闲。LLM 推理中的预填充-解码阶段的不平衡和迭代间的依赖性会加剧这种气泡问题。

3.1.7. 服务水平目标 (Service Level Objectives, SLOs) 与吞吐量 (Goodput)

• 首令牌时间 (Time to First Token, TTFT)：从接收请求到生成第一个输出令牌所需的时间。这是衡量预填充阶段延迟的关键指标，对用户感知的响应速度至关重要。
• 每输出令牌时间 (Time Per Output Token, TPOT)：生成每个后续输出令牌所需的平均时间。这是衡量解码阶段延迟的关键指标，影响用户感知的生成流畅性。
• 吞吐量 (Goodput)：在给定 SLO 约束下，系统每秒成功处理的请求数或生成的令牌数。它反映了系统在满足服务质量要求的前提下的效率。论文中还特别提到，系统吞吐量通常通过逐渐增加请求率直到系统无法达到预设的 SLO 来衡量。

3.2. 前人工作

LLM 大规模服务策略根据预填充和解码阶段是否解耦，主要分为以下两类：

3.2.1. 非解耦策略 (Non-Disaggregated, NoDG)

• 核心思想：预填充和解码阶段在同一个推理实例中共同执行。一个实例负责处理请求的整个生命周期。当请求量增加时，系统通过复制更多独立实例来横向扩展服务。
• 代表系统：vLLM [5], Sarathi [9]。
• 局限性：
  • 预填充-解码干扰 (Prefill-Decode Interference)：这是最主要的问题。预填充阶段通常比解码步骤耗时更长。如果同时调度，解码请求常被预填充请求延迟，导致 TPOT 变差；反之，解码请求的存在也会增加 TTFT。
  • 低吞吐量 (Low Throughput)：在 SLO 约束下，解码阶段难以积累足够大的批次大小来饱和 GPU，导致整体吞吐量低下。
  • 流水线并行兼容性差：由于预填充长度可变、解码迭代间强依赖，微批次工作负载不平衡，导致严重的流水线气泡。
  • Chunked Prefill：Sarathi 提出的分块预填充 (chunked prefill) 技术试图缓解干扰，通过将长预填充请求分成小块处理，但这会引入重复 KV 缓存访问开销，且效果受输入/输出长度比影响。

3.2.2. 完全解耦策略 (Fully Disaggregated, FuDG)

• 核心思想：将预填充和解码阶段明确地分离到不同的实例上。新请求首先进入预填充实例生成 KV 缓存和第一个令牌，然后 KV 缓存被传输到解码实例以完成后续解码步骤。
• 代表系统：DistServe [50] (节点内 FuDG), MoonCake [35] (节点间 FuDG)。
• 优势：彻底消除了预填充-解码阶段的内部干扰。
• 局限性：

  • 高互连要求 (High Interconnect Requirements)：需要传输大量的 KV 缓存数据。如表 3 所示，Llama-30B 在 8 块 A800 GPU 上的预填充实例可能需要超过 38 GB/s 的理论带宽，这需要 400 Gbps 的高性能网络。即使使用 GQA (Grouped Query Attention) 压缩 KV 缓存的 CodeLlama-34B 也需要 4.76 GB/s 的带宽。这些高性能互连（如 NVLink、InfiniBand）不仅昂贵，而且能耗高。

  • 负载不平衡 (Load Imbalance)：

    • 实例类型不平衡：由于预填充和解码阶段持续时间不对称，一个预填充实例通常需要多个解码实例来保持负载平衡，难以精确调整比例。
    • 内存利用率不平衡：解码实例存储大量 KV 缓存，而预填充实例存储较少，可能导致预填充实例的内存闲置，资源利用率低下。

  • PCIe 瓶颈：在没有 GPU 直连互连的节点上，张量并行和 KV 缓存迁移会激烈争夺 PCIe 带宽，可能成为瓶颈。

    下表（原文 Table 3）展示了预填充实例中的 KV 缓存生成速度以及 FuDG 策略所需的理论带宽：

    Model	Device	Tokens/s	Theoretical Bandwidth
    Llama-30B	L20	6584.6	9.796 GB/s
    Llama-30B	A800	26189.2	38.96 GB/s
    CodeLlama-34B	L20	6838.92	1.25 GB/s
    CodeLlama-34B	A800	25978.88	4.76 GB/s

以下是原文 Table 3 的结果： 表格解读: Llama-30B 模型由于其标准的 MHA (Multi-Head Attention) 机制，KV 缓存较大，因此在生成相同数量令牌时所需的带宽远高于采用 GQA (Grouped Query Attention) 机制的 CodeLlama-34B。特别是在 A800 GPU 上，Llama-30B 的预填充实例可能需要高达 38.96 GB/s 的带宽，这对于常见的商品化网络（如 10Gbps 或 25Gbps 以太网）来说是巨大的挑战，必须依赖 400Gbps 或更快的网络才能满足。这突显了 FuDG 策略对高性能互连的强烈依赖。

3.3. 技术演进

LLM 服务策略的演进反映了在提升吞吐量、降低延迟和控制成本之间不断寻求平衡的过程：

1. 早期 NoDG 策略：最初，LLM 服务系统（如 vLLM）自然地采用 NoDG 策略，在单个实例中处理请求的整个生命周期。这种方法实现简单，但在模型规模和并发请求增加时，预填充与解码的干扰成为主要瓶颈。
2. FuDG 策略的出现：为了彻底消除预填充-解码干扰，FuDG 策略被提出（如 DistServe, MoonCake），将这两个阶段分离到不同的实例中。这在性能上提供了显著提升，但引入了高昂的硬件成本和复杂的数据传输挑战，特别是对高性能互连的依赖。
3. PaDG 策略的创新：EcoServe 提出的 PaDG 策略试图在 NoDG 和 FuDG 之间找到一个“甜点”。它认识到，虽然分离阶段可以提高效率，但物理实例间的完全分离以及随之而来的 KV 缓存传输并非总是最佳方案，尤其是在商品化硬件环境下。PaDG 通过时间维度上的解耦（在单个实例内）和多实例间的协调（滚动激活），在保持数据局部性的同时，实现了阶段隔离，从而在商品化互连集群上提供成本效益高的 LLM 服务。

3.4. 差异化分析

下表（原文 Table 5）比较了 PaDG 策略与现有 NoDG 和 FuDG 策略在多个维度上的特点：

以下是原文 Table 5 的结果： 表格解读：

• 吞吐量 (Goodput)：PaDG 和 FuDG 都表现出优异的吞吐量 ($√√$)，远超 NoDG (✓)，这主要得益于阶段解耦带来的干扰消除。

• 成本效益 (Cost Effective)：PaDG 被评为 Excellent，因为它在提供高吞吐量的同时，避免了对昂贵高性能互连的需求。FuDG 被评为 Poor，因为它严重依赖高成本硬件。NoDG 成本效益 Good，但吞吐量受限。

• 负载均衡 (Load Balance)：PaDG 和 NoDG 都相对 Easy 实现负载均衡，因为它们的服务单元是统一的实例。FuDG 则因为需要管理不同类型的实例（预填充和解码）以及它们之间不对称的工作负载，导致负载均衡 Hard。

• 硬件成本 (Hardware Cost)：PaDG 和 NoDG 都需要 Low 硬件成本，可在商品化集群上运行。FuDG 则需要 High 硬件成本，特别是对高性能互连的要求。

• 并行兼容性 (Parallelism Compatibility)：PaDG 和 FuDG 对并行策略（如流水线并行和张量并行）的兼容性都更高 (High)，因为阶段分离可以更好地利用并行性。NoDG 的兼容性 Low，因为阶段干扰和气泡问题。

• 工程复杂度 (Engineering Complexity)：PaDG 和 NoDG 的工程复杂度相对 Low。PaDG 虽然有更复杂的调度逻辑，但避免了跨实例 KV 缓存传输的复杂性。FuDG 需要管理 KV 缓存池和跨实例数据传输，因此复杂度 High。

  总而言之，PaDG 策略旨在通过智能调度和在时间维度上解耦，在商品化硬件上实现与 FuDG 相当甚至更好的吞吐量，同时保持 NoDG 的低成本和工程简洁性，从而提供卓越的成本效益。

4. 方法论

4.1. 方法原理

EcoServe 的核心思想是部分解耦策略 (Partially Disaggregated, PaDG)。该策略通过主动的实例内和实例间编排来优化吞吐量 (goodput)。其背后的直觉是，传统的非解耦 (NoDG) 策略由于预填充 (prefill) 和解码 (decode) 阶段的干扰而效率低下，而完全解耦 (FuDG) 策略虽然解决了干扰，但对昂贵的高性能互连有强依赖。PaDG 策略旨在结合两者的优点，即在单个实例内通过时间维度上的解耦来减轻干扰，并通过多实例间的协调来确保服务的连续性，从而在商品化互连集群上实现经济高效的 LLM 服务。

EcoServe 系统的组织结构是分层架构 (hierarchical architecture)，包含三个层次的调度器：

1. 总体调度器 (Overall Scheduler)：负责将请求分配到宏实例 (macro instance)，并管理不同宏实例之间的容量扩展（例如，实例句柄的迁移）。

2. 宏实例调度器 (Macro-instance Scheduler)：这是 EcoServe 中引入的独特抽象级别，作为系统最小的调度单元。它协调多个实例，聚合它们的执行状态，并根据分析结果和服务水平目标 (SLO) 将请求分派到适当的实例。

3. 实例调度器 (Instance Scheduler)：负责管理单个实例内部的执行，包括协调预填充和解码阶段、编排多个设备，并执行来自上层调度器的指令。

   本文主要聚焦于宏实例内部的架构和机制。

4.2. 核心方法详解

4.2.1. 部分解耦策略 (Partially Disaggregated Strategy - PaDG)

PaDG 策略是 EcoServe 的基石，通过结合时间解耦 (Temporal Disaggregation) 和滚动激活 (Rolling Activation) 来实现主动的实例内和实例间调度。

下图（原文 Figure 5）展示了 EcoServe 的架构概览，其中包含了 PaDG 策略的核心组件：

该图像是图7，展示了扩展和收缩两个过程的示意图。扩展过程包括添加(add)和拆分(split)操作，收缩过程包括删除(delete)和合并(merge)操作。图中以 $N_l=3$ 和 $N_u=6$ 为例说明。

Figure 5. EcoServe Architecture Overview.

图 5 中 $(4)$ 所示的是时间解耦，$(\theta)$ 所示的是滚动激活。

4.2.1.1. 时间解耦 (Temporal Disaggregation)

• 原理：为了减轻预填充-解码干扰，PaDG 策略在单个实例内部沿时间维度解耦预填充和解码阶段。这意味着每个推理实例在一段时间内只专注于处理一种类型的任务（预填充或解码），然后周期性地切换。
• 目的：
  • 减轻干扰：通过确保实例在特定时间段内只处理一种任务，避免了预填充与解码同时竞争资源造成的性能下降。
  • 提高吞吐量：减少切换开销，允许每个阶段更长时间地运行，从而更好地利用设备资源。
  • 保持局部性：与 FuDG 不同，预填充和解码仍在同一实例内执行，因此不需要跨实例传输 KV 缓存，避免了数据传输开销和对高性能互连的依赖。
• 挑战与解决：
  • TTFT 恶化：如果一个新请求被分配到一个正在处理解码阶段的实例，它必须等待实例切换到预填充阶段才能被处理，这会导致不可接受的 TTFT。
  • 解决方式：结合滚动激活来弥补这一挑战。
• TPOT 优势：LLM 服务通常以打字机模式 (typewriter mode) 渲染输出，只要在时间窗口内生成足够多的令牌，TPOT SLO 就能满足。如果解码执行速度快于 TPOT 约束，系统可以积累“节省的 TPOT (saved TPOT)”（即空闲时间），这些时间可以用于中断解码阶段而不违反 SLO。这为切换到预填充阶段提供了灵活性。

4.2.1.2. 滚动激活 (Rolling Activation)

• 原理：为了解决时间解耦可能导致的 TTFT 恶化问题，滚动激活策略主动协调多个实例，并错开它们的预填充阶段。
• 目的：确保预填充处理的持续可用性。通过将多个实例安排成循环模式，在任何给定时间，总会有一些实例专门处于预填充阶段，能够立即处理新请求。
• 宏实例 (Macro Instance)：EcoServe 引入的抽象概念，指代一组相互协作的实例，它们通过滚动激活模式共同工作，以实现连续的预填充处理。宏实例是 EcoServe 中最小的调度单元。
• 效果：从单个请求的角度看，它总能被路由到当前处于预填充阶段的实例，从而立即得到处理。这大大减少了新请求的等待时间，有效解决了 TTFT 问题。
• 数据流：由于输出长度不确定，实例需要不断向宏实例调度器更新其状态，例如解码进度和内存使用情况，以便进行协调。

4.2.2. 系统指标与用户体验 (System Metrics v.s. User Experience)

论文指出，传统的 TTFT 和 TPOT 指标不足以完全反映 LLM 服务系统的性能，尤其是在预填充-解码切换阶段。

下图（原文 Figure 6）展示了运行时和前端的时间特性：

该图像是多组柱状图，展示了EcoServe与vLLM、Sarathi、DistServe及MoonCake在不同模型（如Llama-30B、CodeLlama2-34B、Qwen2-72B）和数据集（Alpaca、ShareGPT、LongBench）下P50、P90及P99延迟下的吞吐率对比，反映了EcoServe在多GPU配置中的优越性能。

Figure 6. Runtime and frontend Timing.

• 运行时 (Runtime)：指的是模型实际执行预填充和解码操作的时间。传统的 TTFT 和 TPOT 在此层面定义。
• 前端 (Frontend)：指用户界面接收并渲染令牌的时间。
• TTFT (Time to First Token)：在 EcoServe 的语境中，报告的 TTFT 实际上包含两个组成部分：true TTFT（实际预填充耗时）和 phase-switching waiting time（等待阶段切换的时间）。这意味着 EcoServe 对 TTFT 的定义是一个更严格的 SLO，因为它将额外的开销也计算在内。
• TPOT (Time Per Output Token)：TPOT 的测量在阶段切换等待时间结束后开始。
• 阶段切换等待时间 (Phase-switching Waiting Time)：在请求进入解码阶段之前，NoDG、PaDG 和 FuDG 策略都会发生额外的操作。对于 NoDG 和 PaDG，其他请求的预填充可能会在当前请求进入解码阶段之前发生。对于 FuDG，解码阶段之前有 KV 缓存传输开销。这个等待时间虽然在传统指标中可能被忽视或误报，但对用户体验至关重要。论文强调这个指标很重要，并且在以往的工作中常被误报，可能掩盖了现有系统的关键局限性。

4.2.3. 自适应调度算法 (Adaptive Scheduling Algorithm)

EcoServe 的自适应调度算法由三个子算法组成，协同工作以实现实例内和实例间的调度决策。

4.2.3.1. 实例间调度算法 (Inter-Instance Scheduling Algorithm)

• 职责：由宏实例调度器执行，负责将传入请求路由到宏实例内的合适实例。
• 工作流程：如算法 1 所示，对于新传入的请求 req：

  1. 算法首先尝试将其路由到处理上一个请求的实例 (last_instance)。

  2. 如果该实例满足由约束检查算法 (Constraint Checking Algorithm) 验证的所有约束，则请求被路由到该实例。

  3. 如果该实例不满足约束，算法会检查下一个可用的实例（通过 (prev_idx + 1)%len(instances) 实现循环遍历），直到找到一个合适的实例。

     以下是原文 Algorithm 1 的伪代码：

Data: current request: req; instance list: instances;
1 Function InterSchedule(req):
2   prev_idx last request's routed instance;
3   last_instance instances[prev_idx];
4   if CheckConstraints (last_instance,req) then
5     route req to instance[prev_idx];
6   else
7     next_idx ← (prev_idx + 1)%len(instances) ;
8     route req to instance[next_idx];

• 符号解释：
  • req: 当前待调度的请求。
  • instances: 宏实例中所有实例的列表。
  • prev_idx: 上一个请求被路由到的实例的索引。
  • last_instance: 上一个请求被路由到的实例对象。
  • CheckConstraints(instance, req): 一个函数，用于检查将 req 路由到 instance 是否会违反预设约束。
  • next_idx: 循环选择的下一个实例的索引。
  • route req to instance[...]: 将请求路由到指定的实例。

4.2.3.2. 约束检查算法 (Constraint Checking Algorithm)

• 职责：由宏实例调度器调用，用于验证将新请求分配给特定实例是否会违反 TTFT/TPOT SLO 或超出实例的内存容量。

• 工作流程：如算法 2 所示，它检查三个主要约束：

  以下是原文 Algorithm 2 的伪代码：

Data: System constraints: SLOTTFT, SLOTPOT;
1 Function CheckConstraints(instance, req):
2   Constraint 1: TTFT
3     t_switch phase switching timestamp;
4     pending_prefills { r ∈ instance.reqs | r.arrival_time ≥ t_switch } ∪ {req}
5     prefill_times predict pending_prefills durations ;
6     t_total ∑ prefill_times;
7     if t_total > SLOTTFT then
8       return NotSatisfied;
9   Constraint 2: TPOT
10    existed_decodes { r ∈ instance.reqs | r.arrival_time < Δt_switch }:
11    saved_tpots [] :
12    current_time current timestamp;
13    foreach r ∈ existed_decodes do
14      L ←r.output_length;
15      saved_l_tpot ← L × SLOTPOT - (current_time -r.first_token_time)
16      saved_tpots.append(saved_l_tpot)
17    mean_saved_tpot mean(saved_tpots);
18    if mean_saved_tpot < t_total then
19      return NotSatisfied;
20  Constraint 3: KV Cache capacity
21    if req_kocache_size > remain_memsize then
22      return NotSatisfied;
23    return Satisfied

• 符号解释：

  • SLO_TTFT: 系统设定的 TTFT 服务水平目标。
  • SLO_TPOT: 系统设定的 TPOT 服务水平目标。
  • instance: 待检查的实例对象。
  • req: 待添加的新请求。
  • t_switch: 实例内预填充和解码阶段切换的时间戳。
  • pending_prefills: 实例中所有在 t_switch 之后到达的待处理预填充请求的集合，包括新请求 req。
  • prefill_times: 预测的 pending_prefills 中每个请求的预填充持续时间。
  • t_total: 所有 pending_prefills 的预填充持续时间总和。
  • existed_decodes: 实例中所有在 t_switch 之前到达的、当前正在解码的请求的集合。
  • saved_tpots: 存储每个正在解码请求的“节省的 TPOT”的列表。
  • current_time: 当前时间戳。
  • r.output_length: 请求 $r$ 已生成的输出令牌长度。
  • r.first_token_time: 请求 $r$ 第一个令牌生成的时间。
  • saved_l_tpot: 对于单个请求 $r$ 而言，L × SLO_TPOT - (current_time - r.first_token_time) 表示其在满足 TPOT SLO 的前提下，可以“节省”的等待时间。如果实际解码时间小于 L × SLO_TPOT，则 saved_l_tpot 为正数，表示有盈余时间。
  • mean_saved_tpot: 所有 existed_decodes 的 saved_l_tpot 的平均值。
  • req_kocache_size: 新请求 req 所需的 KV 缓存大小。
  • remain_memsize: 实例中剩余的 GPU 内存大小。

• 约束 1：TTFT

  • 计算将新请求 req 添加到当前预填充队列后，所有待处理预填充请求的总持续时间 t_total。
  • 如果 t_total 超过 SLO_TTFT，则表示无法满足 TTFT 约束，返回 NotSatisfied。这确保了即使包含等待时间，首令牌延迟也能在 SLO 范围内。预填充持续时间可以通过预先对不同长度序列进行分析来预测。

• 约束 2：TPOT

  • 计算当前正在解码的请求所“节省”的 TPOT（即，它们在满足 TPOT SLO 的前提下，可以承受多少额外的等待时间）。
  • 具体地，对于每个正在解码的请求 $r$，其“节省的 TPOT”计算为 L × SLO_TPOT - (current_time - r.first_token_time)。如果这个值是正的，意味着该请求有额外的缓冲时间。
  • 如果所有正在解码请求的平均“节省的 TPOT” (mean_saved_tpot) 小于新预填充请求的预计总持续时间 t_total，则表示引入新预填充请求会导致现有解码请求违反 TPOT SLO，返回 NotSatisfied。

• 约束 3：KV 缓存容量 (KV Cache Capacity)

  • 检查新请求 req 所需的 KV 缓存大小是否会超出实例的剩余 GPU 内存容量。
  • 如果超出，则无法满足内存约束，返回 NotSatisfied。

4.2.3.3. 实例内调度算法 (Intra-Instance Scheduling Algorithm)

• 职责：由实例调度器执行，管理单个实例内的预填充和解码任务。
• 工作流程：尽管最终结果是阶段在时间上解耦，但实例调度器在执行时优先处理预填充。
  • 它会持续处理活跃的解码请求，并定期向宏实例调度器更新其进度。
  • 当从宏实例调度器接收到新的预填充请求时，它会切换到预填充阶段来处理这些请求。
  • 这种机制确保了即使实例主要处于解码阶段，也能在接收到新预填充请求时迅速响应，并且通过累积“节省的 TPOT”来为这种切换提供缓冲。

4.2.4. 分裂扩容方法 (Mitosis Scaling Approach)

为了实现细粒度的容量调整以适应 LLM 推理工作负载的动态变化，EcoServe 引入了分裂扩容方法。

4.2.4.1. 扩展与收缩 (Expansion and Contraction)

• 超参数：系统定义了两个超参数：
  • $N_l$: 宏实例中实例数量的下限。
  • $N_u$: 宏实例中实例数量的上限。
• 扩容触发：当系统无法满足定义的 SLOs，或资源长期利用率不足时，会触发扩容或收缩。
• 扩展过程：
  1. 新的实例被增量式地添加到现有的宏实例中。
  2. 当宏实例中的实例数量超过上限 $N_u$ 时，会从原始宏实例中拆分 (split) 出一个新的宏实例，其中包含 $N_l$ 个实例（如图 7 中的 $(1)$ 步骤）。
  3. 如果仍需要更多实例，它们首先被添加到原始宏实例，直到再次达到 $N_u$（如图 7 中的 $(3)$ 步骤）。
  4. 后续的实例则添加到新拆分出的宏实例中（如图 7 中的 $(4)$ 步骤）。
• 收缩过程：

  1. 当容量过剩并触发收缩时，实例首先从最小的宏实例中移除，直到其数量达到 $N_l$（如图 7 中的 $(5)$ 步骤）。

  2. 接下来，实例开始从一个满载的宏实例中移除（如图 7 中的 $(6)$ 步骤）。

  3. 当这两个宏实例中的实例总数达到 $N_u$ 时，它们会在移除一个额外实例后合并 (merge) 成一个单一的宏实例（如图 7 中的 $(\delta)$ 步骤）。

     下图（原文 Figure 7）展示了扩展和收缩过程的示意图：

     该图像是图9的图表，展示了EcoServe系统在不同实例数量下的吞吐量表现。图中通过对比EcoServe P90与线性增长，反映了系统的静态粗粒度扩展性能。

Figure 7. The illustration of the expansion and contraction processes. Here $N _ { l } = 3$ and $N _ { u } = 6$ .

图 7 解读：

• 扩展：当实例数量达到 $N_u$ 时，会创建一个新的宏实例，并从原始宏实例中“迁移” $N_l$ 个实例过去，形成两个新的宏实例。
• 收缩：当实例总数较少时，较小的宏实例会被优先缩减。当两个宏实例的总数降至 $N_u$ 时，它们会合并成一个。
• 效果：这种机制使得系统通常维护多个满载的宏实例，以及一个或两个部分填充的宏实例，从而实现弹性适应工作负载变化。

4.2.4.2. 灵活实例迁移 (Flexible Instance Migration)

• 挑战：在动态拆分或合并宏实例时，需要迁移实例而不能中断其执行或重新初始化。重新初始化一个实例（例如 CodeLlama2-34B）可能需要数分钟，这会导致显著的服务中断。
• 解决方案：设计了一个可序列化代理对象 (serializable proxy object)，用于在不同的宏实例调度器之间传输实例句柄 (instance handler)。
• 实现细节：
  • InstanceHandler 元数据封装了关键信息，如演员 ID (actor ID)、工作器地址 (worker address)、函数调用 (function calls) 和其他相关属性。
  • 当句柄需要在宏实例调度器之间（即跨进程）传输时，它首先使用 pickle 库进行序列化。
  • 然后，由总体调度器协调传输过程。
  • 在接收端，接收进程对代理对象进行反序列化，重建一个功能齐全的代理，该代理可以通过 RPC-like 系统发出函数调用。
• 优点：
  • 实现了实例在宏实例调度器之间的逻辑迁移，而无需中断其执行。
  • 开销极低（论文提到小于 100 毫秒），并且可以通过在解码阶段触发迁移来完全隐藏。
  • 支持更灵活和低开销的扩容，显著优于重新初始化实例所带来的高昂开销。

4.2.5. LLM 的主要操作及算术强度

在 Transformer 架构中，主要计算集中在 QKV 投影、注意力机制和前馈网络 (FFN)。

QKV 投影 (QKV Projection):

• 公式： $${\bf Q} = W_q {\bf X}, \quad {\bf K} = W_k {\bf X}, \quad {\bf V} = W_v {\bf X} .$$

• 符号解释：

  • ${\bf Q}, {\bf K}, {\bf V}$: 分别表示查询、键、值矩阵。
  • $W_q, W_k, W_v$: 相应的权重矩阵。
  • ${\bf X}$: 输入的令牌嵌入矩阵。

• 目的：将输入嵌入转换为查询、键和值表示。

  注意力机制 (Attention):

• 公式： $$\mathrm{Attention}(\mathbf{Q}, \mathbf{K}, \mathbf{V}) = \mathrm{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)\mathbf{V}$$

• 符号解释：

  • $\mathbf{Q}$: 查询矩阵。
  • $\mathbf{K}$: 键矩阵。
  • $\mathbf{V}$: 值矩阵。
  • $Q K^T$: 查询和键的点积，衡量令牌之间的相似度。
  • $\sqrt{d_k}$: 缩放因子，其中 $d_k$ 是键向量的维度，用于防止点积过大。
  • $\mathrm{softmax}(\cdot)$: 归一化函数，将注意力分数转换为概率分布。
  • $\mathrm{Attention}(\cdot)$: 最终的注意力输出，是值向量的加权和。

• 目的：捕捉输入序列中不同令牌之间的依赖关系。

  前馈网络 (Feedforward Network, FFN):

• 公式： $$\mathrm{FFN}(x) = \mathrm{Act}(x W_1 + b_1) W_2 + b_2$$

• 符号解释：

  • $x$: 输入到 FFN 的向量。
  • $W_1, W_2$: 权重矩阵。
  • $b_1, b_2$: 偏置向量。
  • $\mathrm{Act}(\cdot)$: 非线性激活函数（例如 ReLU 或 GELU）。

• 目的：在每个位置独立地对令牌表示进行进一步转换，增强模型的表达能力。

  下表（原文 Table 2）展示了 LLM 中主要操作的近似算术强度 (AI)：

  Operation	P/D	FLOPS	Memory Access	Approximate AI
  QKV Projection	Prefill	6BSH2	6BSH + 3H2	BS
  	Decode	6BH2	6BH + 3H2	B
  Attention	Prefill	2BS2H	2BSH + BS2M	S
  	Decode	2BSH	2BSM + BH(S + 1)	1
  Attention ()	Prefill	2BS2H	2BSH + BS2M	S
  	Decode	2BSH	2BSM + BH(S + 1)	1
  Output Projection	Prefill	2BSH2	2BSH + H2	BS
  	Decode	2BH2	2BH + H2	B
  Dim Expansion	Prefill	8BSH2	2BSH + 4H2	BS
  	Decode	8BH2	2BH + 4H2	B
  Dim Reduction	Prefill	8BSH2	2BSH + 4H2	BS
  	Decode	8BH2	2BH + 4H2	B

以下是原文 Table 2 的结果： 表格解读：

• 符号解释 (结合原文 Table 1):
  • $S$: prompt_len，提示的长度。
  • $G$: generation_len，生成令牌的长度。
  • $B$: batch_size，批次大小，即批处理的请求数量。
  • $L$: layer_num，模型层数。
  • $H$: hidden_size，隐藏层输入维度。
  • $M$: heads，注意力头的数量。
  • $D$: size_per_head，每个注意力头的隐藏状态维度。
• 分析：
  • 预填充阶段 (Prefill)：所有主要操作的算术强度都与 $S$ 和/或 $B$ 相关（如 BS, $S$）。由于 $S$ (序列长度) 通常较大，预填充阶段表现出显著更高的算术强度，是计算密集型的。
  • 解码阶段 (Decode)：所有主要操作的算术强度主要与 $B$ 相关（如 $B$, 1）。尤其是注意力操作，其算术强度仅为 1，这意味着解码阶段的计算量相对较小，且需要频繁访问 KV 缓存，使其成为内存密集型的。
• 结论：预填充阶段通常是计算瓶颈，而解码阶段通常是内存带宽瓶颈。这一区别是 PaDG 策略进行阶段解耦和优化的重要依据。

5. 实验设置

5.1. 数据集

实验使用了三个具有不同输入和输出长度分布的代表性数据集，所有输入均截断至最大长度 4096。

下表（原文 Table 4）展示了数据集特征和对应的 SLOs：

以下是原文 Table 4 的结果： 表格解读：

• Alpaca-gpt4：用于人类指令应用。

  • 特点：输入序列非常短 (平均 20.63)，但输出相对较长 (平均 163.80)，输出长度约为输入长度的 10 倍。
  • SLOs：TTFT 1秒，TPOT 100毫秒。

• ShareGPT：用于聊天机器人应用。

  • 特点：输入和输出长度相对平衡 (输入平均 343.76，输出平均 237.20)。
  • SLOs：TTFT 5秒，TPOT 100毫秒。

• LongBench：用于摘要应用。

  • 特点：输入序列非常长 (平均 2686.89)，但输出很短 (平均 101.78)。
  • SLOs：TTFT 15秒，TPOT 100毫秒。

• SLO 设置：TTFT 和 TPOT 的 SLOs 仅根据应用类型设置，不区分模型大小。大多数情况下，这些 SLOs 比现有工作中使用的更严格。

  选择这些数据集的原因：它们代表了不同的 LLM 应用场景和工作负载模式（短输入长输出、平衡、长输入短输出），能够全面评估服务系统的性能。

5.2. 评估指标

论文使用以下指标来评估 LLM 服务的性能：

1. 首令牌时间 (Time to First Token, TTFT)

   • 概念定义: TTFT 衡量从接收到请求到系统生成并返回第一个输出令牌所需的时间。它直接反映了系统对新请求的响应速度，对用户感知的“启动延迟”至关重要。在本文中，报告的 TTFT 包含实际的预填充处理时间和可能存在的阶段切换等待时间 (phase-switching waiting time)，因此其 SLO 比传统定义更为严格。
   • 数学公式: 论文未直接给出 TTFT 的数学公式，但其核心是时间间隔。 $$\text{TTFT} = T_{\text{first\_token\_generated}} - T_{\text{request\_received}}$$
   • 符号解释:
     • $T_{\text{first\_token\_generated}}$: 第一个输出令牌被系统生成的时间点。
     • $T_{\text{request\_received}}$: 系统接收到用户请求的时间点。

2. 每输出令牌时间 (Time Per Output Token, TPOT)

   • 概念定义: TPOT 衡量系统生成每个后续输出令牌所需的平均时间。它反映了生成过程的流畅性，对用户感知的“生成速度”至关重要。本文中，TPOT 的测量在阶段切换等待时间结束后开始。
   • 数学公式: 论文未直接给出 TPOT 的数学公式，但其核心是平均时间。 $$\text{TPOT} = \frac{T_{\text{all\_tokens\_generated}} - T_{\text{first\_token\_generated}}}{N_{\text{total\_tokens}} - 1}$$
   • 符号解释:
     • $T_{\text{all\_tokens\_generated}}$: 所有输出令牌被生成的时间点。
     • $T_{\text{first\_token\_generated}}$: 第一个输出令牌被生成的时间点。
     • $N_{\text{total\_tokens}}$: 生成的总令牌数量。

3. 吞吐量 (Goodput)

   • 概念定义: 吞吐量衡量系统在满足预设的服务水平目标 (SLO) 的前提下，单位时间内成功处理的请求数量或生成的令牌数量。它是衡量系统整体效率的关键指标。论文通过逐渐增加请求率直到系统无法满足 SLO 来收集吞吐量数据。
   • 数学公式: 论文未直接给出吞吐量的数学公式，但通常表示为： $$\text{Goodput} = \frac{\text{Number of Successful Requests}}{\text{Time Period}} \quad \text{或} \quad \text{Goodput} = \frac{\text{Number of Successful Output Tokens}}{\text{Time Period}}$$
   • 符号解释:
     • $\text{Number of Successful Requests}$: 在指定时间段内，所有TTFT和TPOT均满足SLO的请求数量。
     • $\text{Number of Successful Output Tokens}$: 在指定时间段内，所有TTFT和TPOT均满足SLO的请求所生成的令牌总数。
     • $\text{Time Period}$: 测量时间段。

4. SLO 达成率 (SLO Attainment)

   • 概念定义: SLO 达成率衡量达到特定延迟服务水平目标 (Service Level Objectives) 的请求百分比。论文特别关注 P50、P90 和 P99 百分位数，例如 P90 达成率意味着 90% 的请求满足了其延迟要求。这是在实际生产环境中评估系统稳定性和用户体验的关键指标。
   • 数学公式: 论文未直接给出 SLO 达成率的数学公式，但其概念是： $$\text{P}X \text{ Attainment} = \text{Percentage of requests where latency} \le \text{Target Latency}$$
   • 符号解释:
     • $X$: 百分位数 (例如 50, 90, 99)。
     • $\text{latency}$: 某个请求的 TTFT 或 TPOT。
     • $\text{Target Latency}$: 预设的 TTFT 或 TPOT SLO 值。

5.3. 对比基线

为了全面评估 EcoServe，论文将其与四种代表性的 LLM 服务系统进行了比较，这些系统均基于 vLLM 运行时构建，以确保公平性：

1. vLLM [5]：

   • 策略: 非解耦 (NoDG) 策略。
   • 批处理: 独立批处理 (separate batching)。
   • 调度: 预填充优先 (prefill-priority) 调度。
   • 特点: 作为高效 LLM 服务的流行开源系统，vLLM 优化了 KV 缓存管理 (PagedAttention)，但其默认调度策略在预填充和解码之间存在固有干扰。

2. Sarathi [9]：

   • 策略: 非解耦 (NoDG) 策略。
   • 批处理: 混合批处理 (hybrid batching)。
   • 调度: 解码优先 (decode-priority) 调度，并使用分块预填充 (chunked prefill) 技术。
   • 特点: 旨在通过优先解码和分解长预填充来缓解 NoDG 策略中的干扰问题，但其效果受输入-输出长度比等因素影响。

3. DistServe [50]：

   • 策略: 节点内完全解耦 (intra-node FuDG) 策略。
   • 特点: 将预填充和解码实例部署在同一个节点内，通过节点内的高速互连（如 NVLink）传输 KV 缓存，以避免节点间带宽瓶颈。但这些互连本身成本较高。论文指出，DistServe 包含一种跨节点分发实例的策略，但其在本文设置下无法满足 SLO。

4. MoonCake [35]：

   • 策略: 节点间完全解耦 (inter-node FuDG) 策略。
   • 特点: 预填充和解码实例可以分配到不同的节点上。它引入了一个集中式 KV 缓存池 (centralized KV cache pool) 作为 KV 缓存传输的中间缓冲。即使预填充和解码实例在同一节点，KV 缓存仍需通过此中间池传输。为了缓解负载不平衡，实验中会尝试不同的预填充/解码 (P/D) 比例并选择最优的。

5.4. 实验环境

1. 集群测试台 (Cluster Testbed)：

   • 主要测试台 (L20 Cluster)：一个生产级集群，共有 8 个节点，总计 64 块 NVIDIA L20-48GB GPU。每个节点配备 8 块 GPU，通过 PCIe only 连接（意味着无 NVLink）。节点之间通过标准的 10Gbps 以太网互连。这代表了现代数据中心典型的商品化基础设施设置。
   • 第二测试台 (A800 Cluster)：2 个节点，每个节点配备 8 块 NVIDIA A800-80GB GPU，同样通过 PCIe only 连接。节点之间通过更高带宽的 25Gbps RoCE (RDMA over Converged Ethernet) 互连。

2. 模型设置 (Model Setup)：

   • 模型: Llama-30B [43] (标准多头注意力 MHA), CodeLlama2-34B [36] (分组查询注意力 GQA), Qwen2-72B [46] (分组查询注意力 GQA)。
   • 精度: 所有实验均使用 BF16 (bfloat16) 精度。
   • 张量并行 (Tensor Parallelism, TP) 配置：
     • L20 集群 (32 块 GPU)：
       • Llama-30B 和 CodeLlama2-34B: $\mathrm{TP} = 4$。
       • Qwen2-72B: $\mathrm{TP} = 8$。
     • A800 集群 (16 块 GPU)：
       • Llama-30B 和 CodeLlama2-34B: $\mathrm{TP} = 2$。
       • Qwen2-72B: $\mathrm{TP} = 4$。
   • FuDG 系统实例部署：为了缓解 MoonCake 的带宽限制，每个节点只部署一个实例，L20 集群有 8 个实例，A800 集群 LLaMA-30B 和 CodeLlama2-34B 各有 8 个实例，Qwen2-72B 有 4 个实例。

3. 工作负载设置 (Workload Setup)：

   • 请求率: 使用 泊松分布 (Poisson distribution) 来模拟真实的请求到达模式，对固定的请求率引入微小波动。
   • SLOs: TTFT 和 TPOT 的 SLOs 如表 4 所示，根据应用类型设定，在大多数情况下比现有工作更严格。

5.5. EcoServe 运行时实现

EcoServe 的实现细节：

• 单设备运行时：EcoServe 使用 vLLM 作为单设备运行时。
• 多设备控制：通过 Ray 的 RPC-like 控制机制协调单个实例内的多个设备。
• 实例间同步：宏实例调度器通过 ZeroMQ 促进实例之间的同步。

6. 实验结果与分析

6.1. 端到端性能评估

本节比较了 EcoServe 与四种基线系统在 L20 和 A800 集群上、不同模型和数据集组合下的性能表现。性能主要通过在不同 SLO 达成水平（P50、P90、P99）下的吞吐量（goodput）来衡量。

下图（原文 Figure 8）展示了 EcoServe 与 vLLM、Sarathi、DistServe 及 MoonCake 在不同模型和数据集下P50、P90及P99延迟下的吞吐率对比。

该图像是论文中的图表，展示了随着时间推移，SLO达成率（蓝色点）与请求率（绿色点）之间的变化关系。图中以红色虚线分隔了不同时间段，显示请求率逐步增加且SLO达成率在大部分时间保持较高水平，反映了系统在动态负载下的性能表现。

Figure 8. Overall goodput comparison. EcoServe can meet SLOs for Llama-30B with LongBench.

图 8 解读： 图中横轴代表不同的模型和数据集组合（如Llama-30B/Alpaca, CodeLlama2-34B/ShareGPT等），纵轴代表吞吐量（Goodput）。每个组合下有五组柱状图，分别对应 EcoServe 和四种基线系统 (vLLM, Sarathi, DistServe, MoonCake) 在 P50, P90, P99 SLO 达成率下的表现。

6.1.1. 总体比较 (Overall Comparison)

• EcoServe 表现：在大多数情况下，EcoServe 的性能优于所有基线系统。
  • 相较于 NoDG 系统 (vLLM 和 Sarathi)，EcoServe 在 P90 吞吐量上平均提升了 $83.76\%$ (vLLM) 和 $71.97\%$ (Sarathi)。这归因于 PaDG 策略有效减轻了预填充-解码干扰，并为通过跨实例协作平衡 TTFT 和 TPOT 提供了更大空间。
  • 相较于 FuDG 系统 (DistServe 和 MoonCake)，EcoServe 在 P90 吞吐量上平均提升了 $192.41\%$ (DistServe) 和 $218.22\%$ (MoonCake)。这表明 FuDG 系统在商品化互连环境下因 KV 缓存传输开销和负载不平衡而性能受限。
• NoDG 系统例外：在服务 Alpaca 数据集时，NoDG 系统有时能达到与 EcoServe 相当甚至略优的性能。这是因为 Alpaca 数据集输入长度极短，预填充-解码干扰较小，且 SLOs 已足够宽松，PaDG 提供的额外权衡空间影响不那么显著。
• FuDG 系统问题：尽管 FuDG 系统在处理 KV 缓存较小的模型和输出较长的数据集时可能性能与 NoDG 系统相当或更优，但它们在整体上显著落后于 EcoServe。

6.1.2. 不同 SLO 达成水平下的比较 (Comparison Across SLO Attainment Levels)

• 所有系统在 SLO 达成水平从 P50 提高到 P99 时，吞吐量都会下降。
• EcoServe 优势：EcoServe 在更严格的 SLOs（例如 P90 和 P99）下表现出更高的容忍度。
  • 在 P50 SLO 达成率下，EcoServe 比基线系统高出 $36.49\%$ (vLLM)、$19.82\%$ (Sarathi)、$180.73\%$ (DistServe) 和 $194.62\%$ (MoonCake)。
  • 在 P90 SLO 达成率下，这些提升显著增加到 $83.76\%$、$71.97\%$、$192.41\%$ 和 $218.22\%$。
  • 在 P99 SLO 达成率下，差距进一步扩大，一些基线系统甚至无法满足。这验证了 PaDG 通过实例间协作在平衡 TTFT 和 TPOT 方面提供了更大的灵活性。

6.1.3. 不同模型下的比较 (Comparison Across Models)

• 相较于 NoDG 系统：EcoServe 在服务 Llama-30B、CodeLlama2-34B 和 Qwen2-72B 模型时，P90 SLO 吞吐量平均分别提升了 $65.00\%$、$83.30\%$ 和 $85.30\%$，显示了在不同模型上的持续性能改进。
• 相较于 FuDG 系统：EcoServe 在 P90 SLO 吞吐量下的优势在不同模型间差异显著：
  • Llama-30B: 提升 $507.67\%$。Llama-30B 在 FuDG 系统中性能显著下降，主要是因为其较大的 KV 缓存大小导致传输开销巨大。
  • CodeLlama2-34B: 提升 $125.45\%$。
  • Qwen2-72B: 提升 $83.61\%$。CodeLlama2-34B 和 Qwen2-72B 使用了 GQA 机制，减少了 KV 缓存大小，从而减轻了传输开销。Qwen2-72B 虽然模型更大，但其计算成本与模型大小呈二次方增长，而 KV 缓存相对较小，使其在这种比较中表现更好。

6.1.4. 不同集群下的比较 (Comparison Across Clusters)

• P90 SLO 达成率下：
  • A800 集群：EcoServe 比 NoDG 系统平均提升 $71.41\%$，比 FuDG 系统平均提升 $285.78\%$。
  • L20 集群：EcoServe 比 NoDG 系统平均提升 $84.33\%$，比 FuDG 系统平均提升 $124.86\%$。
• 趋势分析：A800 和 L20 集群在与 NoDG 系统比较时表现出相似的性能趋势。然而，在与 FuDG 系统比较时，A800 集群的性能趋势却不太有利。尽管 A800 集群配备了更高带宽的互连（25Gbps RoCE），但其处理能力也提高了 4 倍以上，使得节点间网络成为更显著的瓶颈。这进一步证实了 FuDG 策略对带宽的敏感性。

6.1.5. 不同应用下的比较 (Comparison Across Applications)

• P90 SLO 达成率下：
  • 相较于 NoDG：EcoServe 在 Alpaca、ShareGPT 和 LongBench 数据集上平均吞吐量分别提升了 $10.44\%$、$20.60\%$ 和 $202.57\%$。
    • 短输入长度（如 Alpaca）减少了预填充-解码干扰和分块预填充中重复 KV 缓存访问，使得 EcoServe 相较于 NoDG 的优势略小。
  • 相较于 FuDG：EcoServe 在这些数据集上分别提升了 $74.80\%$、$363.10\%$ 和 $164.42\%$。
    • LongBench 数据集在 FuDG 上的提升会更高，但由于 Llama-30B 在此数据集上执行失败，其性能被排除。长输入和相对短输出的数据集（如 LongBench）需要更多的预填充实例来生成 KV 缓存，增加了网络传输压力，导致 FuDG 性能更差。

6.2. 扩展能力 (Scaling Capability)

本节评估了 EcoServe 的扩展效率，包括静态粗粒度扩展和动态细粒度扩展。

6.2.1. 静态粗粒度扩展 (Static Coarse-grained Scaling)

• 设置：使用 CodeLlama2-34B 和 Qwen2-72B 模型在 L20 集群上进行测试，CodeLlama2-34B 配置 $\mathrm{TP}=4$，Qwen2-72B 配置 $\mathrm{TP}=2$，工作负载为 ShareGPT 数据集。

• 结果：如图 9 所示，两个模型的服务在 P90 SLO 达成率下均实现了超线性 (superlinear) 提升。例如，CodeLlama2-34B 服务从 1 个实例（4 块 GPU）扩展到 4 个实例（16 块 GPU）时，吞吐量实现了 $5.6 \times$ 的提升。

  下图（原文 Figure 9）展示了静态粗粒度扩展。

  该图像是图表，展示了EcoServe与vLLM在不同TP和PP设置下的吞吐量（Throughput）随TPOT SLO变化的关系。图中以CodeLlama2-34B和ShareGPT L20 P90及P99为测试环境，纵轴为吞吐量，横轴为TPOT SLO（ms），对比了不同并行度配置的性能表现。

Figure 9. Static coarse-grained scaling.

• 图 9 解读：横轴表示实例数量（以及对应的 GPU 数量），纵轴表示 P90 SLO 达成下的吞吐量。蓝线表示 EcoServe 的实际吞吐量，虚线表示理想的线性扩展。
• 超线性提升原因：
  1. 最小管理开销：EcoServe 在管理宏实例内的更多实例时，开销极小。
  2. 对称拓扑：集群中的节点在网络拓扑上是对称的。
  3. 缓解干扰：增加实例数量提供了更多空间来减轻实例间干扰，从而实现更高的算术强度和更好的 GPU 饱和度。
• 退化到 NoDG：如果一个宏实例只包含单个实例，PaDG 策略实际上就退化成了 NoDG 策略，两个阶段将频繁切换并严重干扰。
• 饱和效应：这种超线性扩展效应会在达到足够数量的实例后趋于平稳。

6.2.2. 动态细粒度扩展 (Dynamic Fine-grained Scaling)

• 设置：使用 CodeLlama2-34B 模型在 L20 集群上进行测试，配置 $\mathrm{TP}=4$，工作负载为 ShareGPT 数据集。请求率每 2 分钟逐步增加，从 20 到 50 请求/秒，每 30 秒收集一次 SLO 达成率。超参数设置为 $N_l = 4$ 和 $N_u = 16$。系统从 8 个实例开始，最终使用所有 GPU。

• 结果：如图 10 所示，最初增加请求率会导致 SLO 达成率下降，但随后通过添加新实例得以恢复。

  下图（原文 Figure 10）展示了动态细粒度扩展。

  该图像是论文中的示意图，展示了LLM自回归解码过程，区分了预填充(prefill)和解码(decode)阶段，体现时间维度上的输入输出动态及关键缓存机制。

• 图 10 解读：横轴是时间，左侧纵轴是请求率（绿色虚线），右侧纵轴是 SLO 达成率（蓝色点）。随着请求率的逐步上升，系统会通过添加实例来维持 SLO 达成率。

• 机制：自适应调度算法能够立即将新请求路由到新添加的实例，从而为现有实例处理解码请求留出更多时间。

• 实例迁移：虽然在当前实验中节点数量不足以触发宏实例拆分和实例迁移，但论文强调了可序列化代理对象 (serializable proxy object) 在分裂扩容方法中的作用。该对象确保了迁移过程不会中断实例执行，引入的开销小于 100 毫秒，且可以通过在解码阶段触发迁移来完全隐藏。相比之下，重新初始化 CodeLlama2-34B 可能需要 3 分钟甚至更长。

• 结论：分裂扩容方法能够提供灵活和细粒度的扩展，有效适应动态工作负载需求。

6.3. 并行兼容性 (Parallelism Compatibility)

本节验证了 PaDG 策略在流水线并行 (Pipeline Parallelism, PP) 方面的优势。

• 设置：使用 CodeLlama2-34B 模型、ShareGPT 数据集和 L20 集群。TPOT SLO 从 100 毫秒放宽到 500 毫秒。比较了两种配置：$\mathrm{TP}=2, \mathrm{PP}=2$ 和 $\mathrm{TP}=4, \mathrm{PP}=1$。

• 结果：如图 11 所示，EcoServe 在使用 PP 时，在较低的 TPOT SLO 下比其 TP 对应配置表现更好，并优于 vLLM。

  下图（原文 Figure 11）展示了流水线并行兼容性。

  该图像是图表，展示了EcoServe与vLLM在不同TP和PP设置下的吞吐量（Throughput）随TPOT SLO变化的关系。图中以CodeLlama2-34B和ShareGPT L20 P90及P99为测试环境，纵轴为吞吐量，横轴为TPOT SLO（ms），对比了不同并行度配置的性能表现。

Figure 11. Pipeline parallel compatibility.

• 图 11 解读：横轴表示 TPOT SLO (ms)，纵轴表示吞吐量。蓝线是 EcoServe (TP2 PP2)，橙线是 EcoServe (TP4 PP1)，绿线是 vLLM (TP4)。
• EcoServe (PP) 优势：当 TPOT SLO 增加时，EcoServe (TP2 PP2) 的吞吐量上升，并在较低的 TPOT SLO（约 200-250ms 左右）处开始超过 EcoServe (TP4 PP1) 和 vLLM。
• 原因：PaDG 策略减少了预填充-解码切换的频率，从而改善了流水线并行的效率。这使得 PP 在相对宽松的 TPOT SLO 下能达到更高的吞吐量平台。

7. 总结与思考

7.1. 结论总结

本文提出了 EcoServe，一个旨在实现经济高效 LLM 服务的系统。EcoServe 的核心是一个新颖的部分解耦 (PaDG) 策略，该策略通过结合时间解耦 (temporal disaggregation) 和滚动激活 (rolling activation)，实现了主动的实例内和实例间调度。时间解耦在单个实例内沿时间维度分离预填充和解码阶段，有效减轻了阶段间干扰并提高了吞吐量。滚动激活则通过协调多个实例的预填充周期性激活，确保了预填充处理的持续可用性，从而显著改善了 TTFT。EcoServe 的基本服务单元是协作的宏实例 (macro instance)，并进一步集成了自适应调度算法 (adaptive scheduling algorithm) 来路由请求，以及分裂扩容方法 (mitosis scaling approach) 实现细粒度的容量扩展和灵活的实例迁移。

通过在配备商品化互连的生产级集群上进行广泛评估，EcoServe 在服务 30B 和 70B 规模模型时，相较于代表性的非解耦 (NoDG) 和完全解耦 (FuDG) 系统，平均吞吐量取得了显著提升（最高可达 126.96%）。这证明了 EcoServe 在高吞吐量的同时，在负载均衡、硬件成本、并行兼容性和工程简洁性方面也表现出色，为商品化集群上的 LLM 服务提供了一个成本效益极高的解决方案。

7.2. 局限性与未来工作

论文在“讨论”部分隐性地指出了 EcoServe 的适用场景，这也可以看作是其局限性或与其他策略的权衡：

1. 适用模型规模：EcoServe (PaDG) 最适合服务 30B、70B 和 130B 等中大型模型。对于小型模型（如 7B、13B），NoDG 策略可能就足够了，因为其计算需求较低，预填充-解码干扰可以忽略不计。

2. 极端场景：在超大型模型（如 MoE 模型）或对 SLOs 要求极其严格的场景下，即使微小的干扰也可能导致性能显著下降，此时具有先进硬件（如高性能互连）的 FuDG 策略可能变得至关重要。

3. 工程成本：虽然论文声称 PaDG 的工程复杂度较低，但其分层调度器、自适应调度算法和分裂扩容方法（涉及可序列化代理对象）的实现仍然是复杂的系统工程。

   未来工作方向（论文未明确列出，但可从讨论中推断）：

• 更激进的解耦策略：探索更激进的解耦方法，例如 MegaScale-Infer [52] 提出的将注意力 (attention) 和前馈网络 (FFN) 模块解耦到不同实例中，以进一步优化超大型模型的服务。
• 动态预测的准确性：提高预填充持续时间预测的准确性，以及“节省的 TPOT”的动态评估，以进一步优化自适应调度算法的决策质量，减少潜在的 SLO 违反风险。

7.3. 个人启发与批判

7.3.1. 个人启发

1. 权衡艺术的典范：LLM 服务是一个典型的系统优化问题，在吞吐量、TTFT、TPOT、硬件成本和工程复杂度之间存在多维度的权衡。EcoServe 的 PaDG 策略在 NoDG 和 FuDG 之间找到了一个巧妙的“甜点”，通过在时间维度上解耦，避免了物理资源分离带来的高昂互连成本，同时又缓解了单一资源内阶段干扰，体现了卓越的系统设计智慧。
2. 分层调度与动态调整：分层调度架构（总体-宏实例-实例）提供了清晰的职责划分，而自适应调度算法和分裂扩容方法则赋予了系统强大的动态适应能力。特别是“滚动激活”巧妙地利用了多实例的并行性来弥补单个实例时间解耦可能带来的 TTFT 劣势，这是一种非常优雅的设计。
3. 工程实践价值：在商品化硬件上实现高性能是企业部署 LLM 服务的关键。EcoServe 证明了即使在没有昂贵高性能互连的情况下，也能通过软件层面的创新实现显著的性能提升，这对于降低 LLM 服务的门槛和运营成本具有巨大的实践价值。可序列化代理对象实现灵活实例迁移的设计，也是一个非常实用的工程技巧，有效避免了服务中断。

7.3.2. 批判

1. “工程简洁性”的论证有待加强：论文声称 PaDG 在工程复杂度上与 NoDG 相似，低于 FuDG。然而，EcoServe 引入了分层调度器、宏实例抽象、自适应调度算法（涉及复杂的约束检查和动态预测）、以及分裂扩容方法（包括可序列化代理对象实现实例迁移）。这些机制虽然有效，但其实现和维护绝非“低复杂度”的代名词。相较于一个纯粹的 NoDG 系统（如 vLLM），EcoServe 的系统栈明显更复杂。这部分需要更详细的论证，例如对比实际的代码量、开发/部署/维护的团队规模需求等。
2. 动态预测的鲁棒性：自适应调度算法中的 predict pending_prefills durations (预测待处理预填充请求的持续时间) 和 saved_l_tpot (节省的 TPOT) 计算都依赖于对未来行为的预测（例如预填充时间、输出长度）。如果这些预测不准确（例如由于模型复杂性、可变的工作负载或外部干扰），可能会导致 SLO 违反。论文并未深入探讨这些预测机制的准确性及其对系统鲁棒性的影响。
3. 超线性扩展的边界：论文提到了小规模实例数量下的超线性扩展，并解释了其原因。但这种超线性特性是否会在大规模集群中持续，或者何时开始出现边际效益递减，以及递减的程度如何，这些更详细的分析将有助于理解其在不同规模下的普适性。
4. 商品化互连的极限：虽然 EcoServe 在 10Gbps/25Gbps 以太网上表现优异，但其性能是否能在更高并发和更大模型下持续扩展，或者是否存在一个新的瓶颈（例如，由于宏实例内部的通信或单个实例的瓶颈），值得进一步探究。
5. 比较基线的全面性：虽然选择了四种代表性的 NoDG 和 FuDG 系统，但 LLM 服务领域发展迅速，存在其他混合或更高级的调度/并行策略。与这些更先进的策略进行比较，将更能体现 EcoServe 的相对优势和地位。