AI 推理的负载均衡：在 1000+ GPU 上分发请求

更新于 2025 年 12 月 8 日

2025 年 12 月更新： 连续批处理（vLLM、TensorRT-LLM）正在变革负载均衡——动态批次组建已成为标准。Kubernetes Gateway API 在 AI 推理路由中获得广泛采用。多模型服务（Triton Inference Server 2.40+）实现高效 GPU 共享。前缀缓存将 KV 缓存开销降低 40-60%。请求路由现在会考虑提示词相似性以提高缓存命中率。无服务器 GPU 推理（Modal、Beam、RunPod）以高性价比处理突发流量。

负载均衡决定了 AI 推理系统能否实现 95% 的 GPU 利用率，还是因请求分配效率低下而浪费 40% 的计算资源。当 OpenAI 每天在 128,000 个 GPU 上处理 1 亿次 ChatGPT 请求时，复杂的负载均衡算法能防止任何单个 GPU 成为瓶颈，同时避免其他 GPU 闲置。简单轮询与智能负载均衡之间的差异意味着数百万美元的基础设施成本差距，并决定用户体验的响应时间是 50ms 还是 500ms。本指南将探讨经过生产验证的策略，用于在大规模 GPU 集群中分发推理工作负载。

AI 工作负载的负载均衡基础

AI 推理工作负载具有独特特性，传统负载均衡算法难以有效处理。请求处理时间根据输入序列长度可相差 100 倍——BERT 处理 10 个 token 仅需 5ms，但处理 512 个 token 则需要 250ms。随着键值缓存在生成过程中增长，内存消耗会动态波动。批次组建机会仅存在于延迟 SLA 到期前的狭窄时间窗口内。这些因素要求采用超越传统 Web 服务策略的 AI 专用负载均衡方法。

与无状态 Web 应用相比，有状态模型服务使负载分配变得复杂。每个 GPU 维护着消耗 20-140GB 内存的模型权重，无法快速迁移。模型加载后的预热期需要 50-100 次推理才能达到最佳性能。对话式 AI 的会话亲和性需要在多个请求之间保持上下文。模型版本控制意味着不同 GPU 可能同时服务不同的模型迭代版本。这些约束限制了请求路由决策的灵活性。

大规模部署中 GPU 硬件的异构性影响负载均衡的效果。在同一集群中，A100 GPU 处理请求的速度比 V100 快 1.7 倍。16GB 到 80GB 的内存差异决定了最大批处理大小。散热不良的 GPU 会因热节流导致性能下降 20%。网络拓扑差异导致负载均衡器与 GPU 节点之间的延迟各不相同。智能负载均衡必须考虑这些硬件差异以优化整体吞吐量。

推理工作负载的延迟敏感性限制了负载均衡策略。面向用户的应用要求 P95 延迟低于 100ms，这限制了队列深度。自动驾驶等实时应用需要确定性的 20ms 以下响应。为提高吞吐量而延迟批次组建必须与延迟要求相平衡。地理分布增加的往返时间是负载均衡无法消除的。这些约束通常与吞吐量优化目标相冲突。

多租户需求为负载均衡带来了公平性和隔离性挑战。不同客户可能有不同的 SLA 和优先级，需要差异化处理。资源配额防止单个租户独占 GPU 容量。服务质量保证确保无论系统整体负载如何都能达到最低吞吐量。计费准确性依赖于精确的请求归属和资源消耗追踪。负载均衡器必须在保持效率的同时执行这些策略。

架构模式与拓扑

集中式负载均衡架构将所有请求汇集到专用负载均衡层。NGINX Plus 或 HAProxy 实例根据可配置算法将请求分发到 GPU 工作节点。健康检查持续监控 GPU 可用性和性能指标。粘性会话在需要有状态交互时保持客户端亲和性。这种架构简化了管理，但在负载均衡层可能产生潜在瓶颈。Netflix 使用集中式负载均衡处理其推荐推理，每天处理 50 亿次请求。

分布式负载均衡将路由逻辑嵌入客户端应用或服务网格中。客户端维护 GPU 注册信息并直接做出路由决策。Istio 或 Linkerd 服务网格提供带有熔断器的透明负载均衡。这消除了中心瓶颈，但增加了客户端复杂性和协调开销。Uber 的 Michelangelo 平台实现了分布式负载均衡，使其 GPU 集群能够每秒处理 100 万次预测。

分层负载均衡结合全局和本地分发层以实现大规模扩展。全局负载均衡器根据地理位置和容量跨区域分发。区域负载均衡器考虑网络邻近性路由到可用区。区域内的本地负载均衡器处理细粒度的 GPU 分配。这种多层方法可扩展到数十万个 GPU，同时保持区域故障转移能力。Google 为 YouTube 推荐服务在 14 个全球区域实施分层负载均衡。

无服务器负载均衡完全抽象了基础设施，根据请求模式自动扩展。AWS Lambda 或 Google Cloud Run 将推理请求路由到临时 GPU 容器。冷启动影响初始请求延迟，但后续请求可达到毫秒级响应时间。自动扩展消除了容量规划，但增加了每请求成本。这种模式适合对偶发延迟峰值有一定容忍度的可变工作负载。Snapchat 的 AR 滤镜使用无服务器 GPU 推理，每天处理 50 亿次请求并自动扩展。

