Meta最新成果：FleetSieve让LLM集群配置效率暴涨，省21.5%GPU算力

运营大语言模型服务集群的团队大多遇到过类似的两难：有限的GPU预算下，既要满足不同业务的延迟SLO要求，又要尽可能提升资源利用率，而张量并行度和副本数的组合选择一直是配置的核心难点。并行度过高会增加通信开销，减少可部署的副本总数；并行度过低又会拉长单请求延迟，无法满足交互类业务的体验要求，全量压测所有可能的配置虽然可靠，但需要消耗大量算力和时间，很多时候并不现实。

针对这一问题，Meta团队提出了决策导向的压测工具FleetSieve，能够在保证集群配置效果的前提下减少不必要的压测开销。

论文标题：FleetSieve: Decision-Critical Profiling for SLO-Aware LLM Fleet Configuration

论文链接：https://arxiv.org/pdf/2608.19659

研究背景

当前大语言模型服务系统往往需要同时处理多种异构请求流，交互聊天、代码辅助、内容排序、后台生成等不同场景的请求到达规律、输入输出词元长度、延迟目标都存在明显差异。集群运营者需要为每类业务选择对应的并行配置和副本数量，而这些选择之间存在明显的耦合关系：给单个副本分配更多GPU可以降低请求延迟、提升KV缓存余量，但也会导致剩余可用GPU减少，压缩其他业务的可部署副本规模。

张量并行的选择恰好体现了这种矛盾：提升张量并行度可以将模型状态拆分到更多GPU上运行，降低单请求延迟和KV缓存压力，但会增加多卡之间的通信开销，同时减少同一集群内可部署的副本总数，因此不存在“始终用最小并行度”或者“始终用最大并行度”的通用最优解。测试显示，聊天和代码两类工作负载的单GPU SLO可行吞吐量峰值都出现在TP4（4卡张量并行），但当聊天业务负载升高时，TP4的完成时间会违反SLO要求，只有TP8（8卡张量并行）能满足延迟约束，说明张量并行度的最优选择并不存在脱离负载和资源约束的固定排名，最终目标是得到资源约束下的最优集群整体决策。

传统的解决思路是对所有候选配置进行全量压测，这种方案可靠性高，但需要覆盖模型、并行度、请求形态、负载、服务策略的笛卡尔乘积，压测成本随配置复杂度指数级上升。通用的主动学习、贝叶斯优化方法虽然能减少压测量，但通常以降低预测不确定性或者找到最优孤立配置为目标，没有考虑集群分配的资源耦合特性，最终可能得出不符合整体最优的配置结论。

核心设计思路

FleetSieve将压测过程视为下游决策的识别过程，核心是优先测量对最终集群配置决策影响最大的配置项，而非盲目覆盖所有配置项。它会维护所有候选配置的容量和尾延迟不确定性区间，分别基于保守边界（取容量下限、尾延迟上限）和乐观边界（取容量上限、尾延迟下限）求解集群分配方案，当两种方案的决策差距小于指定阈值时就停止压测，否则选择最有可能缩小两种方案差距的配置进行测量。

这种设计的核心创新点主要体现在三个方面：首先是决策导向的采样策略，压测的优先级由测量结果对下游资源耦合分配的预期影响决定，而非单纯由网格覆盖度或者边际不确定性决定，只会优先测量可能改变最终决策的配置项。其次是容量和尾延迟联合建模，容量指标和核心尾延迟指标会共同进入决策流程，避免筛选出吞吐量高但尾延迟违反SLO的配置。最后是条件决策证书机制，压测过程会返回三种状态：已认证可行、未确定、已认证不可行，只有当关键可行性得到确认、剩余分配差距低于阈值时才会停止，而且仅基于已披露测量结果构建先验的重放过程会得到完全相同的停止点和分配结果。

整体运行流程也相对清晰，首先为所有方法初始化相同的稀疏基准测量结果，之后循环拟合容量和尾延迟的联合区间，分别求解保守和乐观两种集群分配方案，判断当前是否满足停止条件，如果已经得到可行或不可行的明确结论就直接返回结果，否则选择能最大程度缩小决策差距的候选配置进行测量，直到所有候选配置都完成测量或者达到停止条件。

