1. 论文基本信息

1.1. 标题

Distributed LLM Serving on Consumer-Grade GPUs by Reconciling Computation and Communication (通过协调计算与通信在消费级 GPU 上提供分布式大型语言模型服务)

1.2. 作者

Lewei Jin, Kui Zhang, Yongqi Chen, Yifan Zhuo, Renjie Li, Yi Gao, Bowei Yang, Zhengong Cai, Wei Dong，浙江大学 (Zhejiang University)

1.3. 发表期刊/会议

论文发布日期为 2025-01-01T00:00:00.000Z，根据其未来的发布时间戳，这可能是一篇尚未正式发表的预印本 (preprint) 或正在审稿中的论文。鉴于其研究内容前沿且涉及系统实现，很可能目标是计算机系统或人工智能领域的顶级会议或期刊。

1.4. 发表年份

2025年

1.5. 摘要

大型语言模型 (LLM) 正在重塑互联网服务。但服务这些模型通常成本高昂，需要多张高端 GPU。消费级 GPU 提供了更便宜的计算能力，为更具成本效益的 LLM 服务提供了机会。先前的研究致力于大规模分布式服务，主要集中在模型部署策略上。然而，由于推理的两个阶段——预填充 (prefill) 和 解码 (decode)——之间数据传输量的不平衡，通信效率已成为一个挑战。预填充请求的数据传输量可能是 解码 请求的 1000 倍，这导致 解码 请求被延迟。结果是，服务器在等待 解码 请求时利用率不足。本文提出了 MoLink，一个高效的分布式 LLM 服务系统。它将 预填充 请求的长时间传输量拆分成更小的 分块 (chunks)，并仔细调度它们的传输。MoLink 包含两个部分：(i) 一个传输调度算法，公平地决定是传输 预填充 还是 解码 请求，以及 (ii) 一个分块确定算法，实时 (just-in-time) 确定 预填充 请求的传输量。我们的评估表明，与最先进的 (state-of-the-art) 分布式 LLM 服务系统相比，MoLink 显著降低了 首词元生成时间 (TTFT)、每输出词元时间 (TPOT) 和延迟 (latency)，最大降幅高达 46%。

1.6. 原文链接

/files/papers/6914a1e059f6bf3b040db300/paper.pdf (发布状态：未知，根据日期可能是预印本)

2. 整体概括

2.1. 研究背景与动机

大型语言模型 (LLM) 的兴起彻底改变了人工智能领域，从搜索引擎到个人助理等互联网服务都受到了深刻影响。然而，部署和提供这些 LLM 服务面临着巨大的挑战，其中最主要的是高昂的成本。大型 LLM，例如 OPT-175B，需要超过 350GB 的加速器内存才能进行推理，这意味着即便是最基本的推理也需要集群中多张高端 GPU 的支持。

本文的动机在于发现了成本优化的巨大潜力：消费级 GPU。与高端 GPU 相比，消费级 GPU 提供了更经济的计算能力。例如，RTX 4090 在 FP16 精度下能提供 330 TFLOPS，与 A100 的 312 TFLOPS 相近，但云市场的小时租用价格却低了 4 倍多。全球范围内有大量消费级 GPU 处于未充分利用状态，这为实现更具成本效益的 LLM 服务提供了绝佳机会。

现有的分布式计算研究，例如 Folding@Home、Petals、HexGen 和 Helix，已经探索了大规模分布式部署，但它们主要关注模型部署策略、容错性或请求调度。这些工作在如何将模型高效地放置在分布式环境中以及如何调度到达的请求方面取得了进展。

然而，本文指出，在这些分布式 LLM 服务系统中存在一个关键的未解决问题：通信效率，尤其是在带宽受限的环境中。挑战源于 LLM 推理的两个主要阶段——预填充 (prefill) 和 解码 (decode)——之间数据传输量的高度不平衡。预填充 请求（处理输入提示）可能涉及比 解码 请求（生成下一个词元）多达 1000 倍的数据传输量。这种差异导致了严重的传输竞争 (transmission competition)：当一个大型 预填充 请求正在传输数据时，即使只需要几毫秒的传输时间，小型 解码 请求也可能被阻塞并延迟长达一秒。这种阻塞导致服务器在等待 解码 数据传输完成时处于未充分利用 (underutilized) 状态。

因此，本文旨在解决这一通信效率瓶颈，特别是在利用消费级 GPU 进行分布式 LLM 服务时，如何有效管理 预填充 和 解码 阶段之间的传输竞争。

2.2. 核心贡献/主要发现

MoLink 系统的核心贡献和主要发现如下：

1. 识别性能瓶颈： 论文首次明确指出并深入分析了分布式 LLM 服务在带宽受限环境下，由 预填充 和 解码 请求之间的数据传输竞争所导致的性能瓶颈。
2. 提出新型传输调度策略： 引入了一种新颖的传输调度策略——分块传输 (chunk transmission)。该策略通过将大型的 预填充 传输量拆分成更小的 分块，并精心调度这些 分块 的传输，从而有效缓解了传输竞争。
3. 设计高效分布式 LLM 服务系统 MoLink：
   • 传输调度算法： 开发了一个加权优先级传输调度算法，公平地决定何时传输 预填充 请求或 解码 请求，并保证 预填充 请求不会发生饥饿 (starvation)。
   • 实时分块确定算法： 提出一个自适应的实时分块确定算法，动态计算 预填充 请求的传输 分块 大小，以避免长时间阻塞 解码 请求。
   • 优化微批次数量： 提出扩展微批次数量以更好地利用 GPU，通过重叠传输与计算来减少流水线气泡 (pipeline bubbles)。
