litellm

一家 SaaS 公司被 LLM 供应商折腾的那些事

2024 年，BerriAI 团队在为一个企业客户搭建 AI 客服系统时，遇到了一个令人头疼的问题：系统需要同时接入 GPT-4、Claude 3 和 Gemini 三个模型，分别对应不同业务场景。但每换一次模型，就要改一套 SDK、换一套认证方式、调试一套错误处理。项目越做越大，代码里充斥着各种 if-else 的 provider 判断，维护成本直线飙升。

这个痛点，直接催生了 LiteLLM。

LiteLLM 是一个开源的 AI 网关（AI Gateway），它的核心思路非常朴素：用一套 OpenAI 兼容的 API，调用全球 100+ 主流大模型服务商的产品。无论你要调 OpenAI 的 GPT-4o、Anthropic 的 Claude 4、谷歌的 Gemini，还是亚马逊 Bedrock、Azure OpenAI、国内的硅基流动——在 LiteLLM 眼里都是同一个调用格式，开发者不需要关心底层差异。

---

项目背景：Y Combinator 孵化的 AI 基础设施公司

LiteLLM 由 BerriAI 开发，公司成立于 2023 年，同年入选 Y Combinator W23 批次加速营。项目在 GitHub 上迅速走红，Star 数从 2024 年初的几千颗一路飙升至 2026 年 5 月的 48,000+ 颗，成为 AI Gateway 领域最受欢迎的开源项目之一。

BerriAI 的商业模式是「开源核心 + 企业版增值」：开源版本覆盖基础的网关功能，企业版提供 SSO、审计日志、高级权限控制、SLA 保障等企业级特性。目前已知采用 LiteLLM 的企业包括 Netflix、Stripe、Google ADK、OpenAI Agents SDK、OpenHands 等国际知名公司，其 GitHub 官方页面也列出了这些重量级用户作为背书。

---

核心技术能力：不仅仅是「统一接口」那么简单

LiteLLM 绝不是一个简单的接口适配层。它的能力边界远超「把 API 包装一下」这个层面。

统一的 SDK + 网关双模式

LiteLLM 同时提供 Python SDK 和独立 Proxy Server 两种使用形态。Python SDK 模式适合直接在项目中引用，三行代码即可完成多模型切换；Proxy Server 模式则面向团队协作场景——部署一个集中式 AI 网关，所有成员通过虚拟 API Key 接入，网关自动处理负载均衡、计费追踪、访问控制等跨团队需求。

100+ 模型支持，覆盖主流与新兴供应商

LiteLLM 支持的模型列表几乎涵盖了市面上所有主流 LLM 服务商：OpenAI 全系列、Anthropic Claude 全系列、Google Gemini / Vertex AI、Azure OpenAI、AWS Bedrock、Cohere、HuggingFace、VLLM、NVIDIA NIM、DeepSeek、硅基流动等。此外还支持 /chat/completions、/responses、/embeddings、/images、/audio、/batches、/rerank、/a2a 等多种接口类型，功能覆盖极为全面。

智能路由与负载均衡

Proxy Server 内置了模型路由能力，可以配置「成本优先」「延迟优先」「自定义权重」等多种策略。请求会自动分配到指定模型，并支持 failover——当主模型不可用时自动切换到备选模型，保障服务可用性。

企业级安全与管理

LiteLLM 提供了虚拟 API Key 体系，管理员可以为不同团队/用户生成独立 Key，追踪每个 Key 的用量和费用。它还内置了 spend limit（消费上限）和 budget manager（预算管理器），防止某个 Key 意外耗尽额度或产生超额账单。

8ms P95 延迟的性能承诺

根据官方 Benchmark，LiteLLM Proxy 在 1k RPS（每秒 1000 请求）的负载下可实现 8ms P95 延迟，这对于大多数在线 AI 应用来说是完全可接受的响应速度。

---

最新版本亮点：Guardrails 与 A2A 协议

进入 2025-2026 年，LiteLLM 的迭代重点从「增加更多模型支持」转向了平台能力的深化。

