告别暴力堆卡！FleetOpt用“压缩即路由”破解LLM推理集群成本悬崖，最高节省82.4% GPU成本

关键词： LLM 推理、集群规划、成本悬崖、压缩即路由、M/G/c 队列

当我们在讨论大模型推理时，我们究竟在关注什么？是每秒处理的 Token 数（TPS）？是首字延迟（TTFT）？还是那令人瞩目的 GPU 云服务器账单？

如果你曾管理或规划过 LLM 推理集群，很可能面临过一个“房间里的大象”：我们的集群是为最坏情况设计的，但绝大多数请求从未触及那个边界。

为了服务那百万分之一、上下文长度高达 128K 的极端请求，我们不得不为整个集群配置巨大的 KV-Cache，而其余 99.9% 的请求，则在大量闲置的内存槽位上“蜗居”。

这种“最坏情况设计”带来了巨大的资源浪费。正如 FleetOpt 论文开篇所言：“现代 LLM GPU 集群是为绝大多数请求从未接近的最坏情况上下文长度而配置的，这浪费了闲置的 KV-Cache 插槽上的 GPU 容量。”这种浪费直接转化为数十万甚至数百万美元的年化成本。

那么，问题来了：我们能否抛弃这种“一刀切”的暴力堆卡模式，从第一性原理出发，先推导出给定工作负载下的最小成本集群，再去构建它？

这正是 FleetOpt 的核心思想。它不满足于简单的池化路由或事后补救的压缩，而是将这些技术统一到一个数学最优的框架中。它将集群规划问题抽象为 M/G/c 队列模型，并得出了一个关键结论： 最优集群是一个双池架构（短上下文池 + 长上下文池），其最优边界由一个“等边际 GPU 成本条件”决定。

但理论上的最优边界在现实中面临一个“成本悬崖”：当一个请求的上下文长度仅仅超过短池边界一个 Token 时，它需要消耗的 GPU 吞吐能力可能是短池请求的 8 倍到 42 倍！ 这就像在悬崖边行走，一步之遥，成本天差地别。

如何跨越这道天堑？FleetOpt 的答案是“压缩即路由”。它在网关层将那些处于“边界带”的请求进行轻量级提取式压缩，使其能被“拽回”短池处理。这不是简单的功能堆砌，而是将硬件的硬边界，转变为一个可读、可控的软件参数。

最终效果如何？作者在三个真实生产负载上进行了评估，结果如下：

• 相比传统同构集群，FleetOpt 实现了 6.7% 到 82.4% 的 GPU 成本节省。
• 相比单纯的池化路由，压缩即路由机制额外贡献了 1.2 到 43.7 个百分点的成本降低。
• 其核心分析模型与离散事件模拟器的误差控制在 3% 以内，证明了其可靠性。

本文不仅是一份关于如何科学、高效运营 LLM 推理集群的行动指南，也对应着开源项目 vLLM Semantic Router。

接下来，我们将深入探讨 FleetOpt 的精妙之处，看它如何用数学和压缩，实现显著的成本节约。

本文目录

• 一、问题的根源：成本悬崖与工作负载的“马太效应”
  • 1.1 KV-Cache 的“内存税”
  • 1.2 “成本悬崖”：一个 Token 的代价
  • 1.3 工作负载的“马太效应”与“边界带”
• 二、核心创新一：从第一性原理出发的数学模型
  • 2.1 将每个池建模为 M/G/c 队列
  • 2.2 利用 Erlang-C 公式和 Kimura 近似进行精确规划
  • 2.3 推导出最优边界：等边际 GPU 成本条件
• 三、核心创新二：压缩即路由——跨越悬崖的桥梁
  • 3.1 虚拟池：改变硬边界的本质
  • 3.2 轻量级提取式压缩：快、准、狠
  • 3.3 协同设计的价值：为什么 1+1 > 2
• 四、FleetOpt 离线规划器：1 毫秒内的最优解
• 五、评估：数据是最好的证明
  • 5.1 总体节省效果
  • 5.2 模型验证：与离散事件模拟（DES）的对比
• 六、相关工作的对比与定位
  • 6.1 池化路由与长度感知调度
  • 6.2 压缩作为路由杠杆
  • 6.3 LLM 容量规划
  • 6.4 推理模拟与建模
• 总结

一、问题的根源：成本悬崖与工作负载的“马太效应”

要理解 FleetOpt 为何有效，首先要搞清楚成本浪费在了哪里。答案就藏在两个词里：KV-Cache 和工作负载分布。

1.1 KV-Cache 的“内存税”

