1. 论文基本信息

1.1. 标题

RServe: Overlapping Encoding and Prefill for Efficient LMM Inference (RServe：重叠编码与预填充以实现高效的大型多模态模型推理)

1.2. 作者

• Tianyu Guo (郭天宇), Xianjie Chen, Junru Chen, Nong Xiao, Xianwei Zhang - 中山大学计算机学院 (CSE, Sun Yat-sen University)
• Tianming Xu - 小红书 (Rednote)

1.3. 发表期刊/会议

发表于 ArXiv (预印本)。

• 发布时间 (UTC): 2025-09-29
• 注意: 这是一个非常前沿的研究工作，针对的是大型多模态模型（LMM）推理系统的优化。

1.4. 摘要

大型多模态模型 (LMMs) 通常包含一个编码模块 (Encoding Module) 将图像/视频转换为嵌入 (Embeddings)，以及一个语言模型 (Language Model) 进行后续处理。传统的服务引擎将两者部署在一起，导致资源干扰严重。虽然现有的“预填充-解码分离” (Prefill-Decode Disaggregation) 架构缓解了部分问题，但仍未能充分利用请求内 (Intra-request) 和请求间 (Inter-request) 的并行性。

RServe 提出了一种新型推理系统，旨在最大化并行度：

1. 请求内: 通过细粒度调度，在单个请求内部，将多模态数据的编码与语言模型的预填充计算重叠执行。

2. 请求间: 利用“可调度词元” (Schedulable Tokens) 和词元预算机制，在微批次 (Micro-batches) 间平衡计算负载。

   实验表明，RServe 相比现有方法，延迟降低了 66%，吞吐量提升了 109%。

1.5. 原文链接

• 原文链接: https://arxiv.org/abs/2509.24381

• PDF 链接: http://arxiv.org/pdf/2509.24381v1

  ---

2. 整体概括

2.1. 研究背景与动机

• LMM 推理的复杂性: 与纯文本的大语言模型 (LLM) 不同，LMM 需要处理图像、视频等多模态数据。这些数据必须先通过一个计算密集的视觉编码器 (Visual Encoder) 转换为嵌入，才能输入到 LLM 中。
• 现有痛点:

  • 串行阻塞: 传统的推理系统（如 vLLM 的早期版本）通常采用“先编码，后推理”的串行模式。对于包含多张高分辨率图片的请求，编码阶段可能占据高达 26% 的总延迟（如下图所示），此时 GPU 的计算单元在等待数据，造成浪费。

  • 解耦不彻底: 现有的 EPD (Encoder-Prefill-Decode) 架构虽然将编码器剥离到了单独的设备上，但通常仍要求所有图像编码完成后才开始 LLM 的预填充，未能利用流水线并行的潜力。

    下图（原文 Figure 2）展示了随着图像分辨率增加，多模态编码时间在总延迟中的占比显著上升：

    该图像是图2所示的柱状图，展示了单次多模态请求（含两张图像）在张量并行和分块流水线并行配置下，随着图像分辨率增加的总延迟（TTFT）分解。图中$$\mathsf { 4 } \times \mathsf { H } 1 0 0 ^ { \cdot }$$ 表示硬件设置。柱上的百分比数字代表多模态编码时间占总延迟的比例，可以看出随着图像分辨率从1K增至8K，总延迟显著增加，且多模态编码所占比例也随之上升。

2.2. 核心贡献

1. 揭示了被忽视的并行性: 强调了多模态编码与 LLM 前向传播之间的请求内并行 (Intra-request Parallelism) 尚未被充分利用。

2. RServe 系统设计: 提出了 RServe，通过嵌入跟踪器 (Embedding Tracker) 和流式调度，实现了编码与预填充的细粒度重叠。

3. 统一调度策略: 结合了分块预填充 (Chunked Prefill) 和可调度词元机制，同时构建了高效的请求内和请求间流水线。

4. 显著的性能提升: 在 Qwen2.5-VL 系列模型上的实验证明了其在延迟和吞吐量上的双重优势。

   ---

