FleetSieve：面向SLO感知LLM舰队配置的决策关键型分析方法

# 面向 SLO 感知的大语言模型集群配置的决策关键性分析
来源：https://arxiv.org/html/2608.19659
Scott Zhang、Aubert Li
隶属机构：美国加利福尼亚州门洛帕克，Meta 公司
电子邮箱：[[email protected]](mailto:)

###### 摘要

为大语言模型服务集群选择张量并行度与副本数是一项挑战，因为性能与张量并行度的关系并非单调，且可行选择会随负载变化而改变。穷尽式分析虽然能解决此不确定性，但会测量许多对最终资源分配并无影响的配置。

我们提出了 FleetSieve，该方法根据测量对资源耦合、SLO 感知的集群决策的预期影响来选择测量项。FleetSieve 联合建模容量与尾延迟，比较保守和乐观的分配方案，并在两者剩余决策差距低于指定容差时停止。针对一个 310 亿参数的开放权重模型，在固定 H100 测量网格上，FleetSieve 以 22,200 GPU 秒达到了预言机的总体决策，比固定比较中的均匀随机分析减少了 6.9%。在 200 个随机揭示顺序下，其相对于随机分析的平均节省率为 5.4%（95% bootstrap 置信区间：3.5–7.2%）。对于 Chat 工作负载，固定比较的节省率为 21.5%，但 FleetSieve 并非在 Code 工作负载上使用最少的 GPU 秒。容量与尾延迟的联合建模也避免选择了一个完成时间 p99 为 46.4 秒、违反 30 秒 SLO 的配置。在一个 16-GPU 分配中，一个不正确的稀疏分析决策会导致每秒最多损失 1.93 个请求，并使最大最小满足率下降 12.4 个百分点。边界重复实验和 BurstGPT 测量支持了所观察到的负载相关的尾延迟机制。

## 1 引言

大语言模型服务系统很少服务于单一的同构请求流。交互式聊天、代码辅助、排名和后台生成在到达过程、令牌长度和延迟目标上各不相同。在有限的 GPU 资源预算下，运营者必须为每类工作负载选择并行配置和副本数。这些选择相互影响：为一个副本分配更多 GPU 可能会降低其延迟并增加其内存余量，但也会留下更少的 GPU 服务于其他工作负载的副本。

张量并行度体现了这种矛盾。增加 TP 会将模型状态分布在更多 GPU 上，可以改善单请求延迟和 KV 缓存余量，但会增加集合通信，并减少在同一集群中可容纳的副本数量。因此，"总是使用最小 TP" 或 "总是使用最大 TP" 通常都不是正确的。在我们的测量中，对于两种工作负载，每 GPU 的 SLO 可行吞吐量峰值均出现在中间选择 TP4。然而，在较重的聊天负载下，TP4 会违反完成时间目标，而 TP8 仍保持可行。因此，相关目标并非脱离上下文的 TP 排名，而是最终受资源约束的集群决策。

传统解决方案是分析所有候选配置。这很可靠，但其规模随模型、TP 度、请求形状、负载和服务策略的笛卡尔积增长而扩大。通用的主动学习和贝叶斯优化方法可以减少测量，但它们通常针对预测不确定性或最佳的孤立配置。而集群规划者需要知道的是，另一次测量是否能够改变耦合的分配方案。

FleetSieve 将分析视为下游决策识别过程。它维持容量和尾延迟的不确定性，在保守和乐观的实现下求解集群分配，并测量那些预计能减少这些决策间分歧的配置。它仅在关键可行性得到解决且剩余分配差距低于容差时才停止。

本文有三个贡献：
1. 1. **决策关键性获取**。分析由测量项对下游资源耦合分配的预测影响驱动，而非仅由网格覆盖或边际不确定性驱动。
2. 2. **容量与尾延迟的联合建模**。容量和作为约束的尾指标共享决策路径，防止一个高吞吐量但尾延迟不可行的配置被认定为可行。
3. 3. **有条件的决策证书**。分析器在经验不确定性模型下返回三态结果——认证可行、未决、或认证不可行。一个仅从已揭示测量构建先验的回放会产生相同的停止点和分配方案。

我们的评估涵盖一个 310 亿参数模型和一个 H100 平台。FleetSieve 在总体分析 GPU 秒方面适度减少，对 Chat 的减少更大，但对 Code 没有减少。因此，我们将此方法解释为在尚未解决的测量仍可能改变分配时具有选择性效用，而非普遍性改进。

## 2 背景与相关工作

