🤖 AI

Coral: Cost-Efficient Multi-LLM Serving over Heterogeneous Cloud GPUs

Coral 是一个自适应且感知异构性的多大型语言模型（LLM）服务系统，它通过跨多样化云 GPU 联合优化资源分配与服务策略，并采用无损两阶段分解以实现快速、近优的决策，从而将成本降低高达 2.79 倍，并将有效吞吐量提升 2.39 倍。

原作者： Yixuan Mei, Zikun Li, Zixuan Chen, Shiqi Pan, Mengdi Wu, Xupeng Miao, Zhihao Jia, K. V. Rashmi

发布于 2026-05-07

📖 1 分钟阅读☕ 轻松阅读

原作者： Yixuan Mei, Zikun Li, Zixuan Chen, Shiqi Pan, Mengdi Wu, Xupeng Miao, Zhihao Jia, K. V. Rashmi

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你经营着一家规模宏大、高端的餐厅厨房。过去，人们认为要烹饪每一道菜，都需要最昂贵、顶级的厨师和最大、最快的炉灶。但在大语言模型（LLM）——即聊天机器人和代码生成器背后的 AI 大脑——的世界里，情况已经发生了变化。没有单一的"AI 模型”能在所有方面都做到最好。有些擅长编写代码，有些擅长聊天，而有些则仅擅长处理简单任务。

此外，这个“厨房”（云服务器）里充斥着各种各样的设备。你拥有超快但昂贵的"H100"炉灶，但它们经常缺货。同时，你也拥有更旧、更便宜的"L4"或"A100"炉灶，它们有现货，而且令人惊讶的是，每美元提供的烹饪能力同样强劲。

问题在于：如何在一个拥有 46 种不同食谱（模型）的厨房中，混合使用昂贵和廉价的炉灶，既不浪费资金，又不让顾客等待？

这就是Coral所要解决的问题。

旧方法：“一刀切”的错误

以前的系统试图通过将每道菜视为一个黑盒来解决这个问题。它们会说：“对于写代码这道菜，我们需要一整台 H100 炉灶。对于聊天这道菜，我们需要一台 A100。”它们没有深入食谱内部，看看是否可以混合搭配炉灶的各个部分。

这导致了两个大问题：

资金浪费：即使更便宜的组合也能达到同样好的效果，它们往往还是购买了最昂贵的设备。
瓶颈：如果昂贵的炉灶用完了，整个厨房就会停摆，尽管还有大量廉价的炉灶闲置着。

Coral 解决方案：“智能混搭”主厨

Coral 就像一位天才主厨，他意识到单道菜并不需要仅在一种类型的炉灶上烹饪。相反，Coral 将烹饪过程分解为各个阶段，并为每个阶段分配完美的炉灶。

以下是其工作原理，使用一个简单的类比：

1. 两阶段策略（离线与在线）

Coral 将其思考过程分为两部分，以避免不堪重负：

阶段 1：食谱书（离线）
在餐厅开业之前，Coral 会花时间创建一本庞大的“食谱书”。对于每一种可能的菜肴（模型）和每一种可能的炉灶组合（GPU），它都会计算出烹饪该菜肴的绝对最佳方式。
- 示例：它计算出，对于"Qwen-3 235B"这道菜，烹饪第一部分（预填充）的最佳方式是使用三台廉价的 L40S 炉灶和两台昂贵的 H100 炉灶，并按特定顺序排列。
- 它将这些完美的“食谱”记录为服务模板。这需要很长时间来完成，但只需进行一次。
阶段 2：日常轮班（在线）
当餐厅开业且订单开始涌入时，Coral 不会停下来从头计算如何烹饪。它只需查阅其食谱书。
- 它会检查：“我们现在有 5 台 L40S 和 2 台 H100 可用。我们需要烹饪 100 份 Qwen-3 菜肴。”
- 它会立即挑选出适合这些特定炉灶并满足客户速度要求的预计算食谱。
- 由于艰难的数学计算已提前完成，Coral 可以在几秒钟内做出这些决定，而不是数小时。这使得厨房能够在炉灶损坏或新订单涌入时立即做出调整。