3. 预备知识与相关工作

为了理解 RServe 的核心机制，我们需要掌握以下基础概念。

3.1. 基础概念

• 大型多模态模型 (LMM): 结合了视觉编码器（如 ViT）和大语言模型（如 Qwen, LLaVA）的模型。流程通常是：图像 -> 视觉编码器 -> 图像嵌入 + 文本嵌入 -> LLM -> 输出文本。
• 预填充 (Prefill) 与 解码 (Decode):
  • 预填充: LLM 推理的第一阶段。模型处理输入的所有提示词 (Prompt)，计算其 Key-Value (KV) Cache，并生成第一个输出词元。这是计算密集型 (Compute-bound) 的。
  • 解码: 生成后续词元的阶段。利用之前计算好的 KV Cache，逐个生成词元。这是内存带宽密集型 (Memory-bound) 的。
• 分块预填充 (Chunked Prefill): 为了防止超长提示词的预填充长时间占用 GPU 导致其他请求的解码停滞，系统将长提示词切分成多个小块 (Chunks) 分批次进行预填充。这是 RServe 实现流水线的基础。
• 流水线并行 (Pipeline Parallelism, PP): 将模型的不同层分布在不同的 GPU 上。
• 分块流水线并行 (Chunked Pipeline Parallelism, CPP): 结合上述两者，允许在一个请求内部，当第一块在 GPU 1 处理完传给 GPU 2 时，GPU 1 立即开始处理第二块，从而实现请求内的并行。

3.2. 技术演进与差异化

下图（原文 Figure 3）对比了 LLM 和 LMM 的推理架构差异：

该图像是图3示意图，对比了大型语言模型（LLMs）的预填充-解码（Prefill-decode）分离架构与大型多模态模型（LMMs）的编码器-预填充-解码（Encoder-Prefill-decode, EPD）分离架构。LMMs在Prefill前增加了Encode步骤以处理多模态输入。

• LLM 架构: 主要是 Prefill 和 Decode 的分离。

• LMM 架构 (EPD): 增加了 Encoder。RServe 的核心差异在于，它不再把 Encoder 和 Prefill 看作两个互斥的黑盒，而是让它们像流水线一样交错工作。

  ---

4. 方法论

RServe 的核心目标是打破“编码完成 -> 开始预填充”的硬性依赖，通过细粒度的状态管理实现两者并行。

4.1. 方法原理：细粒度重叠

RServe 基于 EPD (Encoder-Prefill-Decode) 解耦架构。它的核心直觉是：如果一个请求包含 10 张图片，我们不需要等 10 张图片都编码完才开始让 LLM 处理第 1 张图片的嵌入。一旦第 1 张图片的嵌入准备好了，LLM 就可以开始对其进行预填充计算，同时编码器继续处理第 2 张图片。

下图（原文 Figure 7）形象地展示了不同策略的区别：

• Vanilla (PP2): 串行执行，大片空白等待。

• EPD: 分离了设备，但仍然是粗粒度的。

• Ideal Intra-request Parallelism (RServe): 编码 (绿色) 和 预填充 (蓝色) 紧密重叠，显著缩短了总时间。

  该图像是图7，展示了LMM推理中三种不同的并行策略：Vanilla (PP2)、EPD（编码器-预填充分离）和理想的请求内并行。图中通过两个请求（Request 1和Request 2）在时间轴上的多模态编码（MM encoding，绿色）和预填充（Prefill，蓝色）任务调度，比较了这些策略。理想策略通过高效的请求内调度，实现了显著的时间节省，突出了优化并行度的重要性。

4.2. 核心组件详解

4.2.1. 嵌入跟踪器 (Embedding Tracker)

这是 RServe 实现请求内并行的核心数据结构。它负责维护每个请求中数据的状态。

