有效部署扩散模型常常需要处理耗时较长的请求，这些请求完成时间从数秒到数分钟不等，具体取决于模型复杂性、图像分辨率和采样步数。这一特性使其区别于常见的网络请求，因此需要仔细斟酌负载均衡策略。对于短时、无状态的请求，标准负载均衡技术虽然有效，但若简单应用于长时间的生成任务，可能导致资源使用效率不高和用户体验不佳。
长时间任务的挑战
传统的负载均衡器常依赖于轮询（Round Robin）或简单最少连接等算法。当任务持续时间变化大且可能较长时，这些方法可能会出现问题：
- 负载分布不均： 想象一个轮询设置，将请求分发给三个工作者。如果工作者1收到一个60秒的任务，接着工作者2收到一个5秒的任务，然后工作者3又收到一个60秒的任务，那么下一个请求可能会回到工作者1（现在比工作者3稍微不那么忙，但仍大量被占用）或工作者2（它是空闲的）。简单的算法不考虑正在进行的工作的持续时间或实际负荷，只考虑连接数或到达顺序。这会导致一些工作者空闲，而另一些则被长时间任务完全占用。
- 连接超时： 许多负载均衡器（包括硬件和软件，以及云服务提供商的负载均衡器，如AWS ELB/ALB或GCP Load Balancer）的默认空闲超时设置远短于扩散模型推理 (inference)可能需要的时间。如果在生成过程中，例如30或60秒内没有数据来回传输，负载均衡器可能会过早地终止连接，即使工作者正在正确处理，用户的请求也会因此失败。
- 状态管理（隐式）： 虽然推理过程本身对于每个请求通常是无状态的（根据输入生成图像，不依赖于同一用户的先前交互），但其持续时间长会产生一种隐式状态。客户端（或API网关）与特定工作者之间的连接必须在任务的整个持续时间内保持。这与连接通常短暂的常见网络请求显著不同。
长时间任务的负载均衡算法
为应对这些问题，我们需要改进算法并考虑更充分考虑任务持续时间和工作者可用性的策略。
最少连接
该算法将新请求导向活动连接数最少的服务器。对于可变工作负载，它通常优于轮询，因为它试图更均匀地分配连接。然而，它仍然假设所有连接代表大致相等的负载，这对于扩散模型来说并非如此，因为一个连接可能代表一个5秒的任务，而另一个则代表一个90秒的任务。
加权算法（加权轮询 / 加权最少连接）
如果您的工作者集群包含异构实例（例如，有些配备比其他更快的GPU），加权算法允许您根据容量分配权重 (weight)。一个具有双倍容量的工作者可能会收到两倍的请求（在加权轮询中），或者其连接数会相应地进行调整（在加权最少连接中）。这有助于有效使用功能更强的实例，但它本身并不能解决配置相同的工作者上任务时长不定的问题。
最少未完成请求 / 应用层负载均衡
一种更精细的方案涉及根据更贴近实际进行的工作的指标来做负载均衡。这通常需要应用层面的信息：
- 队列深度： 如果使用基于队列的系统（如第4章所述），负载均衡器（或更确切地说，工作者扩缩机制）可以监控请求队列的深度。工作者在准备好时会拉取任务。
- 自定义指标： 工作者可以暴露自定义指标，例如当前正在处理的任务数量、进行中任务的预估剩余时间或当前GPU占用率。自定义负载均衡机制或能够查询这些指标的高级负载均衡器可以做出更明智的路由决定。这通常需要与Prometheus等监控系统集成或使用服务网格功能。
架构调整
实现有效的负载均衡通常涉及在选择算法方面的架构调整。
负载均衡器配置：超时设置很重要
这通常是首要且非常重要的调整。请确保您的负载均衡器上配置的空闲超时时间长于扩散模型任务的最大预期推理 (inference)时间。
- 面向客户端的负载均衡器： 面向最终用户或API客户端的负载均衡器需要较长的超时设置。
- 内部负载均衡器： 如果您有多层架构（例如，负载均衡器 -> API服务 -> 负载均衡器 -> 工作者），请确保每个环节的超时设置都合适。
- 应用服务器超时： Web服务器或框架（如Gunicorn、uvicorn）也可能有自己的超时设置，需要进行调整。
同时考虑keep-alive设置，以便在适当情况下高效复用连接，尽管主要关注点是活跃处理过程中的空闲超时。
健康检查
标准健康检查通常只验证端口是否开放或简单的/health端点是否返回200 OK。对于长时间运行的任务，这并不足够。一个工作者可能处于活动状态，但已被长时间任务完全占用，无法立即接受新工作。健康检查理想情况下应反映工作者接受新请求的能力。
- 就绪探测（Kubernetes）： 使用就绪探测来指示Pod是否可以处理流量。一个正在处理最大数量并发长时间任务的Pod可能会暂时变为“未就绪”。
- 自定义健康端点： 实现仅当工作者有可用容量时（例如，GPU内存可用，处理槽位空闲）才报告
OK的端点。
使用消息队列解耦
如前所述，使用消息队列（如RabbitMQ、SQS、Kafka或带有适当后端的Celery）在管理长时间运行任务方面提供了显著优势。
- API前端： 接收请求，执行验证，将任务详细信息放入队列，并立即向客户端返回任务ID或确认（异步模式）。这里的负载均衡器处理短时API请求。
- 工作者池： 工作者在有容量时独立地从队列中拉取任务。负载均衡通过工作者的拉取速率和队列系统隐式处理。自动扩缩可以基于队列长度进行。
这种架构自然地处理可变任务持续时间，并防止长时间任务阻塞API层。
图示一个基于队列的架构，用于处理长时间运行的扩散模型任务。客户端通过负载均衡器与API服务器交互。API服务器将任务放入队列。工作者从队列中拉取任务，从而有效解耦长时间的推理过程与初始请求，并简化负载均衡。
总结
需要考虑的重要事项包括：
- 选择合适的算法： 最少连接是一个改进，但应用感知的策略（最少未完成请求、自定义指标）或基于队列的解耦通常能提供更好的负载分布。
- 配置长时间超时： 确保负载均衡器和应用服务器的空闲超时时间显著长于任务的最大预期持续时间。
- 设计有意义的健康检查： 使用能够反映工作者实际接受新的、可能长时间运行的任务能力的健康检查（如Kubernetes就绪探测）。
- 运用异步处理： 采用消息队列可以将请求处理与长时间运行的推理 (inference)过程解耦，从而简化负载均衡并提升系统的弹性和可伸缩性。
通过仔细考虑这些因素，您可以构建一个负载均衡系统，该系统能够高效使用您的GPU资源，并为高要求的生成工作负载提供稳定服务。
