AiDuo123 Logo
简体|繁體
充值登录注册
★ 54,177· 9,920 forks· Python· NOASSERTION开源替代

LiteLLM - 统一 100+ 大模型的开源 AI 网关

BerriAI/litellm

Rust 内核 Python SDK 的轻量级 AI 网关,用 OpenAI 格式调用 100+ LLM 提供商,自带成本追踪、负载均衡和企业级管控

成熟度：维护极活跃,最近提交 0 天前,但 4044 个未关闭 issue 反映社区支持压力大

GitHub 仓库 → HN 讨论 · 938 点 · 500 评论对标：Portkey, Kong AI Gateway

项目体检

部署 · Docker Compose 一键启动(默认端口 4000),依赖 PostgreSQL 数据库服务,可选挂载 config.yaml 配置文件

成本 · 需配置目标 LLM 提供商的 API Key(OpenAI/Anthropic/Azure 等),数据库默认 PostgreSQL,开箱需手动填写 .env 中的 LITELLM_MASTER_KEY 和各厂商凭证

技术 · Python 主体 + Rust 核心,支持 FastAPI 代理服务器,集成 LangChain/Pydantic AI 等 Agent 框架

许可 · NOASSERTION(未明确声明许可协议),商用前需联系项目方确认授权条款

活跃 · 极活跃:最新 release v1.93.0 发布于 2 天前,1545 名贡献者,但 4044 个 open issues 显示维护负担重

解决什么

企业在接入多个 LLM 提供商时常遇到三大痛点:每家厂商 SDK 格式不同(OpenAI 的 messages vs Anthropic 的 prompt)、鉴权方式各异(API Key/IAM/OAuth)、成本和日志分散难以统一管控。LiteLLM 通过统一网关层抹平差异,让开发者用 OpenAI 的调用格式即可切换 100+ 模型提供商(包括 Bedrock、Azure OpenAI、VertexAI、国产通义千问等),同时在网关层实现虚拟密钥管理、成本追踪、速率限制和负载均衡。

为何火

该项目获 Y Combinator W23 批次孵化,在 Hacker News 上因供应链攻击事件引发广泛关注:2026 年 7 月其 PyPI 包 1.82.7/1.82.8 版本被植入恶意代码,仅 import litellm 即触发后门,攻击者通过入侵创始人 GitHub 账号推送恶意版本。事件暴露出两点争议:1) 项目维护者账号安全管理存在漏洞;2) 攻击者在 GitHub issue 区用数百个机器人账号刷屏试图压制讨论(类似 Trivy 项目遭遇的手法)。尽管官方已撤回恶意版本并发布安全公告,但社区对其依赖安全性产生质疑,部分用户表示"即使只用轻量封装也会迁移走"。

技术层面的吸引力在于其 Rust 核心 + Python SDK 架构实现了 8ms P95 延迟(1k RPS 压测),且被 Stripe、Netflix、Google ADK 等大厂采用。统一接口让团队无需重写代码即可在 GPT-4/Claude/Gemini 间切换,配合 Admin UI 可视化管理密钥和预算。

核心功能

  • 多模型统一调用:支持 /chat/completions、/embeddings、/images 等 OpenAI 兼容端点,覆盖 100+ 提供商(含国内文心一言、智谱 GLM)
  • 企业级管控:虚拟密钥(Virtual Keys)隔离团队权限、预算告警、请求日志持久化到 PostgreSQL、Guardrails 内容过滤
  • 负载均衡与容错:多模型间自动 fallback、基于延迟的智能路由、速率限制防滥用
  • Agent 协议支持:实现 A2A(Agent-to-Agent)协议,对接 LangGraph、Bedrock AgentCore 等框架
  • 成本追踪:实时计算 token 消耗费用,按用户/团队维度生成账单报表

安装

Python SDK 方式(适合直接集成到代码):

uv add litellm  # 或 pip install litellm

自托管网关方式(推荐生产环境):

# Docker Compose 启动(需先配置 .env 文件)
docker-compose up -d
# 或快速测试
uv tool install 'litellm[proxy]'
litellm --model gpt-4o  # 默认监听 4000 端口

⚠️ 安全建议:生产环境务必锁定版本号(如 litellm==1.93.0)并验证 SHA256 哈希,避免供应链攻击风险。

适合谁

  • 多云 LLM 架构团队:需要在 AWS Bedrock、Azure OpenAI、自建模型间灵活切换
  • 成本敏感型企业:需要精细化追踪各部门/项目的 LLM 调用费用
  • 合规要求高的场景:需要自托管网关避免数据经过第三方 SaaS(如 Portkey)
  • Agent 应用开发者:需要统一管理多个 AI Agent 的模型调用和鉴权

不适合:个人开发者若只用单一模型提供商(如纯 OpenAI),直接用官方 SDK 更简单;对供应链安全极度敏感的团队可能需要 fork 后自行审计代码。

社区评价

Hacker News 讨论热度 938 点,但几乎全是负面情绪:

  • 安全恐慌:多名用户表示"即使只 import 就触发恶意代码,太可怕了",有工程师因 Chrome 预加载恶意域名被安全团队误判感染,不得不重置凭证和重装系统
  • 信任崩塌:评论指出"创始人和 CTO 的 GitHub 账号被攻破"(krrishdholakia),攻击者还在 issue 区用 100+ 机器人账号刷屏压制讨论,手法与此前 Trivy 项目遭遇的攻击类似
  • 迁移意向:有用户明确表态"只是用它做轻量封装,现在会完全迁移走,风险不值得",反映出供应链攻击对开源项目声誉的长期伤害
  • 技术细节:安全研究员在 PyPI Inspector 发现恶意代码连接 checkmarx.zone/raw 和 models.litellm.cloud/ 两个 C&C 域名

尽管官方已撤回恶意版本并加强账号安全(启用 2FA、轮换 Token),但社区普遍认为此次事件暴露了项目在供应链防护上的薄弱环节。

选型对比

维度LiteLLMPortkey(商业)Kong AI Gateway
部署方式自托管/开源托管 SaaS自托管/企业版
模型覆盖100+ 提供商50+ 提供商主流模型
成本免费(自维护)按请求量收费企业授权费
延迟8ms P95~20ms(经 SaaS 中转)取决于配置
供应链风险曾遭攻击需自审SaaS 托管相对安全企业级安全审计

取舍建议:若团队有运维能力且需要完全数据自主权,LiteLLM 自托管是最佳选择;若追求开箱即用和安全托管,Portkey 更省心但有厂商锁定风险;Kong 适合已有 API 网关基础设施的大型企业。

已知坑

  1. 供应链安全:PyPI 包曾被植入恶意代码,生产环境必须锁定版本并验证哈希值,建议通过 Docker 镜像部署而非直接 pip 安装
  2. Issue 积压严重:4044 个未关闭 issue 反映维护者响应压力大,复杂问题可能得不到及时支持
  3. 许可协议不明:GitHub 显示 NOASSERTION,商用前需联系官方确认授权(企业版需付费)
  4. 国内网络限制:部分提供商(OpenAI/Anthropic)需配置代理,且官方文档的某些示例域名可能被墙
  5. 数据库依赖:网关模式强依赖 PostgreSQL,需额外维护数据库高可用;虚拟密钥等功能必须启用 STORE_MODEL_IN_DB=True
  6. 配置复杂度:.env 需手动填写所有提供商的 API Key,初次配置容易遗漏导致调用失败

来源: GitHub BerriAI/litellm + Hacker News 讨论 "Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised"

安装方式：pip/uv

← 浏览全部项目