LLM 负载均衡：生产模式（2026）

当单个 API 密钥或端点不够用时——受限于速率限制、延迟、多区域——你需要负载均衡跨多个 LLM 端点。其中回退链处理*故障*，而负载均衡通过将流量分散到健康端点来处理*容量和延迟*。两者相辅相成。

为什么需要负载均衡

速率限制： 将请求分布到多个密钥/部署上，以提高有效吞吐量。

延迟： 路由到最近或最快的端点（例如，区域本地的 Azure 部署）。

成本/容量： 混合使用不同提供商或层级，以在负载下优化支出。

策略

轮询 / 加权： 最简单；根据每个端点的配额进行加权。

最少延迟 / 最少繁忙： 路由到当前延迟或队列最短的端点。

容量感知： 跟踪每个密钥的速率限制头部，并远离接近上限的密钥。

python
LiteLLM Router：跨部署负载均衡，自动回退
from litellm import Router
router = Router(model_list=[
    {"model_name": "gpt-4o", "litellm_params": {"model": "azure/gpt-4o", "api_base": EAST, "api_key": K1}},
    {"model_name": "gpt-4o", "litellm_params": {"model": "azure/gpt-4o", "api_base": WEST, "api_key": K2}},
], routing_strategy="least-busy", num_retries=2)
resp = router.completion(model="gpt-4o", messages=[{"role":"user","content":"hi"}])

使用网关可以避免手动实现——比较 LiteLLM vs Portkey。

结合回退 + 健康检查

健壮的设置包含三层：均衡跨健康端点，回退当某个端点失败时，以及健康检查将故障端点从轮换中移除（熔断器）。添加可观测性以查看每个端点的延迟和错误率——参见 LangSmith 用于评估/追踪。

陷阱

会话粘连： 如果不同模型的提示行为有差异，保持多轮对话在同一提供商上。

尊重速率限制头部： 对正在节流的特定密钥进行退避，而不是整个池。

不要为了均衡而牺牲正确性： 一个更便宜但回答更差的端点并不划算。

常见问题

负载均衡 vs 回退？ 均衡将负载分散到健康端点；回退挽救失败的请求。两者都使用。 最佳策略？ 最少繁忙/最少延迟以获得响应性；加权轮询用于简单的配额分配。 使用库还是自己实现？ LiteLLM Router / Portkey 提供了现成的功能。 如何剔除不良端点？ 健康检查 + 熔断器将其从轮换中移除，直到恢复。

总结

负载均衡以扩展吞吐量并降低延迟：使用最少繁忙或加权策略将请求分散到多个密钥/区域，结合回退和健康检查，尊重速率限制头部，并在模型不同时保持会话粘连。像 LiteLLM 这样的网关提供了所有这些功能。

---

*最后更新：2026 年 6 月。请对照 LiteLLM 文档验证 API。*