LiteLLM 是什么？一个网关把 100+ 模型全拽到手边，Agent 省钱从这开始
你有没有这种经历：今天测 GPT，明天换 Claude，后天又疼 Gemini，但每种模型 SDK 不一样、鉴权不一样、报错格式也不一样。代码里写着写着就变成一堆 if/else 去兼容各家 API。更恼火的是——你本地明明有跑得不错的小模型（比如 /mnt/ai 里那堆 GGUF），想跟云端模型一起统一用，硬是没有一条干净的通道。
LiteLLM 干的就是这件事：一个开源 AI 网关，把 100 多家 LLM 提供方（OpenAI、Anthropic、Gemini、Bedrock、Azure，还有你要的本地 Ollama）全部统一成 OpenAI 的请求格式，你只管用一套接口，调用方永远不用改代码，任意换背后的模型。
这不是我拍脑袋编的，数据是刚从 GitHub 拉的实时数据：LiteLLM 目前 58.9K 星、11.5K fork，2023 年 7 月创建，出自 Y Combinator W23 的 BerriAI，现在还在疯狂迭代（今天还在 push）。用的公司有一长串：Stripe、Netflix，连 OpenAI Agents SDK、Google ADK 都挂在它头上当适配器。一个给模型”做中间层”的开源项目能攒到近六万星，说明这痛点是真的痛。
它到底解决什么问题
一句话：别让每个 Agent 各自为战去接各家模型，统一走一个网关。
具体拆开有三层价值：
- 统一接口：不管背后是 OpenAI 还是本地跑的小参数量模型，你的代码永远写
completion(model="openai/gpt-4o", ...)或model="ollama/你的模型名"。想换供应商，改一行配置，代码零改动。 - 生产级网关：虚拟 Key、费用统计、负载均衡、护栏（guardrails）、管理后台——这些开箱即用。说白了它把”多云多模型”这件事从裸 SDK 拼装，升级成一套能上线的服务。
- Agent 底座：它不止接 LLM，现在还通过 A2A 协议直接调别的 Agent（LangGraph、Vertex、Azure AI Foundry、Bedrock、Pydantic AI 都能接）。所以它不是跟 Agent 框架抢饭碗，而是给所有框架垫底。
对做 Agent 的你来说，它最实际的价值是：省钱换成钱、换模型再也不用重写代码。就像我上一篇讲本地模型那篇说的，谁不想用一个接口把所有模型都试一遍再定？
上手有多快
分两种玩法，都简单得不像话。
① 直接当 Python SDK 用：pip install litellm，然后：
from litellm import completion
completion(model="openai/gpt-4o", messages=[{"role":"user","content":"你好"}])
completion(model="ollama/qwen2.5:14b", messages=[{"role":"user","content":"你好"}])
同一个函数，云端模型和本地模型一起调，就这么粗暴。
② 起一个网关代理服务：litellm --model gpt-4o 起来后，别的程序只要把 base_url 指到 http://0.0.0.0:4000，用 OpenAI 的 SDK 就能访问你代理的所有模型。团队里其他人完全不用装 LiteLLM、不用配各家 Key——统一到你这一端。最爽的是，你可以把开源小模型和一个云端强模型放一起，平时用便宜的，关键时刻手切到贵的。
实话
摸着良心说两句。LiteLLM 星多、生态猛，但配置项也多。它不只是”调函数”，真要用好虚拟 Key、预算、路由那套，得啃一会儿文档，一上来就想全功能拉满容易被配置淹死。另外项目更新太快，隔一阵就有新端点、新 provider，喜欢”装完就不动”的人会有点跟不上它的节奏。它开源（MIT 系），社区够大，救火基本靠 Stack Overflow 和官方文档就够。
还有句要提醒的：本地模型和云端模型在质量上不是一个物种，网关只负责”路通不通”，不负责”哪个模型更聪明”。省钱是省了，该上的强模型别抠。
适合谁：管好几个项目、不想给每个项目配一堆 Key 的团队/个人；想偷偷把模型换来换去比较、又不想动代码的折腾党；以及像我这种喜欢把本地模型和云端模型混着用、为省钱愿意搭一层中间件的玩家。不太适合：只接一个模型、永远不换的那种极简需求——那确实用不上它。
我是数码罗记，常驻 godsun.pro，专攻把模型、Agent、自建这套玩明白还省钱的路子。这期先到这儿，下期接着聊怎么把 LiteLLM 接进你的 Hermes / OpenWrt 那套自动化里。
by 数码罗记 · godsun.pro
