查看: 9|回复: 7

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

[复制链接]

1

主题

3

回帖

9

积分

新手上路

积分
9
发表于 2026-7-9 09:48:40 | 显示全部楼层 |阅读模式
最近在做 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 交流。
回复

使用道具 举报

0

主题

37

回帖

74

积分

注册会员

积分
74
发表于 2026-7-9 10:00:35 | 显示全部楼层
star 支持
回复

使用道具 举报

0

主题

2

回帖

4

积分

新手上路

积分
4
发表于 2026-7-9 10:01:42 | 显示全部楼层
Token 消耗计算准吗?
回复

使用道具 举报

0

主题

3

回帖

6

积分

新手上路

积分
6
发表于 2026-7-9 10:08:12 | 显示全部楼层
我们也做了一个,不过网关是直接基于 agentgateway/envoy ,计费限额这部分用 rust 实现 ext_authz filter+oltp 入库就够了。一开始图快用 go 做了个 ext_proc 的实现最近在往 rust 这边重构。
回复

使用道具 举报

1

主题

3

回帖

9

积分

新手上路

积分
9
 楼主| 发表于 2026-7-9 10:28:27 | 显示全部楼层
@k00baa 问到点上了,自己测试过,会有点偏差
回复

使用道具 举报

1

主题

3

回帖

9

积分

新手上路

积分
9
 楼主| 发表于 2026-7-9 10:30:03 | 显示全部楼层
@dummyx 很厉害啊,统计 token 这个比较麻烦
回复

使用道具 举报

0

主题

2

回帖

4

积分

新手上路

积分
4
发表于 2026-7-9 10:41:01 | 显示全部楼层
这种中间层最害怕的是有一些转换不稳定,导致客户端控制的很好的缓存,过了中间层差了一两个字符,最后全没了
回复

使用道具 举报

1

主题

3

回帖

9

积分

新手上路

积分
9
 楼主| 发表于 2026-7-9 10:58:00 | 显示全部楼层
@otakustay 这个我在 deepseek 上测试过,缓存命中还是挺高的
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Powered by Discuz! X5.0 © 2001-2026 Discuz! Team.

在本版发帖
返回顶部