在 LLM 推理过程中，为了加速生成，模型会将所有历史 Token 的 Key 和 Value 向量缓存下来，这就是 KV-Cache。

对于一个像 Llama-3-70B 这样的模型，在 fp16 精度下，每个 Token 的 KV-Cache 大小约为 320KB。

• 如果为单条请求预留 64K Token 的上下文，其占用的 KV-Cache 约为：64,000 * 320KB ≈ 20.5GB。
• 而如果只预留 8K Token，则仅需 8,000 * 320KB ≈ 2.5GB。

这意味着，在同样的 GPU 显存下，配置为 8K 上下文的 GPU 可以容纳的并发请求数是 64K 配置的 8 倍。 这种吞吐能力的巨大差异，是“成本悬崖”的底层物理基础。

1.2 “成本悬崖”：一个 Token 的代价

假设我们设定一个短池边界 = 8,192 Token。那么：

1.2 成本悬崖的量化冲击

在连续批处理系统中，请求根据其输入长度被路由到不同配置的KV-Cache池。这种硬性边界划分会引发一个关键问题：当请求长度仅略微超出短池边界时，其资源消耗会不成比例地剧增，即“成本悬崖”。

• 一个请求长度恰好为8，192个Token，将被路由至短池，占用一个2.5GB的“小”插槽。
• 一个请求长度为8，193个Token，仅多了一个Token，就必须进入长池，占用一个20.5GB的“大”插槽。

这意味着，这“一个Token”的代价，是让单张GPU的并发处理能力（吞吐量）从128个请求（短池）骤降至16个请求（长池）。这就是成本悬崖现象，其资源效率的落差可达8倍。如果短池边界设置得更低（例如1，536 Token），这种悬崖效应甚至可能达到惊人的42倍。

下表量化展示了当请求长度仅超出短池边界一个Token时，其消耗的GPU资源如何跃升。

表 1：成本悬崖的量化分析。在边界为8K时，短池每个GPU可支持128个并发插槽，长池仅支持16个。一个8，193 Token的请求虽然使用了长池的大插槽，但其实际KV-Cache利用率仅为12.5%，却付出了8倍的吞吐成本代价。

1.3 工作负载的“马太效应”与“边界带”

有效的集群规划必须基于对实际工作负载的深刻洞察。研究分析了三种典型负载模式，揭示了“边界带”请求的关键影响：

1. I 型：集中-短型：绝大多数请求长度集中在短池边界之下（例如LMSYS的多轮对话负载）。分析发现，长度紧邻边界上方的请求（边界带）虽然占总请求数的比例不高（约4.6%-7.8%），但在所有超出边界的请求中却占据了大多数（51%-76%）。 这意味着，若能高效处理这部分边界带请求，即可显著减少对昂贵长池的依赖。
2. II 型：分散型：请求长度跨越多个数量级，分布广泛（例如混合了RAG与工具调用的负载）。边界带请求占总请求的比例相对较高（约7%-12%），且分布较为分散。
3. III 型：集中-长型：大部分请求长度均位于短池边界之上（例如某些代码生成任务）。对于此类负载，压缩技术的收益有限，优化重点在于提高长池本身的资源利用率。

表 2：不同工作负载的边界带特征。该表展示了在不同工作负载和短池边界设定下，边界带请求的比例（β）。α是可直接路由至短池的请求比例，β则是可通过压缩技术纳入短池的边界带请求比例。β值越大，实施压缩技术带来的潜在成本收益就越高。

二、核心创新：基于第一性原理的数学模型

FleetOpt 的第一个核心贡献在于建立了一个严谨的数学框架，从系统性能目标（SLO）出发，逆向推导出最优的集群配置，而非依赖经验性猜测。

2.1 将处理池建模为 M/G/c 队列

作者将每个KV-Cache池（短池与长池）建模为一个 M/G/c 队列：
* M（到达过程）：假设请求到达服从泊松过程，这是系统建模中的常用合理假设。
* G（服务时间）：请求的推理服务时间服从一般分布。这是关键，因为LLM请求的输入、输出长度差异巨大，服务时间并非简单的指数分布。
* c（服务器数量）：在此模型中，每个KV-Cache插槽被视为一个“服务器”。单张GPU能同时容纳的插槽数（c）取决于其配置的上下文长度。例如，配置为64K上下文的长池，c=16；配置为8K上下文的短池，c=128。因此，对于一个拥有 N 张GPU的池，其总服务器数 C = N × c。

