LLM服务公平性

将大型语言模型作为多租户 SaaS 平台运行，会面临一个看似简单实则棘手的问题：许多组织共享同一批 GPU，且它们的流量具有突发性和不均衡性。如果不加管理，一个客户的流量尖峰就可能变成其他所有客户的延迟问题。

在这篇博文中，我们将介绍 Cohere 如何结合架构模式与经典调度算法，提出一种新的解决方案，以在租户之间公平地调度推理请求。

问题：吵闹的邻居

当请求被批量处理时，推理效率最高。一个满载的 GPU 运行高效且经济，而一次只处理单个请求的 GPU 则大多处于空闲状态。因此，请求会短暂排队，在到达硬件之前被打包成批次。

关键在于排序。想象一个简单的队列：一个单一的共享队列，仅按优先级和截止时间排序。现在，考虑当一个组织突发发送 10,000 个请求，而另一个组织只发送 5 个请求时会发生什么。使用单一的全局队列，10,000 个请求会堆积在前面，而那 5 个行为良好的请求则排在后面。

这就是经典的“吵闹邻居”问题，多租户 LLM 平台与面临此类流量模式的任何其他共享系统并无不同。

服务公平性的目标是将租户彼此隔离，使租户获得的推理容量份额取决于公平调度——而不是取决于它向队列注入请求的激进程度。同时，它仍然在每个租户内部保留优先级和截止时间排序，同时保持批处理效率。

解决方案：分层容量管理方法

Cohere 通过结合四种不同的机制来公平地管理跨租户的工作负载，每种机制解决问题的不同方面。它们按固定顺序运行：一个速率限制器控制进入时的准入，然后三个选择器——性能层级、赤字轮询和优先级——在输出时选择下一个请求。

以下是架构和逐步流程：

1. 速率限制器

在请求加入调度队列之前，它需要经过准入控制。速率限制限制了单个租户在给定时间范围内（例如每分钟或每月）可以提交的最大推理请求数。

在 Cohere，这些限制是在端点级别配置的，并根据每个模型消耗的资源量在不同模型之间有所不同。例如，一个重量级的生成模型比一个轻量级的嵌入模型具有更严格的限制。

还有一个实时的节流检查：如果队列已经积压到新请求无法在其延迟目标内得到服务，那么该请求会被提前拒绝。这可以保护系统不接受其无法完成的工作，并在负载下保持延迟的可预测性。

请求被准入后，会进入下面的选择器序列。

2. 性能层级（选择器一）

第一个选择决策是层级。计算资源根据服务等级协议（SLA）进行优先级排序：付费更高的层级比低层级（或试用层级）获得更高的处理优先级和更快的队列处理。反过来，后者在容量允许的情况下得到服务。

关键在于，层级划分决定了谁先走；它本身并不能防止层级内部的单个大租户占据主导地位。这就是接下来两层的目的。

3. 赤字轮询（选择器二）

系统的核心是赤字轮询（DRR）算法，它确保在层级内部，计算资源在集群中公平分配。

每个租户（一个“组织”）都有自己的队列。调度器不是排空最长的队列，而是在租户之间轮流进行。每个租户在其轮次中被授予一个小的预算——一个量子——它可以执行的工作量。当一个租户使用其轮次时，其预算会扣除它刚刚发送的请求的成本。预算用完的租户会被跳过，直到下一轮其预算被补充。

DRR 的优雅之处在于它既是工作守恒的又是加权的。廉价的请求让租户更频繁地出现，昂贵的请求则相反，因此没有租户可以独占 GPU——但也不会浪费任何容量。回到我们之前的例子：即使组织 A 排队了 10,000 个请求，而组织 B 只有 5 个，组织 B 在每个周期仍然会得到它应得的轮次。组织 A 的突发不再转化为组织 B 的延迟。

预算衡量什么

该方案取决于两个关键变量：

• 量子： 每轮授予租户的预算量
• 成本： 每个请求消耗的预算量

关键的设计选择在于这些变量以什么单位表示。至关重要的是，这决定了我们如何在不同的推理上下文中概念化“公平性”。在 Cohere，我们根据端点使用两种成本模型：基于请求的预算和基于 token 的预算。

基于请求的预算

为简单起见，每个请求的成本为 1，量子是每轮租户可以发送的请求数量。因此，公平性纯粹以请求数量来衡量。

