TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Gemini Balance：將多把 Gemini 金鑰輪詢成一個穩定端點
Gemini Balance 是開源的 Gemini API 輪詢代理：多把金鑰照順序派工、壞了自動停用、每小時探測恢復，同一個端點同時開 OpenAI 與 Gemini 兩種格式。2026 年 4 月起 AI Studio 改發 AQ. 開頭金鑰，管理介面還認不得，部署前先對齊金鑰格式與維護現況。
用 AI 摘要這篇文章：
想整理 Gemini 金鑰的人，搜尋後第一個遇到的通常是 New API 這類通用閘道：一台伺服器管住所有供應商的金鑰，渠道、權杖、計費一次處理。如果你要的就是這種全能櫃檯，去架那套就好。Gemini Balance 走的是另一條窄路：它只服務 Google Gemini 這一家，把多把 API 金鑰放進同一個自己管理的服務，對外只開一個端點，內部照順序輪流派工。照顧的範圍小一個量級，要設定的東西也少一個量級。
先把結論放前面：手上已經有一批 AIzaSy 開頭的舊格式金鑰、想把它們輪詢成一個穩定端點，這套工具的機制在原始碼裡一條條對得出來，值得自架。但 2026 年才要新申請金鑰的人得先停一下，因為 Google 已改發 AQ. 開頭的新格式金鑰，而這套工具的管理介面在 2026 年 9 月仍認不得它，對應的支援 issue 從 2026 年 6 月開著至今無人修。整個專案的維護也停在 2025 年。金鑰格式、維護現況、該部署哪一個版本，這三件事對齊了再動手，才不會白架一輪。
和通用閘道怎麼分工：只顧 Gemini 這一家
Gemini Balance 是用 Python 加 FastAPI 寫的開源服務，倉庫裡對自己的描述就一句話：Gemini 輪詢代理服務。它不做多供應商的格式轉換中樞，不處理儲值與帳務，只回答一個問題：很多把 Gemini 金鑰，怎麼變成一個看起來永遠活著的端點。上游倉庫截至 2026 年 9 月有五千八百多顆星、一千一百多個複本，在這類自架小工具裡算是被大量使用過的等級。
窄歸窄，它和通用閘道並不是互斥的選擇。README 特別寫明模型清單端點與 NewAPI 的自動抓模型清單完全相容，也就是說你可以把 Gemini Balance 架在前面顧金鑰輪詢，再讓通用閘道把它當成一個上游渠道接走，兩層各做各擅長的事。真的要自己驗證端點通不通、回應速度長什麼樣，之前介紹過的 LLM API Test 這類瀏覽器工具就能直接打幾發看看。
還有一種人會特別感受到它的好：金鑰是公司或團隊共用的。免費額度的速率限制跟著單把金鑰走，一把金鑰同時被三個專案搶，尖峰期互相踩踏的情況很常見。把金鑰收進一個池子統一派工，哪把被限流、哪把恢復了，狀態頁上一目了然，用的過程中少掉很多互相猜測的溝通成本。
輪詢就是照順序派工，壞了自動停用
「負載平衡」四個字在這裡的實際含義，看 key_manager.py 就很清楚：服務啟動時把金鑰清單丟進 Python 的 itertools.cycle，配一把鎖，每次請求進來就拿下一把金鑰，用完一輪從頭再來。它是嚴格的順序輪詢，不看哪把金鑰比較快、也不看誰的額度剩得多，流量就是平均分攤。這種設計對免費額度金鑰池很夠用，但別期待它做智慧調度。
壞金鑰的處理鏈做得最完整。單次請求失敗可以照 MAX_RETRIES 換下一把金鑰重試，預設三次；同一把金鑰的失敗會累計，到 MAX_FAILURES 就自動停用（程式內建值是 3，範例設定檔放寬成 10）；背景排程器每 CHECK_INTERVAL_HOURS（預設一小時）用設定檔指定的測試模型對失敗過的金鑰（含已停用的）發一次探測，成功就把失敗計數歸零、讓金鑰回到正常輪詢。也就是說半夜某把金鑰被限流或失效，隔天早上它在狀態頁上會自己復活或躺著，不用人盯。
狀態頁本身就是這套工具的核心賣點之一：/keys_status 頁面（需要認證）即時列出每把金鑰的可用狀態與用量，另有完整的呼叫日誌與錯誤記錄可查，單次呼叫走過哪把金鑰、遇到什麼錯誤都留得下來，排查效能瓶頸時有東西可看。管理後台的設定改完按儲存直接生效，不用重啟容器。設定範例則要看對版本：fork 的範例檔凍結在 2025 年 7 月，測試模型寫 gemini-1.5-flash、思考模型用當年的預覽版名稱；上游現在的範例已換成 gemini-2.5-flash-lite 這類現行值，照上游映像檔部署的人不必急著動這些設定。
一個端點兩種協議：OpenAI 的程式換個網址就能接
同一個實例同時開兩種路：Gemini 原生格式走 http://localhost:8000/gemini/v1beta，OpenAI 格式走 http://localhost:8000/v1。已經寫死 OpenAI SDK 的應用，把 base_url 換成自己的服務、金鑰換成自己設定的存取權杖，程式一行都不用動就接上 Gemini。OpenAI 格式的 embeddings 端點也在，拿來做本地文件的向量化可以直接沿用既有程式碼。
在模型名後面加後綴就能切換能力：把某個模型填進 IMAGE_MODELS，呼叫端改用「模型名-image」就能走圖文對話與修圖；填進 SEARCH_MODELS，用「模型名-search」就會帶聯網搜尋。同一把金鑰池打開多模態與搜尋能力，不用另外架服務。圖片生成還做了轉接，imagen-3.0-generate-002 被包成 OpenAI 的圖片生成 API 格式，用戶端照習慣的介面呼叫。上游模型清單太長的話，FILTERED_MODELS 可以把用不到的型號濾掉，清單也支援自動抓取最新版。
幾個貼近日常使用的小開關也藏在設定檔裡：串流回應有可選的最佳化器，調整長文字串流的節奏，讓邊收邊顯示的應用讀起來更順；搜尋結果要不要附原始連結、思考過程要不要攤給呼叫端看，都有獨立開關。這些細節不影響核心輪詢，但對真的接上線的應用來說，體感差異都來自這一層。
2026 年的新金鑰格式，是它最現實的斷層
前面結論提到的那條分流線，值得單獨展開。管理介面批次匯入金鑰時，前端用一條正則式判斷什麼是有效金鑰，config_editor.js 裡寫的是 /AIzaSy\S{33}/g，只認 AIzaSy 開頭加三十三個字元的傳統格式。上游 issue 回報 2026 年 4 月起 Google AI Studio 開始改發 AQ. 開頭的新格式，這條正則式直接把它擋在門外。上游倉庫對應的適配 issue 從 2026 年 6 月開著，到 9 月仍是開著的狀態，唯一一個想做支援的合併請求被關閉了、沒有被採用。
有個容易混淆的地方要說清楚：系統裡本來就有 AQ. 開頭的金鑰，但那是 Vertex Express 那條軌，設定檔的 VERTEX_API_KEYS 吃的就是這種開頭五十三碼的格式，批次匯入視窗也明寫了這個規格。所以斷層專指 AI Studio 免費金鑰這條最常見的路，不是所有 AQ. 都進不去。實際影響很直接：手上那批是過去幾年慢慢攢下的舊格式存量，這套工具的輪詢機制照樣吃得下（金鑰本身在 Google 端是否仍有效，部署前先用一兩把試打確認）；那批是 2026 年 4 月以後才新申請的，先到 AI Studio 的管理頁看清開頭是 AIzaSy 還是 AQ.，再決定要不要花這個架子。
部署用上游映像檔，說明書讀 fork 繁中版
搜 Gemini Balance 會找到兩個倉庫，關係要理一下。上游 snailyp/gemini-balance 是主專案，2024 年 12 月建立，一年九個月裡累積四百多次提交、三十五位貢獻者、七十四個版本標籤，一路更新到 2025 年 9 月，最後一個正式版 v2.2.8 停在 2025 年 9 月 23 日，倉庫最後一次推送也在 9 月底。yulin0629 的繁中化版本是它的 fork，2025 年 7 月建立，實際活躍只有四天，之後設定的每日上游同步從 7 月中就天天失敗、一次都沒成功過，每天留一則失敗報告直到 2025 年 11 月底才停止，fork 倉庫一百四十個開著的 issue 幾乎全是這些同步機器人的報告，不是真的使用問題。有趣的是上游的 issue 區到 2026 年 8 月還有人留言問金鑰申請的問題，社群還在用，只是沒有人再出面修東西。
fork 的兩個主要賣點，一個已經過時：它宣稱獨有的 countTokens 端點（發送前先算 token 數），上游後來自己也有了，路由在 gemini_routes.py 裡對得上。另一個仍然成立，就是完整的繁體中文 README 與一份反向代理設定指南，教你在本機用 nginx 把 Gemini Balance 偽裝成標準的 Google API 端點，連 hosts 與本機憑證都一步步寫。更實際的是，fork 的 docker-compose 拉的照樣是上游的 ghcr.io/snailyp/gemini-balance 映像檔，兩邊跑的其實是同一份程式。所以答案不難：部署用上游映像檔，說明書讀 fork 的繁中版，各取所長，不用二選一。
部署的最低輪廓是一台能跑 Docker 的機器：官方 docker-compose 起兩個容器，服務本體加一個 MySQL 8，環境變數寫好金鑰清單就能動；嫌資料庫麻煩可以換 SQLite，本機跑 uvicorn app.main:app 也行。fork 附的那份反向代理指南價值在細節：nginx 設定、用 mkcert 簽本機憑證、hosts 指到本機，讓既有的應用完全不感知後面換了人，指南還附了切換代理、更新連接埠與完整移除的管理腳本。上游自帶的說明站 GB Docs 還活著，上面有 Hugging Face、Zeabur、Render 這類平台的部署教學，不想自己顧機器的人有現成路線。
授權、金鑰去哪，以及網路上兜售的 Gemini API
授權條款要單獨看一眼，因為它不是常見的 MIT 或 Apache：整個專案採用 CC BY-NC 4.0，署名、非商業性使用。自己架、公司內部用、改來玩都沒問題；拿去開收費 API、打包轉售這類營利行為是授權明文禁止的，條款裡連 SaaS、二次銷售、收費分發都逐一點名，真有商業需求要找原作者拿書面授權。README 還附了一段作者聲明，說他從未在任何平台販售這套服務，市面上兜售的都是轉賣者。對照網路上不時出現的低價 Gemini API，這段聲明剛好提供了一個辨識基準：來路不明的廉價端點，背後可能就是這類開源服務套殼，穩定度與金鑰來源都是問號。
資料流向也順著自架的性質想清楚。金鑰只存在自己的環境變數與資料庫裡，請求內容經過自己的服務轉發到 Google，日誌與用量統計落在自己機器上。這比把金鑰交給第三方中轉站好非常多，但它畢竟是一個自架的轉運服務，不是應用程式直連 Google：代理這一層看得到流量，對外的信任邊界取決於你自己怎麼顧這台機器。另外也可以設定一組 HTTP 或 SOCKS5 的代理池，每個請求由程式自動分配代理，還能設成同一把金鑰固定走同一個節點，用不到的人無感，需要的人不用改程式。
順帶一提，把金鑰留在自己身上的工具我們介紹過幾個，像 SkidHomework 就是自備 Gemini 金鑰、瀏覽器直連的例子。Gemini Balance 解決的則是另一端的問題：金鑰多的時候怎麼管。
舊金鑰庫值得整理，新申請金鑰先確認格式
收斂成決策：手上有三把以上的 AIzaSy 舊格式金鑰，分散在不同專案或不同機器，架一套 Gemini Balance 把它們收斂成一個端點，加上 OpenAI 格式相容與狀態頁，成本很低、效益清楚。金鑰是 2026 年 4 月以後新申請的 AQ. 格式，先別動工，去上游 issue 區看適配進度，或考慮直接走 Vertex Express 那條本來就支援 AQ. 的軌。需求跨好幾家供應商，通用閘道比它合適。想要的是智慧調度、權重分流那種細緻負載平衡，這套順序輪詢也滿足不了。
最後把界線講清楚：這篇的機制描述都從倉庫的原始碼、設定檔與說明文件直接核對出來，查證時間點是 2026 年 9 月；實際部署打流量的穩定度、延遲與併發表現，這裡不做任何結論，真要上生產，架好之後先拿測試工具打一輪再說。維護停更加上金鑰格式轉換期，這套工具正處在能用但要自己扛責任的階段，好處是程式就在那裡，出問題至少看得見原因。
