自己搭 AI 网关嫌 LiteLLM 太重？

自己搭 AI 网关的团队大多用过 LiteLLM（GitHub 5.86 万星），但它的调用核心被埋在一堆代理、缓存和成本统计里。9 月 11 日 Hacker News 上出现一个反向思路：一个叫 litelm 的项目把 LiteLLM 的模型路由和消息翻译抽出来单独重写，总共约 2900 行、只依赖 openai 和 httpx 两个包，作者的原话是「不再有 Router 类、没有代理、没有缓存」。

provider/model 形式的路由、Anthropic/Bedrock/Cloudflare/Mistral 的消息格式转换、流式输出、工具调用、嵌入、OpenAI Responses API，覆盖 19 家供应商，而且函数名和参数跟 LiteLLM 一致——从 LiteLLM 迁移只需要把 import 里的 litellm 改成 litelm。

Router 的负载均衡与回退、代理服务器、缓存/预算/成本追踪、token 计数、图像音频 OCR 微调、agents 和 guardrails。README 里这张对照表写得很直白，等于承认这份「轻」是靠砍功能换来的。

作者 9 月 11 日对上游 LiteLLM 的 360 个核心提交做了审计，自有 262 个测试通过，45 个 live provider 测试和 10 个 DSPy 集成测试也过了；不过项目自己标的状态是 Alpha。

litelm 现在只有 194 星、4 个 fork，基本是单人维护的早期项目；Hacker News 上最靠前的两条批评也很实在——一条说「删掉的缓存、成本追踪恰好是很多人用 LiteLLM 的理由」，另一条建议作者手写 README（这份 README 是 AI 生成的）。LiteLLM 那边 5001 个未关闭 issue 是它的历史包袱，但它自己也在往 Rust 内核演进，两边不在同一个成熟度上。

我的判断：如果你的网关只做「多厂商调用 + 格式转换」这一层，litelm 值得当参考实现读一遍，甚至可以直接替换；但只要你依赖缓存省钱、成本报表、代理部署或 token 计数，这次就得留在 LiteLLM——别看到 2900 行就冲动迁移。

你们的 AI 网关是「能调通就行」，还是必须要一份能对账的成本报表？