SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场llm-gateway

llm-gateway

部署与运维

查看项目

更新于 10-27 02:31

技能介绍

用途 LLM Gateway 是一套统一 API 网关方案，用于把面向多家模型供应商和自托管模型的 LLM 请求收敛到单一端点，并在网关层集中处理限流、成本追踪、缓存与故障转移。主要实现基于开源的 LiteLLM Proxy，其对外提供 OpenAI 兼容 API。

适用场景（资料列举）

  • 在单一端点后运行多个 LLM 后端，例如 OpenAI、Anthropic、vLLM、Ollama。
  • 按团队或按用户实施速率限制与支出预算。
  • 在供应商不可用时实现自动回退。
  • 在工作负载测量支持的前提下加入语义缓存，减少重复请求成本。
  • 集中管理 API 密钥，而不是把密钥分发到每个应用。

前置条件

  • Docker 与 Docker Compose。
  • PostgreSQL 或 SQLite 数据库（用于 LiteLLM 状态）。
  • LLM API 密钥（OpenAI、Anthropic 等）或自托管 vLLM 端点。
  • 可选：Redis 用于缓存与限流。

主要能力

  • 多模型路由：通过 litellm-config.yaml 的 model_list 定义模型，可为每个模型设置 model、api_key、rpm、tpm 等参数。
  • 负载均衡：同一 model_name 配置多个部署（如两台 vLLM 副本）即自动负载均衡；router_settings 支持 least-busy、latency-based、simple-shuffle 等路由策略，以及 num_retries、retry_after、allowed_fails、cooldown_time。
  • 故障回退：通过 fallbacks 配置回退链路（示例为 gpt-4o 回退到 gpt-4o-mini）。
  • 缓存：litellm_settings.cache 开启缓存，示例使用 Redis 作为后端。
  • 日志与可观测性：success_callback 与 failure_callback 示例使用 langfuse。
  • 虚拟密钥与配额：通过 /key/generate 接口为团队创建虚拟密钥，可设定允许的模型列表、max_budget、budget_duration、rpm_limit、tpm_limit；通过 /spend/keys、/spend/models、/key/list 查询花费与密钥。
  • 健康检查：/health 与 /health/liveliness。
  • Nginx 作为替代或补充：示例提供 upstream 的 least_conn、max_fails、fail_timeout、keepalive，limit_req_zone 按 Authorization 头限流，以及为 SSE 流式响应设置 proxy_buffering off 与较长 proxy_read_timeout。

使用方式

  1. 用 Docker 启动 LiteLLM Proxy，挂载 litellm-config.yaml，通过环境变量注入 OPENAI_API_KEY、ANTHROPIC_API_KEY，端口示例为 127.0.0.1:4000。
  2. 编写 litellm-config.yaml，定义 model_list、router_settings、litellm_settings 与 general_settings（master_key、database_url、store_model_in_db）。
  3. 可用 Docker Compose 组合 litellm、postgres:16-alpine、redis:7-alpine 三个服务，并配置 depends_on 健康检查与数据卷。
  4. 使用 master key 调用 /key/generate 创建带预算与限流的虚拟密钥，再供各应用使用。
  5. 通过健康检查与花费接口监控网关状态。

常见问题（资料表格）

  • 连接后端被拒：检查 api_base、确认后端健康。
  • 429 限流错误：预算或 RPM 超限，提高限额或切换到回退模型。
  • 流式响应慢：Nginx 开启了 proxy_buffering，应关闭。
  • 缓存命中率低：阈值过严，可下调 similarity_threshold 至 0.85。
  • Postgres 连接错误：数据库未就绪，补充 depends_on 的 service_healthy 条件。

限制与注意事项

  • 该资料为仅文档导入，上游脚本与模板未随附，示例配置为示意性参考，并非已做生产安全加固的栈：应固定经审查的镜像摘要、要求强网关主密钥与带认证的 TLS 入口、替换示例数据库凭据、保护数据库与 Redis 网络。
  • 重复的 model_name 条目实现的是负载均衡，并不保证有序回退；需显式配置无环的回退策略，并披露供应商或模型的替换。
  • 普通 Redis 缓存不自动等同于语义向量缓存，需验证所选后端与 schema；缓存键应按租户、授权、模型配置与内容版本分区；不得跨用户缓存敏感或携带操作的响应。
  • 基于请求头的 Nginx 限流键不验证身份，也无法阻止客户端改动任意请求头。
  • 配额错误应进行预算审查，而非自动提高限额。
  • 缓存正确性与命中率需在实际工作负载上测量，不保证固定比例的节省。
  • 日志应只记录允许清单内的运维元数据；私有提示与响应追踪需要明确的数据传输与保留范围。
  • 基础设施命令可能中断服务，变更前需确认目标主机与范围并准备备份或快照。
  • 自托管模型建议使用 least-busy 路由避免 GPU 饱和。