实测效果验证

研究团队基于31B参数的开源解码器模型、FP8精度、H100节点、vLLM服务栈进行了测试，候选张量并行度为2、4、8，每个配置项的压测时长为300秒，压测成本以运行时长乘以使用GPU数的GPU秒为单位，工作负载采用公开的Azure聊天和代码trace，其中聊天业务要求成功率≥99%、首包延迟p99≤2秒、完成时间p99≤30秒，代码业务要求成功率≥99%、首包延迟p99≤5秒。

从基础测试结果来看，聊天和代码两类工作负载的单GPU峰值SLO可行吞吐量都出现在TP4，并行度过高或过低都会导致吞吐量下降。而在更高的聊天负载下，TP4和TP8的原始服务速率相同，都是11.27请求/秒，但TP4的平均完成时间p99为46.4秒，违反了30秒的SLO要求，只有TP8的25.2秒符合要求，说明即使吞吐量相同，SLO可行的并行度选择也会随负载变化。

压测成本对比显示，在固定对比场景下，FleetSieve达到和全量压测相同的最优决策只需要22200 GPU秒，比均匀随机采样低6.9%，比其他基准方法低9.8%-21.3%，且所有确定性运行和随机试验都达到了零决策 regret。拆分场景来看，聊天场景下FleetSieve的压测成本比随机采样低21.5%，比其他基准方法低30.4%-38.5%，收益更为明显；而代码场景下由于TP4的优势很早就可以通过少量测量确认，随机采样等方法的压测成本反而低于FleetSieve，说明该方法的收益存在场景依赖性，并非在所有场景下都能带来成本下降。

在16GPU的固定资源分配测试中，全量压测和FleetSieve都选择了聊天和代码业务各部署2个TP4副本的配置，而稀疏独立规则选择了1个TP8聊天副本和2个TP4代码副本，两类配置消耗的GPU数量相同，但服务能力存在明显差距。在0.7倍需求下，剩余容量足够掩盖配置差距，两类配置都能满足全部需求；在1.0倍需求下，稀疏规则的配置损失了0.73请求/秒的吞吐量，最大最小满足率下降了6.1个百分点；在1.3倍需求下，损失进一步扩大到1.93请求/秒和12.4个百分点，充分体现了孤立配置选择和资源耦合集群决策的差异。

尾延迟联合建模的作用也得到了验证，如果只采用容量指标建模，高负载下会选择吞吐量更高的TP4配置，但其46.4秒的完成时间p99违反了SLO要求，联合建模则会在高负载下选择TP8配置，同时在中等负载下保留吞吐量更高的TP4配置，实现了性能和SLO的平衡。

适用边界与局限性

当前测试仅覆盖了31B参数模型、FP8精度、H100平台、vLLM服务栈的场景，模型架构、量化方式、集群互联条件、运行时策略的变化都会改变通信开销和KV缓存容量的平衡，可能会移动甚至消除观测到的内部最优并行度拐点。决策证书的可靠性依赖于经验校准的残差区间和内部拐点的结构假设，如果容量曲线存在多峰或者剧烈不连续的情况，可能会违反这些假设导致决策偏差。

此外测量噪声在SLO边界附近也会产生影响，测试中8个重复边界测量点中有1个的可行性会随种子变化，不过会改变并行度选择的高负载测量点在所有重复测试中都保持了稳定的结果。目前的测试仅在16GPU的固定资源规模下验证了效果，更大规模集群下的表现还需要进一步验证。

总结

FleetSieve是一款面向大语言模型服务集群配置的决策导向压测工具，通过优先测量对最终集群决策影响最大的配置项，能够在保证配置效果和SLO合规的前提下减少压测算力开销。在测试场景下，它相比随机压测整体节省6.9%的GPU秒，聊天场景下节省比例可达21.5%，同时能避免选择尾延迟超标的配置，在16GPU集群中相比稀疏配置规则最多可提升1.93请求/秒的吞吐量和12.4个百分点的最大最小满足率。该方法的收益和负载场景、配置复杂度高度相关，适合需要快速完成大规模集群配置、且配置决策存在较高不确定性的场景使用。