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
2
3
4
5
6
graph LR
A[Cherry Studio] --> B[Docker GPT-Load]
B --> C[CloudFlare Worker]
C --> D[Google AI API]
C --> E[断流检测]
E --> F[自动续传]

技术栈

  • 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
2
3
GPT-Load 根据负载均衡策略选择 API Key
→ 将请求转发到 CloudFlare Worker
→ Worker 作为中间代理层处理请求

第三步:CloudFlare Worker → Google AI API

1
2
3
CloudFlare Worker 携带选定的 API Key
→ 直接调用 Google AI API
→ 获取 Gemini 响应

第四步:响应处理与断流检测

1
2
3
CloudFlare Worker 接收 Gemini 响应
→ 实时分析响应内容
→ 检测是否被截断

2. 防截断机制 (基于 G.E.M. 方案)

截断检测算法:

1
2
3
4
5
6
7
8
9
10
11
12
13
// 伪代码示例
function detectTruncation(response) {
// 1. 检查响应长度是否异常短
if (response.length < expectedLength) return true;

// 2. 检查是否以不完整句子结尾
if (!response.endsWith('.') && !response.endsWith('!') && !response.endsWith('?')) return true;

// 3. 检查是否有截断标记
if (response.includes('[截断]') || response.includes('...')) return true;

return false;
}

自动续传流程:

  1. 检测截断: Worker 实时监控响应状态
  2. 保存上下文: 保留原始请求的上下文信息
  3. 构造续传请求: 基于截断点构造新的 API 调用
  4. 智能拼接: 将续传内容与原内容无缝拼接
  5. 返回完整响应: 返回给 GPT-Load 再转发给 Cherry Studio

3. 负载均衡策略

GPT-Load 配置示例:

1
2
3
4
5
6
7
8
9
10
11
12
# 多账户轮询配置
providers:
- name: "mako"
api_key: "${MAKO_API_KEY}"
quota: 8
- name: "grey"
api_key: "${GREY_API_KEY}"
quota: 10
- name: "fish"
api_key: "${FISH_API_KEY}"
quota: 10
hidden: true

故障切换机制:

  • 账户配额耗尽时自动切换到下一个可用账户
  • 网络异常时重试机制
  • 账户被封禁时自动禁用并告警

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: 初始版本,基础框架搭建
  • 待补充更多更新记录…

个人技术记录,持续更新中…