1. 前言

Gemini 2.5 pro

Google 的 Gemini 2.5 Pro 模型无疑是当今最顶尖的 AI 模型之一，其慷慨的免费额度更是吸引了大量开发者。然而，这份“免费午餐”并非毫无限制。根据官方文档，其免费套餐的速率限制（Rate Limits）相当严格：

  • Gemini 2.5 Pro: 5 RPM (每分钟请求数), 100 RPD (每天请求数)

对于轻度使用或许足够，但对于开发者来说，5 RPM 和 100 RPD 的限制极易触发，导致服务中断或模型降级。

问题的关键在于：Gemini 的速率限制是基于单个 Google Cloud 项目的。这意味着，每一个独立的项目都拥有一套独立的免费额度。这个机制，正是我们优雅绕过限制、实现“额度自由”的突破口。

为了利用这一机制，社区中涌现了如 GPT-Load 和 gemini-balance 这样的优秀负载均衡工具。它们通过汇集来自不同项目的多个 API Key，将请求轮询分发，从而将速率上限提升数倍（例如，10 个 Key 即可将 RPM 提升至 50）。

本文将深入对比这两款热门的 Gemini API 负载均衡网关，并提供完整的部署思路，帮助你根据自己的需求，为你的 Roo Code 工作流选择并搭建最合适的“API 管家”。

2. 工作流解析

在深入部署之前，让我们先看一下这个模块化工作流的整体架构和核心组件。

2.1 整体架构

它由三个层面构成：客户端、API 网关（接入层）和模型服务。我们的目标是在客户端 Roo Code 和模型 Gemini 之间，插入一个我们自己控制的 API 网关。

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 在本文的工具组合中，Gemini 系列模型扮演了核心引擎的角色。选择它的理由很充分：顶尖的性能、慷慨的免费额度。但其“快乐”的背后也伴随着“痛苦”：严格的速率限制。因此，一个强大的负载均衡层不再是“可选项”，而是最大化利用 Gemini 能力、确保服务稳定性的“必需品”。

  • 客户端层：你的交互界面 Roo Code 在这个工具箱中，我们统一使用 Roo Code 作为交互界面。它是一个功能强大的 VSCode AI 编码助手，最大的特点是高度的可配置性，原生支持连接到任何兼容 OpenAI 或 Gemini 原生格式的 API 端点。这使得它能与我们自定义的网关完美配合。

2.3 接入层网关对比：GPT-Load vs. gemini-balance

接入层的两个主角，GPT-Load 和 gemini-balance，是这篇文章的核心。它们都解决了 Gemini API Key 的负载均衡问题，但设计哲学和侧重点截然不同。

GPT-Load: 性能与原生适配的极客之选

GPT-Load 是一个用 Go 语言编写的高性能 API 网关。

  • 核心优势：性能与原生 API。得益于 Go 语言的并发性能和对 Gemini 原生 API 格式的直接支持，GPT-Load 在与 Roo Code 等客户端协同工作时，响应速度更快，能更好地发挥 Gemini 模型的原生特性。
  • 通用性：它不仅能代理 Gemini，还能同时管理 OpenAI 等多种模型的 API，是一个更具通用性的“万能网关”。
  • 权衡：它的管理界面相对基础，更适合习惯于通过配置文件进行管理的开发者。

gemini-balance: 功能与易用性的友好选择

gemini-balance 是一个专为 Gemini 设计的负载均衡器，用 Python 编写。

  • 核心优势：功能与兼容性。它最大的特点是提供了一个功能非常丰富的 Web UI，让 API Key 的管理、监控变得直观方便。它通过维护一个 API Key 池，并将收到的请求以轮询方式分发到这些 Key 上，从而实现负载均衡。同时，它将 Gemini API 巧妙地包装成了 OpenAI 的标准格式，这对于那些只支持 OpenAI 格式的工具生态来说，是巨大的福音。
  • 专注性：它专注于做好 Gemini 的代理，功能打磨得非常完善。
  • 权衡：为了实现格式转换和丰富的功能，其性能表现理论上可能不及 GPT-Load。

横向对比总结

特性维度 GPT-Load (性能派) gemini-balance (功能派)
核心定位 高性能、通用的 API 网关 功能丰富、易用的 Gemini 专项代理
开发语言 Go Python
性能表现 更高 (Go 语言优势，原生 API) 标准 (Python 实现)
API 格式 支持 Gemini 原生格式 & OpenAI 格式 包装为 OpenAI 兼容格式
管理界面 较为基础 功能丰富的 Web UI
主要优势 速度快，原生适配 Roo Code 兼容性好，管理方便
适合用户 追求极致性能、需要管理多模型的开发者 看重易用性、Web UI 和 OpenAI 生态兼容性的用户

3. 部署步骤

3.1 第一步：获取 API Keys (共同的基石)

无论你选择哪个网关，都需要先准备好一个 API Key 池。

  1. 创建多个 Google Cloud 项目：一个标准 Google 账户可创建约 12 个项目。(创建地址)
  2. 为每个项目生成 API Key：在 Google AI Studio 中，切换到不同的项目，为每个项目单独生成 Key。(生成地址)

风险提示：直接使用个人主力 Google 账户创建大量项目和 Key 可能存在被风控的风险。为了安全起见，建议使用一些非关键的 Google 账户进行操作。

3.2 第二步：部署 API 网关

获取到足量的 API Key 后，就可以部署你选择的网关了。你可以根据官方文档的指引，将其部署在本地、个人服务器（VPS）或者 Heroku、Vercel 等云平台上。

部署完成后，记下你的服务地址和访问凭证（API Key 或 Token）。

3.3 第三步：配置 Roo Code

最后一步，就是将 Roo Code 指向你刚刚部署好的网关。

在 Roo Code 的设置中，找到 API 端点（Endpoint/Base URL）和 API Key 的配置项：

  • API Key: 填入你在部署网关时设置的访问凭证。
  • Endpoint / Base URL: 填入你的网关服务地址 (例如 http://localhost:8000/v1)。

完成配置后，Roo Code 的所有请求都将通过你的专属网关发出，从而实现对 Gemini API 的“无限”免费调用。

4. 结论

通过上述对比和解析，我们可以清晰地看到 GPT-Load 和 gemini-balance 各有侧重。

  • 选择 GPT-Load，如果你是追求极致性能的硬核用户，希望与 Roo Code 等原生客户端达到最佳配合，并需要一个统一的网关来管理包括 OpenAI 在内的多种模型。
  • 选择 gemini-balance，如果你更看重开箱即用的便利性、友好的 Web 管理界面，并且你的工具生态更依赖于标准的 OpenAI API 格式。

最终，选择哪个工具取决于你的核心诉求：是追求极致的性能与原生体验，还是更丰富的功能与管理便利性。无论选择哪一个，你都将为你的 AI 工作流增添一个强大的 API 管理核心，彻底告别速率限制的烦恼。