4. 显著的性能提升： 实验评估表明，与最先进的分布式 LLM 服务系统相比，MoLink 在 首词元生成时间 (TTFT)、每输出词元时间 (TPOT) 和端到端延迟 (latency) 上实现了显著降低，最大降幅高达 46%。这证明了 MoLink 在提高消费级 GPU 分布式 LLM 服务效率方面的有效性。

3. 预备知识与相关工作

3.1. 基础概念

为了理解 MoLink 的工作原理，需要首先了解 LLM 推理过程、分布式 LLM 服务的基本概念以及相关的性能指标。

3.1.1. 大型语言模型 (LLM) 推理

• 大型语言模型 (LLM, Large Language Model)：指参数量庞大（通常达数十亿甚至千亿）的深度学习模型，能够理解和生成人类语言。它们通常基于 Transformer 架构。
• 推理 (Inference)：指使用训练好的 LLM 对输入进行预测或生成输出的过程。
• 预填充 (Prefill) 阶段：当一个新请求（包含一个输入提示，即 prompt）到达时，LLM 需要并行处理提示中的所有词元 (token)，计算它们的隐藏表示 (hidden representation)。这个阶段涉及的词元数量通常较多，计算量和数据传输量较大。
• 解码 (Decode) 阶段：在 预填充 阶段完成后，LLM 进入 解码 阶段，逐个生成输出词元。每一步 解码 都只处理一个新生成的词元，并基于之前的输出和输入提示来预测下一个词元。这个阶段的计算量和数据传输量相对较小。

3.1.2. 分布式 LLM 服务

由于 LLM 模型规模巨大，单个 GPU 往往无法存储整个模型或处理大量请求。因此，需要将模型或请求分布到多个 GPU 上进行处理。

• 模型并行 (Model Parallelism)：将模型的不同部分部署到不同的 GPU 上。
  • 张量并行 (TP, Tensor Parallelism)：将每个操作符（如矩阵乘法）的权重（张量）在不同 GPU 之间进行分区。这通常涉及频繁的 all-reduce 通信，对网络带宽和延迟非常敏感。
  • 流水线并行 (PP, Pipeline Parallelism)：将模型的不同层分配给不同的 GPU，形成一个计算流水线。输入数据被分成多个微批次 (micro-batches)，这些微批次依次通过流水线中的每个 GPU。在 PP 中，激活张量 (activation tensor)（即中间计算结果）作为数据在不同服务器之间传输。
• 分布式集群 (Distributed Cluster)：由多台连接在一起的服务器组成，每台服务器通常配备一个或多个 GPU。
• 带宽受限环境 (Bandwidth-Constrained Environments)：指网络传输速率较低的环境，例如消费级 GPU 集群中常见的 100 Mbps 以太网连接，这使得数据传输成为瓶制性能的因素。

3.1.3. 性能指标

• 首词元生成时间 (TTFT, Time to First Token)：衡量从接收到用户请求到生成第一个输出词元所需的时间。它主要反映了 预填充 阶段的效率。
  • 概念定义： TTFT 旨在量化用户从发出请求到看到模型开始响应的等待时间。对于交互式应用，这是一个非常关键的用户体验指标，因为它直接影响用户的感知响应速度。一个较低的 TTFT 意味着用户可以更快地看到模型的初步反馈。
  • 数学公式： 通常是直接测量的时间，没有通用公式。
  • 符号解释： 无。
• 每输出词元时间 (TPOT, Time per Output Token)：衡量生成每个后续输出词元的平均时间。它主要反映了 解码 阶段的效率。
  • 概念定义： TPOT 衡量模型在生成第一个词元后，继续生成后续词元的平均速度。它反映了模型在连续生成文本时的吞吐量。一个较低的 TPOT 意味着模型可以更快地完成整个响应，特别是对于需要生成长文本的请求。
  • 数学公式： 通常是直接测量的时间，没有通用公式。
  • 符号解释： 无。
• 延迟 (Latency)：指从发送请求到接收到所有输出所需的时间。通常指端到端延迟。
  • 概念定义： 端到端延迟是指从用户发出请求开始，到模型生成并返回所有响应词元为止的总时间。它是衡量整个系统响应速度的综合指标。
  • 数学公式： 通常是直接测量的时间，没有通用公式。
  • 符号解释： 无。
• 微批次 (Micro-batch)：在 流水线并行 中，为了提高 GPU 利用率并减少 流水线气泡 (pipeline bubbles)，通常将一个大批次 (mini-batch) 的数据进一步划分为更小的 微批次，使其可以更细粒度地在流水线中流动。
• 流水线气泡 (Pipeline Bubbles)：在 流水线并行 中，由于不同阶段计算时间不平衡或数据传输延迟，会导致某些 GPU 暂时空闲，等待前一个或后一个阶段完成。这种空闲时间被称为 流水线气泡，会降低整体 GPU 利用率和系统吞吐量。

3.2. 前人工作

分布式 LLM 服务领域已经有很多研究，主要可以分为以下几类：

• 模型部署与资源管理：

  • Folding@Home [22] 等项目展示了利用大量分布式 GPU 进行科学计算的潜力，其调度重点在于任务分发和结果汇总。
  • Petals [4] 专注于在不稳定的去中心化服务器上提供 LLM 服务时的容错性 (fault-tolerance) 和模型部署策略，但它在固定设备组上的优化机会较少。
  • HexGen [10] 优化了 LLM 在去中心化环境中的部署。
  • Helix [14] 在异构集群下探索了 LLM 的最优部署和请求调度，旨在最大化吞吐量。它采用顺序发送 预填充 或 解码 数据到 ZeroMQ 消息队列，由 ZeroMQ 异步发送。
  • SkyPilot [27] 和 Mélange [6] 关注于为请求选择最佳 GPU 类型。
  • 这些工作更多地从宏观层面管理资源和调度任务，但在细粒度通信层面对 预填充 和 解码 阶段的差异处理不足。

