在企业级 AI 平台中，LLM 网关已从「可选组件」演变为「基础设施」。随着模型提供商数量的增加和流量规模的增长，如何在多个部署之间高效分配请求、保证故障时的服务连续性、控制推理成本，成为网关层必须解决的核心工程问题。LiteLLM 作为当前最成熟的开源 LLM 代理方案，其负载均衡与 Guardrails 机制经过大量生产环境验证，能够为团队提供一套开箱即用的高可用路由方案。

负载均衡策略的选择与配置

LiteLLM Router 支持五种核心路由策略，每种策略适用于不同的业务场景。simple-shuffle 是最基础的策略，每次请求随机选择一个可用的 deployment，实现简单但无法感知各节点的负载状态，适合模型能力完全对等且流量较小的场景。least-busy 策略会根据 Redis 中记录的实时请求数，选择当前负载最低的节点，这种策略在高并发场景下表现优异，能够有效避免单点过载。latency-based 策略会优先选择历史延迟最低的 deployment，适合对响应时间敏感的任务型应用。usage-based 策略严格遵守预设的 RPM 或 TPM 配额，适合需要精细控制各 provider 调用量的场景。cost-based 策略则会自动选择成本最低的可用模型，适合成本敏感的批量处理场景。

实际生产环境中，最常用的组合是 cost-based 配合 least-busy 作为降级策略。主路由层按成本选择，但当成本最低的节点达到配额上限或响应变慢时，自动切换到其他可用节点。这种组合方式在成本控制和服务可用性之间取得了良好的平衡。路由策略通过 routing_strategy 参数在 router_settings 中配置，例如 routing_strategy: cost-based 即可启用成本优先策略。

分布式状态共享与容量控制

当部署多个 LiteLLM Proxy 实例时，需要在各实例之间共享各 deployment 的实时使用量、冷却状态等信息，以确保路由决策的一致性。LiteLLM 通过 Redis 实现这一功能。配置时只需要在配置文件中指定 Redis 的 host、port 和 credentials，Router 会自动将每个 deployment 的 RPM/TPM 计数写入 Redis，并在每次路由决策前读取最新的使用量。

容量控制的配置围绕两个核心参数展开：rpm（Requests Per Minute）和 tpm（Tokens Per Minute）。为每个 deployment 设置合理的配额上限，能够防止某个 provider 被流量打满而导致限流。实践中建议将配额定为该 provider 官方限流的 80% 左右，留有一定的 buffer 应对突发流量。例如某 Azure deployment 的官方限流为 3000 RPM，则配置时建议设置为 2400 RPM。配置示例中可以看到，同一个模型可以配置多个 deployment，Router 会自动在它们之间分配流量。

Guardrails 机制：超时、重试与冷却

生产环境中的 LLM 调用面临诸多不稳定因素：provider 服务抖动、网络瞬时超时、模型响应质量波动。Guardrails 机制是 LiteLLM 在网关层面为这些问题提供的统一解决方案。

超时控制通过 timeout 参数设置，单位为秒。默认超时通常设为 30 秒，但对于某些响应时间较长的模型（如大上下文任务），可以适当延长到 60 秒。超时设置过短会导致频繁误判 provider 不可用，过长则影响用户体验。建议在实际部署前对各 provider 的典型响应时间进行测量，然后设置为典型值的 1.5 到 2 倍。

重试机制是应对瞬时故障的核心手段。LiteLLM 支持两种重试策略：固定间隔重试和指数退避重试。固定间隔适合稳定的 provider 环境，重试间隔通常设为 1-2 秒。指数退避适合处理偶发性故障，首次重试间隔设为 1 秒，之后每次重试间隔翻倍（1 秒、2 秒、4 秒），最大重试次数通过 num_retries 参数控制，建议设为 2-3 次。超过重试次数后，Router 会尝试 fallback 到备选 deployment。

冷却机制用于在某个 deployment 连续失败后暂停一段时间，避免持续向故障节点发送请求。冷却时间通过 cooldown_time 参数配置，通常设为 30-60 秒。冷却机制与 fallback 机制的配合逻辑是：当某个 deployment 触发冷却后，Router 会自动将后续请求路由到 fallback list 中的备选模型，待冷却时间结束后再尝试恢复。

Fallback 配置与高可用保障

Fallback 是高可用保障的最后一道防线。LiteLLM 支持为每个模型配置 fallback 模型列表，当主模型不可用时按顺序尝试备用选项。配置时需要在 fallbacks 字段中指定一个模型数组，例如 [{"gpt-4o": ["gpt-4-turbo", "gpt-3.5-turbo"]}] 表示当 gpt-4o 不可用时依次尝试 gpt-4-turbo 和 gpt-3.5-turbo。

选择 fallback 模型时需要考虑两个因素：能力兼容性和行为一致性。从 Claude 切换到 GPT-4o 可能导致响应风格明显不同，从而影响用户体验。因此建议在同一个 provider 的不同模型之间设置 fallback，或者选择能力定位相近的模型。此外，fallback 机制会增加请求的端到端延迟，因为需要等待主模型超时或失败后才开始调用 fallback 模型。对于延迟敏感的场景，可以在主模型配置中设置较短的超时（如 15 秒），加快 fallback 触发。

部署配置模板与监控要点

以下是生产环境部署 LiteLLM Proxy 的核心配置模板，涵盖了负载均衡、Guardrails 和 Redis 状态共享的关键参数：

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: azure/azure-gpt-4o
      api_base: https://your-resource.openai.azure.com/
      api_key: ${AZURE_API_KEY}
      rpm: 2400
      tpm: 400000
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: ${OPENAI_API_KEY}
      rpm: 500
      tpm: 150000

router_settings:
  routing_strategy: cost-based
  num_retries: 2
  timeout: 30
  retry_after: 1
  cooldown_time: 30

redis_host: your-redis-host.redis.cache.windows.net
redis_port: 6380
redis_password: ${REDIS_PASSWORD}

部署后的监控需要关注四个核心指标：P50/P95/P99 延迟反映网关和 provider 的响应表现，各 deployment 的 RPM/TPM 使用率用于评估配额是否合理，错误率按 provider 拆解用于快速定位故障节点，Fallback 触发频率用于评估主模型的可用性状况。这些指标可以通过 LiteLLM 内置的日志端点采集，对接到 Prometheus 或 Grafana 构建可视化仪表盘。

资料来源：LiteLLM 官方负载均衡文档（https://docs.litellm.ai/docs/proxy/load_balancing）及路由策略文档（https://docs.litellm.ai/docs/routing）