2. “团队合作”类比

想象你有两个工人团队（两个不同的 AI 模型）和有限的工具供应（GPU）。

旧方法：团队 A 拿走了所有最好的工具，因为他们是“最好”的团队。团队 B 只能拿到坏工具，无法完成工作。
Coral 的方法：Coral 纵观全局。它意识到，如果团队 A 重新安排工作流程，他们实际上使用混合的好工具和一般工具也能很好地完成工作。这为团队 B 腾出了最好的工具。两个团队都能按时完成任务，没有任何工具被浪费。

为什么这很重要

该论文使用 6 种不同的 AI 模型和 20 种不同类型的计算机芯片（GPU）对 Coral 进行了测试。结果令人印象深刻：

更便宜：与现有最佳方法相比，Coral 将运行这些 AI 模型的成本降低了高达2.79 倍。这就像原本为这顿饭支付 100 美元，现在只需支付 36 美元即可获得同等质量。
更快（当资源稀缺时）：当“厨房”拥挤且工具难以寻找时，Coral 能够在不减速的情况下，比竞争对手多服务2.39 倍的顾客。

核心结论

Coral 是一个不再将 AI 模型视为僵化、单一块状机器的系统。相反，它将它们视为灵活的食谱，可以在新旧设备的混合体上烹饪。通过提前规划“完美组合”，然后在实时中快速应用，它节省了巨额资金，并确保了 AI 的平稳运行，即使硬件供应不稳定。

简而言之：Coral 是一位聪明的管理者，懂得如何混合使用昂贵和廉价的工具，以比任何人都更快、更便宜的方式完成任务。

技术摘要：Coral——基于异构云 GPU 的成本效益多 LLM 服务

1. 问题陈述

大型语言模型（LLM）的部署格局日益碎片化，没有单一模型占据主导地位；相反，提供商必须同时服务多个模型，每个模型都具有独特的架构和成本 - 质量权衡。与此同时，云提供商提供混合的 GPU 代际（从顶级的 H100 到中高端的 A100 以及较旧的 L4）。虽然顶级硬件提供峰值性能，但中端和旧款 GPU 通常提供相当或更优的每美元性能以及更好的可用性。

Coral 解决的核心挑战是在异构云资源上实现成本效益高且自适应的多 LLM 服务。这需要联合优化两个紧密耦合的决策：

资源分配：确定在不同云区域中配置哪些节点。
模型放置：决定如何在这些异构节点上划分每个模型（例如，通过流水线并行和数据并行）。

现有系统未能端到端地解决这一问题。 prior 工作要么在假设同质副本的情况下优化资源分配（忽略了放置优化），要么在固定节点集上为单个模型优化放置（忽略了全局分配）。由于两个维度的搜索空间呈指数级增长，且需要快速重新求解（以分钟计，而非小时）以适应波动的需求和资源价格，暴力联合优化是不可行的。

2. 方法论

Coral 引入了一种自适应且感知异构性的系统，将联合优化问题解耦为无损的两阶段分解。

关键洞察：服务模板

Coral 观察到，对于固定的模型和延迟服务等级目标（SLO），特定节点集上的吞吐量最优模型放置仅取决于该节点组合，而与集群其余部分的分配方式无关。这使得放置搜索可以离线进行。

阶段 1：离线服务模板生成

过程：对于每个（模型，SLO）对，Coral 枚举一个原则性的节点组合子集。对于每个组合，它使用整数线性规划（ILP）计算满足延迟 SLO 的吞吐量最优模型放置（层划分和节点分配）。
输出：服务模板库。每个模板是一个可重用的工件，指定节点组合及其最优放置策略。
优化：ILP 在延迟约束下最大化吞吐量。为了处理组合复杂性，Coral 通过限制每个模板的最大节点数（ $N_{max}$ ）和相对于模型大小的总内存比率（ $\rho$ ）来剪枝搜索空间，因为较大的组合通常会产生过高的通信开销。

