Grok Build反代改良版，提升大号池并发稳定性

背景

该帖子来自 LINUX DO 社区，作者分享了一款名为 grokbuild-pool 的开源项目，该项目是对原有 Grok Build 反代方案的改良版，旨在增强大规模账号池在高并发场景下的稳定性。作者原本看到社区另一位大佬 Chenyme 已经做出了类似成品（Grok2api 相关），自己还在 debug 阶段，一度觉得晚了一步，但最终本着“干就干完”的精神完成了项目。项目的核心定位是：面向需要多账号池调度且服务器内存“寸土寸金”、要求轻量化部署的开发者——对没有此类刁钻需求的用户则无使用必要。

核心内容

grokbuild-pool 是一个专注于 Grok Build 上游的大规模账号池代理工具，已实现以下功能：

• 支持 OpenAI Chat Completions / OpenAI Responses / Anthropic Messages 接口。
• 多账号池自动调度，采用 SQLite 冷库 + 内存热池的存储架构，兼顾持久化与高速访问。
• 会话粘性（Session Stickiness）与 Power-of-Two 选号算法进行账号分配，优化负载均衡。
• 提供 API 令牌、额度、RPM（每分钟请求数）和并发限制管理。
• 内置 Web 管理后台，支持 Docker 一键部署，默认服务端口为 8080。

与同类项目的对比（节选自原文表格）：

| 对比项 | grokbuild-pool | CLIProxyAPI | grok2api | |--------|----------------|-------------|----------| | 主要定位 | 面向 Grok Build 的大规模账号池代理 | 面向多种 AI CLI 订阅的统一 API 代理 | 面向 Grok Build 与 Grok Web 的完整网关 | | 上游范围 | 专注 Grok Build | Claude Code、OpenAI Codex、Gemini、Grok Build 等 | Grok Build、Grok Web | | 多账号调度特点 | SQLite 冷库、内存热池、会话粘性、Power-of-Two 选号 | 多 Provider、多账号轮询与负载均衡 | 优先级、额度门控、会话粘性、冷却与故障切换 | | 大规模账号池 | 核心设计目标 | 支持，但更侧重多 Provider 统一接入 | 支持，更侧重完整功能与管理体验 | | 客户端令牌管理 | 令牌额度与并发限制 | 提供 Management API，可搭配第三方 Dashboard | 完整 React 管理后台 | | 数据库 | SQLite | SQLite / PostgreSQL | Redis 支持 | | 更适合 | 只使用 Grok Build，重视账号池规模、调度性能和轻量部署 | 个人使用，希望统一接入多个 AI CLI / OAuth Provider | 需要 Grok Build、Grok Web、媒体生成和完整后台 |

创新点（作者自嘲“不知道有没有用，反正 Grok4.5 这样写了”）：

• 飞速的多账号上传：检测到大于某数值的 JSON 自动切块并行上传，耗时不到 30 秒，极大提升了账号导入效率。
• SSO（单点登录）转换功能尚不完善。

鸣谢：

• Grok2api 的前端设计借鉴自 @Chenyme
• 原 Grok Build 反代项目由 @greyGun 提供
• SSO 转 JSON 工具来自 @flymyd
• @lixuanye 的号池提供 API

作者还提到本项目大部分代码由 Grok4.5 以“vibe coding”方式编写，GPT5.6 sol 与作者本人进行 review，但难免有疏漏；因作者日后忙碌，项目可能疏于维护，欢迎自行 Fork 二开，issue 和 PR 可能无法及时回应。

关键要点

• 专注 Grok Build 上游：代理仅面向 Grok Build 的账号池，类型清晰。
• SQLite 冷库 + 内存热池架构：磁盘持久化（冷库）与内存快速存取（热池）结合，兼顾容量与速度，尤其适合内存有限的服务器。
• 会话粘性与 Power-of-Two 选号：通过粘性确保同一用户的请求落在同一账号上，减少切换开销；Power-of-Two 随机选号算法平衡负载。
• 轻量化部署：Docker 一键部署，默认端口 8080；管理后台为轻量页面，复杂度低于 grok2api 的 React 后台。
• 账号导入速度优化：自动检测大 JSON 并分块并行上传，30 秒内完成大量账号录入。
• 多账号调度与限流：内置 RPM、并发限制、额度控制，防止账号被过度使用。
• 项目维护状态：作者声明可能“疏于维护”，社区可自行 Fork 二次开发。

意义与影响

对于拥有大规模 Grok Build 账号池且需要轻量级反向代理的用户，grokbuild-pool 提供了一个实用选择。相比同类项目 CLIProxyAPI 和 grok2api，它更聚焦于 Grok Build 单上游，内存占用更低（依赖 SQLite 而非 Redis 或 PostgreSQL），账号调度策略（冷热分离、粘性、随机选号）针对高频并发场景进行了专门优化。其账号快速上传功能解决了大规模池的部署痛点。

尽管作者自谦为“玩具”，但该项目已在 LINUX DO 社区开源，并获得了其他开发者的参考与鸣谢，说明其设计思路具有实际参考价值。对于关注 Grok Build 生态、需要自建代理网关的开发者，该项目既可作为即用工具，也可作为二次开发的起点。其存在也丰富了 Grok 相关开源代理的生态，为用户提供了不同侧重的选项。