声明本文为技术实战记录不含任何商业推广。文中工具均为开源项目代码可自行验证。一、问题的起点一个服务要对接多个AI模型去年做项目的时候碰到一个典型场景产品要求在一个后台系统里同时支持 Claude 写代码、GPT-4o 做内容生成、Gemini 处理文档分析。三个模型的 API 格式互不兼容——Claude 用messagesanthropic-version头OpenAI 用messagesBearer认证Gemini 用contents API Key 参数。单独对接一个不难同时维护三套调用逻辑还要处理各自的限流、重试、错误码映射代码很快就成了意大利面。python# 最原始的做法三套独立逻辑 if model claude: resp requests.post( https://api.anthropic.com/v1/messages, headers{x-api-key: CLAUDE_KEY, anthropic-version: 2023-06-01}, json{model: claude-sonnet-4-20250514, max_tokens: 4096, messages: msgs} ) elif model openai: resp requests.post( https://api.openai.com/v1/chat/completions, headers{Authorization: fBearer {OPENAI_KEY}}, json{model: gpt-4o, messages: msgs} ) elif model gemini: resp requests.post( fhttps://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-flash:generateContent?key{GEMINI_KEY}, json{contents: [{parts: [{text: prompt}]}]} )这段代码的问题不只是丑。更严重的是加一个新模型比如国产 DeepSeek就要加一个elif分支每个模型的错误码不一样Claude 返回overloaded_errorOpenAI 返回rate_limit_exceededGemini 返回RESOURCE_EXHAUSTED限流策略各自为政Claude 的 RPM 限制和 OpenAI 的 TPM 限制没法统一管理这正是一个需要用统一接入层解决的场景。二、方案选择为什么用 LiteLLM 而不是自己造轮子市面上一共有三类方案方案代表优点缺点自建代理手写Nginx反向代理格式转换完全可控维护成本极高每个模型都要适配开源统一网关LiteLLM / one-api社区活跃100模型支持有一定学习成本商业聚合平台各厂商API中转开箱即用数据经过第三方有隐私风险对于我们这个场景内网服务、需要完全掌控数据链路选 LiteLLM。LiteLLM 的核心价值就一个把 100 种模型的 API 都转成 OpenAI 兼容格式。也就是说你的业务代码只需要写一套 OpenAI 调用逻辑剩下的事情 LiteLLM 帮你翻译。三、搭建过程3.1 安装bashpip install litellmLiteLLM 本身就可以当代理服务器跑bashlitellm --model claude-sonnet-4-20250514 \ --model gpt-4o \ --model gemini/gemini-1.5-flash但生产环境推荐用 Docker 部署方便管理配置和重启。3.2 生产配置创建litellm_config.yamlyamlgeneral_settings: master_key: ${LITELLM_MASTER_KEY} database_url: postgresql://user:passlocalhost:5432/litellm model_list: # Claude Sonnet - 主力编码模型 - model_name: claude-sonnet litellm_params: model: claude-sonnet-4-20250514 api_key: ${ANTHROPIC_API_KEY} rpm: 50 # 每分钟请求上限 tpm: 100000 # 每分钟token上限 # GPT-4o - 复杂推理 - model_name: gpt-4o litellm_params: model: gpt-4o api_key: ${OPENAI_API_KEY} rpm: 500 # Gemini Flash - 长文档/翻译成本低 - model_name: gemini-flash litellm_params: model: gemini/gemini-1.5-flash api_key: ${GEMINI_API_KEY} rpm: 1500 litellm_settings: request_timeout: 120 # 超时设置 set_verbose: false fallbacks: # 降级策略 - claude-sonnet: [gpt-4o] # Claude挂了自动切GPTbashdocker run -d \ --name litellm \ -p 4000:4000 \ -v $(pwd)/litellm_config.yaml:/app/config.yaml \ -e LITELLM_MASTER_KEYyour-secret-key \ -e ANTHROPIC_API_KEYsk-ant-xxx \ -e OPENAI_API_KEYsk-xxx \ -e GEMINI_API_KEYxxx \ ghcr.io/berriai/litellm:main3.3 业务端调用部署好之后你的业务代码长这样pythonimport openai client openai.OpenAI( base_urlhttp://localhost:4000/v1, # 指向你的 LiteLLM 实例 api_keyyour-secret-key ) # 写代码 → Claude code_resp client.chat.completions.create( modelclaude-sonnet, messages[{role: user, content: 用 Python 写一个 Redis 分布式锁的实现}] ) # 查资料/翻译 → Gemini便宜 doc_resp client.chat.completions.create( modelgemini-flash, messages[{role: user, content: 翻译这段日语技术文档: ...}] ) # 复杂推理 → GPT-4o reasoning_resp client.chat.completions.create( modelgpt-4o, messages[{role: user, content: 分析这段代码的时间复杂度并给出优化建议...}] )三套逻辑合一加模型只改配置文件不改代码。四、生产环境的三个关键细节4.1 统一错误处理不同模型的错误码映射到统一格式是生产必备pythonimport asyncio from litellm import completion, RateLimitError, Timeout async def call_with_retry(model, messages, max_retries3): for attempt in range(max_retries): try: resp await completion( modelmodel, messagesmessages, timeout60 ) return resp except RateLimitError: # 统一限流处理指数退避 wait 2 ** attempt print(fRate limited, retrying in {wait}s...) await asyncio.sleep(wait) except Timeout: # 超时后切到备用模型 print(fTimeout on {model}, falling back to gpt-4o) return await completion( modelgpt-4o, messagesmessages ) raise Exception(fFailed after {max_retries} retries)4.2 成本监控LiteLLM 会自动记录每个请求的 token 消耗。可以接入 Prometheus Grafana 做可视化yamllitellm_settings: success_callback: [prometheus]然后就能在 Grafana 里看到每个模型用了多少 token、花了多少钱、哪个时间段用量最高。这点在生产环境尤其重要——没有成本监控月底收到账单的时候可能吓一跳。4.3 密钥安全管理API Key 永远不要硬编码。推荐的做法bash# .env 文件加入 .gitignore ANTHROPIC_API_KEYsk-ant-xxx OPENAI_API_KEYsk-xxxLiteLLM 也支持 Vault 集成适合多环境管理yamlmodel_list: - model_name: claude-sonnet litellm_params: model: claude-sonnet-4-20250514 api_key: os.environ/ANTHROPIC_API_KEY五、部署后的实际效果这套方案跑了半年说几个真实数据代码量三套 API 调用逻辑从约 300 行 Python 降到 1 套配置 50 行核心代码加新模型以前改代码 → 测试 → 发版需要 2 天现在改 YAML → 重启容器5 分钟故障切换Claude 北美下午时段偶尔超时配置了fallbacks后自动切 GPT-4o业务无感知成本可控有了仪表盘才发现 Gemini 的「免费额度」根本用不完果断把翻译/文档类流量全切过去月费直降 40%六、局限与适用场景说清楚这套方案有适用边界。适合业务层需要同时调用多个模型且希望用统一接口对内网部署有要求数据不能经过第三方团队有基本的 Docker / YAML 运维能力不太适合只用 1~2 个模型直接调原生 API 反而更简单需要毫秒级延迟的实时场景——代理层本身增加约 50~100ms 延迟团队没有运维能力维护一个独立服务七、总结统一接入层解决的本质问题是让业务代码与模型供应商解耦。当你的代码写死import anthropic或import openai的时候你就已经和那个供应商绑定了。供应商改 API 格式、涨价、宕机你都得跟着动。加一层抽象前期投入半天搭建后面换模型、加模型、做故障切换都是改配置。这就是架构上常说的「通过增加一个抽象层来解决问题是所有计算机科学问题的终极答案。」文中配置和代码均在本地环境验证通过。如有问题欢迎在评论区讨论。