• LLM 特定服务优化：

  • Orca [28] 提出了迭代级别的调度，一旦请求完成就释放资源。
  • vLLM [12] 引入了 PageAttention 机制，通过精确分配请求所需的页面来减少内存消耗，从而提高吞吐量。vLLM 使用异步套接字发送 预填充 或 解码 数据。
  • 推测推理 (Speculative Inference) [13, 15] 利用小型模型预测多个输出词元，以加速生成过程。
  • Splitwise [18] 和 DistServe [29] 尝试将 预填充 和 解码 阶段的请求进行解耦处理。
  • Sarathi [1] 引入了 分块预填充 (chunked prefill) 的概念，为 预填充 阶段分配预算，但这并未优化 预填充 请求的传输方式（即将传输量本身分块）。
  • 这些系统侧重于内存优化、计算加速或阶段管理，但大多未能有效解决 预填充 和 解码 传输数据量差异带来的通信竞争问题。

• 分布式 ML 任务的通用优化：

  • 一些工作 [9, 17] 共同设计了模型分区和在异构集群上的放置。
  • Learninghome [21] 和 DeDLOC [5] 研究了去中心化集群中的网络感知路由。
  • SWARM [20] 优化了异构网络中的流水线通信。
  • 还有一些工作 [26, 7] 使用近似方法来减少网络通信或同步需求。
  • 这些工作提供了分布式系统优化的通用思路，但没有专门针对 LLM 预填充 和 解码 阶段的通信特征进行深度优化。

3.3. 技术演进

LLM 服务的技术演进大致经历了从单机单卡到单机多卡，再到分布式集群的阶段。早期分布式 LLM 服务的重点在于如何将大型模型分布到多张 GPU 上（如 模型并行），并进行高效的任务调度。随着模型规模的进一步扩大和用户请求量的增加，人们开始关注如何提高 LLM 服务的吞吐量和降低延迟，这催生了 vLLM 等在内存和计算效率上进行优化的系统。

本文的工作代表了 LLM 服务优化的一个新方向：从关注计算和模型部署转向关注通信效率。尤其是在利用成本更低的消费级 GPU 构建分布式系统时，网络带宽往往成为新的瓶颈。因此，如何在这种带宽受限的环境下，优化 预填充 和 解码 阶段之间传输量巨大差异所带来的通信竞争，成为了当前技术演进中的一个关键挑战。MoLink 正是试图填补这一空白。

3.4. 差异化分析

MoLink 与上述相关工作的主要区别和创新点在于：

• 聚焦通信竞争： 现有工作大多关注模型部署、计算优化或请求调度，但 MoLink 明确识别并专注于解决 预填充 和 解码 阶段之间数据传输量极度不平衡所导致的传输竞争问题。这是其与众不同的核心切入点。

• 分块传输 策略： 针对 预填充 传输量大的特点，MoLink 提出将其分块进行传输，并通过智能调度来保证 解码 请求的优先级，这是对传统异步或顺序传输机制的重大改进。

  • vLLM 和 Helix 虽然也进行异步传输，但它们没有 分块 机制，也没有对 预填充 和 解码 请求进行细粒度的传输优先级调度，导致 解码 请求仍可能被大型 预填充 请求阻塞。
  • Sarathi 提出了 分块预填充，但它是在计算层面进行预算分配，而非在网络传输层面进行分块和调度。MoLink 的创新在于将这种思想应用于网络传输。

• 自适应实时分块确定： MoLink 的 分块 策略不是静态的，而是通过一个实时 (just-in-time) 算法，根据当前系统状态（如 解码 请求的执行时间）动态确定 分块 大小，从而实现更精细的控制和更高的效率。

• 优化微批次数量： 虽然其他系统也使用 微批次，但 MoLink 强调在带宽受限下，通过扩展 微批次 数量来更好地重叠传输和计算，减少 流水线气泡，这与传统上将 微批次 数量设为 流水线并行 度数相等的做法不同，更适应于高通信开销的环境。

  综上所述，MoLink 的创新在于其对分布式 LLM 服务中通信瓶颈的深刻理解和针对性的解决方案，特别是在消费级 GPU 这种带宽受限的场景下，通过细粒度的传输管理和智能调度，实现了计算与通信的有效协调。

4. 方法论

4.1. 方法原理

MoLink 的核心思想是通过协调 预填充 (prefill) 和 解码 (decode) 阶段的计算与通信，解决在分布式 LLM 服务中，由两者之间数据传输量巨大差异导致的性能瓶颈。具体来说，它针对 预填充 请求传输量大、耗时长的特点，将其分解为更小的分块 (chunks) 进行传输。同时，MoLink 设计了一套智能调度机制，确保 解码 请求的传输能够及时进行，避免被 预填充 请求长时间阻塞。这样做的目标是最大化系统吞吐量，同时保证 预填充 请求不会被无限期地饥饿 (starvation)，并且通过增加 微批次 (micro-batch) 数量来减少 流水线气泡 (pipeline bubbles)，提高 GPU 利用率。

4.2. 核心方法详解 (逐层深入)

4.2.1. 架构

MoLink 旨在作为一种在分布式消费级 GPU 上服务大型语言模型 (LLM) 的平台。

下图（原文 Figure 4）展示了 MoLink 的架构。它采用流水线并行 (pipeline parallelism) 策略，将模型的不同层部署在不同的工作节点 (workers) 上。这意味着模型的计算任务被划分为多个阶段，每个阶段在一个 worker 上执行。

