LiteLLM

LiteLLM 不是聚合平台（像 OpenRouter），也不是简单的代理转发（像 One API）。它是一个开源的 LLM 网关，你可以自己部署，然后在前端暴露一套统一的 OpenAI 格式接口，后端对接几十家厂商的 API——OpenAI、Anthropic、Azure、Cohere、Together、Groq、Vertex AI，甚至国内的通义千问、智谱都能挂。 和 One API / New API 的核心区别：LiteLLM 更像一个“控制面”，主打负载均衡、预算管理、审计日志、路由策略，而且是 YAML 配置驱动，适合 GitOps 场景。 实测效果 优点： 统一接口确实省事。代码里只写 openai.BaseURL = "http://litellm:4000"，后端切换模型时改一个配置参数就行，不用发版。支持的模型列表自动通过 /v1/models 暴露，客户端可以动态获取。 负载均衡比 New API 更灵活。支持加权轮询、最少负载、优先级，还能按请求头（比如 x-user-id）做一致性哈希，保证同一个用户的请求落到同一个模型实例上——对有状态会话很有用。 预算控制做得细。可以按 API Key、按团队、按模型设置月度/每日额度，超限自动拒绝，而且支持“软上限”（告警）和“硬上限”（熔断）两级。还能把花费打到成本中心 ID 上，方便财务对账。 故障转移很智能。主模型返回 429 或超时，LiteLLM 自动切到备用的模型或厂商，并且记录到审计日志。实测从 OpenAI 切到 Azure 的过程对上层透明，客户端只看到一次 200 响应。 跟踪调用很爽。每个请求自动记录：输入输出 token、模型、响应时间、花费、IP、用户 ID。默认存SQLite，生产可以换 PostgreSQL。配合 Grafana 能直接画出“哪个部门花了多少钱”的曲线。 缺点（真实踩过的坑）： YAML 配置学习曲线陡。不是点几下鼠标就能配好，所有路由规则、模型列表、重试策略都要写配置文件。官方文档虽然全，但示例复杂，初用者容易配错。有一次我不小心把 model_list 缩进写错，LiteLLM 直接启动失败，没有任何友好的校验提示。 性能有损耗。毕竟多了一层代理，实测对比直连 OpenAI 增加约 50-80ms 延迟。好在 LiteLLM 支持 Redis 缓存和流式响应透传，对吞吐影响不大。但如果你的业务对延迟极度敏感（比如实时语音），这层损耗要考虑。 某些厂商适配有 bug。我遇到过 Vertex AI（Google 云）上的 Gemini 调用返回非标准错误格式，LiteLLM 直接崩溃。去 GitHub Issues 翻了很久，发现是 1.40.0 版本引入的，后来升到 1.42.3 才修好。这种“新版本修老 bug 又引入新 bug”的现象不算少见。 多模态支持不统一。它主要针对文本补全和对话设计，图片生成（DALL-E）、音频（Whisper）的接口虽然能转发，但路由策略、负载均衡不会对它们生效。文档里也明确说了“优先保证文本模型”。 日志存储没有自动轮转。默认 SQLite 跑一个月磁盘能撑爆，必须自己配 PostgreSQL + 定时清理。生产部署需要额外写脚本或者用外部日志系统（比如 Loki）。 和同类产品对比 维度 LiteLLM One API New API OpenRouter 部署方式 自托管 自托管 自托管 SaaS 配置界面 YAML + 仪表盘（简单） Web UI Web UI Web UI 预算控制 极细 中等 细 粗 审计日志 完整 基础 较好 无 学习成本 高 低 中 低 适合场景 企业/多云 个人/小团队 小团体运营 个人探索 总结 如果你是一个个人开发者，只是想转发几个 API Key，LiteLLM 太重了，One API 或 New API 更合适。 如果你是企业团队，有多个云账号（Azure、AWS Bedrock、GCP Vertex），需要统一管理预算、做成本分摊、审计谁调用了什么模型，那 LiteLLM 值得花时间研究。它不提供现成的免费额度，也没有傻瓜式 Web 界面，但给你的是可控性和企业级能力。 生产环境上 LiteLLM，建议搭配 PostgreSQL + Redis + Prometheus + Grafana，配置写进 Git 做版本管理。不要图省事用默认 SQLite，血的教训。