统一AI API网关
统一接入多个LLM供应商，实现负载均衡、故障转移、成本优化、用量管控。
项目概述
企业在使用 LLM 的过程中，通常会接入多个供应商（OpenAI、Anthropic、Google、DeepSeek 等）和多种模型（GPT-4、Claude、Gemini）。每个供应商有不同的 API 风格、定价策略、限流规则，底层架构也可能随时变更。如果每个业务团队各自对接，不仅开发成本高、重复造轮子，还难以统一管控成本和安全。
本案例展示了一个基于 LiteLLM 的统一 AI API 网关。网关作为 LLM 流量的唯一入口，实现供应商透明切换、负载均衡、自动故障转移、成本优化、用量监控和权限管控。
关键指标
系统架构
以 LiteLLM 为核心路由引擎，Redis 作为缓存和限流后端，Prometheus + Grafana 实现可观测性，Kong API 网关提供外部统一入口。
┌──────────────────────────────────────────────────────┐ │ 业务应用 / AI Agent 层 │ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ │ │ Chatbot│ │ Agent │ │ RAG │ │ 分析 │ │ │ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │ │ │ │ │ │ ├──────┴───────────┴───────────┴───────────┴──────────┤ │ Kong API 网关 (统一端点) │ ├──────────────────────┬──────────────────────────────┤ │ LiteLLM 路由引擎 │ │ ┌──────────────────────────────────────────────┐ │ │ │ ┌────────┐ ┌───────┐ ┌──────┐ ┌──────┐ │ │ │ │ │ 负载均衡│→│ 故障转移│→│ 成本 │→│ 重试 │ │ │ │ │ └────────┘ └───────┘ └──────┘ └──────┘ │ │ │ └──────────────────────────────────────────────┘ │ ├──────────┬──────────┬──────────┬──────────┬─────────┤ │ OpenAI │ Claude │ Gemini │ DeepSeek │ 其他 │ │ GPT-4o │ Sonnet │ Pro 2.0 │ V3/R1 │ Llama │ │ GPT-4o- │ Haiku │ Flash │ │ Qwen │ │ mini │ │ │ │ │ ├──────────┴──────────┴──────────┴──────────┴─────────┤ │ 可观测性 & 基础设施 │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Prometheus│ │ Grafana │ │ Redis │ │ │ │ 指标收集 │ │ 仪表盘 │ │ 缓存/限流 │ │ │ └──────────┘ └──────────┘ └──────────┘ │ └──────────────────────────────────────────────────────┘
实现细节
路由与负载均衡
供应商抽象
LiteLLM 提供统一接口，将 15+ 供应商的 API 差异（认证方式、请求格式、流式/非流式、模型命名）封装为一致的 OpenAI-compatible 接口。
智能路由策略
支持多种路由策略：Round-Robin（默认）、Least-Load（最低负载）、Latency-Based（最低延迟）、Cost-Optimized（最低成本）。可按业务场景配置不同策略。
模型别名管理
通过模型别名实现供应商透明切换。如将 "gpt-4o" 别名映射到 "claude-sonnet-4"，上游完全无感知。切换后只需更改 LiteLLM 的 config，无需修改业务代码。
故障转移与容错
自动故障检测
持续监控每个模型的健康状态（HTTP 5xx、超时、限流 429）。连续 3 次失败自动标记为不健康，从路由池中移除。
级联降级
配置降级链：如 "gpt-4o → claude-sonnet → gemini-pro → gpt-4o-mini"。高级模型不可用时自动降级到次优模型，确保业务不中断。
智能重试
对可恢复的错误（限流、超时）自动重试。支持指数退避、抖动（jitter）、指定重试次数。限流错误增加 0.5-2 秒随机延迟后重试，成功率 95%+。
成本优化与管控
成本路由
Cost-Optimized 策略根据实时成本数据自动选择最便宜的可用模型。对于非关键请求（如数据摘要、内容分类），优先使用低成本模型。
预算管控
按团队、项目、模型设置月度预算上限。达到阈值后自动告警、降级或限制。支持预算滚动周期（月度/季度/年度）。
用量监控
每 15 秒收集一次指标：输入/输出 Token 数、请求延迟、错误率、成本累计。Grafana 仪表盘实时展示，支持按团队、模型、时间段多维度下钻。
LiteLLM 网关配置
# config.yaml — LiteLLM 网关配置
model_list:
# 主模型：GPT-4o
- model_name: gpt-4o
litellm_params:
model: openai/gpt-4o
api_key: os.environ/OPENAI_API_KEY
model_info:
tier: premium
cost_per_input_token: 0.000005
cost_per_output_token: 0.000015
# 备用模型：Claude Sonnet
- model_name: gpt-4o
litellm_params:
model: anthropic/claude-3.5-sonnet
api_key: os.environ/ANTHROPIC_API_KEY
model_info:
tier: premium
# 降级模型：Gemini
- model_name: gpt-4o
litellm_params:
model: gemini/gemini-1.5-pro
api_key: os.environ/GEMINI_API_KEY
model_info:
tier: standard
# 经济模型：用于非关键请求
- model_name: gpt-4o-mini
litellm_params:
model: openai/gpt-4o-mini
api_key: os.environ/OPENAI_API_KEY
model_info:
tier: economy
router_settings:
routing_strategy: latency-based # 或 cost-optimized
fallbacks:
- gpt-4o: [claude-3.5-sonnet, gemini-1.5-pro, gpt-4o-mini]
retry_policy:
max_retries: 3
retry_on_status: [429, 500, 502, 503]
backoff_base: 1.0
backoff_exponent: 2.0
general_settings:
alerting:
slack_webhook_url: os.environ/SLACK_WEBHOOK
budget_alerts:
- threshold: 75%
action: warn
- threshold: 90%
action: degrade
- threshold: 100%
action: block
cache:
type: redis
host: os.environ/REDIS_HOST
port: 6379
ttl: 3600
max_parallel_requests: 100
request_timeout: 120经验教训
- 模型别名是杀手特性 — 部署初期不要告诉业务团队底层用的具体模型，通过别名抽象后，切换供应商时完全无感。就连 OpenAI 断供 GPT-4 时我们 5 分钟就切到了 Claude
- 成本路由需要业务打标 — 只有对请求做了优先级标记（critical/standard/batch），才能让成本优化策略生效。一开始所有请求都是 critical，成本根本降不下来
- 缓存策略收益极高 — 对于 idempotent 请求（如数据分类、摘要），开启 Redis 缓存后命中率可达 30-40%，大幅降低成本和延迟
- 可观测性要早于做 — 没有监控就不知道哪个模型有问题、哪个团队花最多钱。建议网关上线第一天就接好 Prometheus + Grafana