GPT-Load：把多把上游憑證收進一個自架閘道
Self-hosted AI gateway for multi-channel, multi-credential setups — API keys and subscription accounts, scheduling, failover, request logs and usage. 自托管 AI 网关：多渠道多凭据统一接入，含密钥与订阅账号、调度容错、日志与用量。
秒懂
- 它是什麼？
- GPT-Load 以 Go 撰寫、MIT 授權，把 OpenAI、Anthropic、Gemini 等原生協議的上游憑證集中在單一入口後面，內建排程、冷卻與黑名單。它的價值在憑證治理，代價是 2.0 與 1.x 資料不相容，且目前仍停在 rc 階段。
- 適合誰用？
- 如果你手上同時有多把 OpenAI、Anthropic、Gemini 金鑰，或混用 Codex、Claude 這類訂閱帳號，而且願意自己跑 Docker 與資料庫，GPT-Load 的群組、AccessKey、冷卻與黑名單機制能省下自行拼裝輪替邏輯的工。反過來說，單一上游、單一金鑰的使用者不需要它；把閘道當成跨供應商語意轉換層的人也不該選它，因為 README 的定位是客戶端維持原生介面。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
一把 AccessKey 後面藏著多少把上游金鑰
多數團隊的 AI 呼叫一開始都很乾淨：一把金鑰、一個 base URL。等到某個模型開始限流，或某個供應商的免費額度用完，程式裡就開始出現分支，接著是環境變數、再接著是某個同事寫的輪替腳本。GPT-Load 想處理的正是這個階段。README 的敘述是應用程式只需要一個 base URL 和一個 AccessKey，供應商、帳號、憑證、模型與路由策略全部在管理介面裡設定。
它服務的對象因此很明確：手上握有多把同質金鑰、或同時使用官方 API 與訂閱型帳號的維運者。README 特別點出 Codex、Claude、Antigravity、Grok 與 API key 通道共用同一套憑證管理、排程與健康處理，這句話的份量在於訂閱帳號過去很難和 API key 放進同一套調度邏輯，因為前者的失效模式是配額窗口重置，後者是速率限制或金鑰撤銷。
如果你只有一把金鑰、一個上游，這個專案對你沒有任何好處，你只是多養一個容器和一個資料庫。
群組、通道、AccessKey：三層設定決定了流量怎麼走
從 README 的初始設定章節可以還原出它的資料模型。第一層是通道，代表一個上游服務，底下掛一或多把 API key；訂閱型通道則走 OAuth 流程或匯入憑證。第二層是群組，從通道挑選，並設定可用模型與執行期策略。第三層是 AccessKey，指定它能使用哪些群組與客戶端協議。
這個分層的實際意義是權限邊界。README 提到 AccessKey 有唯讀首頁，用 AccessKey 登入只看得到它自己的群組、模型、請求、用量與成本額度。對內部分發來說這比共用管理金鑰合理得多：你可以給每個應用或每個團隊一把 AccessKey，出事時能沿著 AccessKey 追到群組，再追到通道與具體憑證。
排程與容錯落在通道與群組這一層。README 列出的機制包括多憑證調度、可設定權重、重試、冷卻、黑名單與會話親和。這些詞單獨看很普通，但組合起來描述的是一個失敗隔離的流程：某把憑證被上游拒絕後進入冷卻，權重決定其他憑證吃下多少流量，會話親和則讓同一段對話盡量留在同一把憑證上。最後一點對多輪對話尤其重要，因為上游的 prompt cache 綁在帳號上，換憑證等於快取歸零。README 的用量頁把快取命中率列為觀察指標，兩者互相呼應。
需要保留的是，這些行為的細節（冷卻時長、權重如何計算、黑名單何時解除）在提供的 README 片段裡沒有展開，實際數值得看管理介面或原始碼。
從 docker compose 到第一個 AccessKey 的實際路徑
部署路徑在 README 裡寫得很短。需要 Docker 與 Docker Compose，然後複製倉庫、複製環境檔、啟動：
git clone --depth 1 https://github.com/tbphp/gpt-load.git cd gpt-load cp .env.example .env docker compose up -d
啟動後用 curl --fail http://127.0.0.1:3001/health 確認服務起來。首次啟動會產生管理金鑰，讀取方式是 docker compose exec gpt-load sh -c 'cat /app/data/auth.key'，README 提醒要妥善保存。也可以在啟動前於 .env 明確設定 AUTH_KEY。預設只監聽 loopback，不對外暴露，這個預設值對自架工具來說是對的。
有一個容易踩到的限制寫在訂閱通道的摺疊段落裡：Codex、Claude 與 Antigravity 的 OAuth 客戶端使用固定回呼埠，Compose 會把它們發佈在 HOST 指定的位址上，預設 127.0.0.1；設成 HOST=0.0.0.0 會連同這些回呼埠一起發佈到所有介面。因為埠由上游客戶端固定，同一台主機同時只能跑一個預設 Compose 實例。要在同一台機器上開第二個環境，就得處理這個衝突。
同一段還提到遠端情境：透過 SSH 或遠端瀏覽器操作時，瀏覽器的 localhost 可能連不到 GPT-Load，解法是把完整回呼 URL 貼進授權對話框。這是 OAuth 走本機回呼的常見毛病，不是這個專案獨有，但它確實需要使用者手動繞過。
資料層面，README 說內嵌 UI 由 SQLite、MySQL 或 PostgreSQL 支撐，憑證在本機加密。三種資料庫的取捨（單機 SQLite 對多實例 PostgreSQL）在提供的材料裡沒有比較，只能說選項存在。
客戶端協議清單透露的定位：閘道，不是翻譯層
README 的協議表列出 OpenAI Chat Completions、OpenAI Responses 及其資源路徑、OpenAI Images、OpenAI Embeddings、Rerank 等主要入口。搭配 Why 段落那句「客戶端維持 OpenAI、Anthropic 或 Gemini 原生介面」，可以推出一個明確的設計立場：GPT-Load 讓同協議的流量通過，而不是把 A 協議即時轉成 B 協議。
這個立場會直接影響你的採用判斷。如果你的需求是「用 OpenAI SDK 呼叫 Claude 模型」，你要找的是轉換層，不是這個專案；README 的敘述反而是在說你可以繼續用 Anthropic 原生介面，只是入口換成閘道。反過來說，如果你的問題是「我有一堆同協議的憑證和帳號要調度」，那協議轉換對你毫無價值，憑證治理才是。
Responses 及其資源路徑被單獨列為一列，說明這個較新的 OpenAI 介面有被納入範圍，但 README 片段在此處截斷，後續還有哪些協議沒有完整列出，這點無法從手上材料確認。
2.0 與 1.x 之間的資料斷層
README 在快速開始之前放了一個警告框，語氣比一般專案重：如果你正在用 1.x，先讀遷移章節，因為 2.0 無法就地開啟、匯入或遷移 1.x 資料。
這不是文件寫得不清楚，而是產品層級的決定。對已經在生產環境跑 1.x 的團隊，這意味著升級等同於重新建置：新的資料庫、重新設定通道與群組、重新發 AccessKey。舊的請求日誌與用量統計能不能帶過去，README 的說法是「無法遷移」，所以答案是不能。
第二個訊號是版本節奏。近期發布是 v2.0.0-rc.11、rc.10、rc.9，三天內連續三個候選版。這代表 2.0 仍在收尾階段，介面與行為都可能再動。把 rc 版放進正式環境不是不行，但你得接受在正式版之前可能還要再經歷幾次設定或資料結構的調整。
這兩件事合起來是一個明確的採用門檻：全新部署的人負擔很輕，正在跑 1.x 的人則要先想清楚舊資料怎麼處理，以及新環境要不要等正式版。
它不適合誰：單上游、要語意轉換、不想碰資料庫
第一種不適合的情況前面提過，這裡講另外兩種。
如果你的痛點是跨供應商的 API 形狀不一致，例如工具呼叫的欄位、圖片輸入的格式、串流事件的命名，GPT-Load 幫不上忙。它的協議表是按原生介面切的，客戶端維持自己的協議，閘道負責把請求送到對的憑證上。要處理形狀差異，你需要的是 LiteLLM 這類以統一介面為核心的代理：它把不同供應商的回應正規化成同一種格式，代價是你要接受它定義的抽象，並且在供應商推出新功能時等它跟上。兩者的差異不在功能多寡，而在你希望閘道是透明的還是有主張的。GPT-Load 選擇透明，LiteLLM 選擇統一。
第三種是維運預算有限的情境。README 明說內嵌 UI 由 SQLite、MySQL 或 PostgreSQL 支撐，也就是說這是一個有狀態服務，不是無狀態反向代理。你要考慮資料庫的備份、憑證加密金鑰的保管、以及 auth.key 這把管理金鑰的存放位置。如果你的規模還不到需要輪替憑證，這些都是淨成本。
還有一個實務限制：固定 OAuth 回呼埠讓同一台主機只能跑一個預設實例。想在測試與正式環境各跑一份，得先解決埠衝突。
授權與後續維護的實際成本
授權是 MIT，條款寬鬆，自架與商用都不需要額外授權安排。README 沒有提到任何企業版或授權金鑰機制，管理介面與排程功能都在同一個倉庫裡。
維護成本主要來自三個地方。上游協議會變，OpenAI Responses 這類介面還在演進，閘道要跟著追；訂閱通道的 OAuth 流程依賴上游客戶端的固定回呼埠，上游一改就得跟著改；憑證本身會過期或被撤銷，冷卻與黑名單機制能吸收一部分，但最終還是需要有人看健康狀態。
升級成本則取決於你從哪個版本進來。全新部署在 2.0 正式版之前，每次 rc 都要先看 release notes 再決定要不要跟。從 1.x 過來的人，成本已經被 README 的警告框寫死了：無法就地遷移，等於重建。
最後一個無法從材料確認的點是專案的長期維護承諾。這裡沒有貢獻者數量、沒有發布週期承諾、也沒有支援管道說明，只有官方網站與贊助聯絡信箱。對內部工具這通常夠用，對要放進關鍵路徑的服務，這是你得自己評估的風險。
編輯結論
如果你手上同時有多把 OpenAI、Anthropic、Gemini 金鑰，或混用 Codex、Claude 這類訂閱帳號，而且願意自己跑 Docker 與資料庫，GPT-Load 的群組、AccessKey、冷卻與黑名單機制能省下自行拼裝輪替邏輯的工。反過來說，單一上游、單一金鑰的使用者不需要它；把閘道當成跨供應商語意轉換層的人也不該選它，因為 README 的定位是客戶端維持原生介面。導入前先確認三件事：你現在跑的是 1.x 還是全新部署，因為 2.0 無法就地開啟或匯入 1.x 資料；你的資料庫要選 SQLite、MySQL 還是 PostgreSQL；以及正式版何時脫離 rc，因為近期版本仍是 v2.0.0-rc.11 這種候選版節奏。
社群筆記