**v1.81.14（2026 年 2 月）**引入了 Gateway Level Guardrails（网关级防护栏）和 Compliance Playground（合规测试沙箱），管理员可以在网关层面统一配置内容过滤、敏感信息拦截等策略，而不需要在每个应用层单独实现。

**v1.85.1（2026 年 5 月）**实现了对 Gemini 3.5 Flash 的 day-0 支持（即新模型发布当天即完成适配），同时修复了多 Pod 部署下的消费计数器 bug，确保团队预算在 Redis 缓存未命中时不会被重复计算。

此外，LiteLLM 也在积极拥抱 A2A 协议（Agent-to-Agent），支持通过标准协议调用 LangGraph、Vertex AI Agent Engine、Azure AI Foundry、Bedrock AgentCore 等主流 Agent 框架，将自己定位为 Agent 时代的统一通信枢纽。

---

MCP 集成：让 AI Agent 真正「看见」外部世界

Model Context Protocol（MCP）是 AI Agent 连接外部工具和数据源的标准协议，LiteLLM 在这一领域的布局相当前瞻。通过 LiteLLM 的 MCP Gateway，开发者可以在调用 LLM 时直接挂载 MCP 工具——例如让 GPT-4o 直接查询 GitHub 仓库状态、操作数据库、或调用自定义 API——而不需要自己实现工具调用逻辑。

特别值得一提的是，LiteLLM 还支持与 Cursor IDE 集成，在编辑器层面直接调用 MCP 工具，进一步降低了 AI 原生工具链的接入门槛。

---

部署体验：开箱即用的容器化方案

LiteLLM 在部署方面下了很大功夫，提供了多种部署选项，适合不同规模的团队。

Docker Compose 是最推荐的入门方式。项目根目录提供了 docker-compose.yml，配合 Redis（可选）即可快速启动一个完整的 AI 网关服务，包含管理后台（LiteLLM Dashboard）、代理服务和数据库持久化。docker-compose.hardened.yml 则提供了加固版本，适用于对安全性有更高要求的生产环境。

Helm + Kubernetes 方案支持在 Kubernetes 集群中部署，适合已经在容器编排平台上有投入的中大型团队。Terraform 模块则方便在 AWS/GCP/Azure 等云平台上通过 IaC 方式管理基础设施。

Web 管理后台开箱即用，提供用量可视化、消费追踪、Key 管理等常用功能，不需要额外的运维工具即可完成日常管理工作。

整个部署流程的技术门槛不高，有 Docker 基础的开发者可以在 10-30 分钟内完成从零到生产可用的网关搭建。

---

值得关注的风险：供应链安全事件

2026 年 3 月，LiteLLM 经历了一次供应链安全事件——PyPI 上的 litellm==1.82.7 和 litellm==1.82.8 两个版本被发现包含恶意代码，攻击者通过劫持发布流程注入了后门。BerriAI 团队反应迅速，在发现问题后暂停了新版本发布，并紧急发布了 v1.83.0 修复版本，同时升级了 CI/CD 流程（v2 pipeline），增加了隔离构建环境、安全门禁和发布分离机制。

这个事件提醒我们：即使是成熟的开源项目，在依赖管理上也需要保持警惕，生产环境应锁定已验证的安全版本，并通过 SHA-256 校验确保二进制一致性。

---

总结：AI 网关赛道的标杆之作

LiteLLM 的成功，本质上解决了一个非常实在的问题——在 LLM 供应商生态高度碎片化的当下，如何让开发者以最低成本、最小心智负担地使用多模型能力。它不是简单地做了 API 适配，而是通过网关化的设计，将路由、安全、计费、监控等工程难题一并消化，让企业可以真正把精力放在应用层创新上。

从技术成熟度、社区活跃度、企业采纳情况三个维度来看，LiteLLM 都是当前 AI Gateway 赛道中不可忽视的存在。对于正在构建 AI 应用的团队，LiteLLM 值得作为技术选型的重要候选。