为了解决这些内部的小麻烦，我们写了一个轻量的中间层，后来觉得可能对同样场景的团队有点帮助，就把它开源了 —— LLM Gateway （项目地址： https://github.com/AaronRZH/llm-gateway ）。
它的定位很简单：放在客户端和各模型 provider 之间，把常见的“对接杂活”集中处理掉，而不是替代任何已有方案。
它主要帮我们做了几件事：
统一输出格式：客户端只用一种习惯的格式（比如 OpenAI 风格），网关再按上游要求做转换，省去每个服务单独适配的功夫。
灵活的路由选择：支持按优先级、轮询、延迟优先或成本优先等方式分配请求，也支持把模型分为几个级别，在服务不可用时尝试备用模型，让调用更稳定一些。
用量统计更清晰：我们会记录每次调用的 token 消耗，存到数据库里，方便事后对账或分析成本分布。
一些基础的保护机制：比如简单的熔断和限流，避免因为某个上游抖动影响到整体体验。
一个简单的管理界面：方便运维同事动态调整 provider 配置和 key ，不用每次都重启服务。
技术实现上用了 Go + Gin ，依赖 PostgreSQL 和 Redis （但是不完全依赖，可以降级到文件，内存），整体比较轻量，单机部署就能满足我们中等规模的业务。
目前我们对接了 OpenAI 、Anthropic 、DeepSeek 、商汤、小米、GLM 、NVIDIA 等几家，但架构上新增 provider 也比较方便。
这个项目完全是按我们自己的实际需求来做的，不一定适合所有场景，但如果你也在做类似的多模型接入，或许能省一点时间。我们也在持续完善中，欢迎感兴趣的朋友看看，有任何建议或问题都欢迎提 issue 交流。
