llm-gateway

用途

LLM Gateway 是一个统一的 API 网关，用于在多个 LLM 供应商与自托管模型之间路由请求，并提供速率限制、成本追踪、缓存与故障转移能力。

适用场景包括：

在单一端点后运行多个 LLM 后端（OpenAI、Anthropic、vLLM、Ollama）
对每个团队或用户强制执行速率限制与支出预算
在供应商宕机时实现自动回退
添加语义缓存以降低 API 成本
集中管理 API 密钥，而不是将密钥分发到每个应用

主要能力

多后端路由与负载均衡：支持 OpenAI、Anthropic 以及自托管 vLLM 实例，同一 model_name 配置多个副本可自动负载均衡。
路由策略：支持 least-busy、latency-based、simple-shuffle 等策略，并可配置重试次数、重试间隔、允许失败次数与冷却时间。
故障回退：通过 fallbacks 配置在主模型失败时切换到备用模型。
语义缓存：基于 Redis 的缓存，可设置相似度阈值（如 0.90），资料称可降低 API 成本 20–50%。
虚拟密钥与预算控制：可为团队生成虚拟 API 密钥，限制可用模型、最大预算、预算周期、RPM 与 TPM。
成本追踪：提供按密钥、按模型的支出查询接口。
日志与可观测性：支持将成功与失败回调发送到 Langfuse。
Nginx 负载均衡补充方案：提供基于 least_conn 的 vLLM 副本轮询、按密钥限流以及 SSE 流式传输所需的 proxy_buffering off 配置。

使用方式

前置条件：Docker 与 Docker Compose；PostgreSQL 或 SQLite 数据库（用于 LiteLLM 状态）；LLM API 密钥或自托管 vLLM 端点；可选 Redis 用于缓存与限流。

快速启动（Docker）：

docker run -d \
  --name litellm-proxy \
  -p 4000:4000 \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  -v $(pwd)/litellm-config.yaml:/app/config.yaml \
  ghcr.io/berriai/litellm:main-latest \
  --config /app/config.yaml \
  --detailed_debug

配置文件 litellm-config.yaml 中定义 model_list（模型名称、litellm_params、api_key、rpm、tpm、api_base 等）、router_settings（routing_strategy、num_retries、retry_after、allowed_fails、cooldown_time、fallbacks）、litellm_settings（cache、cache_params、success_callback、failure_callback、langfuse 密钥）以及 general_settings（master_key、database_url、store_model_in_db）。

完整网关栈可通过 Docker Compose 部署，包含 litellm、postgres、redis 三个服务，并配置健康检查与数据卷。

虚拟密钥与限流示例：

curl -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "team-backend",
    "key_alias": "backend-team-key",
    "models": ["gpt-4o-mini", "llama-3.1-8b"],
    "max_budget": 100,
    "budget_duration": "monthly",
    "rpm_limit": 100,
    "tpm_limit": 500000
  }'

查看支出：

curl http://localhost:4000/spend/keys \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

健康监控接口：

curl http://localhost:4000/health
curl http://localhost:4000/health/liveliness
curl http://localhost:4000/spend/models \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"
curl http://localhost:4000/key/list \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

Nginx 可作为替代或补充的负载均衡层，配置 upstream 使用 least_conn、max_fails、fail_timeout、keepalive，并设置 limit_req_zone 按 Authorization 头限流，location /v1/ 中设置 proxy_read_timeout 300s、proxy_buffering off 以支持 SSE 流式传输。

适用场景

多团队或多应用共享 LLM 资源，需要按团队分配密钥与预算。
自托管 vLLM 多副本部署，需要负载均衡与故障转移。
需要降低重复或相似查询的 API 成本。
需要集中审计与成本归因。

限制与注意事项

资料未提供具体收费、价格或平台信息。
常见问题包括：后端不可达导致 ConnectionRefusedError；超出预算或 RPM 导致 429；Nginx 开启 proxy_buffering 导致流式响应变慢；相似度阈值过严导致缓存命中率低；Postgres 未就绪导致连接错误。
最佳实践：为每个团队或应用使用虚拟密钥，不暴露原始供应商密钥；启用 Redis 缓存；设置重试与回退；将请求日志发送到 Langfuse 或 OpenTelemetry；自托管模型使用 least-busy 路由策略以避免 GPU 饱和。
相关技能：vllm-server、llm-inference-scaling、llm-caching、llm-cost-optimization。

技能介绍

用途

主要能力

使用方式

适用场景

限制与注意事项