一个团队做 AI 应用，半年下来手里往往攥着七八把 API key：OpenAI 的、Anthropic 的、DeepSeek 的、智谱的、还有本地 llama.cpp 的。每接一家，代码里就多一套字段名、一套错误码、一套计费口径。LiteLLM 要解决的就是这个：它对外只暴露 OpenAI 兼容协议，对内把各家模型翻译成同一套调用格式。
它到底统一了什么
- 一套 SDK：代码里只写
client.chat.completions.create(...)，模型名写成deepseek/deepseek-chat、gemini/gemini-2.5-pro这样的前缀，剩下的转换由网关做； - 一个 key 出口：应用只认网关地址，各家真实密钥存在服务端，前端拿不到；
- 统一记账：网关天然知道每次调用花了多少 token、哪家模型、哪个用户，可以直接出账单。
起一个网关
最省事的是用它的 proxy 模式：写一个 config.yaml 列出模型与对应环境变量里的密钥，然后 litellm --config config.yaml --port 4000。应用把 base_url 指向 http://localhost:4000，就像在调一个 OpenAI。
再往上走，可以开它的后台 UI，按团队、按 key 分组限额——市场部的 key 每天最多花 50 元，研发的 key 不限速但要记账。
为什么这件事值得做
Manus 2.0 把 Token 成本砍掉两成多，靠的是框架优化。但如果你连「谁在花、花在哪」都看不见，优化就是盲人摸象。一个统一网关是把账单从黑盒变成仪表盘的前提。等哪天你要在 GPT-6 和 DeepSeek 之间按价格动态切换模型，这个网关就是路由层——没有它，多模型容灾只是纸上谈兵。
补一个排障细节：网关层最容易出问题的是超时。长任务（Agent 跑十几步）很容易超过默认的短 HTTP 超时，导致前端报错但后端其实还在跑。把网关和客户端的超时都调到五分钟以上，并开启流式响应，长任务的体验才顺。另外，key 分组限额要配告警，别等账单来了才发现某个测试 key 被循环调用。
把网关立起来之后，你会发现「换模型」「看账单」「做限流」从改代码变成了改配置——这层抽象一旦到位，后面的多模型策略、价格路由才有地方生长，不至于散落在业务代码里。