#### 大语言模型服务。
vLLM 中的 PagedAttention [1] 和 Orca 中的连续批处理 [2] 提高了内存利用率和调度效率。Sarathi-Serve [3]、DistServe [4]、Splitwise [5] 和 AlpaServe [6] 优化了批处理、阶段分离或放置。SLOs-Serve [7] 跨多个目标分配服务资源，而 Nitsum [8] 则在运行时为分级请求调整 TP。这些系统促成了丰富的配置空间；FleetSieve 解决的是一个互补的问题：在承诺集群配置之前，需要哪些测量。

#### 配置搜索与面向决策的测量。
SCOOT [9] 将约束贝叶斯优化应用于大语言模型推理引擎调优。主动学习更广泛地选择信息性样本 [10]；有针对性的主动学习明确优化关于下游贝叶斯决策的信息 [11]。固定置信度的组合探索，如 CombGapE [12]，以较少的样本识别最优的组合动作。FleetSieve 借鉴了这种面向决策的视角，但将其应用于相关的服务测量、多个 SLO 指标以及整数的、资源耦合的集群分配。我们并非声称主动学习、贝叶斯优化、消除或固定置信度停止是独立的新颖方法。

#### 公开追踪数据。
我们的主要回放使用了伴随 DynamoLLM [13] 的公开 Azure LLM 推理追踪数据；该数据集以 CC BY 许可分发。BurstGPT [14] 提供了用于机制级鲁棒性检查的独立对话追踪。

#### 资源受限的选择。
资源受限的选择也出现在其他基础设施领域。例如，Cheng 等人 [15] 将连续道路覆盖形式化为一个背包约束的斯坦纳树问题。FleetSieve 解决的是一个不同的系统并使用不同的算法，但共享着将有限资源预算集中于决定系统级效用的决策这一更广泛的目标。

## 3 问题表述

设工作负载类 i ∈ 𝒲 具有到达需求 λᵢ、SLO Lᵢ 和优先级 pᵢ。优先级定义了一组关键类 𝒸 和 i ∈ 𝒸 的最小满足率下限 δᵢ。一个服务配置 q ∈ 𝒬ᵢ 指定了 TP 度和准入/负载设置。它消耗 gq 个 GPU 每副本。其未知的性能向量是

θᵢq = (cᵢq, ℓᵢq, sᵢq)，其中 cᵢq 是可持续吞吐量，ℓᵢq 是相关的尾延迟指标，sᵢq 是成功概率。配置仅当其尾延迟和成功指标满足类策略时才是可行的。

分配器选择整数副本数 nᵢq 和服务负载 xᵢ。在我们的实现中，每个类使用一个同构配置，用二元选择器 yᵢq 表示：

∑_q yᵢq = 1，nᵢq ≤ M yᵢq，(1)
xᵢ ≤ ∑_q nᵢq cᵢq，(2)
∑_{i,q} nᵢq gq ≤ G，(3)
0 ≤ xᵢ ≤ λᵢ，nᵢq ∈ ℤ≥0，yᵢq ∈ {0, 1}，(4)
yᵢq = 1 ⇒ ℓᵢq ≤ Lᵢ，sᵢq ≥ sᵢ^{min}。(5)
满足率 rᵢ = xᵢ / λᵢ。目标是字典序的：(1) 在可行时强制关键类满足 rᵢ ≥ δᵢ，(2) 最大化 min_i rᵢ，(3) 最大化总服务有效吞吐量，(4) 最小化碎片化。分析使用单独的以 GPU 秒衡量的计算预算。

如果所有 θᵢq 都已知，穷尽分析将产生预言机分配。分析问题在于如何在仅揭示表格子集的情况下接近该决策。

## 4 FleetSieve

### 4.1 联合不确定性状态

在第 t 轮之后，FleetSieve 维护容量区间 [c̲ᵢq,t，c̄ᵢq,t] 和尾延迟区间 [ℓ̲ᵢq,t，ℓ̄ᵢq,t]。这些区间结合了内部拐点结构先验和测量残差。它们是经验性的而非无分布假设的；第 6.4 节描述了对此主张进行限定的审核。

保守分配 A_t⁻ 使用容量下界和尾延迟上界。乐观分配 A_t⁺ 使用容量上界和尾延迟下界。两者使用相同的 GPU 约束、SLO 策略和字典序目标。

### 4.2 决策证书