该图像是一个示意图，展示了在MoLink系统中，多个k8s pod和WSL VM之间的微批处理过程。图中表示了模型层之间的数据传输、网络连接及微批次调度的过程，突出了分布式LLM服务的结构与调度算法。

图 4: MoLink 的架构。模型层的不同部分以流水线并行策略部署在工作节点上。它支持访问 Linux 服务器和 Windows PC。

MoLink 的设计特点是支持异构平台，即同时支持 Windows PC 和 Linux 服务器。对于 Linux 服务器，它利用 Kubernetes 来管理 Docker 容器，实现资源的有效编排和部署。对于 Windows PC 和其他容器化环境（如 AutoDL），MoLink 实现了轻量级的 Kubernetes 类似功能来管理资源和部署，降低了在消费级硬件上部署的复杂性。

除了基本的流水线并行架构，MoLink 通过以下两个主要机制进一步提升性能：

1. 传输调度 (Transmission Scheduling)：管理 预填充 和 解码 请求的传输（详见第 4.2.2 节）。
2. 扩展微批次数量 (Extending the number of micro-batches)：优化 微批次 的数量以更好地利用 GPU（详见第 4.2.3 节）。

4.2.2. 传输调度 (Transmission Scheduling)

为了缓解 预填充 和 解码 请求之间的传输竞争，MoLink 的解决方案是将 预填充 请求的长时间激活传输量分块，并在传输时避免占用 解码 请求所需的带宽。这个设计目标是最大化服务系统的吞吐量，同时确保 预填充 请求的激活传输不会在极端情况下发生饥饿 (starvation)。

4.2.2.1. 加权优先级传输调度 (Weighted-priority transmission scheduling)

算法 1 描述了 MoLink 的传输调度策略。

1Initialize volume queue vq1, vq2 ← ∅
2Initialize waiting weight W = 0
3: Initialize max waiting weight N = 30
4: While True do
5: While v_new = get_next_volume() do
6: if v_new in phase.decode:
7: add v_new to vq1
8: else
9: add v_new to vq2
10: if vq1 ≠ ∅ and vq2 ≠ ∅
11: W = W + 1
12: if vq1 ≠ ∅ and W < N
13: send(vq1[0])
14: pop(vq1)
15: elif vq2 ≠ ∅
16: if W >= N
17: v_t = vq2[0].left
18: else
19: v_t = chunk(vq2[0].left)
20: vq2[0].left = vq2[0].left - v_t
21: if vq2[0].left == 0
22: pop(vq2)
23: send(vt)
24: W = 0

• 队列管理：系统不断检查是否有请求在服务器上完成计算并产生待传输的数据量 (volume)。这些数据量根据请求的阶段被分为两类队列：
  • vq1：用于 解码 阶段请求的传输队列。
  • vq2：用于 预填充 阶段请求的传输队列。
• 优先级策略：MoLink 优先传输 解码 请求的激活。因此，即使存在需要传输的 预填充 请求，系统也会优先选择传输 解码 请求（算法第 12-14 行）。
• 防止饥饿 (starvation)：为了保证 预填充 请求的传输不会被饥饿，引入了一个等待权重 (waiting weight) $W$ 和一个最大等待权重 (max waiting weight) $N$（初始化为 30）。
  • 当 vq1 和 vq2 均非空，且 解码 请求被优先传输时，$W$ 会加 1（算法第 10-11 行）。
  • 只有当 $W$ 超过阈值 $N$，或者 vq1 中没有 解码 请求时，系统才会开始计算并传输 预填充 请求的数据量（算法第 15-23 行）。
  • 预填充 请求传输完成后，$W$ 会被重置为 0（算法第 24 行）。
• 分块传输：对于 预填充 请求，MoLink 不会一次性传输全部数据。如果 $W < N$，它会调用 chunk() 函数来确定一个较小的传输 分块 大小 $v_t$（算法第 19 行）。如果 $W \geq N$，则传输剩余的全部数据（算法第 17 行），从而防止饥饿。传输后，vq2[0].left（剩余传输量）会相应减少。

4.2.2.2. 实时分块确定 (Just-in-time chunk determination)

MoLink 提出一个自适应的实时分块确定算法 (adaptive chunking determination algorithm)，用于在传输即将开始时，动态决定 预填充 激活的 分块 大小。目标是预测 分块 传输可用的时间间隔。

为了解决这个问题，我们定义了以下变量： 表 1: 变量符号。

由于可用时间间隔 $T_a$ 取决于 解码 请求的传输，算法通过三种情况来计算 分块 量。下图（原文 Figure 5）展示了 分块 量确定的过程。

该图像是一个示意图，显示了在不同服务器上处理预填和解码请求的时间安排。图中展示了三个服务器在处理请求时的情况，标记了时间点 $t_c$ 和 $t_s$，并列出了三种不同的情况（案例1、案例2、案例3），说明了请求的到达和处理时间的关系。

图 5: 确定 分块 的大小。$T_a$ 表示 分块 传输的持续时间。$T_a$ 的计算有三种情况，这取决于 $t_c$ 和 $t_s$ 之间的关系。$t_c$ 表示传输的开始时间，$t_s$ 表示当前（或下一个）解码 执行的开始时间（$dec*$ 表示第一个批次）。

我们的目标是预测可用时间 $T_a$，其一般计算公式为：

T _ { a } = t _ { s } + T _ { d } - t _ { c }

其中 $T_d$ 表示当前（或下一个）解码 执行的持续时间。

情况 1：传输开始时间 $t_c$ 等于当前执行开始时间 $t_s$。

