如何提升多个公益站渠道聚合后的可用性？

开发调优
,
1

感谢站内佬们提供的公益站，让我体验到token自由的感觉。我搭的是newapi，聚合了多个佬们的公益站接口。俗话说饱暖思淫，温饱解决了，就想吃的更好。 :laughing:

目前发现的痛点:

  • 有些站点快，有些站点慢，各家情况不同。同一站点在不同时间也可能有有很大变化。极端情况可能首字到达要一分钟，agent就搁在那转圈圈，看着干着急。
  • 一下蹬猛了，有的站点余额欠费，接口直接报错，但newapi不会自动切换，可能又因为会话有粘连性，开发进程就卡住了。

每次出问题都需要去后台翻看会话记录。如果是波动问题就需要手动禁用渠道。如果是接口报错，得分析是欠费还是单纯参数错误。这里还有个问题，可能同一渠道的其他模型也在用，那就得把渠道对应的模型手动删除。处置完后又感觉可惜，还得标注一下什么时间重新开启渠道或还原模型。

总的来说，维护这套“基建”，心智负担对我这种懒鬼还是有点大了。所以想问佬们有什么操作，可以提高优质接口的命中率，提升开发效率。

可能是一个我没发现的开关，可能是新的代理转发程序，也可能是newapi相关的边车服务，又或者有什么骚操作？希望佬们不吝赐教，畅所欲言。

当然，我本身也有全栈能力。如果真的没有办法，我就用ai开发一个newapi的边车回馈社区吧，我想象的功能大致是:

  • 定时拨测，指定模型并发测试多渠道接口。
  • 优选渠道，为每个请求打分，低分临时移除，高分保留。之前临时移除的接口也可以重新加入池子。
  • 错误处理，通过字符匹配或者一个小的模型判断，如果是欠费就临时移除。
  • 兜底保障，尽可能维持模型可用，让低分数的接口回归池子。

一个人的想象是有限的，希望能收割佬友们的智慧。 :distorted_face:

26.4.1更新：axonhub、ccload和metapi都试过了，目前只有ccload有超时自动故障转移的，虽然这个项目本身还不是很完善，但已经能解决问题了。

7 个赞
2

octopus 支持故障转移、轮询、随机、加权，但是测试不允许（一些公益站的限制）

见：octopus | 为个人打造的美观优雅的 LLM API 聚合服务 支持 会话保持 熔断 单渠道多KEY多端点 自动分组 自动同步上游模型 热重载 负载均衡 协议互转 用量统计

2 个赞
3

这怎么把他们聚合在一起呀

1 个赞
4

ccload，axonhub可以参考一下，我觉得ccload那个健康度更好些

4 个赞
5

我最大的痛点还是延迟波动大，提出拨测这个功能是个人所在行业使然。部分公益站确实会禁止批量测试，所以我希望的是以任务队列形式小体量长间隔的拨测。这个项目不错的，但不太适合我的需求，感谢佬友推荐。

6

可以自己vibe一个监测功能进去就是了

1 个赞
7

ccload 这个项目挺符合我的预期，按时延加权随机分流确实可以改善体验，自动故障切换功能又是未曾设想的惊喜:star_struck:，文档风格更是大受震撼。

1 个赞
8

我用cpa接入各种公益,newapi不用管接入,只管调用

1 个赞
9

sub2api聚合也蛮好用的

1 个赞
10

聚合是最基础的能力，添加多个供应商，用同一个模型名字自然就聚合了。

2 个赞
11

有个 metapi，也是做聚合的，不过倒是没注意是否符合你的需求

13

佬，我跟你的需求一样，你实现了吗？什么方案呢

14

我目前也是用的 newapi，在设置中，添加下面的禁用关键词：

用户额度不足, 剩余额度
无效的令牌
无效的令牌，数据库查询出错，请联系管理员
该令牌额度已用尽
预扣费额度失败，用户剩余额度

自动禁用状态码设置为：401,403,409-503

基本没啥问题了。

15

目前用 ccload 顶一段时间，这个项目其实用下来槽点很多，维护者也不太活跃，但能解决一部分问题

16

确实可以解决一部分接口报错的场景，但这个维护压力有点大，我太懒了，不想每天开关渠道。 :distorted_face:

17

不过我个人对波动不是很敏感，找了个学校里的教育网的线路，访问 cloudflare 延迟超低（50ms），比较稳

如果有条件可以试一下用境外的机器做中转，然后自己挂代理连中转，延迟和成功率会好一些？

我这边配置好之后还好，没有每天开关渠道？

1 个赞
18

如果是直连厂商接口确实是有必要的，但我大多是白嫖佬友的公益站 :rofl: ，各个站点的网络情况不太一致。

19

我也是。主要想实现： 一个模型背后多个上游，下游只调用一个模型，上游挂了自动切 :joy:

20

准备缝一个出来，蹲一下佬们思路

1 个赞
21

我也是白嫖的公益站。对那个“亲和性”设置又爱又恨…

1 个赞