一个 GitHub 新项目，把 LLM 中间件领域的老牌选手 LiteLLM，按在地上做了一次“抽脂手术”。
原版 LiteLLM，10 万+ 行代码，proxy、caching、cost tracking、数十个功能层层堆叠。新项目 litelm 只取其中一条路径：路由 + 消息格式翻译，压缩到约 2900 行代码、2 个依赖。
这不是 fork，更像是一次“外科手术式”的精简。
LiteLLM 的“臃肿”，终于有人忍不了了
做过后端接入的人都知道这个痛点。
OpenAI、Anthropic、Groq、Bedrock、vLLM、Ollama……每家 API 格式都不一样。LiteLLM 的价值，就是把这堆接口统一封装：你写一份代码，它能帮你路由到不同模型，自动翻译消息格式。
但问题是，核心能力只有一点点，周边功能却越堆越多。
代理服务器、缓存层、成本追踪、权限管理、计费面板……对很多只想“调个模型”的开发者来说，这些功能根本用不上，却得跟着一起部署、一起升级、一起背依赖。
litelm 的作者干脆把 LiteLLM 的 call path 单独抽出来：模型路由、消息翻译、streaming、tool use、embeddings，别的都不要。
没有 Router class，没有 proxy，没有 caching。
安装命令简单到离谱：
pip install litelm # 只需要 openai + httpx
如果需要 Anthropic 或 Bedrock，再按需加 extras。这种“按需加载”的思路，和原版动辄庞大的依赖树形成鲜明对比。
“切换成本几乎为零”
litelm 最狠的一点，是** API 完全镜像 LiteLLM **。
函数名一样，参数一样，返回类型也一样。作者原话：
“If you're using litellm today, switching is
s/litellm/litelm/in your imports.”
也就是说，你把 import 里的 litellm 改成 litelm，代码大概率直接跑起来。
支持 19 家 provider，用 "provider/model-name" 的写法：
import litelm
response = litelm.completion(
"openai/gpt-4o",
messages=[{"role": "user", "content": "Hello!"}]
)
streaming、embeddings、tool use、async 变体，一个不少。本地模型也能接，vLLM、Ollama、LM Studio 都通过 api_base 一把梭。
错误处理也做了统一映射：ContextWindowExceededError、RateLimitError、AuthenticationError 都能直接 catch。
对很多只想“轻量接模型”的团队来说，这个定位非常精准。
但社区有人不买账：你砍掉的，正是我要的
反转来得很快。
热评第一条就直说：“LiteLLM Without the Bloat” 这个口号有问题。因为被 litelm 砍掉的功能——cost tracking、streaming、caching——对很多企业用户来说，恰恰是 LiteLLM 的核心价值。
另一条评论更直接：
“Having a reliable way to track token spend per customer across different services is important to us, and LiteLLM handles this well.”
翻译一下：我们不是不需要那些“臃肿”功能，我们部署 LiteLLM 就是为了这个。
这其实是两种用户画像的冲突。
一边是个人开发者、小团队，只想快速切换模型，越轻越好；另一边是平台型产品，需要跨客户计费、权限隔离、成本分摊，功能越全越稳。
litelm 不是 LiteLLM 的替代品，更像是LiteLLM 的一个极端子集。
还有人在吐槽 readme 和依赖
更有意思的是社区对项目“质感”的争论。
有人建议作者**“rewrite the readme by hand”**，认为 readme 是判断一个项目有没有用心的“嗅觉测试”。
也有人指出隐患：litelm 的两个依赖之一是 httpx，而 httpx 的维护状态存疑，Pydantic 已经接手做了 httpx2。虽然素材没有说 litelm 会换，但这确实是一个值得关注的点。
这些讨论说明一件事：代码可以极简，但信任没法极简。
更大的趋势：AI 写代码，infra 被“去中介化”
litelm 的 readme 里有一句话很微妙：
“litelm is human-directed, AI-assisted software. Much of the code was written with Claude Code using Claude Opus 4.6/4.7.”
后面 2026-05-14 起的代码，又换成了 Pi + GPT-5.5。
换句话说，这是一个由 AI 辅助生成、人类定向裁剪的项目。而且作者做了相当认真的兼容性审计：审计了 360 个核心路径 commit，262 个本地测试通过，45 个 live provider 测试通过，10 个 DSPy smoke 测试通过。
社区里有人把这个现象拔高了一层：
“most software like this will be dematerialized, democratized, and demonetized — companies building in the infra band being increasingly disintermediated.”
意思是，中间件这层的基础设施公司，会越来越被边缘化。因为用 AI 工具写一个“够用的替代品”，成本正在快速下降。
另一条评论更狠：
“This is a 30 minute project with a frontier LLM. I don’t see why anyone would use anyone else’s router.”
技术有价值，库本身未必。
所以，LiteLLM 会被替代吗？
老实说，短期内不会。
LiteLLM 的生态、企业支持、功能完整性，仍然是 litelm 无法比拟的。但 litelm 的出现，至少证明了一件事：市场对“更轻量的 LLM 路由层”有真实需求。
而且这不是孤例。
从 langchaint 到各种自研 client，越来越多开发者开始自己写 LLM 客户端。他们不是不相信 LiteLLM，而是不想为 1000 个功能里的 990 个买单。
未来可能会出现一个中间态：LiteLLM 继续做它的“企业级全家桶”，litelm 这类项目则守住“极简路由”的 niche。
问题是，这个 niche 会不会越来越大？
【锐评】：当 2900 行代码就能挑战 10 万行的帝国，臃肿本身就是一种原罪。
参考链接：
https://github.com/kennethwolters/litelm