• 发生场景：这通常发生在 预填充 请求的第一个 分块 传输，此时 预填充 传输与随后的 解码 批次执行同时开始。
• 计算：在这种情况下，解码 执行的完成时间 $t_f$ 可以计算为 $t_f = t_s + T_d$。由于 $t_c = t_s$，因此可用时间间隔 $T_a$ 可以计算为：

T _ { a } = t _ { f } - t _ { c } = T _ { d }

`解码` 批次的执行时间 $T_d(x)$ 主要取决于处理的词元数量 $x$，这个函数是通过在真实系统上分析数据获得的。

情况 2：传输开始时间 $t_c$ 晚于当前执行开始时间 $t_s$。

• 发生场景：当一个 分块 传输（例如来自 预填充 阶段）在多个串行 解码 批次中的一个完成后才开始时。此时系统已经在执行一个 解码 批次。
• 计算：与情况 1 类似，$t_f = t_s + T_d$。然而，由于 $t_c > t_s$，可用时间间隔 $T_a$ 会缩短，计算为：

T _ { a } = t _ { f } - t _ { c } = T _ { d } + t _ { s } - t _ { c }

这个值通常比情况 1 小，因为传输开始得晚。

情况 3：传输开始时间 $t_c$ 早于当前执行开始时间 $t_s$。

• 发生场景：当一个 分块 传输（例如来自 预填充 阶段）在序列中最后一个 解码 批次执行完成后才开始时。此时系统中没有正在执行的 解码 批次。
• 计算：在这种情况下，需要考虑下一个 解码 执行的完成时间 $t_f$，它将发生在系统的下一个迭代中。由于 LLM 具有自回归特性，可以根据前一个迭代的执行轨迹来预测下一个迭代的执行。假设 $\{ B_1, B_2, \ldots, B_N \}$ 是最新迭代中 解码 批次的序列。批次 $B_1$ 预计将是下一个执行的批次（如 Figure 5 中的 $dec*$ 所示）。因此，我们关注 $B_1$ 下一个执行的开始时间（即到达时间）$t_s$。 我们需要对 $B_1$ 完成其在服务器间迭代所需的传输开销 $T_m$ 和计算开销 $T_o$ 进行建模。
  • 计算开销 $T_o$： $$T _ { o } = \sum _ { i = 1 } ^ { M } T _ { d _ { i } } ( n )$$ 其中 $T_{d_i}(n)$ 表示在服务器 $i$ 上处理 $n$ 个词元的执行时间，该函数从每个服务器的分析数据中获得。$M$ 是流水线并行度（即服务器数量）。
  • 传输开销 $T_m$： $$T _ { m } = \sum _ { i = 1 } ^ { M } \mathrm { L a t } _ { i } + \sum _ { i = 1 } ^ { M - 1 } \frac { \mathrm { a c t } _ { - } \mathrm { s z } \times n } { \mathrm { B and } _ { i } } + \frac { \mathrm { t ok } _ { - } \mathrm { s z } \times n } { \mathrm { B and } _ { M } }$$ 其中：
    • $M$ 是流水线并行度（服务器数量）。
    • $\mathrm { L a t } _ { i }$ 是服务器 $i$ 和服务器 $i+1$ 之间的延迟（对于 $i \le M-1$），以及服务器 $M$ 和服务器 1 之间的延迟（当 $i=M$ 时，即环形拓扑）。
    • $\mathrm { B and } _ { i }$ 表示相应的带宽。
    • $n$ 是此批次中处理的词元数量。
    • $\mathrm { a c t } _ { - } \mathrm { s z }$ 是激活张量的大小（例如，LLaMa-30B 为 13312B）。
    • $\mathrm { t ok } _ { - } \mathrm { s z }$ 是词元的大小（例如，LLaMa-30B 为 2B）。
  • 估计完成时间 $t_f$：下一个 解码 执行的估计完成时间为：

t _ { f } = t _ { p } + T _ { o } + T _ { m }

    其中 $t_p$ 表示最新迭代中第一个 `解码` 批次完成的时间。
*   **可用时间间隔 $T_a$**：

T _ { a } = t _ { f } - t _ { c } = t _ { p } + T _ { o } + T _ { m } - t _ { c }

    这个值通常比情况 1 大，因为下一个 `解码` 执行的开始时间被延迟了。

通过预测 $T_a$，MoLink 可以计算出在此时间段内可以传输的 预填充 分块 大小，从而实现 预填充 和 解码 传输的有效协调。

4.2.3. 扩展微批次数量 (Extending the number of micro-batches)

为了充分利用 GPU，现有系统通常将微批次 (micro-batch) 的数量设置为与流水线并行度 (pipeline degree) 相等 [12, 28]。这种做法基于一个假设：服务器之间的传输开销可以忽略不计，因为激活数据量相对较小。然而，在服务器通过有限带宽连接的情况下（例如消费级 GPU 集群），激活数据的传输开销会显著增加。这可能导致流水线气泡 (pipeline bubbles) 的出现，从而降低系统的整体效率。

下图（原文 Figure 6a）展示了一个当 微批次 数量等于 流水线并行 度数时的例子。

该图像是一个示意图，展示了在分布式 LLM 服务中，两个服务器（server1 和 server2）在不同时间点上处理请求 B1 和 B2 的调度情况。图中同时展示了网络传输的时间，反映了预填充请求与解码请求的调度策略。

图 6: 微批次数量在流水线中的影响。（a）微批次数量等于流水线并行度。（b）微批次数量大于流水线并行度。

我们可以看到，中间激活的传输过程需要时间，并延迟了目标服务器中 微批次（如 B1 和 B2）的执行。结果是，当完成其中一个 微批次（如 B2）时，服务器会空闲，因为另一个 微批次（如 B1）的到达总是被延迟。这种服务器未充分利用的情况在 微批次 数量等于 流水线并行 度数时自然存在，因为没有更多的 微批次 可以在服务器空闲期间填充进来。

