开源一个我们自己用的大模型 API 网关,支持 OpenAI、Anthropic、DeepSeek 等

aaronrzh 2026-07-09 09:48 1

最近在做 AI 应用时,需要同时接入几家不同的大模型 API ( OpenAI 、Anthropic 、DeepSeek 等)。过程中遇到一些比较琐碎的重复工作,比如客户端要维护多套调用格式、不同 provider 的 key 管理比较分散、还有用量统计对账不太方便。


为了解决这些内部的小麻烦,我们写了一个轻量的中间层,后来觉得可能对同样场景的团队有点帮助,就把它开源了 —— LLM Gateway (项目地址: https://github.com/AaronRZH/llm-gateway )。


它的定位很简单:放在客户端和各模型 provider 之间,把常见的“对接杂活”集中处理掉,而不是替代任何已有方案。


它主要帮我们做了几件事:


统一输出格式:客户端只用一种习惯的格式(比如 OpenAI 风格),网关再按上游要求做转换,省去每个服务单独适配的功夫。


灵活的路由选择:支持按优先级、轮询、延迟优先或成本优先等方式分配请求,也支持把模型分为几个级别,在服务不可用时尝试备用模型,让调用更稳定一些。


用量统计更清晰:我们会记录每次调用的 token 消耗,存到数据库里,方便事后对账或分析成本分布。


一些基础的保护机制:比如简单的熔断和限流,避免因为某个上游抖动影响到整体体验。


一个简单的管理界面:方便运维同事动态调整 provider 配置和 key ,不用每次都重启服务。


技术实现上用了 Go + Gin ,依赖 PostgreSQL 和 Redis (但是不完全依赖,可以降级到文件,内存),整体比较轻量,单机部署就能满足我们中等规模的业务。


目前我们对接了 OpenAI 、Anthropic 、DeepSeek 、商汤、小米、GLM 、NVIDIA 等几家,但架构上新增 provider 也比较方便。


这个项目完全是按我们自己的实际需求来做的,不一定适合所有场景,但如果你也在做类似的多模型接入,或许能省一点时间。我们也在持续完善中,欢迎感兴趣的朋友看看,有任何建议或问题都欢迎提 issue 交流。

最新回复 (10)
  • YAFEIML 07-09 10:00
    1
    star 支持
  • k00baa 07-09 10:01
    2
    Token 消耗计算准吗?
  • dummyx 07-09 10:08
    3
    我们也做了一个,不过网关是直接基于 agentgateway/envoy ,计费限额这部分用 rust 实现 ext_authz filter+oltp 入库就够了。一开始图快用 go 做了个 ext_proc 的实现最近在往 rust 这边重构。
  • aaronrzh 楼主 07-09 10:28
    4
    @k00baa 问到点上了,自己测试过,会有点偏差
  • aaronrzh 楼主 07-09 10:30
    5
    @dummyx 很厉害啊,统计 token 这个比较麻烦
  • otakustay 07-09 10:41
    6
    这种中间层最害怕的是有一些转换不稳定,导致客户端控制的很好的缓存,过了中间层差了一两个字符,最后全没了
  • aaronrzh 楼主 07-09 10:58
    7
    @otakustay 这个我在 deepseek 上测试过,缓存命中还是挺高的
  • k00baa 07-09 14:38
    8
    @aaronrzh 只兼容一种模型缓存吗?
  • aaronrzh 楼主 07-09 15:05
    9
    @k00baa 不是啊,其他的没测,不过感觉只做转发,不会影响缓存的
  • aaronrzh 楼主 07-10 00:52
    10
    @k00baa 查了一下文档,终于发现统计不准确的地方,可能是因为 openAI 协议的流式响应默认不返回 usage,所以统计不准确,已经修复,可以更新测试一下
* 帖子来源V2EX
返回