基于GPU的AI服务：负载均衡按GPU利用率路由请求的实现问询

一、能不能让负载均衡器按GPU内存利用率路由请求？ #

可以实现，但AWS Application Load Balancer（ALB）的原生轮询策略做不到这点，需要通过自定义扩展或者搭配专门工具来实现。

二、具体实现方案 #

1. 基于AWS生态的自定义指标路由 #

• 先给每个GPU实例部署指标采集脚本：用nvidia-smi定时获取GPU内存利用率，把数据上报到CloudWatch作为自定义指标（比如命名为GPU/MemoryUtilization）。
• 借助Lambda函数动态调整目标组权重：写一个Lambda函数，定时查询CloudWatch里各实例的GPU利用率，计算出对应的权重（GPU利用率越低，权重越高），然后调用AWS API更新Target Group中实例的权重。
• 配置ALB使用加权轮询策略：让ALB根据实例的权重分配请求，权重高的实例会收到更多请求，自然实现了向GPU空闲实例倾斜的路由逻辑。另外还可以在Lambda里过滤掉GPU利用率超过阈值（比如85%）的实例，暂时从目标组中剔除，避免把请求发过去。

2. 用专门的AI负载均衡工具 #

• Kubernetes环境：如果是用K8s部署AI服务，推荐用KServe或者Emissary Ingress。先通过nvidia-dcgm-exporter采集GPU指标，再把指标同步到Prometheus，然后让负载均衡控制器根据这些指标动态调整请求分发——比如优先把请求转发到GPU内存使用率低的节点上。
• Nginx Plus扩展：Nginx Plus支持通过API动态修改上游服务器的权重。可以写一个简单的脚本，定期从各GPU实例拉取GPU利用率数据，然后调用Nginx API更新权重，让Nginx根据GPU负载分配请求。

三、其他基于GPU负载的动态分配机制与最佳实践 #

• 请求排队+智能调度：在负载均衡器前面加一层请求队列（比如用Redis做队列），再搭配调度器（比如Celery）。调度器实时监控各实例的GPU负载，从队列里取请求分配给空闲度高的实例，避免直接把请求压到高负载节点上。
• GPU负载触发的弹性伸缩：给GPU实例组配置Auto Scaling Group（ASG），把GPU内存利用率作为伸缩触发指标——比如当利用率持续超过80%时自动加实例，低于30%时缩容。负载均衡器会自动把新实例纳入分发池，不用手动干预。
• 请求优先级区分：把请求分成不同优先级，比如低延迟要求的推理请求优先分配给GPU空闲的实例，训练类的批量请求可以调度到还有剩余容量的实例上，最大化资源利用率的同时保证核心服务的性能。
• 容器化资源隔离：在K8s里用NVIDIA GPU Operator，给每个AI服务的Pod分配固定的GPU显存配额，K8s调度器会自动把Pod调度到有足够GPU资源的节点上，再结合Ingress的负载均衡，实现更细粒度的资源利用。

内容的提问来源于stack exchange，提问作者Manjinder Singh