为了解决这个问题，MoLink 将 微批次 的数量扩展到大于 流水线并行 度数。下图（原文 Figure 6b）展示了一个例子。通过增加一个新的 微批次（如 B3），使其在 B2 之后顺序执行，我们可以看到 B1 的传输时间被 B3 的执行所重叠 (overlapped)。因此，这减少了服务器的空闲时间。

最佳 微批次 数量会根据硬件和网络条件而有所不同。由于 微批次 数量的搜索空间有限，MoLink 在 $N$ 到 2N（其中 $N$ 表示 流水线并行 度数）之间模拟不同数量的 微批次，以找到一个最优值。

5. 实验设置

5.1. 数据集

实验使用了 Azure Conversation [2] trace 来模拟请求的到达。这是一个典型的 LLM 推理调用 trace，包含了输入和输出词元。

• 输入输出长度分布：下图（原文 Figure 7）展示了数据集的输入和输出长度分布。

  该图像是一个直方图，展示了输入长度（蓝色）和输出长度（红色）的比例分布。横轴表示长度，纵轴表示比例，数据包括长度为0到2000的范围。该图反映了输入与输出长度的差异情况。

  图 7: 输入和输出长度的分布。

  从图中可以看出，输入长度（蓝色）主要集中在 0-500 词元之间，但也有一部分长达 2000 词元。输出长度（红色）则主要集中在 0-500 词元之间。这种分布反映了实际 LLM 使用中，用户提示长度多变且输出也存在长短不一的情况。为了适应实验设置，论文移除了输入长度大于 2048 或输出长度大于 1024 的请求。

• 到达率：下图（原文 Figure 8）展示了数据集的到达率。

  该图像是一个示意图，展示了在时间（秒）上到达率（请求/秒）的变化情况。图中显示到达率在0到20之间波动，具有明显的高峰和低谷，反映了请求流量的动态特性。

  图 8: 到达率。

  到达率（请求/秒）随时间波动，呈现出周期性的高峰和低谷，这模拟了实际服务中请求流量的动态性。论文根据所用 GPU 的数量，对请求到达频率进行了缩放。

实验中，集群会进行 1 分钟的预热 (warm-up)，然后进行 30 分钟的测试。

5.2. 评估指标

论文使用了以下三个关键指标来衡量 LLM 服务的性能：

1. 首词元生成时间 (TTFT, Time to First Token)

   • 概念定义： TTFT 衡量的是从用户请求发送到服务器接收到并返回第一个输出词元所需的时间。这个指标对于衡量 LLM 服务交互性至关重要，因为它直接影响用户的感知响应速度。较低的 TTFT 意味着用户会更快地看到模型的初步反馈。
   • 数学公式： TTFT = T_first_token_received - T_request_sent
   • 符号解释：
     • T_first_token_received：接收到第一个输出词元的时间戳。
     • T_request_sent：发送请求的时间戳。

2. 每输出词元时间 (TPOT, Time per Output Token)

   • 概念定义： TPOT 衡量的是在生成第一个词元之后，模型生成每个后续输出词元的平均时间。这个指标反映了模型持续生成文本的效率，对于需要生成长文本的请求（如摘要、长篇回复）尤其重要。
   • 数学公式： TPOT = (T_all_tokens_received - T_first_token_received) / (N_output_tokens - 1)
   • 符号解释：
     • T_all_tokens_received：接收到所有输出词元的时间戳。
     • T_first_token_received：接收到第一个输出词元的时间戳。
     • N_output_tokens：请求生成的总输出词元数量。

3. 端到端延迟 (End-to-end Latency)

   • 概念定义： 端到端延迟 是指从发送用户请求到接收到所有生成的输出词元为止的总时间。它是衡量整个 LLM 服务系统响应速度的综合指标。
   • 数学公式： End-to-end Latency = T_all_tokens_received - T_request_sent
   • 符号解释：

     • T_all_tokens_received：接收到所有输出词元的时间戳。

     • T_request_sent：发送请求的时间戳。

       这些指标在服务持续时间内进行平均，以提供服务性能的全面视图。

5.3. 对比基线

MoLink 与两个最先进的 (state-of-the-art) 分布式 LLM 服务系统进行了比较：

• vLLM [12]：这是一个广泛用于学术界和工业界的代表性 LLM 服务系统。它采用并发传输调度 (concurrent transmission schedule)，通过套接字异步发送 预填充 或 解码 数据量。实验中使用 v0.7.2 版本，这也是 MoLink 基础实现所用的版本。
• Helix [14]：一个为分布式集群设计的高吞吐量服务系统。它将 预填充 或 解码 数据量顺序发送到 ZeroMQ 消息队列中，然后由底层的 ZeroMQ 异步发送消息。

5.4. 集群设置

• 模型 (Models)：实验中使用了 Qwen 7B [19] 模型，这是一个流行的开源 Transformer 模型家族成员，用于研究系统性能。模型推理以半精度 (FP16) 运行。

• 集群配置 (Cluster Setup)：分布式集群包含 3 台服务器，每台服务器配备一张 RTX 4090 GPU。

• 网络条件 (Network Conditions)：节点间通信的平均带宽为 100 Mbps，平均延迟为 30 ms（这是通过在实验室服务器上进行分析获得的结果）。

• 并行策略 (Parallelism Strategy)：这些服务器配置为使用流水线并行 (pipeline parallelism) 策略进行 LLM 服务。

  论文还研究了带宽、延迟 和 流水线并行 度对服务指标的影响。

