随着 gemini 的免费额度被砍
今天的 429 势不可挡
面对上万的key，似乎适合没有一个能用，一直报错
这时候，我发现，保证低错误率的关键反而是少key
设置 黑名单阈值为1 ，分组大概维持 10-20 个有效key
这样就能筛选出 有用的key
说的不好听，就是逮着有有效的key使劲薅
毕竟，成功过的key，下一次成功的概率远高于未知的key
23:00 错误率几乎达到30%，我改用少key的方法，之后稳得一批
12 个赞
只是分母减少而已，分子并没有增多。
问题是现在429的，下一分钟可能恢复正常了。
1 个赞
这个错误率OK不?
1 个赞
key太多可以用这个测试工具
一个Gemini测API key小玩具【更新】 - 开发调优 / 开发调优, Lv1 - LINUX DO
3 个赞
可以了吧 算一下才1000多点
谢谢佬提供思路方法
pgt-load这么优秀的作品，我竟然上个礼拜才用上，配上打野key，体验丝滑
牛逼 这个概率
我觉得要是加个并发请求功能就行了，一次性使用5个key发起请求，哪个成功返回的最快就用哪个，就跟DNS查询类似
感觉有点太浪费了
现在gemini额度降低了，并发只会更加浪费额度，让总的可用降低。
并且并发也只能非流，流式请求无法解决。
500次重试等得久么，我都没尝试这么高的重试数 
1 个赞
那你很有耐心了
我是设置的100次，还是不太行
后来把key筛选了一下就行了
不等不行啊
1 个赞
感谢大佬
本地docker的话，我放了八万多，然后直接全部用不了，要么空回复，要么错误，只能减少到两三万才正常使用