服务时间模型基于连续批处理的特性推导。每次模型迭代的延迟 T_iter = T_compute + T_mem × s，其中 T_compute 是基础计算时间，T_mem 是每个活跃插槽带来的内存带宽开销，s 是当前活跃插槽数。最终，一个请求的总服务时间由其输入长度和输出长度共同决定，其分布具有一般性，这正是采用G分布的原因。

2.2 利用 Erlang-C 公式与 Kimura 近似进行精确容量规划

基于上述队列模型，FleetOpt 运用排队论经典工具进行精确的容量规划。

设池的请求到达速率为λ，每个插槽的平均服务率为μ，则总插槽数 C = N × c，系统负载 ρ = λ / (Cμ)。
* Erlang-C 公式：用于计算新到达请求需要排队等待的概率（P_queue）。
* Kimura 近似：用于在M/G/c队列中，结合服务时间的方差，近似计算P99排队等待时间（T_queue）。定义服务时间的平方变异系数为 C_s²，则可进行估算。

首次令牌时间（TTFT）被分解为：TTFT = T_prefill + T_queue + T_decode。其中预填充时间（T_prefill）是确定的。因此，满足SLO的约束条件可表述为：P99(T_prefill) + P99(T_queue) ≤ SLO_TTFT。通过此约束，可以为给定的请求速率和长度分布，反推出所需的最小插槽数 C，进而得到最小的GPU数量 N。 这是一个从性能目标倒推资源配置的精妙过程。

2.3 推导最优边界：等边际GPU成本条件

FleetOpt 最优雅的理论贡献之一，是从数学上推导出了划分长短池最优边界（B_short）的条件。

设路由后短池和长池的请求到达率分别为 λ_s 和 λ_l，N_s 与 N_l 是在各自到达率下满足SLO所需的最小GPU数量。总成本函数为 C_total = N_s + N_l。

通过对总成本函数关于边界 B_short 求导并令其为零，得到一阶最优条件——等边际成本条件：
∂N_s / ∂λ_s = ∂N_l / ∂λ_l
其中，偏导数项代表每增加单位请求速率所需额外增加的GPU数量（边际GPU成本）。该条件意味着：在最优边界处，将一个额外请求路由到短池所带来的边际GPU成本增加，必须等于从长池减少一个请求所带来的边际GPU成本节省。

这一条件深刻揭示：最优的集群配置并非任意设定，而是由工作负载特性与硬件成本共同决定的精确平衡点。

三、核心创新：压缩即路由——跨越成本悬崖的桥梁

完美的数学最优解面临现实的硬件障碍：成本悬崖。若直接按理论最优边界 B_short 路由，所有边界带请求都将被推入长池，无法实现理论最优成本。

FleetOpt 的第二个核心创新——压缩即路由（C&R），正是架设在此悬崖之上的桥梁。它并非事后补救工具，而是实现理论最优边界的核心执行机制。

3.1 虚拟池：软化硬件边界

C&R 的核心思想是在请求抵达推理引擎前，于网关层进行智能干预。

对于落在边界带 [B_short, γ·B_short] 内的请求，系统先将其压缩至 B_short Token以内，再送入短池处理。由此，从LLM引擎的视角看，短池的“有效容量”被提升了。虽然其硬件KV-Cache大小固定为 B_short，但通过C&R，它能处理长度最高达 γ·B_short 的请求，从而形成了一个“虚拟池”。C&R 成功将硬件的刚性边界，转化为软件层面可灵活调节的参数 γ。

虚拟池的路由逻辑如下所示：
[原始请求] --> [网关]
|
+-- 长度 <= B_short? --> [短池 (硬件边界: B_short)]
|
+-- B_short < 长度 <= γ·B_short? --> [压缩] --> [短池 (硬件边界: B_short)]
|
+-- 长度 > γ·B_short? --> [长池 (硬件边界: γ·B_short)]

3.2 轻量级提取式压缩：快速、精准、可靠

压缩组件的设计目标并非追求极限压缩率，而是在毫秒级延迟内完成操作，并确保硬性的内存溢出（OOM）防护。

