LiteLLM 是 BerriAI 维护的开源模型调用层，既提供 Python SDK，也提供集中式 AI Gateway。它把 100 多家模型提供方转换成统一接口，并在网关侧增加认证、路由、预算、限流和日志。
来源：github.com/BerriAI/litellm；https://github.com/BerriAI/litellm/blob/ma… 查看 GitHub 仓库 → 📘 使用教程 →当前稳定版 v1.101.0 于 2026-09-15 发布。官方发布页将 v1.103.0-rc.1 等标为预发布；生产环境应区分稳定版与 RC，并阅读破坏性变化。LiteLLM 是 BerriAI 维护的开源模型调用层，既提供 Python SDK，也提供集中式 AI Gateway。它把 100 多家模型提供方转换成统一接口，并在网关侧增加认证、路由、预算、限流和日志。
来源：github.com/BerriAI/litellm/releases/tag/v1.101.0SDK 和 Gateway 把多家提供方的聊天、Responses、embedding、图像、音频等端点转换为 OpenAI 或原生格式。
来源：github.com/BerriAI/litellm/blob/main/README.mdGateway 在 SDK 外增加虚拟 key、预算、限流、花费记录、团队与用户管理。
来源：github.com/BerriAI/litellm/blob/main/ARCHITECTURE.mdRouter 按部署状态、配额和策略选择模型，并支持负载均衡、回退与冷却。
来源：github.com/BerriAI/litellm/blob/main/ARCHITECTURE.md可把 MCP server 和 A2A agent 暴露给授权客户端；OAuth、工具目录和审批策略会扩大权限边界。
来源：github.com/BerriAI/litellm/blob/main/README.md客户端先进入 Gateway 的认证、限流和 hook 层，再由 Router 调用 LiteLLM SDK。SDK 选择 provider adapter，转换请求并经 HTTP 发往上游模型。Redis 可保存 key 缓存、RPM/TPM、冷却和响应缓存；PostgreSQL 保存 key、团队、用户和花费日志，后台任务定期写入用量。
来源：github.com/BerriAI/litellm/blob/main/ARCHITECTURE.mdPython 环境或官方容器各模型提供方合法 API key生产治理需要强 LITELLM_MASTER_KEY可选 PostgreSQL 与 Redis适合需要统一多模型接口、集中分发虚拟 key、限制预算和观测调用的团队。网关会接触提示、响应、provider key、用户身份和花费记录；日志回调、MCP、A2A 与自定义 provider 都要单独做数据和权限审查。
来源：github.com/BerriAI/litellm/blob/main/ARCHITECTURE.md；https://github.c…当前稳定版 v1.101.0 于 2026-09-15 发布。官方发布页将 v1.103.0-rc.1 等标为预发布；生产环境应区分稳定版与 RC，并阅读破坏性变化。
来源：github.com/BerriAI/litellm/releases/tag/v1.101.0；https://github.com/B…status: official_docs_checked_not_run | checked_at: 2026-09-23 | environment: 核对官方 README、架构文档、入门文档、v1.101.0 Release 和官方供应链事件记录 | limitations: 未安装 Python 包或容器，未验证签名，未配置 provider key、数据库、Redis、MCP、A2A 或管理界面，也未产生任何上游调用 | observed_output: v1.101.0 是当前稳定版；Release 提供固定 cosign 公钥验证命令；架构文档明确 Gateway→SDK→provider 流程及 Redis/PostgreSQL 数据职责
来源：github.com/BerriAI/litellm/releases/tag/v1.101.0；https://github.com/B…Envoy AI Gateway 同样解决多模型流量入口问题，但建立在 Envoy Gateway 与 Envoy Proxy 上，更偏 Kubernetes 平台的控制面和数据面。LiteLLM 同时提供 Python SDK、provider 格式转换、预算和管理界面。已有 Envoy 平台并重视代理数据面时评估 Envoy AI Gateway；需要应用内 SDK 和开箱即用模型适配时评估 LiteLLM。
来源：github.com/envoyproxy/ai-gateway/blob/main/GOALS.md；https://github.co…LiteLLM 适合确有多模型统一接入和团队治理需求的场景。先在本机用固定、可验证的稳定版本与单个低额度 key 验证，再把数据库、缓存、回调和远程入口逐层加入；它的企业服务不构成本站定义的严重账号转售漏斗。
来源：github.com/BerriAI/litellm/blob/main/README.md；https://github.com/Ber…不建议。生产与评估都应固定 v1.101.0，并按官方 Release 的 cosign 命令验证镜像签名；main-latest 会随提交变化。
不应该。master key 控制管理能力，应单独保存；普通调用方使用范围和预算受限的虚拟 key，管理端也要与数据面隔离。
不能这样假设。请求会发给所选模型提供方，日志、回调、缓存和花费记录还可能保存内容或元数据，必须逐项检查配置。
官方事件记录针对 1.82.7 和 1.82.8。本文不外推当前版是否受影响，建议固定已确认版本、核对官方发布记录，并优先验证签名容器。