• 分类: 输入嵌入被分为两类：
  • 就绪嵌入 (Ready Embeddings): 文本嵌入（计算极快，视为立即就绪）和已经完成编码的多模态嵌入。
  • 未就绪嵌入 (Not-ready Embeddings): 尚未通过编码器的多模态数据。
• 工作流:

  1. 请求到达，文本嵌入标记为 Ready。

  2. 多模态数据进入编码队列。

  3. 一旦某部分多模态数据编码完成，跟踪器将其状态更新为 Ready，并立即触发 LLM 对这部分数据的预填充。

  4. 预填充完成后，立即释放对应的嵌入以节省显存。

     下图（原文 Figure 9）详细展示了这一过程。注意 Prefill 和 Encode 操作是如何在时间轴上重叠的（例如在处理 MM1 的预填充时，同时在编码 MM2）：

     该图像是图9，展示了嵌入跟踪器中的一系列编码和预填充操作。它通过Case0和Case1两种情况，详细说明了请求中包含的多模态（MM）数据和文本数据嵌入是如何进行处理的。图中绿色方框表示“ready/cached”状态，红色方框表示“unready/released”状态。通过Prefill和Encode的交错执行，该图清晰地描绘了嵌入状态的动态变化，体现了RServe系统对LMM推理管线的并行优化策略。

4.2.2. 编码器调度 (Encoder Scheduling)

为了配合上述逻辑，编码器不能再一次性处理所有图片，也不能极端地一张一张处理（效率低）。

算法逻辑 (基于 Algorithm 1): RServe 采用分批编码 (Batched Encoding) 策略。

1. 维护一个等待队列 $Q$。
2. 创建一个缓冲区 buffer。
3. 遍历请求中的多模态项目，将其加入 buffer。
4. 当 buffer 中的多模态词元数量达到阈值 $C$ (Embedding Batch Size) 时，执行 Encode(buffer)。
5. 这样既保证了编码器的 GPU 利用率（不至于太空闲），又提供了足够细的粒度来触发流水线。

4.2.3. 请求间调度：可调度词元 (Schedulable Tokens)

当系统中有多个请求同时存在时，如何决定先处理谁？RServe 引入了 可调度词元 的概念。

核心定义: 一个词元 $t$ 是“可调度”的，当且仅当：

1. 它的多模态嵌入已经生成（Ready）。
2. 它之前的所有词元都已经完成了预填充，或者也处于可调度状态（保证因果顺序）。

调度算法 (基于 Algorithm 2):

1. 预算检查: 系统维护一个全局词元预算 $B$ (Token Budget，即一次迭代能处理的最大词元数)。

2. 提取词元: 从请求 $r$ 中计算出当前有多少个“可调度词元” $t$。

3. 填充批次:

   • 如果 $t \le B$，将这些词元全部加入当前执行批次，更新 $B \leftarrow B - t$。
   • 如果 $t > B$，仅加入 $B$ 个词元，填满预算。

4. 状态更新: 如果一个请求没有被完全处理完（例如还在等后续图片的编码），它会被标记为“未完成”并放回队列首部，以便在下一轮循环中优先处理。

   下图（原文 Figure 10）展示了结合请求内和请求间流水线的效果。相比仅使用请求内并行（上图），组合策略（下图）能用其他请求的计算填补流水线的气泡 (Bubbles)，从而极大地提高了吞吐量。

   该图像是图10的示意图，比较了RServe系统中“请求内管道”与“请求内和请求间组合管道”的计算调度。它展示了后者如何通过重叠多模态编码和语言模型预填充（包括微批次处理）来显著提高并行度并缩短处理时间。

---

5. 实验设置

5.1. 模型与硬件

• 模型: Qwen2.5-VL 系列 (7B, 32B, 72B)。选择理由是其强大的多模态能力。
• 硬件:
  • 主要平台: 8 $\times$ H100 GPU (NVLink 连接)。
  • 验证平台: 4 $\times$ A100 GPU (PCIe 连接)。
• 架构: 均采用 EPD 解耦架构配置。

5.2. 数据集