• 算法设计：采用纯经典的 NLP 提取式流水线，综合 TextRank、位置信息、TF-IDF 和新颖性得分对句子进行评分，然后贪婪地选取高分句子，同时保留关键的“首3句”和“尾2句”。整个流程不依赖任何大语言模型（LLM）推理，因此速度极快。
• 硬性 OOM 保障：压缩器接收明确的目标预算。这意味着，压缩后的提示词（Prompt）Token 数加上请求的预期输出 Token 数，其总和严格等于短池的 KV-Cache 容量上限。因此，任何经过压缩的请求，其总 Token 数都不会超过短池容量，从根本上杜绝了内存溢出风险。
• 安全过滤机制：并非所有内容都适合压缩。例如，代码（Code）类请求会被排除。路由器会使用指数移动平均（EMA）估计为每个请求打上内容类别标签，仅允许 RAG 检索增强生成和散文等结构可提取的内容进入压缩流程，以确保语义无损。
• 延迟表现：在 Intel Xeon Platinum 8568Y+ 处理器上，端到端压缩时间介于 2 到 7 毫秒之间。即使在代理密集型（Agent-heavy）负载的最坏情况下，平均每个请求的压缩开销也仅为 0.39 毫秒，相对于 500 毫秒的首 Token 时间（TTFT）服务等级目标（SLO）而言完全可以忽略。

下表展示了压缩器在不同负载下的延迟表现，验证了其生产环境可行性。

表 4：端到端压缩器延迟（毫秒），在 Intel Xeon Platinum 8568Y+ 单核上测得。“每请求开销”为所有请求的平均新增延迟，经加权计算，对大多数请求而言可忽略不计。

3.3 协同设计的价值：实现一加一大于二

FleetOpt 将压缩与路由（C&R）策略与集群规划进行协同设计，而非简单地在已有集群上“改造”添加该功能。

定理 2（协同设计不劣于事后改造） 指出：协同设计集群的成本总是小于或等于事后改造集群的成本。

其证明直观：协同设计的集群在规划阶段即已预知，未来部分请求会被压缩并路由至短池，因此可以据此缩减长池的规模。 而事后改造的集群，在初始规划时并未考虑压缩，其长池规模是为原始流量分布设计的，即使后续加入压缩，也无法回收为长池超额配置的 GPU 资源。这一“协同设计”优势，在流量分布呈现“集中-短”特征（如 Azure 和 LMSYS 负载）时尤为显著。

四、FleetOpt 离线规划器：毫秒级求解最优配置

整合前述理论、模型与机制的核心是 FleetOpt 的离线规划器。该规划器如同一个“最优集群计算器”，它输入工作负载的累积分布函数（CDF）、SLO 要求、GPU 硬件信息及成本，在不到 1 毫秒的时间内，输出最优的短池边界（B）与压缩带宽（γ）。

规划器的核心逻辑是基于枚举的优化，包含两个关键步骤：

1. 枚举边界 B 与压缩带宽 γ：受硬件约束，B 必须是使 GPU 数量为整数的值，因此候选集有限。γ 则在 1.0 到 2.0 范围内进行扫描。
2. 重新校准长池服务率：这是规划中最易被忽略却至关重要的一步。当通过压缩将部分请求“转移”到短池后，剩余进入长池的请求其平均长度会变长，服务率（μ）会相应降低。若忽略此点，规划器将错误高估长池服务能力，从而低估所需 GPU 数量，导致集群过载。

算法 1：FleetOpt 离线规划器。核心在于枚举所有可能的短池边界 B 和压缩带宽 γ，并对每种组合进行完整的 M/G/c 队列建模。第 6 步“重新校准长池服务率”至关重要，它考虑了压缩后长池请求分布变“重”的事实，避免了收益高估。

五、评估：数据验证效能

理论需经实践检验。FleetOpt 在三种代表性负载上的评估结果，清晰展示了其强大的成本节省能力。

5.1 总体节省效果

下表对比了 FleetOpt 与其他基线方法在三种负载下的集群规模与成本节省情况，直观体现了协同设计的威力。

表 3：GPU 集群规模与成本节省对比。在 Azure 负载上，FleetOpt 通过将 γ 提升至 2.0，几乎完全消除了长池需求（仅需 2 个 GPU），实现了高达 82.4% 的成本节省。而在代理密集型负载上，由于存在大量代码和分散分布，γ 停留在 1.5，节省相对温和。

分析上表，可得出以下关键结论：

• 同构集群代价高昂：在所有负载中，为最坏情况（64K 上下文）配置的同构集群成本均为最高。
• 池化路由基础收益显著：对于短请求集中的负载（如 LMSYS），单纯的池化路由（PR）已能节省 41.7% 的成本。
• C&R 的核心价值在于处理“边界”请求：在 Azure 负载上，C&R 将 PR 的 38.7% 节省提升至 67.6%，增加了近 29 个百分点。这正是因为 Azure 负载的边界请求占比（β=7.8%）高且悬崖比（ρ=16×）显著，压缩每个边界请求都能带来巨大收益。
• 协同设计在 γ=2.0 时效果极致：在 Azure 和 LMSYS 负载上，FleetOpt（γ=2.0）比简单的 PR+C&R 改造（γ=1.5）效果更优。这是因为规划阶段已确知可使用 γ=2.0 进行压缩，从而能更激进地缩减长池规模。