这对于生成式端点（例如聊天和补全）来说不是最优的，因为在这些端点中，请求服务成本可能差异巨大。一个带有 100K token 提示的请求可能比一个带有 1K token 提示的请求消耗多个数量级的资源。对于具备推理能力的模型，总成本不仅取决于输入大小，还取决于请求特定上下文所触发的中间推理、规划和输出生成量。

理想情况下，DRR 将使用基于请求的 token 归一化服务成本的指数移动平均（EMA）的反馈循环，使预算能够适应观察到的资源消耗。当端点内的请求在大小和成本上大致相似时，静态预算效果最好。

基于 Token 的预算

在这里，请求的成本是其 token 数量，而量子是每轮的token 预算。现在，公平性以实际完成的工作来衡量。这自然适用于批处理端点，如嵌入和重排序器，在这些端点中，批次的token 总和（而不是项目数量）驱动 GPU 成本。发送少量非常大文档的租户会很快花光其预算并更快地让出位置；发送许多小请求的租户每个请求收费很少，因此会更频繁地出现。这样，没有租户可以通过提交少量超大请求来独占 GPU。

每种模型对你的请求意味着什么

	基于请求的	基于 Token 的
一个请求的成本	始终为 1，无论大小	与其 token 数量成比例
量子（每轮预算）	请求数量	Token 配额
一个大请求	与一个小请求计数相同	收费更高，消耗更多租户份额
发送小请求的租户	获得与其他任何人相同的轮次数	获得更多轮次（每个请求成本低）
最适合	生成式/流式端点	嵌入/重排序器（批处理）端点
公平性衡量	服务的请求数	完成的工作（token）数

因此，在基于请求的预算下，你的请求最多等待来自每个竞争租户的固定数量的请求（无论这些请求有多大）。这个数量可能是可预测的，但邻居的大请求仍然可能在其每次轮次中消耗你的 GPU 时间。

在基于 token 的预算下，一个大请求“更重”：它会更快地消耗其租户的预算，因此该租户会更快地让位，小请求可以高效地通过。这个模型更忠实地反映了工作的真实成本，并且是防止单个租户高流量造成瓶颈的更强有力的保证。

量子的大小也针对端点的批处理策略进行了调整：流式端点在每个租户大约一个请求后轮换，以实现紧密的交错，而批处理端点则授予接近完整批次的预算。因此，在调度器继续之前，一个租户可以贡献有意义的一块——在不牺牲公平性的情况下保持批处理效率。

4. 优先级（选择器三）

如果公平性是关于决定哪个租户下一个处理，那么优先级选择器则决定该租户的哪个请求下一个处理。

一旦赤字轮询选择了一个租户进行其轮次，调度器就会从该租户的队列中取出一个请求——但不是盲目的。每个队列都是一个系统化的队列，按以下顺序排序：

1. 优先级： 明确更高优先级的请求首先被服务。
2. 截止时间： 在优先级相同的情况下，截止时间最早的请求获胜，因此时间敏感的工作不会过期。
3. 到达时间： 作为最后的决胜条件，较早的请求先处理，提供稳定、可预测的先进先出行为。

将这种排序保留在每个租户内部——而不是在一个全局队列中——是让公平性和紧迫性在平台上共存的原因。一个租户不会仅仅因为共享平台而失去其优先级和截止时间保证；它只是将这些保证应用于其自己公平的容量份额。

整合起来

这四个阶段构成了一个清晰的请求生命周期。速率限制控制进入时的准入；层级划分、公平性和每个租户的紧迫性控制输出时（当每个批次被组装时）的选择。

单独来看，这些机制——速率限制、层级划分、轮询调度和优先级队列——对于 MLOps 和平台工程师来说都非常熟悉。它们的新颖价值来自于它们如何集成：

• 速率限制 保护系统免受过载，并强制执行每个租户的配额。
• 层级划分 履行商业承诺。
• 赤字轮询 保证，在同等层级的已准入流量中，每个租户都能获得公平、防突发的份额。
• 优先级 在其公平份额内保留每个租户自身的紧迫性和截止时间排序。

步骤 2-4 重复进行，直到批次满，然后将批次发送到 GPU。结果是，你的体验取决于你的层级和你公平的容量份额——而不是取决于你的邻居那天碰巧有多吵闹。

立即享受更公平、无摩擦的推理

服务公平性现已面向所有通过我们的 SaaS API 和第三方市场部署（包括 AWS）使用任何 Cohere 模型的客户启用。

我们以客户需求为中心开发了此功能。如果你正在使用 Cohere 模型，并且有反馈、观察到性能问题或有改进建议，请通过我们的 Discord 联系我们的工程团队。