阶段 2：在线资源分配

过程：在线资源分配器定期查询预计算的服务模板库。它求解第二个轻量级 ILP，以确定在哪些区域实例化哪些模板，以最低成本满足当前的吞吐量需求。
输入：实时吞吐量需求、GPU 可用性以及各区域的价格。
目标：最小化总配置成本加上初始化惩罚（以抑制过度震荡），同时满足吞吐量和可用性约束。
效率：通过将复杂的模型放置搜索移出关键路径，在线求解器在几十秒内完成，而非数小时，从而使集群能够适应需求和供应的动态变化。

系统实现

Coral 作为一个运行时系统实现，使用 ZeroMQ 进行控制，NCCL 进行实例间通信，并以 vLLM 作为执行引擎。它支持解耦的预填充 - 解码（Prefill-Decode, PD）和聚合服务。一个经过真实硬件验证的高保真事件驱动模拟器被用于大规模评估，因为在物理上配置成本过高。

3. 主要贡献

论文声称以下贡献：

问题形式化：将感知异构性的多 LLM 服务形式化为在每模型延迟 SLO 下，对资源分配和模型放置的联合优化。
无损分解：一种新颖的两阶段方法，使用可重用的服务模板将复杂的放置搜索移至离线阶段，将在线求解时间从数小时缩短至几十秒，且不牺牲最优性。
可扩展求解器：基于 ILP 的求解器，分别用于离线放置和在线分配，可扩展至数千个节点的集群。
端到端系统：Coral 的完整实现以及用于大规模评估的已验证模拟器。
实证验证：在 6 个模型和 20 种 GPU 配置上的评估，展示了显著的成本降低和良好吞吐量（goodput）提升。

4. 结果

评估在多样化的模型（参数范围从 14B 到 235B）和 GPU 配置（包括 H100、A100、L40S、L4、A10G）以及不同的资源可用性条件下进行。

成本效益：在扩展设置中，与最佳基线（Homo，使用同质副本）相比，Coral 将服务成本降低了高达 2.79 倍；与 Cauchy（一种 PD 解耦基线）相比，降低了 2.66 倍。在核心设置中，降低幅度分别为 1.62 倍 和 1.60 倍。
稀缺资源下的良好吞吐量：在资源稀缺的情况下，Coral 提供的良好吞吐量（满足 SLO 的每秒 token 数）比基线高出高达 2.39 倍。这是通过跨模型联合协调资源以解决争用实现的，而基线无法满足特定模型的需求。
求解时间：在线资源分配 ILP 在核心设置中平均求解时间为 0.24 秒，在扩展设置中为 9.68 秒，远优于所需的适应窗口。
与 Helix 的比较：在固定异构集群上的单模型模式下，与 Helix 相比，Coral 降低了 21% 的成本，提高了 26% 的吞吐量，同时严格满足延迟 SLO。
敏感性：分析表明，当节点上限（ $N_{max}$ ）设置为 6 且内存比率（ $\rho$ ）设置为 12 时，生成模板的成本效益趋于平稳，这证明了剪枝策略的合理性。

5. 意义

论文认为，资源分配和模型放置的联合优化对于成本效益高的多 LLM 服务至关重要。通过将模型副本视为同质硬件上的黑盒，现有系统留下了巨大的成本节约空间，并在资源约束下难以应对。Coral 证明，副本内异构性——通过混合流水线和数据并行在单个模型副本内混合不同类型的 GPU——允许系统根据特定的工作负载特征和 SLO 定制实例。

Coral 的意义在于其使这种联合优化变得可行且自适应。通过将最优放置预计算为可重用的模板，它弥合了联合搜索的理论最优性与快速在线重新配置的实际必要性之间的差距。这使得云提供商能够利用更广泛、更具成本效益的 GPU 库存，同时为多样化的并发 LLM 工作负载保持严格的延迟保证。