为什么你需要一个 AI 网关
先说一个我自己的真实状况。某天我想核一笔 API 花费，打开 newapi 的后台才发现：为了几个不同的项目，我同时挂着三家渠道的 key。哪个项目用的哪家的、各自花了多少，全靠记忆。到现在没出过大错，但我知道这么下去总有一天会出。
如果你也同时用 OpenAI、Claude、Gemini，加上国内的 DeepSeek 和 Kimi，你的代码里很快就会积累一堆 if-else：不同供应商一套 SDK、一套请求格式、一套报错规则。这就是"AI 网关"要解决的问题。
今天要说的 LiteLLM，是开源 AI 网关里名气最大的那一个。它承诺给你三样东西：
- 统一接口：不管底下是什么供应商，你的应用都只需要说 OpenAI 格式
- 一个后台：所有 key 的调用量、花费记录，都在 Admin UI 里照着看
- 虚拟 key：可以为每个项目单独发一个带预算上限的 key，原始 key 不用外借
它的 GitHub 页面列了 Stripe、Netflix、Google ADK、OpenHands 这些采用者。定位不是玩具，是能跑生产环境的基础设施。
SDK 和网关，别混着理解
LiteLLM 有两种用法，很多人一开始就绕进去了：
- Python SDK：代码里
import litellm，用一行函数切换 100+ 家供应商 - AI Gateway（代理服务器）：跑一个独立服务，你所有应用都指向这个网关发请求
如果你是个人用户，目标是统一管理 key 和花费，直接用网关模式，SDK 是给写代码集成的人准备的。下面是部署过程，步骤照着官方 Docker 快速部署文档走，写这篇之前我把文档原文拉下来核对过一遍。
装 LiteLLM：三条命令
前提：一台 24 小时开机的机器加 Docker。官方 quickstart 是这么写的：
curl -sSLO https://github.com/BerriAI/litellm/raw/main/docker/docker-compose.quickstart.yml
printf 'LITELLM_MASTER_KEY=sk-%s\nLITELLM_SALT_KEY=sk-%s\n' "$(openssl rand -hex 32)" "$(openssl rand -hex 32)" > .env
docker compose -f docker-compose.quickstart.yml up -d
下载 compose 文件、生成两个密钥写入 .env、启动。它会拉起两个服务：网关本体（4000 端口）加一个 Postgres 数据库，模型配置、虚拟 key、花费记录都存数据库里。
这两个 key 各管一头，先分清：
LITELLM_MASTER_KEY：网关的根凭证。Admin UI 的登录密码就是它，发管理请求也用它。必须以sk-开头，官方文档的原话是要把它当 root 密码对待：不进代码仓库，泄露了马上轮换LITELLM_SALT_KEY：用来加密你后面录入的各家供应商 API key 的盐值。这里有个容易踩的坑：它没有原地轮换机制，.env 文件删了重新生成，数据库里存的所有供应商 key 立刻变成解不开的乱码，只能手动重新录入
所以那个 .env 文件生成之后要原地保住，别删、别覆盖。
后台五步走完
跑起来后浏览器打开 http://服务器IP:4000/ui。用户名 admin，密码就是 .env 里的 MASTER_KEY。按官方文档的顺序：
- Models + Endpoints → Add Model：选供应商、从目录里勾模型、贴上那家的 API key，点 Test Connect 验证连通性。这里是"选"模型而不是手敲名字，LiteLLM 内置了各家供应商的模型目录和定价映射
- Playground：后台里直接试模型，发一条消息就能看到延迟和 token 计数，走的是真实链路
- Virtual Keys → Create New Key：给应用发一个虚拟 key，替代原始供应商 key。只显示一次，当场复制
顺手记一个安全习惯：供应商的原始 key 压根可以不贴进后台，Add Model 时 API key 字段填 os.environ/OPENAI_API_KEY，把真实 key 配在 docker compose 的环境变量里，key 就不会出现在 UI 和数据库里。
你的代码一行不用改
网关是 OpenAI 兼容的。所有支持自定义 base_url 的 OpenAI SDK 都能直接用：
from openai import OpenAI
client = OpenAI(api_key="你的虚拟key", base_url="http://你的服务器:4000")
换供应商时只改后台配置，代码不动。Cursor 这类支持自定义 OpenAI 接口的 IDE 同样能接，官方文档里就给了 Cursor 把 MCP 工具挂到网关的示例。虚拟 key 上还能加预算和限速，做到「测试项目最多烧 5 美元」这种约束。
不想装数据库？省钱版有一个大坑
quickstart 带一个 Postgres，占地不大但也算多一个服务。官方文档提供了无数据库的精简版：起一个带配置文件的 litellm 镜像，model_list 里写好模型映射，请求用 MASTER_KEY 认证。
但文档里用加粗字体写了一个提醒，我建议直接抄下来贴墙上：
没有数据库时，预算上限不会生效。配置里写
max_budget: 100也不会拦，因为无数据库时累计花费没有地方记账，跑过 $100 既不报错也不提醒；虚拟 key 本身也依赖数据库，没有数据库时 MASTER_KEY 是你唯一的凭证，而它自己没有预算概念。
所以结论很直白：你装 LiteLLM 的动机里如果有"管钱"这一条，就必须用带数据库的完整版。精简版只适合"我只想转发请求、花钱的事我在供应商那边自己控"的场景。
它适合谁
| 你的情况 | 判断 |
|---|---|
| 只在网页/客户端里聊天，不写代码 | 用不上，Cherry Studio 这类聚合客户端更合适 |
| 项目多、key 分散、脚本定时任务多，想管钱 | 正好是它的主场：虚拟 key + 花费记录 + 预算 |
| 小团队，API 统一入口，要做限速和用量审计 | 官方定位就是这个，还有企业版 |
| 只用 CLI 和 Agent 工具 | 不是必需品，各家 CLI 自带账号线就能看 |
我自己的安排是：交互式用客户端，真正跑着烧钱的脚本和定时任务全部挂到网关后面。供应商 key 收进后台之后，"这笔钱是谁烧的"终于有地方查了。
几个常见问题
Q：和 One API / New API 什么区别？
都是统一转发，功能重叠很多。差异在生态：LiteLLM 对 100+ 家供应商的覆盖和测试更全，但没有中文界面；New API 是国内项目，中文文档和社区更顺手。建议以你实际要接的供应商为准，部署前先在两边文档里搜你家供应商的名字。
Q：一定要 Docker 吗？
不用。uv tool install 'litellm[proxy]' 之后 litellm --model gpt-4o 就能跑。生产环境还是容器省心，出问题好回滚。
Q：Master key 忘了存在哪里，能重新生成吗？
主 key 可以在后台或数据库里重置；但 LITELLM_SALT_KEY 不能丢，丢了供应商 key 全部作废重录。
装的部分就到这里。真正花时间的不是部署，是想清楚你要它管什么：管 key、管钱、管流量，对应的配置姿势不一样。部署遇到坑欢迎留言。