Python实战:手写一个LLM API统一网关,实现DeepSeek/通义千问/OpenAI多Provider自动容灾切换
通义千问又挂了?我写了一个 LLM Gateway,自动帮你切换到 DeepSeek
你的 LLM 应用,不应该因为一个 API 挂了就瘫痪。
引言
上个月通义千问 API 故障了 2 小时,我朋友的 AI 客服直接瘫痪了。用户问什么都回复"服务暂时不可用"。
其实 DeepSeek 的 API 是好的,但他的代码里只配了通义千问一个 Provider。
手动切换?改代码、改配置、重启服务,至少 30 分钟。
这个问题完全可以用一个统一网关来解决。于是我写了LLM Gateway—— 在你的应用和 LLM Provider 之间加一层,自动处理容灾、路由、统计。
你是不是也遇到过这些问题?
1. Provider 偶尔抽风
大模型 API 不稳定是常态。DeepSeek 限速、通义千问维护、OpenAI 网关超时——每个月总要来几次。你的应用停摆,用户不知道发生了什么。
2. 手动切换太慢
发现 API 挂了 → 改配置文件 → 改代码 → 测试 → 重启服务。30 分钟过去了。
3. 多个 Provider,管理混乱
DeepSeek 便宜但偶尔慢,通义千问稳定但贵,OpenAI 质量好但不稳定。每个 API 的base_url、api_key、模型名都不一样,每次切换都要翻文档。
LLM Gateway 怎么解决的?
最简单的使用方式
# 1. 安装 git clone https://github.com/Vincent-crypto-coder/llm-gateway.git cd llm-gateway pip install -r requirements.txt # 2. 配置 cp config.example.yaml config.yaml # 编辑 config.yaml,填入 API Key # 3. 启动 python -m gateway --config config.yaml --port 8000
客户端代码一行不用改
from openai import OpenAI # 只改 base_url,其他不变 client = OpenAI(api_key="any-key", base_url="http://localhost:8000/v1") response = client.chat.completions.create( model="deepseek-chat", messages=[{"role": "user", "content": "你好"}] )就这么简单。你的应用只需要指向 Gateway,它帮你搞定剩下的事情。
核心功能
自动容灾
配置多个 Provider,Gateway 自动切换:
providers: - name: deepseek base_url: https://api.deepseek.com api_key: ${DEEPSEEK_API_KEY} models: [deepseek-chat] priority: 1 # 最高优先级 - name: dashscope base_url: https://dashscope.aliyuncs.com/compatible-mode/v1 api_key: ${DASHSCOPE_API_KEY} models: [qwen-turbo, qwen-plus] priority: 2 # DeepSeek 挂了,自动切到这里 failover: strategy: priority failure_threshold: 3 # 连续失败 3 次后标记不可用 recovery_interval: 300 # 5 分钟后自动恢复DeepSeek 正常时,请求走 DeepSeek。DeepSeek 连续失败 3 次后,自动切到通义千问。5 分钟后 DeepSeek 恢复了,自动切回来。
3 种路由策略
failover: strategy: lowest-latency # 选延迟最低的 Provider
| 策略 | 说明 | 适用场景 |
|---|---|---|
priority | 按优先级顺序 | 默认,优先用便宜的 |
round-robin | 轮流调用 | 负载均衡 |
lowest-latency | 选最快的 | 延迟敏感的场景 |
用量统计
curl http://localhost:8000/stats?days=7
返回每个 Provider、每个模型的调用次数和花费。帮你回答"这个月 API 花了多少钱"。
Provider 状态监控
curl http://localhost:8000/status
一目了然:哪些 Provider 健康、延迟多少、失败率多少。
架构
┌─────────────┐ ┌─────────────────────┐ ┌─────────────────┐ │ 你的应用 │────▶│ LLM Gateway │────▶│ DeepSeek │ │ (OpenAI │ │ │ │ 优先级 1 │ │ SDK) │ │ /v1/chat/completions│ ├─────────────────┤ │ │◀────│ OpenAI 兼容 API │──X──│ 通义千问 │ └─────────────┘ │ │ │ (备用) │ │ Router + Tracker │ ├─────────────────┤ │ SQLite 用量统计 │ │ OpenAI │ └─────────────────────┘ │ (备选) │ └─────────────────┘
Gateway 对外提供 OpenAI 兼容的 API,对内路由到配置的各个 Provider。
为什么用 Gateway 而不是直接多配几个 Key?
你可能会说:"我在代码里多配几个 Provider 不就行了?"
可以,但你需要自己写:
健康检查逻辑
自动切换逻辑
用量统计
切换后自动恢复
这些代码在每个项目都要写一遍。Gateway 统一处理了,你的应用只管调 API。
适合什么场景?
生产环境:多 Provider 容灾,不能因为一个 API 挂了就停摆
成本优化:便宜的优先,贵的当备选
多模型管理:统一入口,不用记每个 Provider 的地址和 Key
开发测试:本地起一个 Gateway,同时调试多个模型
接下来
这个项目还在早期,TODO 里有很多想做的:
Web Dashboard(用量可视化)
Token 限流(按用户/IP)
Prompt 缓存(相同请求不重复调用)
但核心功能已经能用了。如果你也遇到过 API 故障导致服务中断的问题,可以试试。
GitHub: https://github.com/Vincent-crypto-coder/llm-gateway
觉得有用的话,给个 ⭐ 吧!