• 数据集: MMMU (Massive Multi-discipline Multimodal Understanding)。这是一个涵盖科学、工程、人文等领域的大规模多模态基准测试。

• 输入分布: 包含文本、图像、图表等。如下图（原文 Figure 15）所示，2K 分辨率下的输入长度平均可达 12k 词元，这对推理系统是巨大的考验。

  该图像是图15，一个直方图，展示了MMMU数据集中不同分辨率（1K和2K）下输入长度的分布。1K分辨率（含5k多模态令牌）的输入长度主要集中在8k-9k范围，平均值约为8.5k。而2K分辨率（含9k多模态令牌）则显示出更长的输入长度，主要分布在11k-13k，平均值约为12.5k，表明分辨率越高，输入令牌序列越长。

5.3. 评估指标

1. 首字延迟 (Time to First Token, TTFT):
   • 定义: 从用户发送请求到系统生成第一个响应词元的时间。这是衡量交互系统响应速度的关键指标。
   • 公式: $T_{first\_token} - T_{arrival}$
2. 吞吐量 (Throughput):
   • 定义: 单位时间内系统处理的输入词元数量。
   • 公式: $\frac{\text{Total Input Tokens}}{\text{Total Time}}$
3. SLO 达成率 (SLO Attainment):
   • 定义: 在给定的 TTFT 延迟约束下（例如要求 TTFT < 2秒），成功满足要求的请求所占的比例。

5.4. 对比基线

• vLLM: 业界广泛使用的推理引擎，作为基础基线。

• gLLM: 一个轻量级高效推理框架，本文的实现基础。

• gLLM-epd: 基于 gLLM 实现的 EPD 解耦版本，但没有 RServe 的细粒度重叠调度。

• RServe-intra: 仅启用请求内并行，禁用请求间优化的 RServe 变体（用于消融实验）。

  ---

6. 实验结果与分析

6.1. 延迟 (TTFT) 分析

RServe 在降低延迟方面表现出色，尤其是在不同的请求速率下。

• 分析: 如下图（原文 Figure 12）所示，在对数坐标系下，RServe (绿色线) 始终低于 vLLM 和 gLLM。

  • 低负载时: 优势主要来自请求内并行。多模态编码不再阻塞预填充，利用了“等待编码”的时间窗口。

  • 高负载时: 优势来自请求间并行。RServe 能更灵活地调度碎片化的计算资源。

  • 数据: RServe 相比 gLLM-epd 实现了额外 18% - 19% 的延迟降低。

    该图像是图12，比较了vLLM、gLLM和REDServe三种LMM推理系统的延迟性能。图表以对数坐标系展示了Qwen2.5-VL-72B模型在1K和2K分辨率下，请求速率与首次生成令牌时间（TTFT）的关系。REDServe在所有测试配置下均表现出最低的TTFT，显著优于vLLM和gLLM，证实了其在降低延迟方面的优势。

6.2. 吞吐量分析

• 结果: 如下图（原文 Figure 13）所示，随着请求率增加，系统吞吐量达到饱和。RServe (绿色线) 的峰值吞吐量显著高于其他系统。

• 原因: 传统系统在等待编码时 GPU 处于空闲状态（流水线气泡），而 RServe 通过交错执行填补了这些气泡，最大化了硬件利用率。RServe 达到了约 10600-11100 tokens/s 的吞吐量。

  该图像是图13，展示了vLLM、gLLM和RServe的吞吐量比较。它包含两个子图：(a) Qwen2.5-VL-72B模型在1K分辨率下的吞吐量随请求率的变化，以及(b) 同一模型在2K分辨率下的吞吐量变化。在两个子图中，REDServe（绿色曲线）均表现出最高的吞吐量，尤其是在请求率达到一定阈值后，其性能明显优于gLLM-epd（蓝色曲线）、gLLM（红色虚线）和vLLM（黑色及紫色曲线），证实了REDServe在LMM推理服务中的卓越效率和并行化能力。

6.3. SLO 达成率分析