边缘负载均衡将推理分布到地理上分散的边缘位置。内容分发网络将请求路由到最近的支持 GPU 的接入点。5G 多接入边缘计算为移动应用实现低于 10ms 的延迟。负载均衡必须考虑广域网带宽成本和边缘容量限制。跨边缘位置的模型同步使版本管理变得复杂。Cloudflare 的 Workers AI 在 285 个城市实现边缘推理，与集中式服务相比延迟降低 60%。

算法选择与优化

最少连接算法将请求路由到活动连接数最少的 GPU，近似实现负载分配。简单实现仅需连接计数，无需深入检查工作负载。然而，对于大小各异的请求，连接数与实际 GPU 利用率的相关性较差。长时间运行的生成请求尽管看起来是单个连接，却会使分配产生偏差。增强版本根据估计处理时间对连接进行加权，提高了均衡质量。此算法适合处理时间可预测的同质工作负载。

加权轮询根据处理能力为 GPU 分配不同权重。H100 GPU 的权重可能是 A100 的 2 倍，反映性能差异。权重根据观察到的吞吐量和延迟指标动态调整。慢启动机制逐步增加新添加 GPU 的流量。这种方法有效处理异构硬件，但需要准确的权重校准。Amazon SageMaker 对多实例端点使用加权轮询，比简单轮询提高 15% 的利用率。

最短响应时间路由为新请求选择最近响应时间最低的 GPU。移动平均平滑临时峰值，同时捕捉性能趋势。响应时间预测结合请求特征（如 token 数量）。网络延迟测量将传输与处理延迟分离。此算法能适应变化条件，但在负载下可能出现振荡。Microsoft 的 Azure ML 实施响应时间路由，将 P99 延迟降低 30%。

队列深度均衡在路由决策时考虑每个 GPU 的待处理请求。队列较短的 GPU 接收新请求，保持积压均衡。估计完成时间比简单队列长度指标更准确。优先级队列确保高优先级请求不会等待在批处理作业之后。队列深度可见性需要与 GPU 服务基础设施紧密集成。Anthropic 使用队列深度均衡服务 Claude，在可变负载下保持一致的响应时间。

预测性负载均衡使用机器学习预测最佳请求路由。历史模式训练模型，从请求特征预测处理时间。时间序列分析预测负载峰值，实现主动扩展。强化学习通过持续实验优化路由策略。这些复杂方法能实现卓越性能，但需要大量开发投入。Meta 的 AI 基础设施采用学习型负载均衡，比启发式算法提高 25% 的吞吐量。

实现技术与工具

NGINX Plus 提供企业级负载均衡，并针对 GPU 进行了专门增强。upstream 模块支持通过 API 动态管理后端。主动健康检查在数秒内检测 GPU 故障。请求缓冲和重试逻辑优雅地处理瞬时故障。实时指标暴露请求率、错误率和延迟百分位数。自定义 Lua 脚本可实现复杂的路由逻辑。GPU 负载均衡的配置示例：

upstream gpu_backend {
    zone gpu_zone 64k;
    least_conn;
    server gpu1.internal:8080 weight=2 max_fails=2 fail_timeout=30s;
    server gpu2.internal:8080 weight=1 max_fails=2 fail_timeout=30s;
    keepalive 32;
}

HAProxy 提供高性能负载均衡，具有丰富的算法选项。运行时 API 支持零停机重新配置以进行扩展操作。粘性表在请求之间保持会话持久性。高级健康检查包括用于 GPU 特定验证的自定义协议。连接复用减少 HTTP/2 gRPC 推理 API 的开销。OpenAI 使用 HAProxy 服务 ChatGPT，处理数百万并发连接。

Envoy Proxy 提供现代云原生负载均衡，具有广泛的可观测性。指数退避的自动重试处理临时 GPU 不可用情况。熔断器防止 GPU 过载时的级联故障。异常检测自动从轮换中移除性能不佳的实例。原生 gRPC 支持优化张量数据传输。速率限制和准入控制防止过载情况。Lyft 的机器学习平台使用 Envoy 管理所有 GPU 流量。

Kubernetes 原生解决方案将负载均衡与容器编排集成。Istio 等服务网格实现提供透明负载均衡。Gateway API 支持基于请求头或路径的高级路由。Horizontal Pod Autoscaler 根据指标调整 GPU Pod 数量。自定义资源定义对 GPU 特定需求和约束进行建模。这种集成简化了运维，但可能缺乏 GPU 特定优化。Spotify 使用 Kubernetes ingress 在 2,000 个 GPU 上提供 ML 模型服务。

应用层负载均衡器将路由逻辑嵌入服务框架中。TensorFlow Serving 包含内置的请求批处理和路由功能。Triton Inference Server 实现带有优先级调度的动态批处理。Ray Serve 为 ML 工作负载提供 Python 原生负载均衡。这些解决方案与 ML 框架紧密集成，但可能缺乏运维成熟度。Instacart 的 ML 平台使用 Ray Serve

[内容因翻译需要而截断]