5.2 模型验证：与离散事件模拟的对比

优秀的理论模型必须经得起实践检验。FleetOpt 将其分析模型预测结果与开源离散事件模拟器 inference-fleet-sim 的结果进行了对比。

下表展示了 FleetOpt 分析模型预测的 GPU 利用率与实际模拟结果的对比，误差在 3% 以内，证明了模型的准确性。

表 5：分析模型与离散事件模拟（DES）的 GPU 利用率对比。分析模型预测的利用率略低于模拟结果，表明模型预测稍显乐观，但误差极小。在实际部署中，可通过添加少量 GPU（1-3 个）轻松弥补此差距。

六、相关工作对比

在 FleetOpt 之前，已有诸多工作致力于降低 LLM 推理成本，但 FleetOpt 的独特之处在于其全局优化视角和从第一性原理出发的系统性方法。

6.1 池化路由与长度感知调度

• 代表工作：Chen et al. [2026b], Yuan et al. [2025], She et al. [2026]
• 核心思想：根据请求长度将其路由至不同的、针对特定长度范围优化的计算池中。 FleetOpt 借鉴了此思想，并将其作为实现最优解的基础架构。
• 区别：前述工作通常将池化路由视为独立技术。而 FleetOpt 将其置于一个更大的优化框架中，并指出“成本悬崖”是阻碍其达到理论最优的根本障碍，需引入额外机制（如压缩）来解决。

6.2 作为路由杠杆的压缩技术

• 代表工作：Chen et al. [2026a]
• 核心思想：首次将提示词压缩作为一种可操作的路由杠杆，在现有集群上实施改造。
• 区别：FleetOpt 将压缩视为实现理论最优边界的实施机制，而非可选“外挂”。它从集群规划阶段即考虑压缩，实现了协同设计，而非仅是事后补偿。

6.3 LLM 容量规划

• 代表工作：Romero et al. [2021], Gujarati et al. [2020]
• 核心思想：专注于模型变体选择、预测性扩缩容等。
• 区别：FleetOpt 是首个联合优化池边界、GPU 数量和压缩率，并直接从工作负载 CDF 推导出最优集群配置的系统。它直接回答了“在给定流量下，最优集群应如何配置”这一核心问题。

6.4 推理模拟与建模

(此部分内容在提供的片段中未展开，保留小节标题以供参考。)

• 代表工作：Vidur [Agrawal et al., 2024b], inference-fleet-sim [Chen et al., 2026c]
• 核心思想：模拟单个引擎或集群的行为。
• 区别：FleetOpt 利用这些模拟器（如 inference-fleet-sim）来验证其分析模型。其核心价值在于快速的分析求解能力，可在毫秒级时间内给出最优解，而模拟器则主要用于方案验证与精细化调优。

总结

FleetOpt 为 LLM 推理集群的规划提供了一种全新的视角，其启示主要包括以下几点：

1. 成本优化应基于第一性原理：避免盲目堆叠硬件，转而从数学上推导系统最优解。M/G/c 队列模型等工具能够将复杂的系统行为转化为可求解的数学问题。
2. 以软件机制“软化”硬件边界：成本悬崖是硬件设计的固有特性，但可通过“压缩即路由”（C&R）等软件手段改变其影响。C&R 的本质是将物理内存容量限制，转化为一个可动态调整的软件参数，从而在更广范围内提升硬件效率。
3. “协同设计”是未来方向：将压缩、路由、调度、规划等模块视为整体而非孤立组件，才能释放最大优化潜力。FleetOpt 证明，在规划阶段即考虑未来的压缩行为，能够带来显著的额外成本节省。
4. 数据的核心价值：FleetOpt 的有效性高度依赖于对工作负载累积分布函数的准确刻画。 缺乏数据支撑，任何优化都如同空中楼阁。未来，随着 AI 应用多样化，需要更精细、动态地理解负载特征，并将其反馈至规划系统，实现真正的数据驱动式基础设施运营。

最终，FleetOpt 不仅是一项技术方案，更代表了一种思维范式的转变：从被动“应对”最坏情况，转向主动“设计”最经济系统。 对于任何希望将 LLM 推理成本控制在合理范围内的团队而言，这都是一份值得深入研究和实践的宝贵参考。

关注“鲸栖”小程序，掌握最新AI资讯