6. 实验结果与分析

6.1. 核心结果分析

6.1.1. 不同请求速率下的性能比较

以下是原文 Table 2 的结果，展示了在不同请求速率下，vLLM、Helix 和 MoLink 的 TTFT、TPOT 和端到端延迟的平均值。带宽设置为 100 Mbps，延迟为 30 ms。括号中的百分比表示与 vLLM 对应值的比较。

以下是原文 Table 2 的结果：

分析：

• 总体优势：MoLink 在所有请求速率下，TTFT、TPOT 和端到端延迟都达到了最小值，显示出其优越的性能。最大降幅高达 46%。
• 竞争最激烈时效果显著：在 $0.3 req/s$ 的请求速率下，MoLink 相对于 vLLM 和 Helix 实现了最显著的性能提升。例如，TTFT 从 vLLM 的 6.20s 降低到 MoLink 的 5.23s (84%)，TPOT 从 1.69s 降低到 1.30s (77%)，端到端延迟从 306s 降低到 256s (83%)。这表明在 预填充 和 解码 请求并发处理且竞争最激烈的情况下，MoLink 的优化效果最佳。
• 高低负载下收益变化：在高负载 ($0.7 req/s$) 和低负载 ($0.1 req/s$) 情况下，MoLink 的收益有所下降。这是因为在高负载时，一种类型的请求（例如 预填充）可能占据主导地位，使得 分块传输 的机会减少；而在低负载时，传输竞争本身就不那么严重。

6.1.2. 不同带宽下的性能比较

以下是原文 Table 3 的结果，展示了在不同带宽水平下，MoLink 的 TTFT、TPOT 和端到端延迟的平均值。请求速率固定为 $0.3 req/s$，延迟为 30 ms。括号中的百分比表示与 vLLM 对应值的比较。

以下是原文 Table 3 的结果：

分析：

• 带宽增加收益减少，但仍显著：随着带宽的增加（从 60 Mbps 到 400 Mbps），通信开销逐渐降低，传输竞争的影响被缓解，MoLink 相对于基线的性能提升百分比有所减小。然而，即使在 400 Mbps 的高带宽下，MoLink 仍然能带来显著的性能提升，例如 TTFT 相比 vLLM 降低了 13%，TPOT 降低了 14%，端到端延迟降低了 15%。
• 长上下文场景的重要性：这表明通信量仍然不可忽略，尤其是在长上下文（long-context）场景中，预填充 请求的 prompt 可能会非常大（例如摘要任务），即使带宽较高，分块传输 和智能调度依然能带来优势。

6.1.3. 不同网络延迟下的性能比较

以下是原文 Table 4 的结果，展示了在不同网络延迟下，MoLink 的 TTFT、TPOT 和端到端延迟的平均值。请求速率固定为 $0.3 req/s$，带宽为 100 Mbps。括号中的百分比表示与 vLLM 对应值的比较。

以下是原文 Table 4 的结果：

分析：

• 延迟增加，收益减少：随着网络延迟的增加，MoLink 的性能提升百分比（相对于 vLLM）有所下降。这是因为更高的延迟会导致 微批次 到达的延迟更多，从而更频繁地产生流水线气泡 (pipeline bubbles)（如 Figure 6 所示）。
• 微批次数量的影响：论文指出，在此实验中，微批次 数量固定为 5。增加 微批次 数量可以在一定程度上缓解延迟的影响，因为更多的 微批次 可以提供更多的机会来重叠传输和计算，从而更好地填充 流水线气泡。这与 MoLink 提出的“扩展微批次数量”的优化策略相符。

6.2. 消融实验/参数分析

论文通过消融实验 (ablation study) 来分离 MoLink 中每项技术的改进效果。

以下是原文 Table 5 的结果，展示了当单独启用 MoLink 中每项技术时所实现的 TTFT、TPOT 和端到端延迟。请求速率固定为 $0.3 req/s$，带宽为 100 Mbps，延迟为 30 ms。微批次数量设置为 5。

以下是原文 Table 5 的结果：

分析：

• 各项优化均有效：从表格中可以看出，无论是 分块传输 (chunk transmission) 还是 微批次扩展 (micro-batch extending)，单独启用它们都能带来性能提升。
  • 分块传输 将 TPOT 从 No optimizations 的 0.48s 降至 0.44s (约 8.4% 提升)。
  • 微批次扩展 将 TPOT 从 No optimizations 的 0.48s 降至 0.43s (约 10.5% 提升)。
• 组合优化效果更佳：当 分块传输 和 微批次扩展 这两项技术结合在一起时（所有优化 (All optimizations)），性能提升更为显著。例如，TPOT 降低到 0.41s，相比 No optimizations 降低了约 14.6%，相比单独的 分块传输 或 微批次扩展 也更优。这证明了 MoLink 中各项优化技术之间存在协同效应，它们的组合能够带来比单个技术更强大的性能增益。

7. 总结与思考

7.1. 结论总结

本文提出了 MoLink，一个专为在消费级 GPU 上提供分布式大型语言模型 (LLM) 服务而设计的高效系统。MoLink 的核心创新在于解决了 LLM 推理中 预填充 (prefill) 和 解码 (decode) 阶段之间数据传输量巨大不平衡导致的通信效率瓶颈。通过引入分块传输 (chunk transmission) 策略，将大型 预填充 请求的传输量拆分为更小的 分块，并结合加权优先级传输调度算法和实时分块确定算法，MoLink 能够公平地调度 预填充 和 解码 请求的传输，同时防止 预填充 请求饥饿 (starvation)。此外，通过扩展微批次数量，MoLink 有效减少了 流水线气泡 (pipeline bubbles)，提高了 GPU 利用率。实验结果表明，MoLink 在各种请求速率、带宽和网络延迟条件下，均显著降低了 首词元生成时间 (TTFT)、每输出词元时间 (TPOT) 和端到端延迟 (latency)，最大降幅高达 46%，证明了其在提升消费级 GPU 集群 LLM 服务效率方面的卓越性能。

