引言

事实上，为个人打造的LLM聚合网关系统已经有很多，例如octopus，metapi等，究竟要不要重复造一个轮子让我思考了很久。

最终，如你所见，lens还是诞生了。

所以，当前的开源系统肯定没有lens想要做的样子，总结一下，我有以下鄙见：

lens没有多个协议互转功能

因为都26年了，能调用llm api的软件理应都具有每个广商的协议调用。

但是lens却保留了两条我认为真正有价值的单向转换：

• chat->response
• chat->anthropic

首先我们都知道，response是Agent时代更推荐的协议，而很多newapi站点的模型仅提供了chat，我很喜欢response的多步输出，能够让我知道它是否活着，要是网不好，chat很容易造成什么都没有，现在我在codex/cherry studio总是使用着response。其次需要chat->anthropic功能，那就是为了能够在cc使用了，这个道理就不用多说了。

lens 更轻，因为它只想做网关

构造lens的理念就是觉得现有的系统过于冗余，lens只是想成为API 网关或者说得更大的范围就是ai infra路由中的一层，因此未来的更新都将围绕这方面进行更新，而站点，账号导入等功能不是lens想要包含的内容。

我觉得通过各种工具的组合会胜过统一集合体，毕竟也有人不需要这样的功能。

谁说python就不能在光里做英雄！

看到太多的go，ts，rust项目了。呜呜，python也想说自己可以，大部分推理框架例如vLLM、SGLang都是python写的，写的聚合项目速度再怎么快，上游也不给力啊，何况项目定位的是个人使用，简简单单的高并发python也是可以的，所以你可以把lens看成python版的个人api聚合网关~

lens不是想打败谁，也不是想证明其它项目不好。它只是选择了一条更克制的路线。

如果你也希望有一个轻量化工具，能把 OpenAI、Anthropic、Gemini等上游统一起来，同时还能看清路由、日志、成本和配置，那就快来https://github.com/dyedd/lens看看吧。

功能

现在来总结一下lens的功能：

• 上游渠道管理，只要上游支持OpenAI Chat、OpenAI Responses、Anthropic、Gemini那就可以聚合。还可以在这里对请求内容进行参数覆盖和请求头增加，可以强制在cc启动某些参数，方便国产模型和国外模型的迁移。
• 模型组管理，在这个组合，你需要规范化模型名称，应该通过这个对外保留名称和生成模型价格。当然，我还实现了模型路由功能，例如把opus的请求全路由到kimi去。
• 路由策略，目前仅做了轮询和故障转移的功能。
• 协议入口，我觉得模型用什么协议是需要人为固定的, 因为还存在2个协议转换功能，所以例如anthropic协议的模型也是可以把chat加入。
• 网关 API Key
• 请求日志
• Token 和成本统计
• 一些定时任务，例如更新价格，清空日志等等
• 配置备份迁移

界面如下所示，总体设计看起来简约清爽。

部署

在目录放置 docker-compose.yml和.env两个文件即可：

启动前请编辑 .env，至少修改 LENS_AUTH_SECRET_KEY。

如果需要修改数据目录，那就改 volumes 左侧的宿主机路径，右侧 /app/data 保持不变：

最后，拉取并启动线上镜像：

更多的部署方案可以看项目的README。

更多的使用方法也可以看项目的README，就不再多余阐述了。

厚言

为什么要把这个项目成为lens呢，lens的翻译是透镜/镜片，我们可以拿着镜片将各种光给聚合在一起~这和项目的含义不谋而合。

感谢你读到了这里，欢迎使用我的项目！

地址：https://github.com/dyedd/lens