本篇定位 ："AI 网关 / Token 网关"系列的第二篇。上一篇聊清了"为什么需要 AI 网关"与三大流派全景；本篇聚焦其中当前最流行的开源网关 LiteLLM，做一次完整拆解------基本信息、基础原理、架构与模块设计、核心功能、优势劣势，最后给出选型建议与 One-API 系的对比速览。
资料来源：LiteLLM 官网、GitHub 仓库与官方文档（2026-09 数据），链接见文末。
一、LiteLLM 是什么
| 项 | 内容 |
|---|---|
| 项目 | BerriAI/litellm |
| 定位 | 开源 AI 网关：一个 OpenAI 兼容 API 统一调用 140+ 提供商 / 1800+ 模型 |
| 语言 | Python SDK + Rust 核心（官方新方向："The fastest, litest AI Gateway"） |
| 许可 | 核心 MIT；企业功能（SSO/审计等）走 Commercial License |
| 热度 | 58k+ Stars、11k+ Forks、1000+ 贡献者、240M+ Docker 拉取（2026-09） |
| 两种形态 | ① Python SDK ：代码里 import litellm 直接用；② Proxy Server（AI Gateway）：独立服务，本文重点 |
| 生产规模 | 官方宣称 10 亿+ 请求已服务；Netflix 等公司在用 |
LiteLLM 官方主图很直白地表达了它的定位------开发者的一切请求都交给它，由它去对接 LLM API、MCP 工具乃至 A2A Agents：
二、基础原理
LiteLLM 的核心思想一句话：把"调用任意模型"抽象成"调用 OpenAI 格式"。
- 统一协议层 ：所有请求走 OpenAI 的
/chat/completions等标准格式； - 适配器层（Provider Handlers）：每个模型提供商有一个 handler，负责把统一请求"翻译"成该厂商的原生格式（URL、鉴权、请求体、流式协议），再把响应"翻译"回 OpenAI 格式------包括错误码的归一化；
- Router 层：当同一个模型配置了多个部署（比如 3 个 Azure 实例 + 2 个中转），Router 负责挑一个最合适的，失败时按策略重试/降级；
- 治理层：在转发链路上叠加鉴权、预算、限流、缓存、护栏、日志等横切能力。
因为出口是标准 OpenAI 格式，上层应用只需把 base_url 指向网关，换模型、加供应商都不用改代码：
python
from openai import OpenAI
client = OpenAI(base_url="http://gateway:4000", api_key="sk-虚拟密钥")
client.chat.completions.create(model="gemini-2.5-pro", messages=[...])三、架构与模块设计
两种形态，同一套核心：
| Python SDK | Proxy Server（AI Gateway） | |
|---|---|---|
| 形态 | 库，嵌在应用进程里 | 独立网关服务（FastAPI + Rust 核心） |
| 使用者 | 单个应用开发者 | 平台团队（服务整个组织） |
| 独有能力 | Router 重试/回退/多部署均衡 | 虚拟密钥、多租户预算、管理 UI、护栏、SSO |
Proxy Server 的请求处理链路（一次调用的完整旅程）：
客户端（OpenAI SDK，持虚拟密钥 sk-xxx）
│ POST /chat/completions
▼
① 鉴权与元数据：校验虚拟密钥 → 定位归属团队/项目/预算
│
② 治理检查：预算余额、RPM/TPM 限流、模型访问控制、护栏（PII/提示注入）
│
③ Router 选路：在 model_list 定义的多个部署里按策略挑选
│ （least-busy / usage-based / latency-based，故障部署进入 cooldown）
│
④ 适配器翻译：litellm.completion(model="azure/gpt-4o", ...)
│ → Provider Handler 转换成厂商原生请求
▼
⑤ 上游模型 API（流式/非流式响应）
│
⑥ 响应规范化：翻译回 OpenAI 格式；统计 token 用量
│
⑦ 后处理：计费入账（Postgres）、日志回调（Langfuse/OTEL）、缓存写入（Redis）
▼
客户端拿到标准 OpenAI 响应模块与部署清单：
- 核心模块 ：
litellm（SDK 与 Provider Handlers）、Router（多部署调度）、Proxy（FastAPI 网关）、Prisma + PostgreSQL （虚拟密钥/团队/预算/用量的持久化，Proxy 模式的硬依赖）、Redis （分布式限流与缓存）、管理 UI 仪表盘、enterprise/（商业功能）； - 配置方式 ：
proxy_config.yaml声明model_list（模型名 → 多个部署及其真实密钥）、路由策略、回调等； - 参考部署：官方 Terraform 提供 AWS（ECS Fargate + Aurora + ElastiCache + ALB）与 GCP（Cloud Run + Cloud SQL + Memorystore）两套模板，密钥托管在 Secrets Manager，网关/后端/UI 三服务拆分；
- 新特性方向：Rust 核心进一步压延迟（官方宣传 p99 增加仅 0.66ms）、MCP Server 网关化、A2A 代理协议支持。
启动一个 Proxy 网关就是一条命令的事------它读取 proxy_config.yaml，把里面声明的模型全部挂载到统一端点下（截图中为官方示例配置加载的 gpt-4o 与一批 Bedrock Claude/Nova 模型）：
四、核心功能速览
| 类别 | 能力 |
|---|---|
| 统一接入 | 140+ 提供商、1800+ 模型；新模型"发布次日即支持"；OpenAI 兼容；支持自托管/微调模型挂载 |
| 密钥治理 | 虚拟密钥（应用持虚钥，真实密钥只在网关）、按团队/项目发放、到期轮换 |
| 预算与计费 | 按 key/团队/模型设硬预算（到额即停）、日/月重置、费用归因、成本看板 |
| 稳定性 | 多部署负载均衡、失败 cooldown、自动重试、跨供应商 fallback |
| 限流缓存 | RPM/TPM 限流、响应缓存与语义缓存 |
| 安全护栏 | PII 掩码（Presidio）、提示注入检测、内容审核、密钥泄露防护、审计日志（企业版） |
| 可观测性 | 实时请求日志、延迟/花费监控、Langfuse / LangSmith / OTEL 等回调集成 |
| 管理界面 | Web UI 管理密钥、团队、模型、预算 |
上一章的"八项核心能力"，LiteLLM 基本项项齐活。看两张官方管理界面截图感受一下------第一张是虚拟密钥管理页：每个 Key 可以单独设预算、有效期，随时点开花费报告，这就是"应用持虚钥、真实密钥只在网关"的操作入口：
第二张是 Usage 用量看板：月度花费趋势、Top API Keys / 用户 / 模型排行，"这个月 Token 花在哪"在这里一目了然：
五、优势
- 生态与覆盖面第一：140+ 提供商适配是社区里最全的，新模型跟进极快；
- 功能完整度高：虚拟密钥、预算、限流、缓存、护栏、观测------一套全齐，接近"开箱即用的企业网关"；
- 双形态灵活：小团队可以从 SDK 嵌入起步，规模化后平移到 Proxy 网关，学习成本延续；
- 社区活跃：58k+ Stars、千余贡献者，文档齐全（docs.litellm.ai），遇到问题基本都能搜到；
- 部署姿势全：Docker / Helm / Terraform 一键模板，支持 air-gapped 离线环境。
六、劣势与坑
-
性能开销 ：Python 实现的转发链路有额外延迟（Kong 官方基准称比 LiteLLM 低 86% 延迟------数据出自竞品，仅供参考），官方用 Rust 核心应对，但属于较新的演进；
官方为新 Rust 网关公布的对比数据相当激进：单请求开销 0.05ms vs 7.5ms（约 150 倍）、高并发吞吐 15 倍、峰值内存轻 11 倍（官方博客数据，测试条件见图注，仅供参考）。方向很明确：性能短板正被官方重点补齐------这也是第一章表格中"Rust 核心"的由来：
-
版本迭代快 = 破坏性变更多 ：更新激进，建议锁
-stableDocker 镜像（发布前经 12 小时负载测试）并先在测试环境验证； -
Proxy 模式强依赖 PostgreSQL：多一个要运维的有状态组件（虚拟密钥/预算都靠它）；小场景用 One-API（SQLite 即可）更轻；
-
安全事件前科：历史上有过漏洞与供应链相关安全事件通报，需要建立及时的升级纪律；
-
配置有学习曲线 ：
model_list/Router 策略/回调体系概念多，初次上手比 One-API 的"点点界面加渠道"陡； -
中文生态弱于 One-API 系：国内"兑换/分发"类需求（兑换码、invite 机制等）One-API 系开箱即有。
七、选型建议（速查）
- Python 技术栈 + 想要完整网关能力（密钥/预算/护栏/观测） → LiteLLM，当前综合最优解；
- 个人中转站、轻量 Token 分发计费 → One-API / New API 更轻更好上手；
- 已有 K8s/Envoy 基础设施，要流量级治理 → Higress / APISIX / Kong；
- 完全不想自运维 → OpenRouter / Cloudflare AI Gateway / Portkey 托管。
各流派的完整对照与项目传送门，见系列第一篇《AI 网关介绍与主流方案全景》。
八、与 One-API 系对比速览
第一篇的全景里反复出现 One-API 系------它是国内轻量中转场景的默认答案，也最常被拿来与 LiteLLM 比较。一张表看清两者定位差异：
| 维度 | LiteLLM | One-API / New API |
|---|---|---|
| 语言 | Python + Rust | Go（单二进制，部署极简） |
| 定位 | 企业级 AI 网关（治理全面） | Token 中转 + 渠道计费（轻量） |
| 提供商覆盖 | 140+，全球主流全覆盖 | 主流厂商 + 国内渠道丰富 |
| 虚拟密钥/团队/预算 | ✅ 完整（数据库驱动） | ✅ 令牌/额度/兑换码体系 |
| 负载均衡与 fallback | ✅ 多策略 Router | ✅ 渠道权重 + 重试 |
| 缓存 / 护栏 / 观测回调 | ✅ 内置 + 生态集成 | 基础功能，靠分支补齐 |
| 管理界面 | ✅ 功能全，偏工程师审美 | ✅ 简洁，中文友好 |
| 上手成本 | 中（需理解 Router/配置） | 低（点点点就能用） |
| 典型用户 | 平台工程团队 | 个人开发者 / 小团队 |
九、小结与下篇预告
- LiteLLM 凭借"最全的提供商适配 + 最完整的网关功能 + 最活跃的社区"，是当前功能派自建网关的默认答案；
- 代价是 Python 栈的性能开销（官方正用 Rust 核心补齐）、Proxy 模式的 PostgreSQL 依赖与较陡的配置曲线；
- 一句话选型：平台团队要完整治理选 LiteLLM，个人轻量中转选 One-API 系。
下篇预告：《网关篇 · 03｜One-API 深度解读》------对比表里最常被拿来比较的那个对手：国内最流行的轻量 Token 中转系统，同样从原理、架构到优劣势做一次完整拆解，顺带聊聊热度已反超本尊的分支 New API。
参考链接
- LiteLLM 官网 ｜ GitHub 仓库 ｜ 官方文档
- LiteLLM 官方文档站截图与基准图（BerriAI/litellm-docs）
- 7 Open-Source LiteLLM Alternatives（API7）
- Higress vs 其他 AI 网关对比（官方）
- 2025 主流 LLM 网关评测（Agenta）
- Kong AI Gateway vs Portkey vs LiteLLM 基准（Kong 官方）
- OneAPI 与 Higress 对比（知乎）
- 本文配图均来自 LiteLLM 官方渠道：GitHub 仓库主图、官方文档站截图（BerriAI/litellm-docs 仓库，含 Admin UI 界面与 Rust 网关基准图），仅作学习交流用途