跨模型实例的负载均衡

成功部署大型语言模型不只是需要一个训练好的成品；它需要能够高效可靠地处理大量并发请求的基础设施。如前所述，在大量负载下，即使是强大的硬件，单个模型实例也很快会成为瓶颈。此外，仅依靠单个实例会造成单点故障。为解决这些限制并获得可伸缩性和高可用性，使用负载均衡将推理请求分配到多个模型实例上是必要的。

负载均衡充当你的LLM服务的流量管理员。请求不会直接到达单个模型实例，而是首先到达负载均衡器。负载均衡器的任务是根据选定的策略，智能地将每个请求转发给多个可用后端模型实例（副本）中的一个。主要目标是最大化总体吞吐量（每秒处理的请求数），最小化用户感受到的平均响应延迟，确保即使某些实例出现故障服务也能保持可用，并优化GPU等昂贵硬件资源的使用效率。

LLM为何需要负载均衡

LLM推理的独特特点使得负载均衡显得尤为重要：

1. 每次请求资源消耗高： 使用大型模型生成文本需要大量计算（GPU周期）和内存（用于模型权重、激活和KV缓存）。在一个GPU上按顺序处理请求会极大地限制吞吐量。为了同时服务多个用户，并行执行跨多个实例是必需的。
2. 请求负载多变： LLM应用的客户端流量通常会根据一天中的时间、用户活动或特定事件而波动。负载均衡层使得后端基础设施（模型实例数量）能够根据需求进行水平伸缩（增加或移除实例），从而在不过度预留资源的情况下确保性能一致。
3. 容错与高可用： 硬件会失效，软件会崩溃，网络问题也会发生。如果你只有一个模型实例，任何此类故障都会导致服务完全中断。通过将请求分配到多个实例，负载均衡器可以检测无响应的实例（通过健康检查），并仅将流量路由到健康的实例，从而显著提高服务的总体可用性。

常见负载均衡策略

可以使用多种算法来决定哪个后端实例应接收下一个传入请求。选择取决于你应用程序的具体要求、推理请求的性质以及在简单性和最佳负载分配之间所需做的权衡。

• 轮询（Round Robin）： 这是最简单的策略。负载均衡器维护一个可用后端实例列表，并按顺序循环它们，将每个新请求发送给列表中的下一个实例。

  轮询策略按顺序将请求分配给可用实例。

  它易于实现，但假定所有请求的复杂度大致相同，并且所有实例都具有相同的性能。它不适应实例负载或请求处理时间的变化。

• 最少连接（Least Connections）： 该策略将新请求定向到当前处理活动连接最少的后端实例。这样做的原因是为了让连接较少的实例可能更不繁忙。

  最少连接策略将新请求定向到当前连接最少的实例（实例 2）。

  当请求持续时间不同时，这通常比轮询提供更好的负载分配，因为它隐式地将流量从被长时间运行请求拖慢的实例中分流。然而，它依赖连接数作为负载的代理，这可能无法完美反映GPU的使用情况。

• 最少负载/基于资源： 更精密的策略是根据后端实例实际测量的资源使用情况来路由请求。这可能涉及监控GPU使用率、可用GPU内存、CPU负载，甚至像模型服务器内部请求队列长度这样的自定义应用级指标。负载均衡器将新请求定向到当前报告负载最低的实例。这在理论上是平衡实际工作量最有效的方式，但它需要一个监控系统来收集这些指标，以及一个能够使用这些指标的负载均衡器，这会增加复杂性。

• 加权策略： 如果你的后端实例具有不同的能力（例如，某些实例拥有更强大的GPU），你可以为它们分配权重。加权轮询或加权最少连接算法将根据这些权重按比例分配请求，向能力更强的实例发送更多流量。

• 哈希/会话粘滞： 像IP哈希这样的策略会将来自相同客户端IP地址的请求始终定向到相同的后端实例。这被称为会话粘滞或粘性会话。虽然对于用户会话数据必须驻留在特定服务器上的有状态应用程序很重要，但对于典型的无状态LLM推理API来说，它通常适用性较小，有时甚至不理想，因为任何实例都可以处理任何请求。如果某些客户端发送的请求比其他客户端多得多，保持粘滞性可能导致负载分配不均。

实现考量

为LLM服务实现负载均衡涉及多个组件：

• 负载均衡器选择： 你可以使用硬件负载均衡器，但在云和容器化环境中，软件解决方案更常见。常用选择包括：

  • 配置为负载均衡的反向代理，如Nginx或HAProxy。
  • 云提供商服务，如AWS弹性负载均衡（ELB）、谷歌云负载均衡或Azure负载均衡器，它们提供托管式、可伸缩的解决方案。
  • Kubernetes服务：当在Kubernetes中将模型实例作为Pod部署时，内置服务（如LoadBalancer或NodePort）和Ingress控制器会自动处理健康Pod之间的路由和负载均衡。

• 健康检查： 负载均衡器的一项重要功能是持续监控后端实例的健康状况。它会定期向每个实例的特定端点（例如，/healthz）发送一个小请求（健康检查）。如果一个实例未能正确响应或在超时时间内未响应，负载均衡器会将其标记为不健康，并停止向其发送流量，直到它恢复。为LLM服务器设计有效的健康检查可能不仅涉及检查服务器进程是否正在运行，还可能涉及执行一个最小推理任务，以确保模型已加载并可响应。

• 与服务框架集成： 模型服务框架（如NVIDIA Triton推理服务器或TorchServe）运行在每个后端实例上。负载均衡器位于这些实例的前面。框架本身可能处理动态批处理（将负载均衡器接收到的、时间相近的请求分组以进行高效GPU处理）等方面，但实例间的负载均衡通常由外部管理。

• 自动伸缩集成： 负载均衡与自动伸缩结合使用时最有效。自动伸缩器监控实例池的汇总指标（例如，平均GPU使用率、请求队列长度、延迟）。根据预定义的阈值，它会在高负载时自动添加更多模型实例，并在需求减少时移除它们。负载均衡器会动态调整以适应自动伸缩器提供的可用实例集的变化，确保流量始终在活跃的实例池中分配。

挑战与权衡

负载均衡虽然必不可少，但也带来一些考量：

• 延迟开销： 负载均衡器本身为每个请求增加了一个小的网络跳跃和处理延迟。这通常与LLM推理时间相比可以忽略不计，但仍是一个因素。
• 配置复杂性： 选择和配置正确的策略、健康检查和超时，需要根据观察到的流量模式和性能目标进行仔细调整。
• 冷启动： 当自动伸缩添加新实例时，会存在一个延迟，因为实例需要启动、容器需要开始，并且大型模型需要加载到GPU内存中（即“冷启动”）。负载均衡器根据健康检查信息，必须等到实例完全就绪后才能向其发送流量。

“总之，负载均衡是构建可伸缩且弹性LLM服务系统的基本技术。通过将请求分配到多个模型副本，它使得更高的吞吐量、更低的平均延迟和容错成为可能，从而确保你强大的语言模型能够有效处理应用需求。选择适当的策略并将其与健康检查和自动伸缩正确结合，是部署生产级LLM的重要组成部分。”