7.2. 局限性与未来工作

论文作者指出了当前 MoLink 的两个主要局限性，并展望了未来的研究方向：

1. 网络波动适应 (Network Fluctuation Adaptation)：
   • 当前假设：MoLink 在设计时假定网络条件是静态的。这意味着它没有内置机制来动态地响应网络带宽或延迟的变化。
   • 未来工作：未来的研究可以探索自适应机制，使系统能够感知并响应网络波动，从而在不断变化的网络条件下保持一致的性能。例如，可以根据实时网络监测结果动态调整 分块 大小或调度策略。
2. 容错性 (Fault Tolerance)：
   • 当前假设：MoLink 在设计中假定设备是可靠的，不会发生故障。
   • 未来工作：在现实世界的场景中，特别是当利用大量消费级 GPU 或去中心化资源时，设备故障是常态。未来的研究可以调查容错机制，以确保系统在设备发生故障时仍能保持鲁棒性 (robustness) 和可靠性。这可能涉及检查点 (checkpointing)、热备 (hot standby) 或其他分布式容错技术。

7.3. 个人启发与批判

7.3.1. 个人启发

• 通信优化的重要性：这篇论文深刻地揭示了在分布式 LLM 服务中，通信效率往往是被忽视的性能瓶颈。尤其是在追求成本效益而转向消费级 GPU 的背景下，网络带宽成为关键限制。这提醒我们，在设计高性能分布式系统时，不能仅仅关注计算和内存，通信也是一个需要精细调优的维度。
• 分阶段特性利用：LLM 推理的 预填充 和 解码 阶段具有截然不同的通信特征。MoLink 精准地抓住了这一特性，并设计了专门的调度策略。这种对任务内部结构化特征的深度理解和利用，是系统优化的一个通用且强大的方法论。
• 自适应实时决策：实时分块确定 算法是一个亮点。它不是一个静态的配置，而是根据运行时状态动态调整。这种自适应性对于处理异构工作负载和动态系统环境至关重要，也为其他领域的资源调度提供了参考。
• 流水线优化的新视角：通过扩展 微批次 数量来填充 流水线气泡，挑战了传统 微批次 数量等于 流水线并行 度数的假设，为带宽受限环境下的流水线并行优化提供了新的思路。

7.3.2. 批判性思考与潜在改进

• 最大等待权重 N 的确定：论文中将 最大等待权重 N 设置为 30，但没有详细说明这个值的来源或如何动态调整。这个固定值在不同的网络条件、请求模式或 GPU 数量下可能不是最优的。未来的工作可以探索：

  • 基于强化学习或其他自适应控制机制，根据系统实时吞吐量、延迟或饥饿情况动态调整 $N$ 值。
  • 提供一种理论分析或经验法则，指导用户如何为特定部署环境选择一个合适的 $N$ 值。

• just-in-time chunk determination 的预测准确性：MoLink 的 分块 确定依赖于对 解码 执行时间 $T_d(x)$ 的预测，以及对 $T_o$ 和 $T_m$ 的建模。这些预测和建模的准确性直接影响 分块 调度的效果。在实际动态环境中，GPU 负载、OS 调度、甚至网络抖动都可能导致实际时间与预测时间出现偏差。

  • 可以引入误差校正机制或更鲁棒的预测模型，例如考虑历史执行数据或实时反馈进行动态调整。
  • LLM 的 解码 过程是自回归的，未来词元的生成时间可能受到前面词元内容的影响，这可能使得 $T_d(x)$ 并非一个简单的函数。

• 跨节点通信的复杂性：论文虽然提到了 RTX 4090，但 100 Mbps 的带宽相对较低。在更复杂的网络拓扑或更高带宽环境下，现有的 TP 和 PP 结合 chunking 的策略可能需要更复杂的通信拓扑优化，例如考虑 NCCL 等高性能通信库。

• 异构设备的进一步优化：虽然 MoLink 支持 Windows PC 和 Linux 服务器，但 Windows 环境下的 GPU 驱动、OS 调度以及容器化开销可能与 Linux 存在显著差异。论文中未详细探讨在异构 OS 环境下的性能特性和具体优化措施。

• 请求队列管理：MoLink 的调度主要聚焦于激活传输，但请求本身的排队策略（例如，请求被 vLLM 或 Helix 接收后，在进入流水线前的排队）也对端到端性能有重要影响。更全面的调度系统应该将请求层面的调度与传输层面的调度相结合。

• 可扩展性限制：虽然 MoLink 在 3 个 GPU 的集群上表现良好，但对于更大规模（例如数十、数百个 GPU）的集群，其调度算法的扩展性（如调度开销）以及 饥饿 预防机制的有效性仍需进一步验证。

• LLM 模型的特定行为：不同的 LLM 模型可能具有不同的 预填充 和 解码 特性（例如，某些模型可能对输入长度更敏感）。MoLink 的参数（如 $N$ 值、chunk 策略）是否需要针对不同模型进行调优？

  总的来说，MoLink 为 LLM 分布式服务，尤其是在成本敏感和带宽受限的环境中，提供了一个非常有前景的解决方案。它强调了通信优化的重要性，并提供了一种新颖的 预填充/解码 传输协调机制。未来的工作可以在其基础上，进一步提升系统的鲁棒性、自适应性以及在大规模异构环境中的性能。