• 结果: 如下图（原文 Figure 14）所示，RServe 在高负载下仍能保持较高的 SLO 达成率。相比 gLLM-epd，RServe 的 SLO 曲线覆盖面积增加了 23%。这意味着在同样的延迟要求下，RServe 能服务更多的并发用户。

  该图像是图14，展示了gLLM和REDServe在不同请求速率下的服务水平目标（SLO）达成率对比。两幅图分别在1K和2K分辨率下，比较了两种系统。结果显示，REDServe在两种分辨率下均表现出更高的SLO达成率，尤其在高请求速率下优势更明显，表明其卓越的性能。

6.4. 功能性验证 (MMMU Benchmark)

为了证明优化的调度策略没有牺牲模型精度，作者在 MMMU 数据集上进行了测试。

以下是原文 Table 1 的结果：

• 结论: 分数波动极小（< 0.5%），证明 RServe 保持了完全的功能正确性。

6.5. 消融实验：嵌入批处理大小 (Embedding Batch Size)

• 分析: 如下图（原文 Figure 16）所示，对于高质量（编码慢）的多模态数据，较小的批处理大小更有利（图左侧），因为它可以更快地触发预填充重叠。如果批次太大（图右侧 gLLM-epd 对应的情况），重叠机会减少，TTFT 会升高。这验证了 RServe 细粒度调度的必要性。

  该图像是图表，展示了图16中不同嵌入批处理大小对RServe系统性能的影响，包括吞吐量（Throughput）和首个 token 延迟（TTFT）。图(a)为高质量多模态数据（1024 toks/MM item），图(b)为低质量多模态数据（32 toks/MM item）。结果显示，在两种数据质量下，RServe在多数嵌入批处理大小下均能保持较高的吞吐量和较低的TTFT。最右侧的"gLLM-epd"代表所有多模态数据编码完成后才执行预填充操作，其TTFT显著高于RServe，尤其是在高质量数据场景下。

---

7. 总结与思考

7.1. 结论总结

本文提出了 RServe，一个针对大型多模态模型 (LMM) 的高效推理服务系统。

1. 问题: 指出了传统 LMM 服务中，多模态编码与 LLM 预填充之间存在严重的资源干扰和时序阻塞。
2. 方法: 通过嵌入跟踪器和流式调度，打破了编码与预填充的硬性边界，实现了请求内的细粒度重叠。同时，通过可调度词元机制，实现了高效的请求间负载均衡。
3. 效果: 实验证明，RServe 能够显著降低首字延迟 (TTFT) 并大幅提升吞吐量，且不损失模型精度。

7.2. 局限性与未来工作

• 网络带宽依赖: EPD 架构依赖于节点间的高速通信。虽然本文使用了 NVLink，但在低带宽环境下（如普通的以太网连接），传输嵌入的开销可能会抵消并行带来的收益。
• 调度复杂性: RServe 需要精细地管理每个请求的状态和显存释放，这增加了系统的工程复杂性。
• 适用范围: 目前主要针对 Transformer 类架构的 LMM，对于未来可能出现的新型架构（如 SSMs）可能需要重新设计调度策略。

7.3. 个人启发与批判

• 流式思想的胜利: RServe 本质上是将“批处理 (Batch Processing)”思维转变为“流处理 (Stream Processing)”思维。在传统思维中，编码是一个原子操作；在 RServe 中，编码变成了数据流。这种思想在处理长序列、多模态数据时非常具有借鉴意义。
• 硬件利用率的极致追求: 这篇论文再次证明，AI 系统优化的核心往往不在于模型本身，而在于如何消除流水线中的“气泡 (Bubbles)”。任何让 GPU 等待数据的时刻都是优化的机会。
• 通用性: 虽然本文针对 LMM，但这种“部分依赖就绪即执行”的细粒度调度思想，完全可以迁移到其他具有复杂依赖链的计算任务中，例如复杂的 Agent 工作流或链式推理 (Chain-of-Thought) 系统。