Ultimate Plan for Gemini API Calls
Gemini API Key 终极管理方案 - 个人技术记录
📋 概述
Gemini API Key 管理方案,解决 API 调用限制、断流问题以及多账户负载均衡。
🔐 Account Status
当前账户配置
- mako:
main, online
✅ - grey:
main, online
✅ - fish:
mylove, hidden
🔒 - aibots:
deprecated, exposed
❌ (开小号被发现了)
账户配额
账户 | 配额 | 状态 |
---|---|---|
mako | 8个 | 主用 |
grey | 10个 | 主用 |
fish | 10个 | 备用 |
扩展计划
- 手机 Google Mail 注册新账户增加 Key 数量
- Chrome 匿名模式管理小号
- 避免在非匿名环境中操作小号
🏗️ 技术方案
核心架构
1 | graph LR |
技术栈
- GPT-Load: 负载均衡和API管理
- CloudFlare Worker: 断流检测和自动续传
- Docker: 容器化部署
- Google AI API: 底层服务
🔧 详细工作原理
1. 请求流程详解
第一步:Cherry Studio → GPT-Load
1 | Cherry Studio 发送请求 → Docker 容器中的 GPT-Load 接收 |
第二步:GPT-Load → CloudFlare Worker
1 | GPT-Load 根据负载均衡策略选择 API Key |
第三步:CloudFlare Worker → Google AI API
1 | CloudFlare Worker 携带选定的 API Key |
第四步:响应处理与断流检测
1 | CloudFlare Worker 接收 Gemini 响应 |
2. 防截断机制 (基于 G.E.M. 方案)
截断检测算法:
1 | // 伪代码示例 |
自动续传流程:
- 检测截断: Worker 实时监控响应状态
- 保存上下文: 保留原始请求的上下文信息
- 构造续传请求: 基于截断点构造新的 API 调用
- 智能拼接: 将续传内容与原内容无缝拼接
- 返回完整响应: 返回给 GPT-Load 再转发给 Cherry Studio
3. 负载均衡策略
GPT-Load 配置示例:
1 | # 多账户轮询配置 |
故障切换机制:
- 账户配额耗尽时自动切换到下一个可用账户
- 网络异常时重试机制
- 账户被封禁时自动禁用并告警
4. 技术实现要点
CloudFlare Worker 核心功能:
- 中间代理: 作为 GPT-Load 和 Google API 之间的桥梁
- 自适应混淆: 动态调整请求参数避免检测
- 上下文保持: 在续传过程中保持对话连贯性
- 错误处理: 完善的异常处理和重试机制
📊 部署进度
✅ 已完成
- 三个账户配置完成
- API配额分配
- 基础架构搭建
🔄 待完成
- 手机 Google Mail 注册新账户增加 Key 数量
- 优化 old 方案,看保留做备用还是直接彻底擦除
- 其他API如阿里云的配置
⚠️ 重要提醒
🚨 关键问题:手机端兼容性
忘记了! 这个方案是完全给 LapTop 私密化 的…
所以必须保留一些原先的服务器管理 API Key 调用方案给手机 ChatBox 使用
🎯 应用场景分配
Allocate 策略
应用 | 方案 | 说明 |
---|---|---|
Cherry Studio | 新方案 | 调用Gemini的话全部这个方案~~ 其他方案可以先设置为 unseen |
ChatBox | 老方案 | 得用老方案,这个是手机端的 |
RooCode etc | 观望 | 先不动再说,看Cursor和ClaudeCode能否稳定长期使用 |
🔍 待考虑的~
想起来什么再补充
- 所有的key应该有记录,整个加密文件
- 监控和告警机制
- 成本统计和分析
- 备份和恢复策略
📚 Ref
- GPT-Load
- G.E.M. - 让 Gemini 自动续写被截断的对话【无缝断点续传 | 自适应混淆】
- 完全解决Gemini 断流问题!!!(有点麻,还是有中断)好像修复了?移步新帖讨论
- [Gemini公益] 防断流v2|已测试 效果不错
📝 更新日志
- 2025-08-12: 初始版本,基础框架搭建
- 待补充更多更新记录…
个人技术记录,持续更新中…