1. 前言
根据官方文档，Gemini 2.5 Pro 免费额度的速率限制为：
- 5 RPM（每分钟请求数）
- 100 RPD（每天请求数）
限制按“Google Cloud 项目”计。多个独立项目意味着多份独立额度。将多个项目的 API Key 组成“Key 池”，并通过网关以轮询方式分发请求，可线性提升吞吐（例如 10 个 Key≈50 RPM）。
本文对比两款常用网关（GPT-Load、gemini-balance），并给出部署与 Roo Code 接入配置，目标是构建一个稳定、可扩展的 Gemini 工作流。
2. 工作流解析
在深入部署之前，让我们先看一下这个模块化工作流的整体架构和核心组件。
2.1 整体架构
三层结构：客户端、API 网关、模型服务。核心思路是在 Roo Code 与 Gemini 之间增加自管网关。
graph TD
subgraph "客户端层"
A1[Roo Code]
end
subgraph "接入层 (二选一)"
B1[GPT-Load]
B2[gemini-balance]
end
subgraph "模型服务层 (核心)"
C[Gemini API]
end
A1 -- "API请求" --> B1;
A1 -- "API请求" --> B2;
B1 -- "负载均衡" --> C;
B2 -- "负载均衡" --> C;
style A1 fill:#f9f,stroke:#333,stroke-width:2px
style B1 fill:#9cf,stroke:#333,stroke-width:2px
style B2 fill:#9cf,stroke:#333,stroke-width:2px
style C fill:#ccf,stroke:#333,stroke-width:2px
2.2 核心组件
- 模型服务层（Gemini）：性能强、额度友好；速率按项目计，需要网关做 Key 轮询与熔断控制保障吞吐与稳定。
- 客户端层（Roo Code）：VSCode AI 助手，支持自定义 OpenAI/Gemini 端点，易于接入自建网关。
2.3 网关对比（GPT-Load vs. gemini-balance）
两者都能对 Gemini API Key 做轮询分发，但有些不同：
- GPT-Load（Go）：原生支持 Gemini 与 OpenAI 格式，性能强、并发好；配置驱动，UI 基础。适合追求吞吐与多模型统一管理的用户。
- gemini-balance（Python）：OpenAI 兼容封装，内置 Web UI，Key 池管理直观，上手快。适合看重易用性与 OpenAI 生态兼容的用户。
3. 部署步骤
3.1 获取 API Keys（共同）
注意：批量创建与使用可能触发风控，建议使用非关键账户。
容量与多账号建议：
- 多账号 + 多项目：建议至少 5 个 Google 账户，每个账户≈12 个项目，共≈60 个 Keys，便于高并发“畅用”。
- 粗略估算：吞吐上限≈Key 数×5 RPM；日配额≈Key 数×100 RPD（以 Gemini 2.5 Pro 免费档为准）。例如 60 Keys≈300 RPM、6000 RPD（理论值，受网关调度与并发上限影响）。
- 网关策略：启用轮询分发、对配额耗尽/限流的 Key 做短期跳过与退避，定期健康检查；按网关文档开启失败重试与熔断以提升稳定性。
3.2 部署 API 网关
支持本地、VPS、或无服务器平台。参考：
- GPT-Load ：https://github.com/tbphp/gpt-load
- gemini-balance ：https://github.com/snailyp/gemini-balance
完成后记录服务 Base URL 与访问凭证（API Key/Token）。
3.3 配置 Roo Code
在 Roo Code 设置中：
- API Key：使用网关侧凭证。
- Endpoint/Base URL：指向网关地址（如
http://localhost:8000/v1）。
说明：
- 使用 GPT-Load 时，可走 Gemini 原生或 OpenAI 兼容路由，按网关文档选择对应模型标识。
- 使用 gemini-balance 时，走 OpenAI 兼容接口（
/v1），模型名与网关映射保持一致。