如果即使 A_t⁺ 也无法满足关键下限，则状态为 **认证不可行**。如果关键可行性未解决或乐观与保守目标差异超过 ε，则状态保持 **未决**。当 A_t⁻ 满足关键策略、每个承诺的尾延迟上界已知且在 SLO 内、且阶段分配差距至多为 ε 时，则状态为 **认证可行**。

此证书取决于不确定性集合包含相关的性能表。因此我们使用“经验性的”或“条件校准的”，而非无条件正确性保证。

### 4.3 获取

对于每个未测量的实验项，FleetSieve 估计揭示其结果将如何缩小容量/尾延迟不确定性并改变保守-乐观分配差距：

score_t(e) = 𝔼[Γ_t - Γ_{t+1} | e]，其中 Γ_t 是阶段下游分配差距。该实现使用确定性近似此信息价值目标。预期的分析 GPU 秒是严格的决胜因素，而非除数；因此我们将此规则描述为决策关键性而非普遍计算资源最优。

**算法 1** FleetSieve 分析循环
1: 初始化所有方法共用的稀疏设计。
2: **while** 存在未测量的候选 **do**
3:     拟合联合容量和尾延迟区间。
4:     A⁻ ← 保守集群分配。
5:     A⁺ ← 乐观集群分配。
6:     z ← 证书(A⁻, A⁺, ε)。
7:     **if** z = 认证可行 **then**
8:         **return** A⁻。
9:     **else if** z = 认证不可行 **then**
10:        **return** 不可行。
11:    **end if**
12:    揭示具有最大决策差距缩减的候选。
13: **end while**
14: **return** 最佳已测量的可行分配。

## 5 实验方法

#### 系统。
我们在单个 H100 节点上评估一个 310 亿参数的开放权重解码器模型，使用基于 vLLM 的服务栈，并禁用投机解码。候选 TP 度为 {2, 4, 8}。每个单元格运行 300 秒；分析以持续时间乘以使用的 GPU 数衡量，报告为 GPU 秒。

#### 工作负载与 SLO。
主要工作负载使用公开的 Azure 对话和代码追踪 [13]。追踪记录提供到达时间和输入/输出令牌数，而非提示内容。聊天策略要求 success ≥ 99%，TTFT-p99 ≤ 2 秒，completion-p99 ≤ 30 秒。代码策略要求 success ≥ 99% 且 TTFT-p99 ≤ 5 秒。负载标签如 C96 是记录到达规模阶梯的序数索引，而非字面的进行中请求数。

固定主要网格包含 21 个标准化单元格和四个早期代码-TP2 校准单元格。这四个单元格使用不同的预热划分并单独标记；排除它们不会改变代码预言机，因为 TP2 被支配。边界实验用五个种子重复了八个 TP4/TP8 单元格。BurstGPT 增加了 18 个已测量单元格：三个负载规模，两个 TP 度，三个种子。

#### 基线与指标。
所有方法从相同的观测开始，使用相同的候选表、SLO、分配器和经验停止条件。我们比较均匀随机、固定网格顺序、联合最大不确定性、共享特征不确定性代理、有针对性的主动学习、信息价值、约束贝叶斯优化和 FleetSieve。主要指标是达到 ε-正确证书决策（ε=0.05）的 GPU 秒，相对于完全测量的预言机的决策遗憾，以及遗憾 AUC。我们还报告生成的 16-GPU 分配、边界稳定性和尾延迟证书控制。

**图 1：为什么分析是必要的。** (a) 每 GPU 的 SLO 可行吞吐量峰值是非单调的，并在两种 Azure 工作负载类中都在 TP4 达到峰值。(b) 在较重的聊天 C128 点，TP4 和 TP8 服务相同的原始请求率，但只有 TP8 满足完成时间目标；柱状图显示五个种子的平均值。

## 6 结果

### 6.1 TP 最优是内部的且依赖于负载
表 1 和图 1 报告了每 GPU 的峰值 SLO 可行吞吐量。两种工作负载类都在 TP4 达到峰值；更小或更大的 TP 并非统一最佳。

**表 1：峰值 SLO 可行吞吐量（请求/秒/GPU）。** 在较重的聊天 C128 点跨五次重复，TP4 和 TP8 均服务 11.27 请求/秒。它们的平均 completion-p99 值分别为 46.4 和 25.2 秒，因此只有 TP8 通过 30 秒目标。因此，即使吞吐量不变，SLO 可行的 TP 也可能改变。

### 6.2 决策关键性分析在总体上适度更好
表 2 和图 2 报告了达到共同经验证书所需的 GPU 秒。在固定总体比较中，FleetSieve 使用 22,200 GPU 秒，比随机分析低 6.9%。