LiteLLM 教程：先验证固定版本和网关边界
LiteLLM 同时提供 Python SDK 和集中式 AI Gateway。客户端请求经过认证、限流和 hook，再由 Router 选择部署，交给 SDK 的 provider adapter 转换并发送到上游模型。这个入口会集中接触 provider key、提示、响应和用量记录，首次验证要尽量缩小范围。
main-latest 当成稳定渠道。1. 先核对发布物
官方 v1.101.0 Release 提供 cosign 验证命令和固定公钥提交。下载或拉取镜像后先验证签名，再进入配置。项目官方记录还说明 PyPI 1.82.7 与 1.82.8 曾发生供应链事件，因此安装来源和版本固定不能省略。
cosign verify --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub ghcr.io/berriai/litellm:v1.101.0
2. 准备最小配置
只配置一个低额度测试 provider key，并为网关生成独立的 LITELLM_MASTER_KEY。master key 能管理网关，不应分发给普通调用方。测试客户端以后改用有范围和预算限制的虚拟 key。
model_list:
- model_name: test-model
litellm_params:
model: provider/model-name
api_key: os.environ/PROVIDER_API_KEY
general_settings:
master_key: os.environ/LITELLM_MASTER_KEY
3. 只绑定本机端口
官方示例常显示服务监听 0.0.0.0:4000，便于容器内启动；首次评估要把宿主映射限制为 127.0.0.1:4000。公网入口需要 TLS、反向代理、管理面隔离、速率限制和日志保留策略。
4. 核对一次请求的数据路径
发送一条无敏感内容的请求，检查无 key、错误 key、超预算和上游错误分别返回什么。确认提示与响应发给哪家 provider，哪些字段写进日志、回调、缓存和花费表。加入 MCP 或 A2A 后，工具目录、OAuth 凭据和调用结果也进入网关边界。
5. 最后增加数据库和缓存
PostgreSQL 保存 key、团队、用户和花费日志；Redis 可保存认证缓存、RPM/TPM、冷却、响应缓存和待写入用量。启用前要明确备份、保留期、加密和删除流程，多副本还要测试迁移与预算一致性。
与 Envoy AI Gateway 对比
Envoy AI Gateway 建立在 Envoy Gateway 和 Envoy Proxy 上，面向 Kubernetes 平台团队管理生成式 AI 流量。LiteLLM 同时提供应用内 Python SDK、provider 格式转换、预算和管理界面。已有 Envoy 平台并重视代理数据面时评估 Envoy AI Gateway；需要 SDK 和开箱即用模型适配时评估 LiteLLM。
这里仅补原教程没有展开的事实和边界。安装命令与操作步骤仍以前文为准。
先判断这个项目是否适合你
适合谁用
适合需要统一多模型接口、集中分发虚拟 key、限制预算和观测调用的团队。网关会接触提示、响应、provider key、用户身份和花费记录；日志回调、MCP、A2A 与自定义 provider 都要单独做数据和权限审查。
采用建议
LiteLLM 适合确有多模型统一接入和团队治理需求的场景。先在本机用固定、可验证的稳定版本与单个低额度 key 验证，再把数据库、缓存、回调和远程入口逐层加入；它的企业服务不构成本站定义的严重账号转售漏斗。
原教程未展开的系统信息
核心功能
统一模型接口
SDK 和 Gateway 把多家提供方的聊天、Responses、embedding、图像、音频等端点转换为 OpenAI 或原生格式。
认证与用量治理
Gateway 在 SDK 外增加虚拟 key、预算、限流、花费记录、团队与用户管理。
路由和回退
Router 按部署状态、配额和策略选择模型，并支持负载均衡、回退与冷却。
MCP 与 A2A 网关
可把 MCP server 和 A2A agent 暴露给授权客户端；OAuth、工具目录和审批策略会扩大权限边界。
技术栈和运行条件
语言
Python SDK/Gateway，部分 Rust 核心与 TypeScript 管理界面
框架
FastAPI 风格代理层、provider adapters、Router、Prisma/PostgreSQL、可选 Redis
关键依赖
- Python 环境或官方容器
- 各模型提供方合法 API key
- 生产治理需要强 LITELLM_MASTER_KEY
- 可选 PostgreSQL 与 Redis
运行环境
本地试用只绑定 127.0.0.1:4000；团队网关需要 TLS、认证、数据库备份、日志保留和管理端隔离
常见问题
LiteLLM v1.101.0 应该使用 main-latest 镜像吗？
不建议。生产与评估都应固定 v1.101.0，并按官方 Release 的 cosign 命令验证镜像签名；main-latest 会随提交变化。
LiteLLM Gateway 可以把 master key 当作客户端 key 吗？
不应该。master key 控制管理能力，应单独保存；普通调用方使用范围和预算受限的虚拟 key，管理端也要与数据面隔离。
LiteLLM 会把提示只保存在本机吗？
不能这样假设。请求会发给所选模型提供方，日志、回调、缓存和花费记录还可能保存内容或元数据，必须逐项检查配置。
LiteLLM 的 PyPI 供应链事件还影响当前稳定版吗？
官方事件记录针对 1.82.7 和 1.82.8。本文不外推当前版是否受影响，建议固定已确认版本、核对官方发布记录，并优先验证签名容器。