关于 Octopus 的发展

这个项目搁置了一段时间,最近开始重新捡起来了,经过这么长时间的沉淀,有些想法想和佬友们讨论一下,其实很久之前就想发个帖子了

主要是项目的定位问题

个人想法以及一些吐槽

最开始的定位就是 LLM API 聚合网关

但是发现协议太多了,当时想到的就只有 openai,openai_responses,anthropic 三种,后续随着用户变多,发现还有各种生图,嵌入,语言,视频等等,除此之外还有国内各种魔改的协议,自己一个人根本维护不过来,这期间虽然有很多PR帮我增加支持,一方面是太多AI生成的,而且PR前都不人工审核一遍,完全忽视我的要求

另一方面是当前PR没有问题,可是后续的BUG还是要我自己维护,我能力还是不够,力不从心^-^

后续迁移到 axonhub 作为协议转换,当时迁移到一半忙别的事情了,最近继续迁移发现还是有些吃力,不光是协议转换,还有代码架构上

这期间也尝试使用了别的网关 例如 9router omnirouter 感觉思路上和octopus差不多,但是协议转换上我用着总有一些小问题,而且UI审美我个人不太喜欢,后端也不够轻量(使用的nodejs,有的还要redis,还需要单独的数据库)

说这么多其实就是想和佬友讨论一下未来的发展方向和定位

目前我自己是这样想的:

- 保持单机部署,目前的分发功能是想直接删了的,目标就是给自己个人一个用户使用的,真的需要分发的话newapi就是一个很好的选择

- 各种官方的 oauth 渠道,在octopus前套一个cpa,目前不打算集成

- 尽量不和别的现有的功能完善的项目上功能重叠,就是一个,仅专注于openai/chat_completions,openai/responses,anthropic/messages这几种协议的个人网关,提供给agent使用

特色就是

- 轻量,单机部署,没有附属依赖组件,单二进制就能启动

- 服务端部署,VPS,NAS用户友好

- 分组作为模型名称进行负载均衡

- UI美观(我自己感觉是挺美观的,勿喷,有什么改进建议可以讨论一下)

- 用量统计

- 详细请求内容日志查看

其实和cc switch的网关功能有些重叠,但是cc switch是桌面端,octopus更偏向服务端

当然以上只是我的个人的想法,这个帖子发出来就是想听听各位佬友的意见,我很听劝